Skip to main content
Enterprise applications
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Übersicht über vSphere Datastore- und Protokollfunktionen

Beitragende

Sieben Protokolle können für die Anbindung von VMware vSphere ESXi Hosts an ONTAP Systeme für Datastores genutzt werden:

  • FCP

  • FCoE

  • NVMe/FC

  • NVMe/TCP

  • ISCSI

  • NFS v3

  • NFS 4.1

FCP, FCoE, NVMe/FC, NVMe/TCP und iSCSI sind Blockprotokolle. VMware Datastores werden über das vSphere Virtual Machine File System (VMFS) gespeichert, um VMs innerhalb von ONTAP LUNs oder NVMe Namespaces zu speichern, die in einem ONTAP FlexVol Volume enthalten sind. Beachten Sie, dass VMware ab vSphere 7.0 keine Software FCoE mehr in Produktionsumgebungen unterstützt. NFS ist ein File-Protokoll. Hierbei werden die Datastores nicht zusätzlich mit VMFS formatiert. VMs laufen direkt auf dem ONTAP Volume. SMB (CIFS), iSCSI, NVMe/TCP oder NFS kann direkt aus einem Gastbetriebssystem für ONTAP genutzt werden.

In der folgenden Tabelle sind die Funktionen herkömmlicher Datastores dargestellt ONTAP, die von vSphere unterstützt werden. Diese Informationen gelten nicht für VVols Datastores, sie gelten jedoch im Allgemeinen für vSphere 6.x bzw. neuere Versionen, bei denen unterstützte ONTAP Versionen verwendet werden. Sie können sich auch beraten "Maximalwerte für die VMware Konfiguration" Bestätigen Sie für bestimmte vSphere Versionen bestimmte Limits.

Funktion/Feature FC/FCoE ISCSI NVMe-of NFS

Formatieren

VMFS oder Raw Device Mapping (RDM)

VMFS oder RDM

VMFS

K. A.

Maximale Anzahl an Datastores oder LUNs

1024 LUNs pro Host

1024 LUNs pro Server

256 Namespeces pro Server

256 Halterungen
Standard-NFS. MaxVolumes ist 8. Erhöhen Sie mit den ONTAP Tools für VMware vSphere auf 256.

Maximale Datastore-Größe

64 TB

64 TB

64 TB

100 TB FlexVol Volume oder mehr mit FlexGroup Volume

Maximale Datastore-Dateigröße

62 TB

62 TB

62 TB

62 TB mit ONTAP 9.12.1P2 und höher

Optimale „Queue depth“ pro LUN oder Filesystem

64-256

64-256

Autonegotiation Ist Eingeschaltet

Siehe NFS.MaxQueueDepth in "Empfohlene ESXi Host-Einstellungen und andere ONTAP Einstellungen".

In der folgenden Tabelle sind die unterstützten Funktionen in Bezug auf VMware Storage aufgeführt.

Kapazität/Funktion FC/FCoE ISCSI NVMe-of NFS

VMotion

Ja.

Ja.

Ja.

Ja.

Storage vMotion

Ja.

Ja.

Ja.

Ja.

VMware HA

Ja.

Ja.

Ja.

Ja.

Storage Distributed Resource Scheduler (SDRS)

Ja.

Ja.

Ja.

Ja.

VMware vStorage APIs for Data Protection (VADP)-fähige Backup-Software

Ja.

Ja.

Ja.

Ja.

Microsoft Cluster Service (MSCS) oder Failover Clustering in einer VM

Ja.

Ja*

Ja*

Nicht unterstützt

Fehlertoleranz

Ja.

Ja.

Ja.

Ja.

Site Recovery Manager

Ja.

Ja.

Nein**

Nur V3**

VMs (virtuelle Festplatten) mit Thin Provisioning

Ja.

Ja.

Ja.

Ja.
Diese Einstellung ist der Standard für alle VMs im NFS, wenn nicht VAAI verwendet wird.

Natives VMware Multipathing

Ja.

Ja.

Ja, Verwendung des neuen High Performance Plug-ins (HPP)

Für das NFS v4.1 Session-Trunking ist ONTAP 9.14.1 und höher erforderlich

In der folgenden Tabelle werden die unterstützten ONTAP Storage-Managementfunktionen aufgeführt.

Funktion/Feature FC/FCoE ISCSI NVMe-of NFS

Datendeduplizierung

Einsparungen im Array

Einsparungen im Array

Einsparungen im Array

Einsparungen im Datastore

Thin Provisioning

Datenspeicher oder RDM

Datenspeicher oder RDM

Datenspeicher

Datenspeicher

Datenspeichergröße ändern

Erweitern Sie nur

Erweitern Sie nur

Erweitern Sie nur

Vergrößerung, Autogrow und Verkleinerung

SnapCenter Plug-ins für Windows, Linux Applikationen (in Gast-BS)

Ja.

Ja.

Nein

Ja.

Monitoring und Host-Konfiguration mit ONTAP Tools für VMware vSphere

Ja.

Ja.

Nein

Ja.

Bereitstellung mit ONTAP Tools für VMware vSphere

Ja.

Ja.

Nein

Ja.

In der folgenden Tabelle sind die unterstützten Backup-Funktionen aufgeführt.

Funktion/Feature FC/FCoE ISCSI NVMe-of NFS

ONTAP Snapshots

Ja.

Ja.

Ja.

Ja.

Durch replizierte Backups unterstütztes SRM

Ja.

Ja.

Nein**

Nur V3**

Volume SnapMirror

Ja.

Ja.

Ja.

Ja.

VDMK Image-Zugriff

VADP fähige Backup-Software

VADP fähige Backup-Software

VADP fähige Backup-Software

VADP fähige Backup-Software, vSphere Client und vSphere Web Client Datastore-Browser

VDMK-Zugriff auf Dateiebene

VADP fähige Backup-Software, nur Windows

VADP fähige Backup-Software, nur Windows

VADP fähige Backup-Software, nur Windows

VADP fähige Backup-Software und Applikationen von Drittanbietern

NDMP-Granularität

Datenspeicher

Datenspeicher

Datenspeicher

Datastore oder VM

*NetApp empfiehlt für Microsoft Cluster die Verwendung von in-Guest iSCSI anstelle von Multiwriter-fähigen VMDKs in einem VMFS Datastore. Dieser Ansatz wird von Microsoft und VMware vollständig unterstützt. Er bietet mit ONTAP ein hohes Maß an Flexibilität (SnapMirror auf ONTAP Systeme vor Ort oder in der Cloud), lässt sich leicht konfigurieren und automatisieren und kann mit SnapCenter gesichert werden. In vSphere 7 wurde eine neue Clustered VMDK-Option hinzugefügt. Dies unterscheidet sich von VMDKs mit mehreren Schreibenden, die einen Datenspeicher benötigen, der über das FC-Protokoll bereitgestellt wird, für das die Unterstützung für geclusterte VMDK aktiviert ist. Weitere Einschränkungen sind möglich. VMware's ansehen "Einrichtung für Windows Server Failover Clustering" Dokumentation für Konfigurationsrichtlinien.

**Datastores mit NVMe-of und NFS v4.1 erfordern die vSphere Replizierung. Array-basierte Replizierung wird von SRM nicht unterstützt.

Auswahl eines Storage-Protokolls

Systeme mit ONTAP Software unterstützen alle wichtigen Storage-Protokolle, sodass die Kunden das für ihre Umgebung am besten geeignete Protokoll auswählen können. Dies hängt von der vorhandenen und geplanten Netzwerkinfrastruktur und den Fähigkeiten der Mitarbeiter ab. Bei von NetApp durchgeführten Tests zeigten sich generell nur geringfügige Unterschiede zwischen Protokollen, die mit ähnlichen Übertragungsgeschwindigkeiten ausgeführt wurden. Daher empfiehlt es sich, den Schwerpunkt in erster Linie auf die Netzwerkinfrastruktur und die Fähigkeiten der Mitarbeiter und erst in zweiter Linie auf die ursprüngliche Protokoll-Performance zu legen.

Die folgenden Faktoren könnten bei Überlegungen zur Auswahl eines Protokolls hilfreich sein:

  • Gegenwärtige Kundenumgebung. Obwohl IT-Teams normalerweise erfahren sind, um Ethernet IP-Infrastrukturen zu managen, sind nicht alle erfahren im Management einer FC SAN Fabric. Die Nutzung eines nicht auf Storage-Traffic ausgelegten dedizierten IP-Netzwerks ist jedoch unter Umständen keine gute Lösung. Berücksichtigen Sie Ihre vorhandene Netzwerkinfrastruktur, alle geplanten Optimierungen sowie die Fähigkeiten und die Verfügbarkeit von Mitarbeitern, die diese managen.

  • Einfache Einrichtung. über die Erstkonfiguration der FC-Fabric hinaus (zusätzliche Switches und Kabel, Zoning und die Verifizierung der Interoperabilität von HBA und Firmware) müssen Blockprotokolle auch LUNs erstellen und zuordnen sowie vom Gastbetriebssystem Erkennung und Formatierung vornehmen. Nach der Erstellung und dem Export der NFS-Volumes werden sie vom ESXi Host gemountet und sind dann betriebsbereit. Für NFS sind keine besonderen Hardwarequalifizierungen oder Firmware für das Management erforderlich.

  • Einfaches Management. bei SAN-Protokollen sind bei Bedarf mehrere Schritte erforderlich, darunter das Vergrößern einer LUN, das erneute Erkennen der neuen Größe und das Anwachsen des Dateisystems). Obwohl eine LUN vergrößert werden kann, ist eine Reduzierung der Größe einer LUN nicht möglich. Auch das Recovery von ungenutztem Speicherplatz kann weiteren Aufwand bedeuten. NFS ermöglicht eine problemlose Größenanpassung, die durch das Storage-System automatisiert werden kann. SAN bietet über TRIM/UNMAP-Befehle des Gast-Betriebssystems eine Speicherplatzrückgewinnung, sodass Speicherplatz aus gelöschten Dateien an das Array zurückgegeben werden kann. Diese Art der Rückgewinnung von ungenutztem Speicherplatz ist bei NFS-Datenspeichern schwieriger.

  • Storage-Speicherplatztransparenz. die Storage-Auslastung ist in NFS-Umgebungen in der Regel einfacher zu erkennen, da Thin Provisioning unmittelbare Einsparungen ermöglicht. In ähnlicher Form sind Einsparungen durch Deduplizierung und Klonen unmittelbar für andere VMs im selben Datastore oder für Storage-System-Volumes verfügbar. Die VM-Dichte ist typischerweise ebenfalls größer als in einem NFS-Datastore. Hierdurch können höhere Einsparungen bei der Deduplizierung sowie eine Senkung der Managementkosten erzielt werden, da weniger Datastores gemanagt werden müssen.

Datenspeicher-Layout

ONTAP Storage-Systeme bieten beim Erstellen von Datastores für VMs und virtuelle Festplatten ein hohes Maß an Flexibilität. Obwohl viele ONTAP Best Practices angewendet werden, wenn Datastores für vSphere mit VSC bereitgestellt werden (siehe Abschnitt) "Empfohlene ESXi Host-Einstellungen und andere ONTAP Einstellungen"), hier sind einige zusätzliche Richtlinien zu berücksichtigen:

  • Der Einsatz von vSphere mit ONTAP-NFS-Datastores sorgt für eine hochperformante, einfach zu managende Implementierung mit VM/Datastore-Verhältnissen, die mit blockbasierten Storage-Protokollen nicht erreicht werden können. Diese Architektur kann zu einer Verzehnfachung der Datastore-Dichte und einer damit korrelierenden Verringerung der Datastore-Anzahl führen. Obwohl ein größerer Datastore die Storage-Effizienz begünstigen und betriebliche Vorteile bieten ONTAP kann, sollten Sie mindestens vier Datastores (FlexVol Volumes) verwenden. Durch die Verteilung der Datastores auf die Controller kann so die bestmögliche Ausnutzung der Hardware gewährleistet werden. Mit diesem Ansatz können Sie auch Datastores mit unterschiedlichen Recovery-Richtlinien erstellen. Einige können je nach den geschäftlichen Anforderungen häufiger gesichert oder repliziert werden als andere. Da FlexGroup Volumes eine Skalierung pro Design durchführen, sind für mehrere Datastores nicht erforderlich.

  • NetApp empfiehlt die Verwendung von FlexVol Volumes für die meisten NFS-Datastores. Ab ONTAP 9.8 werden FlexGroup Volumes auch für die Nutzung als Datastores unterstützt und für bestimmte Anwendungsfälle im Allgemeinen empfohlen. Andere ONTAP Storage-Container wie qtrees werden im Allgemeinen nicht empfohlen, da diese derzeit weder durch ONTAP Tools für VMware vSphere noch durch das NetApp SnapCenter Plug-in für VMware vSphere unterstützt werden. Indessen könnte die Implementierung von Datastores als mehrere qtrees in einem einzelnen Volume in hoch automatisierten Umgebungen nützlich sein, die von Kontingenten auf Datastore-Ebene oder VM-Dateiklonen profitieren können.

  • Eine gute Größe für einen FlexVol Volume-Datastore liegt bei etwa 4 TB bis 8 TB. Diese Größe bildet einen guten Ausgleichspunkt im Hinblick auf Performance, einfaches Management und Datensicherung. Beginnen Sie mit einem kleinen Datastore (beispielsweise 4 TB) und vergrößern Sie diesen nach Bedarf (bis auf maximal 100 TB). Kleinere Datenspeicher lassen sich nach einem Backup oder nach einem Ausfall schneller wiederherstellen und können schnell im Cluster verschoben werden. Die automatische Größenanpassung von ONTAP kann sinnvoll sein, um das Volume bei wechselnder Speicherplatzbelegung automatisch zu vergrößern oder zu verkleinern. Der ONTAP Tools für die Bereitstellung von VMware vSphere Datastores verwendet Autosize standardmäßig für neue Datastores. Eine weitere Anpassung der Vergrößerungs- und Verkleinerungsschwellenwerte sowie der maximalen und minimalen Größe kann mit System Manager oder über die Befehlszeile erfolgen.

  • Alternativ können VMFS Datastores mit LUNs konfiguriert werden, auf die über FC, iSCSI oder FCoE zugegriffen wird. Bei VMFS können alle ESX Server in einem Cluster gleichzeitig auf herkömmliche LUNs zugreifen. VMFS Datastores können eine Größe von bis zu 64 TB haben und bestehen aus bis zu 32 2TB LUNs (VMFS 3) oder einer einzelnen 64-TB-LUN (VMFS 5). Die maximale LUN-Größe von ONTAP beträgt auf den meisten Systemen 16 TB und 128 TB auf All-SAN-Array-Systemen. Daher kann auf den meisten ONTAP Systemen ein VMFS 5 Datastore mit maximaler Größe aus vier 16-TB-LUNs erstellt werden. Für Workloads mit hohem I/O-Aufkommen und mehreren LUNs (bei High-End FAS oder AFF Systemen) können Performance-Vorteile zum Tragen kommen, allerdings werden diese durch das komplexere Management beim Erstellen, Managen und Sichern der Datastore-LUNs und ein erhöhtes Verfügbarkeitsrisiko ausgeglichen. NetApp empfiehlt im Allgemeinen, eine einzelne, große LUN für jeden Datastore zu verwenden. Und nur im Ausnahmefall, wenn größere Datastores mit über 16 TB gebraucht werden, mit Extends zu arbeiten. Analog zu dem NFS Ansatz, verteilen ONTAP Sie ebenfalls die Datastores über die Controller, um die bestmögliche Performance zu erzielen.

  • Ältere Gastbetriebssysteme (OS) mussten an das Storage-System angeglichen werden (Alignment), um die bestmögliche Performance und Storage-Effizienz zu erzielen. Bei modernen Betriebssystemen mit Anbieterunterstützung von Microsoft und Linux Distributoren wie Red hat sind jedoch keine Anpassungen mehr erforderlich, um die Filesystem-Partition mit den Blöcken des zugrunde liegenden Storage-Systems in einer virtuellen Umgebung zu alignen. Wenn Sie ein altes Betriebssystem verwenden, für das unter Umständen ein Alignment erforderlich ist, suchen Sie in der NetApp Support Knowledgebase nach Artikeln, in denen das Thema VM Alignment behandelt wird, oder fordern Sie bei einem NetApp Ansprechpartner für den Vertrieb oder für Partner ein Exemplar des technischen Berichts TR-3747 an.

  • Vermeiden Sie die Verwendung von Defragmentierungsprogrammen innerhalb des Gast-Betriebssystems, da dies keinen Performance-Vorteil bietet und die Speichereffizienz und Snapshot-Speicherplatznutzung beeinträchtigt. Zudem sollten Sie die Suchindizierung im Gastbetriebssystem für virtuelle Desktops deaktivieren.

  • ONTAP ist eines der branchenweit führenden Unternehmen mit innovativen Storage-Effizienzfunktionen, mit denen Sie Ihren nutzbaren Festplattenspeicherplatz maximal ausschöpfen können. AFF Systeme sind durch Inline-Deduplizierung und -Komprimierung sogar noch effizienter. Die Daten werden über alle Volumes hinweg in einem Aggregat dedupliziert. Daher müssen zur Maximierung der Einsparungen keine ähnlichen Betriebssysteme und ähnlichen Applikationen in einem einzelnen Datastore mehr gruppieren.

  • In einigen Fällen benötigen Sie eventuell nicht einmal einen Datastore. Um die beste Performance und ein optimales Management zu erzielen, sollten Sie für Applikationen mit hohem I/O-Aufkommen – beispielsweise für Datenbanken und bestimmte Applikationen – keinen Datastore verwenden. Hier sind „inguest“-Ansätze via NFS oder iSCSI in Erwägung zu ziehen, die vom Gastbetriebssystem verwaltet werden oder via Raw Device Mapping (RDM). Eine Anleitung zu bestimmten Applikationen finden Sie in den technischen Berichten von NetApp für die jeweilige Applikation. Beispiel: "Oracle-Datenbanken auf ONTAP" Ein Abschnitt zur Virtualisierung mit hilfreichen Details.

  • Festplatten der ersten Klasse (oder verbesserte virtuelle Festplatten) ermöglichen über vCenter gemanagte Festplatten unabhängig von einer VM mit vSphere 6.5 und höher. Sie werden zwar primär durch API gemanagt, sind aber auch mit VVols nützlich, insbesondere bei dem Management mit OpenStack oder Kubernetes-Tools. Sie werden von ONTAP unterstützt sowie ONTAP Tools für VMware vSphere.

Datastore und VM-Migration

Wenn Sie VMs aus einem bestehenden Datastore in einem anderen Storage-System zu ONTAP migrieren, sollten Sie die folgenden Praktiken berücksichtigen:

  • Verwenden Sie Storage vMotion, um den Großteil Ihrer Virtual Machines in ONTAP zu verschieben. Dieser Ansatz ermöglicht nicht nur einen unterbrechungsfreien Betrieb der VMs, sondern auch die Nutzung von ONTAP Storage-Effizienzfunktionen wie Inline-Deduplizierung und -Komprimierung zur Verarbeitung der Daten während der Migration. Es empfiehlt sich unter Umständen, mithilfe von vCenter Funktionen mehrere VMs aus der Bestandsliste auszuwählen und die Migration dann zu einem geeigneten Zeitpunkt zu planen (dazu klicken Sie mit gedrückter Strg-Taste auf „Actions“).

  • Sie können eine Migration auf geeignete Ziel-Datastores zwar genau planen, doch es ist oft einfacher, große Datenmengen zu migrieren und diese anschließend nach Bedarf zu organisieren. Vielleicht möchten Sie diesen Ansatz nutzen, um Ihre Migration in verschiedene Datastores zu steuern, wenn Sie spezielle Datensicherungsanforderungen, z. B. unterschiedliche Snapshot Zeitpläne, haben.

  • Die meisten VMs und deren Storage können im Betrieb (eingeschalteter Zustand) migriert werden. Attached Storage (nicht im Datastore) – beispielsweise in Form von ISOs, LUNs oder NFS-Volumes – aus einem anderen Storage-System muss jedoch unter Umständen im ausgeschalteten Zustand migriert werden.

  • Virtual Machines, bei denen eine präzisere Migration erforderlich ist, sind unter anderem Datenbanken und Applikationen mit Nutzung von Attached Storage. Bei diesen sollten Sie die Migration im Allgemeinen mit den Applikationstools managen. Für Oracle empfiehlt sich zur Migration der Datenbankdateien die Nutzung von Oracle-Tools wie RMAN oder ASM. Siehe "TR-4534" Finden Sie weitere Informationen. Ganz ähnlich kommen für SQL Server entweder SQL Server Management Studio oder NetApp Tools wie SnapManager für SQL Server oder SnapCenter in Betracht.

ONTAP Tools für VMware vSphere

Wenn Sie vSphere mit ONTAP verwenden, ist es eine Best Practice, die ONTAP Tools für VMware vSphere Plug-in (ehemals Virtual Storage Console) zu installieren und zu verwenden. Dieses vCenter Plug-in vereinfacht das Storage-Management, erhöht die Verfügbarkeit und senkt die Storage-Kosten und den Betriebsaufwand – sei es bei SAN oder bei NAS. Dieses Plug-in nutzt Best Practices für die Bereitstellung von Datastores und optimiert die ESXi Hosteinstellungen für Multipath- und HBA-Timeouts (diese sind in Anhang B beschrieben). Da es sich um ein vCenter Plug-in handelt, ist es für alle vSphere Webclients verfügbar, die eine Verbindung mit dem vCenter Server herstellen.

Das Plug-in hilft Ihnen auch bei der Nutzung anderer ONTAP Tools in vSphere Umgebungen. Damit können Sie das NFS-Plug-in für VMware VAAI installieren, das einen Copy-Offload zu ONTAP für VM-Klonvorgänge, eine Speicherplatzreservierung für Thick Virtual Disk Files und ONTAP Snapshot Offload ermöglicht.

Das Plug-in ist auch die Managementoberfläche für viele Funktionen von VASA Provider für ONTAP und unterstützt das richtlinienbasierte Storage-Management mit VVols. Nach der Registrierung von ONTAP Tools für VMware vSphere erstellen Sie damit Storage-Funktionsprofile, ordnen diesen Storage zu und stellen im Laufe der Zeit die Datastore-Compliance mit den Profilen sicher. Vasa Provider verfügt auch über eine Schnittstelle zum Erstellen und Managen von vVol Datastores.

Im Allgemeinen empfiehlt NetApp zur Bereitstellung herkömmlicher und VVols Datastores die Verwendung der ONTAP Tools für die Schnittstelle VMware vSphere in vCenter, um die Einhaltung von Best Practices sicherzustellen.

Allgemeines Networking

Wenn Sie vSphere mit Systemen mit ONTAP Software verwenden, ist die Konfiguration von Netzwerkeinstellungen einfach und erfolgt ähnlich wie andere Netzwerkkonfigurationen. Folgende Punkte sind dabei zu berücksichtigen:

  • Separater Storage-Netzwerk-Traffic aus anderen Netzwerken. Ein separates Netzwerk kann mithilfe eines dedizierten VLANs oder separater Switches für Storage eingerichtet werden. Falls im Storage-Netzwerk physische Pfade wie Uplinks geteilt werden, sind eventuell QoS oder zusätzliche Uplink-Ports erforderlich, um eine ausreichende Bandbreite sicherzustellen. Stellen Sie keine direkte Verbindung zwischen Hosts und Storage her. Verwenden Sie Switches, um redundante Pfade zu verwenden und VMware HA ohne Eingriff von Microsoft HA zu arbeiten. Siehe "Direkte Netzwerkverbindung" Finden Sie weitere Informationen.

  • Jumbo Frames können genutzt werden, sofern dies gewünscht ist und von Ihrem Netzwerk unterstützt wird, insbesondere bei Verwendung von iSCSI. Vergewissern Sie sich bei ihrem Einsatz, dass sie auf allen Netzwerkgeräten, VLANs etc. Im Pfad zwischen Storage und dem ESXi Host gleich konfiguriert sind. Anderenfalls kann es zu Performance- oder Verbindungsproblemen kommen. Auf dem virtuellen ESXi Switch, dem VMkernel Port, sowie den physischen Ports oder den Interface Groups muss für jeden ONTAP Node auch jeweils dieselbe MTU festgelegt sein.

  • NetApp empfiehlt eine Deaktivierung der Netzwerk- Flusssteuerung nur an den Cluster-Netzwerkports innerhalb eines ONTAP Clusters. Für die übrigen Netzwerkports, die für Daten-Traffic verwendet werden, gibt NetApp im Hinblick auf Best Practices keine weiteren Empfehlungen. Diese Ports sollten Sie nach Bedarf aktivieren oder deaktivieren. Siehe "TR-4182" Für mehr Hintergrund zur Flusssteuerung.

  • Wenn ESXi und ONTAP Storage-Arrays mit Ethernet-Storage-Netzwerken verbunden werden, empfiehlt NetApp, die Ethernet-Ports, mit denen diese Systeme verbunden werden, mit der Cisco PortFast Funktion oder als Rapid Spanning Tree Protocol (RSTP)-Edge-Ports zu konfigurieren. NetApp empfiehlt die Aktivierung der Spanning Tree PortFast Trunk-Funktion in Umgebungen mit Verwendung der Cisco PortFast Funktion und 802.1Q VLAN-Trunking entweder für den ESXi Server oder für die ONTAP Storage-Arrays.

  • Für die Link-Aggregation empfiehlt NetApp die folgenden Best Practices:

    • Verwenden Sie Switches, die die Link-Aggregation von Ports in zwei separaten Switch-Chassis durch einen Ansatz mit einer Multi-Chassis-Link-Aggregationsgruppe wie Virtual PortChannel (vPC) von Cisco unterstützen.

    • Deaktivieren Sie LACP für mit ESXi verbundene Switch Ports, es sei denn, Sie verwenden dvSwitches ab 5.1 mit konfiguriertem LACP.

    • Erstellen Sie mit LACP Link-Aggregate für ONTAP Storage-Systeme mit dynamischen Multimode-Schnittstellengruppen mit Port- oder IP-Hash. Siehe "Netzwerkmanagement" Für weitere Hinweise.

    • Verwenden Sie eine IP-Hash-Teaming-Richtlinie für ESXi bei Verwendung von statischer Link-Aggregation (z. B. EtherChannel) und Standard-vSwitches oder LACP-basierter Link-Aggregation mit vSphere Distributed Switches. Wenn die Link-Aggregation nicht verwendet wird, verwenden Sie stattdessen „Weiterleiten basierend auf der ursprünglichen virtuellen Port-ID“.

Die folgende Tabelle enthält eine Zusammenfassung der Netzwerkkonfigurationselemente sowie Angaben dazu, wo die Einstellungen angewendet werden.

Element ESXi Switch Knoten SVM

IP-Adresse

VMkernel

Nein**

Nein**

Ja.

Link-Aggregation

Virtueller Switch

Ja.

Ja.

Nein*

VLAN

VMkernel und VM-Portgruppen

Ja.

Ja.

Nein*

Flusskontrolle

NIC

Ja.

Ja.

Nein*

Spanning Tree

Nein

Ja.

Nein

Nein

MTU (für Jumbo Frames)

Virtueller Switch und VMkernel Port (9000)

Ja (auf Maximalwert eingestellt)

Ja (9000)

Nein*

Failover-Gruppen

Nein

Nein

Ja (erstellen)

Ja (auswählen)

*SVM-LIFs werden mit Ports, Schnittstellengruppen oder VLAN-Schnittstellen verbunden, die über VLAN-, MTU- und andere Einstellungen verfügen. Diese Einstellungen werden jedoch nicht auf SVM-Ebene gemanagt.

**Diese Geräte haben eigene IP-Adressen für das Management, aber diese Adressen werden nicht im Zusammenhang mit ESXi Storage Networking verwendet.