Кардиостимулятор, Heartbeat, и т.д. имеют смысл для EC2?
Можно также сделать это с rsync. Настройте rsync сервер в машине Linux и используйте rsync клиент в машине Windows для получения файлов.
С rsync Вы сможете возобновить прерванные передачи
EC2 контролирует здоровье сервисов в гостях?
В противном случае и это - что-то, что Вы хотите, затем Кардиостимулятор был бы релевантен здесь. Corosync, вероятно, еще не является опцией, поскольку он только делает mcast и bcast, таким образом, это был бы pacemaker+heartbeat сценарий.
Вот руководство по тому, как люди делают это с linode экземплярами, большая часть его, вероятно, также будет релевантна на EC2: http://library.linode.com/linux-ha/
Для ответа на вопрос того, каковы части Кардиостимулятор является вещью, которая запускает и останавливает сервисы и содержит логику для обеспечения и что они работают, и что они работают только в одном месте (для предотвращения повреждения данных).
Но это не может сделать этого без способности говорить с собой на другом узле (узлах), который является, где heartbeat и/или corosync входят.
Думайте о heartbeat и corosync как шина, на которую любой узел может бросить сообщения и знать, что они будут получены всеми его коллегами. Шина также гарантирует, что все соглашаются, кто (и не), подключенный к шине, и говорит Вам, когда тот список изменяется.
Для двух узлов Кардиостимулятор мог так же, как легко использовать сокеты, но кроме того сложность растет вполне быстро и очень трудна разобраться - таким образом, действительно имеет смысл использовать существующие компоненты, которые, оказалось, были надежны.
-
1Кто-то еще недавно спросил то же самое. Это было, вероятно, самым соответствующим ответом: lists.linux-ha.org/pipermail/linux-ha/2010-October/041471.html – 16 October 2010 в 11:06
Мой инстинкт уровня пищеварительного тракта должен сказать "нет", это - действительно не правильные инструменты для кластерного управления на EC2. Я использовал их на одиноких аппаратных средствах и нашел, что у Вас должен быть очень определенный набор потребностей / случаи возникновения отказов для них, чтобы действительно иметь смысл там. Я не могу придумать вариант использования в голове, которая потребовала бы те инструменты по более определенным облачным системам контроля и оснащающий как обмен сообщениями, разработанный с платформой в памяти.
Это сказало, что я не считаю свой ответ авторитетным здесь, я действительно надеюсь, что кто-то соглашается с немного большим опытом с тем комплектом инструментальных средств в ec2 облаке.
Экземпляры EC2 очень похожи на реальные аппаратные средства в целях управления. Если это понижается, это понижается (или если физический хост понижается). Нет никакого внутреннего механизма для обработки отказа на EC2. Вы извлекаете пользу для перезапуска экземпляра, и это "волшебно" вновь появится, w/o любое физическое вмешательство, ни обслуживание, но все еще необходимо сделать это, или вручную или автоматически (возможно, EC2 перезапустит его для Вас, я не делаю теперь, когда). Это может означать отключение электричества нескольких минут.
Если Вы захотите решение HA, то это будет, вероятно, быстрее с точки зрения восстановления, но необходимо продолжить 2 экземпляра EC2 все время.
Но идеальная архитектура для EC2 должна иметь несколько экземпляров для сервиса, который Вы хотите, все работающие в параллели и берущий запросы, и если Вы умрете, то другие возьмут слабое.