Anycast-routning med Azure Route Server
Du kan distribuera ditt program över Tillgänglighetszoner i en enda Azure-region för att uppnå högre tillgänglighet, men ibland kan du behöva distribuera dina program i flera regioner, antingen för att uppnå en högre återhämtning, bättre prestanda för användare över hela världen eller bättre affärskontinuitet. Det finns olika metoder som kan användas för att dirigera användare till en av de platser där ett program med flera regioner distribueras till: DNS-baserade metoder som Azure Traffic Manager, routningsbaserade tjänster som Azure Front Door eller Azure Cross-Region Load Balancer.
De tidigare Azure-tjänsterna rekommenderas för att få användarna till den bästa programplatsen via det offentliga Internet med offentliga IP-adresser, men de stöder inte privata nätverk och IP-adresser. Den här artikeln utforskar användningen av en routningsbaserad metod (IP anycast) för att tillhandahålla distributioner av program med flera regionala, privata nätverk.
IP anycast består i huvudsak av att annonsera exakt samma IP-adress från mer än en plats, så att paket från programanvändare dirigeras till närmaste region (när det gäller routning). Att tillhandahålla nåbarhet för flera regioner över anycast ger vissa fördelar jämfört med DNS-baserade metoder, till exempel att inte behöva förlita sig på klienter som inte cachelagr sina DNS-svar och inte behöver ändra DNS-designen för programmet.
Topologi
I det här scenariot annonseras samma IP-adress från virtuella nätverk i olika Azure-regioner, där virtuella nätverksinstallationer annonserar programmets IP-adress via Azure Route Server. Följande diagram visar två enkla hubb- och ekertopologier, var och en i en annan Azure-region. En NVA i varje region annonserar samma väg (a.b.c.d/32 i det här exemplet) till sin lokala Azure Route Server (routningsprefixet får inte överlappa Med Azure och lokala nätverk). Vägarna sprids vidare till det lokala nätverket via ExpressRoute. När programanvändare vill komma åt programmet lokalt löser DNS-infrastrukturen (som inte omfattas av det här dokumentet) DNS-namnet på programmet till den anycast IP-adress (a.b.c.d), som de lokala nätverksenheterna dirigerar till en av de två regionerna.
Valet av en region bland de tillgängliga alternativen bestäms helt av routningsattribut. Om vägarna från båda regionerna är identiska använder det lokala nätverket vanligtvis ECMP-routning (multi-path) med samma kostnad för att fördela programflöden jämnt mellan båda regionerna. Dessutom kan du justera de vägannonser som genereras av varje NVA i Azure för att prioritera en region framför den andra. Du kan till exempel använda BGP AS Path prepending för att upprätta en önskad sökväg från det lokala nätverket till Azure-arbetsbelastningen.
Viktigt!
DE NVA:er som annonserar vägarna bör innehålla någon hälsokontrollmekanism för att sluta annonsera vägen när programmet inte är tillgängligt i respektive region, för att undvika svart trafik.
Returnera trafik
När programtrafiken från den lokala klienten kommer till en av nva:erna i Azure, utför NVA antingen omvänd proxyanslutning eller DNAT (Destination Network Address Translation). Sedan skickar den paketen till det faktiska programmet, som vanligtvis finns i ett virtuellt ekernätverk som är peer-kopplat till det virtuella hubbnätverket där NVA distribueras. Trafiken tillbaka från programmet går tillbaka via NVA, vilket skulle inträffa naturligt om NVA omvänd proxy för anslutningen (eller utför käll-NAT dessutom till mål-NAT).
Annars kommer trafik som kommer till programmet fortfarande från den ursprungliga lokala klientens IP-adress. I det här fallet kan paket dirigeras tillbaka till NVA med användardefinierade vägar (UDR). Särskild försiktighet måste iakttas om det finns fler än en NVA-instans i varje region, eftersom trafiken kan vara asymmetrisk (inkommande och utgående trafik som går genom olika NVA-instanser). Asymmetrisk trafik är vanligtvis inte ett problem om NVA:er är tillståndslösa, men det resulterar i fel om NVA:er håller reda på anslutningstillstånd, till exempel brandväggar.