Сквозной отказоустойчивый дизайн, отказ на уровне DNS?

Question

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

Прикладная сторона вещей, похоже, в основном решается с помощью настройки базы данных master-slave между colos и сервисами, предназначенными для восстановления и возможности работать в середине потока.Я пытаюсь разработать стратегию перемещения трафика с основного сайта на резервный.Отказоустойчивость DNS, даже при низких TTL, по-видимому, несет в себе изрядная задержка.

Какие стратегии вы бы порекомендовали для быстрого перемещения трафика между colo, предполагая, что серверы в главном colo недоступны?

Если у вас есть другой интересный опыт / мудрые слова о переходе на другой ресурс в cross-colo, я бы тоже хотел их услышать.

Answer 1

Механизмы, основанные на DNS, вызывают проблемы, даже если вы указываете низкие значения TTL в своих файлах зон.

Причина этого в том, что многие приложения (например,MSIE) поддерживают свои собственные кэши, которые игнорируют TTL.Другое программное обеспечение выполнит один gethostbyname() или эквивалентный вызов и сохранение результата до перезапуска программы.

Хуже того, известно, что рекурсивные DNS-серверы многих ИНТЕРНЕТ-провайдеров игнорируют значения TTL ниже их собственного предпочтительного минимума и навязывают свои собственные более высокие значения TTL.

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

При использовании multihoming вам необходимо получить как минимум сетевой блок / 24 "независимого от провайдера" IP-адресного пространства (он же "PI"), а затем сообщить об этом в глобальную таблицу маршрутизации только с резервного сайта, если основной сайт отключится.

Answer 2

Что касается DNS, я хотел бы сослаться на, "Почему глобальная балансировка нагрузки на сервер на основе DNS не работает".Для всего остального -- используйте BGP.

Проектирование сетей с целью балансировки нагрузки с использованием BGP по-прежнему остается непростой задачей, и я сам, конечно, не являюсь экспертом в этом.Это также сложнее, чем может рассказать Википедия, но в Интернете есть пара интересных статей, в которых подробно описывается, как это можно сделать:

• Балансировка нагрузки В сетях BGP
• Распределение нагрузки в средах с одним и несколькими домами

Всегда есть что-то еще, если вы ищете BGP и балансировку нагрузки.В сети также есть пара технических документов, в которых описывается, как Akamai выполняет глобальную балансировку нагрузки (я полагаю, что это тоже BGP.), которые всегда интересно читать и изучать.

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

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

Answer 3

Если вы можете, Многоадресная рассылка - http://en.wikipedia.org/wiki/Multicast или любая другая передача - http://en.wikipedia.org/wiki/Anycast