Die unterstützten Versionen von ONTAP, ESXi und vCenter Server variieren je nach ONTAP tools Release. Der ESXi Host und der vCenter Server, die zum Deployment der virtuellen Maschine von ONTAP tools verwendet werden, können zudem separate, restriktivere Anforderungen haben als die Versionen, die ONTAP tools nach dem Deployment managen kann. Die unterstützten Versionen ändern sich zwischen Releases, daher sind für das verwendete Release immer die "NetApp Interoperabilitäts-Matrix-Tool" und "ONTAP-Tools für VMware vSphere – Anforderungen und Konfigurationsgrenzen" zu prüfen.

Die meisten Umgebungen profitieren von einem Wechsel auf die neueste ONTAP tools 10.x Version. Im Vergleich zu ONTAP tools 9.13 bietet sie NVMe-oF Unterstützung für VMFS, ist für neuere ONTAP und VMware vSphere Versionen qualifiziert und unterstützt mehrere vCenter Server Instanzen pro Appliance statt nur einer. Bei ONTAP tools 9.x zu bleiben, ist nur dann sinnvoll, wenn Ihre Umgebung eine spezifische Abhängigkeit hat, die von der neuesten 10.x Version noch nicht unterstützt wird, und eine frühzeitige Migrationsplanung ist sinnvoll, da sich ONTAP tools 9.x dem Supportende nähert. Die aktuellen End-of-Support-Termine stehen auf der "NetApp Support Site - Unterstützung für Softwareversionen" Seite. Aus der "Vergleich der Funktionen von ONTAP tools for VMware vSphere nach Version" und der "NetApp Interoperabilitäts-Matrix-Tool" geht hervor, welche Version zu Ihren ONTAP, ESXi und vSphere Versionen passt.

ONTAP tools wird zunächst immer als extra-kleine (XS) Einzelknoten-Appliance eingesetzt und stellt zentrale Services für NFS- und VMFS-Datastores bereit. Wenn später mehr Ressourcen, höhere Ausfallsicherheit oder vVols und HA erforderlich sind, ist eine Skalierung auf klein, mittel oder groß beziehungsweise eine Erweiterung auf HA möglich; HA-Deployments sind mehrknotenbasiert, verwenden drei Knoten und erfordern eine Bibliothek, und große Deployments werden nur mit HA unterstützt. Zur Unterstützung der HA-Erweiterung ist die Appliance in einem ESXi-Cluster oder Ressourcenpool einzusetzen; außerdem muss sichergestellt sein, dass CPU Hot-Add und Memory Hot-Plug aktiviert sind; ab ONTAP tools 10.6 sind diese Einstellungen bei neuen Deployments standardmäßig aktiviert. Die CPU-, Speicher- und Festplattenressourcen für jede Größe sind in "ONTAP-Tools für VMware vSphere – Anforderungen und Konfigurationsgrenzen" aufgeführt, sodass ein Start mit der XS-Standardkonfiguration unbedenklich ist und bei wachsenden Anforderungen eine Erweiterung erfolgen kann. ONTAP tools unterstützt nur die Skalierung nach oben: Die Knotengröße kann nur erhöht, nicht verringert werden, und nach der Aktivierung von HA ist keine Rückkehr zu einer Einzelknotenkonfiguration ohne HA mehr möglich. Informationen zu Deployment-, Dimensionierungs- und Erweiterungsschritten finden Sie unter "Schnellstart für ONTAP-Tools für VMware vSphere", "Workflow für die Hochverfügbarkeitsbereitstellung von ONTAP tools" und "ONTAP tools skalieren und Hochverfügbarkeit aktivieren".

Die HA-Lösung ist für die Wiederherstellung nach dem Ausfall eines einzelnen Host-Knotens, eines Netzwerks, des Gastbetriebssystems oder der ONTAP tools Applikation vorgesehen. HA-Deployments verwenden drei Knoten, die sich für die Kommunikation zwischen den Knoten im selben Subnetz befinden müssen. CPU Hot-Add und Memory Hot-Plug müssen aktiviert sein; der HA-Workflow erfordert außerdem VASA Provider für vVols Datastores. Einrichtungsschritte sind in "Workflow für die Hochverfügbarkeitsbereitstellung von ONTAP tools" beschrieben.

HA ist nicht erforderlich, wenn Sie nur NFS- oder VMFS-Datastores ohne vVols verwenden, bietet jedoch weiterhin eine umfassendere Ausfallsicherheit gegenüber Ausfällen eines einzelnen Knotens, des Hosts, des Netzwerks, des Gastbetriebssystems oder der ONTAP tools Applikation. HA ist erforderlich, um den VASA Provider Service für vVols Datastores kontinuierlich verfügbar zu halten. Daher ist ein HA Deployment erforderlich, wenn Sie vVols verwenden oder wenn Sie eine höhere Service-Ausfallsicherheit und mehr Container pro Service benötigen, als ein Einzelknoten Deployment bietet.

Ja. Im Gegensatz zu ONTAP tools 9.x, das nur einen vCenter Server pro Appliance unterstützt, unterstützt ONTAP tools 10.x Mandantenfähigkeit und ermöglicht das Managen mehrerer vCenter Server Instanzen über eine einzige ONTAP tools Manager Oberfläche, wodurch sich die Anzahl der Appliances und der gesamte Ressourcenbedarf verringern. Wenn Sie vVols Datastores über mehrere vCenter Server Instanzen hinweg verwenden, aktualisieren Sie das selbstsignierte Zertifikat auf ein von einer CA signiertes Zertifikat, um eine sichere Kommunikation zu gewährleisten. Die Schritte finden Sie unter "vCenter Server-Instanzen zu ONTAP -Tools hinzufügen".

Für ein Einzelknoten-Deployment sind drei eindeutige, statische IPv4-Adressen im selben Subnetz erforderlich:

Ein HA-Deployment fügt für den zweiten und dritten Knoten jeweils eine zusätzliche Knoten-IP-Adresse hinzu; die IP-Adresse von ONTAP tools und die virtuelle IP-Adresse werden von allen Knoten gemeinsam genutzt. Das vollständige Deployment-Arbeitsblatt ist unter "ONTAP-Tools für VMware vSphere – Anforderungen und Konfigurationsgrenzen" und "Anforderungen vor der Bereitstellung von ONTAP tools" verfügbar.

ONTAP tools stellt die Ports 443 und 8443 als externe Pass-through-Ports für ONTAP tools Manager, die REST API, den VASA Provider und das Back-End des vSphere Client Plug-in bereit. Die übrigen Ports in der Tabelle mit den Portanforderungen sind Inter-Node-Ports, die vom Kubernetes Cluster der Appliance intern verwendet werden; in einem Einzelknoten-Deployment ist kein externer Zugriff darauf erforderlich, und in einem HA Deployment müssen alle drei Knoten einander über diese Ports erreichen können, einschließlich UDP 8472 für die Pod-zu-Pod-Kommunikation. Die vollständige Porttabelle ist unter "ONTAP-Tools für VMware vSphere – Anforderungen und Konfigurationsgrenzen" zu finden.

Ein Zertifikat sichert eine Verbindung nur dann, wenn es die Identität des Servers nachweist, mit dem Sie sich verbinden. Die Subject Alternative Name (SAN)-Erweiterung liefert diesen Nachweis: Sie listet die DNS-Namen und IP-Adressen auf, für die das Zertifikat gültig ist.

Das Maschinen-SSL-Zertifikat des vCenter Server muss folgende Anforderungen erfüllen:

Wenn das Zertifikat kein SAN aufweist oder das SAN nicht mit dem DNS-Namen, der IP-Adresse oder der PNID des vCenter Servers übereinstimmt, schlagen Operationen der ONTAP tools mit Zertifikatsvalidierungsfehlern fehl. Diese Validierung kann nicht deaktiviert werden. Korrigieren Sie das SAN mit dem vSphere Certificate Manager, bevor Sie die vCenter Server Instanz hinzufügen. Zertifikatanforderungen und Beispiele finden Sie unter "vCenter Server-Instanzen zu ONTAP -Tools hinzufügen".

ONTAP tools validiert standardmäßig Storage-Backend-Zertifikate, aus demselben Grund, aus dem auch vCenter Server-Zertifikate validiert werden: Die SAN-Erweiterung weist nach, zu welchem Cluster oder zu welcher SVM-Management-LIF das Zertifikat gehört. Das standardmäßige selbstsignierte ONTAP Zertifikat hat häufig keine SAN-Erweiterung und schlägt daher bei der Validierung fehl, wenn das Storage-Backend hinzugefügt wird.

Zum Beheben einer fehlgeschlagenen Validierung:

Wenn ein Storage-Backend-Zertifikat abläuft, bevor Sie es erneuern, markiert ONTAP tools das Storage-Backend als unbekannt, weil keine Verbindung mehr zum Storage-System hergestellt werden kann. Die Schritte finden Sie unter "Fügen Sie ein Speicher-Backend zu ONTAP tools hinzu" und "Zertifikatvalidierungsflag ändern".

ONTAP tools unterstützt diese Datenspeichertypen und Protokolle:

Die Schritte zur Erstellung finden Sie unter "Erstellen Sie einen Datenspeicher in ONTAP tools".

ONTAP tools verwendet systembedingt ein verschachteltes Initiatorgruppenmodell:

Wenn Sie bereits flache Initiatorgruppen haben, die Datastores zugeordnet sind, die ONTAP tools erkennt, konvertiert ONTAP tools diese während der Erkennung: Die ursprüngliche Initiatorgruppe bleibt als untergeordnete Initiatorgruppe mit dem otv_ Präfix erhalten, und darüber wird eine übergeordnete Initiatorgruppe erstellt, ohne die zugrunde liegenden Initiatorzuordnungen zu ändern. Initiatorgruppen, die keinem Datastore zugeordnet sind, wie z. B. Boot-LUN-Initiatorgruppen, bleiben unverändert.

Da ONTAP tools diese Parent-Child-Struktur zur Nachverfolgung des Hostzugriffs verwendet, sollten von ONTAP tools verwaltete Initiatorgruppen nicht manuell umbenannt, bearbeitet oder gelöscht werden. Stattdessen sind die ONTAP tools Workflows zum Mounten, Unmounten und Aktualisieren von Hosts zu verwenden. Details finden Sie in "Verschachtelte Initiatorgruppe Verwaltung in ONTAP tools" und "Wie ONTAP tools igroups und Exportrichtlinien verwaltet".

Storage Backends unterscheiden sich hinsichtlich Umfang und Zugangsdaten:

Die Schritte finden Sie unter "Fügen Sie ein Speicher-Backend zu ONTAP tools hinzu" und "Verknüpfen Sie ein Storage-Backend mit einer vCenter Server-Instanz in ONTAP tools".

Die Workflows für vVols Datastore hängen davon ab, dass der VASA Provider Service aktiviert und beim ausgewählten vCenter Server registriert ist. ONTAP tools verwendet VASA Provider, um die vVols Datastore Darstellung zu erstellen und zu pflegen, und VM Storage Policies verwenden Regeln des NetApp vVols Storage Type Provider. In einer HA Konfiguration erfordert der HA Workflow für vVols Datastores ebenfalls VASA Provider. Einrichtungsschritte sind in "Optionale Dienste im ONTAP tools Manager aktivieren" und "Registrieren Sie den VASA Provider bei einer vCenter Server-Instanz in ONTAP tools" beschrieben.

Broadcom hat vVols ab VMware Cloud Foundation und VMware vSphere Foundation 9.0 als veraltet eingestuft und plant, die Funktion in einer zukünftigen Version einzustellen. Für neue Deployments sollten VMFS- oder NFS-Datastores eingeplant werden, und der VASA Provider sollte deaktiviert bleiben, sofern vVols derzeit nicht verwendet wird. Informationen zur vVols Unterstützung in den einzelnen Releases finden Sie in den Release Notes der ONTAP tools.

Sie können einen geeigneten VMFS-Datenspeicher, der das iSCSI- oder FC-Protokoll verwendet, schützen, indem Sie ihn einer Schutzgruppe mit einer SnapMirror Beziehung unter Verwendung einer asynchronen oder AutomatedFailOverDuplex Richtlinie hinzufügen. Wenn ein Hostcluster Datenspeicher aus mehreren SVMs enthält, verwenden Sie stattdessen den Workflow für granularen Datenspeicherschutz, um Datenspeicher auf Schutzgruppen-Level auszuwählen und zu schützen. Die Schritte finden Sie unter "Einen VMFS Datenspeicher in ONTAP tools schützen" und "Datenspeicher in einem Cluster mit ONTAP tools schützen".

Für die Array-basierte Notfallwiederherstellung ist der SRA-Service in ONTAP tools zu aktivieren und der SRA-Adapter auf der VMware Live Site Recovery Appliance zu installieren. Vor dem Ausführen von SRA-Workflows sind auf den Quell- und Ziel-Clustern dieselben benutzerdefinierten SnapMirror Zeitpläne zu verwenden. In einer neuen SRA-Konfiguration sollte immer ein Test-Failover ausgeführt werden; wird dieser übersprungen, kann der Reprotect-Vorgang fehlschlagen. Die Einrichtungsschritte finden Sie in "Konfigurieren Sie SRA in ONTAP tools, um Datastores zu schützen".

Die SRA unterstützt NFSv3-Datenspeicher und VMFS-Datenspeicher auf iSCSI und FC. Disaster Recovery wird für NVMe-oF-Datenspeicher nicht unterstützt, und VMware Live Site Recovery unterstützt keine arraybasierte Replikation für NFSv4.1- oder FlexGroup-Datenspeicher. Konsistenzgruppen werden nur für iSCSI und FC unterstützt; das Hinzufügen von NFS-Volumes zu einer Konsistenzgruppe führt zu einem Fehler bei der Geräteerkennung.

Der Host-Cluster-Schutzworkflow verwendet SnapMirror active sync für VMFS-Datastores. ONTAP tools 10.6 unterstützt außerdem granularen Datastore-Schutz, mit dem Sie geeignete VMFS-Datastores mit iSCSI oder FC auswählen und den Schutz auf Schutzgruppen-Level anwenden können. SRA lässt sich stattdessen in VMware Live Site Recovery für arraybasierte Disaster-Recovery-Workflows integrieren. Einzelheiten zur Eignung finden Sie in "Granulare Kriterien für den Schutz von Datenspeichern in ONTAP Tools".

Der Zugriff wird in zwei Umgebungen gesteuert: Die Berechtigungen von vCenter Server regeln den Zugriff auf vSphere Objekte, und ONTAP Rollen steuern Storage-Vorgänge. ONTAP tools prüft zuerst die vCenter Rolle und anschließend die ONTAP Rolle, die dem Storage-Backend zugeordnet ist. ONTAP tools erstellt keine Benutzerkonten in vCenter oder ONTAP, daher erstellen Administratoren die erforderlichen Dienstkonten. Weitere Informationen enthält "Informationen zu rollenbasierter Zugriffssteuerung (RBAC) in ONTAP tools".

Da ONTAP tools keine Benutzerkonten in vCenter oder ONTAP erstellt, muss ein vSphere Administrator die erforderlichen Service Accounts erstellen und in beiden Umgebungen Rollen zuweisen. In vCenter Server erweitert ONTAP tools das RBAC-Modell um zusätzliche Objekte, die über das Remote-Plug-in verfügbar gemacht werden. In ONTAP wird der Zugriff über eine ONTAP Rolle gesteuert, die dem Benutzer zugewiesen ist, den Sie bei der Authentifizierung eines Storage Backends angeben. ONTAP tools stellt vordefinierte Rollen und JSON-Rollendateien bereit, mit denen Sie die für Storage Backend Vorgänge erforderlichen Mindestberechtigungen zuweisen können. Einrichtungsschritte sind unter "Wie die rollenbasierte Zugriffssteuerung (RBAC) von vCenter Server mit ONTAP tools for VMware vSphere funktioniert" und "Konfigurieren Sie ONTAP Benutzerrollen und -Berechtigungen für ONTAP tools" beschrieben.

Ab ONTAP tools 10.5 sind Backups standardmäßig aktiviert und werden alle 10 Minuten ausgeführt. Die Backup-Dateien werden im Datastore gespeichert und ermöglichen es Ihnen, die ONTAP tools Appliance selbst neu einzusetzen und wiederherzustellen, falls die ursprüngliche virtuelle Maschine verloren geht; sie sind kein Backup der ONTAP Cluster- oder vCenter Server-Konfiguration, die ONTAP tools managt. Sie können die Häufigkeit auf einen Wert zwischen 10 und 60 Minuten ändern. Die Schritte finden Sie unter "ONTAP tools-Sicherungseinstellungen bearbeiten" und "ONTAP tools für VMware vSphere aus der Sicherung wiederherstellen".

Sie können Backups zwar deaktivieren, sollten dies aber nicht tun, da dies ONTAP tools daran hindert, ein niedriges Wiederherstellungspunktziel (RPO) beizubehalten. Das Deaktivieren von Backups löscht keine vorhandenen Backup-Dateien. Die Schritte finden Sie unter "ONTAP tools-Sicherungseinstellungen bearbeiten".

Sie können ein Protokollpaket in ONTAP tools Manager oder über den vSphere Client erstellen. Ein in ONTAP tools Manager erstelltes Paket enthält Protokolle für alle verwalteten vCenter Server-Instanzen; ein im vSphere Client erstelltes Paket ist auf den ausgewählten vCenter Server begrenzt. Das erstellte Archiv kann heruntergeladen und dem technischen Support auf Anfrage zur Verfügung gestellt werden. Die Schritte finden Sie unter "Fehlercodes bei der Bereitstellung von ONTAP tools".

Zusätzlich zu einem Protokollpaket können Sie über die Managementplattform den Remote-Diagnosezugriff (SSH) auf das diag Benutzerkonto aktivieren. Es ist jeweils nur eine diag Anmeldesitzung zulässig, und der Zugriff wird automatisch um Mitternacht des folgenden Tages oder bei einer erneuten Anmeldung als diag Benutzer deaktiviert. Dieser Zugriff ist für eine tiefergehende Fehlerbehebung vorgesehen, die über den Umfang eines Protokollpakets hinausgeht, und zunächst sollte ein Protokollpaket erstellt werden, damit der technische Support über die Basisprotokolle verfügt. Die Schritte sind in "Konfigurieren Sie den Ferndiagnosezugriff für ONTAP tools" beschrieben.

Ein direktes Upgrade ist von den beiden Releases unmittelbar vor dem neuesten Release (N-2) möglich. Wenn Ihr System weiter zurückliegt, ist zunächst ein Upgrade auf den ältesten Release erforderlich, der ein direktes Upgrade auf den neuesten Release unterstützt, und danach ein weiteres Upgrade auf den neuesten Release. Vor dem Start ist das Low-RPO-Backup zu aktivieren und das Backup herunterzuladen, da ein fehlgeschlagenes Upgrade nicht immer rückgängig gemacht werden kann und die Wiederherstellung dann vom Low-RPO-Backup oder von der Snapshot-Wiederherstellung abhängt. Die unterstützten Upgrade-Pfade und -Schritte sind unter "Upgrade von ONTAP tools für VMware vSphere 10.x auf 10.6" aufgeführt.

Die Migration wird nur von bestimmten ONTAP tools 9.x Versionen unterstützt. Der Migrationspfad hängt davon ab, ob Ihre Umgebung vVols verwendet: Umgebungen mit vVols migrieren den VASA Provider und aktualisieren SRA, während Umgebungen mit ausschließlich NFS- und VMFS-Datastores das 9.x Deployment entfernen und 10.x einsetzen. vVols Datastores, die NVMe/FC verwenden, sind nach der Migration nicht mehr betriebsbereit, da ONTAP tools 10.x NVMe-oF nur mit VMFS-Datastores unterstützt. Siehe "Migration von ONTAP tools für VMware vSphere 9.xx auf 10.6" für die unterstützten Quellversionen und Schritte.

Ja. ONTAP tools bietet eine separate REST-API für die Automatisierung, unabhängig von der ONTAP Cluster REST-API. Der API-Zugriff verwendet die IP-Adresse von ONTAP tools und Port 8443; zur Authentifizierung mit den Anmeldeinformationen von ONTAP tools Manager wird ein Zugriffstoken abgerufen, das anschließend im x-auth Header gesendet wird. Lang laufende Vorgänge können asynchron ausgeführt werden und einen zu überwachenden Job zurückgeben. Informationen für den Einstieg finden Sie unter "Erfahren Sie mehr über die ONTAP tools REST API" und "Führen Sie Ihren ersten ONTAP tools REST API-Aufruf durch".