vSAN und ESXi 6.5 - Video und Text

Einstieg in die Hyperkonvergenz mit VMware Virtual SAN 6.6

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Der vSAN-Kernel bringt mit Version 6.5 auch einer verbesserte vSAN-Version 6.6 mit, die zum Beispiel dank Unicast-Support performanter und robuster geworden ist.
Der vSAN-Kernel bringt mit Version 6.5 auch einer verbesserte vSAN-Version 6.6 mit, die zum Beispiel dank Unicast-Support performanter und robuster geworden ist. (Bild: VMware, Thomas Drilling)

Die hyperkonvergente, softwaredefinierte Storage-Software „Virtual SAN“ (vSAN) von VMware hat sich von der 2014 erschienenen Erstlings-Version 5.5 bis zur aktuellen Version 6.6 zu einem veritablen Enterprise-Storage gemausert, der inzwischen alle Zielgruppengrößen adressiert. Dieser Beitrag erläutert das Konzept von vSAN, klärt die Voraussetzungen hinsichtlich Hardware, Software und Lizenz und zeigt die Installation.

Hyperconverged-Lösungen vereinen Hypervisor (Compute) und Storage-Virtualisierung (Software-defined Storage) in einem „Gerät“, was je nach Sichtweise verschiedene Vorteile eröffnet.

So bringt der Hyperkonvergenz-Aspekt treffsicher zum Ausdruck, dass Hypervisor und Speichervirtualisierer auf der gleichen Hardware laufen. Das spart nicht nur Energie und Bereitstellungs-/Verwaltungskosten, sondern erlaubt auch ein zentralisiertes Storage-Management.

vSAN eröffnet VMware-Nutzern aber vor allem Kostenvorteile. So muss der Nutzer mit vSAN kein dediziertes Storage-Array-Network (SAN) mehr betreiben, das je nach Alter und Art schlecht, gar nicht oder nur mit hohem Kostenaufwand skaliert.

Die Box ist Commodity

Ferner funktioniert VMware Virtual SAN mit Commodity-Hardware, also auf im Vergleich zu spezialisierter Storage-Hardware preiswerten Standard-Servern, die sich mit Platten „von der Stange“ bestücken lassen. Denn die eigentliche Intelligenz des Storage steckt in der Software, also im Hypervisor und nicht mehr in Host-Bus-Adaptern, FC-Switchen oder Array-Betriebssystemen.

Die eingesparten Kosten - ein vSAN benötigt keine HBAs, oder RAID-Controller - können Kunden nach der Kalkulation von VMware in die vSAN-Lizenz investieren. Mit einer vSAN-Lizenz lassen sich die in den ESXi-Hosts vorhandenen Platten einer sinnvollen Verwendung zuführen, insbesondere wenn bereits Flash-Beschleunigerkarten existieren, die bis dato „nur“ für das Feature „VMware Virtual Flash Ressource“ zum Einsatz kamen.

Ein weiterer Kern-Aspekt von Virtual SAN ist das richtlinienbasierte Speicher-Management. Da es bei einer Software-basierten Storage-Lösung wie vSAN keine klassischen LUNs als begrenzenden Faktor für die Eigenschaften eines Datastore mehr gibt, lassen sich Storage-Policies unmittelbar einzelnen VMs zuweisen.

Verlangt zum Beispiel eine kritische VM den Storage einer bestimmten Kapazitäts-, Verfügbarkeits- oder Performance-Klasse, sorgt eine Policy dafür, dass vSAN den Speicher (VMDK) der VM als natives Speicherobjekt, gegebenenfalls mit mehrfachen Replikaten oder verteilt über mehrere Spindeln ablegt, unabhängig von den Storage-Eigenschaften, die einer anderen VM im gleichen vSAN-Datastore zugewiesen sind.

Architektur von vSAN

Die Architektur von vSAN orientiert sich grob an den HC-Infrastrukturen anderer Hersteller. Auch vSAN führt Direct Attached Storage sämtlicher ESXi-Hosts in einem Pool zusammen, der sich dann als Shared Storage für VMs nutzen lässt.

Ab Version 6.2 ist vSAN zudem in der Lage, Speicherplatz via iSCSI-Target nach „außen“ zu präsentieren, so dass sich ein vSAN auch als Storage für Workloads jeglicher Art nutzen lässt. Dabei allerdings ist die Workload-Charakteristik „virtueller“ Maschinen mit ihren speziellen Anforderungen wie relativ großen Dateien für vSAN prädestiniert. Die Abbildung verdeutlicht das Konzept:

Die Architektur von Virtual SAN.
Die Architektur von Virtual SAN. (Bild: VMware)

Im Unterschied aber zu allen anderen SDS-Herstellern für ESXi wie Nutanix, Simplivity, Datacore und Starwind. kann VMware auf eine so genannte Kontroll-VM verzichten. Diese macht letztendlich an den ESXI-Hosts angeschlossenen DAS-Storage mit Hilfe eines in der VM implementierten Speicher-Hypervsiors als Shared Storage für VMs verfügbar, zum Beispiel durch die Implementation von iSCSI-Targets oder NFS-Freigaben.

VMware hingegen verlagert den Speichervirtualisierer „in“ den ESXi-Kernel, ein technischer Kunstgriff, der nur VMware als Hersteller des ESX-Kernels möglich ist. So wandert die gesamte Logik der Speichervirtualisierung in den Kernel. Dies bringt nicht nur Sicherheits-Vorteile, sondern vereinfacht auch die Inbetriebnahme.

Konzept von Virtual SAN

vSAN ist ein verteilter und damit robuster und ausfallsicherer aggregierter Storage-Pool auf Basis eines ESXi-Host-Clusters. vSAN implementiert dabei einer Art RAID-Modell, allerdings auf Software-Ebene. Ein physikalischer RAID-Controller im Host ist nicht erforderlich, das heißt: Ein vorhandener RAID-Controller muss je nach Konfiguration im Pass-through- oder HBA-Modus arbeiten, damit der ESXi-Host die physischen Platten „sieht“.

vSAN implementiert hinsichtlich bekannter Cluster-Konzepte einen klassischen 3-Node-Cluster mit 3 ESXi-Hosts von denen jeder einzelne pro VM (VMDK) die Funktion eines Witness-Knotens übernehmen kann, während bei anderen VMDK ein anderer Host als Zeuge fungiert. Zu erkennen ist dies bei einem konfigurierten vSAN-Cluster im Web Client, wenn man den vSAN-Cluster markiert, dann in den Bereich „Monitor / vSAN“ navigiert und den Abschnitt „Virtual Objects“ markiert. Die Zuordnung erscheint im unteren Teil des Bildschirms bei „Physical Placement“.

In der Einstellungen für das physikalische Placement ist zu erkennen, welcher Host pro VM als "Zeuge" fungiert.
In der Einstellungen für das physikalische Placement ist zu erkennen, welcher Host pro VM als "Zeuge" fungiert. (Bild: Thomas Drilling)

Eine der herausragenden Eigenschaften von Virtual SAN ist nämlich die vollständige Umsetzung von VMware´s Konzept des richtlinienbasierten Speicher-Managements, das bei vSAN auf einer bidirektionalen Kommunikation zwischen Storage und ESXi-Hyperisor basiert, die durch den implementierten VASA-Provider der Version 1.5 realisiert wird. Das Konzept des Policy Based Storage Storage Management arbeitet Hand in Hand mit dem Konzept des Virtual San Datastore.

Der taucht bei erfolgreich eingerichtetem Virtual-SAN-Cluster automatisch auf, erfordert KEIN Definieren von LUNs oder ähnliche Konzepten am Backend und skaliert automatisch vertikal mit der Anzahl der im Host verbauten Platten oder horizontal mit der Anzahl der Hosts im Cluster.

Der vSAN-Datastore als "logisches Objekt" erscheint automatisch, sobald der vSAN-Cluster erstellt ist.
Der vSAN-Datastore als "logisches Objekt" erscheint automatisch, sobald der vSAN-Cluster erstellt ist. (Bild: Thomas Drilling)

Der „vsanDatastore“ ist per Default mit der Standard-vSAN-Richtlinie verknüpft. Jeder VM (genauer VMDK) lassen sich bei vSAN jedoch individuelle vSAN-Policies anheften, die dann mit einer der drei oben geschilderten Kategorien „Capacity“, „Availability“ oder „Performance“ verknüpft sind.

Eine Speicherrichtlinie definiert einen Satz von „Anforderungen“ für die betreffende VMDKs. Eine Anforderung der Kategorie „Number of failures to tolerate“ erlaubt beispielsweise Werte zwischen 0 und 3 und definiert die Anzahl der abzulegenden Repliken, während eine Policy der Kategorie „Number of disk stripes per objekt“ die Performance beeinflusst.

Das "Konsumieren" des Virtual SAN kann durchgängig regelbasiert erfolgen.
Das "Konsumieren" des Virtual SAN kann durchgängig regelbasiert erfolgen. (Bild: Thomas Drilling)

Der Clou an vSAN ist, dass sich jeder einzelnen VMDK grundsätzlich andere Policies anhängen lassen, obwohl diese als Objekt am gleichen Backend gespeichert wird. Dies liegt in der Natur eines vSAN-Clusters als verteilter Datastore. Standardmäßig arbeitet vSAN in RAID 1 (Spiegelung) und legt von jedem Objekt 2 Repliken (1 x Mirror, 1 x Witness) ab. Bei einem klassischen SAN hingegen würde die LUN die Speicher-Charakteristik definieren, so dass sämtliche VMDKs, die im mit der gleichen LUN verknüpften Datastore lägen, die gleichen Storage-Policies bekämen.

Eine automatisch Überwachung beziehungsweise Einhaltung auf Basis der VASA-Schnittstelle, zum Beispiel im Rahmen von SLAs, wäre bei einem LUN-zentrierten, klassischen Konzept gar nicht möglich.

Ab der Version 6.2 und nur mit einer Advanced-Lizenz unterstützt vSAN zusätzlich auch einfachen oder doppelten Paritätsschutz, der den Ausfall auch mehrerer Hosts verkraftet ( RAID 5 oder RAID 6). Eine einfache Spiegelung ist aber auch hier problemlos möglich; denn für RAID 5 oder RAID 6 benötigt man auch mindestens 5 oder 6 Knoten.

vSAN in Betrieb nehmen

VMware Virtual SAN lässt sich im Vergleich zu anderen SDS- und HC-Lösungen relativ einfach in Betrieb nehmen. Dazu bedarf es lediglich 3er Schritte:

  • 1. vSAN durch das Einspielen der vSAN-Lizenz freizuschalten
  • 2. die für jeden ESXi-Hot benötigten VMKernel-Adater für den vSAN-Kontroll-Traffic einzurichten
  • 3. ein Cluster-Objekt erstellen und in den Cluster-Settings das vSAN-Feature aktivieren.

Einfacher lässt sich eine Enterprise-SDS-Lösung kaum in Betrieb nehmen, sieht man mal von den „anspruchsvollen“ Installationsvoraussetzung hinsichtlich der unterstützen Hardware ab. Hier sollte man unbedingt die HCL zu Rate ziehen.

Ein 10 Gbit/s-Netzwerk ist für vSAN empfehlenswert. Die zwingend erforderlichen Cache-SSDs (mindestens eine pro Host) sorgt für die erforderliche Performance, das geschilderte Cluster-Konzept mit mindestens 3 Hosts für Ausfallsicherheit und der im Kernel verankerte Storage-Virtualisierer ist für Features wie Stretched Cluster, Deduplizierung , Komprimierung oder die Unterstützung für iSCSI zuständig.

Die Hardware-Voraussetzungen für vSAN siind erstens Standard und zweitens recht anspruchsvoll.
Die Hardware-Voraussetzungen für vSAN siind erstens Standard und zweitens recht anspruchsvoll. (Bild: VMware)

Folgendes Video demonstriert das Aufsetzen eines einfachen vSAN-Cluster mit 3 physischen Knoten:

Über den Autor

Thomas Drilling ist freier Autor und IT-Berater. Auf DataCenter-Insider schreibt er seinen eigenen Blog: „Drillings Open Source Eck“. Seine Videos finden sich unter anderem im Youtube-Kanal von DataCenter-Insider.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44798614 / Virtuelle Systeme)