ESXi und NFS 4.1: Features und Einschränkungen


    Tags: , , ,

    Datastore mit NFS 4.1 in ESXi Host ClientVMware unter­stützt seit der Version 6.0 von ESXi bzw. vSphere das Speichern von virtu­ellen Ma­schinen auf Frei­gaben, die über NFS 4.1 expor­tiert wurden. Das bringt Verbes­serungen in Hin­blick auf Siche­rheit und Per­formance, gleich­zeitig muss man auf solchen NFS-Shares aber auf einige ver­traute 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 unver­schlüsselten Übertragung der Daten und fehlendes Load Balancing.

    Authentifizierung über Kerberos

    NFS 4.1 bringt nun zusätzliche Sicherheit durch Kerberos-Authenti­fizierung, 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.

    Bei NFS 4 blendet der Host Client die Felder für Username und Passwort ein, wenn der Host Mitglied eines AD-Domäne ist.

    Die unter NFS 3 einzig verfügbare Authenti­fizierung ü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 Ausfall­sicherheit, 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.

    Eingabe von Pfad und Server für die NFS-Freigabe. Hier lässt sich auch Session Trunking einrichten.

    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 Lastver­teilung 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än­kungen 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.

    Unter ESXi 6.0 stehen bei Verwendung von NFS 4.1 einige Features nicht zur Verfügung.

    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 bereit­gestellt 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.

    Keine Kommentare