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

<p>из чтения кажется, что отказоустойчивость dns не рекомендуется только потому, что dns не был разработан для этого. но если у вас есть два веб-сервера в разных подсетях, в которых размещается избыточный контент, какие существуют другие способы, чтобы гарантировать, что весь трафик будет перенаправлен на работающий сервер, если один сервер выйдет из строя?</p><p>мне кажется, что dns failover является единственным вариантом восстановления после сбоя, но единодушным является то, что это не очень хороший вариант. и все же такие сервисы, как dnsmadeeasy.com, предоставляют его, поэтому в этом должна быть заслуга. любые комментарии?</p>

<p>под "отказоустойчивостью dns" я понимаю, что вы имеете в виду dns round robin в сочетании с некоторым мониторингом, то есть публикацией нескольких ip-адресов для имени хоста dns и удалением мертвого адреса, когда мониторинг обнаруживает, что сервер не работает. это может быть работоспособным для небольших, менее посещаемых сайтов.</p><p>когда вы отвечаете на запрос dns, вы также предоставляете время жизни (ttl) для ответа, который вы раздаете. другими словами, вы говорите другим dns-серверам и кешам: "вы можете сохранить этот ответ и использовать его в течение x минут, прежде чем проверять со мной". из этого вытекают недостатки:</p><ul> <li>при аварийном переключении dns неизвестный процент ваших пользователей будет кэшировать ваши данные dns с различным объемом ttl осталось. до истечения срока действия ttl они могут подключиться к мертвый сервер. <strong>есть более быстрые способы завершения аварийного переключения, чем этот.</strong></li> <li>из-за вышеизложенного вы склонны устанавливать ttl) достаточно низким, скажем, 5-10 минут. но установка его выше дает (очень небольшое) выигрыш в производительности и может помочь распространению dns работать надежно, даже если в сетевом трафике есть небольшая проблема, поэтому использование аварийного переключения на основе dns идет против высоких ttl, но высокие ttl являются частью dns и могут быть полезны.</li> </ul><p>более распространенные методы получения хорошего времени работы включают в себя:</p><ul> <li>размещение серверов в одной локальной сети.</li> <li>поместите лвс в центр обработки данных с высокой доступностью питания и сетевых плоскостей.</li> <li>используйте балансировщик нагрузки http для распределения нагрузки и отработки отказа при сбоях отдельных серверов.</li> <li>получите уровень резервирования/ожидаемое время безотказной работы, необходимое для брандмауэров, балансировщиков нагрузки и коммутаторов.</li> <li>разработайте коммуникационную стратегию для сбоев в полном центре обработки данных и случайного сбоя коммутатора/сервера базы данных/другого ресурса, который нельзя легко отразить.</li> </ul><p>очень небольшое количество веб-сайтов используют настройки нескольких центров обработки данных с "геобалансировкой" между центрами обработки данных.</p>

<p>отработка отказа dns определенно работает отлично. я использую его в течение многих лет, чтобы вручную переключать трафик между центрами обработки данных или автоматически, когда системы мониторинга обнаруживают сбои, проблемы с подключением или перегруженные серверы. когда вы увидите скорость, с которой он работает, и объемы реального трафика, которые можно легко перенести, вы никогда не оглянетесь назад. я использую zabbix для мониторинга всех своих систем, а визуальные графики, показывающие, что происходит во время аварийного переключения dns, заставляют меня сомневаться и заканчивать. там могут быть несколько интернет-провайдеров, которые игнорируют ttl, и есть некоторые пользователи, которые все еще используют старые браузеры - но когда вы смотрите на трафик с миллионов просмотров страниц в день в двух местах центра обработки данных и вы делаете смену трафика dns - оставшийся трафик, который игнорирует ttl, смешен. отработка отказа dns - это надежный метод.</p><p>dns не был разработан для аварийного переключения - но он был разработан с ttl, которые прекрасно работают для аварийного переключения в сочетании с надежной системой мониторинга. ttl могут быть очень короткими. я эффективно использовал ttl продолжительностью 5 секунд в производстве для облегчения решений, основанных на быстром отказоустойчивости dns. вы должны иметь dns-серверы, способные справиться с дополнительной нагрузкой - и named не будет сокращать ее. тем не менее, powerdns отвечает всем требованиям, если он поддерживается реплицированными базами данных mysql на избыточных серверах имен. вам также нужна надежная распределенная система мониторинга, которой вы можете доверять для автоматической интеграции при сбое. zabbix работает для меня - я могу почти мгновенно проверить сбои в нескольких распределенных системах zabbix - обновлять записи mysql, используемые powerdns, на лету - и обеспечивать почти мгновенное переключение при сбое во время отключений и всплесков трафика.</p><p>но, эй, я построил компанию, которая предоставляет службы аварийного переключения dns после многих лет работы для крупных компаний. так что прими мое мнение с крошкой соли. если вы хотите увидеть некоторые графики трафика zabbix для сайтов большого объема во время сбоя - чтобы убедиться, как именно работает отказоустойчивость dns - напишите мне, я более чем рад поделиться.</p>

<p>проблема с отказоустойчивостью dns заключается в том, что во многих случаях она ненадежна. некоторые интернет-провайдеры игнорируют ваши ttl, это происходит не сразу, даже если они действительно уважают ваши ttl, и когда ваш сайт возвращается, это может привести к некоторой странности с сеансами, когда время ожидания dns-кэша пользователя истекает, и они заканчивают заголовком на другой сервер.</p><p>к сожалению, это в значительной степени единственный вариант, если только вы не достаточно велики, чтобы выполнять собственную (внешнюю) маршрутизацию.</p>

<p>распространено мнение, что при dns rr, когда ip-адрес падает, некоторые клиенты будут продолжать использовать сломанный ip-адрес в течение нескольких минут. об этом было сказано в некоторых предыдущих ответах на вопрос, и это также написано в википедии.</p><p>тем не мение,</p><p> <a href="http://crypto.stanford.edu/dns/dns-rebinding.pdf">http://crypto.stanford.edu/dns/dns-rebinding.pdf</a> объясняет, что это не так для большинства современных браузеров html. они попробуют следующий ip через несколько секунд.</p><p> <a href="http://www.tenereillo.com/gslbpageofshame.htm">http://www.tenereillo.com/gslbpageofshame.htm</a> кажется еще более сильным:</p><blockquote> <p>использование нескольких записей a - это не хитрость или особенность, задуманная производителями оборудования для балансировки нагрузки. именно по этой причине протокол dns был разработан с поддержкой нескольких записей а. такие приложения, как браузеры, прокси и почтовые серверы, используют эту часть протокола dns.</p> </blockquote><p>может быть, какой-то эксперт может прокомментировать и дать более четкое объяснение того, почему dns rr не подходит для высокой доступности.</p><p>спасибо,</p><p>валентино</p><p>ps: извините за неработающую ссылку, но, как новый пользователь, я не могу опубликовать более 1</p>

<p>в течение многих лет я выполнял отработку отказа dns rr на производственном, но критически важном для бизнеса веб-сайте (в двух регионах).</p><p>это отлично работает, но есть как минимум три тонкости, которые я усвоил на собственном опыте.</p><p>1) браузеры переключатся с нерабочего ip на рабочий ip через 30 секунд (в последний раз, когда я проверял), если оба они считаются активными в любой кэшированной dns, доступной вашим клиентам. это в основном хорошая вещь.</p><p>но "половина" ваших пользователей ждать 30 секунд недопустимо, поэтому вы, вероятно, захотите обновить записи ttl) на несколько минут, а не нескольких дней или недель, чтобы в случае в случае сбоя вы можете быстро удалить отключенный сервер из dns, другие ссылались на это в своих ответах.</p><p>2) если один из ваших серверов имен (или одна из ваших двух географических зон полностью) выйдет из строя, который обслуживает ваш круговой домен, и если основной из них выйдет из строя, я смутно напоминаю, что вы можете столкнуться с другими проблемами, пытаясь удалить это сбитый сервер имен из dns, если вы не установили soa ttl/expiration для сервера имен также достаточно низкое значение. я мог бы ошибиться в технических деталях, но их больше, чем один = ttl настройка, которая вам нужна, чтобы получить право на настоящую защиту от единичных точек отказа.</p><p>3) если вы публикуете веб-api, rest сервисы и т.д., они обычно не вызываются браузерами, и, таким образом, по моему мнению, отработка отказа dns начинает показывать реальные недостатки. возможно, поэтому некоторые говорят, как вы говорите "это не рекомендуется". вот почему я так говорю. во-первых, приложения, которые используют эти url-адреса, обычно не являются браузерами, поэтому им не хватает 30-секундных свойств переключения/логики обычных браузеров. вторая запись dns вызывается или даже повторный опрос dns во многом зависит от низкоуровневых деталей программирования сетевых библиотек на языках программирования, используемых этими клиентами api/rest, а также от того, как они вызываются клиентом api/rest приложение. (под этими заголовками библиотека вызывает get\_addr и когда? если сокеты зависают или закрываются, приложение повторно открывает новые сокеты? есть ли какая-то логика тайм-аута? и т. д. и т. д.)</p><p>это дешево, хорошо проверено и "в основном работает". как и в большинстве случаев, ваш пробег может отличаться.</p>

<p>есть группа людей, которые используют нас (dyn) для восстановления после отказа. это та же самая причина, по которой сайты могут либо создавать страницу состояния, когда у них есть время простоя (например, такие вещи, как twitter fail whale) ... или просто перенаправлять трафик на основе ttl. некоторые люди могут подумать, что dns failover - это гетто ... но мы серьезно спроектировали нашу сеть с отказоустойчивостью с самого начала ... чтобы она работала так же хорошо, как и оборудование. я не уверен, как dme это делает, но у нас есть 3 из 17 наших ближайших любых точек зрения, которые отслеживают ваш сервер из ближайшего местоположения. когда из двух из трех обнаруживается, что он не работает, мы просто перенаправляем трафик на другой ip-адрес. единственное время простоя - это те, которые были запрошены на оставшуюся часть этого интервала ttl).</p><p>некоторые люди любят использовать оба сервера одновременно ... и в этом случае могут делать что-то вроде циклического распределения нагрузки ... или распределения нагрузки на основе гео. для тех, кто действительно заботится о производительности ... наш диспетчер трафика в режиме реального времени будет следить за каждым сервером ... и если он медленнее ... перенаправить трафик на самый быстрый, основываясь на том, какие ip-адреса вы указали в своих именах хостов. опять же ... это работает на основе значений, которые вы указали в нашем ui/api/portal.</p><p>я предполагаю, что моя точка зрения ... мы специально спроектировали аварийное переключение dns. хотя dns изначально не создавался для восстановления после отказа, наша сеть dns была разработана для его реализации с самого начала. обычно это может быть так же эффективно, как и аппаратное обеспечение. без амортизации или стоимости оборудования. надеюсь, что это не заставляет меня думать, что я подключил dyn ... есть много других компаний, которые делают это ... я просто говорю с точки зрения нашей команды. надеюсь это поможет...</p>

<p>другой вариант - настроить сервер имен 1 в местоположении a и сервер имен 2 в местоположении b, но настроить каждый из них так, чтобы все записи a в ns1 указывали трафик на ip для местоположения a, а на ns2 все записи a указывали на ip для местоположение b. затем установите свои ttl для очень низкого числа и убедитесь, что ваша запись домена в регистраторе настроена для ns1 и ns2. таким образом, он будет автоматически балансировать нагрузку, и при сбое одного сервера или одной ссылки на местоположение произойдет сбой.</p><p>я использовал этот подход немного по-другому. у меня есть одно местоположение с двумя провайдерами, и я использую этот метод для направления трафика по каждой ссылке. теперь, это может быть немного больше обслуживания, чем вы готовы сделать ... но я смог создать простое программное обеспечение, которое автоматически извлекает записи ns1, обновляет ip-адреса записи для выбранных зон и переводит эти зоны в ns2.</p>

<p>альтернативой является отказоустойчивая система на основе bgp. это не просто настроить, но это должно быть пуленепробиваемым. настройте сайт a в одном месте, сайт b в секунду с локальными ip-адресами, затем получите переносимый ip-адрес класса c или другой блок и настройте перенаправление с переносных ip-адресов на локальные ip-адреса.</p><p>есть подводные камни, но лучше, чем решения на основе dns, если вам нужен такой уровень контроля.</p>

<p>один из вариантов аварийного переключения нескольких центров обработки данных - это обучение пользователей. мы объявляем нашим клиентам, что мы предоставляем несколько серверов в нескольких городах и в наших электронных письмах о регистрации, и в них включены ссылки непосредственно на каждый "сервер", чтобы пользователи знали, если один сервер не работает, они могут использовать ссылку на другой сервер.</p><p>это полностью обходит проблему аварийного переключения dns, просто поддерживая несколько доменных имен. пользователи, которые заходят на www.company.com или company.com и входят в систему, направляются на server1.company.com или server2.company.com и могут выбрать закладку для любого из них, если заметят, что с помощью одного или другого они получат более высокую производительность. , если один выходит из строя, пользователи обучаются переходить на другой сервер.</p>

<p>последние десять лет я использую балансировку сайтов на основе dns и отработку отказа, и есть некоторые проблемы, но они могут быть смягчены. bgp, хотя и в некотором смысле лучше, не является 100% решением с повышенной сложностью, возможно, дополнительными затратами на оборудование, временем конвергенции и т.</p><p>я обнаружил, что объединение локальной (на основе локальной сети) балансировки нагрузки, gslb и хостинга на основе облачных зон работает достаточно хорошо, чтобы закрыть некоторые проблемы, обычно связанные с балансировкой нагрузки на dns.</p>

<p>все эти ответы имеют какое-то значение для них, но я думаю, что это действительно зависит от того, что вы делаете и каков ваш бюджет. здесь, в cloudfloordns, большой процент нашего бизнеса - это dns, и он предлагает не только быстрый dns, но и низкие ttl опции и отказоустойчивость dns. мы не были бы в бизнесе, если бы это не работало) и работать хорошо.</p><p>если вы являетесь многонациональной корпорацией с неограниченным бюджетом на время безотказной работы, то да, аппаратные балансировщики нагрузки gslb и центры обработки данных уровня 1 великолепны, но ваш dns все еще должен быть быстрым и надежным. как многие из вас знают, dns является критическим аспектом любой инфраструктуры, кроме самого доменного имени, это сервис самого низкого уровня, на котором основывается любая другая часть вашего присутствия в сети. начиная с надежного регистратора доменов, dns так же важен, как и прекращение срока действия вашего домена. dns выходит из строя, это означает, что весь онлайн аспект вашей организации также не работает!</p><p>при использовании отказоустойчивости dns другими важными аспектами являются мониторинг сервера (всегда необходимо проверять несколько географических местоположений и всегда несколько (по крайней мере, 3) проверять, чтобы избежать ложных срабатываний) и правильно управлять записями dns, если обнаружен сбой. низкие значения ttl и некоторые опции, связанные с переключением при сбое, могут сделать этот процесс беспроблемным, и вы не сможете проснуться на пейджер посреди ночи, если вы системный администратор.</p><p>в целом, dns failover действительно работает и может быть очень доступным. в большинстве случаев у нас или у большинства провайдеров управляемых dns вы получаете anycast dns вместе с мониторингом сервера и отработкой отказа за небольшую часть стоимости аппаратного обеспечения.</p><p>таким образом, реальный ответ - да, это работает, но это для всех и каждого бюджета? возможно, нет, но пока вы не попробуете это и не проведете тесты для себя, трудно игнорировать, если вы являетесь предприятием малого и среднего бизнеса с ограниченным ит-бюджетом, который хочет максимально возможное время безотказной работы.</p>

<p>сегодня хорошие глобальные балансировщики нагрузки, которые работают с использованием этой техники и работают довольно хорошо. проверьте, например, azure traffic manager <a href="https://azure.microsoft.com/en-us/services/traffic-manager/">https://azure.microsoft.com/en-us/services/traffic-manager/</a> </p>

<p>"и почему вы рискуете использовать его для большинства производственных сред (хотя это лучше, чем ничего)".</p><p>на самом деле, "лучше, чем ничего" лучше выражать как "единственный вариант", когда присутствия географически разнообразны. аппаратные балансировщики нагрузки отлично подходят для одной точки присутствия, но единственная точка присутствия также является единственной точкой отказа.</p><p>есть много сайтов с большим долларом, которые используют dns на основе манипуляции трафиком для хорошего эффекта. это тот тип сайтов, которые ежечасно узнают, что продажи отключены. может показаться, что они последними, кто "рискует, используя его для большинства производственных сред". действительно, они тщательно рассмотрели свои варианты, выбрали технологию и хорошо за нее заплатили. если они думают, что что-то лучше, они уходят в одно мгновение. тот факт, что они по-прежнему предпочитают оставаться, говорит о реальном использовании мира.</p><p>аварийное переключение на основе dns имеет определенную задержку. обойти это невозможно. но это все еще единственный жизнеспособный подход к управлению отказоустойчивостью в мульти-поп сценарии. как единственный вариант, это гораздо больше, чем "лучше, чем ничего".</p>

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

<p>если вы хотите узнать больше, прочитайте заметки по применению на</p><p> <a href="http://edgedirector.com">http://edgedirector.com</a> </p><p>они охватывают: аварийное переключение, глобальное распределение нагрузки и множество связанных вопросов.</p><p>если ваша внутренняя архитектура разрешает это, лучшим вариантом является глобальная балансировка нагрузки с возможностью восстановления после отказа. таким образом, все серверы и пропускная способность будут задействованы в максимально возможной степени. вместо вставки дополнительного доступного сервера в случае сбоя эта настройка выводит отказавший сервер из службы до его восстановления.</p><p>короткий ответ: это работает, но вы должны понимать ограничения.</p>