При чтении кажется, что отказоустойчивость DNS не рекомендуется только потому, что DNS не предназначен для этого. Но если у вас есть два веб-сервера в разных подсетях, на которых размещается избыточный контент, какие еще методы существуют, чтобы гарантировать, что весь трафик будет перенаправлен на рабочий сервер, если один из серверов выйдет из строя?
Мне кажется, что отказоустойчивость DNS - единственный вариант отказа здесь, но все согласны с тем, что это не лучший вариант. Тем не менее, такие службы, как DNSmadeeasy.com, предоставляют его, так что в этом есть свои достоинства. Любые комментарии?
Я понимаю, что под «переключением DNS» вы подразумеваете циклический перебор DNS в сочетании с некоторым мониторингом, то есть публикацией нескольких IP-адресов для имени хоста DNS и удалением мертвого адреса, когда мониторинг обнаруживает, что сервер не работает. Это может работать для небольших веб-сайтов с меньшей посещаемостью.
По задумке, когда вы отвечаете на запрос DNS, вы также предоставляете время жизни (TTL) для ответа, который вы раздаете. Другими словами, вы говорите другим DNS-серверам и кешам: «Вы можете сохранить этот ответ и использовать его в течение x минут, прежде чем обратиться ко мне». Отсюда и недостатки:
Наиболее распространенные методы увеличения времени безотказной работы включают:
Очень незначительное меньшинство веб-сайтов использует настройки с несколькими центрами обработки данных с «географической балансировкой» между центрами обработки данных.
Отказоустойчивость DNS определенно работает отлично. Я использую его в течение многих лет для ручного переключения трафика между центрами обработки данных или автоматически, когда системы мониторинга обнаруживают сбои, проблемы с подключением или перегруженные серверы. Когда вы увидите скорость, с которой он работает, и объемы реального мирового трафика, которые можно легко изменить, вы никогда не оглянетесь назад. Я использую Zabbix для мониторинга всех своих систем, и визуальные графики, показывающие, что происходит во время аварийного переключения DNS, положили конец всем моим сомнениям. Может быть несколько интернет-провайдеров, которые игнорируют TTL, и некоторые пользователи все еще работают со старыми браузерами, но когда вы смотрите на трафик из миллионов просмотров страниц в день в 2 местах центров обработки данных, и вы выполняете сдвиг трафика DNS - остаточный трафик, который игнорирует TTL, просто смехотворен. Отработка отказа DNS - надежный метод.
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 был разработан с поддержкой нескольких A-записей. Такие приложения, как браузеры, прокси и почтовые серверы, используют эту часть протокола DNS.
Может быть, какой-нибудь эксперт прокомментирует и даст более четкое объяснение, почему DNS RR не подходит для высокой доступности.
Спасибо,
Валентино
PS: извините за неработающую ссылку, но, как новый пользователь, я не могу опубликовать более 1
Я выполнял аварийное переключение DNS RR на производственном веб-сайте с умеренным трафиком, но критически важном для бизнеса (в двух регионах) в течение многих лет.
Он работает нормально, но есть как минимум три тонкости, которые я усвоил на собственном горьком опыте.
1) Браузеры будут переключаться с неработающего IP-адреса на рабочий IP-адрес через 30 секунд (последний раз, когда я проверял), если оба они считаются активными в любом кешированном DNS, доступном вашим клиентам. В основном это хорошо.
Но когда «половина» пользователей ждут 30 секунд, это недопустимо, поэтому вы, вероятно, захотите обновить записи TTL до нескольких минут, а не нескольких дней или недель, чтобы в случае сбоя вы могли быстро удалить неработающий сервер. из вашего DNS. Другие ссылались на это в своих ответах.
2) Если один из ваших серверов имен (или один из двух ваших географических регионов полностью) выходит из строя, который обслуживает ваш домен с циклическим перебором, и если основной из них выходит из строя, я смутно припоминаю, что вы можете столкнуться с другими проблемами, пытаясь удалить это отключен сервер имен от DNS, если вы также не установили для SOA TTL / истечение срока действия сервера имен достаточно низкое значение. Я мог бы ошибиться здесь в технических деталях, но есть более чем одна настройка 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 ближайших к нам любых PoP, отслеживающих ваш сервер из ближайшего места. Когда он обнаруживает, что два из трех не работают, мы просто перенаправляем трафик на другой 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-адреса записи A для выбранных зон и подталкивает эти зоны к NS2.
Альтернативой является система аварийного переключения на основе BGP. Его непросто настроить, но он должен быть пуленепробиваемым. Настройте сайт A в одном месте, сайт B во втором, все с локальными IP-адресами, затем получите класс C или другой блок IP-адресов, которые являются переносимыми, и настройте перенаправление с переносных IP-адресов на локальные IP-адреса.
Есть подводные камни, но это лучше, чем решения на основе DNS, если вам нужен такой уровень контроля.
Один из вариантов аварийного переключения нескольких центров обработки данных - обучение пользователей. Мы рекламируем нашим клиентам, что предоставляем несколько серверов в нескольких городах и в наших электронных письмах о регистрации, включая ссылки непосредственно на каждый «сервер», чтобы пользователи знали, что если один из серверов не работает, они могли использовать ссылку на другой сервер.
Это полностью решает проблему аварийного переключения DNS, просто поддерживая несколько доменных имен. Пользователи, которые переходят на www.company.com или company.com и входят в систему, перенаправляются на server1.company.com или server2.company.com и могут добавить в закладки любой из них, если заметят, что работают лучше, используя тот или иной . Если один из них выходит из строя, пользователи обучаются переходить на другой сервер.
Я использую балансировку сайтов и аварийное переключение на основе DNS в течение последних десяти лет, и есть некоторые проблемы, но их можно решить. BGP, хотя и превосходит некоторые аспекты, не является стопроцентным решением с повышенной сложностью, возможно, дополнительными затратами на оборудование, временем конвергенции и т. Д.
Я обнаружил, что сочетание локальной (на основе LAN) балансировки нагрузки, GSLB и облачного зонального хостинга работает достаточно хорошо, чтобы решить некоторые проблемы, обычно связанные с балансировкой нагрузки DNS.
Все эти ответы имеют определенную ценность для них, но я думаю, что это действительно зависит от того, что вы делаете и каков ваш бюджет. Здесь, в CloudfloorDNS, большая часть нашего бизнеса - это DNS, и мы предлагаем не только быстрый DNS, но и варианты с низким TTL и отказоустойчивость DNS. Мы бы не занимались бизнесом, если бы это не работало и работало хорошо.
Если вы транснациональная корпорация с неограниченным бюджетом на время безотказной работы, да, аппаратные балансировщики нагрузки GSLB и центры обработки данных уровня 1 - это здорово, но ваш DNS по-прежнему должен быть быстрым и надежным. Как многие из вас знают, DNS является критическим аспектом любой инфраструктуры, кроме самого доменного имени, это служба самого низкого уровня, на которой базируется любая другая часть вашего присутствия в сети. Начиная с надежного регистратора доменов, DNS столь же важен, как и предотвращение истечения срока действия вашего домена. DNS выходит из строя, это означает, что весь онлайн-аспект вашей организации также не работает!
При использовании DNS Failover другими критическими аспектами являются мониторинг сервера (всегда следует проверять несколько географических местоположений и всегда следует проверять несколько (как минимум 3), чтобы избежать ложных срабатываний) и правильное управление записями DNS при обнаружении сбоя. Низкий TTL и некоторые варианты переключения при отказе могут сделать этот процесс беспрепятственным и лучше, чем просыпаться от пейджера посреди ночи, если вы системный администратор.
В целом, DNS Failover действительно работает и может быть очень доступным. В большинстве случаев от нас или большинства поставщиков управляемых DNS вы получите Anycast DNS вместе с мониторингом сервера и аварийным переключением за небольшую часть стоимости оборудования.
Итак, настоящий ответ - да, это работает, но подходит ли это для всех и любого бюджета? Может быть, и нет, но пока вы не попробуете и не проведете тесты на себе, это сложно игнорировать, если вы малый или средний бизнес с ограниченным ИТ-бюджетом, который хочет максимально возможного времени безотказной работы.
«и почему вы рискуете использовать его в большинстве производственных сред (хотя это лучше, чем ничего)».
На самом деле, «лучше, чем ничего» лучше выразить как «единственный вариант», когда присутствие географически разнообразно. Аппаратные балансировщики нагрузки отлично подходят для единой точки присутствия, но единственная точка присутствия также является единственной точкой отказа.
Существует множество дорогих сайтов, которые эффективно используют манипуляции с трафиком на основе DNS. Это тип сайтов, которые ежечасно знают, нет ли продаж. Казалось бы, они последними, кто «рискнет использовать его в большинстве производственных сред». Действительно, они внимательно изучили свои варианты, выбрали технологию и хорошо за нее заплатили. Если бы они думали, что что-то лучше, они бы сразу же ушли. Тот факт, что они по-прежнему предпочитают оставаться, красноречиво говорит об их использовании в реальном мире.
Отработка отказа на основе DNS действительно страдает определенной задержкой. Нет никакого способа обойти это. Но это по-прежнему единственный жизнеспособный подход к управлению аварийным переключением в многопользовательском сценарии. Как единственный вариант, это гораздо больше, чем «лучше, чем ничего».
Сегодня хорошие глобальные балансировщики нагрузки, которые работают с этой техникой и работают довольно хорошо. Например, проверьте диспетчер трафика Azure https://azure.microsoft.com/en-us/services/traffic-manager/
Если вы хотите узнать больше, прочтите примечания по применению на
Они охватывают: отработку отказа, глобальную балансировку нагрузки и множество других вопросов.
Если ваша внутренняя архитектура позволяет это, лучшим вариантом будет глобальная балансировка нагрузки с опцией аварийного переключения. Таким образом, все серверы и пропускная способность задействованы в максимально возможной степени. Вместо того, чтобы вставлять дополнительный доступный сервер в случае сбоя, эта настройка выводит отказавший сервер из эксплуатации до тех пор, пока он не будет восстановлен.
Короткий ответ: это работает, но вы должны понимать ограничения.
Я считаю, что идея аварийного переключения была предназначена для кластеризации, но поскольку она также могла работать в одиночку, все же позволяла работать в режиме индивидуальной доступности.
Я бы порекомендовал вам либо A, выбрать центр обработки данных с несколькими сетями на собственной AS, либо B, разместить ваши серверы имен в общедоступном облаке. ДЕЙСТВИТЕЛЬНО маловероятно, что EC2, HP или IBM выйдут из строя. Просто мысль. Хотя DNS работает как исправление, в данном случае это просто исправление плохой конструкции сетевой основы.
Другой вариант, в зависимости от вашей среды, - использовать комбинацию с IPSLA, PBR и FHRP для удовлетворения ваших потребностей в избыточности.