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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

Если можете, Multicast - http://en.wikipedia.org/wiki/Multicast или AnyCast - http://en.wikipedia.org/wiki/Anycast