Имеет ли смысл экосистема Pacemaker (Corosync и т. Д.) В контексте EC2? До какого-то момента Corosync требовал многоадресной IP-рассылки (недоступной на EC2), но я думаю, что сейчас она транслировалась. Тем не менее, Pacemaker et. al. правильный инструмент для управления кластером на EC2, например отслеживать друг друга на предмет сбоев и, таким образом, запускать создание новых экземпляров для замены вышедших из строя?
Думаю, отчасти проблема в том, что я потратил довольно много времени, просто поправляя здесь всех игроков (Heartbeat, Corosync, OpenAIS и т. Д.), И я все еще пытаюсь понять, что это на самом деле являются (помимо туманных терминов, например, что Pacemaker является «диспетчером ресурсов кластера» и что Corosync обеспечивает «надежную инфраструктуру обмена сообщениями и членства»).
Поэтому приношу свои извинения, если мой вопрос сам по себе не совсем понятен или не совсем понятен. Приветствуются любые идеи. Спасибо.
Контролирует ли EC2 состояние сервисов внутри гостей?
Если нет, и это то, что вам нужно, то здесь будет уместен кардиостимулятор. Corosync, вероятно, пока не подходит, поскольку он выполняет только mcast и bcast, поэтому это будет сценарий с кардиостимулятором + сердцебиением.
Вот руководство о том, как люди делают это с экземплярами линода, большая часть которого, вероятно, также будет актуальна для EC2: http://library.linode.com/linux-ha/
Чтобы ответить на вопрос о том, что это за части, Pacemaker - это то, что запускает и останавливает службы и содержит логику для обеспечения их работы и работы только в одном месте (во избежание повреждения данных).
Но он не может этого сделать без возможности разговаривать с самим собой на другом узле (ах), где используются сердцебиение и / или коросинхронизация.
Подумайте о биении и коросинхронизации как о шине, по которой любой узел может отправлять сообщения и знать, что они будут получены всеми его узлами. Шина также гарантирует, что все согласятся, кто подключен (а кто нет) к шине, и сообщит вам, когда этот список изменится.
Для двух узлов Pacemaker может так же легко использовать сокеты, но помимо этого сложность растет довольно быстро, и ее очень трудно исправить, поэтому действительно имеет смысл использовать существующие компоненты, которые доказали свою надежность.
Мой инстинкт интуитивно говорит «нет», это действительно не те инструменты для управления кластером на EC2. Я использовал их на отдельном оборудовании и обнаружил, что у вас должен быть очень специфический набор требований / случаев отказа, чтобы они действительно имели смысл. Я не могу придумать в своей голове вариант использования, который потребовал бы этих инструментов по сравнению с более конкретными системами облачного мониторинга и такими инструментами, как обмен сообщениями, разработанными с учетом платформы.
Тем не менее, я не считаю свой ответ здесь авторитетным, я действительно надеюсь, что кто-то присоединится к нам, получив немного больше опыта работы с этим инструментом, установленным в облаке ec2.
Экземпляры EC2 очень похожи на реальное оборудование для целей управления. Если он выходит из строя, он выходит из строя (или если физический хост выходит из строя). На EC2 нет внутреннего механизма аварийного переключения. Вы получаете возможность перезапустить экземпляр, и он «волшебным образом» появится снова, без какого-либо физического вмешательства или обслуживания, но вам все равно придется делать это вручную или автоматически (возможно, EC2 перезапустит его за вас, я не теперь это). Это может означать отключение на несколько минут.
Если вам нужно решение высокой доступности, оно, вероятно, будет быстрее с точки зрения восстановления, но вам нужно постоянно поддерживать 2 экземпляра EC2.
Но идеальная архитектура для EC2 - иметь несколько экземпляров нужной службы, все они работают параллельно и принимают запросы, и если один из них выйдет из строя, остальные воспользуются нехваткой ресурсов.