DNS и то, как он работает, возможно, сопровождается большим количеством недоразумений, легенд, суеверий и мифологии как любого аспекта ИТ.
Даже те из нас, кто знает, что мы в сущности лжем (или, по крайней мере, радикально упрощаем), когда мы говорим о «распространении» изменений, все еще склонны использовать этот термин для описания чего-то, что - одновременно - чрезвычайно просто и понятно ... все же трудно объяснить ... и не имеет ничего общего с распространением как таковым , но все, что связано с кэшированием и негативным кэшированием, оба являются важным компонентом работы системы (и, возможно, того, как она предотвращает полный крах при его собственный вес) - по сути, наизнанку, противоположную действительному «распространению», тяга - не толчок.
Несмотря на все беспокойства и трудности, связанные с короткими TTL, они, как правило, работают чаще, чем нет, и в ваших интересах просто попробовать их. На $ {day_job}, когда наши сайты переходят со «старой» платформы на «новую» платформу, это часто означает, что они переходят таким образом, что ничто в инфраструктуре не используется совместно. Мой первый шаг в такой миграции - падение TTL до 60-х достаточно далеко до начала отсечения, чтобы у старого TTL было несколько кратных самого себя, что дает мне разумную уверенность в том, что эти переходные RR с короткими TTL «распространятся». «. Когда я буду готов к сокращению, я перенастраиваю старый балансировщик для привязки трафика к новой системе - через Интернет - так, чтобы балансировщик больше не балансировал несколько внутренних систем, а вместо этого был "
Затем я переключаю DNS и смотрю новый балансировщик и старый.
Я всегда приятно удивлен тем, как быстро происходит переход. Похоже, что несогласными почти всегда являются поисковые пауки и сторонние сайты «проверки здоровья», которые необъяснимым образом фиксируются на старых записях.
Но есть один сценарий, который предсказуемо ломается: когда окна браузера пользователя остаются открытыми, они имеют тенденцию привязываться к уже обнаруженному адресу, и часто это продолжается до тех пор, пока все окна его браузера не будут закрыты.
Но в приведенном выше описании вы найдете решение проблемы: «балансировщик нагрузки», а именно, обратный прокси-сервер, может быть системой, на которую указывает ваша открытая запись DNS.
Обратный прокси-сервер затем перенаправляет запрос на правильный целевой IP-адрес, который он разрешает, используя второе «фиктивное» имя хоста с коротким TTL, указывающим на реальный внутренний сервер. ³ Поскольку прокси всегда учитывает DNS TTL на этом фиктивная запись DNS, вы уверены в быстром и полном переключении.
Недостатком является то, что вы можете перенаправлять трафик через ненужную дополнительную инфраструктуру или платить избыточно за транспортировку через несколько сетевых границ.
Существуют службы, которые предоставляют такую возможность в глобальном масштабе, и наиболее знакомой мне является CloudFront. (Скорее всего, Cloudflare будет служить точно такой же цели, так как небольшое количество тестов, которое я провел, указывает на то, что оно также ведет себя правильно, и я уверен, что есть и другие.)
Хотя CloudFront в основном продается как CDN, он по своей сути является глобальной сетью обратных прокси-серверов с возможностью дополнительного кэширования ответов. Если www.example.comуказатель на CloudFront и CloudFront настроен на пересылку этих запросов backend.example.com, а запись DNS для него backend.example.comиспользует короткий TTL, то CloudFront будет действовать правильно, потому что он поддерживает этот короткий TTL. Когда изменяется внутренняя запись, весь трафик будет мигрировать к тому времени, когда истечет TTL.
TTL на внешней стороне записи, указывающей на CloudFront, и то, соблюдают ли его браузеры и средства разрешения кэширования, не имеет значения, поскольку изменения в конечном назначении не требуют изменений в www.example.comзаписи ... так что понятие «Интернет» имеет, что касается правильной цели для www.example.comявляется последовательным, независимо от того, где находится серверная система.
Для меня это полностью решает проблему, избавляя браузер от необходимости «следить» за изменениями IP-адреса исходного сервера.
ТЛ; dr: перенаправить запросы в систему, которая служит прокси-сервером для реального веб-сервера, так что только конфигурация прокси должна учитывать изменение IP-адреса исходного сервера, а не DNS-сервера, обращенного к браузеру.
Обратите внимание, что CloudFront также сводит к минимуму задержку за счет некоторой магии DNS, которую он налагает на лицевую сторону, что приводит к www.example.comразрешению в наиболее оптимальное крайнее местоположение CloudFront на основе местоположения запрашивающего браузера www.example.com, поэтому существует минимальная вероятность того, что трафик будет проходить излишне обходным путем от браузера к краю к источнику ... но эта часть прозрачна и автоматична и выходит за рамки вопроса.
И, конечно же, кэширование контента также может быть полезным за счет снижения нагрузки на исходный сервер или транспорт - я настроил веб-сайты на CloudFront, где исходный сервер находился в канале ADSL, а ADSL по своей природе ограничен для пропускной способности восходящего потока. Исходный сервер, к которому CloudFront подключается для получения контента, не обязательно должен быть сервером внутри экосистемы AWS.
Speak Я говорю о балансире как об одном объекте, когда на самом деле он имеет несколько узлов. Когда балансировщик является ELB, машина, стоящая за балансировщиком, действует как фиктивный сервер приложений и выполняет фактическое закрепление на балансировщике новой платформы, поскольку ELB не может сделать это самостоятельно.
² Единственное знание нового балансировщика о старом состоит в том, что он должен доверять старому балансирующему X-Forwarded-For и что он не должен делать какие-либо ограничения на основе IP для адресов источника старого балансировщика.
³ Если прокси-сервер является одним или несколькими серверами, которыми вы управляете, у вас есть возможность пропустить использование DNS на задней стороне и просто использовать IP-адреса в конфигурации прокси, но обсуждаемый сценарий размещения / распределения впоследствии требует второго уровня DNS ,