Planen der Netzwerkintegration für Azure Stack Hub

Dieser Artikel enthält Informationen zur Azure Stack Hub-Netzwerkinfrastruktur, mit denen Sie entscheiden können, wie Sie Azure Stack Hub am besten in Ihre vorhandene Netzwerkumgebung integrieren können.

Hinweis

Um externe DNS-Namen aus Azure Stack Hub (z. B. www.bing.com) aufzulösen, müssen Sie DNS-Server bereitstellen, an die DNS-Anforderungen weitergeleitet werden sollen. Weitere Informationen zu Azure Stack Hub-DNS-Anforderungen finden Sie unter Azure Stack Hub-Rechenzentrumsintegration – DNS-.

Physisches Netzwerkdesign

Die Azure Stack Hub-Lösung erfordert eine robuste und hoch verfügbare physische Infrastruktur, um den Betrieb und die Dienste zu unterstützen. Um Azure Stack Hub in das Netzwerk zu integrieren, erfordert es Uplinks von den Top-of-Rack-Switches (ToR) zum nächstgelegenen Switch oder Router, der in diesem Artikel als Borderbezeichnet wird. Die ToR-Einheiten können per Uplink mit einer Grenze bzw. einem Grenzpaar verbunden werden. Die ToR-Einheit wird mit unserem Automatisierungstool vorkonfiguriert. Sie erwartet mindestens eine Verbindung zwischen ToR und Border bei Verwendung von BGP-Routing und mindestens zwei Verbindungen (eins pro ToR) zwischen ToR und Border bei Verwendung von statischem Routing mit maximal vier Verbindungen bei beiden Routingoptionen. Diese Verbindungen sind auf SFP+- oder SFP28-Medien und mindestens eine GB-Geschwindigkeit beschränkt. Erkundigen Sie sich bei Ihrem Oem-Hardwarehersteller (Original Equipment Manufacturer) nach Verfügbarkeit. Das folgende Diagramm zeigt das empfohlene Design:

Bandbreitenzuweisung

Azure Stack Hub basiert auf Windows Server 2019-Failovercluster- und Spaces Direct-Technologien. Um sicherzustellen, dass die Direkte Speicherkommunikation von Spaces die Leistung und Skalierung der Lösung erfüllen kann, ist ein Teil der physischen Azure Stack Hub-Netzwerkkonfiguration für die Verwendung von Datenverkehrstrennung und Bandbreitengarantien eingerichtet. Die Netzwerkkonfiguration verwendet Datenverkehrsklassen, um die RDMA-basierte Spaces Direct-Kommunikation von derjenigen der Netzwerkauslastung durch die Azure Stack Hub-Infrastruktur und/oder den Mandanten voneinander zu trennen. Um sich an die aktuellen Best Practices für Windows Server 2019 anzupassen, verändert Azure Stack Hub seine Nutzung einer zusätzlichen Verkehrsklasse oder Priorität, um die Server-zu-Server-Kommunikation weiter zu trennen und so die Steuerkommunikation für Failover-Cluster zu unterstützen. Diese neue Datenverkehrsklassendefinition wird so konfiguriert, dass 2 % der verfügbaren physischen Bandbreite reserviert werden. Diese Konfiguration von Datenverkehrsklassen und Bandbreitenreservierung wird durch eine Änderung an den Top-of-Rack (ToR)-Switches der Azure Stack Hub-Lösung und am Host oder an den Servern von Azure Stack Hub erreicht. Beachten Sie, dass Änderungen auf den Kunden-Border-Netzwerkgeräten nicht erforderlich sind. Diese Änderungen bieten eine bessere Resilienz für die Failoverclusterkommunikation und sollten Situationen vermeiden, in denen die Netzwerkbandbreite vollständig genutzt wird und daher Failovercluster-Kontrollmeldungen unterbrochen werden. Beachten Sie, dass die Failoverclusterkommunikation eine wichtige Komponente der Azure Stack Hub-Infrastruktur ist und wenn sie über lange Zeiträume unterbrochen wird, zu Instabilität in den Spaces Direct-Speicherdiensten oder anderen Diensten führen kann, die letztendlich die Stabilität der Mandanten- oder Endbenutzerarbeitsauslastung beeinträchtigen.

Logische Netzwerke

Logische Netzwerke stellen eine Abstraktion der zugrunde liegenden physischen Netzwerkinfrastruktur dar. Sie werden verwendet, um Netzwerkzuweisungen für Hosts, virtuelle Computer (VMs) und Dienste zu organisieren und zu vereinfachen. Als Teil der logischen Netzwerkerstellung werden Netzwerkstandorte erstellt, um die virtuellen lokalen Netzwerke (VLANs), IP-Subnetze und IP-Subnetz-/VLAN-Paare zu definieren, die dem logischen Netzwerk an jedem physischen Standort zugeordnet sind.

In der folgenden Tabelle sind die logischen Netzwerke und die zugeordneten IPv4-Subnetzbereiche aufgeführt, die Sie planen müssen:

Logisches Netzwerk	BESCHREIBUNG	Größe
Öffentliche VIP	Azure Stack Hub verwendet insgesamt 31 Adressen aus diesem Netzwerk, und der Rest wird von Mandanten-VMs verwendet. Aus den 31 Adressen werden 8 öffentliche IP-Adressen für einen kleinen Satz von Azure Stack Hub-Diensten verwendet. Wenn Sie beabsichtigen, App Service und die SQL-Ressourcenanbieter zu verwenden, werden 7 weitere Adressen verwendet. Die verbleibenden 16 IPs sind für zukünftige Azure-Dienste reserviert.	/26 (62 Hosts) - /22 (1022 Hosts) Empfohlen = /24 (254 Hosts)
Switch-Infrastruktur	Point-to-Point-IP-Adressen für Routingzwecke, dedizierte Switchverwaltungsschnittstellen und Loopbackadressen, die dem Switch zugewiesen sind.	/26
Infrastruktur	Wird für interne Azure Stack Hub-Komponenten für die Kommunikation verwendet.	/24
Privat	Wird für das Speichernetzwerk, private VIPs, Infrastrukturcontainer und andere interne Funktionen verwendet. Weitere Informationen finden Sie im Abschnitt Privates Netzwerk in diesem Artikel.	/20
BMC	Für die Kommunikation mit BMCs auf den physischen Hosts.	/26

Hinweis

Eine Benachrichtigung im Portal erinnert den Operator daran, das PEP-Cmdlet Set-AzsPrivateNetwork auszuführen, um einen neuen privaten IP-Bereich "/20" hinzuzufügen. Weitere Informationen und Anleitungen zum Auswählen des privaten IP-Speicherplatzes /20 finden Sie im Abschnitt privates Netzwerk in diesem Artikel.

Netzwerkinfrastruktur

Die Netzwerkinfrastruktur für Azure Stack Hub besteht aus mehreren logischen Netzwerken, die auf den Switches konfiguriert sind. Das folgende Diagramm zeigt diese logischen Netzwerke und wie sie in TOR- (Top-of-Rack), BMC- (Baseboard Management Controller = Baseboard-Verwaltungscontroller) und Grenzswitches (Kundennetzwerk) integriert werden können.

BMC-Netzwerk

Dieses Netzwerk dient zum Verbinden aller Baseboard-Verwaltungscontroller (auch als BMC oder Dienstprozessoren bezeichnet) mit dem Verwaltungsnetzwerk. Beispiele sind: iDRAC, iLO, iBMC usw. Es wird nur ein BMC-Konto verwendet, um mit jedem BMC-Knoten zu kommunizieren. Falls vorhanden, befindet sich der Hardware-Lifecycle-Host (HLH) in diesem Netzwerk und kann OEM-spezifische Software für Hardwarewartung oder -überwachung bereitstellen.

Die HLH hostet auch die Bereitstellungs-VM (DVM). Das DVM wird während der Azure Stack Hub-Bereitstellung verwendet und beim Abschluss der Bereitstellung entfernt. Der DVM erfordert Internetzugriff in verbundenen Bereitstellungsszenarien, um mehrere Komponenten zu testen, zu überprüfen und darauf zuzugreifen. Diese Komponenten können sich innerhalb und außerhalb Ihres Unternehmensnetzwerks befinden (z. B. NTP, DNS und Azure). Weitere Informationen zu Konnektivitätsanforderungen finden Sie im Abschnitt NAT in der Integration der Azure Stack Hub-Firewall.

Privates Netzwerk

Dieses /20 -Netzwerk (4096-IPs) ist privat für die Azure Stack Hub-Region (leitet nicht über die Border Switch-Geräte des Azure Stack Hub-Systems hinaus) und ist in mehrere Subnetze unterteilt, hier einige Beispiele:

• Speichernetzwerk: Ein Netzwerk des Typs „/25“ (128 Host-IP-Adressen), das zur Unterstützung der Verwendung von „Direkte Speicherplätze“ und Server-Message-Block-Speicherdatenverkehr (SMB) sowie der Livemigration von VMs verwendet wird..
• Internes VIP-Netzwerk: Ein Netzwerk des Typs „/25“, das ausschließlich internen virtuellen IPs für den softwaregestützten Lastenausgleich vorbehalten ist.
• Containernetzwerk: Ein /23 (512 IPs)-Netzwerk, das für den internen Datenverkehr zwischen Containern, die Infrastrukturdienste ausführen, reserviert ist.

Das Azure Stack Hub-System erfordert zusätzlichen /20 privaten internen IP-Speicherplatz. Dieses Netzwerk ist privat für das Azure Stack Hub-System (leitet nicht über die Border Switch-Geräte des Azure Stack Hub-Systems hinaus) und kann auf mehreren Azure Stack Hub-Systemen innerhalb Ihres Rechenzentrums wiederverwendet werden. Während das Netzwerk privat für Azure Stack ist, darf es sich nicht mit anderen Netzwerken im Rechenzentrum überlappen. Der private IP-Raum /20 ist in mehrere Netzwerke unterteilt, die das Ausführen der Azure Stack Hub-Infrastruktur auf Containern ermöglichen. Darüber hinaus ermöglicht dieser neue private IP-Raum laufende Anstrengungen, den erforderlichen routingfähigen IP-Speicherplatz vor der Bereitstellung zu reduzieren. Das Ziel der Ausführung der Azure Stack Hub-Infrastruktur in Containern besteht darin, die Auslastung zu optimieren und die Leistung zu verbessern. Darüber hinaus wird der private IP-Speicherplatz /20 auch verwendet, um laufende Anstrengungen zu ermöglichen, die den erforderlichen routingfähigen IP-Speicherplatz vor der Bereitstellung reduzieren. Anleitungen zum privaten IP-Raum finden Sie unter RFC 1918.

Azure Stack Hub-Infrastrukturnetzwerk

Dieses /24-Netzwerk ist für interne Azure Stack Hub-Komponenten vorgesehen, sodass sie daten untereinander kommunizieren und austauschen können. Dieses Subnetz kann extern von der Azure Stack Hub-Lösung auf Ihr Rechenzentrum umleitbar sein. Es wird nicht empfohlen, öffentliche oder routingfähige IP-Adressen in diesem Subnetz zu verwenden. Dieses Netzwerk wird bis zum Rand beworben, aber die meisten IPs sind durch Access Control Lists (ACLs) geschützt. Die für den Zugriff zulässigen IPs befinden sich innerhalb eines kleinen Bereichs, entspricht der Größe eines /27-Netzwerks und Hostdienstes wie dem privilegierten Endpunkt (PEP) und Azure Stack Hub Backup.

Öffentliches VIP-Netzwerk

Das öffentliche VIP-Netzwerk wird dem Netzwerkcontroller in Azure Stack zugewiesen. Es ist kein logisches Netzwerk auf dem Switch. Die SLB verwendet den Adresspool und weist /32-Netzwerke für Mandantenworkloads zu. In der Switch-Routingtabelle werden diese /32-IPs als verfügbare Route über BGP angekündigt. Dieses Netzwerk enthält die extern zugänglichen und öffentlichen IP-Adressen. Die Azure Stack Hub-Infrastruktur reserviert die ersten 31 Adressen aus diesem öffentlichen VIP-Netzwerk, während der Rest von Mandanten-VMs verwendet wird. Die Netzwerkgröße in diesem Subnetz kann von mindestens /26 (64 Hosts) bis zu einem Maximum von /22 (1022 Hosts) reichen. Es wird empfohlen, dass Sie ein /24-Netzwerk planen.

Herstellen einer Verbindung mit lokalen Netzwerken

Azure Stack Hub verwendet virtuelle Netzwerke für Kundenressourcen wie virtuelle Computer, Lastenausgleichsgeräte und andere.

Es gibt mehrere verschiedene Optionen für die Verbindung zwischen Ressourcen innerhalb des virtuellen Netzwerks und lokalen/Unternehmensressourcen:

• Verwenden Sie öffentliche IP-Adressen aus dem öffentlichen VIP-Netzwerk.
• Verwenden von VNet-Gateway oder virtueller Netzwerkappliance

Wenn ein S2S-VPN-Tunnel verwendet wird, um Ressourcen mit oder aus lokalen Netzwerken zu verbinden, tritt möglicherweise ein Szenario auf, in dem eine Ressource auch eine öffentliche IP-Adresse zugewiesen ist und über diese öffentliche IP-Adresse nicht mehr erreichbar ist. Wenn die Quelle versucht, auf die öffentliche IP zuzugreifen und innerhalb des gleichen Subnetzbereichs liegt, der in den lokalen Netzwerkgatewayrouten (Virtual Network Gateway) oder benutzerdefinierten Routen für NVA-Lösungen definiert ist, leitet Azure Stack Hub den ausgehenden Datenverkehr basierend auf den konfigurierten Routingregeln über den S2S-Tunnel zurück zur Quelle. Der Rückdatenverkehr verwendet die private IP-Adresse der VM und nicht die von der Quelle per NAT übersetzte Adresse als öffentliche IP-Adresse:

Es gibt zwei Lösungen für dieses Problem:

• Leiten Sie den Datenverkehr, der an das öffentliche VIP-Netzwerk geleitet wird, zum Internet weiter.
• Fügen Sie ein NAT-Gerät zum Übersetzen aller Subnetz-IP-Adressen per NAT hinzu, die im lokalen Netzwerkgateway definiert sind und zum öffentlichen VIP-Netzwerk geleitet werden.

Switchinfrastrukturnetzwerk

Dieses /26-Netzwerk ist das Subnetz, das die routbaren Punkt-zu-Punkt-IP /30 (zwei Host-IPs) Subnetze und die Loopbacks enthält, die dedizierte /32-Subnetze für die In-Band-Switch-Verwaltung und die BGP-Router-ID sind. Dieser Bereich von IP-Adressen muss außerhalb der Azure Stack Hub-Lösung in Ihr Rechenzentrum umleitbar sein. Sie können private oder öffentliche IPs sein.

Switch-Verwaltungsnetzwerk

Dieses /29 -Netzwerk (sechs Host-IPs) ist für die Verbindung der Verwaltungsports der Switches vorgesehen. Es ermöglicht out-of-Band-Zugriff für Bereitstellung, Verwaltung und Problembehandlung. Es wird aus dem zuvor erwähnten Switch-Infrastrukturnetzwerk berechnet.

Zulässige Netzwerke

Das Bereitstellungsarbeitsblatt verfügt über ein Feld, mit dem der Operator einige Zugriffssteuerungslisten ändern kann, um den Zugriff auf Netzwerkgeräteverwaltungsschnittstellen und den Hardwarelebenszyklus-Host (HLH) aus einem vertrauenswürdigen Rechenzentrumsnetzwerkbereich zu ermöglichen. Mit der Änderung der Zugriffssteuerungsliste kann der Operator seine Verwaltungs-Jumpbox-VMs innerhalb eines bestimmten Netzwerkbereichs für den Zugriff auf die Switch-Verwaltungsschnittstelle und das HLH-Betriebssystem zulassen. Der Operator kann ein oder mehrere Subnetze für diese Liste bereitstellen; wenn sie leer gelassen wird, wird standardmäßig der Zugriff verweigert. Diese neue Funktion ersetzt die Notwendigkeit eines manuellen Eingriffs nach der Bereitstellung, wie es früher in der Beschreibung unter Ändern bestimmter Einstellungen in der Konfiguration Ihres Azure Stack Hub-Switcheserklärt wurde.

Nächste Schritte

• Virtuelles Netzwerkverkehrs-Routing
• Informationen zur Netzwerkplanung: Border Connectivity