Udostępnij za pośrednictwem


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

Aplikację można wdrożyć w Strefy dostępności w jednym regionie świadczenia usługi Azure, aby uzyskać wyższą dostępność, ale czasami może być konieczne wdrożenie aplikacji w wielu regionach, aby osiągnąć większą odporność, lepszą wydajność dla użytkowników na całym świecie lub lepszą ciągłość działalności biznesowej. Istnieją różne podejścia, które można kierować użytkowników do jednej z lokalizacji, w których wdrożono aplikację z wieloma regionami: podejścia oparte na systemie DNS, takie jak Usługa Azure Traffic Manager, usługi oparte na routingu, takie jak Azure Front Door, lub usługa Load Balancer między regionami platformy Azure.

Poprzednie usługi platformy Azure są zalecane w celu uzyskania użytkownikom najlepszej lokalizacji aplikacji za pośrednictwem publicznego Internetu przy użyciu publicznego adresowania IP, ale nie obsługują sieci prywatnych i adresów IP. W tym artykule omówiono użycie podejścia opartego na trasach (anycast IP) w celu zapewnienia wdrożeń aplikacji obejmujących wiele regionów i sieci prywatnych.

Emisja IP zasadniczo składa się z reklamy dokładnie tego samego adresu IP z więcej niż jednej lokalizacji, dzięki czemu pakiety od użytkowników aplikacji są kierowane do najbliższego regionu (pod względem routingu). Zapewnienie dostępności w wielu regionach w przypadku każdej emisji zapewnia pewne korzyści w przypadku metod opartych na systemie DNS, takich jak brak konieczności polegania na klientach, którzy nie buforują odpowiedzi DNS, i nie wymagają modyfikacji projektu DNS dla aplikacji.

Topologia

W projekcie tego scenariusza ten sam adres IP jest anonsowany z sieci wirtualnych w różnych regionach świadczenia usługi Azure, gdzie wirtualne urządzenia sieciowe (WUS) anonsują adres IP aplikacji za pośrednictwem usługi Azure Route Server. Na poniższym diagramie przedstawiono dwie proste topologie piasty i szprych, z których każda znajduje się w innym regionie świadczenia usługi Azure. Urządzenie WUS w każdym regionie anonsuje tę samą trasę (a.b.c.d/32 w tym przykładzie) do lokalnego serwera usługi Azure Route Server (prefiks trasy nie może nakładać się na platformę Azure i sieci lokalne). Trasy są dalej propagowane do sieci lokalnej za pośrednictwem usługi ExpressRoute. Gdy użytkownicy aplikacji chcą uzyskać dostęp do aplikacji ze środowiska lokalnego, infrastruktura DNS (nieobjęta tym dokumentem) rozpoznaje nazwę DNS aplikacji na dowolny adres IP emisji (a.b.c.d), który lokalne urządzenia sieciowe są kierowane do jednego z dwóch regionów.

Diagram shows an example of using IP anycast with Azure Route Server.

Decyzja o tym, które z dostępnych regionów jest wybierana, jest całkowicie oparta na atrybutach routingu. Jeśli trasy z obu regionów są identyczne, sieć lokalna zazwyczaj korzysta z routingu wielościeżkowego (ECMP, equal-cost multi-path) do wysyłania każdego przepływu aplikacji do każdego regionu. Istnieje również możliwość zmodyfikowania anonsów generowanych przez każde urządzenie WUS na platformie Azure, aby wybrać jeden z regionów. Na przykład użycie ścieżki AS protokołu BGP w celu ustanowienia ścieżki deterministycznej ze środowiska lokalnego do obciążenia platformy Azure.

Ważne

Urządzenia WUS reklamujące trasy powinny zawierać pewien mechanizm kontroli kondycji, aby zatrzymać anonsowanie trasy, gdy aplikacja nie jest dostępna w odpowiednich regionach, aby uniknąć ruchu blackholing.

Zwracany ruch

Gdy ruch aplikacji z klienta lokalnego dociera do jednego z urządzeń WUS na platformie Azure, urządzenie WUS wykonuje połączenie odwrotnego serwera proxy lub docelowego tłumaczenia adresów sieciowych (DNAT). Następnie wysyła pakiety do rzeczywistej aplikacji, która zazwyczaj znajduje się w sieci wirtualnej będącej szprychą równorzędną do sieci wirtualnej koncentratora, w której jest wdrażane urządzenie WUS. Ruch z powrotem z aplikacji przechodzi z powrotem przez urządzenie WUS, co może się zdarzyć naturalnie, jeśli urządzenie WUS odwraca serwer proxy połączenia (lub wykonuje translator adresów sieciowych źródła dodatkowo do docelowego translatora adresów sieciowych).

W przeciwnym razie ruch przychodzący do aplikacji jest nadal pozyskiwany z oryginalnego lokalnego adresu IP klienta. W takim przypadku pakiety mogą być kierowane z powrotem do urządzenia WUS przy użyciu tras zdefiniowanych przez użytkownika (UDR). Należy zachować szczególną ostrożność, jeśli w każdym regionie istnieje więcej niż jedno wystąpienie urządzenia WUS, ponieważ ruch może być asymetryczny (ruch przychodzący i wychodzący przechodzący przez różne wystąpienia urządzenia WUS). Ruch asymetryczny zazwyczaj nie jest problemem, jeśli urządzenia WUS są bezstanowe, ale powoduje błędy, jeśli urządzenia WUS śledzą stany połączenia, takie jak zapory.