Отказоустойчивый кластер из 2+ серверов для аварийных ситуаций только с 2+ физическими машинами
TL; DR: Вопрос выделен жирным шрифтом ниже
Здесь http: //www.howto-expert.com/how-to-create-a-server-failover-solution/ - это (я предполагаю) старый пост в блоге, объясняющий, как настроить 2 серверных машины (один главный и одно подчиненное устройство), каждый из которых расположен в разных географических точках.
Контекст касается самостоятельного хостинга службы веб-сайта (+ базы данных), и сделать его таким, чтобы, когда мастер не прошел проверку работоспособности (например, потому что машина выключена , или подключение к Интернету отсутствует, или администратор выполняет обновления и т. д.), тогда подчиненный берет на себя обслуживание веб-сайта (ов) для посетителей.
Здесь используется программное решение «DNS Made Easy», которое, кажется,
- вращается на третьей машине,
- связывает IP-адрес веб-сайта с этой третьей машиной (когда нужно выбрать доменное имя через регистратора. ),
- и, кажется, перенаправляет посетителя на один из двух хостов веб-сайта.
(Я бы предпочел в качестве решения что-то вроде HAproxy + KeepAliveD, только потому, что это бесплатно.)
Важная иллюстрация из приведенный выше URL-адрес:
Но теперь, если предположить, что я предоставил оборудование для второй подчиненной машины именно на тот случай, если главная выйдет из строя, тогда вложения будут бесполезными, если 3-я машина ( монитор аварийного переключения на pic) сбой.
ОСНОВНОЙ ВОПРОС: Как встроить мониторинг аварийного переключения на 2 машины?
ИЛИ, альтернативно, как можно выполнить аварийное переключение только с 2 физическими машинами?
(для того, чтобы получить 2 балла отказа вместо 1)
Вопросы подразумевают:
Почему у людей всегда остается единственная точка отказа (изолированный монитор аварийного переключения)?
Должен ли я использовать KVM, чтобы иметь «2 сервера» на каждой машине (monitor1 + master на master, и monitor2 + slave на slave) или я могу установить все различные службы на машине?
Можно ли иметь 2 машины, расположенные друг от друга с одним и тем же IP-адресом?
В этом руководстве по DNS Made Easy описывается узел мониторинга, способный вносить изменения в DNS; балансировщик нагрузки на основе DNS.Да, один узел мониторинга — это единая точка отказа. Однако, находясь вне пути данных, пока активный узел работает, соединения будут продолжать работать. Даже если узел мониторинга не работает. Кроме того, он может быть расположен на 3-м хостинге, чтобы лучше обнаруживать проблемы, достигающие его извне. Одним из недостатков является то, что обновления DNS могут занять некоторое время, они долго кэшируются.
haproxy — это другой зверь. Он проксирует соединения через серверные части и, как таковой, находится на пути к данным. Обычно они находятся в одном и том же месте центра обработки данных, чтобы уменьшить задержку. Прокси означает, что он может делать умные вещи с запросами, быстро перенаправлять на другой сервер, завершать TLS, возиться с заголовками HTTP и многое другое. Незапланированные простои приведут к отключению службы, поэтому рассмотрите их высокую доступность.
Кластеры — это еще одна вещь. Именно здесь ресурсы приложения, такие как IP-адреса или общее хранилище, перемещаются между хостами. Общее хранилище позволяет выполнять отработку отказа баз данных с одними и теми же данными. Однако их сложно реализовать безопасно, раздел кластера — разделенный мозг — может быть опасен для целостности системы. Кроме того, их приемы хранения и сети предназначены для традиционных центров обработки данных и, вероятно, не будут работать с вашим типичным провайдером хостинга виртуальных машин.
Возможно ли иметь 2 машины, расположенные вдали друг от друга, которые по-прежнему используют один и тот же IP-адрес?
Нелегко, это другой уровень этого проекта. В Интернете вам нужно будет проделать какой-нибудь трюк BGP, например, anycast. Вам потребуется собственное IP-пространство, ASN и несколько маршрутизаторов BGP.Или передайте его балансировщику нагрузки какого-либо провайдера в качестве услуги.
В конечном счете определите свои требования к скорости восстановления и режимам сбоя, которых следует избегать. Затем реализуйте что-то, чтобы удовлетворить их.
Если у вас есть серверы с разными IP-адресами и вы можете выдержать пару часов простоя, ручное изменение IP-адреса может сработать. Красиво и просто.
Если вам нужен немедленный автоматический переход на другой ресурс, отсутствие единой точки отказа и глобальная маршрутизация в стиле CDN, это значительно более сложная схема.