Tags: Storage, ESXi, vSphere, NFS
VMware unterstützt seit der Version 6.0 von ESXi bzw. vSphere das Speichern von virtuellen Maschinen auf Freigaben, die über NFS 4.1 exportiert wurden. Das bringt Verbesserungen in Hinblick auf Sicherheit und Performance, gleichzeitig muss man auf solchen NFS-Shares aber auf einige vertraute vSphere-Features verzichten.
NAS als Storage für VMs haben den Vorteil, dass sie relativ einfach einzurichten und zu verwalten sind. Darüber hinaus gibt es eine breite Unterstützung für NFS, die von einfachen Linux-PCs über Windows Server bis zu SANs reicht.
Management pro VM
Ein weiteres Argument für File-basiertes Storage war bisher die VM-Granularität, weil Operationen wie Snapshots oder Replikation pro VM erfolgen können, während sie bei iSCSI- oder Fibrechannel-Speicher auf LUN-Ebene stattfinden. Dieser Vorzug schwindet in VMware-Umgebungen nun dank Virtual Volumes (VVols), mit deren Hilfe auch Block-basiertes Storage ein Per-VM-Management erlaubt.
Dennoch erfreuen sich File-Shares für virtuelle Maschinen ungebrochener Popularität, auch bei Microsoft. So sind SMB3 und dazugehörige Techniken wie RDMA oder SMB Multichannel sowie die Rolle des Scale-out File-Server explizit für die Speicherung von VMs unter Hyper-V ausgelegt.
VMware unterstützt langer Zeit NFS 3 und seit vSphere 6.0 auch die Version 4.1 des Network File Systems. NFS 3 leidet jedoch unter einigen Nachteilen wie der unverschlüsselten Übertragung der Daten und fehlendes Load Balancing.
Authentifizierung über Kerberos
NFS 4.1 bringt nun zusätzliche Sicherheit durch Kerberos-Authentifizierung, wenn die betreffenden Hosts Mitglied in einer AD-Domäne sind. In diesem Fall lässt sich ein Konto definieren, über das der Host auf den File-Server zugreift. Dadurch entfällt die Notwendigkeit, dem ESXi-Server für das NFS-Share root-Zugriff einzuräumen.
Die unter NFS 3 einzig verfügbare Authentifizierung über AUTH_SYS steht aber auch unter NFS 4.1 weiterhin zur Verfügung. Kerberos ist nur eine Option, die zudem voraussetzt, dass man IPv4 verwendet, die Version 6 des Internet-Protokolls wird zurzeit noch nicht unterstützt. Für NFS 4.1 mit AUTH_SYS gilt diese Einschränkung hingegen nicht.
Lastverteilung und Failover
Zu den Verbesserungen von NFS 4.1 zählt zudem die Unterstützung für Load Balancing und Failover. Verwendet man bei NFS 3 NIC-Teaming, dann erhöht sich dadurch die Ausfallsicherheit, aber die Verbindung bleibt auf eine TCP-Session für I/O beschränkt, so dass sich damit kein nennenswert höherer Durchsatz erzielen lässt.
Mit NFS 4.1 unterstützt VMware Session Trunking, allerdings nicht auf Basis von Parallel NFS (pNFS). Das setzt natürlich voraus, dass der NFS-Server dieses Feature ebenfalls beherrscht. Ein solches Multipathing erlaubt die Lastverteilung auf mehrere Pfade, die man im vSphere Web Client als Komma-separierte Liste von IP-Adressen hinterlegt.
Limitierungen von NFS 4.1 in ESXi 6.0
Der Einsatz von NFS 4.1 bringt aber auch einige Einschränkungen mit sich, weil VMware einige Features auf einem solchen Speicher aktuell noch nicht unterstützt. Dazu zählen Storage DRS, Storage I/O Control, Site Recovery Manager und Virtual Volumes.
Interessant in der Tabelle ist die Erwähnung von VVols, die bei NFS 3 verfügbar sind. Sie leisten mit ihrem Policy Based Management nämlich deutlich mehr als nur VM-Granularität, die NFS ja ohnehin selbst bietet.
Der Support von NFS 3 und 4.1 durch vSphere erfordert die Einhaltung bestimmter Regeln bzw. die Beachtung folgender Limitierungen:
- Ein Datastore darf nicht parallel über NFS 3 und 4.1 gemountet werden, wenn mehrere Hosts darauf zugreifen. Die beiden Protokolle verwenden verschiedene Locking-Mechanismen, so dass die Integrität der Daten gefährdet wäre.
- Um solche Probleme in gemischten Umgebungen aus ESXi 5.x und 6.0 zu vermeiden, ist es am sichersten, wenn man nur NFS 3 einsetzt. Das kann man dadurch gewährleisten, dass man ein Share am Server nur über diese Version von NFS exportiert.
- Ein Host ist in der Lage, Datastores mit jeweils verschiedenen NFS-Versionen gleichzeitig zu nutzen.
- Thick Provisioning von virtuellen Festplatten in NFS-4.1-Datenspeichern wird mangels VAAI-Support nicht unterstützt, nur Thin Provisioning.
- Gleichzeitiges Mounten von Datenspeichern mit AUTH_SYS und Kerberos ist nicht möglich.
- vSphere kann Datastores nicht von NFS 3 auf 4.1 konvertieren. Hierfür sollte man eine neue NFS-Freigabe mit der Version 4.1 einrichten und die VMs vom alten Share mit Storage vMotion dorthin verschieben. Alternativ kann man schauen, ob der NFS-Server ein Upgrade der Freigabe auf 4.1 erlaubt.
- Shares, die von Windows Server 2012 R2 oder 2016 bereitgestellt werden, mountet ESXi 6.0 (auch in Update 2) über NFS 4.1 automatisch als "Nur Lesen", selbst wenn man diese Option nicht aktiviert hat. Mit NFS 3 tritt dieses Problem nicht auf.
- Per Voreinstellung kann ESXi 6.0 maximal 8 NFS-Datastores mounten. Dieser Wert lässt sich über den Parameter NFS.MaxVolumes erhöhen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- VMware ESXi mit NFS-Freigabe verbinden
- Neu in vSAN 7 (U1): SMB in Native File Services, Support für Laufwerke bis 32TB, Hot-plug für NVMe
- Thin Provisioning unter VMware vSphere: VMDK, NFS, VAAI
- VMware vSphere 6.0 Update 2: Host Client 1.0, vSAN 6.2, 50 GBit-Ethernet
- ESXi 6.0 Free und vSphere Client: Einschränkungen und Funktionen
Weitere Links