Was ist Azure-VMware-Lösung?

Azure-VMware-Lösung bietet private Clouds, die VMware vSphere-Cluster enthalten, die aus dedizierter Bare-Metal-Azure-Infrastruktur erstellt wurden. Azure-VMware-Lösung steht in Azure Commercial und Azure Government zur Verfügung. Die Mindestbereitstellung für den Einstieg besteht aus drei Hosts, es können jedoch weitere Hosts bis zu einem Maximum von16 Hosts pro Cluster hinzugefügt werden. Alle bereitgestellten privaten Clouds verfügen über VMware vCenter Server, VMware vSAN, VMware vSphere und VMware NSX-T. Daher können Sie Workloads aus Ihren lokalen Umgebungen migrieren, neue virtuelle Computer (VMs) bereitstellen und Azure Dienste aus Ihren privaten Clouds nutzen. Informationen zum SLA finden Sie auf der Seite Azure Service Level Agreements.

Azure-VMware-Lösung ist eine VMware-validierte Lösung mit fortlaufender Validierung und Tests von Verbesserungen und Upgrades. Microsoft verwaltet und verwaltet die private Cloudinfrastruktur und -software, sodass Sie sich auf die Entwicklung und Ausführung von Workloads in Ihren privaten Clouds konzentrieren können, um den Geschäftlichen Nutzen zu erzielen.

Das Diagramm zeigt die Nähe zwischen privaten Clouds und VNets in Azure, Azure Diensten und lokalen Umgebungen. Netzwerkzugriff von privaten Clouds auf Azure Dienste oder VNets bietet SLA-gesteuerte Integration von Azure Dienstendpunkten. ExpressRoute Global Reach verbindet Ihre lokale Umgebung mit Ihrer Azure-VMware-Lösung privaten Cloud.

Azure-VMware-Lösung Private Cloud-Typen

Azure-VMware-Lösung bietet zwei verschiedene private Cloud-Generationen:

1. Azure-VMware-Lösung Generation 1 bietet VMware vSphere-Cluster aus dedizierten Bare-Metal-Hosts, die in Azure-Rechenzentren bereitgestellt werden. Microsoft verwaltete ExpressRoute-Schaltkreise ermöglichen die Konnektivität zwischen VMware vSphere-Hosts und systemeigenen Azure Ressourcen, die in virtuellen Netzwerken bereitgestellt werden.

2. Azure-VMware-Lösung Generation 2 stellt VMware vSphere-Cluster aus dedizierten Azure Bare-Metal-Hosts bereit. Azure-VMware-Lösung Generation 2 verfügt über eine aktualisierte Netzwerkarchitektur, bei der VMware vSphere-Hosts direkt an Azure virtuelle Netzwerke angefügt werden. Dieses Angebot wird nur auf der AV64-SKU unterstützt.

Hosts, Cluster und private Clouds

Azure-VMware-Lösung Cluster basieren auf einer hyperkonvergierten Infrastruktur. Die folgende Tabelle zeigt die CPU-, Arbeitsspeicher-, Datenträger- und Netzwerkspezifikationen des Hosts.

Ein Azure-VMware-Lösung Cluster erfordert mindestens drei Hosts. Sie können Hosts desselben Typs nur in einer einzelnen Azure-VMware-Lösung privaten Cloud verwenden. Hosts, die zum Erstellen oder Skalieren von Clustern verwendet werden, stammen aus einem isolierten Hostpool. Diese Hosts haben Hardwaretests bestanden, und alle Daten wurden sicher gelöscht, bevor sie zu einem Cluster hinzugefügt wurden.

Alle vorherigen Hosttypen weisen einen Netzwerkschnittstellendurchsatz von 100 GBit/s auf.

*Details sind über den Azure Preisrechner verfügbar.

**AV64-Voraussetzung: Eine Azure-VMware-Lösung private Cloud, die mit AV36, AV36P, AV48 oder AV52 bereitgestellt wird, ist erforderlich, bevor Av64 hinzugefügt wird.

***Unformatiert (Raw) basiert auf dem internationalen Standard of Units (SI), die vom Datenträgerhersteller gemeldet wurden. Beispiel: 1 TB Raw = 100000000000 Bytes. Der im Binärsystem berechnete Speicherplatz von einem Computer (1 TB binär = 1099511627776 Bytes) entspricht 931,3 Gigabyte, die aus dem Dezimalsystem umgerechnet wurden.

****ESA gilt für AV64 Gen 2-Bereitstellungen.

Sie können neue private Clouds bereitstellen oder bestehende skalieren über das Azure-Portal oder die Azure CLI.

Azure-VMware-Lösung Private-Cloud-Erweiterung mit Knoten der Größe AV64

Der AV64 ist eine Azure-VMware-Lösung Host-SKU, die verfügbar ist, um die Azure-VMware-Lösung private Cloud zu erweitern, die mit der vorhandenen AV36-, AV36P- oder AV52-SKU erstellt wurde. Wenn Sie AV64 direkt bereitstellen möchten, lesen Sie Azure-VMware-Lösung in einem Azure Virtual Network. Verwenden Sie die dokumentation Microsoft, um die Verfügbarkeit der AV64-SKU in der Region zu überprüfen.

Diagramm, das die private Azure-VMware-Lösung-Cloud mit AV64 SKU in einer gemischten SKU-Konfiguration zeigt.

Voraussetzung für die AV64-Erweiterung auf AV36, AV36P und AV52

Nachfolgend finden Sie die Voraussetzungen für die AV64-Clusterbereitstellung.

• Eine Azure private Cloud für VMware-Lösungen wird mithilfe von AV36, AV36P, AV48 oder AV52 in AV64 erstellt, die region/AZ unterstützt werden.

• Für die Verwaltung des AV64-Clusters benötigen Sie entweder einen Adressblock /23 oder drei Adressblöcke /25 (zusammenhängend oder nicht zusammenhängend).

Unterstützungsmöglichkeiten für Kundenszenarien

Kunde mit vorhandener Azure-VMware-Lösung Private Cloud: Wenn einem Kunden eine Azure-VMware-Lösung Private Cloud bereitgestellt wurde, kann er die Private Cloud skalieren, indem er einen separaten AV64 vCenter-Knoten-Cluster zu dieser bestehenden privaten Cloud hinzufügt. In diesem Szenario müssen Kunden die folgenden Schritte ausführen:

1. Erhalten Sie eine AV64-Quotenfreigabe von Microsoft mit mindestens drei Knoten. Fügen Sie weitere Details zur Azure-VMware-Lösung privaten Cloud hinzu, die Sie mit AV64 erweitern möchten.
2. Verwenden Sie einen vorhandenen Azure-VMware-Lösung Add-Cluster-Workflow mit AV64-Hosts, um zu erweitern.

Customer plant, eine neue Azure-VMware-Lösung private Cloud zu erstellen: Wenn ein Kunde eine neue Azure-VMware-Lösung private Cloud möchte, die AV64-SKU verwenden kann, aber nur zur Erweiterung. In diesem Fall erfüllt der Kunde die Voraussetzung für eine Azure-VMware-Lösung private Cloud, die mit AV36, AV36P oder AV52 SKU erstellt wurde. Der Kunde muss mindestens drei Knoten der AV36-, AV36P- oder AV52-SKU kaufen, bevor er mithilfe von AV64 erweitern kann. Führen Sie für dieses Szenario folgende Schritte aus:

1. Rufen Sie av36, AV36P oder AV52 und AV64 quota-Genehmigung von Microsoft mit jeweils mindestens drei Knoten ab.
2. Erstellen Sie eine Azure-VMware-Lösung private Cloud mit AV36, AV36P oder AV52-SKU.
3. Verwenden Sie einen vorhandenen Azure-VMware-Lösung Add-Cluster-Workflow mit AV64-Hosts, um zu erweitern.

Azure-VMware-Lösung Stretched Clusters Private Cloud: Die AV64-SKU wird nicht mit der Azure-VMware-Lösung gestreckten Clustern Private Cloud unterstützt. Dies bedeutet, dass eine AV64-basierte Erweiterung für die Private Cloud mit gestrecktem Cluster von Azure-VMware-Lösung nicht möglich ist.

Erweiterte vMotion-Kompatibilität (EVC) mit AV64-Erweiterung

Durch das Hinzufügen von AV64-Knoten zu einer Azure-VMware-Lösung privaten Cloud wird eine heterogene Umgebung erstellt, die zu Enhanced vMotion Compatibility (EVC)-Problemen zwischen AV64-Clustern und Basis-SKU-Clustern mit AV36-, AV36P- oder AV52-SKUs führt. AV64-Cluster verwenden den Icelake EVC-Modus aufgrund ihrer Intel Icelake-CPUs, während AV36-, AV36P- und AV52-Cluster, die auf älteren Intel-CPUs basieren, keinen expliziten EVC-Modus aktiviert haben. Details zu CPU-Generationen für jede SKU werden oben bereitgestellt.

Die Heterogenität von EVC-Modi über Cluster hinweg stellt Herausforderungen für Live-vMotion-Vorgänge dar, wie von Broadcom definiert, basierend auf dem spezifischen Szenario und der Richtung der Migration. Der folgende Abschnitt enthält eine Zusammenfassung der Benutzererfahrung beim Ausführen von Live-vMotion zwischen AV64 und den Basisclustern.

• vMotion zu AV64-Cluster von Basis-SKU-Cluster – dies funktioniert einwandfrei, da der virtuelle Computer von einem Cluster mit niedrigem EVC-Modus zu einem Cluster mit höherem EVC-Modus per vMotion verschoben wird.

• vMotion zum Basis-SKU-Cluster aus dem AV64-Cluster – zwei Szenarien

  • Wenn der virtuelle Computer zuvor aus dem Basiscluster verschoben wurde und nicht wieder eingeschaltet wurde, ist Live vMotion erfolgreich.

  • Wenn ein virtueller Computer im AV64-Cluster erstellt und eingeschaltet wurde, obwohl er zuvor vom Basis-SKU-Cluster per vMotion verschoben wurde, schlägt Live vMotion mit dem EVC-Kompatibilitätsfehler fehl.

Kunden können Live-vMotion-Probleme zwischen Basis-SKU- und AV64-Clustern vermeiden, indem Sie den EVC-Modus auf VM-Ebene so festlegen, dass er einem niedrigeren Basiscluster-EVC entspricht, oder indem er den virtuellen Computer ausschaltet und eine kalte vMotion ausführt.

Design und Empfehlungen für eine AV64-Cluster vSAN-Fehlerdomäne (FD)

Die herkömmlichen Azure-VMware-Lösung Hostcluster verfügen nicht über eine explizite vSAN FD-Konfiguration. Die Begründung ist die Hostzuordnungslogik stellt innerhalb von Clustern sicher, dass sich keine zwei Hosts in derselben physischen Fehlerdomäne innerhalb einer Azure Region befinden. Dieses Feature bietet von Natur aus Resilienz und Hochverfügbarkeit für den Speicher, die die vSAN-FD-Konfiguration bieten soll. Weitere Informationen zur vSAN-FD finden Sie in der VMware-Dokumentation.

Die Azure-VMware-Lösung AV64-Hostcluster verfügen über eine explizite VSAN-Fehlerdomänenkonfiguration (FD). Azure-VMware-Lösung Steuerebene konfiguriert sieben vSAN-Fehlerdomänen (FDs) für AV64-Cluster. Hosts werden gleichmäßig über die sieben FDs verteilt, wenn Benutzer die Hosts in einem Cluster von drei Knoten auf 16 Knoten skalieren. Einige Azure-Regionen unterstützen weiterhin höchstens fünf FDs als Teil der ersten Veröffentlichung der AV64-SKU. Weitere Informationen finden Sie in der Azure Regionsverfügbarkeitszone für die Hosttypzuordnungstabelle.

Empfehlung zur Clustergröße

Die Azure-VMware-Lösung mindest unterstützte vSphere-Knoten-Clustergröße ist drei. Die vSAN-Datenredundanz wird behandelt, indem sichergestellt wird, dass sich die minimale Clustergröße von drei Hosts in unterschiedlichen vSAN-FDs befindet. In einem vSAN-Cluster mit drei Hosts, die sich jeweils in einer anderen FD befinden, wären die vSAN-Daten geschützt, falls eine FD fehlschlagen würde (z. B. bei einem Fehler des Top-of Rack-Switches). Vorgänge wie die Objekterstellung (neue VM, VMDK und andere) würden fehlschlagen. Dies würde auch für alle Wartungsaktivitäten gelten, bei denen ein ESXi-Host in den Wartungsmodus versetzt und/oder neu gestartet wird. Um solche Szenarien zu vermeiden, wird empfohlen, vSAN-Cluster mit mindestens vier ESXi-Hosts bereitzustellen.

Workflow und bewährte Methoden zum Entfernen von AV64-Hosts

Aufgrund der Konfiguration der AV64-Cluster-vSAN-Fehlerdomäne (FD) und der Notwendigkeit für Hosts, die auf allen FDs ausgeglichen sind, unterscheidet sich das Entfernen des Hosts aus AV64-Clustern von herkömmlichen Azure-VMware-Lösung Hostclustern mit anderen SKUs.

Derzeit kann ein Benutzer einen oder mehrere Hosts auswählen, die mithilfe des Portals oder der API aus dem Cluster entfernt werden sollen. Eine Bedingung dabei ist, dass ein Cluster mindestens drei Hosts aufweisen muss. Ein AV64-Cluster weist jedoch in bestimmten Szenarien ein anderes Verhalten auf, wenn AV64 vSAN-FDs verwendet. Bei jeder Anforderung zum Entfernen eines Hosts erfolgt eine Überprüfung hinsichtlich eines potenziellen Ungleichgewichts in den vSAN-Fehlerdomänen. Wenn die Anforderung zum Entfernen eines Hosts ein Ungleichgewicht erzeugt, wird die Anforderung mit der HTTP-Antwort 409 (Konflikt) abgelehnt. Der HTTP-Antwortstatuscode 409 (Konflikt) weist auf einen Anforderungskonflikt hin und gibt den aktuellen Status der Zielressource (Hosts) zurück.

Die folgenden drei Szenarien zeigen Beispiele für Instanzen, die normalerweise einen Fehler verursachen. Dabei werden verschiedene Methoden dargestellt, um Hosts zu entfernen, ohne ein Ungleichgewicht in den vSAN-Fehlerdomänen (FD) zu erzeugen.

• Das Entfernen eines Hosts erzeugt ein vSAN FD-Ungleichgewicht, da ein Unterschied zwischen den am den meisten und den am wenigsten gefüllten FDs um mehr als eins gibt. Im folgenden Beispiel müssen Benutzende einen der Hosts aus der FD 1 entfernen, bevor sie Hosts aus anderen Fehlerdomänen entfernen können.

  

• Mehrere Anforderungen zur Entfernung von Hosts erfolgen gleichzeitig und bestimmte davon erzeugen ein Ungleichgewicht. In diesem Szenario entfernt die Azure-VMware-Lösung Steuerebene nur Hosts, die kein Ungleichgewicht erzeugen. Im folgenden Beispiel können Benutzende nicht beide Hosts aus denselben Fehlerdomänen entfernen, es sei denn, sie verringern die Clustergröße auf vier oder kleiner.

  

• Eine ausgewählte Hostentfernung verursacht weniger als drei aktive vSAN-Fehlerdomänen. Dieses Szenario wird nicht erwartet, da alle AV64-Regionen fünf oder sieben FDs aufweisen. Beim Hinzufügen von Hosts kümmert sich die Azure-VMware-Lösung Steuerungsebene darum, Hosts gleichmäßig aus allen sieben FDs hinzuzufügen. Im folgenden Beispiel können Benutzer*innen einen der Hosts aus der FD 1, jedoch nicht aus der FD 2 oder FD 3 entfernen.

  

So identifizieren Sie den Host, der entfernt werden kann, ohne ein vSAN FD-Ungleichgewicht zu verursachen: Ein Benutzer kann zur vSphere-Clientoberfläche wechseln, um den aktuellen Status von vSAN-Fehlerdomänen und Hosts abzurufen, die der von ihnen zugeordnet sind. Dadurch können Hosts (basierend auf den vorherigen Beispielen) identifiziert werden, die entfernt werden können, ohne dass das vSAN FD-Gleichgewicht gestört wird und ohne dass dabei Fehler beim Entfernungsvorgang entstehen.

AV64-unterstützte RAID-Konfiguration

Diese Tabelle enthält die Liste der unterstützten RAID-Konfigurationen und Hostanforderungen in AV64-Clustern. Die Richtlinien für RAID-6 FTT2 und RAID-1 FTT3 werden in einigen Regionen mit der AV64-SKU unterstützt. In Azure Regionen, die derzeit auf fünf FDs beschränkt sind, ermöglicht Microsoft Kunden die Verwendung der RAID-5 FTT1 vSAN-Speicherrichtlinie für AV64-Cluster mit sechs oder mehr Knoten, um die Vereinbarung zum Servicelevel (SLA) zu erfüllen. Weitere Informationen finden Sie in der Azure Regionsverfügbarkeitszone für die Hosttypzuordnungstabelle.

Storage

Azure-VMware-Lösung unterstützt die Erweiterung der Datenspeicherkapazität über das, was in vSAN mit Azure Speicherdiensten enthalten ist, sodass Sie die Datenspeicherkapazität erweitern können, ohne die Cluster zu skalieren. Weitere Informationen finden Sie unter Erweiterungsoptionen für Datenspeicherkapazität.

Networking

Azure-VMware-Lösung bietet eine private Cloudumgebung, auf die von lokalen Websites und Azure basierten Ressourcen zugegriffen werden kann. Dienste wie Azure ExpressRoute, VPN-Verbindungen oder Azure Virtual WAN liefern die Konnektivität. Diese Dienste benötigen jedoch bestimmte Netzwerkadressbereiche und Firewallports für die Aktivierung der Dienste.

Wenn Sie eine private Cloud bereitstellen, werden private Netzwerke für Verwaltung, Bereitstellung und vMotion erstellt. Sie verwenden diese privaten Netzwerke, um auf den VMware vCenter Server und den VMware NSX-Manager sowie auf vMotion oder die Bereitstellung von virtuellen Maschinen zuzugreifen.

ExpressRoute Global Reach wird verwendet, um private Clouds mit lokalen Umgebungen zu verbinden. Es verbindet Schaltungen direkt auf der Microsoft Edge Ebene. Die Verbindung erfordert ein virtuelles Netzwerk (VNet) mit einer ExpressRoute-Leitung zur lokalen Umgebung in Ihrem Abonnement. Der Grund dafür: VNet-Gateways (ExpressRoute-Gateways) können keinen Datenverkehr übertragen. Das bedeutet, dass Sie zwar zwei Verbindungen an das gleiche Gateway anfügen können, der Datenverkehr aber nicht von einer Verbindung an die andere gesendet wird.

Jede Azure-VMware-Lösung Umgebung ist eine eigene ExpressRoute-Region (ein eigenes virtuelles MSEE-Gerät), mit dem Sie die globale Reichweite mit dem Lokalen Peeringstandort verbinden können. Sie können mehrere Azure-VMware-Lösung Instanzen in einer Region mit demselben Peering-Standort verbinden.

Virtuelle Computer, die in der privaten Cloud bereitgestellt werden, sind über die funktionalität Azure Virtual WAN public IP für das Internet zugänglich. Bei neuen privaten Clouds ist der Internetzugriff standardmäßig deaktiviert.

Weitere Informationen finden Sie unter Netzwerkarchitektur.

Zugriff und Sicherheit

Azure-VMware-Lösung private Clouds verwenden die rollenbasierte vSphere-Zugriffssteuerung für erhöhte Sicherheit. Sie können vSphere SSO LDAP-Funktionen in Microsoft Entra ID integrieren. Weitere Informationen finden Sie auf der Seite Zugriffs- und Identitätsarchitektur.

Die vSAN-Verschlüsselung ruhender Daten ist standardmäßig aktiviert und dient zum Schutz des vSAN-Datenspeichers. Weitere Informationen finden Sie unter Speicherarchitektur.

Datenresidenz und Kundendaten

Azure-VMware-Lösung speichert keine Kundendaten.

Versionen von VMware-Software

In der folgenden Tabelle sind die Softwareversionen aufgeführt, die in neuen Bereitstellungen von Azure-VMware-Lösung privaten Clouds verwendet werden.

Wenn die aufgeführte Buildnummer nicht mit der in den Versionshinweisen aufgeführten Buildnummer übereinstimmt, liegt es daran, dass ein benutzerdefinierter Patch für Cloudanbieter angewendet wurde.

Die aktuelle ausgeführte Softwareversion wird auf neue Cluster angewendet, die einer vorhandenen privaten Cloud hinzugefügt werden, wenn die vCenter Server-Version sie unterstützt.

Verwaltung des Host- und Softwarelebenszyklus

Regelmäßige Upgrades der Azure-VMware-Lösung private Cloud und VMware-Software stellen sicher, dass die neuesten Sicherheits-, Stabilitäts- und Featuresätze in Ihren privaten Clouds ausgeführt werden. Weitere Informationen finden Sie unter Hostwartung und Lebenszyklusverwaltung.

Überwachen Ihrer privaten Cloud

Nachdem Sie Azure-VMware-Lösung in Ihrem Abonnement bereitgestellt haben, werden Azure Monitor Protokolle automatisch generiert.

In Ihrer privaten Cloud haben Sie folgende Möglichkeiten:

• Sammeln von Protokollen auf jedem Ihrer virtuellen Computer
• Laden Sie den MMA-Agenten herunter und installieren Sie ihn auf Linux- und Windows-VMs.
• Aktivieren Sie die Diagnoseerweiterung Azure.
• Erstellen und Ausführen neuer Abfragen
• Ausführen der gleichen Abfragen, die Sie auch sonst auf Ihren virtuellen Computern ausführen

Überwachungsmuster innerhalb der Azure-VMware-Lösung ähneln Azure VMs innerhalb der IaaS-Plattform. Weitere Informationen und Anleitungen finden Sie unter Monitoring Azure VMs mit Azure Monitor.

Kundenkommunikation

Im Azure Portal finden Sie Serviceprobleme, geplante Wartung, Gesundheitsberater und Sicherheitsratgeberbenachrichtigungen, die über Service Health veröffentlicht wurden. Um rechtzeitige Aktionen auszuführen, können Sie Aktivitätsprotokollwarnungen für diese Benachrichtigungen einrichten. Weitere Informationen finden Sie unter Create Service Health alerts using the Azure portal.

Azure-VMware-Lösung Verantwortungsmatrix – Microsoft vs Kunden

Azure-VMware-Lösung implementiert ein Modell für gemeinsame Verantwortung, das unterschiedliche Rollen und Zuständigkeiten der beiden beteiligten Parteien definiert: Kunde und Microsoft. Die Zuständigkeiten der gemeinsamen Rollen werden in den beiden folgenden Tabellen näher erläutert.

In der Matrix für gemeinsame Verantwortung werden die wichtigsten Aufgaben beschrieben, die Kunden und Microsoft bei der Bereitstellung und Verwaltung sowohl der privaten Cloud- als auch der Kundenanwendungs-Workloads übernehmen.

Die folgende Tabelle enthält eine detaillierte Liste der Rollen und Zuständigkeiten zwischen dem Kunden und Microsoft, die die am häufigsten verwendeten Aufgaben und Definitionen umfasst. Für weitere Fragen wenden Sie sich an Microsoft.

Nächste Schritte

Im nächsten Schritt lernen Sie wichtige Konzepte der privaten Cloudarchitektur kennen.