Grundlagen zu vSphere 6: Shared Storage mit VMFS- und NFS-Datastores

Shared Storage: VMFS versus NFS

Ein Cluster-fähiges Dateisystem ist jedoch zwingende Voraussetzung für Shared-Storage, der wiederrum für vMotion sowie Cluster-Features wie VMware HA (High Availability), VMware FT (Fault Tolerance) oder Distributed Resource Scheduling (DRS) benötigt wird. NFS 3 ist – abgesehen vom Authentifizierungsthema (NFS 3 arbeitet grundsätzlich mit Root-Rechten) – besser als sein Ruf und stellt gerade für kleine Unternehmen mit schmalbandiger Netzwerkanbindung (1 Gbs) die einzige Möglichkeit dar, Netzwerk-Storage einigermaßen performant anzubinden.

Eine iSCSI-Anbindung mit einem ausgewachsenen SAN böte zwar den Vorteile, blockbasierten Storage mit VMFS-Dateisystem (VMware Virtual Machine File System) nutzen zu können, bei 1Gbs-iSCSI ist der Protokoll-Overhead allerdings deutlich höher. Gerade kleine SAN-Geräte mit Atom-CPUs, mit denen Hersteller wie Synology oder Qnap kleine Unternehmen adressieren, schwächeln dann spürbar.

NFS-Datastores

Ist eine NFS-Freigabe vorhanden und sind die benötigten Verbindungsparameter wie Name oder IP des NFS-Servers sowie der Namen des freigegebenen Ordners bekannt, lässt sich ein NFS-basierter Datastore einfach zum Beispiel im vSphere Web Client in der Datastore-Ansicht mit Hilfe des Assistenten Storage/New Datastore nach Auswahl der Option NFS mounten und bei Bedarf auch wieder unmounten.

Letzteres hat wie das Löschen eines NFS-Datastores keinen Einfluss auf die Daten am Backend, weil vSphere bei NFS keine Kontrolle über das unterliegende Dateisystem hat. VMDK-Dateien sind daher bei virtuellen Maschinen, die einen NFS-Datastore nutzen, standardmäßig vom Typ Thin-Provisioning. Für virtuelle Thick provisionierte VMDKs benötigt man ein NAS-System, das entsprechende VAAI-Primitive (vStorage API for Array Integration) für NFS unterstützt.

VMFS-Datastores

Flexibler, weil im laufenden Betrieb erweiterbar, sind VMFS-Datastores. Hier „sieht“ und nutzt ESXi eine oder mehrere physische Disks exklusiv und formatiert diese mit VMwares Cluster-Dateisystem VMFS 5. Bei den unterliegenden Block-Devices kann es sich um lokale SAS-, beziehungsweise SATA-Devices, um ein entsprechendes RAID-System oder um von einem externen SAN präsentierte LUNs handeln.

Lokale Platten sind allerdings als Backend für Shared Storage quasi wertlos, sieht man einmal von der sich gezielt an kleine Unternehmen richtenden Möglichkeit ab, mittels „Shared Nothing vMotion“ auch ohne Shared Storage virtuelle Maschinen zur Laufzeit verschieben zu können, in dem der Storage einfach mit auf den Ziel-ESXI-Host umzieht, wenn dieser ebenfalls lokale Platten nutzt.

Für echten Shared Storage kommen abgesehen von VMware vSAN nur LUNs in Frage. Übrigens unterstützt ESXi lokale SATA-Festplatten am Host-System erst aber Version 4.0. Beim Präsentieren der benötigten LUNs muss gegebenenfalls SAN-seitig darauf geachtet werden, dass das Gerät den multiplen Zugriff mehrere ESXI-Hosts erlaubt.

Sind die Voraussetzungen auf der SAN-Seite erfüllt und die entsprechenden Pfade vSphere-seitig am Storage-Adapter sichtbar, kann der Administrator mit dem Einrichten von VMFS-Datastores beginnen. Dies schließt auch ein, dass zum Beispiel bei einem iSCSI-Target die erforderlichen Netzwerkeinstellungen (etwa für iSCSI) auf allen Hosts identisch konfiguriert sind (zum Beispiel mit Hilfe eines Distributed vSwitch).

Einrichten eines VMFS-Datastores

Der Assistent ist der Gleiche wie bei NFS, nur dass der Anwender hier im zweiten Schritt bei Typ den ersten Eintrag VMFS wählt. Dort vergibt er einen Namen für den Datastore und wählt im Klappmenü darunter den oder die ESXi-Hosts aus, die auf den neuen Datastore zugreifen dürfen. Anschließend kann er eine der vom jeweiligen Storage-Gerät präsentierten LUNs auswählen und wahlweise mithilfe der Default-Einstellung Use all available Partitions komplett mit VMFS 5 formatieren oder unter Zuhilfenahme des Sliders partitionieren.

Letzteres bietet später die Möglichkeit, bei steigendem Platzbedarf den Datastore allein vSphere-seitig ohne erneute Nachfrage beim Storage-Admin zu vergrößern. Andernfalls müsste der vSphere-Admin den Storage-Admin bitten, die betreffende LUN zu vergrößern (Expand) oder weitere LUNs bereitzustellen, die der vSphere-Admin dann verwendet, um den VMFS-Datastores mit so genannten Extents zu erweitern.

Da Extents allerdings kein echtes Stripe-Set darstellen, das zudem keine „Unterbrechung“ durch ein defektes Extent (LUN) toleriert, ist das Vergrößern von VMFS-Datastores mittels Expanding dem Anfügen von Extents vorzuziehen. Zum Vergrößern eines VMFS-Datastores steht im Gegensatz zu NFS-Datastores bei markiertem Datastore in der Datastore-Ansicht im Tab Manage unter Settings im Abschnitt General die Schaltfläche Increase zur Verfügung.

Hier wählt der Nutzer als Ziel-LUN für einen Expand-Vorgang diejenige aus, auf der der Datastore bereits basiert. Im Fall eines Extents dagegen eine oder mehrere zusätzliche noch nicht verwendete LUN. Welche LUNs als Extents in einem Datastore „verbaut“ sind, ist im Tab Manage/Settings im Bereich Device Backing zu erkennen.

Datastores verkleinern oder Löschen

Verkleinern lässt sich ein Datastore allerdings nicht, wozu in der Praxis allerdings auch nur selten Anlass bestehen sollte. Hier müsste man einen Datastore mittels Storage vMotion „leeräumen“, dann komplett löschen und anschließend einen neuen Datastore erstellen. Aber Achtung beim Entfernern von LUNs in einer vSphere-Umgebung, denn bevor man eine LUN endgültig löscht, müssen unbedingt folgende Bedingung geprüft werden:

•  es dürfen keine VMs oder Templates auf der LUN liegen,
• die LUN darf nicht mehr als RDM (Raw Device Mapping) verknüpft sein,
• die LUN darf nicht mehr Mitglied eines Datastore Clusters sein,
• die LUN darf nicht mehr per Storage DRS verwaltet werden,
• die LUN darf nicht für den Datastore Heartbeat verwendet werden,
• Storage I/O Control muss für diese LUN deaktiviert sein.

VMFS ist ein modernes Cluster-fähiges Dateisystem, das für den Betrieb von virtualisierten Umgebungen – hier kommt es unter anderem auf die Verwaltbarkeit großer (VMDK)-Dateien an – optimiert ist. So können VMFS-Datastores bis zu 64 TB groß werden und unterstützen Dateien bis zu einer Größe von 62 TB.

Insofern bieten Datastores auf VMFS-Basis als Shared Storage eine größere Flexibilität als NFS-Freigaben. Selbstverständlich muss der unterliegende Netzwerk-Stack (Fibre Channel oder iSCSI) den Performance-Anforderungen genügen. Bei iSCSI ist daher eine 10-Gbs-Verkabelung Pflicht und zwar möglichst redundant, da Enterprise-Storage stets mit mehreren Pfaden angebunden sein sollte. Beim iSCSI-Initiator reicht aber problemlos auch der in vSphere vorhandene Softwareadapter.

Im FC-Bereich hingegen erzielen auch 8-Gbs-Adapter aufgrund des geringeren Overheads eine akzeptable Performance. VMFS liegt aktuell in Version 5 vor, die VMware mit vSphere 5 veröffentlicht hat. Neben dem erwähnten Block-Level-Locking und der dynamischen Erweiterbarkeit punktet VMFS mit eine Block-Größe von 1 MB, beherrscht aber Subblock-Adressing. Somit verwendet VMFS bei sehr kleinen Dateien Sub-Blöcke mit einer Größe von 8 KB, was angesichts der Default-Block-Size von 1 MB den zu befürchtenden Verschnitt minimiert.

vSphere 6 kennt neben VMFS- und NFS-Datastores sowie Datastore-Clustern aber auch VVOL-Datastores (Virtual Volumes) und VSAN-Storage-Cluster. Beide implementieren unter anderem VMwares neue Philosophie des Storage-Policy-based-Management.

Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!