Freigeben über


Was ist Azure VMware Solution?

Azure VMware Solution bietet private Clouds mit VMware vSphere-Clustern, die auf dedizierter Bare-Metal-Azure-Infrastruktur basieren. Azure VMware Solution ist in Azure Commercial und Azure Government verfügbar. 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. Infolgedessen können Sie Workloads aus Ihren lokalen Umgebungen migrieren, neue virtuelle Computer (Virtual Machines, VMs) bereitstellen und Azure-Dienste über Ihre privaten Clouds nutzen. Weitere Informationen zur SLA finden Sie auf der Seite Vereinbarung zum Servicelevel für Azure.

Bei Azure VMware Solution handelt es sich um eine von VMware geprüfte Lösung, deren Erweiterungen und Upgrades kontinuierlich geprüft und getestet werden. Microsoft verwaltet und wartet die private Cloudinfrastruktur und -software, sodass Sie sich auf die Entwicklung und Ausführung von Workloads in Ihren privaten Clouds konzentrieren können, um geschäftlichen Nutzen zu erzielen.

Das Diagramm zeigt die Adjazenz zwischen privaten Clouds und VNETs in Azure, Azure-Diensten und lokalen Umgebungen. Der Netzwerkzugriff von privaten Clouds auf Azure-Dienste oder VNETs ermöglicht eine SLA-basierte Integration von Azure-Dienstendpunkten. Über ExpressRoute Global Reach wird Ihre lokale Umgebung mit Ihrer privaten Azure VMware Solution-Cloud verbunden.

Diagram: Adjazenz zwischen privater Azure VMware Solution-Cloud, Azure Services und lokaler Umgebung.

Private Cloudtypen für Azure VMware Solution

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

  1. Azure VMware Solution Generation 1 bietet VMware vSphere-Cluster, die von dedizierten Bare-Metal-Hosts erstellt wurden, die in Azure-Rechenzentrumseinrichtungen bereitgestellt werden. Von Microsoft verwaltete ExpressRoute-Schaltkreise bieten Verbindungen zwischen VMware vSphere-Hosts und nativen Azure-Ressourcen, die in virtuellen Netzwerken bereitgestellt werden.

  2. Azure VMware Solution Generation 2 (Public Preview) stellt VMware vSphere-Cluster bereit, die von dedizierten Azure Bare-Metal-Hosts erstellt wurden. Azure VMware Solution Generation 2 verfügt über eine aktualisierte Netzwerkarchitektur, wobei VMware vSphere-Hosts direkt mit Azure Virtual Networks verbunden sind. Dieses Angebot wird nur auf der AV64-SKU unterstützt.

Hosts, Cluster und private Clouds

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

Hosttyp CPU (Kerne/GHz) RAM (GB) vSAN-Architektur vSAN-Cache-Ebene (TB, raw***) vSAN-Kapazitätsebene (TB, raw***) Regionale Verfügbarkeit
AV36 Zwei Intel Xeon Gold 6140 CPUs (Skylake Mikroarchitektur) mit 18 Kernen/CPU @ 2,3 GHz, insgesamt 36 physische Kerne (72 logische Kerne mit Hyperthreading) 576 Obstruktive Schlafapnoe (OSA) 3.2 (NVMe) 15.20 (SSD) Ausgewählte Regionen (*)
AV36P Dual Intel Xeon Gold 6240 CPUs (Cascade Lake Mikroarchitektur) mit 18 Kernen/CPUs @ 2,6 GHz / 3,9 GHz Turbo, insgesamt 36 physische Kerne (72 logische Kerne mit Hyperthreading) 768 Obstruktive Schlafapnoe (OSA) 1,5 (Intel Cache) 19.20 (NVMe) Ausgewählte Regionen (*)
AV48 Dual Intel Xeon Gold 6442Y CPUs (Sapphire Rapids Mikroarchitektur) mit 24 Kernen/CPU @ 2,6 GHz / 4,0 GHz Turbo, Insgesamt 48 physische Kerne (96 logische Kerne mit Hyperthreading) 1\.024 ESA 25.6 (NVMe) Ausgewählte Regionen (*)
AV52 Dual Intel Xeon Platinum 8270 CPUs (Cascade Lake Mikroarchitektur) mit 26 Kernen/CPU @ 2,7 GHz / 4,0 GHz Turbo, insgesamt 52 physische Kerne (104 logische Kerne mit Hyperthreading) 1\.536 Obstruktive Schlafapnoe (OSA) 1,5 (Intel Cache) 38.40 (NVMe) Ausgewählte Regionen (*)
AV64 Duale Intel Xeon Platinum 8370C-CPUs (Ice Lake-Mikroarchitektur) mit 32 Kernen pro CPU und 2,8 GHz bzw. 3,5 GHz (Turbo); insgesamt 64 physische Kerne (128 logische Kerne mit Hyperthreading) 1\.024 Obstruktive Schlafapnoe (OSA) 3,84 (NVMe) 15,36 (NVMe) Ausgewählte Regionen (**)

Ein Azure VMware Solution-Cluster erfordert eine Mindestanzahl von drei Hosts. Sie können Hosts desselben Typs nur in einer privaten Azure VMware Solution-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 private Azure VMware-Lösung, die mit AV36, AV36P oder AV52 bereitgestellt wird, ist vor dem Hinzufügen von AV64 erforderlich.

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

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

Private Cloud-Erweiterung für Azure VMware Solution mit AV64-Knotengröße

Der AV64 ist eine Azure VMware Solution-Host-SKU, die verfügbar ist, um die private Azure VMware Solution-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 Microsoft-Dokumentation, um zu überprüfen, ob die AV64-SKU in der jeweiligen Region verfügbar ist.

Diagramm, das die private Azure VMware Solution-Cloud mit der AV64-SKU in gemischter 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 private Cloud für Azure-VMware-Lösung wird mithilfe von AV36, AV36P, AV48 oder AV52 in der unterstützten Region/VZ in AV64 erstellt.

  • 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 privater Azure VMware Solution-Cloud: Wenn ein Kunde eine private Azure VMware Solution-Cloud bereitgestellt hat, kann er die private Cloud skalieren, indem er einen separaten AV64 vCenter-Knotencluster zu dieser privaten Cloud hinzufügt. In diesem Szenario müssen Kunden die folgenden Schritte ausführen:

  1. Beschaffen Sie sich eine AV64-Kontingentgenehmigung von Microsoft mit mindestens drei Knoten. Fügen Sie weitere Details zur privaten Azure VMware Solution-Cloud hinzu, die Sie mithilfe von AV64 erweitern möchten.
  2. Verwenden Sie zum Erweitern mit AV64-Hosts einen vorhandenen Azure VMware Solution-Workflow zum Hinzufügen eines Clusters.

Der Kunde plant, eine neue private Azure VMware Solution-Cloud zu erstellen: Wenn ein Kunde eine neue private Azure VMware Solution-Cloud möchte, die die AV64-SKU verwenden kann, aber nur für die Erweiterung. In diesem Fall erfüllt der Kunde die Voraussetzung für eine private Azure VMware Solution-Cloud, die mit der AV36-, AV36P- oder AV52-SKU erstellt wird. 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. Beschaffen Sie sich eine AV36-, AV36P- oder AV52- und AV64-Kontingentgenehmigung von Microsoft mit mindestens drei Knoten.
  2. Erstellen Sie eine private Azure VMware Solution-Cloud mithilfe der AV36-, AV36P-, der AV52-SKU.
  3. Verwenden Sie zum Erweitern mit AV64-Hosts einen vorhandenen Azure VMware Solution-Workflow zum Hinzufügen eines Clusters.

Private Azure VMware Solution Stretched Cluster-Cloud: Die AV64-SKU wird für private Azure VMware Solution Stretched Cluster-Clouds nicht unterstützt. Das bedeutet, dass eine AV64-basierte Erweiterung für eine private Azure VMware Solution Stretched Cluster-Cloud nicht möglich ist.

Hinweis

Der gesamte Datenverkehr von einem AV64-Host in ein Kundennetzwerk verwendet die IP-Adresse der VMKernel-Netzwerkschnittstelle 1.

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

Die herkömmlichen Azure VMware Solution-Hostcluster verfügen nicht über eine explizite vSAN-FD-Konfiguration. Der Grund dafür ist darin zu sehen, dass die Hostzuordnungslogik innerhalb von Clustern sicherstellt, dass sich in einer Azure-Region nicht zwei Hosts in derselben physischen Fehlerdomäne 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 Solution AV64-Hostcluster verfügen über eine explizite vSAN-FD-Konfiguration (Fehlerdomäne). Die Azure VMware Solution-Steuerungsebene 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 maximal fünf FDs als Teil des ersten AV64-SKU-Releases. Weitere Informationen finden Sie in der Zuordnungstabelle für Hosttypen der Verfügbarkeitszone der Azure-Region.

Empfehlung zur Clustergröße

Die Mindestgröße des vSphere-Knotenclusters in Azure VMware Solution 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, Hosts gleichmäßig über alle Fehlerdomänen zu verteilen, unterscheidet sich das Entfernen eines Hosts aus dem AV64-Cluster von dem bei herkömmlichen Azure VMware Solution-Cluster-Hosts 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.

    Diagramm, das zeigt, wie einer der Hosts aus der FD 1 entfernt wird, bevor Hosts aus anderen Fehlerdomänen (FD) entfernt werden

  • Mehrere Anforderungen zur Entfernung von Hosts erfolgen gleichzeitig und bestimmte davon erzeugen ein Ungleichgewicht. In diesem Szenario entfernt die Azure VMware Solution-Steuerungsebene 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.

    Diagramm, dass zeigt, dass nur dann beide Hosts aus derselben Fehlerdomänen entfernt werden können, wenn die Clustergröße auf vier oder weniger verringert wird.

  • 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. Die Azure VMware Solution-Steuerungsebene fügt Hosts gleichmäßig aus allen sieben FDs hinzu. Im folgenden Beispiel können Benutzer*innen einen der Hosts aus der FD 1, jedoch nicht aus der FD 2 oder FD 3 entfernen.

    Diagramm, das zeigt, wie einer der Hosts aus FD 1, aber nicht aus FD 2 oder 3 entfernt werden kann

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 es Kunden, die RAID-5 FTT1 vSAN-Speicherrichtlinie für AV64-Cluster mit sechs oder mehr Knoten zu verwenden, um die Vereinbarung zum Servicelevel (SLA) zu erfüllen. Weitere Informationen finden Sie in der Zuordnungstabelle für Hosttypen der Verfügbarkeitszone der Azure-Region.

RAID-Konfiguration Zu tolerierende Fehler (Failures to Tolerate, FTT) Mindestens erforderliche Hostanzahl
RAID-1 (Spiegelung) Standardeinstellung. 1 3
RAID-5 (Erasure Coding) 1 4
RAID-1 (Spiegelung) 2 5
RAID-6 (Erasure Coding) 2 6
RAID-1 (Spiegelung) 3 7

Speicher

Die Azure VMware Solution unterstützt die Erweiterung der Datenspeicherkapazität über das in vSAN enthaltene Maß hinaus mithilfe von Azure-Speicherdiensten, sodass Sie die Datenspeicherkapazität ohne Skalierung der Cluster erweitern können. Weitere Informationen finden Sie unter Erweiterungsoptionen für Datenspeicherkapazität.

Netzwerk

Azure VMware Solution stellt eine private Cloudumgebung bereit, die über lokale Standorte und Azure-basierte Ressourcen zugänglich ist. Die Konnektivität wird über Dienste wie Azure ExpressRoute, über VPN-Verbindungen oder über Azure Virtual WAN bereitgestellt. 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. Leitungen werden direkt auf der Microsoft Edge-Ebene verbunden. 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 Solution-Umgebung ist eine eigene ExpressRoute-Region (ein eigenes virtuelles MSEE-Gerät), mit der Sie Global Reach mit dem „lokalen“ Peeringstandort verbinden können. Es ermöglicht Ihnen, mehrere Azure VMware Solution-Instanzen in einer Region mit demselben Peeringstandort zu verbinden.

Hinweis

Für Standorte, an denen ExpressRoute Global Reach nicht aktiviert ist (beispielsweise aufgrund örtlicher Bestimmungen), muss eine Routinglösung mit Azure-IaaS-VMs erstellt werden. Einige Beispiele finden Sie unter Azure Cloud Adoption Framework – Netzwerktopologie und -konnektivität für Azure VMware Solution.

In der privaten Cloud bereitgestellte virtuelle Computer sind vom Internet aus über die öffentliche IP-Adresse von Azure Virtual WAN zugänglich. Bei neuen privaten Clouds ist der Internetzugriff standardmäßig deaktiviert.

Weitere Informationen finden Sie unter Netzwerkarchitektur.

Zugriff und Sicherheit

Zur Verbesserung der Sicherheit wird von privaten Azure VMware Solution-Clouds die rollenbasierte Zugriffssteuerung von vSphere verwendet. vSphere-SSO-LDAP-Funktionen können in Microsoft Entra ID integriert werden. 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 Solution speichert keine Kundendaten.

Versionen von VMware-Software

In der folgenden Tabelle sind die Softwareversionen aufgeführt, die in neuen Bereitstellungen privater Azure VMware Solution-Clouds verwendet werden.

Software Version Buildnummer
VMware vCenter Server 8.0 U2d 23929136
VMware ESXi 8.0 U2d 24585300
VMware vSAN 8.0 U2 24585300
VMware vSAN Zeuge 8.0 U2 24585300
VMware vSAN-Datenträgerformat 19
VMware vSAN-Speicherarchitektur OSA
VMware VM 4.1.1 22224317
VMware HCX 4.10.3 24447633
VMware Site Recovery Manager 8.8.0.3 23263429
VMware vSphere-Replikation 8.8.0.3 23166649

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

Durch regelmäßige Upgrades der privaten Azure VMware Solution-Cloud und der VMware-Software wird gewährleistet, dass die Sicherheit, Stabilität und Features Ihrer privaten Clouds immer auf dem neuesten Stand sind. Weitere Informationen finden Sie unter Hostwartung und Lebenszyklusverwaltung.

Überwachen Ihrer privaten Cloud

Nach der Bereitstellung von Azure VMware Solution in Ihrem Abonnement werden automatisch Azure Monitor-Protokolle generiert.

In Ihrer privaten Cloud haben Sie folgende Möglichkeiten:

Überwachungsmuster innerhalb von Azure VMware Solution sind mit virtuellen Azure-Computern auf der IaaS-Plattform vergleichbar. Weitere Informationen und Anleitungen finden Sie unter Überwachen von virtuellen Azure-Computern mit Azure Monitor.

Kundenkommunikation

Benachrichtigungen zu Dienstproblemen, geplanter Wartung, Integritätsempfehlungen und Sicherheitsempfehlungen werden über Service Health im Azure-Portal veröffentlicht. Um rechtzeitige Aktionen auszuführen, können Sie Aktivitätsprotokollwarnungen für diese Benachrichtigungen einrichten. Weitere Informationen finden Sie unter Erstellen von Service Health-Warnungen über das Azure-Portal.

Ein Screenshot, der die Service Health-Benachrichtigungen zeigt.

Azure VMware Solution-Zuständigkeitsmatrix  – Microsoft und Kund*innen im Vergleich

Azure VMware Solution implementiert ein Modell der gemeinsamen Zuständigkeiten, das unterschiedliche Rollen und Zuständigkeiten der beiden an dem Angebot beteiligten Parteien definiert: Kund*innen und Microsoft. Die Zuständigkeiten der gemeinsamen Rollen werden in den beiden folgenden Tabellen näher erläutert.

In der Matrixtabelle der gemeinsamen Zuständigkeiten werden die Hauptaufgaben beschrieben, die Kund*innen und Microsoft jeweils bei der Bereitstellung und Verwaltung der Workloads für private Cloud- und Kundenanwendungen erledigen.

Diagramm der übergeordneten gemeinsamen Verantwortungsmatrix für Azure VMware Solution.

Die folgende Tabelle enthält eine detaillierte Liste der Rollen und Verantwortlichkeiten zwischen dem Kunden und Microsoft, die die häufigsten Aufgaben und Definitionen umfasst. Wenden Sie sich bei weiteren Fragen an Microsoft.

Rolle Aufgabe/Details
Microsoft: Azure VMware Solution Physische Infrastruktur
  • Azure-Regionen
  • Azure-Verfügbarkeitszonen
  • Express-Route/Globale Reichweite
Compute/Netzwerk/Speicher
  • Rack- und Power-Bare-Metal-Computerhosts
  • Rack- und Power-Netzwerkgeräte
Bereitstellung/Lebenszyklus der privaten Cloud
  • Bereitstellen, Patchen und Upgrade von VMware ESXi
  • Bereitstellen, Patchen und Upgrade von VMware vCenter Server-Instanzen
  • Bereitstellen, Patchen und Upgrade von VMware NSX
  • Bereitstellen, Patchen und Upgrade von VMware vSAN
Private Cloud Networking – VMware NSX-Anbieterkonfiguration
  • Microsoft Edge-Knoten/Cluster, VMware NSX-Hostvorbereitung
  • Anbietergateway der Ebene 0 und Mandantengateway der Ebene 1
  • Konnektivität von Ebene 0 (mit BGP) mit dem Azure-Netzwerk über ExpressRoute
Private Cloud Compute - VMware vCenter Server Anbieterkonfiguration
  • Erstellen eines Standardclusters
  • Konfigurieren von virtuellen Netzwerken für vMotion, Verwaltung, vSAN und andere
Private Cloud-Sicherung/Wiederherstellung
  • Sichern und Wiederherstellen von VMware vCenter Server
  • Sichern und Wiederherstellen von VMware NSX Manager
Überwachung des Zustands der privaten Cloud und Abhilfemaßnahmen, z. B.: Austausch ausgefallener Hosts

(optional) VMware HCX wird mit vollständig konfiguriertem Compute-Profil auf der Cloud-Seite als Add-on bereitgestellt

(optional) VMware SRM bereitstellen, upgraden und nach oben/unten skalieren

Support – Private Cloud-Plattformen und VMware HCX
Kunde Fordern Sie ein Angebot für Azure VMware Solution-Hosts bei Microsoft an.
Planen und Erstellen einer Anforderung für private Clouds im Azure-Portal mit:
  • Hostanzahl
  • Bereich Verwaltungsnetzwerk
  • Weitere Informationen
Konfigurieren des privaten Cloudnetzwerks und der Sicherheit (VMware NSX)
  • Netzwerksegmente zum Hosten von Anwendungen
  • Weitere Router der Ebene -1
  • Brandmauer
  • VMware KILO LB
  • IPSec-VPN
  • NAT
  • Öffentliche IP-Adressen
  • Verteilte Firewall/Gatewayfirewall
  • Netzwerkerweiterung mit VMware HCX oder VMware NSX
  • AD/LDAP-Konfiguration für RBAC
Konfigurieren der privaten Cloud – VMware vCenter Server
  • AD/LDAP-Konfiguration für RBAC
  • Bereitstellung und Lebenszyklusverwaltung von VMs und Anwendungen
    • Installieren von Betriebssystemen
    • Patchen von Betriebssystemen
    • Installieren von Antivirensoftware
    • Installieren von Sicherungssoftware
    • Installieren von Konfigurationsverwaltungssoftware
    • Installieren von Anwendungskomponenten
    • VM-Netzwerk mit VMware NSX-Segmenten
  • Migrieren von VMs
    • VMware HCX-Konfiguration
    • Live vMotion
    • Kalte Migration
    • Synchronisieren der Inhaltsbibliothek
Konfigurieren der privaten Cloud – vSAN
  • Definieren und Verwalten von vSAN-VM-Richtlinien
  • Hosts hinzufügen, um ausreichenden „Freiraum“ beizubehalten
Konfigurieren von VMware HCX
  • Laden Sie den HCA-Connector-OVA herunter und stellen Sie ihn im lokalen System bereit.
  • Kopplung des VMware-HCX-Connectors vor Ort
  • Konfigurieren von Netzwerkprofil, Computeprofil und Service Mesh
  • Konfigurieren der VMware HCX-Netzwerkerweiterung/MON
  • Upgrade/Updates
Netzwerkkonfiguration zum Herstellen einer Verbindung mit der lokalen Umgebung, einem virtuellen Netzwerk oder dem Internet

Hinzufügen oder Löschen von Hostanforderungen an den Cluster über das Portal

Bereitstellen/Lebenszyklusverwaltung von Partnerlösungen (Drittanbieter)
Ökosystem der Partnerunternehmen Unterstützung für ihr Produkt/ihre Lösung. Als Referenz werden im Folgenden einige der unterstützten Azure VMware Solution-Partnerlösungen/-Produkte aufgeführt:
  • BCDR – VMware SRM, JetStream, Zerto und andere
  • Sicherung: Veeam, Commvault, Rubrik und andere
  • VDI: Horizon, Citrix
  • VMware Cloud Director, VMware Cloud Director Availability (VCDA)
  • Sicherheitslösungen: BitDefender, TrendMicro, Checkpoint
  • Andere VMware-Produkte - Aria Suite, NSX Advanced Load Balancer

Nächste Schritte

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