Несколько центров обработки данных и HTTP-трафик: DNS Round Robin - ЕДИНСТВЕННЫЙ способ обеспечить мгновенное переключение при сбое?

Несколько записей A, указывающих на один и тот же домен, похоже, используются почти исключительно для реализации DNS Round Robin в качестве дешевого метода балансировки нагрузки.

Обычное предупреждение против DNS RR состоит в том, что это не хорошо для высокой доступности. Когда 1 IP выходит из строя, клиенты будут продолжать использовать его в течение минут.

Балансировщик нагрузки часто предлагается как лучший выбор.

Оба утверждения не совсем верны:

1. Когда трафик HTTP, тогда большинство браузеров HTML могут автоматически пробовать следующую запись A, если предыдущая не работает, без нового поиска DNS. Прочитайте здесь главу 3.1 и здесь .

2. Когда задействованы несколько центров обработки данных, DNS RR является единственным вариантом для распределения трафика между ними.

Итак, правда ли, что при наличии нескольких центров обработки данных и HTTP-трафика использование DNS RR является ЕДИНСТВЕННЫМ способом обеспечить мгновенное переключение при сбое, когда один центр обработки данных выходит из строя?

Спасибо,

Валентино

Редактировать:

• Конечно, каждый центр обработки данных имеет локальный балансировщик нагрузки с горячим резервированием.
• Можно пожертвовать близостью сеанса для мгновенного переключения при сбое.
• AFAIK единственный способ для DNS предложить центр обработки данных вместо другого - ответить только IP (или IP), связанными с этим центром обработки данных. Если центр обработки данных становится недоступным, то все эти IP-адреса также недоступны. Это означает, что даже если умные HTML-браузеры смогут мгновенно попробовать другую запись A, все попытки завершатся неудачно, пока не истечет срок действия записи в локальном кэше и не будет выполнен новый поиск DNS, извлекая новые рабочие IP-адреса (я предполагаю, что DNS автоматически предлагает новый дата-центр при выходе из строя). Таким образом, «умный DNS» не может обеспечить мгновенное переключение при сбое.
• И наоборот, циклический перебор DNS разрешает это. Когда происходит сбой одного центра обработки данных, интеллектуальные HTML-браузеры (большинство из них) мгновенно пробуют другие кэшированные записи A, переходя в другой (работающий) центр обработки данных. Таким образом, циклическая перестановка DNS не гарантирует сессионную сессию или самый низкий RTT, но, кажется, является единственным способом обеспечить мгновенное переключение при сбое, когда клиенты являются «умными» браузерами HTML.

Изменить 2:

• Некоторые люди предлагают TCP Anycast в качестве окончательного решения. В этой статье (глава 6) объясняется, что отработка отказа Anycast связана с конвергенцией BGP. По этой причине Anycast может использовать от 15 минут до 20 секунд. 20 секунд возможны в сетях, где топология была оптимизирована для этого. Вероятно, только операторы CDN могут предоставить такие быстрые отработки отказа.

Редактировать 3: *

• Я сделал несколько проверок DNS и traceroutes (может быть, некоторые эксперты могут проверить дважды) и:
  • Похоже, что единственным CDN, использующим TCP Anycast, является CacheFly, другие операторы, такие как сети CDN и BitGravity, используют CacheFly. Кажется, что их края не могут быть использованы в качестве обратных прокси. Следовательно, они не могут быть использованы для мгновенного переключения при сбое.
  • Akamai и LimeLight, похоже, используют гео-ориентированный DNS. Но! Они возвращают несколько записей А. Из traceroutes кажется, что возвращенные IP-адреса находятся в одном центре обработки данных. Итак, я озадачен тем, как они могут предложить 100% SLA, когда один центр обработки данных выходит из строя.

Когда я использую термин «DNS Round Robin», я обычно имею в виду «дешевый метод балансировки нагрузки», как его описывает OP.

Но это не единственный способ использования DNS для глобальной высокой доступности. Большую часть времени людям с разным (технологическим) происхождением просто сложно хорошо общаться.

Лучшая техника балансировки нагрузки (если деньги не являются проблемой), как правило, считается:

1. Anycast - глобальная сеть «интеллектуальных» DNS-серверов,
2. и набор глобально распределенных центров обработки данных,
3. где каждый узел DNS реализует Split Horizon DNS,
4. и мониторинг доступности и потоков трафика некоторым образом доступен для «интеллектуальных» узлов DNS,
5. так что пользовательский DNS-запрос передается на ближайший DNS-сервер через IP Anycast ,
6. и этот DNS-сервер передает «запись / набор A» с низким TTL-рекордом для ближайшего / лучшего центра обработки данных для этого конечного пользователя через «интеллектуальный» DNS с разделенным горизонтом.

Использование anycast для DNS, как правило, хорошо, поскольку ответы DNS не сохраняют состояние и почти очень короткие. Поэтому, если маршруты BGP изменятся, маловероятно, что он прервет запрос DNS.

Anycast менее подходит для более длинных и динамичных HTTP-разговоров, поэтому эта система использует DNS с разделением горизонта. Сеанс HTTP между клиентом и сервером хранится в одном центре данных; как правило, он не может переключиться на другой центр обработки данных без прерывания сеанса.

Как я указал в «наборе записей A», то, что я бы назвал «DNS Round Robin», можно использовать вместе с настройкой выше. Обычно он используется для распределения нагрузки трафика по нескольким высокодоступным балансировщикам нагрузки в каждом центре обработки данных (так что вы можете добиться лучшей избыточности, использовать меньшие / более дешевые балансировщики нагрузки, не перегружать сетевые буферы Unix одного хост-сервера и т. Д.).

Итак, правда ли, что при наличии нескольких центров обработки данных и HTTP-трафика использование DNS RR является ЕДИНСТВЕННЫМ способом обеспечения высокой доступности?

Нет, это неправда, если под «DNS Round Robin» мы просто подразумеваем раздачу нескольких записей А для домена. Но это правда, что грамотное использование DNS является критически важным компонентом в любой глобальной системе высокой доступности. Выше показан один общий (часто лучший) способ.

Редактировать: Документ Google « Выход за пределы сквозной информации о пути для оптимизации производительности CDN» , по-моему, является современным в глобальном распределении нагрузки для лучшей производительности конечного пользователя.

Редактировать 2: Я прочитал статью «Почему на основе DNS .. GSLB .. не работает», на которую ссылается OP, и это хороший обзор - я рекомендую посмотреть на него. Прочитайте это сверху.

В разделе «Решение проблемы кэширования в браузере» он предлагает ответы DNS с несколькими записями A, указывающие на несколько центров обработки данных, как единственно возможное решение для мгновенного переключения при сбое.

В разделе «Полив» внизу, он раскрывает очевидное, что отправка нескольких записей A не является крутой, если они указывают на центры обработки данных на нескольких континентах, потому что клиент будет подключаться случайным образом и, таким образом, довольно часто получит «медленный» ДК на другом континенте. Таким образом, для того, чтобы это работало действительно хорошо, на каждом континенте требуется несколько центров обработки данных.

Это другое решение, чем мои шаги 1 - 6. Я не могу дать идеальный ответ на этот вопрос, я думаю, что нужен специалист по DNS из таких, как Akamai или Google, потому что большая часть этого сводится к практическим ноу-хау в ограничения развернутых кешей DNS и браузеров сегодня. AFAIK, мои шаги 1-6 - то, что Akamai делает со своим DNS (кто-нибудь может подтвердить это?).

Мне кажется, что я работал премьер-министром на мобильных браузерных порталах (сотовых телефонах), что разнообразие и уровень полной разбитости браузеров просто невероятны. Лично я бы не стал доверять решению HA, которое требует от терминала конечного пользователя «делать правильные вещи»; поэтому я считаю, что глобальное мгновенное переключение без прерывания сеанса сегодня неосуществимо.

Я думаю, что мои шаги 1-6 выше являются лучшими, которые доступны с товарной технологией. Это решение не имеет мгновенного переключения при сбое.

Я хотел бы, чтобы один из тех специалистов по DNS из Akamai, Google и т. Д. Пришел и доказал, что я не прав. :-)

Ваш вопрос: «Является ли DNS Round Robin ЕДИНСТВЕННЫМ способом обеспечить мгновенное переключение при сбое?»

Ответ таков: «DNS Round Robin НИКОГДА не является правильным способом обеспечения мгновенного переключения при сбое».

(по крайней мере, не самостоятельно)

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

В простейшей конфигурации это обеспечивает только аварийное переключение. Он также может быть использован для предоставления Anycast с предупреждением о том, что протоколы на основе TCP не будут работать в момент переключения, если в маршрутизации будет нестабильность.

Итак, правда ли, что при наличии нескольких центров обработки данных и HTTP-трафика использование DNS RR является ЕДИНСТВЕННЫМ способом обеспечения высокой доступности?

Очевидно, что это ложное утверждение - вам нужно только взглянуть на Google, Akamai, Yahoo, чтобы убедиться, что они не используют отклики [*] в качестве единственного решения (некоторые могут использовать его частично, наряду с другими подходами). .)

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

Можно использовать методику циклического перебора на простом подходе с совмещенным сервером, и вам не придется беспокоиться о сбое сервера, если вы также организуете «переключение» IP-адреса. (Но большинство выбирают методы балансировки нагрузки, один IP-адрес и аварийное переключение между балансировщиками нагрузки.)

Может быть, вам нужны все запросы для одного сеанса, чтобы перейти на одни и те же серверы, но вы хотите, чтобы запросы были распределены по разным, региональным кластерам серверов? Для этого не подходит циклический перебор: вам нужно что-то сделать, чтобы каждый клиент каждый раз обращался к одному и тому же физическому кластеру серверов (кроме случаев, когда возникают «исключения», такие как сбой сервера). Либо они получают согласованный IP-адрес из запроса DNS, либо перенаправляются на тот же кластер физического сервера. Решения для этого включают различные коммерческие и некоммерческие «балансировщики нагрузки» DNS или (если у вас больше контроля над сетью) рекламные объявления сети BGP. Вы можете просто сделать так, чтобы серверы имен вашего домена давали совершенно разные ответы (но, поскольку запросы DNS могут отправляться повсюду, вы выиграли »

[* Я собираюсь использовать «циклический перебор», потому что «RR» в терминологии DNS означает «запись ресурса».]

Очень приятное наблюдение vmiazzo +1 для вас! Я застрял именно там, где ты ... сбит с толку, как эти CDN делают свое волшебство.

Ниже приведены мои предположения о том, как CDN работает в своей сети:

• Используйте Anycast DNS (упомянутый Jesper Mortensen), чтобы получить ближайший дата-центр
• Они управляют локальной сетью, которая охватывает разные центры обработки данных, что позволяет им делать что-то вроде CARP на своих хостах в другом центре обработки данных

Или же

• Они используют протокол балансировки нагрузки шлюза на своих маршрутизаторах или протокол маршрутизатора с горячим резервированием (HSRP) . которые имеют дело с отключением центра обработки данных.
• Причина, по которой они включают несколько IP-адресов, заключается в том, что клиент будет повторять попытку, и к тому времени, когда клиент выполнит повтор, путь маршрутизации может измениться.

На данный момент у меня работает следующее решение: - DNS возвращает несколько IP, например:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Последняя точка входа в обратный прокси-сервер в облаке Amazon, который интеллектуально передает доступный сервер (или предоставляет на странице обслуживания)

Обратный прокси все еще получает удар, но бот такой же тяжелый, как и основной.

Почему RFC 2782 (применяется так же, как MX / priority для сервисов, таких как http, imap, ...), не реализовано ни в одном браузере? Все было бы проще ... Существует ошибка, открывшаяся в течение десяти лет в Mozilla !!! потому что это будет конец индустрии коммерческого балансировщика нагрузки ??? Я очень разочарован этим.

2 - Вы можете сделать это с Anycast, используя Quagga

(Даже если есть информация, что Anycast плох с TCP, есть несколько крупных компаний, использующих его, например CacheFly)

Интересно, сколько людей, отвечающих на эти вопросы, на самом деле используют большую всемирную сеть серверов? Google использует Round Robin, и моя компания использует его в течение многих лет. Это может работать довольно хорошо, с некоторыми ограничениями. Да, это должно быть дополнено другими мерами.

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

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

Отказоустойчивый отстой. Лучший HA использует все ресурсы все время.

Я работаю с HA с 1986 года. Я прошел обширное обучение по созданию систем отработки отказа, и я вовсе не фанат отработки отказа.

Кроме того, RR работает для распределения нагрузки, хотя и пассивно, а не активно. Журналы нашего сервера четко показывают соответствующий процент трафика на каждом сервере - в пределах разумного.

Другой очень простой выбор - использовать низкий (в зависимости от ваших потребностей) TTL в записи DNS A или CNAME и обновить эту запись, чтобы выбрать, какой IP будет использоваться.

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

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

TCP Anycast на самом деле очень стабильный и используется, по крайней мере, CacheFly (с 2002 года), Prolexic и BitGravity. Хорошая презентация по TCP Anycast была сделана на NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

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

Так что для абсолютной избыточности это необходимо. Вот почему это делает Google или любой другой, кто хочет быть уверенным в постоянной доступности сервиса.

Совершенно очевидно, почему это так ... множественные записи A являются единственным способом перемещения точки, в которой запросы направляются в клиентский браузер. Любой другой метод будет опираться на одну точку между клиентским браузером и сервером, на которой может произойти сбой, что приведет к отключению вашей службы. При использовании записей A единственной точкой отказа от клиента к серверу становится сам клиент.

Если у вас нет нескольких записей A, вы просите время простоя ...

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