DNS і як він працює, можливо, супроводжується більшою мірою нерозуміння, легенди, забобони та міфології як будь-якого аспекту ІТ.
Навіть ті з нас, хто знає, що насправді брешуть (або принаймні різко спрощують), коли ми говоримо про "поширення" змін, як і раніше, як правило, використовують термін для опису чогось, що є - одночасно - надзвичайно простим і прямим ... але важко пояснити ... і не має нічого спільного з поширенням самого по собі , але все, що з кешуванням і негативним кешуванням, обидва з яких є одним з найважливіших компонентів , як працює система (і, можливо, як він уникає прямого колапсу під власна вага) - по суті внутрішньо-зовнішнє, протилежне фактичному «розповсюдженню», тягнути - не виштовхувати.
Незважаючи на те, що хвилюються та стискаються з приводу коротких TTL, вони, як правило, працюють частіше за все, до того, що, можливо, вам потрібно просто спробувати їх. Коли $ {day_job} коли наші сайти переходять зі "старої" платформи на "нову" платформу, це часто означає, що вони мігрують таким чином, що нічого в інфраструктурі не ділиться. Мій перший крок у такій міграції - це скидання TTL до 60-х років достатньо далеко перед розрізом, так що старий TTL має кілька кратних самих себе, щоб вичерпатися, що дає мені обґрунтовану впевненість, що ці перехідні RR з короткими TTL будуть "поширюватися" . " Коли я готовий до скорочення, я переконфігурую старий балансир¹, щоб закріпити трафік до нової системи - через Інтернет - таким чином, щоб балансир більше не врівноважував декілька внутрішніх систем, а натомість "
Потім я вирізаю DNS і спостерігаю за новим балансиром і старим.
Мене завжди приємно дивує те, як швидко відбувається перехід. Схоже, майже завжди це пошукові павуки та сторонні сайти "перевірки здоров'я", які незрозуміло прив'язуються до старих записів.
Але є один сценарій, який передбачувано руйнується: коли вікна браузера користувача залишаються відкритими, вони, як правило, прив'язуються до вже виявленої адреси, і часто це зберігається, поки всі їх вікна браузера не закриються.
Але у наведеному вище описі ви знаходите рішення проблеми: "балансир завантаження" - конкретно і точніше, зворотний проксі - може бути системою, на яку вказує ваш відкритий запис DNS.
Потім зворотний проксі пересилає запит на правильну цільову IP-адресу, яку він вирішує, використовуючи друге "манекенне" ім'я хоста з коротким TTL, що вказує на реальний сервер зворотного зв'язку. фіктивний запис DNS, ви впевнені в швидкому і повному перемиканні.
Недоліком є те, що ви можете направляти трафік через непотрібну додаткову інфраструктуру або платити більше за транспорт через декілька меж мережі, зайве.
Є сервіси, які надають такі можливості в глобальному масштабі, і той, з яким я найбільше знайомий, - це CloudFront. (Швидше за все, Cloudflare буде служити точно тій самій цілі, оскільки невелика кількість тестувань, які я зробив, вказує на те, що він також поводиться правильно, і я впевнений, що є й інші.)
Хоча в основному продається як CDN, CloudFront є своєю суттю глобальною мережею зворотних проксі-серверів із можливістю додаткового кешування відповідей. Якщо 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.
¹ Я кажу про балансира, як про єдине ціле, коли насправді він має кілька вузлів. Коли балансир - це ELB, машина, яка стоїть за балансовою системою, виконує функцію фіктивного сервера додатків і робить фактичну прив’язку до балансира нової платформи, оскільки ELB не може це зробити самостійно.
² Єдине знання нового балансира про старий - це те, що йому потрібно довіряти X-Forwarded-For старого балансира і що він не повинен робити ніяких обмежень на основі IP, що обмежуються на вихідні адреси старого балансира.
³ Коли проксі-сервер є одним або декількома серверами, якими ви керуєте, у вас є можливість пропустити за допомогою DNS на зворотному боці та просто використовувати IP-адреси в конфігурації проксі-сервера, але хост / розподілений сценарій, що обговорюється, згодом потребує цього другого рівня DNS .