Verwenden einer einzelnen logischen Schnittstelle (LIF) für jede SVM auf jedem Node im ONTAP-Cluster Die bisherigen Empfehlungen eines LIF pro Datenspeicher sind nicht mehr erforderlich. Der direkte Zugriff (LIF und Datastore auf demselben Node) ist zwar am besten, aber indirekte Zugriffe müssen sich keine Sorgen machen, da die Performance-Auswirkungen im Allgemeinen minimal sind (Mikrosekunden).

VMware unterstützt NFSv3 seit VMware Infrastructure 3. VSphere 6.0 bietet zusätzlich Unterstützung für NFSv4.1 und ermöglicht damit einige erweiterte Funktionen wie Kerberos Sicherheit. In NFSv3 wird „Client-side locking“ verwendet, in NFSv4.1 „Server-side locking“. Ein ONTAP Volume kann zwar mit beiden Protokollen exportiert werden, doch ESXi kann nur durch ein Protokoll gemountet werden. Bei diesem Einzelprotokoll-Mounting ist jedoch nicht ausgeschlossen, dass ESXi Hosts denselben Datastore auch durch eine andere Version mounten. Denken Sie daran, die beim Mounten verwendete Protokollversion anzugeben, damit alle Hosts dieselbe Version und somit auch denselben Sperrungsstil anwenden. Verwenden Sie auf verschiedenen Hosts nicht unterschiedliche NFS-Versionen. Falls möglich, prüfen Sie mithilfe von Hostprofilen die Compliance.

Zur Steuerung des Zugriffs durch vSphere Hosts kommen NFS-Exportrichtlinien zur Anwendung. Sie können eine Richtlinie für mehrere Volumes (Datastores) nutzen. Bei NFSv3 verwendet ESXi den Sicherheitsstil „sys“ (UNIX). Zur Ausführung von VMs ist dabei die Root-Mount-Option erforderlich. In ONTAP wird diese Option als Superuser bezeichnet. Wenn die Option Superuser verwendet wird, ist es nicht erforderlich, die anonyme Benutzer-ID anzugeben. Beachten Sie, dass Exportrichtlinien mit unterschiedlichen Werten für gelten -anon Und -allow-suid Die ONTAP-Tools können zu Problemen bei der SVM-Erkennung führen. Hier sehen Sie eine Beispielrichtlinie:

Wenn das NetApp NFS-Plug-in für VMware VAAI verwendet wird, sollte das Protokoll auf eingestellt werden nfs Statt nfs3 Wenn die Regel für die Exportrichtlinie erstellt oder geändert wird. Die Funktion für den Copy-Offload erfordert das NFSv4-Protokoll, selbst wenn das Datenprotokoll NFSv3 ist. Angeben des Protokolls als nfs Umfasst sowohl die NFSv3 als auch die NFSv4-Versionen.

NFS-Datastore-Volumes werden aus dem Root-Volume der SVM heraus verbunden. Daher muss ESXi zum Navigieren und Mounten von Datastore Volumes auch Zugriff auf das Root-Volume haben. Die Exportrichtlinie für das Root-Volume und für alle anderen Volumes, in denen die Verbindung des Datastore Volumes geschachtelt ist, muss eine oder mehrere Regeln für die ESXi Server einschließen, die ihnen schreibgeschützten Zugriff gewähren. Hier sehen Sie eine Beispielrichtlinie für das Root-Volume, bei der auch das VAAI Plug-in genutzt wird:

Verwenden Sie ONTAP Tools für VMware vSphere (die wichtigste Best Practice):

Obwohl ONTAP eine flexible Namespace-Struktur für Volumes bietet, in der Volumes mithilfe von Verbindungen in einer Baumstruktur angeordnet werden können, ist dieser Ansatz für vSphere nicht praktikabel. Für jede VM im Root-Verzeichnis des Datastores wird unabhängig von der Namespace-Hierarchie des Storage ein Verzeichnis erstellt. Daher besteht die Best Practice darin, den Verbindungspfad für Volumes für vSphere im Root-Volume der SVM zu erstellen. Dies entspricht auch der Art und Weise, wie ONTAP Tools für VMware vSphere Datastores bereitstellt. Ohne geschachtelte Verbindungspfade besteht bei Volumes zudem nur eine Abhängigkeit zum Root-Volume. Wenn ein Volume dann offline geschaltet oder sogar absichtlich zerstört wird, wirkt sich dies also nicht auf den Pfad zu den anderen Volumes aus.

Eine Blockgröße von 4 KB ist für NTFS-Partitionen auf NFS-Datenspeichern gut. In der folgenden Abbildung ist die Konnektivität eines vSphere Hosts zu einem ONTAP NFS-Datastore dargestellt.