Многопользовательская высокая доступность

У нас есть SaaS-приложение, которое нам необходимо для высокой доступности. У нас уже есть дорогой, хорошо обслуживаемый отказоустойчивый кластер Hyper-V, но сегодня в центре обработки данных, где мы размещаем этот кластер, произошло отключение питания на пять часов, которое полностью вывело нас из строя. Итак, теперь мы задаемся вопросом, может ли быть лучше подходить к использованию серверов в двух отдельных центрах обработки данных. Предполагая, что мы выполняем всю внутреннюю репликацию файлов и репликацию данных между этими двумя сайтами, мы задаемся вопросом, как справиться с интерфейсной маршрутизацией - неудивительно, как мы подходим к проблеме, мы всегда получаем балансировщик нагрузки единственная точка отказа.

Итак, вопрос в том ... как настроить балансировку нагрузки между двумя хостинговыми сайтами так, чтобы балансировщик нагрузки не был единственной точкой отказа? Есть ли способ использовать два отдельных балансировщика нагрузки, по одному на каждом сайте? Должны ли мы рассмотреть круговой DNS?

Чтобы сделать это правильно, вам необходимо иметь:

• Два отдельных экземпляра в двух центрах обработки данных (как вы уже определили)
• Синхронизация между двумя центрами обработки данных (как вы уже определили)
• Способ перенаправления клиентов от одного к другому в случае сбоя

Есть два распространенных способа сделать это. Один простой, один ... нет.

DNS

Round-Robin DNS - не совсем то, что вам нужно, потому что, скорее всего, вы хотите, чтобы все запросы отправлялись на основной DC, а второй DC используется только во время простоя первого.

Однако вы можете установить очень низкий TTL на вашем DNS (скажем, 30 секунд или 5 минут), что будет означать, что если ваш DC не работает, вы просто обновите свой DNS и в течение 5 минут или около того, все ваши клиенты будут указывать на ваш другой округ Колумбия.

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

BGP

По сути, если вы задаете этот вопрос, то это вне вашей досягаемости. Короче говоря, ваши IP-адреса остаются прежними, но они «перемещаются» из одного центра обработки данных в другой. Это включает дорогие маршрутизаторы, дорогие диапазоны IP-адресов и дорогие подписки на локальный реестр для номеров AS и диапазонов IP-адресов.

Маршрутизаторы BGP перестают рекламировать свой в своем основном центре обработки данных и начинают рекламу в своем дополнительном центре обработки данных. Затем Интернет обходит автономный центр обработки данных и отправляет трафик на ваш новый DC.

Если вы виртуализированы с ESXi и vSphere, у VMWare есть довольно хороший продукт, который мы опробовали однажды, под названием VMWare Site Recovery Manager , который в основном все делает за вас. Он синхронизирует ваши настройки виртуальной машины и включает их на втором сайте, когда первый сайт отключается. Это большие деньги, хотя.

Вам необходимо сбалансировать нагрузку балансировщиков нагрузки.

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

Вы также можете сделать это с помощью глобальной балансировки нагрузки на сервер (GSLB). Это более продвинутый способ использования DNS, чтобы вы могли видеть из Интернета несколько центров обработки данных. Короче говоря, вы настраиваете некоторый механизм для разделения вашего трафика на фрагменты и используете DNS для выбора фрагмента. Мы используем хэш DNS-преобразователя, настроенного для поиска клиента. Другие люди используют географию для маршрутизации в «ближайший» центр обработки данных. Вам нужно будет добавить какой-то механизм для быстрого удаления IP-адреса из GSLB в случае отказа какой-либо одной точки отказа для этого центра обработки данных или кластера.

http://www.eukhost.com/web-hosting/kb/global-server-load-balancing/

Наконец, некоторые действительно продвинутые люди решают эту проблему с помощью Anycast DNS. Это снова пытается использовать «ближайший» подход к центру обработки данных. Anycasting ваш сервис означает, что вам нужно будет устранить любую «Statefullness». Это может оказаться трудным.

Годы спустя ... но для тех, кто все еще ищет, это, кажется, самые доступные / простые решения для отработки отказа DNS:

• DynDNS
• DNS Made Easy
• Amazon Route 53