RAS-Gateway: Hohe Verfügbarkeit
Gilt für Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI (Version 21H2 und 20H2)
In diesem Thema erfahren Sie mehr über Hochverfügbarkeitskonfigurationen für das RAS Multitenant Gateway for Software-Defined Networking (SDN).
Dieses Thema enthält folgende Abschnitte:
Übersicht: RAS-Gateway
Wenn es sich bei Ihrer Organisation um einen Cloud-Dienstanbieter (Cloud Service Provider, CSP) oder ein Unternehmen mit mehreren Mandanten handelt, können Sie das RAS-Gateway im mehrinstanzenfähigen Modus bereitstellen, um das Routing von Netzwerkdatenverkehr zwischen virtuellen und physischen Netzwerken inklusive des Internets zu ermöglichen.
Sie können RAS-Gateway im mehrinstanzenfähigen Modus als Edgegateway bereitstellen, um Datenverkehr aus Mandanten-Kundennetzwerken an virtuelle Mandantennetzwerke und -ressourcen weiterzuleiten.
Wenn Sie mehrere Instanzen von RAS-Gateway-VMs bereitstellen, die Hochverfügbarkeit und Failover bieten, stellen Sie einen Gatewaypool bereit. In Windows Server 2012 R2 bildeten alle Gateway-VMs einen einzelnen Pool, was eine logische Trennung der Gatewaybereitstellung etwas erschwerte. Das Windows Server 2012 R2-Gateway bot eine 1:1-Redundanzbereitstellung für die Gateway-VMs, was zu einer Unterauslastung der verfügbaren Kapazität für Site-to-Site-VPN-Verbindungen (S2S) führte.
Dieses Problem wird in Windows Server 2016 behoben, wo mehrere Gatewaypools bereitgestellt werden, die für die logische Trennung unterschiedlichen Typs sein können. Der neue Modus der M+N-Redundanz ermöglicht eine effizientere Failoverkonfiguration.
Weitere Informationen zum RAS-Gateway finden Sie unter RAS-Gateway.
Übersicht zu Gatewaypools
In Windows Server 2016 können Sie Gateways in einem oder mehreren Pools bereitstellen.
Die folgende Abbildung zeigt verschiedene Arten von Gatewaypools, die Datenverkehrsrouting zwischen virtuellen Netzwerken ermöglichen.
Jeder Pool hat die folgenden Eigenschaften.
Jeder Pool ist M+N-redundant. Dies bedeutet, dass eine Anzahl von „M“ aktiven Gateway-VMs von „N“ Standbygateway-VMs gesichert wird. Der Wert von N (Standbygateways) beträgt immer höchstens M (aktive Gateways).
Ein Pool kann jede der einzelnen Gatewayfunktionen ausführen – Internet Key Exchange Version 2 (IKEv2), S2S, Layer 3 (L3) und Generic Routing Encapsulation (GRE) – oder der Pool kann alle diese Funktionen ausführen.
Sie können allen Pools oder einer Teilmenge von Pools eine einzelne öffentliche IP-Adresse zuweisen. Dadurch wird die Anzahl der öffentlichen IP-Adressen, die Sie verwenden müssen, erheblich reduziert, da alle Mandanten über eine einzige IP-Adresse eine Verbindung mit der Cloud herstellen können. Im Abschnitt unten zu Hochverfügbarkeit und Lastenausgleich wird beschrieben, wie dies funktioniert.
Sie können einen Gatewaypool problemlos zentral hoch- oder herunterskalieren, indem Sie virtuelle Gatewaycomputer im Pool hinzufügen oder entfernen. Das Entfernen oder Hinzufügen von Gateways beeinträchtigt nicht die Dienste, die von einem Pool bereitgestellt werden. Sie können auch ganze Pools von Gateways hinzufügen oder entfernen.
Verbindungen eines einzelnen Mandanten können in mehreren Pools und mehrere Gateways in einem Pool enden. Wenn ein Mandant jedoch Verbindungen aufweist, die in einem Gatewaypool des Typs Alle enden, kann er weder andere Gatewaypools vom Typ Alle noch einzelne Typen abonnieren.
Gatewaypools bieten außerdem die Flexibilität, zusätzliche Szenarien zu ermöglichen:
Einzelmandantenpools: Sie können einen einzelnen Pool für die Verwendung durch einen Mandanten erstellen.
Wenn Sie Clouddienste über Partnerkanäle (Wiederverkäufer) verkaufen, können Sie für jeden Wiederverkäufer separate Sets von Pools erstellen.
Mehrere Pools können dieselbe Gatewayfunktion, aber unterschiedliche Kapazitäten bereitstellen. Sie können z. B. einen Gatewaypool erstellen, der sowohl IKEv2-S2S-Verbindungen mit hohem als auch niedrigem Durchsatz unterstützt.
Übersicht: RAS-Gateway-Bereitstellung
Die folgende Abbildung zeigt eine typische CSP-Bereitstellung (Cloud Service Provider, Cloud-Dienstanbieter) von RAS Gateway.
Bei dieser Art der Bereitstellung werden die Gatewaypools hinter einem Software Load Balancer (SLB, Softwarelastenausgleich) bereitgestellt, sodass der CSP eine einzelne öffentliche IP-Adresse für die gesamte Bereitstellung zuweisen kann. Mehrere Gatewayverbindungen eines Mandanten können auf mehreren Gatewaypools enden – und auch auf mehreren Gateways innerhalb eines Pools. Dies wird im obigen Diagramm durch IKEv2 S2S-Verbindungen veranschaulicht, aber dasselbe gilt auch für andere Gatewayfunktionen, z. B. L3- und GRE-Gateways.
In der Abbildung ist das MT BGP-Gerät ein RAS Multitenant Gateway mit BGP. Mehrinstanzenfähiges BGP wird für dynamisches Routing verwendet. Das Routing für einen Mandanten ist zentral: Ein einzelner Punkt, der als Routenreflektor (RR) bezeichnet wird, übernimmt das BGP-Peering für alle Mandantenstandorte. Der RR selbst ist auf alle Gateways in einem Pool verteilt. Dies führt zu einer Konfiguration, bei der die Verbindungen eines Mandanten (Datenpfad) auf mehreren Gateways enden, der RR für den Mandanten (BGP-Peeringpunkt – Kontrollpfad) sich jedoch nur auf einem der Gateways befindet.
Der BGP-Router ist im Diagramm getrennt, um dieses zentrale Routingkonzept darzustellen. Die Gateway-BGP-Implementierung bietet auch Transitrouting, sodass die Cloud als Transitpunkt für das Routing zwischen zwei Mandantenstandorten fungieren kann. Diese BGP-Funktionen gelten für alle Gatewayfunktionen.
Integration des RAS-Gateways in Netzwerkcontroller
Das RAS-Gateway ist vollständig in den Netzwerkcontroller in Windows Server 2016 integriert. Wenn RAS-Gateway und Netzwerkcontroller bereitgestellt werden, führt der Netzwerkcontroller die folgenden Funktionen aus.
Bereitstellung der Gatewaypools
Konfiguration von Mandantenverbindungen auf jedem Gateway
Wechsel des Netzwerkdatenverkehrs zu einem Standbygateway im Falle eines Gatewayausfalls
Die folgenden Abschnitte enthalten ausführliche Informationen zu RAS-Gateway und Netzwerkcontroller.
Bereitstellung und Lastenausgleich von Gatewayverbindungen (IKEv2, L3 und GRE)
Wenn ein Mandant eine Gatewayverbindung anfordert, wird die Anforderung an den Netzwerkcontroller gesendet. Der Netzwerkcontroller wird mit Informationen zu allen Gatewaypools konfiguriert, einschließlich der Kapazität jedes Pools und jedes Gateways in jedem Pool. Der Netzwerkcontroller wählt den richtigen Pool und das richtige Gateway für die Verbindung aus. Diese Auswahl basiert auf der Bandbreitenanforderung für die Verbindung. Der Netzwerkcontroller verwendet einen „Best Fit“-Algorithmus, um Verbindungen effizient in einem Pool auszuwählen. Der BGP-Peeringpunkt für die Verbindung wird zu diesem Zeitpunkt auch festgelegt, wenn dies die erste Verbindung des Mandanten ist.
Nachdem der Netzwerkcontroller ein RAS-Gateway für die Verbindung ausgewählt hat, stellt der Netzwerkcontroller die erforderliche Konfiguration für die Verbindung auf dem Gateway bereit. Wenn es sich bei der Verbindung um eine IKEv2 S2S-Verbindung handelt, stellt der Netzwerkcontroller auch eine NAT-Regel (Network Address Translation) auf dem SLB-Pool bereit. Diese NAT-Regel auf dem SLB-Pool leitet Verbindungsanforderungen vom Mandanten an das angegebene Gateway weiter. Mandanten werden nach der Quell-IP unterschieden, die eindeutig sein soll.
Hinweis
L3- und GRE-Verbindungen umgehen den SLB und stellen eine direkte Verbindung mit dem angegebenen RAS-Gateway her. Diese Verbindungen erfordern, dass der Remoteendpunktrouter (oder ein anderes Gerät eines Drittanbieters) ordnungsgemäß für die Verbindung mit dem RAS-Gateway konfiguriert sein muss.
Wenn BGP-Routing für die Verbindung aktiviert ist, wird das BGP-Peering vom RAS-Gateway initiiert, und Routen werden zwischen lokalen und Cloudgateways ausgetauscht. Die Routen, die vom BGP gelernt werden (oder statisch konfigurierte Routen sind, wenn BGP nicht verwendet wird), werden an den Netzwerkcontroller gesendet. Der Netzwerkcontroller leitet dann die Routen zu den Hyper-V-Hosts hinunter, auf denen die Mandanten-VMs installiert sind. An diesem Punkt kann der Mandantendatenverkehr an den richtigen lokalen Standort weitergeleitet werden. Der Netzwerkcontroller erstellt auch zugeordnete Richtlinien zur Hyper-V-Netzwerkvirtualisierung, die Gatewayspeicherorte angeben, und leitet sie zu den Hyper-V-Hosts hinunter.
Hochverfügbarkeit für IKEv2 S2S
Ein RAS-Gateway in einem Pool besteht aus Verbindungen und BGP-Peering verschiedener Mandanten. Jeder Pool verfügt über „M“ aktive Gateways und „N“ Standbygateways.
Der Netzwerkcontroller behandelt den Ausfall von Gateways wie folgt.
Der Netzwerkcontroller pingt ständig die Gateways in allen Pools und kann ein Gateway erkennen, bei dem ein Fehler aufgetreten oder das ausgefallen ist. Der Netzwerkcontroller kann die folgenden Arten von RAS-Gatewayfehlern erkennen.
RAS-Gateway-VM-Fehler
Fehler des Hyper-V-Hosts, auf dem das RAS-Gateway ausgeführt wird
RAS-Gateway-Dienstfehler
Der Netzwerkcontroller speichert die Konfiguration aller bereitgestellten aktiven Gateways. Die Konfiguration besteht aus Verbindungseinstellungen und Routingeinstellungen.
Wenn bei einem Gateway ein Fehler auftritt, wirkt sich dies auf Mandantenverbindungen im Gateway aus sowie auf Mandantenverbindungen, die sich auf anderen Gateways befinden, deren RR sich jedoch auf dem fehlerhaften Gateway befindet. Die Downtime letzterer Verbindungen ist geringer als die der davorliegenden. Wenn der Netzwerkcontroller ein fehlerhaftes Gateway erkennt, führt er die folgenden Aufgaben aus.
Die Routen der betroffenen Verbindungen werden von den Computehosts entfernt.
Die Richtlinien zur Hyper-V-Netzwerkvirtualisierung auf diesen Hosts werden entfernt.
Ein Standbygateway wird ausgewählt, in ein aktives Gateway konvertiert und das Gateway konfiguriert.
Die NAT-Zuordnungen im SLB-Pool werden geändert, um Verbindungen auf das neue Gateway zu verweisen.
Gleichzeitig werden die IKEv2 S2S-Verbindungen und das BGP-Peering wiederhergestellt, wenn die Konfiguration auf dem neuen aktiven Gateway erfolgt. Die Verbindungen und das BGP-Peering können entweder vom Cloudgateway oder vom lokalen Gateway initiiert werden. Die Gateways aktualisieren ihre Routen und senden sie an den Netzwerkcontroller. Nachdem der Netzwerkcontroller die von den Gateways ermittelten neuen Routen kennengelernt hat, sendet der Netzwerkcontroller die Routen und die zugehörigen Richtlinien zur Hyper-V-Netzwerkvirtualisierung an die Hyper-V-Hosts, auf denen sich die VMs der von dem Fehler betroffenen Mandanten befinden. Diese Aktivität des Netzwerkcontrollers ähnelt dem Umstand einer neuen Verbindungseinrichtung, nur tritt sie in größerem Umfang auf.
Hochverfügbarkeit für GRE
Der Prozess der RAS-Gateway-Failoverantwort des Netzwerkcontrollers – einschließlich Fehlererkennung, Kopieren der Verbindungs- und Routingkonfiguration auf das Standbygateway, Failover von BGP/statischem Routing der betroffenen Verbindungen (einschließlich des Entfernens und erneuten Herstellens von Routen auf Computehosts und BGP-Repeering) und Neukonfiguration von Richtlinien zur Hyper-V-Netzwerkvirtualisierung auf Computehosts – ist für GRE-Gateways und -Verbindungen identisch. Die Wiederherstellung von GRE-Verbindungen erfolgt jedoch anders, und die Hochverfügbarkeitslösung für GRE hat einige zusätzliche Anforderungen.
Zum Zeitpunkt der Gatewaybereitstellung wird jeder RAS-Gateway-VM eine dynamische IP-Adresse (DIP) zugewiesen. Darüber hinaus wird jeder Gateway-VM auch eine virtuelle IP-Adresse (VIP) für GRE-Hochverfügbarkeit zugewiesen. VIPs werden nur Gateways in Pools zugewiesen, die GRE-Verbindungen akzeptieren können, und nicht Nicht-GRE-Pools. Die zugewiesenen VIPs werden mithilfe von BGP den TOR-Switches (Top-of-Rack) angekündigt, wodurch die VIPs dann weiter im physischen Cloudnetzwerk angekündigt werden. So sind die Gateways von den Remoteroutern oder Geräten von Drittanbietern aus erreichbar, auf denen sich das andere Ende der GRE-Verbindung befindet. Dieses BGP-Peering unterscheidet sich vom BGP-Peering auf Mandantenebene für den Austausch von Mandantenrouten.
Zum Zeitpunkt der Bereitstellung der GRE-Verbindung wählt der Netzwerkcontroller ein Gateway aus, konfiguriert einen GRE-Endpunkt auf dem ausgewählten Gateway und gibt die VIP-Adresse des zugewiesenen Gateways zurück. Diese VIP wird dann als GRE-Tunnelzieladresse auf dem Remoterouter konfiguriert.
Wenn ein Gateway ausfällt, kopiert der Netzwerkcontroller die VIP-Adresse des fehlerhaften Gateways und andere Konfigurationsdaten in das Standbygateway. Wenn das Standbygateway aktiv wird, kündigt es die VIP seinem TOR-Switch und weiter im physischen Netzwerk an. Remoterouter verbinden weiterhin GRE-Tunnel mit derselben VIP, und die Routinginfrastruktur stellt sicher, dass Pakete an das neue aktive Gateway weitergeleitet werden.
Hochverfügbarkeit für L3-Weiterleitungsgateways
Ein Hyper-V-Netzwerkvirtualisierung-L3-Weiterleitungsgateway fungiert als Brücke zwischen der physischen Infrastruktur im Rechenzentrum und der virtualisierten Infrastruktur in der Hyper-V-Netzwerkvirtualisierung-Cloud. Auf einem mehrinstanzenfähigen L3-Weiterleitungsgateway verwendet jeder Mandant sein eigenes, mit VLAN gekennzeichnetes logisches Netzwerk für die Konnektivität mit dem physischen Netzwerk des Mandanten.
Wenn ein neuer Mandant ein neues L3-Gateway erstellt, wählt der Dienst-Manager des Netzwerkcontrollergateways eine verfügbare Gateway-VM aus und konfiguriert eine neue Mandantenschnittstelle mit einer hoch verfügbaren Kundenadressraum-IP-Adresse (Customer Address (CA) aus dem mit VLAN gekennzeichneten logischen Netzwerk des Mandanten). Die IP-Adresse wird als Peer-IP-Adresse auf dem Remotegateway (physisches Netzwerk) verwendet und ist der Next-Hop, um das Hyper-V-Netzwerkvirtualisierung-Netzwerk des Mandanten zu erreichen.
Im Gegensatz zu IPsec- oder GRE-Netzwerkverbindungen lernt der TOR-Switch das mit VLAN gekennzeichnete Netzwerk des Mandanten nicht dynamisch. Das Routing für das mit VLAN gekennzeichnete Netzwerk des Mandanten muss auf dem TOR-Switch und allen Switches und Routern zwischen der physischen Infrastruktur und dem Gateway konfiguriert werden, um eine End-to-End-Konnektivität sicherzustellen. Im Folgenden finden Sie ein Beispiel für die CSP-Virtual Network-Konfiguration, wie in der folgenden Abbildung dargestellt.
| Netzwerk | Subnet | VLAN-ID | Standardgateway |
|---|---|---|---|
| Logisches Contoso L3-Netzwerk | 10.127.134.0/24 | 1001 | 10.127.134.1 |
| Logisches Woodgrove L3-Netzwerk | 10.127.134.0/24 | 1002 | 10.127.134.1 |
Im Folgenden finden Sie Beispielkonfigurationen für Mandantengateways, wie in der folgenden Abbildung dargestellt.
| Mandantenname | L3-Gateway-IP-Adresse | VLAN-ID | Peer-IP-Adresse |
|---|---|---|---|
| Contoso | 10.127.134.50 | 1001 | 10.127.134.55 |
| Brandenburg | 10.127.134.60 | 1002 | 10.127.134.65 |
Es folgt eine Abbildung dieser Konfigurationen in einem CSP-Rechenzentrum.
Gatewayfehler, Fehlererkennung und Gatewayfailoverprozess im Kontext eines L3-Weiterleitungsgateways ähneln den Prozessen für IKEv2- und GRE-RAS-Gateways. Die Unterschiede bestehen in der Art und Weise, wie die externen IP-Adressen behandelt werden.
Wenn der Gateway-VM-Zustand fehlerhaft wird, wählt der Netzwerkcontroller eines der Standbygateways aus dem Pool aus und stellt Netzwerkverbindungen und Routing auf dem Standbygateway neu bereit. Beim Verschieben der Verbindungen wird die hoch verfügbare Kundenadressraum-IP-Adresse des L3-Weiterleitungsgateways zusammen mit der Kundenadressraum-BGP-IP-Adresse des Mandanten auch auf die neue Gateway-VM verschoben.
Da die L3-Peering-IP-Adresse während des Failovers auf die neue Gateway-VM verschoben wird, kann die physische Remoteinfrastruktur erneut eine Verbindung mit dieser IP-Adresse herstellen und anschließend die Hyper-V-Netzwerkvirtualisierung-Workload erreichen. Da die Kundenadressraum-BGP-IP-Adresse auf die neue Gateway-VM verschoben wird, kann der Remote-BGP-Router für das dynamische BGP-Routing das Peering wiederherstellen und alle Routen der Hyper-V-Netzwerkvirtualisierung erneut erlernen.
Hinweis
Sie müssen die TOR-Switches und alle Zwischenrouter separat konfigurieren, um das mit VLAN gekennzeichnete logische Netzwerk für die Mandantenkommunikation zu verwenden. Darüber hinaus ist das L3-Failover nur auf die Racks beschränkt, die auf diese Weise konfiguriert sind. Darum muss der L3-Gatewaypool sorgfältig konfiguriert und die manuelle Konfiguration separat abgeschlossen werden.