Имеют ли смысл кардиостимулятор, сердцебиение и т. Д. Для EC2?
Имеет ли смысл экосистема Pacemaker (Corosync и т. Д.) В контексте EC2? До некоторого момента Corosync требовала многоадресную IP-рассылку (недоступно в EC2), но я думаю, что она уже транслировалась. Тем не менее, Pacemaker et. и др. правильный инструмент для кластера, чтобы управлять собой на EC2, например, контролировать друг друга на предмет сбоев и, таким образом, запускать новые экземпляры для замены неисправных?
Я полагаю, что часть проблемы в том, что я потратил довольно много времени, просто выпрямляя всех игроков здесь (Heartbeat, Corosync, OpenAIS и т. Д.), И я все еще пытаюсь выяснить, каковы эти вещи на самом деле (помимо туманных терминов, например, что Pacemaker является "администратором ресурсов кластера", а Corosync предоставляет "надежную инфраструктуру обмена сообщениями и членства").
Следовательно, извинения, если мой вопрос сам по себе немного неуклюж или не имеет полностью смысла. Любая идея будет принята с благодарностью. Благодарю.
3 ответа
Контролирует ли EC2 состояние служб внутри гостей?
Если нет, и это то, что вы хотите, то Pacemaker будет уместным здесь. Corosync, вероятно, пока не подходит, так как он работает только с mcast и bcast, так что это будет сценарий кардиостимулятор + сердцебиение.
Вот руководство о том, как люди делают это с экземплярами линод, большая часть которого, вероятно, также будет иметь отношение к EC2: http://library.linode.com/linux-ha/
Чтобы ответить на вопрос о том, что такое части, Pacemaker - это то, что запускает и останавливает службы и содержит логику для обеспечения того, что они работают и работают только в одном месте (чтобы избежать повреждения данных).
Но он не может сделать это без возможности общаться с самим собой на другом (их) узле (ах), в который входят сердцебиение и / или коросинхронизация.
Представьте, что сердцебиение и corosync - это шина, на которую любой узел может пересылать сообщения и знать, что они будут получены всеми его коллегами. Шина также гарантирует, что все согласны с тем, кто (а не) подключен к шине, и сообщат вам, когда этот список изменится.
Для двух узлов Pacemaker может так же легко использовать сокеты, но помимо этого сложность растет довольно быстро, и ее очень сложно понять - поэтому действительно имеет смысл использовать существующие компоненты, которые доказали свою надежность.
Мой инстинкт инстинктивного уровня заключается в том, чтобы сказать "нет", это действительно не те инструменты для управления кластерами в EC2. Я использовал их на отдельном оборудовании и обнаружил, что у вас должен быть очень специфический набор потребностей / случаев отказа, чтобы они действительно имели смысл там. Я не могу придумать случай использования в моей голове, который потребовал бы этих инструментов по сравнению с более конкретными системами облачного мониторинга и такими инструментами, как обмен сообщениями, разработанный с учетом платформы.
Тем не менее, я не считаю, что мой ответ заслуживает доверия здесь, я действительно надеюсь, что кто-то присоединится к нему с немного большим опытом работы с этим набором инструментов в облаке ec2.
Экземпляры EC2 очень похожи на реальное оборудование для целей управления. Если он выходит из строя, он выходит из строя (или если физический хост выходит из строя). На EC2 нет встроенного механизма аварийного переключения. Вы получаете выгоду для перезапуска экземпляра, и он "волшебным образом" появится снова, без какого-либо физического вмешательства или технического обслуживания, но вам все равно придется сделать это, вручную или автоматически (возможно, EC2 перезапустит его для вас, я не теперь это). Это может означать отключение на несколько минут.
Если вам нужно решение HA, оно, вероятно, будет быстрее с точки зрения восстановления, но вам придется постоянно поддерживать 2 экземпляра EC2.
But the ideal architecture for EC2 is to have multiple instances for the service you want, all running in parallel and taking requests, and if one dies, the others will pick up the slack.