DNS i jego działaniu może towarzyszyć więcej nieporozumień, legend, przesądów i mitologii jako dowolnego aspektu IT.
Nawet ci z nas, którzy wiedzą, że zasadniczo kłamiemy (lub przynajmniej drastycznie upraszczamy), kiedy mówimy o „propagowaniu” zmian, nadal używają tego terminu do opisania czegoś, co - jednocześnie - jest niezwykle proste i jednoznaczne ... ale trudne do wyjaśnienia ... i nie ma nic wspólnego z propagacją jako taką , ale wszystko, co dotyczy buforowania i buforowania negatywnego, które są istotnym składnikiem działania systemu (i, prawdopodobnie, w jaki sposób pozwala uniknąć całkowitego upadku pod własnego ciężaru) - zasadniczo wywrotka, przeciwieństwo rzeczywistego „propagacji”, ciągnięcia - a nie pchania.
W przypadku wszystkich zmartwień i kłopotów związanych z krótkimi czasami TTL, zwykle działają one częściej niż nie, do tego stopnia, że w twoim interesie może być po prostu ich wypróbowanie. Gdy $ {day_job}, kiedy nasze witryny migrują ze „starej” platformy na „nową” platformę, często oznacza to, że migrują w taki sposób, że nic w infrastrukturze nie jest udostępniane. Moim pierwszym krokiem w takiej migracji jest obniżenie TTL do lat 60 wystarczająco daleko przed cięciem, tak że stary TTL ma wiele wielokrotności siebie do wyczerpania, co daje mi wystarczającą pewność, że te przejściowe RR z krótkimi TTL „rozejdą się” . ” Kiedy jestem gotowy do cięcia, ponownie konfiguruję stary moduł równoważący¹, aby spiąć ruch z nowym systemem - przez Internet - tak, aby moduł równoważący nie balansował już wielu systemów wewnętrznych, ale zamiast tego jest „
Następnie przełączam DNS i obserwuję nowy balancer i stary.
Zawsze jestem mile zaskoczony, jak szybko zachodzi przemiana. Występują niemal zawsze pająki wyszukiwania i strony „sprawdzające kondycję” stron trzecich, które w niewytłumaczalny sposób nawiązują do starych zapisów.
Ale jest jeden scenariusz, który rozkłada się w przewidywalny sposób: gdy okna przeglądarki użytkownika pozostają otwarte, mają tendencję do blokowania się na już odkrytym adresie i często utrzymuje się, dopóki wszystkie okna przeglądarki nie zostaną zamknięte.
Ale w powyższej narracji znajduje się rozwiązanie problemu: „moduł równoważenia obciążenia” - konkretnie, a dokładniej, odwrotne proxy - może być systemem, na który wskazuje odsłonięty rekord DNS.
Odwrotny serwer proxy przesyła następnie żądanie na właściwy docelowy adres IP, który jest rozwiązywany za pomocą drugiej „fałszywej” nazwy hosta z krótkim TTL, co wskazuje na prawdziwy serwer zaplecza .³ Ponieważ proxy zawsze honoruje TTL DNS na tym fałszywy wpis DNS, masz pewność szybkiego i całkowitego przełączenia.
Wadą jest to, że możesz kierować ruchem przez niepotrzebną dodatkową infrastrukturę lub płacić za transport ponad wieloma granicami sieci, nadmiarowo.
Istnieją usługi, które zapewniają tego rodzaju możliwości w skali globalnej, a najbardziej znana jest CloudFront. (Najprawdopodobniej Cloudflare miałby dokładnie ten sam cel, ponieważ mały zestaw testów, które przeprowadziłem, wskazuje, że również zachowuje się poprawnie i jestem pewien, że są inne.)
Chociaż CloudFront jest sprzedawany głównie jako CDN, u podstaw jest globalna sieć odwrotnych serwerów proxy z możliwością opcjonalnego buforowania odpowiedzi. Jeśli www.example.compunkty do CloudFront i CloudFront są skonfigurowane do przekazywania tych żądań backend.example.com, a rekord DNS dla backend.example.comużywa krótkiego TTL, wówczas CloudFront zrobi właściwą rzecz, ponieważ honoruje to krótkie TTL. Gdy rekord zaplecza ulegnie zmianie, ruch będzie migrowany do czasu wyczerpania TTL.
TTL rekordu frontowego wskazującego na CloudFront i to, czy przeglądarki i programy buforujące honorują go, są nieistotne, ponieważ zmiany miejsca docelowego zaplecza nie wymagają zmian w www.example.comrekordzie ... więc pojęcie, że „Internet” ma, jeśli chodzi o właściwy cel, www.example.comjest spójny, niezależnie od tego, gdzie znajduje się system zaplecza.
Dla mnie to całkowicie rozwiązuje problem, zwalniając przeglądarkę z potrzeby „śledzenia” zmian adresu IP serwera źródłowego.
tl; dr: kieruje żądania do systemu, który służy jako serwer proxy dla prawdziwego serwera WWW, tak że tylko konfiguracja serwera proxy musi uwzględniać zmianę adresu IP serwera źródłowego - nie DNS skierowany do przeglądarki.
Zwróć uwagę, że CloudFront minimalizuje również opóźnienie dzięki pewnej magii DNS, którą narzuca na stronę frontową, co powoduje www.example.comrozwiązywanie najbardziej optymalnej lokalizacji krawędzi CloudFront na podstawie lokalizacji zapytania www.example.com, więc ruch jest niepotrzebnie okrężny. od przeglądarki do krawędzi do początku ... ale ta część jest przezroczysta i automatyczna i nie wchodzi w zakres pytania.
Oczywiście buforowanie zawartości może być również przydatne, ponieważ zmniejsza obciążenie serwera lub transportu źródłowego - skonfigurowałem strony internetowe na CloudFront, gdzie serwer źródłowy był w obwodzie ADSL, a ADSL jest z natury ograniczony do przepustowości łącza nadawczego. Serwer źródłowy, z którym łączy się CloudFront w celu pobrania zawartości, nie musi być serwerem w ekosystemie AWS.
¹ Mówię o równoważeniu jako o pojedynczej jednostce, gdy w rzeczywistości ma wiele węzłów. Gdy moduł równoważący jest modułem ELB, maszyna stojąca za modułem równoważącym działa jako atrapa serwera aplikacji i faktycznie łączy się z modułem równoważącym nowej platformy, ponieważ ELB nie może tego zrobić samodzielnie.
² Jedyną wiedzą nowego modułu równoważącego na temat starej jest to, że musi on ufać X-Forwarded-For starego modułu równoważącego i że nie powinien wykonywać żadnych ograniczeń opartych na IP na źródłowych adresach starego modułu równoważącego.
³ Gdy serwerem proxy jest jeden lub więcej serwerów, które kontrolujesz, możesz pominąć korzystanie z DNS po stronie zaplecza i po prostu użyć adresów IP w konfiguracji serwera proxy, ale omówiony scenariusz hostowany / rozproszony potrzebuje następnie drugiej warstwy DNS .