Почему отказоустойчивость DNS не рекомендуется?

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

Мне кажется, что DNS failover является единственным вариантом восстановления после сбоя здесь, но единодушное мнение, что это не очень хороший вариант. И все же такие сервисы, как DNSmadeeasy.com, предоставляют его, поэтому в этом должна быть заслуга. Любые комментарии?

Под «отказоустойчивостью DNS» я понимаю, что вы имеете в виду DNS Round Robin в сочетании с некоторым мониторингом, т.е. публикацией нескольких IP-адресов для имени хоста DNS и удалением мертвого адреса, когда мониторинг обнаруживает, что сервер не работает. Это может быть работоспособно для небольших, менее посещаемых сайтов.

Когда вы отвечаете на запрос DNS, вы также предоставляете время жизни (TTL) для ответа, который вы раздаете. Другими словами, вы говорите другим DNS-серверам и кешам: «Вы можете сохранить этот ответ и использовать его в течение x минут, прежде чем проверять со мной». Недостатки происходят от этого:

• При сбое DNS неизвестный процент ваших пользователей будет кэшировать ваши данные DNS с различным количеством оставшихся TTL. До истечения срока действия TTL они могут подключаться к мертвому серверу. Есть более быстрые способы завершения аварийного переключения, чем этот.
• Из-за вышеизложенного вы склонны устанавливать TTL достаточно низким, например, 5-10 минут. Но его установка дает (очень небольшое) выигрыш в производительности и может помочь вашему DNS-распространению работать надежно, даже если в сетевом трафике есть небольшая задержка. Таким образом, использование отработки отказа на основе DNS идет против высоких TTL, но высокие TTL являются частью DNS и могут быть полезны.

Более распространенные методы получения хорошего времени работы включают в себя:

• Размещение серверов в одной локальной сети.
• Поместите ЛВС в центр обработки данных с высокой доступностью питания и сетевых плоскостей.
• Используйте балансировщик нагрузки HTTP для распределения нагрузки и отработки отказа при сбоях отдельных серверов.
• Получите уровень резервирования / ожидаемое время безотказной работы, необходимое для брандмауэров, балансировщиков нагрузки и коммутаторов.
• Разработайте коммуникационную стратегию для сбоев в полном центре обработки данных и случайного сбоя коммутатора / сервера базы данных / другого ресурса, который нельзя легко отразить.

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

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

DNS не был разработан для аварийного переключения - но он был разработан с TTL, которые прекрасно работают для аварийного переключения в сочетании с надежной системой мониторинга. TTL могут быть очень короткими. Я эффективно использовал TTL продолжительностью 5 секунд в производстве для облегчения решений, основанных на быстром отказоустойчивости DNS. Вы должны иметь DNS-серверы, способные справиться с дополнительной нагрузкой - и named не будет сокращать ее. Тем не менее, PowerDNS отвечает всем требованиям, если он поддерживается реплицированными базами данных MySQL на избыточных серверах имен. Вам также нужна надежная распределенная система мониторинга, которой вы можете доверять для автоматической интеграции при сбое. Zabbix работает для меня - я могу почти мгновенно проверять сбои в нескольких распределенных системах Zabbix - обновлять записи mysql, используемые powerdns на лету - и обеспечивать почти мгновенное переключение при сбое во время отключений и скачков трафика.

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

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

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

Распространено мнение, что при DNS RR, когда IP-адрес падает, некоторые клиенты будут продолжать использовать сломанный IP-адрес в течение нескольких минут. Об этом было сказано в некоторых предыдущих ответах на вопрос, и это также написано в Википедии.

Так или иначе,

http://crypto.stanford.edu/dns/dns-rebinding.pdf объясняет, что это не так для большинства современных браузеров HTML. Они попробуют следующий IP через несколько секунд.

http://www.tenereillo.com/GSLBPageOfShame.htm кажется еще более сильным:

Использование нескольких записей A - это не хитрость или особенность, задуманная производителями оборудования для балансировки нагрузки. По этой причине протокол DNS был разработан с поддержкой нескольких записей А. Такие приложения, как браузеры, прокси и почтовые серверы, используют эту часть протокола DNS.

Может быть, какой-то эксперт может прокомментировать и дать более четкое объяснение того, почему DNS RR не подходит для высокой доступности.

Спасибо,

Валентино

PS: извините за неработающую ссылку, но, как новый пользователь, я не могу опубликовать более 1

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

Это отлично работает, но есть как минимум три тонкости, которые я усвоил на собственном опыте.

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

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

2) Если один из ваших серверов имен (или одна из ваших двух географических зон полностью) выходит из строя, который обслуживает ваш круговой домен, и если основной из них выходит из строя, я смутно напоминаю, что вы можете столкнуться с другими проблемами, пытаясь устранить сбитый сервер имен из DNS, если вы также не установили для своего сервера имен TTL / срок действия SOA достаточно низкое значение. Я мог бы ошибиться в технических деталях, но есть больше, чем одна настройка TTL, которую нужно получить, чтобы действительно защитить себя от единичных точек отказа.

3) Если вы публикуете веб-API, службы REST и т. Д., Они обычно не вызываются браузерами, и, таким образом, на мой взгляд, отработка отказа DNS начинает показывать реальные недостатки. Это может быть причиной того, что некоторые говорят, как вы говорите, «это не рекомендуется». Вот почему я так говорю. Во-первых, приложения, которые используют эти URL-адреса, обычно не являются браузерами, поэтому им не хватает 30-секундных свойств / логики отработки отказа в обычных браузерах. Во-вторых, то, вызывается или нет вторая запись DNS или даже DNS перезапрашивается, очень сильно зависит от низкоуровневых деталей программирования сетевых библиотек на языках программирования, используемых этими клиентами API / REST, а также от того, как они вызываются клиентское приложение API / REST. (Под ними рассматривается, вызывает ли библиотека get_addr и когда? Если сокеты зависают или закрываются, приложение повторно открывает новые сокеты? Есть ли какая-то логика тайм-аута? И т. Д. И т. Д.)

Это дешево, хорошо проверено и "в основном работает". Как и в большинстве случаев, ваш пробег может отличаться.

Есть группа людей, которые используют нас (Dyn) для восстановления после отказа. Это та же самая причина, по которой сайты могут либо создавать страницу состояния, когда у них есть время простоя (например, такие вещи, как Twitter Fail Whale) ... или просто перенаправлять трафик на основе TTL. Некоторые люди могут подумать, что DNS Failover - это гетто ... но мы серьезно спроектировали нашу сеть с отказоустойчивостью с самого начала ... чтобы она работала так же хорошо, как и оборудование. Я не уверен, как DME это делает, но у нас есть 3 из 17 наших ближайших любых точек зрения, которые отслеживают ваш сервер из ближайшего местоположения. Когда из двух из трех обнаруживается, что он не работает, мы просто перенаправляем трафик на другой IP-адрес. Единственное время простоя - это те, которые были запрошены на оставшуюся часть этого интервала TTL.

Некоторые люди любят использовать оба сервера одновременно ... и в этом случае могут делать что-то вроде циклического распределения нагрузки ... или распределения нагрузки на основе гео. Для тех, кто действительно заботится о производительности ... наш диспетчер трафика в режиме реального времени будет следить за каждым сервером ... и если он медленнее ... перенаправить трафик на самый быстрый, основываясь на том, какие IP-адреса вы указали в своих именах хостов. Опять же ... это работает на основе значений, которые вы указали в нашем UI / API / Portal.

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

Другой вариант - настроить сервер имен 1 в местоположении A и сервер имен 2 в местоположении B, но настроить каждый из них так, чтобы все записи A в NS1 указывали трафик на IP для местоположения A, а на NS2 все записи A указывали на IP для местоположение B. Затем установите свои TTL для очень малого числа и убедитесь, что ваша запись домена в регистраторе настроена для NS1 и NS2. Таким образом, он будет автоматически балансировать нагрузку, и при сбое одного сервера или одной ссылки на местоположение произойдет сбой.

Я использовал этот подход немного по-другому. У меня есть одно местоположение с двумя провайдерами, и я использую этот метод для направления трафика по каждой ссылке. Теперь, это может быть немного больше обслуживания, чем вы готовы сделать ... но я смог создать простое программное обеспечение, которое автоматически извлекает записи NS1, обновляет IP-адреса записей для выбранных зон и переводит эти зоны в NS2.

Альтернативой является отказоустойчивая система на основе BGP. Это не просто настроить, но это должно быть пуленепробиваемым. Настройте сайт A в одном месте, сайт B в секунду с локальными IP-адресами, затем получите переносимый IP-адрес класса C или другой блок и настройте перенаправление с переносных IP-адресов на локальные IP-адреса.

Есть подводные камни, но это лучше, чем решения на основе DNS, если вам нужен такой уровень контроля.

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

Это полностью обходит проблему аварийного переключения DNS, просто поддерживая несколько доменных имен. Пользователи, которые заходят на www.company.com или company.com и входят в систему, направляются на server1.company.com или server2.company.com и могут выбрать закладку для любого из них, если заметят, что с помощью одного или другого они получат более высокую производительность. , Если один выходит из строя, пользователи обучаются переходить на другой сервер.

Последние десять лет я использую балансировку сайтов на основе DNS и отработку отказа, и есть некоторые проблемы, но они могут быть смягчены. BGP, хотя и в некотором смысле лучше, не является 100% решением с повышенной сложностью, возможно, дополнительными затратами на оборудование, временем конвергенции и т. Д.

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

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

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

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

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

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

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

На самом деле, «лучше, чем ничего» лучше выражать как «единственный вариант», когда присутствия географически разнообразны. Аппаратные балансировщики нагрузки отлично подходят для одной точки присутствия, но единственная точка присутствия также является единственной точкой отказа.

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

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

Сегодня хорошие глобальные балансировщики нагрузки, которые работают с использованием этой техники и работают довольно хорошо. Проверьте, например, Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Если вы хотите узнать больше, прочитайте заметки по применению на

http://edgedirector.com

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

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

Короткий ответ: это работает, но вы должны понимать ограничения.

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

Я бы порекомендовал вам либо A, выбрать центр данных с многосетевым подключением в собственной AS, либо B, разместить свои серверы имен в общедоступном облаке. ДЕЙСТВИТЕЛЬНО маловероятно, что EC2, HP или IBM пойдут на спад. Просто мысль. Хотя DNS работает как исправление, в данном случае это просто исправление плохого дизайна в основе сети.

Другой вариант, в зависимости от вашей среды, заключается в использовании комбинации с IPSLA, PBR и FHRP для удовлетворения ваших потребностей в резервировании.