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

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

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

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

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

Мне известны общие недостатки балансировки нагрузки на DNS через несколько циклических записей A:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прежде всего, правильный ответ на вопрос - не ответить на вопрос, а сказать:

1. «Возможно, вместо этого вам нужна балансировка сетевой нагрузки Windows ». ИЛИ ЖЕ
2. «Идите в ногу со временем, разместите свой статический контент в чем-то вроде облачных файлов или S3 и сделайте так , чтобы CDN отражал его во всем мире».

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

Вопрос

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

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

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

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

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

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

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

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

1) TTL на записях DNS, используемых для циклического перебора, должен быть коротким, но НЕ НОЛЬ. Наличие нулевого TTL нарушает основной способ обеспечения устойчивости.

2) DNS RR распределяет, но не балансирует нагрузку, а распределяет ее, потому что на большой клиентской базе они, как правило, запрашивают DNS-сервер независимо и в результате получают разные записи DNS первого выбора. Эти разные варианты выбора означают, что клиенты обслуживаются разными серверами, а нагрузка распределяется. Но все зависит от того, какое устройство выполняет DNS-запрос и как долго он удерживает результат. Типичным примером является то, что все клиенты за корпоративным прокси-сервером (который выполняет DNS-запрос для них) все будут в конечном итоге нацелены на один сервер. Нагрузка распределена - но она не сбалансирована равномерно.

3) DNS RR обеспечивает устойчивость до тех пор, пока клиентское программное обеспечение правильно ее реализует (и TTL, и диапазон внимания пользователей не слишком малы). Это связано с тем, что циклический перебор DNS предоставляет упорядоченный список IP-адресов сервера, и клиентское программное обеспечение должно пытаться связаться с каждым из них по очереди, пока не найдет сервер, который принимает соединение.

Таким образом, если сервер первого выбора не работает, время ожидания клиентского TCP / IP-соединения истекает, и при условии, что ни TTL, ни интервал внимания не истекли, тогда клиентское программное обеспечение делает еще одну попытку подключения ко второй записи в списке - и так до тех пор, пока Срок действия TTL истекает, или он попадает в конец списка (или пользователь с отвращением сдается).

Длинный список сломанных серверов (ваша ошибка) и большие пределы попыток соединения TCP / IP (ошибочная конфигурация клиента) могут составлять в течение длительного периода, прежде чем клиент действительно найдет работающий сервер. Слишком короткий TTL означает, что он никогда не добирается до конца списка, а вместо этого выдает новый DNS-запрос и получает новый список (надеюсь, в другом порядке).

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

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

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

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

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

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

Так что ДА, DNS round robin определенно "достаточно хорош" для вашего первого шага за один сервер, на котором размещен весь ваш статический контент в одном месте.

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

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

Я всегда использовал Round-Robin DNS с длинными TTL в качестве балансировщика нагрузки. Он действительно отлично работает для сервисов HTTP / HTTPS с браузерами .

Я действительно обращаю внимание на браузеры, так как большинство браузеров реализуют своего рода «повторную попытку на другом IP», но я не знаю, как другие библиотеки или программы будут обрабатывать решение с несколькими IP.

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

Еще в 2007 году я сделал следующий тест:

• добавить iframe на мой сайт, указывая на одну запись Round-Robin, например http://roundrobin.test:10080/ping.php
• страница обслуживалась 3-мя PHP-сокетами, прослушивающими 3 разных IP-адреса, все по порту 10080 (я не мог позволить себе тестировать по порту 80, так как мой сайт работал на нем)
• один сокет (скажем, A ) был там, чтобы проверить, что браузер может подключиться к порту 10080 (так как многие компании допускают только стандартные порты)
• другие два сокета (скажем, B и C ) могут быть включены или отключены на лету.

Я позволил этому бежать один час, имел много данных. В результате было получено, что для 99,5% попаданий в сокет A было попадание в сокет B или C (разумеется, я не отключал оба из них одновременно). Браузерами были: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Так что даже не очень совместимые браузеры справились с этим правильно!

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

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

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

Дополнительное примечание: вы можете проверить поведение на своем IP, используя iptables. Например, перед правилом брандмауэра для трафика HTTP добавьте:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(где 12.34.56.78, очевидно, ваш IP)

Не используйте DROP, так как порт остается отфильтрованным , и ваш браузер будет ждать до истечения времени ожидания. Так что теперь вы можете включить или отключить один сервер или другой. Самый очевидный тест - отключить сервер A, загрузить страницу, затем включить сервер A и отключить сервер B. Когда вы снова загрузите страницу, вы увидите небольшое ожидание из браузера, затем она загрузится с сервера Еще раз. В Chrome вы можете подтвердить IP-адрес сервера, посмотрев запрос на панели сети. На Generalвкладке Headersвы увидите поддельный заголовок с именем Remote Address:. Это IP, откуда вы получили ответ.

Итак, если вам нужно перейти в режим обслуживания на одном сервере, просто отключите трафик HTTP / HTTPS с одним iptables REJECTправилом, все запросы будут отправляться на другие серверы (с небольшим ожиданием, почти незаметным для пользователей).

Я не думаю, что это достаточно хорошее решение, потому что, скажем, у вас сейчас два сервера, и вы выполняете циклический перебор, используя DNS для IP-адреса каждого сервера. Когда один сервер выходит из строя, DNS-серверы не знают, что он вышел из строя, и будут продолжать обслуживать этот IP-адрес как часть процесса RR. Тогда 50% вашей аудитории получат испорченный сайт без javascript или изображений.

Возможно, проще указать на общий IP-адрес, который обрабатывается NLB Windows, представляющим два сервера позади. Если вы не используете сервер Linux для статического контента, если я помню, что где-то читал?

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

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

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

Вы также можете иметь один сервер со статическим контентом, дублированным на S3, и переключиться на SAME CNAME, когда ваш основной сервер выйдет из строя. Вы получите такую ​​же задержку, но без стоимости нескольких серверов.

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

Насколько стабильным был ваш сервер вне аппаратного сбоя и т. Д.? Как «spikey» ваш трафик на этот контент? Если предположить, что прямо Apache или что-то в этом роде и относительно ровный трафик, он не будет сильно падать, и я бы сказал, что циклический перебор достаточно хорош.

Я уверен, что откажусь от голосования, потому что я не проповедую 100% -ное решение HA, но это не то, что вы просили. Все сводится к тому, что вы готовы принять как решение в сравнении с затраченными усилиями.

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

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

Хорошей новостью является то, что сердцебиение доступно очень дешево, либо в коммутаторах, либо в Windows.

Не знаю о других ОС, но я полагаю, что это также там.

Я предлагаю вам назначить дополнительный IP-адрес каждому из ваших серверов (в дополнение к статическому IP-адресу, который вы используете, скажем, для ssh), и перенести его в пул DNS. А затем вы используете некоторое программное обеспечение для переключения этих IP-адресов в случае сбоя сервера. Например, Heartbeat или CARP могут сделать это, но есть и другие решения.

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

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

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

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

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

Исследуя балансировку нагрузки Windows несколько лет назад, я увидел документ, в котором говорилось, что веб-ферма Microsoft была настроена как несколько групп балансировки нагрузки с циклическим перебором DNS между ними. Поскольку в каждом пространстве имен может работать несколько DNS-серверов, а балансировка нагрузки Microsoft является самовосстанавливающейся, это обеспечивает как избыточность, так и балансировку нагрузки.

Недостаток: вам нужно как минимум 4 сервера (2 сервера по 2 группы).

Отвечая на комментарий Джеффа относительно ответа Шофа, существует ли способ DNS-циклического перебора между серверами HAProxy?

Он имеет очень незначительное использование, достаточное, чтобы помочь вам, пока вы предлагаете реальное решение. Как вы говорите, TTL должны быть установлены достаточно низкими. Это имеет побочную выгоду, тем не менее, вытаскивая проблемный компьютер из DNS, в то время как у него есть проблемы. Скажем, у вас есть SvrA, SvrB и SvrC, раздающие ваш контент, а SvrA отключается. Вы вытаскиваете его из DNS, и после короткого периода времени, определенного вашим низким TTL, распознаватели определят другой работающий сервер (SvrB или SvrC). Вы снова подключаете SvrA и помещаете его обратно в DNS. Короткое время простоя для некоторых людей, нет для других. Не отлично, но выполнимо. Чем больше статических серверов вы используете, тем меньше вероятность того, что большинство пользователей отключатся.

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