Planen der Netzwerkintegration für Azure Stack Hub

Dieser Artikel enthält Informationen zur Netzwerkinfrastruktur von Azure Stack Hub, die Sie bei der Entscheidung unterstützen, wie Sie Azure Stack Hub am besten in Ihre bestehende Netzwerkumgebung integrieren können.

Hinweis

Zum Auflösen von externen DNS-Namen von Azure Stack Hub (beispielsweise „www.bing.com“) müssen Sie DNS-Server für die Weiterleitung von DNS-Anforderungen bereitstellen. Weitere Informationen zu DNS-Anforderungen für Azure Stack Hub finden Sie unter Azure Stack Hub-Rechenzentrumsintegration: DNS.

Entwurf des physischen Netzwerks

Die Azure Stack Hub-Lösung erfordert eine zuverlässige und hoch verfügbare physische Infrastruktur, um Vorgänge und Dienste zu unterstützen. Zum Integrieren von Azure Stack Hub in das Netzwerk werden Uplinks von den Top-of-Rack-Switches (ToR) zum nächsten Switch oder Router benötigt, der in dieser Dokumentation als „Grenze“ (Border) bezeichnet wird. Die ToR-Einheiten können per Uplink mit einer Grenze bzw. einem Grenzpaar verbunden werden. Die ToR-Einheit wird mit unserem Automatisierungstool vorkonfiguriert. Zwischen ToR und Grenze wird mindestens eine Verbindung erwartet, wenn BGP-Routing und mindestens zwei Verbindungen (eine pro ToR) zwischen ToR und Grenze verwendet werden und das statische Routing genutzt wird. Für jede Routingoption sind maximal vier Verbindungen möglich. Diese Verbindungen sind auf SFP+- oder SFP28-Medien und Mindestgeschwindigkeiten von 1 GB beschränkt. Angaben zur Verfügbarkeit erhalten Sie bei Ihrem OEM-Hardwarehersteller (Original Equipment Manufacturer). In der folgenden Abbildung ist der empfohlene Entwurf dargestellt:

Bandbreitenzuordnung

Azure Stack Hub wird mithilfe der Windows Server 2019-Failovercluster und Spaces Direct-Technologien erstellt. Ein Teil der physischen Netzwerkkonfiguration von Azure Stack Hub erfolgt so, dass die Trennung von Datenverkehr und Bandbreitengarantien genutzt werden, um sicherzustellen, dass die Spaces Direct-Speicherkommunikation die für die Lösung erforderliche Leistung und Skalierbarkeit erfüllen kann. 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. Zum Abgleich mit den aktuellen, für Windows Server 2019 definierten bewährten Methoden wechselt Azure Stack Hub zur Verwendung einer zusätzlichen Datenverkehrsklasse oder Priorität, um die Kommunikation zwischen den Servern weiter zu trennen und dadurch die Failovercluster-Steuerungskommunikation zu unterstützen. Diese neue Datenverkehrsklassen-Definition wird so konfiguriert, dass 2 % der verfügbaren, physischen Bandbreite reserviert wird. 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 auf den Grenznetzwerkgeräten der Kunden keine Änderungen erforderlich sind. Diese Änderungen bieten eine bessere Resilienz bei der Failoverclusterkommunikation und sollen Situationen vermeiden, in denen die Netzwerkbandbreite vollständig genutzt wird und dadurch Failovercluster-Steuerungsmeldungen unterbrochen werden. Beachten Sie, dass die Failoverclusterkommunikation eine kritische Komponente der Azure Stack Hub-Infrastruktur ist und bei längeren Unterbrechungen zur Instabilität der Spaces Direct-Speicherdienste oder anderer Dienste führen kann, was sich schließlich auf die Stabilität von Mandanten- oder Endbenutzerworkloads auswirkt.

Hinweis

Die beschriebenen Änderungen werden in Release 2008 auf der Hostebene eines Azure Stack Hub-Systems hinzugefügt. Wenden Sie sich an ihren OEM, um die erforderlichen Änderungen an den ToR-Netzwerkswitches vornehmen zu lassen. Diese ToR-Änderung kann entweder vor der Aktualisierung auf Release 2008 oder nach dem Aktualisieren auf 2008 ausgeführt werden. Die Konfigurationsänderung an den ToR-Switches ist erforderlich, um die Failoverclusterkommunikation zu verbessern.

Logische Netzwerke

Logische Netzwerke stellen eine Abstraktion der zugrunde liegenden physischen Netzwerkinfrastruktur dar. Sie dienen zum Organisieren und Vereinfachen von Netzwerkzuweisungen für Hosts, VMs und Dienste. Im Rahmen der Erstellung eines logischen Netzwerks 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.

Die folgende Tabelle zeigt die logischen Netzwerke und die zugehörigen IPv4-Subnetzbereiche, die Sie berücksichtigen müssen:

Logisches Netzwerk	BESCHREIBUNG	Size
Öffentliche VIP	Azure Stack Hub verwendet insgesamt 31 Adressen aus diesem Netzwerk. Der Rest wird von Mandanten-VMs verwendet. Von den 31 Adressen werden acht öffentliche IP-Adressen für einige wenige Azure Stack Hub-Dienste verwendet. Wenn Sie App Service und SQL-Ressourcenanbieter verwenden möchten, werden sieben weitere Adressen verwendet. Die verbleibenden 16 IP-Adressen sind für zukünftige Azure-Dienste reserviert.	/26 (62 Hosts) - /22 (1022 Hosts) Empfohlen = /24 (254 Hosts)
Switchinfrastruktur	Point-to-Point-IP-Adressen für Routingzwecke, dedizierte Switchverwaltungsschnittstellen und Loopbackadressen, die dem Switch zugewiesen sind.	/26
Infrastruktur	Wird für die Kommunikation interner Azure Stack Hub-Komponenten verwendet.	/24
Privat	Wird für das Speichernetzwerk, für private VIPs, für Infrastrukturcontainer und für 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

Der Operator wird über eine Warnung im Portal daran erinnert, das neue PEP-Cmdlet Set-AzsPrivateNetwork auszuführen, um einen neuen privaten IP-Adressbereich der Größe „/20“ hinzuzufügen. Weitere Informationen und Anleitungen zum Auswählen des privaten IP-Adressraums der Größe „/20“ finden Sie im Abschnitt Privates Netzwerk dieses Artikels.

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 ist für die Verbindung aller BMCs (auch Dienstprozessoren genannt) mit dem Verwaltungsnetzwerk bestimmt. Zum Beispiel: iDRAC, iLO, iBMC usw. Für die Kommunikation mit einem BMC-Knoten wird nur ein BMC-Konto verwendet. Falls vorhanden, befindet sich der Hardware Lifecycle Host (HLH) in diesem Netzwerk und kann OEM-spezifische Software für die Hardwarewartung oder -überwachung bereitstellen.

Der HLH hostet auch den virtuellen Bereitstellungscomputer (Deployment VM, DVM). Die DVM wird im Rahmen der Azure Stack Hub-Bereitstellung verwendet und nach Abschluss der Bereitstellung entfernt. In verbundenen Szenarien benötigt der DVM Internetzugriff, um mehrere Komponenten testen und überprüfen sowie darauf zugreifen zu können. Diese Komponenten können sich innerhalb oder außerhalb Ihres Unternehmensnetzwerks befinden (z. B.: NTP, DNS, und Azure). Weitere Informationen zu Konnektivitätsanforderungen finden Sie im NAT-Abschnitt des Artikels zur Azure Stack Hub-Firewallintegration.

Privates Netzwerk

Dieses Netzwerk der Größe „/20“ (4096 IP-Adressen) ist für die Azure Stack Hub-Region privat (es erfolgt also kein Routing über die Grenzswitchgeräte des Azure Stack Hub-Systems hinaus) und in mehrere Subnetze unterteilt. Hier einige Beispiele:

• Speichernetzwerk: Ein Netzwerk der Größe „/25“ (128 Host-IP-Adressen), das zur Unterstützung der Verwendung von „Direkte Speicherplätze“ und SMB-Speicherdatenverkehr (Server Message Block) sowie der Livemigration von virtuellen Computern verwendet wird.
• Internes VIP-Netzwerk (Virtuelle IP-Adresse): Ein Netzwerk des Typs „/25“, das ausschließlich internen VIPs für den softwaregestützten Lastenausgleich vorbehalten ist.
• Containernetzwerk: Ein dediziertes Netzwerk der Größe „/23“ (512 IP-Adressen) für internen Datenverkehr zwischen Containern mit Infrastrukturdiensten.

Das Azure Stack Hub-System erfordert einen zusätzlichen privaten internen IP-Adressraum der Größe „/20“. Dieses Netzwerk ist für das Azure Stack Hub-System privat (es erfolgt also kein Routing über die Grenzswitchgeräte des Azure Stack Hub-Systems hinaus) und kann in mehrere Azure Stack Hub-Systemen innerhalb Ihres Rechenzentrums wiederverwendet werden. Das Netzwerk ist zwar ein privates Netzwerk für Azure Stack, es darf sich aber nicht mit anderen Netzwerken im Rechenzentrum überschneiden. Der private IP-Adressbereich „/20“ ist in mehrere Netzwerke unterteilt, die die Ausführung der Azure Stack Hub-Infrastruktur in Containern ermöglichen. Darüber hinaus ermöglicht dieser neue private IP-Adressbereich auch kontinuierliche Maßnahmen zur Verringerung des erforderlichen routingfähigen IP-Adressraums vor der Bereitstellung. Die Ausführung der Azure Stack Hub-Infrastruktur in Containern dient zur Optimierung der Auslastung sowie zur Verbesserung der Leistung. Darüber hinaus wird der private IP-Adressbereich „/20“ auch verwendet, um kontinuierliche Maßnahmen zur Verringerung des erforderlichen routingfähigen IP-Adressraums vor der Bereitstellung zu ermöglichen. Als Leitfaden für den privaten IP-Adressraum empfehlen wir RFC 1918.

Für Systeme, die vor 1910 bereitgestellt wurden, ist dieses Subnetz der Größe „/20“ ein zusätzliches Netzwerk, das nach dem Aktualisieren auf 1910 in Systemen eingerichtet werden muss. Das zusätzliche Netzwerk muss über das PEP-Cmdlet Set-AzsPrivateNetwork für das System bereitgestellt werden.

Hinweis

Die Eingabe „/20“ ist eine Voraussetzung für das nächste Azure Stack Hub-Update nach 1910. Wenn das nächste Azure Stack Hub-Update nach 1910 veröffentlicht wurde und versucht wird, das Update zu installieren, ist das Update nicht erfolgreich, wenn die Eingabe „/20“ nicht vorgenommen wurde, wie in den folgenden Problembehandlungsschritten beschrieben. Im Administratorportal wird eine Warnung angezeigt, bis die oben erwähnten Problembehandlungsschritte ausgeführt wurden. Informationen zur Nutzung dieses neuen privaten Adressraums finden Sie im Artikel Planen der Netzwerkintegration.

Problembehandlungsschritte: Gehen Sie zur Problembehandlung wie unter Zugreifen auf den privilegierten Endpunkt beschrieben vor. Bereiten Sie einen privaten internen IP-Adressbereich der Größe „/20“ vor, und führen Sie in der PEP-Sitzung das folgende Cmdlet unter Verwendung des folgenden Beispiels aus: . Wenn der Vorgang erfolgreich ausgeführt wurde, erhalten Sie eine Meldung mit dem Hinweis, dass der interne Azs-Netzwerkbereich der Konfiguration hinzugefügt wurde (Azs Internal Network range added to the config). Nach erfolgreichem Abschluss wird die Warnung im Administratorportal geschlossen. Das Azure Stack Hub-System kann nun auf die nächste Version aktualisiert werden.

Azure Stack Hub-Infrastrukturnetzwerk

Dieses Netzwerk des Typs „/24“ ist für interne Azure Stack Hub-Komponenten vorgesehen, damit diese untereinander kommunizieren und Daten austauschen können. Dieses Subnetz kann extern von der Azure Stack Hub-Lösung zu Ihrem Rechenzentrum geroutet werden. Von der Verwendung öffentlicher oder über das Internet routingfähiger IP-Adressen in diesem Subnetz wird abgeraten. Dieses Netzwerk wird für das Border-Gerät angekündigt, die meisten der zugehörigen IP-Adressen werden jedoch durch Zugriffssteuerungslisten (ACLs) geschützt. Die für den Zugriff zulässigen IP-Adressen befinden sich in einem kleinen Bereich, der einem Netzwerk des Typs „/27“ und Hostdiensten wie z. B. dem privilegierten Endpunkt (PEP) und Azure Stack Hub Backup entspricht.

Öffentliches VIP-Netzwerk

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

Herstellen einer Verbindung mit lokalen Netzwerken

Azure Stack Hub verwendet virtuelle Netzwerke für Kundenressourcen wie virtuelle Computer, Lastenausgleiche u. a.

Es gibt verschiedene Möglichkeiten, sich mit Ressourcen innerhalb des virtuellen Netzwerks mit lokalen/Unternehmensressourcen zu verbinden:

• Verwenden öffentlicher IP-Adressen im öffentlichen VIP-Netzwerk
• Verwenden von VNet-Gateway oder virtueller Netzwerkappliance

Wenn ein S2S-VPN-Tunnel zum Verbinden von Ressourcen mit lokalen Netzwerken verwendet wird, kann es vorkommen, dass einer Ressource auch eine öffentliche IP-Adresse zugewiesen wurde und sie nicht mehr über diese öffentliche IP-Adresse erreichbar ist. Wenn die Quelle versucht, auf die öffentliche IP-Adresse zuzugreifen, die sich innerhalb desselben Subnetzbereichs befindet, der in den Routen des lokalen Netzwerkgateways (VNet-Gateways) oder in der benutzerdefinierten Route für Lösungen für virtuelle Netzwerkappliances definiert ist, versucht Azure Stack Hub, den ausgehenden Datenverkehr über den S2S-Tunnel zurück zur Quelle zu leiten, und zwar auf Grundlage der konfigurierten Routingregeln. Der Rückdatenverkehr verwendet die private IP-Adresse der VM und nicht die von der Quelle per NAT übersetzte Adresse als öffentliche IP-Adresse:

Für dieses Problem gibt es zwei Lösungen:

• Routen Sie den Datenverkehr, der an das öffentliche VIP-Netzwerk geleitet wird, zum Internet.
• 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 Netzwerk des Typs „/26“ ist das Subnetz, das die routingfähigen Punkt-zu-Punkt-IP-Subnetze des Typs „/30“ (32 Host-IP-Adressen) und die Loopbacks enthält, die dedizierte Subnetze des Typs „/32“ für die In-band-Switchverwaltung und BGP-Router-ID sind. Dieser IP-Adressbereich muss außerhalb der Azure Stack Hub-Lösung zu Ihrem Rechenzentrum geroutet werden können. Es kann sich sowohl um eine private als auch um eine öffentliche IP-Adresse handeln.

Switchverwaltungsnetzwerk

Dieses Netzwerk des Typs „/29“ (6 Host-IP-Adressen) dient zum Verbinden der Verwaltungsports der Switches. Sie erlaubt einen Out-of-band-Zugriff für Bereitstellung, Verwaltung und Problembehandlung. Sie wird anhand des oben erwähnten Switchinfrastrukturnetzwerks berechnet.

Zugelassene Netzwerke

Auf dem Arbeitsblatt für die Bereitstellung ist ein Feld verfügbar, mit dem der Operator einige Zugriffssteuerungslisten (Access Control Lists, ACLs) ändern kann, um den Zugriff auf Verwaltungsschnittstellen für Netzwerkgeräte sowie auf den Hardwarelebenszyklus-Host (HLH) über einen vertrauenswürdigen Netzwerkbereich des Rechenzentrums zu ermöglichen. Wenn sich die Zugriffssteuerungsliste ändert, kann der Operator seinen Verwaltungs-Jumpbox-VMs innerhalb eines bestimmten Netzwerkbereichs erlauben, auf die Switch-Verwaltungsschnittstelle und das HLH-Betriebssystem zuzugreifen. Der Operator kann Subnetze für diese Liste angeben. Ist die Liste leer, wird der Zugriff standardmäßig verweigert. Dank dieser neuen Funktion ist nach der Bereitstellung kein manueller Eingriff mehr erforderlich, wie unter Ändern bestimmter Einstellungen in der Azure Stack Hub-Switchkonfiguration beschrieben.

Nächste Schritte

• Routing von Datenverkehr für virtuelle Netzwerke
• Weitere Informationen zur Netzwerkplanung: Grenzkonnektivität