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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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