Dela via


Hög tillgänglighet för RAS Gateway

Du kan använda det här avsnittet för att lära dig mer om konfigurationer med hög tillgänglighet för RAS Multitenant Gateway for Software Defined Networking (SDN).

Det här avsnittet innehåller följande avsnitt.

Översikt över RAS Gateway

Om din organisation är en molntjänstleverantör (CSP) eller ett företag med flera klienter kan du distribuera RAS Gateway i multitenantläge för att tillhandahålla nätverkstrafikroutning till och från virtuella och fysiska nätverk, inklusive Internet.

Du kan distribuera RAS Gateway i multitenant-läge som en gränsgateway för att effektivt dirigera trafik från hyresgästorganisationers nätverk till deras virtuella nätverk och resurser.

När du distribuerar flera instanser av virtuella RAS Gateway-datorer som ger hög tillgänglighet och redundans distribuerar du en gatewaypool. I Windows Server 2012 R2 bildade alla virtuella gatewaydatorer en enda pool, vilket gjorde en logisk separation av gatewaydistributionen lite svår. Windows Server 2012 R2-gatewayen erbjöd en 1:1-redundansdistribution för de virtuella gatewaydatorerna, vilket resulterade i underutnyttjande av den tillgängliga kapaciteten för VPN-anslutningar från plats till plats (S2S).

Det här problemet löses i Windows Server 2016, som tillhandahåller flera gatewaypooler – som kan vara av olika typer för logisk separation. Det nya läget för M+N-redundans möjliggör en effektivare redundanskonfiguration.

Mer översiktsinformation om RAS Gateway finns i RAS Gateway.

Översikt över gatewaypooler

I Windows Server 2016 kan du distribuera gatewayer i en eller flera pooler.

Följande bild visar olika typer av gatewaypooler som tillhandahåller trafikroutning mellan virtuella nätverk.

RAS Gateway-pooler

Varje pool har följande egenskaper.

  • Varje pool är M+N redundant. Det innebär att ett M-antal aktiva gateway-VM säkerhetskopieras av ett N-antal standby gateway-VM. Värdet för N (standby-gatewayer) är alltid mindre än eller lika med M (aktiva gatewayer).

  • En pool kan utföra någon av de enskilda gatewayfunktionerna – Internet Key Exchange version 2 (IKEv2) S2S, Layer 3 (L3) och Generic Routing Encapsulation (GRE) – eller så kan poolen utföra alla dessa funktioner.

  • Du kan tilldela en enskild offentlig IP-adress till alla pooler eller till en delmängd pooler. Detta minskar avsevärt antalet offentliga IP-adresser som du måste använda, eftersom det är möjligt att alla klienter ansluter till molnet på en enda IP-adress. I avsnittet nedan om hög tillgänglighet och belastningsutjämning beskrivs hur detta fungerar.

  • Du kan enkelt skala upp eller ned en gatewaypool genom att lägga till eller ta bort virtuella gatewaydatorer i poolen. Borttagning eller tillägg av gatewayer stör inte de tjänster som tillhandahålls av en pool. Du kan också lägga till och ta bort hela pooler med gatewayer.

  • Anslutningar för en singel hyresgäst kan avslutas på flera pooler och flera gatewayer i en pool. Men om en klientorganisation har anslutningar som avslutas i en gatewaypool av typen All, kan den inte prenumerera på andra gatewaypooler av typen All eller enskild typ.

Gatewaypooler ger också flexibiliteten att aktivera ytterligare scenarier:

  • Pooler med en enda klientorganisation – du kan skapa en pool för användning av en klientorganisation.

  • Om du säljer molntjänster via partnerkanaler (återförsäljare) kan du skapa separata uppsättningar pooler för varje återförsäljare.

  • Flera pooler kan tillhandahålla samma gatewayfunktion men olika kapaciteter. Du kan till exempel skapa en gatewaypool som stöder både högt dataflöde och IKEv2 S2S-anslutningar med lågt dataflöde.

Översikt över RAS Gateway-distribution

Följande bild visar en typisk CSP-distribution (Cloud Service Provider) av RAS Gateway.

Översikt över RAS Gateway-distribution

Med den här typen av distribution distribueras gatewaypoolerna bakom en SLB (Software Load Balancer), som gör det möjligt för CSP:n att tilldela en enda offentlig IP-adress för hela distributionen. Flera gatewayanslutningar för en klientorganisation kan avslutas på flera gatewaypooler – och även på flera gatewayer i en pool. Detta illustreras via IKEv2 S2S-anslutningar i diagrammet ovan, men detsamma gäller även för andra gatewayfunktioner, till exempel L3- och GRE-gatewayer.

I bilden är MT BGP-enheten en RAS Multitenant Gateway med BGP. Multitenant BGP används för dynamisk routning. Routningen för en hyresgäst är centraliserad – en enda punkt, kallad routereflektor (RR), ansvarar för BGP-peering för alla användarplatser. RR distribueras över alla gateways som en del av en pool. Detta resulterar i en konfiguration där anslutningarna för en klient (datasökväg) avslutas på flera gatewayer, men RR för klientorganisationen (BGP-peeringpunkt – kontrollsökväg) endast finns på en av gatewayerna.

BGP-routern är separerad i diagrammet för att illustrera det här centraliserade routningskonceptet. Gateway-BGP-implementeringen tillhandahåller även transitroutning, vilket gör att molnet kan fungera som en transitpunkt för routning mellan två klientplatser. Dessa BGP-funktioner gäller för alla gatewayfunktioner.

RAS Gateway-integrering med nätverksstyrenhet

RAS Gateway är helt integrerad med nätverksstyrenheten i Windows Server 2016. När RAS Gateway och nätverksstyrenheten distribueras utför nätverksstyrenheten följande funktioner.

  • Utplacering av gateway-pooler

  • Konfiguration av klientanslutningar på varje gateway

  • Växla nätverkstrafikflöden till en standby-gateway i händelse av ett gatewayfel

Följande avsnitt innehåller detaljerad information om RAS Gateway och nätverksstyrenhet.

Etablering och belastningsutjämning av gatewayanslutningar (IKEv2, L3 och GRE)

När en klientorganisation begär en gatewayanslutning skickas begäran till nätverksstyrenheten. Nätverksstyrenheten är konfigurerad med information om alla gatewaypooler, inklusive kapaciteten för varje pool och varje gateway i varje pool. Nätverksstyrenheten väljer rätt pool och gateway för anslutningen. Det här valet baseras på bandbreddskravet för anslutningen. Nätverksstyrenheten använder en "best fit"-algoritm för att välja anslutningar effektivt i en pool. BGP-peeringpunkten för anslutningen fastställs också vid denna tidpunkt om detta är den första anslutningen för klientorganisationen.

När nätverksstyrenheten har valt en RAS-gateway för anslutningen etablerar nätverksstyrenheten den nödvändiga konfigurationen för anslutningen på gatewayen. Om anslutningen är en IKEv2 S2S-anslutning etablerar nätverksstyrenheten även en NAT-regel (Network Address Translation) i SLB-poolen. den här NAT-regeln på SLB-poolen dirigerar anslutningsbegäranden från klientorganisationen till den avsedda gatewayen. Hyresgäster särskiljs av källans IP-adress, som förväntas vara unik.

Note

L3- och GRE-anslutningar kringgår SLB och ansluter direkt till den avsedda RAS-gatewayen. Dessa anslutningar kräver att fjärrslutpunktsroutern (eller annan enhet från tredje part) måste vara korrekt konfigurerad för att ansluta till RAS-gatewayen.

Om BGP-routning är aktiverat för anslutningen initieras BGP-peering av RAS Gateway – och vägar utbyts mellan lokala gatewayer och molngatewayer. De vägar som BGP har lärt sig (eller som är statiskt konfigurerade vägar om BGP inte används) skickas till nätverksstyrenheten. Nätverksstyrenheten plumsar sedan vägarna ner till de Hyper-V värdar där hyresgästens virtuella datorer är installerade. Nu kan klienttrafik dirigeras till rätt lokal plats. Nätverksstyrenheten skapar också associerade Hyper-V nätverksvirtualiseringsprinciper som anger gatewayplatser och implementerar dem på Hyper-V värdar.

Hög tillgänglighet för IKEv2 S2S

En RAS-gateway i en pool består av både anslutningar och BGP-peering för olika klienter. Varje pool har aktiva M-gatewayer och N-standby-gatewayer.

Nätverksstyrenheten hanterar gatewayfelet på följande sätt.

  • Nätverksstyrenheten pingar ständigt gatewayerna i alla pooler och kan identifiera en gateway som är misslyckad eller på väg att misslyckas. Nätverksstyrenheten kan identifiera följande typer av RAS Gateway-fel.

    • Fel vid virtuell RAS Gateway-dator

    • Fel för den Hyper-V värd som RAS-gatewayen körs på

    • FEL i RAS Gateway-tjänsten

    Nätverksstyrenheten lagrar konfigurationen av alla distribuerade aktiva gatewayer. Konfigurationen består av anslutningsinställningar och routningsinställningar.

  • När en gateway misslyckas påverkar den klientanslutningar på gatewayen samt klientanslutningar som finns på andra gatewayer men vars RR finns på den misslyckade gatewayen. Stilleståndstiden för de senare anslutningarna är mindre än den förra. När nätverksstyrenheten identifierar en misslyckad gateway utför den följande uppgifter.

    • Tar bort rutterna för de berörda anslutningarna från beräkningsservrarna.

    • Tar bort Hyper-V principer för nätverksvirtualisering på dessa värdar.

    • Väljer en standby-gateway, konverterar den till en aktiv gateway och konfigurerar gatewayen.

    • Ändrar NAT-mappningarna i SLB-poolen till att peka anslutningar till den nya gatewayen.

  • Samtidigt som konfigurationen kommer upp på den nya aktiva gatewayen återupprättas IKEv2 S2S-anslutningarna och BGP-peering. Anslutningarna och BGP-peering kan initieras av antingen molngatewayen eller den lokala gatewayen. Gatewayerna uppdaterar sina vägar och skickar dem till nätverksstyrenheten. När nätverksstyrenheten har lärt sig de nya vägar som identifieras av gatewayerna skickar nätverksstyrenheten vägarna och de associerade Hyper-V principer för nätverksvirtualisering till de Hyper-V värdar där de virtuella datorerna för de klientorganisationer som påverkas av felet finns. Den här nätverksstyrenhetsaktiviteten liknar omständigheterna för en ny anslutningskonfiguration, bara den sker i större skala.

Hög tillgänglighet för GRE

Processen för RAS Gateway-redundanssvar från nätverksstyrenheten – inklusive felidentifiering, kopiering av anslutning och routningskonfiguration till väntelägesgatewayen, redundansväxling av BGP/statisk routning av de berörda anslutningarna (inklusive tillbakadragande och omval av vägar på beräkningsvärdar och BGP-ompepling) och omkonfiguration av Hyper-V nätverksvirtualiseringsprinciper på beräkningsvärdar – är densamma för GRE-gatewayer och anslutningar. Återetableringen av GRE-anslutningar sker dock på olika sätt, och lösningen med hög tillgänglighet för GRE har vissa ytterligare krav.

Hög tillgänglighet för GRE

Vid tidpunkten för gatewaydistributionen tilldelas varje virtuell RAS Gateway-dator en dynamisk IP-adress (DIP). Dessutom tilldelas varje virtuell gateway-dator även en virtuell IP-adress (VIP) för GRE-hög tillgänglighet. VIP-adresser tilldelas endast till gatewayer i pooler som kan acceptera GRE-anslutningar och inte till icke-GRE-pooler. De VIP:er som tilldelats annonseras överst i rackväxlar (TOR) med hjälp av BGP, som sedan ytterligare annonserar VIP:erna till det fysiska molnnätverket. Detta gör att gatewayerna kan nås från fjärrroutrar eller enheter från tredje part där den andra änden av GRE-anslutningen finns. Den här BGP-peeringen skiljer sig från BGP-peering på klientnivå för utbyte av klientvägar.

Vid tidpunkten för GRE-anslutningsetablering väljer nätverksstyrenheten en gateway, konfigurerar en GRE-slutpunkt på den valda gatewayen och returnerar VIP-adressen för den tilldelade gatewayen. Den här VIP:en konfigureras sedan som fjärrrouterns mål för GRE-tunneladressen.

När en gateway misslyckas kopierar nätverksstyrenheten VIP-adressen för den misslyckade gatewayen och andra konfigurationsdata till standby-gatewayen. När standby-gatewayen blir aktiv annonserar den VIP till sin TOR-switch och vidare in i det fysiska nätet. Fjärrroutrar fortsätter att ansluta GRE-tunnlar till samma VIP och routningsinfrastrukturen säkerställer att paket dirigeras till den nya aktiva gatewayen.

Hög tillgänglighet för L3-vidarebefordringsgatewayar

En Hyper-V vidarebefordrande gateway för nätverksvirtualisering L3 är en brygga mellan den fysiska infrastrukturen i datacentret och den virtualiserade infrastrukturen i Hyper-V nätverkvirtualiseringsmolnet. På en multitenant L3 vidarebefordringsgateway använder varje hyresgäst ett eget VLAN-taggat logiskt nätverk för anslutning till hyresgästens fysiska nätverk.

När en ny klientorganisation skapar en ny L3-gateway väljer Network Controller Gateway Service Manager en tillgänglig virtuell gateway-dator och konfigurerar ett nytt klientgränssnitt med en högtillgänglig IP-adress för kundadressutrymme (CA) (från klientens VLAN-taggade logiska nätverk). IP-adressen används som peer-IP-adress på fjärrgatewayen (fysiskt nätverk) och är Next-Hop för att nå hyresgästens Hyper-V nätverksvirtualiseringsnätverk.

Till skillnad från IPsec- eller GRE-nätverksanslutningar lär sig TOR-växeln inte klientens VLAN-taggade nätverk dynamiskt. Routningen för klientorganisationens VLAN-taggade nätverk måste konfigureras på TOR-växeln och alla mellanliggande växlar och routrar mellan den fysiska infrastrukturen och gatewayen för att säkerställa anslutningen från slutpunkt till slutpunkt. Följande är ett exempel på en CSP Virtual Network-konfiguration som visas i bilden nedan.

Network Subnet VLAN-ID Standardgateway
Contoso L3 logiskt nätverk 10.127.134.0/24 1001 10.127.134.1
Woodgrove L3-logiskt nätverk 10.127.134.0/24 1002 10.127.134.1

Här följer exempel på konfigurationer av klientgatewayen enligt bilden nedan.

Hyresgästnamn IP-adress för L3-gateway VLAN-ID Peer-IP-adress
Contoso 10.127.134.50 1001 10.127.134.55
Woodgrove 10.127.134.60 1002 10.127.134.65

Nedan visas en bild av dessa konfigurationer i ett CSP-datacenter.

Hög tillgänglighet för L3-vidarebefordran av gatewayer

Gatewayfel, felfunktionsdetektering och den automatiska övergångsprocessen i kontexten för en L3-vidarebefordrande gateway liknar processerna för IKEv2- och GRE RAS-gatewayer. Skillnaderna är hur de externa IP-adresserna hanteras.

När tillståndet för den virtuella gatewaydatorn blir felfritt väljer nätverksstyrenheten en av standby-gatewayerna från poolen och etablerar om nätverksanslutningarna och routningen på standby-gatewayen. När anslutningarna flyttas flyttas även IP-adressen för L3-gatewayens högdostillgängliga publika molnutrymme till den nya gateway-virtuella datorn tillsammans med BGP-IP-adressen för hyresgästen.

Eftersom L3-peering-IP-adressen flyttas till den nya virtuella gateway-VM:n under failover kan den fjärranslutna fysiska infrastrukturen återigen ansluta till denna IP-adress och därefter nå nätverksvirtualiseringsarbetsbelastningen Hyper-V. För dynamisk BGP-routning, när CA-utrymmets BGP IP-adress flyttas till den nya virtuella gatewaydatorn, kan den fjärranslutna BGP-routern återupprätta peering och lära sig alla Hyper-V nätverksvirtualiseringsvägar igen.

Note

Du måste konfigurera TOR-växlarna separat och alla mellanliggande routrar för att kunna använda det VLAN-taggade logiska nätverket för klientkommunikation. Dessutom är L3-redundans begränsad till endast de rack som har konfigurerats på det här sättet. Därför måste L3-gatewaypoolen konfigureras noggrant och den manuella konfigurationen måste slutföras separat.