Routing emisji dowolnej za pomocą usługi Azure Route Server

Routing Anycast umożliwia reklamowanie tego samego adresu IP z wielu regionów Azure, co zapewnia lepszą dostępność aplikacji, wydajność i odporność. Dzięki Azure Route Server możesz zaimplementować routing anycast, aby automatycznie kierować ruch do najbliższego lub najbardziej optymalnego wystąpienia aplikacji na podstawie metryk routingu.

W tym artykule wyjaśniono, jak zaimplementować routing typu anycast w usłudze Azure Route Server na potrzeby wdrożeń aplikacji w wielu regionach za pośrednictwem sieci prywatnych.

Co to jest routing anycast?

Routing anycast to metoda adresowania sieciowego i routingu, w której ten sam adres IP jest przypisywany do wielu serwerów lub wystąpień aplikacji w różnych lokalizacjach. Gdy klient wysyła żądanie do dowolnego adresu IP emisji, infrastruktura sieci automatycznie kieruje ruch do najbliższego lub najbardziej optymalnego serwera na podstawie protokołów routingu i metryk.

Korzyści wynikające z routingu anycast

Routing anycast zapewnia kilka zalet wdrożeń wieloregionalnych.

• Zwiększona wydajność: ruch jest automatycznie kierowany do najbliższego wystąpienia aplikacji, co zmniejsza opóźnienie
• Rozszerzona dostępność: jeśli jeden region stanie się niedostępny, ruch zostanie automatycznie przeniesiony do innych regionów
• Dystrybucja obciążenia: ruch można dystrybuować w wielu regionach na podstawie metryk routingu
• Uproszczona konfiguracja klienta: klienci łączą się z pojedynczym adresem IP niezależnie od rzeczywistej lokalizacji serwera
• Obsługa sieci prywatnej: w przeciwieństwie do rozwiązań opartych na DNS, anycast działa z prywatnymi adresami IP i sieciami

Anycast a inne podejścia obejmujące wiele regionów

Platforma Azure oferuje kilka usług dla wdrożeń w wielu regionach, takich jak Azure Traffic Manager, Azure Front Door i Azure Cross-Region Load Balancer, ale te usługi są przeznaczone do publicznego ruchu internetowego i publicznego adresowania IP.

Routing Anycast z usługą Azure Route Server jest przeznaczony dla:

• Scenariusze sieci prywatnej: aplikacje wymagające prywatnego adresowania IP
• Łączność hybrydowa: scenariusze obejmujące połączenia usługi ExpressRoute lub sieci VPN z sieciami lokalnymi
• Zarządzanie ruchem opartym na routingu: gdzie buforowanie DNS lub zachowanie klienta może zakłócać rozwiązania oparte na systemie DNS

Implementacja Anycast z użyciem usługi Azure Route Server

Usługa Azure Route Server umożliwia routing anycast, ułatwiając reklamowanie identycznych tras z wielu regionów platformy Azure do sieci lokalnych za pośrednictwem ExpressRoute lub połączeń VPN.

Przegląd architektury

Implementacja anycast używa następujących składników:

• Wiele regionów platformy Azure: każdy region hostuje wystąpienie aplikacji
• Azure Route Server: wdrożony w każdym regionie w celu zarządzania anonsami tras
• Wirtualne urządzenia sieciowe (WUS): reklamuj adres IP anycast w każdym regionie
• Hub-and-spoke topology: zapewnia łączność między NVA a instancjami aplikacji
• Usługa ExpressRoute lub sieć VPN: łączy regiony platformy Azure z sieciami lokalnymi

Topologia implementacji

Na poniższym diagramie przedstawiono typową implementację anycast z dwoma regionami Azure. Każdy region zawiera:

• Sieć wirtualna hubu z wirtualnym urządzeniem sieciowym i usługą Azure Route Server
• Sieć wirtualna typu szprychowego hostująca instancję aplikacji
• Łączność usługi ExpressRoute z sieciami lokalnymi

Jak działa routing anycast

1. Reklamowanie tras: NVA w każdym regionie reklamują ten sam prefiks adresu IP (na przykład a.b.c.d/32) do lokalnego serwera tras Azure
2. Propagacja tras: usługa Azure Route Server propaguje te trasy do sieci lokalnych za pośrednictwem połączeń usługi ExpressRoute lub sieci VPN
3. Wybór trasy: protokoły routingu lokalnego wybierają najlepszą ścieżkę, aby uzyskać dostęp do dowolnego adresu IP emisji na podstawie metryk routingu
4. Dystrybucja ruchu: ruch klienta jest automatycznie kierowany do optymalnego regionu na podstawie wybranej ścieżki

Wybór trasy i równoważenie obciążenia

Wybór regionu, który otrzyma ruch, zależy od atrybutów routingu.

• Wiele ścieżek o równych kosztach (ECMP): gdy trasy z wielu regionów mają identyczne metryki, ruch jest dystrybuowany równomiernie we wszystkich dostępnych ścieżkach
• Preferencje ścieżki protokołu BGP: Możesz wpływać na decyzje dotyczące routingu, dostosowując atrybuty protokołu BGP, takie jak długość ścieżki AS, preferencje lokalne lub wartości MED
• Dołączanie ścieżki AS: sztucznie wydłuża ścieżkę AS dla określonych tras, aby uczynić je mniej preferowanymi, tworząc scenariusz podstawowy/kopii zapasowej

Rozważania dotyczące ruchu powrotnego

Właściwa obsługa ruchu zwrotnego ma kluczowe znaczenie dla pomyślnych implementacji anycast. Metoda zależy od sposobu, w jaki NVA przetwarza ruch przychodzący.

Metody przetwarzania ruchu

• Tryb zwrotnego serwera proxy zapewnia najbardziej przewidywalny przepływ ruchu, gdy NVA działa jako zwrotny serwer proxy. W tej konfiguracji NVA przerywa oryginalne połączenie od klienta i ustanawia nowe połączenie z wystąpieniem aplikacji. Zwracanie ruchu naturalnie przepływa z powrotem przez tę samą NVA, ponieważ NVA zarządza obiema stronami połączenia.

• Tryb translatora adresów sieciowych (NAT) wymaga różnych rozważań, gdy urządzenie NVA wykonuje tłumaczenie docelowych adresów sieciowych (DNAT). Urządzenie NVA tłumaczy docelowy adres IP z adresu IP anycast na rzeczywisty adres IP aplikacji. Jeśli NVA wykonuje również translację adresów źródłowych (SNAT), przepływ ruchu zwracanego przebiega z powrotem przez to samo urządzenie NVA. Jeśli jednak nie jest wykonywana żadna funkcja SNAT, wymagana jest dodatkowa konfiguracja w celu zapewnienia prawidłowego routingu ruchu powrotnego.

Routowanie ruchu zwrotnego

Gdy aplikacja odbiera ruch z oryginalnym adresem IP klienta (bez użycia SNAT), musisz upewnić się, że ruch jest zwracany przez odpowiednie urządzenie NVA. Trasy zdefiniowane przez użytkownika można skonfigurować w podsieci aplikacji w celu kierowania ruchu z powrotem do NVA. Te zdefiniowane przez użytkownika trasy muszą obejmować zakresy lokalnie zainstalowanych adresów IP i działać dobrze w przypadku wdrożeń pojedynczego urządzenia NVA.

W przypadku wdrożeń z wieloma wystąpieniami urządzenia NVA w regionie kwestie ruchu asymetrycznego stają się istotne. Bezstanowe NVAs mogą obsługiwać ruch asymetryczny, w którym przepływy przychodzące i wychodzące przechodzą przez różne instancje. Jednak stanowe urządzenia NVA wymagają symetrycznego przepływu ruchu w celu zachowania stanu połączenia. Rozwiązania dla stanowych NVA obejmują używanie mechanizmów powiązania połączenia, implementowanie udostępniania sesji między wystąpieniami NVA lub konfigurowanie modułów równoważenia obciążenia z zachowaniem trwałości sesji.

Najlepsze rozwiązania dotyczące przepływu ruchu

Monitorowanie stanu zdrowia powinno implementować niezawodne testy stanu zdrowia w celu szybkiego wykrywania awarii aplikacji i wirtualnych urządzeń sieciowych (NVA). Konfiguracja czasu przełączania awaryjnego wymaga ustawienia odpowiednich timerów BGP, aby znaleźć równowagę między szybkim failoverem a stabilnością. Inżynieria ruchu może używać wspólnot BGP lub innych atrybutów do wdrażania polityki ruchu. Kompleksowe monitorowanie i alerty powinny śledzić anonse tras i wzorce ruchu w różnych regionach, aby zapewnić optymalną wydajność i szybkie wykrywanie problemów.

Uwagi dotyczące implementacji

Wymagania wstępne i wymagania

Przed zaimplementowaniem routingu emisji za pomocą usługi Azure Route Server należy dokładnie zaplanować alokację adresów IP, aby upewnić się, że dowolny adres IP emisji nie powoduje konfliktu z istniejącymi sieciami platformy Azure ani lokalnymi. Solidne zrozumienie zasad routingu BGP i ich wpływ na dystrybucję ruchu jest niezbędne do pomyślnego wdrożenia. Architektura aplikacji musi być zaprojektowana pod kątem efektywnego obsługi ruchu z wielu regionów i należy zaimplementować kompleksowe monitorowanie kondycji zarówno dla aplikacji, jak i wirtualnych urządzeń sieciowych w celu zapewnienia niezawodnej operacji.

Najlepsze praktyki dotyczące wdrażania

Podczas wdrażania routingu anycast zalecamy rozpoczęcie od prostego wdrożenia w dwóch regionach przed rozszerzeniem do innych regionów. Regularne testowanie scenariuszy trybu failover pomaga upewnić się, że system spełnia wymagania dotyczące dostępności i działa zgodnie z oczekiwaniami podczas przestojów. Monitorowanie metryk wydajności, takich jak opóźnienie i przepływność z różnych lokalizacji lokalnych, zapewnia cenny wgląd w skuteczność konfiguracji routingu. Utrzymywanie jasnej dokumentacji zasad protokołu BGP i ich zamierzonych skutków ma kluczowe znaczenie dla ciągłego zarządzania i rozwiązywania problemów.

Ograniczenia i zagadnienia

Podczas implementowania routingu anycast w usłudze Azure Route Server należy wziąć pod uwagę kilka czynników. Czasy zbieżności protokołu BGP mogą powodować opóźnienia podczas zdarzeń przełączenia awaryjnego, potencjalnie wpływając na cele dotyczące czasu odzyskiwania. Dodatkowa złożoność routingu w warstwie sieciowej w porównaniu z rozwiązaniami opartymi na systemie DNS wymaga większej wiedzy i starannego planowania. Rozwiązywanie problemów z routingiem w warstwie sieciowej może być trudniejsze niż diagnozowanie problemów warstwy aplikacji, które wymagają specjalistycznej wiedzy i narzędzi. Ponadto koszty infrastruktury rosną ze względu na potrzebę większej liczby wirtualnych urządzeń sieciowych i wystąpień usługi Route Server w wielu regionach.

Dalsze kroki

• Dowiedz się więcej o obsłudze usługi Azure Route Server dla usługi ExpressRoute i sieci VPN platformy Azure
• Dowiedz się, jak skonfigurować połączenie partnerskie między usługą Azure Route Server a wirtualnymi urządzeniami sieciowymi
• Dowiedz się więcej o preferencjach routingu koncentratora za pomocą usługi Azure Route Server