Вопрос: Является ли Round-Robin DNS «достаточно хорошим» для загрузки статического контента?


У нас есть набор общего, статического контента, который мы обслуживаем между нашими веб-сайтами в http://sstatic.net, К сожалению, этот контент в настоящее время не сбалансирован для нагрузки - он обслуживается с одного сервера. Если у этого сервера есть проблемы, все сайты, которые полагаются на него, эффективно работают, потому что общие ресурсы - это важные общие библиотеки и изображения javascript.

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

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

Об этом говорится в [dns] [балансировка нагрузки] теги, и я прочитал несколько замечательных сообщений по этой теме.

Я знаю об общих недостатках балансировки нагрузки DNS через множественные записи с циклическим А:

  • в DNS-записях обычно нет сердечных сокращений или обнаружения сбоев, поэтому, если данный сервер при вращении падает, его запись A должна быть вручную удалена из записей DNS
  • время жизни (TTL) обязательно должно быть установлено достаточно низким, чтобы это вообще работало, поскольку записи DNS агрессивно кэшируются по всему Интернету
  • клиентские компьютеры несут ответственность за то, что есть несколько записей A и выбор правильного

Но, насколько это хорошо, как стартер, лучше, чем ничего, «пока мы изучаем и реализуем лучшие альтернативы» для балансировки нагрузки для нашего статического контента? Или DNS round robin в значительной степени бесполезен под Любые обстоятельства?


60
2018-01-09 03:01


Источник


HAProxy не вариант? - Howiecamp
как я сказал в сообщении, это конкретный вопрос о это решение - можем ли мы оставаться на тему? - Jeff Atwood
Балансировка нагрузки(en.wikipedia.org/wiki/Load_balancing_%28computing%29) очень отличается от избыточности (en.wikipedia.org/wiki/Redundancy_%28engineering%29). Как заявил Джефф в своем вступительном параграфе, он ищет средство для удаления единственной точки отказа (избыточности), а не фактической балансировки нагрузки. Может кто-то повторить? - antony.trupe
@jeff - абсолютно, тупой балансировщик нагрузки (который имеет простой циклический DNS-DNS) не делает избыточности. Это еще сложнее, если вы говорите о балансировке / избыточности на нескольких сайтах. - Alnitak
@symcbean Я знаком с терминологическими терминами, зарегистрированными в RFC 2119. Вы сказали, что DNS-сервер определяет список предпочтений. Если у вас нет особо странного определения «списков предпочтений», это просто неверно. - Alnitak


Ответы:


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

DNS roundrobin отлично подходит для увеличения емкости, распределяя нагрузку через несколько точек (потенциально географически распределенных). Но он не обеспечивает отказоустойчивость. Вы должны сначала описать, какой тип сбоя вы пытаетесь покрыть. Сбой сервера должен выполняться локально с использованием стандартного механизма захвата IP-адресов (VRRP, CARP, ...). Сбой коммутатора покрывается упругими ссылками на сервере с двумя коммутаторами. Сбой канала WAN может быть связан с установкой нескольких ссылок между вами и вашим провайдером с использованием протокола маршрутизации или решения layer2 (например, многоканального PPP). Ошибка сайта должна быть покрыта BGP: ваши IP-адреса реплицируются на нескольких сайтах, и вы объявляете их в сети только там, где они доступны.

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

Вы спросили: «Что делать, если машина haproxy терпит неудачу?». Это то же самое. Все, кого я знаю, которые используют haproxy для балансировки нагрузки и высокой доступности, имеют две машины и выполняют либо ucarp, keepalived, либо heartbeat на них, чтобы гарантировать, что один из них всегда доступен.

Надеюсь, это поможет!


56
2018-01-09 11:17



Кстати, вам может быть интересна статья, которую я написал около 4 лет назад по этим понятиям: 1wt.eu/articles/2006_lb (взять PDF, чтение HTML через страницы скучно). - Willy Tarreau
-1: «не обеспечивает отказоустойчивость» - да, да, и он реализует его на единственном месте, где неопределенность может быть надежно определена - у клиента. - symcbean
Не за что. Он будет работать, если DNS не будет использовать кеши, но это не так, и клиенты не могут заставить кэши обновляться. Поговорите с любым человеком, который регулярно переключает записи DNS, и они скажут вам, что, хотя они наблюдают 80% -ный переключатель за 5 минут, обычно требуется более одной недели, чтобы приблизиться к 100%. Поэтому DNS не обеспечивает отказоустойчивость. - Willy Tarreau
Простым примером «балансировки нагрузки без избыточности» является RAID0. - robbyt
Вилли, вы правы для записей DNS, требующих возраста для обновления. Но RR-DNS с браузерами обрабатывается на уровне браузера, проверяя каждый IP один за другим, если первый, отправленный DNS, кажется пустым. В этом случае вы никогда не меняете свои записи DNS, поэтому нет ожидающих обновлений. - Yvan


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

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

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

Если один из ваших двух серверов с круговым управлением снизится, то 50% ваших клиентов получат сбой. Это лучше, чем 100% -ный сбой только с одним сервером, но почти любое другое решение, которое действительно обеспечило бы переход на другой ресурс, было бы лучше, чем это.

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

Если вы планируете отключить мертвый сервер вручную, вы ограничены скоростью, с которой вы можете сделать это а также DNS TTL. Что делать, если сервер умирает в 4 часа ночи? Лучшая часть истинного отказоустойчивости - спать всю ночь.  Вы уже используете HAProxy, поэтому вы должны быть знакомы с ним. Я настоятельно рекомендую использовать его, поскольку HAProxy предназначен именно для этой ситуации.


19
2018-01-09 03:09



полностью вне темы, но у нас также возникла проблема с необходимостью перебора нескольких экземпляров HAProxy - что делать, если машина HAProxy терпит неудачу? Тема будущих вопросов, хотя, ДЕЙСТВИТЕЛЬНО не относится к этой теме. - Jeff Atwood
+1 - «С автоматическим способом ... это переключение на гетто. Вручную это даже не так». должны быть выделены жирным шрифтом. DNS round-robin становится ответственность если вы не контролируете машины и не удаляете их из DNS, если они терпят неудачу, и единственный разумный способ сделать это - это автоматическое решение. Есть гораздо лучшие решения, чем DNS round-robin. - Evan Anderson
полностью согласен, но 20% ваших клиентов звонят вам с жалобами является более 100% из них звонят с жалобами. - Jeff Atwood
Ключевым моментом (для меня), который Schof делает в ответе на вопрос Джеффа, является то, что без быстрого перехода на другой уровень Round Robin означает, что со временем у вас больше влияют клиенты, чем без него, но каждый (более частый) инцидент затрагивает только подмножество клиентов, а не всех. Является ли это «лучше» или нет, зависит от сценария, но в большинстве случаев я бы сказал, что это не так. - Helvick
The best part of true failover is getting to sleep through the night. Это одно четкое определение! - Basil Bourque


Круглый DNS-сервер не то, что люди считают. Как автор программного обеспечения DNS-сервера (а именно, BIND), мы получаем пользователей, которые задаются вопросом, почему их круглый робин перестает работать, как планировалось. Они не понимают, что даже при TTL 0 секунд там будет некоторое количество кеширования, так как некоторые кеши устанавливают минимальное время (часто 30-300 секунд) независимо от того, что.

Кроме того, в то время как ваши серверы AUTH могут совершать циклические действия, нет гарантии, что вам небезразлично - кэш, к которым ваши пользователи говорят - будет. Короче говоря, round robin не гарантирует никаких заказов с точки зрения клиента, только то, что ваши серверы auth предоставляют кешу.

Если вам нужен реальный переход на другой ресурс, DNS - это всего лишь один шаг. Неплохая идея перечислить несколько IP-адресов для двух разных кластеров, но я бы использовал другую технологию (например, простой anycast) для выполнения фактической балансировки нагрузки. Я лично презираю аппаратное оборудование для балансировки нагрузки, которое пытается подключиться к DNS, поскольку оно обычно ошибочно. И не забывайте, что DNSSEC подходит, поэтому, если вы выберете что-то в этой области, спросите своего поставщика, что произойдет, когда вы подпишете свою зону.


14
2018-01-09 10:51



и некоторые DNS-серверы (или панели управления) настроены так, чтобы дать вам TTL 7200, независимо от того, что вы его установили, - некоторые крупные хостинговые компании делают это IIRC. - gbjbaanb


Я уже говорил это несколько раз раньше, и я скажу это снова - если отказоустойчивость является проблемой, тогда трюки DNS не ответ,

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

Таким образом, основное правило заключается в том, что истинная устойчивость требует IP маршрутизация уровень обмана. Используйте устройство балансировки нагрузки или OSPF «равноценный многодорожечный путь» или даже VRRP.

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

Я бы также сказал, что нагрузка для вас не проблема, так что у вас может быть еще один сервер, готовый работать в режиме ожидания. Если вы используете немой круглый робот, вы должны активно изменять свои записи DNS, когда что-то ломается, поэтому вы можете так же активно перевернуть сервер горячего резерва в действие и не измените свой DNS.


14
2018-01-09 08:55





Я прочитал все ответы, и одна вещь, которую я не видел, - это то, что большинство современных веб-браузеров будут пытаться использовать один из альтернативных IP-адресов, если сервер не отвечает. Если я правильно помню, Chrome даже попробует несколько IP-адресов и продолжит работу с первым сервером. На мой взгляд, DNS Round Robin Load балансирует всегда лучше, чем ничего.

BTW: Я вижу, что DNS Round Robin более простое решение для распределения нагрузки.


7
2018-04-29 09:28



К сожалению, не видел вашего ответа, прежде чем публиковать мои, так что +1 на вашем, чтобы правда вышла! - Yvan


Windows Vista и Windows 7 осуществлять клиентскую поддержку для циклического разбора по-разному поскольку они передали адрес IPv6-адреса на IPv4. (RFC 3484)

Таким образом, если у вас есть значительное число пользователей Vista, Windows 7 и Windows 2008, вы, вероятно, найдете поведение, несовместимое с вашим планируемым мышлением, в вашем решении по балансировке нагрузки ersatz.


4
2018-01-09 13:55



ах, спасибо, отлично, я искал эту ссылку - я слышал об этом, но не смог найти ссылку! - Jeff Atwood


Я опаздываю на эту тему, поэтому мой ответ, вероятно, просто будет нависнуть один на дне, пренебречь, понюхать.

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

  1. «Вероятно, вы хотите Windows Балансировка сетевой нагрузки вместо." ИЛИ
  2. «Получайте время, поместите свой статический контент на что-то вроде Облачные файлы или S3, и иметь зеркало CDN во всем мире ».

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

Вопрос

является круглым DNS-сервером, достаточно хорошим, как стартер, лучше, чем ничего, «пока мы исследуем и внедряем лучшие альтернативы» - это форма балансировки нагрузки для нашего статического контента?

Между, скажем, 2 или 3 статическими веб-серверами? Да, это лучше, чем ничего, потому что есть Поставщики DNS, которые будут интегрировать DNS Round Robin с проверка работоспособности сервера, и временно удалит мертвые серверы из записей DNS. Таким образом, вы получаете порядочный распределение нагрузки и некоторые высокая доступность; и для настройки требуется всего 5 минут.

Но оговорки, изложенные другими в этой теме, применимы:

  • Текущие браузеры Microsoft кэшируют данные DNS для 30 минут, поэтому вы смотрите на время перехода на более чем 30 минут для подмножества ваших пользователей в зависимости от их первоначального состояния кэша DNS.
  • Что за пользователи видят во время сбоя может быть ... странно (вы не используете auth на статическом контенте и, конечно же, не формируете auth, но ссылка показывает, что нужно следить).

Другие решения

HAProxy - это фантастика, но поскольку Stack Overflow находится в стеке технологий Microsoft, возможно, использование средств балансировки нагрузки и высокой доступности Microsoft будет иметь меньшие накладные расходы администратора. Балансировка сетевой нагрузки заботится об одной части проблемы, и Microsoft фактически имеет L7 HTTP обратный прокси / балансировщик нагрузки Теперь.

Я никогда не использовал ARR самостоятельно, но, учитывая, что на своем втором крупном выпуске и в Microsoft, я полагаю, он был проверен достаточно хорошо. В нем есть легко понять документы, вот один из того, как они видят распространение статического и динамического контента на webnodes, и вот часть о том, как использовать ARR с NLB для достижения как распределения нагрузки, так и высокой доступности.


4
2018-02-03 02:56