У нас уже есть веб-серверы с балансировкой нагрузки. И хотя перебоев в работе не должно быть, они случаются по разным причинам. (сбой центрального коммутатора, неправильно настроенные маршрутизаторы ISP, сбои магистрали, DOS-атака на общую инфраструктуру) Я хочу разместить второй набор серверов в совершенно другом географическом месте с совершенно другими соединениями. Я могу синхронизировать SQL-серверы с помощью ряда различных методов, так что это не проблема. Но я не знаю, как сделать это прозрачно перенаправлять существующие пользовательские веб-сеансы на резервные серверы, когда основной выходит из строя или становится недоступным.
AFAIK, три наиболее распространенных способа справиться с этим:
Но в случае сбоя сайта, в первом случае пользователи не смогут связаться с сервером до тех пор, пока TTL не заставит клиентов запросить DNS и разрешить сайт DR или не вызовет чрезмерные дополнительные запросы DNS. Второй метод по-прежнему оставляет нас с потенциальной единственной точкой отказа (хотя я мог видеть, что несколько A-записей используются для дублирования главной роли «входа в систему» между средами), но по-прежнему не перенаправляет пользователей, когда сайт, на котором они Использую выходит из строя. А третий вообще не будет лишним, если облако выйдет из строя. (как и все они время от времени)
Из того, что я знаю о сети, разве я не могу предоставить двум разным серверам в двух географически разделенных средах один и тот же перекрывающийся IP-адрес и позволить маршрутизации IP-пакетов взять на себя и направить трафик на сервер, принимающий запросы? Возможно ли это только с IPv6? Как это называется и почему для отработки отказа сайтов аварийного восстановления в настоящее время не используется такая техника? Обновление: это называется Anycast. Как мне этого добиться? И стоит ли этого?
Чтобы уточнить: этот вопрос относится к трафику HTTP-сервера только с разрешенным прерыванием обслуживания на срок до 60 секунд. Пользователям не нужно закрывать браузер, возвращаться на страницу входа или обновлять что-либо. Мобильные пользователи не могут принимать дополнительный DNS-запрос для каждого запроса страницы.
Вот некоторые из моих прошлых вопросов.
Общий TL; DR заключается в том, что DNS не является решением по многим причинам, некоторые из которых вы определили. Некоторые из них находятся в ответах на связанные выше вопросы.
Единственный настоящий способ обеспечить географическую устойчивость - с помощью BGP и подразделить / 23 на 2/24, объявить те, что ваши восходящие потоки, а затем делать отдельные вещи DNS оттуда.
Тогда возникает раздражающая проблема синхронизации между ними, но это уже другая история.
Я могу синхронизировать SQL-серверы с помощью ряда различных методов, так что это не проблема.
Что ж, это еще не проблема.
Если вы использовали интеллектуальное перенаправление, либо изменив имя хоста, либо проксируя запрос, у вас возникнет еще одна проблема. "Куда поставить прокси, чтоб не SPOF"
В противном случае у вас будет N географически разделенных сайтов, но одна точка отказа (механизм прокси / перенаправления).
Я полагаю, что теоретически вы могли бы использовать MPLS вместо этого, чтобы ваши местоположения выглядели в той же сети L2, хотя я не уверен, как это на самом деле поможет повысить устойчивость к сбоям.
DNS сам по себе не обеспечивает возможности автоматического переключения при отказе. Но в сочетании с повторной попыткой клиента браузера он предлагает бесплатное (с точки зрения вложений в сеть) решение с низкой задержкой (~ 1 с). См. Ссылки ниже для получения более подробной информации.
http://blog.engelke.com/2011/06/07/web-resilience-with-round-robin-dns/
Несколько центров обработки данных и HTTP-трафик: DNS Round Robin - ЕДИНСТВЕННЫЙ способ обеспечить мгновенное переключение при отказе?