Routing przełączania awaryjnego i geolokalizacyjny

Routing Failover implementuje konfigurację aktywną-pasywną: jeden rekord jest oznaczony jako Primary, a drugi jako Secondary. Route 53 zawsze zwraca rekord Primary, dopóki jego kontrola stanu kończy się powodzeniem. Jeśli rekord Primary przestanie być sprawny, Route 53 automatycznie przełącza się na zwracanie rekordu Secondary.

Routing Failover jest podstawowym schematem w scenariuszach odtwarzania po awarii, w których istnieje środowisko produkcyjne (podstawowe) oraz środowisko rezerwowe (zapasowe), które powinno otrzymywać ruch wyłącznie wtedy, gdy środowisko podstawowe jest niedostępne.

Aby skonfigurować routing Failover, należy utworzyć dwa rekordy o tej samej nazwie DNS: jeden z wartością Failover=PRIMARY, a drugi z wartością Failover=SECONDARY. Do rekordu Primary należy dołączyć kontrolę stanu. Rekord Secondary również powinien mieć kontrolę stanu, jeśli wskazuje zasób, który może niezależnie ulec awarii.

Rekord Secondary pełni funkcję statycznego rozwiązania awaryjnego — może wskazywać statyczną witrynę internetową S3, stronę konserwacji lub pomniejszone środowisko rezerwowe. Nawet jeśli rekord Secondary nie ma kontroli stanu, Route 53 zawsze przełączy się na niego po awarii rekordu Primary.

Routing Failover tworzy konfigurację aktywną-pasywną: podczas normalnego działania ruch obsługuje tylko rekord Primary, a rekord Secondary pozostaje bezczynny i czeka na przejęcie obsługi. Minimalizuje to koszt środowiska rezerwowego, ale wydłuża nieco czas odzyskiwania — jest to czas potrzebny na wygaśnięcie DNS TTL i przełączenie przez Route 53.

W konfiguracjach aktywnych-aktywnych, w których oba zasoby jednocześnie obsługują ruch, należy użyć routingu Weighted z równymi wagami albo routingu Latency. Jeśli jeden z zasobów ulegnie awarii, jego kontrola stanu zakończy się niepowodzeniem, a Route 53 automatycznie usunie go z odpowiedzi DNS, zapewniając konfigurację aktywną-aktywną z wbudowanym przełączaniem awaryjnym.

Routing Geolocation kieruje zapytania DNS na podstawie geograficznej lokalizacji programu rozpoznawania nazw DNS — zazwyczaj programu rozpoznawania nazw dostawcy usług internetowych użytkownika lub AWS Route 53 Resolver. Tworzą Państwo rekordy dla określonych kontynentów, krajów lub stanów USA, a Route 53 zwraca rekord, którego lokalizacja jest najbardziej szczegółowym dopasowaniem do źródła zapytania.

Jeśli nie ma rekordu dla konkretnej lokalizacji, Route 53 zwraca rekord domyślny, jeśli został skonfigurowany. Bez rekordu domyślnego zapytania z niedopasowanych lokalizacji otrzymują odpowiedź NODATA. Zawsze należy utworzyć rekord domyślny, aby obsłużyć użytkowników z lokalizacji, których nie skonfigurowano jawnie.

Najważniejsze przypadki użycia routingu Geolocation:

• Treści w określonym języku: kierowanie osób mówiących po francusku do źródła CDN z treściami w języku francuskim, a osób mówiących po niemiecku do źródła niemieckiego
• Zgodność z przepisami: zapewnienie, że dane użytkowników z UE pozostają w Regionach UE (GDPR), lub blokowanie dostępu z określonych krajów
• Lokalne ceny lub dostępność: wyświetlanie cen zależnych od regionu lub ograniczanie usług do obsługiwanych terytoriów
• Blokowanie geograficzne: zwracanie strony blokady lub pustej odpowiedzi użytkownikom z ograniczonych lokalizacji przez skierowanie ich rekordu geolokalizacyjnego do punktu końcowego z komunikatem o konserwacji

Route 53 dopasowuje najbardziej szczegółową lokalizację geograficzną: rekord na poziomie stanu ma pierwszeństwo przed rekordem na poziomie kraju, rekord na poziomie kraju przed rekordem na poziomie kontynentu, a rekord na poziomie kontynentu przed rekordem domyślnym. Routing geolokalizacyjny na poziomie stanów USA jest dostępny wyłącznie dla Stanów Zjednoczonych.

Jeśli pominą Państwo rekord domyślny, a lokalizacja użytkownika nie będzie pasować do żadnego skonfigurowanego rekordu, Route 53 zwróci NXDOMAIN lub NODATA — spowoduje to niezauważalne przerwanie dostępu użytkownikom z nieskonfigurowanych regionów. Zawsze należy dodać domyślny rekord geolokalizacyjny jako regułę przechwytującą wszystkie pozostałe przypadki, aby uniknąć takich cichych awarii.

Routing Geoproximity kieruje ruchem na podstawie fizycznej odległości geograficznej między użytkownikami a zasobami, z opcjonalnym parametrem bias, który rozszerza lub zmniejsza efektywny promień routingu każdego zasobu. Dodatnia wartość bias rozszerza obszar geograficzny obsługiwany przez zasób, a ujemna go zmniejsza.

Routing Geoproximity jest dostępny wyłącznie za pośrednictwem Traffic Flow — wizualnego edytora zasad routingu Route 53 — i obsługuje zarówno Regiony AWS, których współrzędne Route 53 zna automatycznie, jak i niestandardowe lokalizacje zasobów, dla których należy podać szerokość i długość geograficzną.

Route 53 Traffic Flow to wizualny edytor zasad, który pozwala tworzyć złożoną logikę routingu przez łączenie wielu zasad w diagramie przypominającym drzewo. Można na przykład najpierw zastosować geolokalizację do oddzielenia ruchu z UE, następnie użyć routingu według opóźnienia w UE w celu wybrania najlepiej działającego Regionu, a na końcu zastosować routing Weighted w każdym Regionie na potrzeby wdrożeń blue-green.

Zasady Traffic Flow są wersjonowane, co umożliwia bezpieczne testowanie zmian. Zasadę Traffic Flow można powiązać z jedną lub większą liczbą nazw DNS, a aktualizacje zasad są natychmiast propagowane bez konieczności ponownego tworzenia poszczególnych rekordów.

Routing Failover można zagnieżdżać w innych zasadach. Typowy schemat polega na użyciu routingu Latency do wybrania najbliższego Regionu, a następnie rekordu Failover w każdym Regionie, aby w przypadku awarii podstawowego punktu końcowego w tym Regionie ruch automatycznie przełączył się na dodatkowy punkt końcowy w tym samym Regionie.

Inny schemat to aktywna-pasywna konfiguracja obejmująca wiele Regionów, w której routing Latency służy do wyboru podstawowego punktu końcowego. Jeśli kontrola stanu podstawowego Regionu zakończy się niepowodzeniem, Route 53 przejdzie do kolejnego sprawnego Regionu o najniższym opóźnieniu, skutecznie łącząc optymalizację opóźnienia z przełączaniem awaryjnym DR.

Aby routing Failover działał prawidłowo, rekord Primary musi** mieć dołączoną kontrolę stanu. Bez kontroli stanu Route 53 uznaje rekord Primary za zawsze sprawny i nigdy nie przełącza się na rekord Secondary. Rekord Secondary może opcjonalnie mieć własną kontrolę stanu; jeśli również przestanie być sprawny, Route 53 i tak zwróci jego adres, ponieważ jest to rozwiązanie ostateczne.

Typy kontroli stanu dostępne dla Failover: kontrole punktów końcowych HTTP/HTTPS, kontrole TCP oraz kontrole alarmów CloudWatch, przydatne w przypadku zbiorczych sygnałów stanu aplikacji łączących wiele metryk.

To rozróżnienie często pojawia się na egzaminie SAA-C03:

• Geolocation: kieruje ruchem na podstawie geograficznego położenia użytkownika — dla danego kraju lub kontynentu zawsze zwraca ten sam punkt końcowy, niezależnie od wydajności; służy do lokalizacji treści i zapewnienia zgodności z przepisami
• Latency: kieruje ruchem na podstawie wydajności sieci względem użytkownika — może skierować użytkownika w Europie do us-east-1, jeśli w danym momencie działa ono szybciej niż eu-west-1; służy do optymalizacji wydajności

Słowa kluczowe w pytaniach egzaminacyjnych: „zapewnienie zgodności z wymogami dotyczącymi rezydencji danych”, „treści zależne od kraju”, „blokowanie użytkowników z określonych regionów” → Geolocation. „najbliższy Region”, „najmniejsze opóźnienie”, „najlepsza wydajność dla użytkowników z całego świata” → Latency.

W tej lekcji nauczyli się Państwo, że: routing awaryjny tworzy wysoką dostępność w modelu active-passive, przełączając ruch na Secondary, gdy test kondycji Primary zakończy się niepowodzeniem; routing geolokalizacyjny kieruje użytkowników na podstawie ich położenia geograficznego na potrzeby zgodności z przepisami i lokalizacji; a routing geograficznej bliskości wykorzystuje fizyczną odległość z konfigurowalnym przesunięciem za pośrednictwem Traffic Flow. Zawsze należy dodać domyślny rekord geolokalizacyjny, aby obsłużyć lokalizacje, które nie pasują do żadnego zakresu. W następnej części szczegółowo omówimy testy kondycji i DNS failover.