Вопрос: Несколько центров обработки данных и 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 round-robin не гарантирует сближение сеанса или самый низкий 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. Но! Они возвращают несколько записей A. Из traceroutes кажется, что возвращенные IP-адреса находятся в одном центре данных. Итак, я озадачен тем, как они могут предложить 100% SLA, когда падает один центр обработки данных.

76
2017-09-30 08:44


Источник


При высокой доступности я подразумевал почти мгновенный отказ. Клиент не должен замечать никаких проблем, даже если один центр обработки данных опускается. Я уточнил вопрос. - Valentino Miazzo
MaxCDN использует anycast TCP, и его ребра могут использоваться в режиме кэширования прокси («изначальная выборка» в отраслевой терминологии CDN). - rmalayter
@vmiazzo, ваша ссылка в формате pdf не работает ... Вы имеете в виду 15 минут или 20 секунд до 15 минут? - Pacerier


Ответы:


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

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

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

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

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

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

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

Итак, правда, что с несколькими центрами обработки данных   и HTTP-трафик, использование DNS RR является ТОЛЬКО   способ обеспечить высокую доступность?

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

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

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

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

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

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

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

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

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


34
2017-09-30 10:56



Я добавил больше объяснений в вопросе. Если я понимаю ваш «лучший метод балансировки нагрузки» (пункт 6), он рекламирует только записи A «лучшего» центра обработки данных. Как я пытался объяснить в вопросе, это не позволяет мгновенно отказываться от клиента. - Valentino Miazzo
@vmiazzo: Да, вы поняли меня правильно. Я добавляю второе редактирование на свой пост, чтобы уточнить, но в основном я думаю, что мгновенная неудача, которую вы ищете, непрактична / невозможна. - Jesper Mortensen
Интересно то, что никто не предложил объединить два подхода. Хотя это и не идеально, это обеспечит разумную скорость, когда все будет работать правильно, и дополнительную отказоустойчивость, когда они этого не сделают. Штраф будет большой задержкой, так как клиенты переключаются с одного DNS-адреса на основе anycast на другой. - Avery Payne
@JesperMortensen. Когда вы говорите «интеллектуальный» DNS, вы имеете в виду DNS с разнесенным горизонтом? Или вы имеете в виду что-то еще (решаете на основе факторов за источник IP)? - Pacerier


Ваш вопрос: «Является ли DNS Round Robin единственным способом обеспечить мгновенный сбой?»

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

(по крайней мере, не сам по себе)

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

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


18
2017-09-30 16:04



Добавлена ​​информация об аварийном восстановлении Anycast по этому вопросу. В принципе, TCP Anycast не является идеальным решением. - Valentino Miazzo
@vmiazzo re TCP Anycast - действительно, следовательно, заметка в моем ответе о нестабильности маршрутизации и о том, как она влияет на TCP. - Alnitak


Итак, верно ли, что с несколькими центрами обработки данных и HTTP-трафиком использование DNS RR является ТОЛЬКО способом обеспечения высокой доступности?

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

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

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

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

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


6
2017-09-30 09:47



Я добавил больше объяснений в ответ. Ваше предложение использовать «балансировщики нагрузки» DNS «IMHO» не позволяет мгновенно отказываться. Что касается BGP, вы ссылаетесь на решение Anycast TCP? - Valentino Miazzo
Я не предлагаю какое-либо конкретное решение по сравнению с другим - я говорю, что вам нужно выбрать правильное решение для вашей проблемы (которое вы на самом деле не указали в своем вопросе) и ваши ограничения (так же). DNS round-robin делает не обеспечивают мгновенный сбой больше, чем DNS LB, потому что браузеру не гарантировано делать «правильную вещь» (в основном потому, что «правильная вещь» строго не определена или не предписана. Я не верю, что достаточно «умных» HTML-браузеров ", даже сейчас - я согласен с Jesper, что они слишком разнообразны в своем поведении, чтобы полагаться на них вообще.) - jrg
Я понимаю ваш скептицизм. В любом случае, как вы можете прочитать здесь crypto.stanford.edu/dns/dns-rebinding.pdf большинство современных браузеров HTML уже «умны». - Valentino Miazzo


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

Ниже я догадываюсь о том, как CDN запускает свою сеть:

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

Или

  • Они используют Протокол балансировки нагрузки шлюза на их маршрутизаторах или Протокол Hot Standby Router Protocol (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, который интеллектуально переходит к доступному серверу (или предоставляется на странице обслуживания)

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


5
2017-12-14 08:15



Порядок нескольких записей DNS, которые будут получать клиенты, будет преднамеренно рандомизирован, поэтому ваш обратный прокси-сервер, вероятно, попадет примерно в 1/6 раза (1/2 из 1/3). Как это лучше или отличается от наличия записей за 6 А? - ColinM


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


3
2018-04-16 15:05





2 - Вы можете сделать это с помощью Anycast с помощью Quagga

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


2
2017-09-30 09:08



Абсолютно, но вы не можете сделать это с арендованными серверами, вам нужна ваша собственная сеть. - Julien Tartarin
Добавлена ​​информация об аварийном восстановлении Anycast по этому вопросу. В принципе, TCP Anycast не является идеальным решением. - Valentino Miazzo


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

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

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

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

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

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


2
2017-07-19 14:34





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

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


1
2017-09-30 09:19



Я добавил больше объяснений в вопросе. Многие браузер HTML игнорируют DNS TTL (привязка DNS), см. Бумагу, связанную с вопросом. Измените конфигурацию DNS, когда дата-центр опускается, не разрешает мгновенный сбой на клиенте. - Valentino Miazzo


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


1
2017-09-30 14:44



Есть повод для этого. Низкие TTL оказывают большое влияние на занятые серверы DNS и используют их на постоянной основе, а не просто временно, когда требуется изменение, это злоупотребление системой и их ресурсами. Большинство интернет-провайдеров будут применять минимальный TTL только после того, как он будет установлен на низком уровне дольше, чем разумный период времени. - JamesRyan