Назад | Перейти на главную страницу

Отказоустойчивый кластер из 2+ серверов для аварийных ситуаций с 2+ физическими машинами

TL; DR: вопрос выделен жирным шрифтом ниже

Вот http://www.howto-expert.com/how-to-create-a-server-failover-solution/ это (я полагаю) старый пост в блоге, объясняющий, как настроить 2 серверных машины (один главный и один подчиненный), каждый из которых расположен в разных географических точках.
Контекст посвящен самостоятельному размещению службы веб-сайта (+ база данных) и делает ее так, чтобы, когда мастер не прошел проверку работоспособности (например, потому что машина выключена, или нет подключения к Интернету, или администратор выполняет обновления и т. ), затем подчиненное устройство берет на себя обслуживание веб-сайтов для посетителей.
Здесь используется программное решение «DNS Made Easy», которое

(Я бы предпочел в качестве решения что-то вроде HAproxy + KeepAliveD, просто потому, что оно бесплатное.)

Важная иллюстрация из URL-адреса выше:

Но теперь, если предположить, что я предоставил оборудование для второй ведомой машины именно на тот случай, если ведущая машина выйдет из строя, тогда вложения будут равны бесполезно, если 3-я машина (монитор аварийного переключения на картинке) вылетает.

ГЛАВНЫЙ ВОПРОС: Как встроить мониторинг аварийного переключения на 2 машины?
ИЛИ, альтернативно, как можно выполнить аварийное переключение только с 2 физическими машинами?
(чтобы получить 2 балла отказа вместо 1)

Вопросы, которые он подразумевает:
Почему у людей всегда остается единственная точка отказа (изолированный монитор аварийного переключения)?
Должен ли я использовать KVM, чтобы иметь «2 сервера» на каждой машине (монитор1 + главный в главном и монитор2 + подчиненный в подчиненном) или я могу установить все различные службы на машину?
Возможно ли, чтобы две машины, расположенные друг от друга, по-прежнему имели один и тот же IP-адрес?

В этом руководстве DNS Made Easy описывается узел мониторинга, способный вносить изменения в DNS; балансировщик нагрузки на основе DNS. Да, один узел мониторинга - это единственная точка отказа. Однако, находясь вне пути к данным, пока активен активный узел, соединения будут продолжать работать. Даже если узел мониторинга не работает. Кроме того, он может быть расположен на третьем хостинг-сайте, чтобы лучше выявлять проблемы, попадающие на него извне. Одним из недостатков является то, что обновления DNS могут занять некоторое время, они долго кешируются.

haproxy - это другой зверь. Он проксирует соединения через серверную часть и, как таковой, находится в пути данных. Обычно они находятся в одном месте центра обработки данных, чтобы уменьшить задержку. Прокси-сервер означает, что он может делать умные вещи с запросами, быстро перенаправлять на другой сервер, прекращать TLS, возиться с заголовками HTTP и многое другое. Незапланированные простои приведут к остановке службы, поэтому рассмотрите возможность их высокой доступности.

Другое дело - кластеры. Здесь ресурсы приложения, такие как IP-адреса или общее хранилище, перемещаются между хостами. Совместное хранилище позволяет переключать базы данных с одинаковыми данными. Однако их сложно реализовать безопасно, разделение кластера - разделенный мозг - может быть опасным для целостности системы. Кроме того, их уловки с хранилищем и сетью предназначены для традиционных центров обработки данных и, вероятно, не будут работать с вашим типичным провайдером хостинга виртуальных машин.

Возможно ли, чтобы две машины, расположенные друг от друга, по-прежнему имели один и тот же IP-адрес?

Непросто, это другой уровень этого проекта. В Интернете вам нужно будет проделать какой-нибудь трюк с BGP, например anycast. Вам понадобится собственное IP-пространство, ASN и несколько маршрутизаторов BGP. Или передайте его балансировщику нагрузки какого-нибудь провайдера в качестве услуги.

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

Если у вас есть серверы с разными IP-адресами и вы можете выдержать несколько часов простоя, изменение IP-адреса вручную может сработать. Красиво и просто.

Если вам нужна немедленная автоматическая отработка отказа, отсутствие единой точки отказа и глобальная маршрутизация в стиле CDN, это значительно более сложная конструкция.