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

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

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

165 голосов | спросил Lin 30 PM00000090000000831 2009, 21:57:08

16 ответов


93

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

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

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

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

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

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

ответил Jesper Mortensen 30 PM000000100000002331 2009, 22:39:23
44

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

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

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

ответил Scott McDonald 20 +04002010-10-20T21:17:17+04:00312010bEurope/MoscowWed, 20 Oct 2010 21:17:17 +0400 2010, 21:17:17
31

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

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

ответил Cian 30 PM000000100000005931 2009, 22:27:59
19

Преобладающее мнение заключается в том, что с DNS RR, когда IP уходит, некоторые клиенты будут продолжать использовать сломанный IP в течение нескольких минут. Это было сказано в некоторых предыдущих ответах на вопрос, и оно также написано в Википедии.

В любом случае,

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

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

  

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

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

Спасибо,

Валентино

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

ответил Valentino Miazzo 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 29 Sep 2009 14:06:56 +0400 2009, 14:06:56
11

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

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

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

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

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

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

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

ответил GregW 12 AMpFri, 12 Apr 2013 05:21:27 +040021Friday 2013, 05:21:27
9

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

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

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

ответил Ryan 25 Maypm11 2011, 23:38:21
5

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

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

ответил Amal 7 AM00000090000003931 2011, 09:13:39
4

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

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

ответил Kyle Hodgson 31 AM00000010000003331 2009, 01:40:33
3

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

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

ответил thelsdj 12 +04002010-10-12T02:11:02+04:00312010bEurope/MoscowTue, 12 Oct 2010 02:11:02 +0400 2010, 02:11:02
2

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

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

ответил Greeblesnort 23 AM00000050000000231 2010, 05:50:02
2

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

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

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

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

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

ответил Eric - CloudfloorDNS 24 PMpFri, 24 Apr 2015 20:37:09 +030037Friday 2015, 20:37:09
1

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

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

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

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

ответил spenser 12 +04002010-10-12T01:52:44+04:00312010bEurope/MoscowTue, 12 Oct 2010 01:52:44 +0400 2010, 01:52:44
1

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

ответил Ricardo Polo 12 AMpTue, 12 Apr 2016 07:50:28 +030050Tuesday 2016, 07:50:28
0

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

http://edgedirector.com

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

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

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

ответил 6 +04002009-10-06T18:22:35+04:00312009bEurope/MoscowTue, 06 Oct 2009 18:22:35 +0400 2009, 18:22:35
0

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

ответил Seth 22 FebruaryEurope/MoscowbTue, 22 Feb 2011 03:19:55 +0300000000amTue, 22 Feb 2011 03:19:55 +030011 2011, 03:19:55
-1

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

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

ответил Matt Bram 15 Mayam12 2012, 06:04:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132