Как лучше настроить Failover доступности сайта при падении связи в ДЦ?

Question

[igormukhin]

Здравствуйте!

Ситуация: у ДЦ пропадает связь.
Задача: сделать failover, чтобы сайт работал даже если в ДЦ пропадает связь со всем миром.

Как сделать failover на первый взгляд понятно - ставятся дублирующие сервера (для backend, db) и балансировщик проксирует запросы на разные backends. При падении одного из backend - он перестает обрабатывать запросы, нагрузка распределяется на оставшихся.

Интересно вот что:
1. Как организовать систему так, чтобы балансировщик/frontend был не один, а несколько и в разных ДЦ? Чтобы не иметь единой точки входа/отказа?
2. Если это невозможно, насколько идеологически правильно использовать какой-нибудь DynamicDNS для переключения домена на другой IP (с зеркалом в другом ДЦ) при возникновении проблем? (Downtime около 1 минуты - допустим).

Спасибо.

Answer 1

[Игорь]

В простейшем случае вам поможет round-robin dns. Несколько записей, каждая из которых ведет на балансировщик в отдельнмо дц. При падении ДЦ потеряете только часть трафика. В большинстве своем браузеры сейчас умные и умеют перебирать адреса при недоступности первого.
В более сложном варианте поднимать динамическую маршрутизацию и весами балансировать маршруты до одного и того же адерса балансера в разных дц. При падении основного ДЦ трафик переключится на маршрут с меньшей метрикой и пойдет на резервный балансер.

Comments

[igormukhin]

Спасибо за ответ. При round robin возникает проблема с сессиями, судя по всему. Второй вариант интереснее - не могли бы Вы в двух словах рассказать об инструментах?

Я немного покопался в теме, предварительно вижу такое теоритическое решение:
1. DNS-зона настраивается с TTL 60 секунд
2. В случае проблем на одном из серверов - DNS-зона обновляется т.о., чтобы IP "поломанного" сервера не фигурировал в ней.

Но есть непонятки.

По первому пункту - действительно ли все DNS-сервера провайдеров(?) будут кешировать IP лишь на 60 сек, а не так, как им вздумается? То же касается клиентов (браузеры/роутеры) - не могут ли они закешировать IP на большее время, нежели указано в TTL?

По второму - придется делать свой велосипед (который к тому же в идеале должен быть в 3-м ДЦ), который будет проверять доступность и редактировать зоны. Интересно есть ли что-то готовое?

[Игорь]

По поводу DNS и кеширования на стороне клиента никакой гарантии нет, и можно утверждать с вероятностью близкой к 100%, что обязательно найдутся те, у кого в сетях стоят кеширующие DNS со своими политиками, игнорирующие Ваши.

По поводу динамической маршрутизации могу посоветовать почитать про ospf например.

Answer 2

[Дэн Иванов]

Если вы сами себя анонсируете в мир, и полностью контролируете сеть то стоит смотреть на anycast dns.
Это позволит вам в случае отказа/деградации производительности сервисов одного из кластеров, переставать его анонсить, и убирать нагрузку.

Если нет, то тот вариант который вы описали вполне себе работоспосбный. Тот же амазоновский route53 умеет на основании хелсчеков менять DNS запись. Возьмите, потестируйте, если скорость "смены" Вас устроит, и вы знаете примерное кол-во посетителей в месяц, сможете прикинуть во сколько обойдется данное решение.