Designüberlegungen für Private Clouds der Azure VMware-Lösungsgeneration 2

In diesem Artikel werden wichtige Entwurfsüberlegungen für private Azure VMware Solution Generation 2 (Gen 2) Clouds skizziert. Es erläutert die Funktionen, die diese Generation in VMware-basierte private Cloud-Umgebungen einbringt und den Zugriff auf Ihre Anwendungen sowohl von der lokalen Infrastruktur als auch von Azure-basierten Ressourcen ermöglichen. 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.

Einschränkungen

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

1. 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.

2. Sie können nur 1 private Cloud pro virtuellem Azure-Netzwerk bereitstellen.

3. Sie können nur 1 private Cloud pro Ressourcengruppe erstellen. Mehrere private Clouds in einer einzelnen Ressourcengruppe werden nicht unterstützt.

4. Die private Cloud und das virtuelle Netzwerk für die private Cloud müssen sich in derselben Ressourcengruppe befinden.

5. Sie können Ihre private Cloud nicht von einer Ressourcengruppe in eine andere verschieben , nachdem die private Cloud erstellt wurde.

6. Sie können Ihre private Cloud nicht von einem Mandanten in einen anderen verschieben, nachdem die private Cloud erstellt wurde.

7. Die direkte Konnektivität von Dienstendpunkten von Azure VMware Solution-Workloads wird nicht unterstützt.

8. Private Endpunkte mit globalem Peering zwischen Regionen, die mit Azure VMware Solution verbunden sind, werden nicht unterstützt.

9. vCloud Director mit privaten Endpunkten wird unterstützt. vCloud Director mit öffentlichen Endpunkten wird jedoch nicht unterstützt.

10. vSAN Stretched Clusters wird nicht unterstützt.

11. Öffentliche IP-Adressen bis zu VMware NSX Microsoft Edge für die Internetkonfiguration werden nicht unterstützt. Die unterstützten Internetoptionen finden Sie unter Internetkonnektivitätsoptionen.

12. 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 jenseits des NSX-T Tier-0 (T0) Edge, wie beispielsweise Azure-Diensten oder lokalen Umgebungen.

13. 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.

14. Ressourcenübergreifende Gruppen- und Abonnementverweise von virtuellen Kundennetzwerken bis zum virtuellen Azure VMware-Lösungsnetzwerk 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 einem dieser Verweise verknüpft ist, das sich in einer anderen Ressourcengruppe oder einem anderen Abonnement als das virtuelle Azure VMware Solution-Netzwerk befindet, kann die Netzwerkprogrammierung (z. B. die Verbreitung von NSX-Segmenten) möglicherweise fehlschlagen. Um Probleme zu vermeiden, müssen Kunden sicherstellen, dass das virtuelle Azure VMware-Lösungsnetzwerk 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 einen Verweis verwenden und diesen ordnungsgemäß auf Ihre private Azure VMware Solution-Cloud anwenden.

15. Bei der Bereitstellungen von privaten Clouds der 2. Generation kann ein Fehler auftreten, wenn Azure-Richtlinien, die strenge Regeln für Netzwerksicherheitsgruppen oder Routingtabellen erzwingen (z. B. bestimmte Benennungskonventionen) erzwingen, vorhanden sind. Diese Richtlinieneinschränkungen können die Erstellung der erforderlichen Azure VMware Solution-Netzwerksicherheitsgruppe und Routingtabelle während der Bereitstellung blockieren. Sie müssen diese Richtlinien aus dem virtuellen Azure VMware Solution-Netzwerk entfernen, bevor Sie Ihre private Cloud bereitstellen. Sobald Ihre private Cloud bereitgestellt wurde, können diese Richtlinien wieder zur privaten Azure VMware Solution-Cloud hinzugefügt werden.

16. Wenn Sie privates DNS für Ihre private Azure VMware Solution-Cloud der 2. Generation verwenden, wird die Verwendung von benutzerdefiniertem DNS in dem virtuellen Netzwerk, in dem eine private Azure VMware Solution-Cloud der 2. Generation bereitgestellt wird, nicht unterstützt. Benutzerdefiniertes DNS unterbricht Lebenszyklusvorgänge wie Skalierung, Upgrades und Patchen.

17. Wenn Sie Ihre private Cloud löschen und einige erstellte Azure VMware-Lösungsressourcen nicht entfernt werden, können Sie die Löschung der privaten Azure VMware-Lösungscloud mithilfe der Azure CLI wiederholen.

18. 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.

19. 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 private Azure VMware Solution (AVS) Gen 2 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.

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

Private Clouds der Azure VMware Solution Gen 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 azure-Standardnetzwerke 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 virtuellen Azure-Netzwerk mithilfe von Azure-Standardnetzwerken bereit. Private Clouds der Azure VMware Solution Gen 2 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:

Nächste Schritte

• Beginnen Sie mit der Konfiguration Ihres Azure VMware Solution-Dienstprinzipals als Voraussetzung. Informationen dazu finden Sie im Schnellstart Aktivieren des Azure VMware Solution-Dienstprinzipals.

• Folgen Sie einem Lernprogramm zum Erstellen einer privaten Azure VMware Gen 2-Cloud