У нас есть приложение SaaS, которое нам необходимо для обеспечения высокой доступности. У нас уже есть дорогостоящий, хорошо обслуживаемый отказоустойчивый кластер Hyper-V, но сегодня в центре обработки данных, в котором мы размещаем этот кластер, произошло пятичасовое отключение электроэнергии, в результате чего мы полностью отключились. Итак, теперь мы задаемся вопросом, может ли лучше использовать серверы в двух отдельных центрах обработки данных. Если предположить, что вся внутренняя репликация файлов и репликация данных работают между этими двумя сайтами, мы задаемся вопросом, как обрабатывать внешнюю маршрутизацию - неудивительно, как мы подходим к проблеме, мы всегда заканчиваем тем, что балансировщик нагрузки единственная точка отказа.
Итак, вопрос в том ... как мы можем настроить балансировку нагрузки между двумя хостинговыми сайтами, чтобы балансировщик нагрузки не был единственной точкой отказа? Есть ли способ использовать два отдельных балансировщика нагрузки, по одному на каждом сайте? Стоит ли рассматривать циклический DNS?
Для этого вам необходимо иметь:
Есть два распространенных способа сделать это. Один простой, один ... нет.
Round-Robin DNS - это не совсем то, что вам нужно, потому что, скорее всего, вы хотите все запросы на переход к первичному DC, а второй DC используется только во время простоя первого.
Что ты жестяная банка do, хотя для вашего DNS установлен очень низкий TTL (скажем, 30 секунд или 5 минут), что будет означать, что если ваш DC действительно выйдет из строя, вы просто обновите свой DNS, и в течение 5 минут или около того все ваши клиенты будут указывать на другой ваш DC.
Это означает, что, поскольку у ваших двух контроллеров домена будут разные макеты IP, вам необходимо отрегулировать это при настройке центра обработки данных.
По сути, если вы задаете этот вопрос, то это вне вашей досягаемости. Короче говоря, ваши IP-адреса остаются прежними, но они «перемещаются» из одного центра обработки данных в другой. Это включает в себя дорогие маршрутизаторы, дорогие диапазоны IP-адресов и дорогие подписки на ваш локальный реестр для номеров AS и диапазонов IP-адресов.
Маршрутизаторы BGP перестают рекламировать вашу в основном центре обработки данных и начинают размещать рекламу в дополнительном центре обработки данных. Затем Интернет обходит автономный центр обработки данных и отправляет трафик на ваш новый DC.
Если вы виртуализированы с помощью ESXi и vSphere, у VMWare есть довольно хороший продукт, который мы однажды опробовали и который назывался VMWare Site Recovery Manager, который в основном делает все за вас. Он поддерживает синхронизацию конфигураций ваших виртуальных машин и включает их на 2-м сайте, когда 1-й сайт отключается. Хотя это большие деньги.
Спустя годы ... но для тех, кто все еще ищет, они кажутся наиболее доступными / простыми решениями для аварийного переключения DNS:
Вам необходимо сбалансировать нагрузку на балансировщики нагрузки.
Вы жестяная банка сделайте это с помощью циклического перебора DNS, но у этого подхода есть много проблем. Вы не можете контролировать клиентов, которые кэшируют записи дольше, чем вы хотели бы, и вы не можете заставить трафик идти в определенное место.
Вы также можете сделать это с помощью глобальной балансировки нагрузки сервера (GSLB). Это более продвинутый способ использования DNS для обеспечения видимости нескольких центров обработки данных из Интернета. Короче говоря, вы настраиваете некий механизм для разделения вашего трафика на части и используете DNS для выбора части. Мы используем хеш DNS-преобразователя, настроенного для поиска клиента. Другие используют географию для маршрутизации к «ближайшему» центру обработки данных. Вам нужно будет добавить какой-то механизм для быстрого удаления IP-адреса из GSLB, если какая-то единая точка отказа для этого центра обработки данных или кластера выйдет из строя.
http://www.eukhost.com/web-hosting/kb/global-server-load-balancing/
Наконец, некоторые действительно продвинутые люди решают эту проблему с помощью Anycast DNS. Это снова попытка использовать подход «ближайшего» центра обработки данных. Anycasting для вашей службы означает, что вам нужно будет устранить любую "сохранность состояния". Это может оказаться трудным.