Альтернативы Heartbeat, Pacemaker и CoroSync?

Существуют ли какие-либо основные альтернативы автоматического переключения при сбое в Linux, кроме типичных комбинаций Heartbeat / Pacemaker / CoroSync? В частности, я настраиваю отработку отказа на экземплярах EC2, которые поддерживают только одноадресную передачу - без многоадресной или широковещательной передачи. Я специально пытаюсь разобраться с несколькими имеющимися у нас программами, у которых еще нет автоматического переключения при отказе и которые не поддерживают среды с несколькими мастерами. Это включает в себя такие инструменты, как HAProxy и Solr.

У меня работает Heartbeat + Pacemaker, но я не в восторге от этого. Вот некоторые из моих проблем:

• Сердцебиение - само по себе ограничено двумя узлами. Я хотел бы иметь 3+.
• Кардиостимулятор - невозможно настроить автоматически. Кластер должен работать с кворумом, а затем он все еще требует ручной настройки.
• CoroSync - не поддерживает одноадресную передачу.

Кардиостимулятор работает очень хорошо, хотя его мощность затрудняет настройку. Настоящая проблема Pacemaker заключается в том, что простого способа автоматизации конфигурации не существует. Я действительно хочу запустить экземпляр EC2, установить Chef / Puppet и запустить весь кластер без моего вмешательства.

Я предпочитаю использовать keepalived для высокой доступности. Я считаю, что его проще настроить (один демон и конфиг), чем heartbeat и company. Единственный недостаток, с которым я столкнулся, заключается в том, что keepalived по умолчанию не имеет одноадресной опции и использует только VRRP для связи ( однако автор HAProxy написал одноадресную заплатку для keepalived).

На самом деле я работаю над чем-то очень похожим на то, что вы описали (отказоустойчивый кластер на EC2), и после того, как опробовал Heartbeat, остановился на Corosync в качестве моего уровня обмена сообщениями. Corosync будет работать на нескольких серверах и поддерживает Unicast (UDPU) начиная с версии 1.3.0 (с ноября 2010 г.). Я установил и протестировал Corosync в облаке Amazon EC2 (используя Amazon AMI для Linux) и могу подтвердить, что он работает без проблем.

Пример файла udpu устанавливается в / etc / corosync.

Добавьте один блок-член в раздел интерфейса для каждого узла и укажите транспорт как updu. (Я использовал тот же порт, что и пульс в примере ниже, но вы можете изменить его по своему желанию).

например:

totem {
        version: 2
        secauth: off
        interface {
                member {
                        memberaddr: 10.xxx.xxx.xxx
                }
                member {
                        memberaddr: 10.xxx.xxx.xxx
                }
                ringnumber: 0
                bindnetaddr: 10.xxx.xxx.xxx
                mcastport: 694
        }
        transport: udpu
}

(Предполагается, что Heartbeat поддерживает кластеры узлов 3+ в версиях 1.2.3+, хотя я никогда не пробовал лично и не знаю, будет ли это работать с Unicast).

Извините, но часть о Pacemaker не соответствует действительности. В регрессионных и релиз-тестах Pacemaker широко используются средства автоматизации.

Чтобы настроить без активного кластера, добавьте к ним все команды CIB_file=/var/lib/heartbeat/crm/cib.xmlили задайте их в своей среде. Просто убедитесь, что вы удалили файл .sig перед запуском кластера.

Для кластеров без кворума большинство, если не все инструменты, должны поддерживать -fили --forceкоторые будут указывать кластеру принять изменение в любом случае. Если вы нашли инструмент, которого нет - пожалуйста, сообщите об ошибке.

В мире открытого исходного кода есть RedHat Cluster Suite . Прошло несколько лет с тех пор, как я внедрил RHCS, поэтому у меня не так много важных вещей, чтобы сказать об этом сегодня.

С коммерческой точки зрения существует кластерный сервер Veritas . Нет опыта с этим.

Гораздо более простым и открытым инструментом HA является UCARP . UCARP не предоставляет почти такую ​​же «инфраструктуру», как Heartbeat / Pacemaker / CoroSync, но вы можете создавать решения HA на ее основе.

Вы также можете создать высокодоступную инфраструктуру с помощью технологий виртуализации, но эти решения, как правило, ориентированы на доступность на уровне хоста, а не на уровень приложений.

Существует Oracle Clusterware для Oracle Unbreakable Linux, хотя я им не пользовался.

Если вы уже используете EC2, почему бы не использовать Elastic Load Balancing ? Это позволит вам достичь доступности на уровне приложений без необходимости настраивать аварийное переключение самостоятельно.

Veritas Cluster великолепен (по сравнению с Linux-Heartbeat, AIX-hacmp, HP-Serviceguard и Sun кластером), но стоит больших денег. В последний раз, когда я смотрел на него, его цена была основана на процессорных ядрах кластера. Текущий поставщик Symantec ...

Я написал менеджер отказоустойчивого кластера в оболочке posix: https://github.com/nackstein/back-to-work

Посмотрите на это, я ищу кого-то, кто хочет попробовать и помочь в разработке.

opensvc ( https://www.opensvc.com ) поддерживает несколько драйверов пульса:

• одноадресный
• многоадресного
• общий диск
• 3-е место ретрансляции

а также иметь механизмы кворума в случае расщепления мозга.

Мне удалось автоматически настроить кластер из 4 узлов, состоящий из 2 экземпляров облака Google + 2 экземпляров Amazon с помощью terraform + ansible.