Freigeben über

Entwurfsüberlegungen für Azure VMware Solution Private Clouds der Generation 2

In diesem Artikel werden wichtige Entwurfsüberlegungen für Azure VMware Solution 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 Solution Gen 2-Cloud einrichten. Dieser Artikel enthält Lösungen für Anwendungsfälle, die bei Verwendung des privaten Cloudtyps auftreten können.

Hinweis

Generation 2 ist in bestimmten Azure öffentlichen Regionen verfügbar. Wenden Sie sich an Ihr Microsoft-Kontoteam oder Microsoft Support, um die Abdeckung zu bestätigen.

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.
  • Service-Endpunkte direkte Konnektivität von Azure VMware Solution Workloads wird nicht unterstützt.
  • Private-Endpunkte, wenn global verbunden zwischen Regionen, die mit der Azure VMware Solution 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.
  • Public IP bis zu VMware NSX Microsoft Edge für die Internetkonfiguration wird nicht unterstützt. Die unterstützten Internetoptionen finden Sie unter Internetkonnektivitätsoptionen.
  • Während der ungeplanten Wartung – etwa bei einem Hosthardwarefehler – auf einem der ersten vier Hosts in Ihrem SDDC kann es zu einer vorübergehenden Unterbrechung der Nord-Süd-Netzwerkkonnektivität bei einigen Workloads kommen, die bis zu 30 Sekunden dauern. 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. Wenden Sie sich an Azure Support, um festzustellen, ob Ihre Region von dieser Einschränkung betroffen ist.
  • 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.
  • Verweise über Ressourcengruppen und Abonnements hinweg von Kundennetzwerken zu dem virtuellen Azure VMware Solution-Netzwerk 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 Solution-virtuellen Netzwerk befinden, kann die Netzwerkprogrammierung (z. B. NSX-Segmentverteilung) fehlschlagen. Um Probleme zu vermeiden, müssen Kunden sicherstellen, dass das Azure VMware Solution virtuelles Netzwerk nicht mit Ressourcen in einer anderen Ressourcengruppe oder einem anderen Abonnement verknüpft ist und diese Ressourcen (z. B. DDoS-Schutzpläne) vom virtuellen Netzwerk trennen, bevor Sie fortfahren.
    • Um den ressourcenübergreifenden Gruppenverweis aufrechtzuerhalten, erstellen Sie eine Rollenzuweisung aus Ihrer ressourcenübergreifenden Gruppe oder Ihrem Abonnement, und weisen Sie der "AzS VIS Prod App" die "AVS on Fleet VIS Role" zu. Mit der Rollenzuweisung können Sie eine Referenz verwenden und Ihre Referenz ordnungsgemäß auf Ihre Private Cloud der Azure VMware-Lösung anwenden lassen.
  • 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 Solution Netzwerksicherheitsgruppe und Routentabelle während der Bereitstellung blockieren. Sie müssen diese Richtlinien aus dem Azure VMware Solution virtuellen Netzwerk entfernen, bevor Sie Ihre private Cloud bereitstellen. Sobald Ihre private Cloud bereitgestellt wurde, können diese Richtlinien wieder zu Ihrer Azure VMware Solution privaten Cloud hinzugefügt werden.
  • Wenn Sie Private DNS für Ihre private cloud der Azure VMware Solution Gen 2 verwenden, wird Custom DNS im virtuellen Netzwerk, in dem eine private cloud der Azure VMware Solution Gen 2 bereitgestellt wird, nicht unterstützt. Benutzerdefiniertes DNS unterbricht Lebenszyklusvorgänge wie Skalierung, Upgrades und Patchen.
  • Wenn Sie löschen Ihre private Cloud sind, und einige von der Azure VMware Solution erstellte Ressourcen nicht entfernt werden, können Sie das Löschen der privaten Azure VMware Solution-Cloud mithilfe der Azure CLI wiederholen.
  • Azure VMware Solution 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 mit Dienstendpunkten erfolgen ü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 Base Sync- und Online Sync-Phasen eine deutlich langsamere 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.

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 Solution (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.

Hinweis

Möglicherweise wird im Azure Portal eine Warnung angezeigt, die angibt, dass bestimmte Ports für das Internet verfügbar gemacht werden. Dies geschieht, da das Portal nur die vom Kunden sichtbare Netzwerksicherheitsgruppe (NSG)-Konfiguration auswertet. Azure VMware Solution wendet jedoch auch zusätzliche vom System verwaltete Netzwerksicherheitsgruppen an, die im Portal nicht sichtbar sind. Diese vom System verwalteten Netzwerksicherheitsgruppen blockieren eingehenden Datenverkehr, es sei denn, der Zugriff wurde über Azure VMware Solution Konfiguration explizit aktiviert.

Mit diesem Design wird sichergestellt, dass die AVS-Umgebung isoliert und sicher ist und gleichzeitig kunden das Steuern und Anpassen des Netzwerkzugriffs basierend auf ihren spezifischen Anforderungen ermöglicht.

Überlegungen zu Routing und Subnetz

Azure VMware Solution 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 Solution funktioniert.

Die private Cloud stellt eine Verbindung mit Ihrem Azure-virtuellen Netzwerk mithilfe von standardmäßiger Azure-Netzwerkfunktionen her. Azure VMware Solution 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.

Hinweis

Zulässige Bereiche für Ihren Adressblock sind die privaten RFC 1918-Adressräume (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) mit Ausnahme von 172.17.0.0/16. Das Replikationsnetzwerk gilt nicht für AV64-Knoten und ist für die allgemeine Einstellung zu einem zukünftigen Datum vorgesehen.

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:

Netzwerknutzung Subnetz Beschreibung Beispiel
VMware NSX-Netzwerk /27 NSX Manager Netzwerk. 10.31.0.0/27
vCSA-Netzwerk /27 vCenter Server-Netzwerk. 10.31.0.32/27
avs-mgmt /27 Die Verwaltungsappliances (vCenter Server, NSX-Manager und HCX Cloud Manager) befinden sich hinter dem Subnetz "avs-mgmt", das als sekundäre IP-Bereiche in diesem Subnetz konfiguriert sind. Möglicherweise müssen Sie die Routentabellen anpassen, die diesem Subnetz zugeordnet sind, wenn Ihr Netzwerkdatenverkehr für Ihre Verwaltungsgeräte eine Route über einen NVA oder eine Firewall durchführen muss. 10.31.0.64/27
avs-vnet-sync /27 Wird von Azure VMware Solution Gen 2 verwendet, um die in VMware NSX erstellten Routen in das virtuelle Netzwerk einzutragen. 10.31.0.96/27
avs-services /27 Wird für Azure VMware Solution Gen 2-Anbieterdienste verwendet. Wird auch zum Konfigurieren der privaten DNS-Auflösung für Ihre private Cloud verwendet. 10.31.0.224/27
avs-nsx-gw, avs-nsx-gw-1 /27 Subnetze von jedem der T0-Gateways pro Edge Diese Subnetze werden verwendet, um VMware NSX-Netzwerksegmente als sekundäre IP-Adressen einzurichten. 10.31.0.128/27, 10.31.0.160/27
esx-mgmt-vmk1 /25 vmk1 ist die Verwaltungsschnittstelle, die von Kunden für den Zugriff auf den Host verwendet wird. IPs aus der vmk1-Schnittstelle stammen aus diesen Subnetzen. Der gesamte vmk1-Datenverkehr für alle Hosts stammt aus diesem Subnetzbereich. 10.31.1.0/25
esx-vmotion-vmk2 /25 vMotion VMkernel-Schnittstellen. 10.31.1.128/25
esx-vsan-vmk3 /25 vSAN VMkernel-Schnittstellen und Knotenkommunikation. 10.31.2.0/25
avs-network-infra-gw /26 ** Wird von dem Azure VMware Solution Management für die Programmierung von NSX-Segmenten verwendet. Kunden müssen dieses Subnetz nicht ändern, da es nur für Azure VMware Solution Infrastruktur verwendet wird. Sie sehen, dass Ihre NSX Netzwerksegmente unter diesem Subnetz als sekundäre IP-Präfixe erstellt werden. Die Workload-Segmente leiten jedoch weiterhin durch die Subnetze avs-nsx-gw und avs-nsx-gw-1 weiter. 10.31.2.128/26
Reserviert /27 Reservierter Platz. 10.31.0.128/27
Reserviert /27 Reservierter Platz. 10.31.0.192/27

Hinweis

Für Azure VMware Solution Gen 2-Bereitstellungen müssen Kunden nun zwei zusätzliche /24-Subnetze für die HCX-Verwaltung und -Uplink zuweisen, zusätzlich zu dem während der SDDC-Bereitstellung eingegebenen /22-Subnetz. In AVS Gen 2 sind nur die HCX mgmt- und HCX-Uplink-Subnetze erforderlich. Die vMotion- und Replikationsnetzwerke sind für AVS Gen 2 nicht erforderlich.

Nächste Schritte

  • Last updated on