Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
U kunt dit onderwerp gebruiken voor meer informatie over configuraties voor hoge beschikbaarheid voor de RAS Multitenant-gateway voor Software Defined Networking (SDN).
Dit onderwerp bevat de volgende secties.
Overzicht van RAS-gateway
Als uw organisatie een cloudserviceprovider (CSP) of een onderneming met meerdere tenants is, kunt u RAS-gateway implementeren in de modus met meerdere tenants om netwerkverkeerroutering naar en van virtuele en fysieke netwerken te bieden, inclusief internet.
U kunt RAS-gateway in de modus met meerdere tenants implementeren als een edge-gateway om tenant-klantnetwerkverkeer te routeren naar virtuele tenantnetwerken en -resources.
Wanneer u meerdere exemplaren van RAS Gateway-VM's implementeert die hoge beschikbaarheid en failover bieden, implementeert u een gatewaygroep. In Windows Server 2012 R2 vormen alle gateway-VM's één groep, waardoor een logische scheiding van de gatewayimplementatie een beetje moeilijk is. Windows Server 2012 R2-gateway bood een redundantieimplementatie van 1:1 aan voor de gateway-VM's, wat leidde tot ondergebruik van de beschikbare capaciteit voor site-naar-site-VPN-verbindingen (S2S).
Dit probleem is opgelost in Windows Server 2016, dat meerdere gatewaygroepen biedt, die van verschillende typen kunnen zijn voor logische scheiding. De nieuwe modus van M+N-redundantie maakt een efficiëntere failoverconfiguratie mogelijk.
Zie RAS-gateway voor meer informatie over RAS-gateway.
Overzicht van gatewaygroepen
In Windows Server 2016 kunt u gateways implementeren in een of meer pools.
In de volgende afbeelding ziet u verschillende typen gatewaygroepen die verkeersroutering tussen virtuele netwerken bieden.
Elke pool heeft de volgende eigenschappen.
Elke pool is M+N redundant. Dit betekent dat een 'M' aantal actieve gateway-VM's wordt ondersteund door een 'N' aantal stand-bygateway-VM's. De waarde van N (stand-bygateways) is altijd kleiner dan of gelijk aan M (actieve gateways).
Een pool kan een van de afzonderlijke gatewayfuncties uitvoeren: Internet Key Exchange versie 2 (IKEv2) S2S, Layer 3 (L3) en Generic Routing Encapsulation (GRE) - of de groep kan al deze functies uitvoeren.
U kunt één openbaar IP-adres toewijzen aan alle groepen of aan een subset van groepen. Als u dit doet, vermindert u het aantal openbare IP-adressen dat u moet gebruiken, omdat het mogelijk is om alle tenants verbinding te laten maken met de cloud op één IP-adres. In de onderstaande sectie over hoge beschikbaarheid en taakverdeling wordt beschreven hoe dit werkt.
U kunt gemakkelijk een gateway-pool opschalen of afschalen door gateway-VM's toe te voegen of te verwijderen uit de pool. Het verwijderen of toevoegen van gateways verstoort de services die worden geleverd door een groep niet. U kunt ook toevoegen en verwijderen van de hele groepen van gateways.
Verbindingen van een enkele tenant kunnen worden beëindigd op meerdere pools en meerdere gateways in een pool. Als een tenant echter verbindingen heeft die worden beëindigd in een gatewaygroep van alle typen, kan deze niet worden geabonneerd op andere gatewaygroepen van alle typen of afzonderlijke typen.
Gatewaypools bieden ook de flexibiliteit om aanvullende scenario's mogelijk te maken:
Pools met één tenant: u kunt één pool maken voor gebruik door één tenant.
Als u cloudservices verkoopt via partnerkanalen (wederverkopers), kunt u afzonderlijke groepen maken voor elke wederverkoper.
Meerdere pools kunnen dezelfde gatewayfunctie bieden, maar verschillende capaciteiten. U kunt bijvoorbeeld een gatewaygroep maken die zowel IKEv2 S2S-verbindingen met hoge doorvoer als lage doorvoer ondersteunt.
Overzicht van RAS Gateway-implementatie
In de volgende afbeelding ziet u een typische CSP-implementatie (Cloud Service Provider) van RAS-gateway.
Met dit type implementatie worden de gatewaygroepen geïmplementeerd achter een Software Load Balancer (SLB), waarmee de CSP één openbaar IP-adres voor de hele implementatie kan toewijzen. Meerdere gatewayverbindingen van een tenant kunnen worden beëindigd op meerdere gatewaygroepen - en ook op meerdere gateways binnen een gatewaygroep. Dit wordt geïllustreerd via IKEv2 S2S-verbindingen in het bovenstaande diagram, maar hetzelfde geldt ook voor andere gatewayfuncties, zoals L3- en GRE-gateways.
In de afbeelding is het MT BGP-apparaat een RAS Multitenant-gateway met BGP. Multitenant BGP wordt gebruikt voor dynamische routering. De routering voor een tenant is gecentraliseerd: een single point, de route reflector (RR), verwerkt de BGP-peering voor alle tenantsites. De RR-component zelf wordt over alle gateways in een pool verdeeld. Dit resulteert in een configuratie waarbij de verbindingen van een tenant (gegevenspad) op meerdere gateways worden beëindigd, maar de RR voor de tenant (BGP-peeringpunt - besturingspad) zich op slechts één van de gateways bevindt.
De BGP-router wordt gescheiden in het diagram om dit gecentraliseerde routeringsconcept weer te geven. De implementatie van de gateway BGP biedt ook transitroutering, waardoor de cloud kan fungeren als een transitpunt voor routering tussen twee tenantsites. Deze BGP-mogelijkheden zijn van toepassing op alle gatewayfuncties.
RAS-gatewayintegratie met netwerkcontroller
RAS-gateway is volledig geïntegreerd met netwerkcontroller in Windows Server 2016. Wanneer RAS-gateway en netwerkcontroller worden geïmplementeerd, voert de netwerkcontroller de volgende functies uit.
Implementatie van de gatewaypools
Configuratie van tenantverbindingen op elke gateway
Netwerkverkeer overschakelen naar een standby-gateway wanneer er een uitval van een gateway is.
De volgende secties bevatten gedetailleerde informatie over RAS-gateway en netwerkcontroller.
Inrichting en taakverdeling van gatewayverbindingen (IKEv2, L3 en GRE)
Wanneer een tenant een gatewayverbinding aanvraagt, wordt de aanvraag verzonden naar de netwerkcontroller. Netwerkcontroller is geconfigureerd met informatie over alle gatewaygroepen, inclusief de capaciteit van elke pool en elke gateway in elke pool. Netwerkcontroller selecteert de juiste pool en gateway voor de verbinding. Deze selectie is gebaseerd op de bandbreedtevereiste voor de verbinding. Netwerkcontroller maakt gebruik van een algoritme 'best fit' om efficiënt verbindingen in een pool te kiezen. Het BGP-peeringpunt voor de verbinding wordt op dit moment ook aangewezen als dit de eerste verbinding van de tenant is.
Nadat de netwerkcontroller een RAS-gateway voor de verbinding heeft geselecteerd, richt de netwerkcontroller de benodigde configuratie voor de verbinding op de gateway in. Als de verbinding een IKEv2 S2S-verbinding is, richt de netwerkcontroller ook een NAT-regel (Network Address Translation) in voor de SLB-pool; deze NAT-regel voor de SLB-pool stuurt verbindingsaanvragen van de tenant naar de aangewezen gateway. Tenants worden onderscheiden door het bron-IP-adres, dat naar verwachting uniek is.
Note
L3- en GRE-verbindingen omzeilen de SLB en maken rechtstreeks verbinding met de aangewezen RAS-gateway. Voor deze verbindingen moet de externe eindpuntrouter (of een ander apparaat van derden) correct zijn geconfigureerd om verbinding te maken met de RAS-gateway.
Als BGP-routering is ingeschakeld voor de verbinding, wordt BGP-peering gestart door RAS-gateway en worden routes uitgewisseld tussen on-premises en cloudgateways. De routes die worden geleerd door BGP (of die statisch geconfigureerde routes zijn als BGP niet wordt gebruikt) worden verzonden naar de netwerkcontroller. Netwerkcontroller configureert vervolgens de routes naar de Hyper-V-hosts waarop de tenant-VM's zijn geïnstalleerd. Op dit moment kan tenantverkeer worden doorgestuurd naar de juiste on-premises site. Netwerkcontroller maakt ook gekoppeld Hyper-V netwerkvirtualisatiebeleid dat gatewaylocaties specificeert en geeft deze door aan de Hyper-V hosts.
Hoge beschikbaarheid voor IKEv2 S2S
Een RAS-gateway in een pool bestaat uit zowel verbindingen als BGP-peering van verschillende tenants. Elke pool heeft 'M' actieve gateways en 'N' standby-gateways.
Netwerkcontroller behandelt de uitval van gateways op de volgende manier.
De Netwerkcontroller stuurt voortdurend pings naar de gateways in alle groepen en kan een gateway detecteren die is uitgevallen of defect. Netwerkcontroller kan de volgende typen RAS-gatewayfouten detecteren.
Probleem met RAS-gateway-VM
Fout van de Hyper-V host waarop de RAS-gateway wordt uitgevoerd
RAS-gatewayservice-uitval
Netwerkcontroller slaat de configuratie van alle geïmplementeerde actieve gateways op. De configuratie bestaat uit verbindingsinstellingen en routeringsinstellingen.
Wanneer een gateway mislukt, heeft dit invloed op tenantverbindingen op de gateway, evenals tenantverbindingen die zich op andere gateways bevinden, maar waarvan RR zich op de mislukte gateway bevindt. De storingstijd van de latere verbindingen is minder dan die van de eerdere. Wanneer de netwerkcontroller een mislukte gateway detecteert, worden de volgende taken uitgevoerd.
Hiermee verwijdert u de routes van de betrokken verbindingen van de rekenhosts.
Hiermee verwijdert u het Hyper-V Netwerkvirtualisatiebeleid op deze hosts.
Selecteert een stand-bygateway, converteert deze naar een actieve gateway en configureert de gateway.
Hiermee wijzigt u de NAT-toewijzingen in de SLB-pool om verbindingen met de nieuwe gateway aan te wijzen.
Terwijl de configuratie op de nieuwe actieve gateway wordt weergegeven, worden de IKEv2 S2S-verbindingen en BGP-peering opnieuw tot stand gebracht. De verbindingen en BGP-peering kunnen worden gestart door de cloudgateway of de on-premises gateway. De gateways vernieuwen hun routes en verzenden ze naar de netwerkcontroller. Nadat de netwerkcontroller de nieuwe routes heeft geleerd die door de gateways zijn gedetecteerd, verzendt de netwerkcontroller de routes en het bijbehorende Hyper-V-netwerkvirtualisatiebeleid naar de Hyper-V hosts waar de VM's van de tenants die fouten ondervinden zich bevinden. Deze activiteit van de netwerkcontroller is vergelijkbaar met de omstandigheden van een nieuwe verbindingsinstallatie, alleen op grotere schaal.
Hoge beschikbaarheid voor GRE
Het proces van RAS-gateway-failoverrespons door de netwerkcontroller, inclusief de foutdetectie, het kopiëren van de verbindings- en routeringsconfiguratie naar de standby-gateway, de failover van BGP/statische routering van de getroffen verbindingen (inclusief het terugtrekken en opnieuw instellen van routes op rekenhosts en BGP-herpeering), en de herconfiguratie van Hyper-V-netwerkvirtualisatiebeleid op rekenhosts, is hetzelfde voor GRE-gateways en -verbindingen. De herinrichting van GRE-verbindingen gebeurt echter anders en de oplossing voor hoge beschikbaarheid voor GRE heeft enkele aanvullende vereisten.
Op het moment van de gateway-implementatie wordt aan elke RAS-gateway-VM een DYNAMISCH IP-adres (DIP) toegewezen. Daarnaast wordt aan elke gateway-VM ook een virtueel IP-adres (VIP) toegewezen voor hoge beschikbaarheid van GRE. VIP's worden alleen toegewezen aan gateways in pools die GRE-verbindingen kunnen accepteren en niet aan niet-GRE-pools. De toegewezen VIP's worden geadverteerd naar de top-of-rack switches (TOR) met behulp van BGP, die de VIP's vervolgens verder adverteert in het fysieke cloudnetwerk. Hierdoor zijn de gateways bereikbaar vanaf de externe routers of apparaten van derden waar het andere uiteinde van de GRE-verbinding zich bevindt. Deze BGP-peering verschilt van de BGP-peering op tenantniveau voor de uitwisseling van tenantroutes.
Op het moment dat gre-verbinding wordt ingericht, selecteert de netwerkcontroller een gateway, configureert een GRE-eindpunt op de geselecteerde gateway en retourneert het VIP-adres van de toegewezen gateway. Dit VIP wordt vervolgens geconfigureerd als het doel-GRE-tunneladres op de externe router.
Wanneer een gateway mislukt, kopieert de netwerkcontroller het VIP-adres van de mislukte gateway en andere configuratiegegevens naar de stand-bygateway. Wanneer de stand-bygateway actief wordt, wordt het VIP geadverteerd naar de TOR-switch en verder naar het fysieke netwerk. Externe routers blijven GRE-tunnels verbinden met hetzelfde VIP en de routeringsinfrastructuur zorgt ervoor dat pakketten worden gerouteerd naar de nieuwe actieve gateway.
Hoge beschikbaarheid voor L3 Forwarding Gateways
Een Hyper-V Netwerkvirtualisatie L3-doorstuurgateway is een brug tussen de fysieke infrastructuur in het datacenter en de gevirtualiseerde infrastructuur in de Hyper-V Netwerkvirtualisatiecloud. Op een multitenant L3-doorstuurgateway gebruikt elke tenant een eigen logisch VLAN-gelabeld netwerk voor connectiviteit met het fysieke netwerk van de tenant.
Wanneer een nieuwe tenant een nieuwe L3-gateway maakt, selecteert de Network Controller Gateway Service Manager een beschikbare gateway-VM en configureert een nieuwe tenantinterface met een hoogbeschikbaar IP-adres uit de klantadresruimte (CA) van het logische netwerk van de tenant met VLAN-tagging. Het IP-adres wordt gebruikt als het peer-IP-adres op de externe (fysieke netwerk)-gateway en is de volgende hop om het Hyper-V netwerkvirtualisatienetwerk van de tenant te bereiken.
In tegenstelling tot IPsec- of GRE-netwerkverbindingen leert de TOR-switch het VLAN-netwerk van de tenant niet dynamisch. De routering voor het gelabelde VLAN-netwerk van de tenant moet worden geconfigureerd op de TOR-switch en alle tussenliggende switches en routers tussen fysieke infrastructuur en de gateway om end-to-end-connectiviteit te garanderen. Hieronder volgt een voorbeeld van een CSP Virtual Network-configuratie, zoals wordt weergegeven in de onderstaande afbeelding.
| Network | Subnet | VLAN-id | Standaardgateway |
|---|---|---|---|
| Logisch netwerk contoso L3 | 10.127.134.0/24 | 1001 | 10.127.134.1 |
| Woodgrove L3 Logisch Netwerk | 10.127.134.0/24 | 1002 | 10.127.134.1 |
Hieronder ziet u voorbeelden van tenantgatewayconfiguraties, zoals wordt weergegeven in de onderstaande afbeelding.
| Tenantnaam | IP-adres van L3-gateway | VLAN-id | Ip-adres van peer |
|---|---|---|---|
| Contoso | 10.127.134.50 | 1001 | 10.127.134.55 |
| Woodgrove | 10.127.134.60 | 1002 | 10.127.134.65 |
Hieronder ziet u de afbeelding van deze configuraties in een CSP-datacenter.
De gatewayfouten, foutdetectie en het gatewayfailoverproces in de context van een L3-doorstuurgateway zijn vergelijkbaar met de processen voor IKEv2- en GRE RAS-gateways. De verschillen zijn in de manier waarop de externe IP-adressen worden verwerkt.
Wanneer de status van de gateway-VM beschadigd raakt, selecteert de netwerkcontroller een van de stand-bygateways uit de groep en richt de netwerkverbindingen en routering opnieuw in op de stand-bygateway. Tijdens het verplaatsen van de verbindingen wordt het hoogbeschikbare IP-adres van de CA-ruimte van de L3-gateway ook verplaatst naar de nieuwe gateway-VM, samen met het BGP-IP-adres van de CA-ruimte van de tenant.
Omdat het IP-adres van de L3-peering tijdens de failover naar de nieuwe gateway-VM wordt verplaatst, kan de externe fysieke infrastructuur opnieuw verbinding maken met dit IP-adres en vervolgens de workload Hyper-V Netwerkvirtualisatie bereiken. Voor dynamische BGP-routering, omdat het BGP-IP-adres van de CA-ruimte wordt verplaatst naar de nieuwe gateway-VM, kan de externe BGP-router peering opnieuw tot stand brengen en alle Hyper-V netwerkvirtualisatieroutes opnieuw leren.
Note
U moet de TOR-switches en alle tussenliggende routers afzonderlijk configureren om het logische VLAN-netwerk voor tenantcommunicatie te kunnen gebruiken. Bovendien is L3-failover beperkt tot alleen de racks die op deze manier zijn geconfigureerd. Daarom moet de L3-gatewaygroep zorgvuldig worden geconfigureerd en moet de handmatige configuratie afzonderlijk worden voltooid.