Planen der SDN-Infrastruktur in Azure Stack HCI

Abgeschlossen

Ihre ersten Recherchen zu den SDN-Funktionen von Azure Stack HCI haben Ihr Vertrauen darin gestärkt, dass diese zur Verbesserung der Resilienz, Agilität, Sicherheit und Verwaltbarkeit Ihrer Netzwerkinfrastruktur beitragen können. Ihnen ist jedoch klar, dass eine erfolgreiche Bereitstellung von SDN eine sorgfältige Planung erfordert, insbesondere wenn eine Integration in Ihre vorhandene Umgebung gewünscht ist.

Planen der SDN-Bereitstellung

Bevor Sie SDN in einem Azure Stack HCI-Cluster bereitstellen können, müssen Sie sicherstellen, dass Ihre Infrastruktur alle maßgeblichen Voraussetzungen erfüllt, darunter:

  • Azure Stack HCI-Clusterknoten und -Infrastruktur-VMs
  • Netzwerkcontroller
  • Logical networks
  • Routinginfrastruktur
  • Physische Netzwerke

Hinweis

Diese Einheit bietet eine umfassende Übersicht über die SDN-Anforderungen für Azure Stack HCI. Ausführliche und umfassende Informationen zu diesem Thema finden Sie in der Microsoft-Dokumentation, auf die in der Einheit „Zusammenfassung“ dieses Moduls verwiesen wird.

Azure Stack HCI-Clusterknoten und Infrastruktur-VMs

Jeder Knoten des Azure Stack HCI-Clusters muss über mindestens einen physischen Adapter, der Teil eines externen virtuellen Hyper-V Switches ist, mit dem logischen Netzwerk „Verwaltung“ verbunden sein. Alle virtuellen Computer, die SDN-Infrastrukturdienste wie Netzwerkcontroller, RAS-Gateways und softwarebasierte Lastenausgleichsmodule hosten, müssen über das Azure Stack HCI-Betriebssystem verfügen.

Microsoft stellt für physische Hosts und SDN-Infrastruktur-VMs Mindestanforderungen an Compute-, Speicher- und Softwareressourcen. Beachten Sie jedoch, dass die Größen- und Ressourcenanforderungen für Ihre Infrastruktur letztendlich von den Anforderungen an VMs für Mandantenworkloads abhängen. Praktischerweise erleichtert SDN die Skalierung, sodass Sie weitere Instanzen von auf der Virtualisierung von Netzwerkfunktionen basierenden Diensten bedarfsgerecht bereitstellen können. Je nach Hardwarekapazitäten Ihres Azure Stack HCI-Clusters haben Sie auch die Möglichkeit, physische Clusterknoten hinzuzufügen.

Hinweis

SDN wird für Stretched Cluster (mit mehreren Standorten) nicht unterstützt.

Netzwerkcontroller

Um die Bereitstellung des Netzwerkcontrollers in einer AD DS-Umgebung (Active Directory Domain Services) vorzubereiten, müssen eine Kerberos-basierte Authentifizierung und Autorisierung eingerichtet werden. Diese Autorisierung ermöglicht es dem Netzwerkcontroller, alle relevanten Aspekte der SDN-Infrastruktur zu verwalten. Die erforderlichen Berechtigungen werden im Rahmen der Bereitstellung des Netzwerkcontrollers automatisch zugewiesen.

Hinweis

In hoch verfügbaren Bereitstellungen bildet der Netzwerkcontroller einen Cluster mit drei oder mehr VMs, die jeweils auf einem separaten Knoten des Azure Stack HCI-Clusters ausgeführt werden. Alle Instanzen des Netzwerkcontrollers sind mit derselben AD DS-Domäne verbunden.

Logical networks

Um die auf der Virtualisierung von Netzwerkfunktionen basierenden Dienste zu unterstützen, müssen Sie die erforderlichen logischen Netzwerke bereitstellen:

  • Die logischen Netzwerke „Verwaltung“ und „HNV-Anbieter“
  • Die logischen Netzwerke „Software Load Balancer“ und „Gateways“

Die logischen Netzwerke „Verwaltung“ und „HNV-Anbieter“

Alle Knoten des Azure Stack HCI-Clusters müssen Zugriff auf die logischen Netzwerke „Verwaltung“ und „HNV-Anbieter“ haben. Für die Planung von IP-Adressen muss jedem Knoten des Azure Stack HCI-Clusters mindestens eine IP-Adresse im logischen Netzwerk „Verwaltung“ zugewiesen sein. Für das Netzwerk „Verwaltung“ können Sie IP-Adressen statisch oder über DHCP (Dynamic Host Configuration Protocol) zuweisen. Der SDN-Stapel weist automatisch IP-Adressen für das logische Netzwerk „HNV-Anbieter“ für die einzelnen Azure Stack HCI-Clusterknoten zu. Die Adressen stammen aus einem IP-Adresspool, der über den Netzwerkcontroller festgelegt und von diesem verwaltet wird.

Der REST-DNS-Name des Netzwerkcontrollers muss so konfiguriert sein, dass dynamische DNS-Aktualisierungen zulässig sind. Alle Netzwerkcontroller-VMs müssen zum Erstellen und Aktualisieren des DNS-Eintrags berechtigt sein.

Hinweis

Bei der logischen Netzwerkkonfiguration gibt es noch andere Aspekte, die von der Verwendung von Features wie VLANs und Switch Embedded Teaming (SET) abhängen. Weitere Informationen zu diesen Aspekten finden Sie in der Microsoft-Dokumentation, auf die in der Einheit „Zusammenfassung“ dieses Moduls verwiesen wird.

Die logischen Netzwerke „Software Load Balancer“ und „Gateways“

Sie müssen weitere logische Netzwerke bereitstellen, um die Bereitstellung der virtuellen Computer für den Multiplexer des softwarebasierten Lastenausgleichs und für das RAS-Gateway zu ermöglichen. Für diese Komponenten müssen die jeweiligen IP-Präfixe, VLAN-IDs und Gateway-IP-Adressen identifiziert werden.

  • Logisches Netzwerk mit öffentlichen virtuellen IP-Adressen. Dieses Netzwerk dient der Zuweisung virtueller IP-Adressen, die Front-End-IP-Adressen darstellen. Diese IP-Adressen werden von externen Clients für den Zugriff auf Ressourcen innerhalb virtueller Netzwerke verwendet. Beispiele hierfür sind etwa öffentliche Lastenausgleichsmodule oder die virtuelle Front-End-IP-Adresse des Site-to-Site-VPN-Gateways. Der IP-Adressraum muss daher auch außerhalb der SDN-Umgebung routingfähig sein. Sie müssen dieses Netzwerk nicht in Ihren physischen Switches oder Routern vorab konfigurieren oder ihm ein VLAN zuweisen.
  • Logisches Netzwerk mit privaten virtuellen IP-Adressen. Dieses Netzwerk dient der Zuweisung virtueller IP-Adressen, auf die Workloads von Azure Stack HCI-Mandanten zugreifen. Es muss also nicht außerhalb der SDN-Umgebung routingfähig sein. Sie müssen dieses Netzwerk nicht in Ihren physischen Switches oder Routern vorab konfigurieren oder ihm ein VLAN zuweisen.
  • Logisches Netzwerk mit virtuelle IP-Adressen für GRE. Das Netzwerk für virtuelle IP-Adressen für GRE wird ausschließlich verwendet, um virtuelle IP-Adressen zu definieren, die Gateway-VMs für Site-to-Site-GRE-Verbindungen zugewiesen sind. Sie müssen dieses Netzwerk nicht in Ihren physischen Switches oder Routern vorab konfigurieren oder ihm ein VLAN zuweisen.

Routingkonfiguration

Um Konnektivität zwischen logischen Netzwerken mit öffentlichen virtuellen IP-Adressen und externen Clients zu ermöglichen, müssen Sie einem externen BGP-Peer Routinginformationen vom Software Load Balancer-Multiplexer oder RAS-Gateway ankündigen. Tatsächlich müssen Sie einen BGP-Peer auf dem Router konfigurieren, der von der SDN-Infrastruktur verwendet wird, um Routen für die logischen Netzwerke mit virtuellen IP-Adressen zu empfangen, die von den Software Load Balancer-Multiplexern und RAS-Gateways angekündigt werden.

Für Computer, die für die Verbindung mit mehreren Netzwerken konfiguriert sind, z. B. Azure Stack HCI-Clusterknoten und Gateway-VMs, darf nur ein Standardgateway konfiguriert sein. Dieses Gateway muss sich im Netzwerk „Verwaltung“ der Azure Stack HCI-Clusterknoten, Netzwerkcontroller-VMs und Software Load Balancer-Multiplexer-VMs befinden. Bei den Gateway-VMs muss sich dieses Gateway im Netzwerk „HNV-Anbieter“ befinden.

Physische Netzwerke

Für Switches und Router gelten weitere Voraussetzungen. Diese Voraussetzungen tragen der Notwendigkeit Rechnung, bestimmte MTU-Einstellungen (Maximum Transmission Unit), Linksteuerfunktionen, Hochverfügbarkeit und Redundanz sowie Routing- und VLAN-Taggingprotokolle zu unterstützen.

Hinweis

Beispielkonfigurationsdateien für die gängigsten Switchmodelle und -anbieter sind im GitHub-Repository für Microsoft SDN verfügbar.