Entwurfsüberlegungen für Azure-VMware-Lösung Private Clouds der Generation 2

In diesem Artikel werden wichtige Entwurfsüberlegungen für Azure-VMware-Lösung private Clouds der Generation 2 (Gen 2) beschrieben. Es erläutert die Funktionen, die diese Generation in VMware-basierte private Cloud-Umgebungen bereitstellt, und ermöglicht den Zugriff auf Ihre Anwendungen sowohl von der On-Premises-Infrastruktur als auch von Azure-basierten Ressourcen. Es gibt mehrere Überlegungen, die Sie überprüfen müssen, bevor Sie Ihre private Azure-VMware-Lösung Gen 2-Cloud einrichten. Dieser Artikel enthält Lösungen für Anwendungsfälle, die bei Verwendung des privaten Cloudtyps auftreten können.

Einschränkungen

Die folgenden Funktionen sind in diesem Zeitraum begrenzt. Diese Einschränkungen werden in Zukunft aufgehoben:

• Sie können Ihre Ressourcengruppe, die Ihre private Cloud enthält, nicht löschen. Sie müssen die private Cloud zuerst löschen, bevor Sie die Ressourcengruppe löschen.
• Sie können nur 1 private Cloud pro Azure virtuellen Netzwerk bereitstellen.
• Sie können nur 1 private Cloud pro Ressourcengruppe erstellen. Mehrere private Clouds in einer einzelnen Ressourcengruppe werden nicht unterstützt.
• Die private Cloud und das virtuelle Netzwerk für die private Cloud müssen sich in derselben Ressourcengruppe befinden.
• Sie können Ihre private Cloud nicht von einer Ressourcengruppe in eine andere verschieben , nachdem die private Cloud erstellt wurde.
• Sie können Ihre private Cloud nicht von einem Mandanten in einen anderen verschieben , nachdem die private Cloud erstellt wurde.
• Wenn Sie ExpressRoute FastPath oder Global Virtual Network Peering für Ihre AVS Private Cloud benötigen, erstellen Sie einen Supportfall über das Azure Portal.
• Dienstendpunkte - Die direkte Konnektivität von Azure-VMware-Lösung-Workloads wird nicht unterstützt.
• Private Endpunkte mit globalem Peering zwischen Regionen, die mit Azure-VMware-Lösung verbunden sind, werden nicht unterstützt.
• vCloud Director mit privaten Endpunkten wird unterstützt. vCloud Director mit öffentlichen Endpunkten wird jedoch nicht unterstützt.
• vSAN Stretched Clusters wird nicht unterstützt.
• Die Konfiguration des Internets über die öffentliche IP bis zum VMware NSX Microsoft Edge wird nicht unterstützt. Die unterstützten Internetoptionen finden Sie unter Internetkonnektivitätsoptionen.
• Während ungeplanter Wartungsarbeiten – beispielsweise durch einen Ausfall der Hosthardware – auf einem beliebigen der ersten vier Hosts in Ihrem Software Defined Data Center (SDDC) kann es bei einigen Workloads zu einer vorübergehenden Unterbrechung der North-South-Netzwerkverbindung kommen, die bis zu 30 Sekunden andauern kann. North-South Konnektivität bezieht sich auf den Datenverkehr zwischen Ihren AVS VMware-Workloads und externen Endpunkten über den NSX-T Tier-0 (T0)-Edge hinaus, z. B. Azure Dienste oder lokale Umgebungen. Diese Einschränkung wurde in bestimmten Azure Regionen entfernt. Vergewissern Sie sich, ob Ihre Region von dieser Einschränkung betroffen ist, indem Sie Azure Support überprüfen.  
• Netzwerksicherheitsgruppen , die dem virtuellen Netzwerk des privaten Cloudhosts zugeordnet sind, müssen in derselben Ressourcengruppe wie die private Cloud und das virtuelle Netzwerk erstellt werden.
• Ressourcengruppenübergreifende und abonnementübergreifende Verweise von virtuellen Netzwerken von Kunden auf das virtuelle Netzwerk von Azure-VMware-Lösung werden standardmäßig nicht unterstützt. Dazu gehören Ressourcentypen wie benutzerdefinierte Routen (User-Definied Routes, UDRs), DDoS-Schutzpläne und andere verknüpfte Netzwerkressourcen. Wenn ein virtuelles Kundennetzwerk mit einer dieser Referenzen verknüpft ist, die sich in einer anderen Ressourcengruppe oder einem anderen Abonnement als dem Azure-VMware-Lösung-virtuellen Netzwerk befinden, kann die Netzwerkprogrammierung (z. B. NSX-Segmentverteilung) fehlschlagen. Um Probleme zu vermeiden, sollten Kunden sicherstellen, dass das Azure-VMware-Lösung virtuelles Netzwerk nicht mit Ressourcen in einer anderen Ressourcengruppe oder einem anderen Abonnement verbunden ist. Bevor Sie fortfahren, entfernen Sie solche Verbindungen, z. B. DDoS-Schutzpläne, aus dem virtuellen Netzwerk.
  • Um Ihren ressourcengruppenübergreifenden Verweis beizubehalten, erstellen Sie auf Ebene Ihrer ressourcengruppenübergreifenden Gruppe oder Ihres Abonnements eine Rollenzuweisung, und weisen Sie der „AzS VIS Prod App“ die Rolle „AVS on Fleet VIS Role“ zu. Die Rollenzuweisung ermöglicht es Ihnen, den Verweis zu verwenden und sicherzustellen, dass er korrekt auf Ihre Azure-VMware-Lösung-Private-Cloud angewendet wird.
• Die private Cloud Bereitstellungen der Generation 2 können fehlschlagen, wenn Azure Richtlinien strenge Regeln für Netzwerksicherheitsgruppen oder Routingtabellen (z. B. bestimmte Benennungskonventionen) erzwingen. Diese Richtlinieneinschränkungen können die Erstellung der erforderlichen Azure-VMware-Lösung Netzwerksicherheitsgruppe und Routentabelle während der Bereitstellung blockieren. Sie müssen diese Richtlinien aus dem Azure-VMware-Lösung virtuellen Netzwerk entfernen, bevor Sie Ihre private Cloud bereitstellen. Sobald Ihre private Cloud bereitgestellt wurde, können diese Richtlinien wieder zu Ihrer Azure-VMware-Lösung privaten Cloud hinzugefügt werden.
• Wenn Sie Privates DNS für Ihre private cloud der Azure-VMware-Lösung Gen 2 verwenden, wird Custom DNS im virtuellen Netzwerk, in dem eine private Cloud der Azure-VMware-Lösung Gen 2 bereitgestellt wird, nicht unterstützt. Benutzerdefiniertes DNS unterbricht Lebenszyklusvorgänge wie Skalierung, Upgrades und Patchen.
• Wenn Sie Ihre private Cloud löschen und einige von Azure-VMware-Lösung erstellte Ressourcen nicht entfernt werden, können Sie den Löschvorgang der privaten Cloud von Azure-VMware-Lösung mithilfe der Azure CLI erneut versuchen.
• Azure-VMware-Lösung Gen 2 verwendet einen HTTP-Proxy, um zwischen Kunden- und Verwaltungsnetzwerkdatenverkehr zu unterscheiden. Bestimmte VMware-Clouddienstendpunkte folgen möglicherweise nicht demselben Netzwerkpfad oder Proxyregeln wie allgemeiner vCenter-verwalteter Datenverkehr. Beispiele sind: "scapi.vmware" und "apigw.vmware". Der VAMI-Proxy steuert den allgemeinen ausgehenden Internetzugriff der vCenter Server Appliance (VCSA), aber nicht alle Interaktionen des Dienstendpunkts über diesen Proxy. Einige Interaktionen stammen direkt aus dem Browser des Benutzers oder aus Integrationskomponenten, die stattdessen den Proxyeinstellungen der Arbeitsstation folgen oder Verbindungen unabhängig initiieren. Daher kann der Datenverkehr zu VMware-Clouddienstendpunkten den VCSA-Proxy vollständig umgehen.
• HCX RAV- und Bulk-Migrationen auf Gen 2 können aufgrund von Verzögerungen während der Phasen der Basissynchronisierung und Onlinesynchronisierung eine geringere Leistung aufweisen. Kunden sollten längere Migrationsfenster planen und die Zeitabläufe entsprechend in Wellen einteilen. Für geeignete Workloads bietet vMotion eine schnellere Option mit geringem Aufwand, wenn Host- und Netzwerkbedingungen zulassen.
• Virtueller Hub (virtual WAN)-Peering: Um eine Peeringverbindung zwischen einem Gen-2-VNet und einem virtuellen Hub (virtual WAN) herzustellen, muss sich der virtuelle Hub in derselben Region wie das Gen-2-VNet befinden. Wenn Sie mit einem virtuellen Hub in einer anderen Region peeren müssen, müssen Sie über das Azure Portal einen Supportfall erstellen.
• /32-Routenziel aus einem gekoppelten virtuellen Netzwerk (VNET): Wenn Sie /32-Routen von NSX ankündigen (z. B. HCX-MON-Routen oder DNS-Weiterleitungsrouten) und Zugriff auf dieses /32-Ziel aus einem gekoppelten virtuellen Netzwerk benötigen, müssen Sie im Azure-Portal eine Supportanfrage öffnen. Die Verbindung mit dem /32-Ziel funktioniert ordnungsgemäß innerhalb des lokalen VNET.
• VNET Peer Sync-Subnetzankündigung und Zuordnung zu Azure Route Tables (UDRs) – Azure-VMware-Lösung Gen 2 nutzt zwei interne Architekturen. Die aktuelle Architektur synchronisiert sowohl bestimmte Subnetze als auch den übergeordneten Azure-Adressraum für NSX-Segment- oder Subnetzrouten mit gekoppelten virtuellen Azure-Netzwerken. Daher müssen Sie bei der aktuellen Architektur von Gen 2 möglicherweise Azure-Routentabellen (UDR) mit spezifischeren Subnetzrouten für NSX-Segmente konfigurieren, anstatt allgemeine Adressraumrouten für Azure-VMware-Lösung Workloadsegmente zu verwenden.

Nicht unterstützte Integrationen

Die folgenden Integrationen von Erst- und Drittanbietern sind nicht verfügbar:

• Zerto DR

Delegierte Subnetze und Netzwerksicherheitsgruppen für Gen 2

Wenn eine Azure-VMware-Lösung (AVS) Gen 2 private Cloud bereitgestellt wird, erstellt Azure automatisch mehrere delegierte Subnetze innerhalb des virtuellen Hostnetzwerks der privaten Cloud. Diese Subnetze werden verwendet, um die Verwaltungskomponenten der privaten Cloud zu isolieren und zu schützen.

Kunden können den Zugriff auf diese Subnetze mithilfe von Netzwerksicherheitsgruppen (Network Security Groups, NSGs) verwalten, die im Azure-Portal oder über Azure CLI/PowerShell sichtbar sind. Neben vom Kunden verwalteten NSGs wendet AVS zusätzliche systemverwaltete NSGs auf kritische Verwaltungsschnittstellen an. Diese vom System verwalteten NSGs sind von Kunden nicht sichtbar oder bearbeitbar und vorhanden, um sicherzustellen, dass die private Cloud standardmäßig sicher bleibt.

Im Rahmen des Standardsicherheitsstatus:

• Der Internetzugriff ist für die private Cloud deaktiviert, es sei denn, der Kunde aktiviert ihn explizit.
• Nur erforderlicher Verwaltungsdatenverkehr darf Plattformdienste erreichen.

Dieses Design sorgt dafür, dass die AVS-Umgebung standardmäßig sicher und getrennt ist, während Kunden den Netzwerkzugriff weiterhin verwalten und anpassen können, um ihren Anforderungen gerecht zu werden.

Überlegungen zu Routing und Subnetz

Azure-VMware-Lösung private Clouds der Generation 2 bieten eine private VMware-Cloudumgebung, auf die Benutzer und Anwendungen von lokalen und Azure basierten Umgebungen oder Ressourcen zugreifen können. Konnektivität wird über standard Azure Networking bereitgestellt. Zum Aktivieren dieser Dienste sind bestimmte Netzwerkadressbereiche und Firewallports erforderlich. In diesem Abschnitt können Sie Ihr Netzwerk so konfigurieren, dass es mit Azure-VMware-Lösung funktioniert.

Die private Cloud stellt eine Verbindung mit Ihrem Azure-virtuellen Netzwerk mithilfe von standardmäßiger Azure-Netzwerkfunktionen her. Azure-VMware-Lösung Gen 2 Private Clouds erfordern einen minimalen /22 CIDR-Netzwerkadressblock für Subnetze. Dieses Netzwerk ergänzt Ihre lokalen Netzwerke. Daher sollte sich der Adressblock nicht mit Adressblöcken überschneiden, die in anderen virtuellen Netzwerken in Ihrem Abonnement und Ihren lokalen Netzwerken verwendet werden. Verwaltungs-, vMotion- und Replikationsnetzwerke werden automatisch innerhalb dieses Adressblocks als Subnetze in Ihrem virtuellen Netzwerk bereitgestellt.

Vermeiden Sie die Verwendung des folgenden IP-Schemas, das für die VMware TOOLS-Verwendung reserviert ist:

• 169.254.0.0/24: für das interne Transitnetz
• 169.254.2.0/23 - wird für das Inter-VRF-Transitnetzwerk verwendet
• 100.64.0.0/16: zum internen Verbinden von T1- und T0-Gateways
• 100.73.x.x – verwendet vom Verwaltungsnetzwerk von Microsoft

Beispiel für /22 CIDR-Netzwerkadressblock 10.31.0.0/22 ist in die folgenden Subnetze unterteilt:

Routenprogrammierung von NSX in Azure Virtual Network

Azure-VMware-Lösung Gen-2 NSX-Routen werden unter Verwendung des Adressraums in Azure integriert und dem vom System erstellten Subnetz „avs-network-infra-gw“ als sekundäre IPs zugewiesen, wodurch eine nahtlose Konnektivität zwischen Azure und AVS-Kundenworkloads ermöglicht wird. Wenn NSX Tier-0 basierend auf Benutzereinstellungen eine Route bewirbt – beispielsweise durch das Erstellen von Segmenten, das Hinzufügen statischer Routen oder die Verwendung virtueller HCX MON-Maschinen –, überprüft die Azure-VMware-Lösung-Steuerungsebene, ob das Routenpräfix im Adressraum des virtuellen Netzwerks vorhanden ist. Andernfalls wird der Adressraum erstellt und das Routenpräfix dem Subnetz „avs-network-infra-gw“ als sekundäre IP-Adressen hinzugefügt. Bei angekündigten /32 Routen der Stufe 0, z. B. HCX MON-Routen, werden sekundäre IPs nicht festgelegt, die Datenebene ist jedoch intern konfiguriert, um die Konnektivität mit /32 Zielen auf Azure-VMware-Lösung sicherzustellen.

Neben der Aktualisierung des Adressraums und der Subnetze für NSX-Routen gibt es interne Implementierungen, die Kunden kennen sollten, insbesondere im Hinblick auf den unterstützten Skalierungsumfang, wenn Subnetzmasken mit geringerer Präfixlänge verwendet werden. Weitere Informationen zum Skalierungsaspekt finden Sie unter Route-Architektur für Azure-VMware-Lösung Gen 2

Überlegungen zur Azure-Routingtabelle (UDR)-Zuordnung

Azure-VMware-Lösung Gen-2 umfasst zwei interne Architekturen mit leichter Variation. Einige der ersten privaten Gen-2-Clouds verwenden die anfängliche interne Architektur. Diese werden durch geplante Wartung, koordiniert mit dem Kunden, auf die aktuelle Architektur aktualisiert. Im Vergleich zur anfänglichen Architektur gibt es jedoch Veränderungen im Verhalten mit der aktuellen Architektur, die sich auf bestimmte Überlegungen zum Netzwerkentwurf auswirken können, wie unten beschrieben.

Erste Private Cloud der Generation 2:

• Azure VNET verfügt über zwei Basis-Gateway-Subnetze mit dem Namen „avs-nsx-gw“ und nicht über das Subnetz „avs-network-infra-gw“ wie in der aktuellen Architektur.
• Alle AVS NSX-Segmentsubnetze werden im Subnetz „avs-nsx-gw“ als zusätzliche IPv4-Adressen konfiguriert, um Azure mit NSX-Workloads zu verbinden.
• Die Routentabelle (UDR) oder die Azure NSG für den Datenverkehr von AVS zu Azure VNet und darüber hinaus (z. B. in die lokale Umgebung) müssen auf das Subnetz „avs-nsx-gw“ angewendet werden.

Aktuelle Private Cloud der Generation 2:

Achten Sie darauf, diese Änderung des Verhaltens zu beachten.

• Das Azure-VNET würde zusätzlich zum Namenpräfix „avs-network-infra-gw“ auch zwei Basis-Gateway-Subnetze mit dem Namen „avs-nsx-gw“ aufweisen, wie in der ursprünglichen Architektur.
• Alle Subnetze der AVS-NSX-Segmente werden nun unter diesem Subnetz als sekundäre IPv4-Adresse konfiguriert, um Azure mit NSX-Workloads zu verbinden. Dadurch wird die Netzwerkkonnektivität des Kunden nicht geändert.
• VNET-Peering übermittelt sowohl den Adressraum als auch die Subnetze an das gekoppelte VNET; dies unterscheidet sich von der ursprünglichen Architektur bzw. der nativen Azure-VNET-Synchronisierung, bei der nur der Adressraum synchronisiert wird.

Entwurfsüberlegungen aufgrund von Änderungen an der internen Architektur von Gen-2

• Kunden beobachten aufgrund einer Änderung im Synchronisierungsverhalten von VNET-Peerings zusätzliche effektive Routen für AVS-Subnetze innerhalb des gekoppelten VNET.
• Wenn ein Kunde eine Azure-Routingtabelle (UDR) verwendet, um Datenverkehr vom lokalen Netzwerk über eine Firewall oder eine virtuelle Netzwerkappliance zu AVS zu leiten, sollte der Kunde die UDR so aktualisieren, dass spezifische NSX-Subnetzrouten anstelle des zuvor verwendeten allgemeinen Supernetz-Adressbereichs verwendet werden. Dies ist erforderlich, um zu verhindern, dass für AVS bestimmter Datenverkehr über spezifischere VNET-Subnetzrouten geleitet wird und dadurch die vorgesehene Firewall umgeht, bedingt durch das Longest-Prefix-Match-Verhalten des Azure-Routings. Andernfalls kann dies zu asymmetrischen Routing führen, was zu Verbindungsproblemen führen kann.
• Die Routentabelle (UDR) oder Azure NSG für Datenverkehr von AVS zu Azure-VNET und darüber hinaus (z. B. lokal) würde jedoch weiterhin auf die Subnetze „avs-nsx-gw“ angewendet, nicht auf „avs-network-infra-gw“. Kunden sollten die Routentabelle (UDR) nicht für das Subnetz „avs-network-infra-gw“ verwenden, auch wenn darauf NSX-Segmentsubnetze als sekundäre IP-Adressen konfiguriert sind.

Nächste Schritte

• Beginnen Sie mit der Konfiguration Ihres Azure-VMware-Lösung-Dienstprinzipals (Voraussetzung). Informationen dazu finden Sie im Schnellstart Aktivieren des Azure-VMware-Lösung-Dienstprinzipals.

• Folgen Sie einem Lernprogramm für Creating an Azure VMware Gen 2 Private Cloud