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


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

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


165
2017-08-30 17:57


Источник


Посмотрите Вот для обсуждения по этому вопросу. Теперь переключение выполняется автоматически с помощью современных браузеров. - GetFree


Ответы:


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

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


93
2017-08-30 18:39



Я думаю, что он специально пытается управлять откатом между двумя разными центрами обработки данных (обратите внимание на комментарии по различным подсетям), поэтому размещение серверов вместе / с использованием балансировщика нагрузки / дополнительного избыточности не поможет ему (кроме избыточных центров обработки данных. все равно нужно сказать интернету, чтобы перейти к тому, что все еще есть). - Cian
Добавьте anycast в настройку мультидатчика, и он станет доказательством отказа от центра обработки данных. - petrus
запись в wikipedia на anycast (en.wikipedia.org/wiki/Anycast) обсуждает это в связи с устойчивостью сервера DNS-сервера. - dunxd
Атаки DDoS настолько распространены, что целые центры обработки данных могут быть отправлены в автономном режиме (это случилось с Linode London и другими центрами обработки данных в декабре 2015 года). Поэтому использование одного и того же провайдера в том же центре обработки данных не рекомендуется. Поэтому несколько центров обработки данных с разными поставщиками были бы хорошей стратегией, которая возвращает нас к отказоустойчивости DNS, если не существует лучшей альтернативы. - Laurence Cope
Разве это не значит, что существует переход на другой ресурс, потому что вам нужно поддерживать свой сайт в режиме реального времени, когда устройство не работает / не работает? Какой будет хороший переход на другой ресурс, когда он находится в одной сети, использующей одни и те же устройства, например. маршрутизаторы? - user2128576


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-переключение - напишите мне, что я более чем рад поделиться.


44
2017-10-20 17:17



Ответ Сиана serverfault.com/a/60562/87017 прямо противоречит вашему ..... поэтому кто прав? - Pacerier
Это мой опыт в том, что короткие TTL не работают через Интернет. Возможно, вы используете DNS-серверы, которые уважают RFC, но есть много серверов, которые этого не делают. Пожалуйста, не думайте, что это аргумент против Round Robin DNS - см. Также ответ vmiazzo ниже. Я запустил загруженные сайты с использованием RR DNS и протестировал его - он работает. Единственные проблемы, с которыми я столкнулся, были с некоторыми Java-клиентами (а не с браузерами), которые даже не пытались повторно подключиться к сбою, не говоря уже о том, чтобы цикл списка хостов на RST - symcbean
Бьюсь об заклад, люди, которые говорят, что отслеживают переключение DNS, являются отличными, и люди, которые говорят, что это отстой, имеют схожие впечатления, но с разными ожиданиями. DNS failover НЕ является бесшовным, но он предотвращает значительный простои. Если вам нужен полностью бесшовный доступ (никогда не теряйте ни одного запроса, даже во время сбоя сервера), вам, вероятно, потребуется гораздо более сложная и дорогая архитектура. Это не требование для многих приложений. - Tom Wilson


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

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


31
2017-08-30 18:27



+1 Медленный и ненадежный - Chris S
Также см serverfault.com/q/315199/87017 - Pacerier


Преобладающее мнение заключается в том, что при 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


19
2017-09-29 10:06



Несколько записей A разработаны, но для балансировки нагрузки, а не для отказа. Клиенты будут кэшировать результаты и продолжать использовать полный пул (включая сломанный IP) в течение нескольких минут после изменения записи. - Cian
Итак, что написано в crypto.stanford.edu/dns/dns-rebinding.pdf глава 3.1 ложь? << Internet Explorer 7 связывает DNS-привязки в течение 30 минут.1 К сожалению, если домен злоумышленника имеет несколько записей A и текущий сервер становится недоступным, браузер будет пытаться использовать другой IP-адрес в течение одной секунды. >> - Valentino Miazzo
Перемещено мое подзапрос здесь serverfault.com/questions/69870/... - Valentino Miazzo


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

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

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

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

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

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

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


11
2018-04-12 01:21



библиотека, которая не повторяет попытку на других RR для адреса, нарушена. укажите разработчиков на страницах руководства для getaddrinfo () и т. д. - Jasen


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

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

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


9
2018-05-25 19:38



Что вы подразумеваете под «может быть столь же эффективным, как и аппаратное обеспечение»? Какое оборудование выполняет маршрутизацию DNS? - mpen
@Ryan: Что вы имеете в виду, когда говорите «гетто»? - Pacerier
Для этого слова городской словарь не дает никаких определений с положительным коннотацией, я полагаю, что «решение нищего» может быть подходящим переводом. - Jasen


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

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


5
2017-08-07 05:13



Разве серверы имен слишком много не распространяются? Если вы измените запись DNS с низким TTL, она будет работать мгновенно, но при изменении сервера имен потребуется 24 часа или больше для распространения, поэтому я не вижу, как это может быть решение для переключения на отказ. - Marco Demaio


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

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


4
2017-08-30 21:40



Однако решения на базе BGP доступны не всем. И гораздо проще нарушать особенно ужасные пути, чем DNS. Качели и карусели, я полагаю. - Cian


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

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


3
2017-10-11 22:11



Обучение ваших пользователей таким образом ... Разве это не делает их более склонными к фишингу? - Pacerier


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

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


2
2017-08-23 01:50