Когда мой веб-сервер A отключается от сети, как мне автоматически перенаправить всех пользователей на мой веб-сервер B в другом городе, и наоборот?

Когда мой веб-сервер A отключается от сети, как мне автоматически перенаправить всех пользователей на мой веб-сервер B в другом городе, и наоборот?

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

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

Кажется, что принятый ответ « перенаправить на статическую страницу на другом веб-сервере, когда основной веб-сервер не работает », поддерживает веб-серверы в 2 разных городах. Но как установка части программного обеспечения на одной коробке помогает мне после того, как эта коробка отключена?

Как это делают циклические DNS и сети доставки контента (CDN)?

Я полагаю, один подход начинается примерно так:

1. Я получаю IP-адрес каждого из моих физических веб-серверов.
2. Я поместил IP-адрес каждого из моих физических веб-серверов в запись DNS для одного доменного имени «веб-сайта» (несколько записей A или AAAA или оба).
3. ... тогда что мне нужно делать?

Я полагаю, что другой подход начинается что-то вроде

1. Я использую некоторый динамический DNS-провайдер для одного доменного имени, которое, как я ожидаю, пользователи будут набирать в веб-браузере.
2. Я установил на каждом веб-сервере задание cron, которое периодически сообщает провайдеру DNS свой собственный IP-адрес (обновляет запись A или запись AAAA) или свое собственное доменное имя (обновляет запись CNAME или запись DNAME).
3. ... тогда что мне нужно делать?

(На данный момент я был бы рад, если бы мои пользователи получали статическую веб-страницу с моей контактной информацией и сноской, в которой говорится, что «основной веб-сервер отключен», когда веб-сервер А отключен. Это уже намного лучше, чем текущая система, которая просто выдает ошибку «сервер не найден». В идеале я бы хотел, чтобы A и B были полностью синхронизированы и, по-видимому, идентичны - но это другой вопрос: эквивалентно CDN, но для динамического содержимого? ).

Похоже, вы ищете решение для глобальной балансировки нагрузки на сервер (GSLB). GSLB обычно использует «умный» DNS для направления пользователей на разные серверы на основе ряда параметров (например, недоступность сервера, высокая загрузка, геолокация ip и т. Д.).

Например, скажем, у вас есть два веб-сервера: один на западе (10.10.10.1/24) и один на востоке (10.20.20.1/24). Скажите, что ваше веб-имя хоста - www.connect.com.

GSLB может быть настроен как ваш DNS или как CNAME. В любом случае, пользователь вводит www.connect.com, запрос DNS направляется в решение GSLB, и он отвечает либо 10.10.10.1, либо 10.20.20.1 в зависимости от параметров. GSLB обычно устанавливает низкий TTL, чтобы клиентский хост / браузер кэшировал ответ как можно меньше времени. Существуют разные способы решения проблемы постоянства, но это выходит за рамки этого сценария.

Допустим, восточный (10.20.20.1) веб-сервер отключается. GSLB обычно реализует проверки работоспособности для проверки работоспособности внутренних узлов. GSLB замечает, что восток не работает, и все последующие записи DNS для www.connect.com будут разрешаться до 10.10.10.1.

Если у вас есть решение балансировки нагрузки на локальном сервере (SLB), вы можете настроить его так, чтобы www.connect.com был VIP / VS (скажем, 192.168.1.1/24) с двумя внутренними узлами (10.10.10.1/24 и 10.20.20.1/24). Технически узлы могут находиться в разных сегментах сети, если локальный SLB может достичь другого сервера. SLB-решение может быть достаточно умным, чтобы перенаправить пользователей на доступный сервер, если внутренний узел выйдет из строя. Если вы используете F5 LTM, вы можете легко создать iRule для такого события. Citrix NetScaler и другие решения SLB также должны иметь аналогичные возможности.

RR DNS не работает в этом случае. DNS RR не имеет встроенной разведки. Единственный способ реализовать сценарий использования DNS - это использовать своего рода «умные» днс с помощью решения GSLB (или аналогичного).

CDN обычно реализуют решения GSLB / SLB, чтобы обеспечить HA для своих клиентов.

Вы хотите взглянуть на глобальные балансировщики нагрузки, такие как F5 и Cisco. В основном они делают некоторые уловки с DNS, если партнер не работает, и если партнер работает, они передают данные другим пользователям через балансировщик нагрузки.

Другим дешевым, быстрым и надежным решением для оценки может быть использование аварийного переключения Amazon Route 53 http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html . Эта функция была выпущена 11 февраля 2013 года и обеспечивает высокую доступность и / или балансировку нагрузки между первичным и вторичным сайтами.

Асим

Скажите, если вы используете какой-либо обратный прокси-сервер в своей среде, если вы можете перенаправить его на сервер резервного копирования.

если нет, то F5 - хорошая идея для использования.

также, если вы зарегистрировали домен у стороннего регистратора доменов, вы можете получить конфигурацию DNS-сервера для перенаправления на новый сервер или сервер резервного копирования.

Вы можете сделать это без использования сетевого устройства, используя как минимум следующие два метода, но они потребуют контроля изменений:

• Обратный прокси, вам нужно удалить сервер, который вы собираетесь отключить от кандидатов на прокси

• DNS, вам придется планировать заранее, сменить DNS и дождаться прохождения TTL

Вы также можете выполнить автоматическую балансировку нагрузки и активное-активное аварийное переключение, особенно для веб-сервера, обслуживающего статические страницы с использованием протоколов маршрутизации. Оформить заказ EGP и IGRP. В Интернете должен быть справочный материал (в частности, связанный с Cisco), в котором подробно описывается, как сделать это с двумя или более хостами через маршрутизатор.