Почему обработка отказа DNS не рекомендуется?

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

Существуют ловушки, но лучше, чем основанные на DNS решения при необходимости в том уровне управления.

'Обработкой отказа DNS' я беру его, Вы имеете в виду Циклический алгоритм DNS, объединенный с некоторым контролем, т.е. публикацией нескольких IP-адресов для имени хоста DNS и удаления мертвого адреса, когда контроль обнаруживает, что сервер снижается. Это может быть осуществимо для маленьких, менее переданных веб-сайтов.

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

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

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

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

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

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

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

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

http://edgedirector.com

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

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

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

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

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

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

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

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

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

Спасибо,

Valentino

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

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

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

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

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

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

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

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

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

Обработка отказа DNS определенно работает отлично. Я использовал его много лет для ручного смещения трафика между центрами обработки данных, или автоматически когда системы контроля обнаружили отключения электричества, проблемы возможности соединения или перегруженные серверы. Когда Вы видите скорость, на которой это работает, и объемы трафика реального мира, который может быть смещен легко - Вы никогда не будете оглядываться назад. Я использую Zabbix для контроля всех моих систем и визуальных графиков, которые показывают то, что происходит во время ситуации с обработкой отказа DNS, помещает все мои сомнения в и конец. Может быть несколько ISPs там, которые игнорируют TTLs, и существуют некоторые пользователи все еще там со старыми браузерами - но когда Вы смотрите на трафик от миллионов просмотров страницы дни через 2 местоположения ЦОД, и Вы делаете транспортный сдвиг DNS - остаточный трафик, происходящий в это, игнорирует TTLs, смехотворно. Обработка отказа DNS является твердой техникой.

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

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

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

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

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

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

Другая опция состояла бы в том, чтобы настроить сервер имен 1 в месте A и сервер имен 2 в месте B, но настроить каждого так все записи на трафике точки NS1 к дюйм/с для местоположения A, и на NS2 весь, записи указывают на дюйм/с для местоположения B. Затем установите свой TTLs для очень небольшого числа и удостоверьтесь, что Ваша доменная запись в регистраторе была установкой для NS1 и NS2. Тем путем это автоматически загрузит баланс и заменит, должен, один сервер или одна ссылка на местоположение понижаются.

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

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

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

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

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

I ran DNS RR failover on a production moderate-trafficked but business-critical website (across two geographies) for many years.

It works fine, but there are at least three subtleties I learned the hard way.

1) Browsers will failover from a non-working IP to a working IP after 30 seconds (last time I checked) if both are considered active in whatever cached DNS is available to your clients. This is basically a good thing.

But having "half" your users wait 30 seconds is unacceptable, so you will probably want to update your TTL records to be a few minutes, not a few days or weeks so that in case of an outage, you can rapidly remove the down server from your DNS. Others have alluded to this in their responses.

2) If one of your nameservers (or one of your two geographies entirely) goes down which is serving your round-robin domain, and if the primary one of them goes down, I vaguely recall you can run into other issues trying to remove that downed nameserver from DNS if you have not set your SOA TTL/expiration for the nameserver to a sufficiently low value also. I could have the technical details wrong here, but there is more than just one TTL setting that you need to get right to really defend against single points of failure.

3) If you publish web APIs, REST services, etc, those are typically not called by browsers, and thus in my opinion DNS failover starts to show real flaws. This may be why some say, as you put it "it is not recommended". Here's why I say that. First, the apps that consume those URLs typically are not browsers, so they lack the 30-second failover properties/logic of common browsers. Second, whether or not the second DNS entry is called or even DNS is re-polled depends very much on the low-level programming details of networking libraries in the programming languages used by these API/REST clients, plus exactly how they are called by the API/REST client app. (Under they covers, does the library call get_addr, and when? If sockets hang or close, does the app re-open new sockets? Is there some sort of timeout logic? etc etc)

It's cheap, well-tested, and "mostly works". So as with most things, your mileage may vary.

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

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

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

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

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

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