Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

Спасибо,

Валентино

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

Изменить 2:

Изменить 3: *

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

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

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

  1. Глобальная сеть "интеллектуальных" DNS-серверов Anycast,
  2. и набор глобальных центров обработки данных,
  3. где каждый узел DNS реализует Split Horizon DNS,
  4. и мониторинг доступности и потоков трафика доступен «интеллектуальным» узлам DNS некоторым образом,
  5. таким образом Пользовательский DNS-запрос передается на ближайший DNS-сервер через IP Anycast,
  6. и это DNS-сервер выдает запись A с низким TTL / набор записей 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 на порталах мобильных браузеров (сотовые телефоны), - что разнообразие и уровень полная разбитость браузеров просто невероятно. Я лично не стал бы доверять решению высокой доступности, которое требует, чтобы терминал конечного пользователя «делал правильные вещи»; таким образом, я считаю, что глобальная мгновенная отработка отказа без прерывания сеанса сегодня невозможна.

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

Или

На данный момент для меня работает следующее решение: - 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 использует циклический перебор, и моя компания использует его уже много лет. Может работать неплохо, но с некоторыми ограничениями. Да, его нужно дополнить другими мерами.

Настоящий ключ - быть готовым принять пару сбоев, если сервер выйдет из строя. Когда я отключаю сервер, если браузер пытается получить доступ к этому серверу, будет задержка около минуты, пока браузер узнает, что 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, вы просите простоя ...

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