Как настроить Nginx на двух машинах, чтобы в случае сбоя основной машины происходило автоматическое переключение на вторую машину? И какие здесь лучшие практики?
Кажется, уже много написано о том, как выполнить аварийное переключение для внутренних серверов, на которые направляется nginx. Я не об этом спрашиваю.
Мы используем Corosync и Pacemaker для активного / пассивного кластера nginx в нашей среде, который работает довольно хорошо.
Вот несколько ключевых моментов, о которых следует помнить, исходя из моего недавнего опыта.
/etc/corosync/corosync.conf), а не кардиостимулятора, у меня были частые проблемы, такие как расщепление мозга с последним в моем окружении.Вариант по умолчанию - использовать pcs команда для настройки кластера. Однако вы можете использовать crm также, который предпочитают немногие. Вам нужно будет установить crmsh из репозиториев Suse в зависимости от ОС. Это то, что я использую в дистрибутивах на основе Red Hat.
wget http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-6/network:ha-clustering:Stable.repo -nd -O /etc/yum.repos.d/crmsh.repo && yum install crmsh
После установки обязательно отключите stonith и quorum, а также установите липкость ресурсов. Эти команды должны работать нормально, если у вас двухузловой кластер.
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
pcs resource defaults resource-stickiness="INFINITY"
pcs resource defaults migration-threshold="1"`
Для синхронизации файлов между активным и пассивным узлами вы можете использовать такие инструменты, как rysnc или unison. Для синхронизации на уровне блока (может быть /etc/nginx смонтирован в файловой системе), вы можете использовать drbd, который можно легко добавить в качестве ресурса в кластер
Наконец, не забудьте сгруппировать все ресурсы и упорядочить их с помощью команды типа pcs constraint colocation и pcs constraint order
Вы можете легко использовать Google всю вышеуказанную информацию, вот несколько ссылок, которые помогут вам начать работу.
В случае простого сбоя отличным решением является использование демона Heartbeat для передачи IP-адреса на резервную машину. См. HOWTO Кэмерона Миллера для этого. Многие другие руководства доступны с использованием Поиск Google по запросу "сердцебиение nginx".
взгляните на мой писатель отказоустойчивого кластера в оболочке POSIX https://github.com/nackstein/back-to-work/ много написано о том, как d вам понадобится 3 узла, чтобы иметь кворум (другое программное обеспечение кластера использует 2 узла + общее хранилище или подход STONITH, где каждый узел пытается убить другого, но для этого требуется специализированное оборудование).
вы можете настроить 3 узла с доступом по ssh, которые будут использоваться как серверы блокировки (серверы кворума). Затем выберите, у двух из них будет виртуальный IP-адрес и запущен http-сервер. В случае сбоя возобновление работы переключит виртуальный IP-адрес и http-сервер. Если вам нужна помощь в настройке, напишите мне на почту (см. Код адреса)
У вас есть много вариантов.
Дешево и эффективно, используйте циклический перебор DNS, его используют почти все крупные игроки (хотя и не только для аварийного переключения). Вот пример:
$ host amazon.com
amazon.com has address 176.32.98.166
amazon.com has address 205.251.242.54
amazon.com has address 176.32.103.205
amazon.com mail is handled by 5 amazon-smtp.amazon.com.
$
В этом случае отработку отказа выполняет браузер. На самом деле это довольно эффективно, и все, что вам нужно сделать, это настроить записи DNS.
Другой вариант, не ограниченный HTTP / SMTP, может заключаться в использовании аппаратных балансировщиков нагрузки, например, BIG-IP от F5.
Кроме того, существует множество других решений, и нет места для их перечисления, но их легко найти в Google.