Microsoft und VMware fordern SAN-Hersteller heraus

von Wolfgang Sommergut
Die Server- und Desktop-Virtualisierung steigert die Nachfrage nach Shared Storage, weil fortgeschrittene Features eine zentrale Speicherung der virtuellen Maschinen erfordern. Das sind gute Nachrichten für SAN-Hersteller (SAN = Storage Area Network). Allerdings entpuppen sich die Kosten solcher Speichersysteme für kleinere und mittlere Unternehmen als eine wesentliche Hürde auf dem Weg zur Private Cloud.
Zwar haben sowohl Microsoft als auch VMware die Situation durch verschiedene Maßnahmen entschärft, beispielsweise durch die Einführung der Shared Nothing Live Migration. Besonders bei der Desktop-Virtualisierung aber bremsen die Kosten von SANs eine weitere Verbreitung, so dass verschiedene Hersteller auch hier eigene Lösungen entwickeln. Sie finden sich entweder in den Plattformen selbst, wie etwa bei Citrix VDI-in-a-Box, oder sind Zusatzprodukte von Firmen wie Atlantis Computing, Datacore, Nexanta oder Nutanix.

Eine wesentliche Bedeutung kommt hier aber den Plattformanbietern Microsoft und VMware zu. Sowohl VMware vSphere als auch Microsoft Hyper-V unterstützen die Anbindung von SANs über Schnittstellen wie VAAI, SMI-S oder Offloaded Data Transfer (ODX), über die sie viele Aufgaben an die Storage-Systeme delegieren können. Daran wird sich in absehbarer Zeit nichts ändern, weil weder Microsoft noch VMware mit ihren Systemen SANs ganz ersetzen werden. Besonders VMware befindet sich als Tochter des Storage-Herstellers EMC in einem Interessenkonflikt und gibt sich bescheiden in Bezug auf die eigenen Ambitionen.

Beide Hersteller zielen mit ihren Storage-Features derzeit nicht auf das High-end, decken aber durchaus Einsatzgebiete ab, die bislang SANs vorbehalten waren. Sie verfolgen dabei unterschiedliche Konzepte. Microsoft bleibt mit seinem File-basierten Shared Storage bei einer SAN-ähnlichen Architektur, während VMware bei Virtual SAN lokale Laufwerke von ESXi-Hosts zu einem Pool zusammenfasst.

Microsofts Scale-out File-Server - ein Speicher für Applikationsdaten

Windows Server 2012 führte eine Reihe von neuen Storage-Features ein, die für sich alleine genommen schon nützlich sind. Kombiniert man sie mit der ebenfalls neuen Rolle des Scale-out File-Server, dann fügen sich die Teile zu einem Puzzle zusammen, aus dem Microsofts Storage-Strategie erkennbar wird.

Angesichts der vielen neuen Funktionen in Windows Server 2012 erhielt der Scale-out File-Server (SOFS) recht wenig Beachtung. Das mag am Namen liegen, der kaum Erwartungen weckt. Aber mit der herkömmlichen zentralen Datenablage hat er nicht viel zu tun. Vielmehr positioniert ihn Microsoft als Speicher für Applikationsdaten, besonders für VM-Images und SQL-Datenbanken. SOFS nehmen wie SAN Controller eine Zwischenposition zwischen Speichermedien und Applikations-Server ein. Die Anbindung der Applikations-Server erfolgt nicht über iSCSI oder Fibre Channel, sondern über SMB 3.

Deutliche Verbesserungen von SMB in Version 3

Die neue Version des Kommunikationsprotokolls Server Message Block wurde gegenüber ihrem Vorgänger wesentlich aufgewertet, um den hohen Ansprüchen eines SAN-ähnlichen Speichers gewachsen zu sein. Für besondere Performance-Anforderungen ist SMB Direct ausgelegt. Es kann Daten über RDMA-fähige Netzwerk Controller (NICs) direkt in das RAM des Servers übertragen und so die Prozessorlast reduzieren (RDMA = Remote Direct Memory Access).

Mit SMB Multichannel kommt die Fähigkeit hinzu, mehrere Netzwerkverbindungen parallel zu nutzen. Dieses Feature ist standardmäßig aktiviert und bedarf keiner Konfiguration. Es erhöht nicht nur den Datendurchsatz, sondern auch die Verfügbarkeit der File-Server, wenn einzelne Verbindungen ausfallen. SMB Multichannel funktioniert mit NIC Teaming, aber auch mit nicht gekoppelten Netzadaptern, und unterstützt RDMA. Eine ausführliche Beschreibung des Features leistet dieser Eintrag im TechNet-Blog.

In Windows Server 2012 R2 kommen noch weitere Verbesserungen von SMB 3 hinzu. Dazu zählen ein automatisches Load Balancing, das SMB-Clients abhängig vom benutzten File-Share mit einem Cluster-Knoten verbindet, sowie ein Bandbreiten-Management, das die individuelle Kontrolle der 3 SMB-Traffic-Typen (Standard, Live Migration, VM) erlaubt. Die Nutzung von SMB als Transportmechanismus für Live Migration ist ebenfalls eine Neuerung von Server 2012 R2 (eine Übersicht über alle Verbesserungen gibt dieser TechNet-Beitrag).

Active/Active-Cluster steigert Verfügbarkeit und Skalierbarkeit

Nicht nur SMB Direct und SMB Multichannel gewährleisten eine performante und hochverfügbare Anbindung von Hyper-V-Hosts an die Speichersysteme. Vielmehr leistet die Architektur des Scale-out File-Servers dazu selbst einen wichtigen Beitrag. SOFS lassen sich nämlich in Cluster mit bis zu 8 Knoten zusammenschließen, wobei sie im Gegensatz zum herkömmlichen File-Server in einer Active/Active-Konfiguration betrieben werden.

Anders als die bekannte Active/Passive-Konstellation eines Failover-Clusters können alle Scale-out File-Server gleichzeitig Anforderungen von SMB-Clients für die dieselben Netzwerk-Shares verarbeiten. Das Gesamtsystem lässt sich somit durch Hinzufügen von Knoten zum Cluster skalieren, gleichzeitig bietet dieses automatisches Failover bei Ausfall eines Servers.

Anbindung von SANs

Als Speichersysteme für SOFS kommen zum einen alle Varianten von Shared Storage in Frage, die von Windows Server (im Cluster) unterstützt werden, sich also über iSCSI, Fibre Channel, SAS und dergleichen ansprechen lassen. Microsoft argumentiert, dass es auch Vorteile bringt, wenn Applikations-Server nicht direkt mit SANs kommunizieren, sondern über den Umweg von SOFS.

Setzt man etwa eine größere Zahl von Hyper-V-Hosts ein, dann benötigt im Fall von Fibre Channel nicht jeder von ihnen einen teuren Host Bus Adapter (HBA,) weil die Kommunikation zwischen den SMB-Clients und SOFS normalerweise über 1- oder 10-Gbit-Ethernet erfolgt. Außerdem kommt man mit weniger Switches aus, weil nur die Knoten des SOFS-Clusters mit dem SAN verbunden werden.

Bevorzugte Kombination mit JBODs und Storage Spaces

Die von Microsoft am häufigsten propagierte Konfiguration nutzt billigen Speicher in Form von JBODs (Just a Bunch of Disks), die über Serial Attached SCSI (SAS) mit den Knoten des SOFS-Clusters verbunden sind. Die nötige Intelligenz, um RAID-ähnliche Ausfallsicherheit, Hot-add von Laufwerken oder Thin Provisioning zu unterstützen, liefert Windows Server über Storage Spaces. Sie lassen sich nicht nur auf einzelnen Maschinen, sondern auch im Cluster nutzen.

Dieses mit Server 2012 eingeführte Feature fasst verschiedene Laufwerke zu Pools zusammen, in denen sich virtuelle Volumes einrichten lassen. Zur Auswahl stehen dabei die Typen Simple, Mirror und Parity, wobei Ersteres keine Redundanz bietet und in derartigen Speicherarchitekturen nicht verwendet werden sollte.

Windows Server 2012 R2 ergänzt Storage Spaces um Tiered Storage, indem es sowohl Plattenlaufwerke als auch SSDs integriert. Das System analysiert in regelmäßigen Abständen die Nutzung der darauf gespeicherten Daten und verlagert sie nach Bedarf auf die schnelleren oder langsameren Speichermedien. Zusätzlich dienen SSDs als Schreib-Cache, dessen Inhalt später bei Bedarf durch das Auto-Tiering auf ein langsameres Medium verschoben wird.

Hohe Ausfallsicherheit für gemeinsamen Speicher

Wer alle Komponenten einer SOFS-basierten Storage-Lösung redundant auslegt, vermeidet einen Single Point of Failure. Die Applikations-Server können dank SMB Multichannel mehrere Verbindungen mit Scale-out File-Server aufbauen, und diese bieten im Cluster ebenfalls hohe Ausfallsicherheit. Für die Anbindung von JBODs über SAS unterstützt Windows Server Multipath I/O (MPIO), so dass auch in diesem Abschnitt Defekte aufgefangen werden können.

Cluster Shared Volumes

Wenn die Knoten eines Active/Active-Clusters gleichzeitig auf die gleiche LUN oder das gleiche Volume zugreifen, dann bedarf es zur Vermeidung von Schreibkonflikten eines Cluster-fähigen Dateisystems. Während im Failover-Cluster eines herkömmlichen File-Servers immer nur ein Knoten auf das Storage-System zugreift, benötigte Microsoft spätestens mit der Einführung von Live Migration für Hyper-V eine Cluster-fähige Lösung.

Daher brachte Windows Server 2008 R2 Cluster Shared Volumes, die in der Version 1.0 allerdings noch recht viele Schwächen zeigten. Dazu zählten etwa die schlechte Kompatibilität mit bestehenden Tools für Backup, Defragmentierung oder Laufwerksverschlüsselung. Windows Server 2012 überwand mit CSV 2.0 die meisten dieser Defizite. Freigaben, auf denen etwa Images von virtuellen Maschinen angelegt werden, lassen sich einfach über einen UNC-Pfad ansprechen.

Die Kombination aus SMB 3, Scale-out File-Server, Storage Spaces und Cluster Shared Volumes erlaubt auf Basis von Commodity-Hardware und Standard-Netzwerken den Aufbau von relativ preiswerten Speichersystemen, die alle wesentlichen Funktionen von Hyper-V unterstützen. Das betrifft nicht nur Live Migration, sondern auch die Neuerungen von Windows Server 2012 R2. So dürfen auf SMB-Freigaben auch Shared VHDX (Hyper-V Virtual Hard Disks) abgelegt werden, die ein Guest-Cluster als Shared Storage nutzen kann.

VMware Virtual SAN (vSAN) - Speicher virtualisieren

Eine wesentliche Neuerung von vSphere 5.5 ist ein Feature namens Virtual SAN (vSAN). Es vereint Direct Attached Storage aller Hosts in einem Cluster zu einem Pool, der sich dann als Shared Storage nutzen lässt. Diese Speichervirtualisierung ist Teil der VMware-Strategie für das Software Defined Data Center.

VMware vSAN ist nicht der erste Anlauf des Herstellers zur Virtualisierung von Speicher-Ressourcen. Bereits mit vSphere 5 brachte die Firma das Virtual Storage Appliance (VSA) auf den Markt. Auch diese diente dem Zweck, lokale Disks zu einem Verbund zusammenschließen, der sich gegenüber den Hosts als Shared Storage präsentiert. Allerdings richtete sich das VSA explizit an kleinere Firmen, weil es nur den Speicher von maximal 3 Servern zusammenfassen kann. Wie der Name nahelegt, handelt es sich beim VSA um eine Virtual Appliance, die als virtuelle Maschine auf allen beteiligten ESXi-Hosts laufen muss.

Virtual SAN soll künftig die VSA ersetzen und aufgrund seiner höheren Leistungsfähigkeit auch neue Einsatzgebiete erschließen. Es unterstützt in seiner ersten Ausführung die Einrichtung von Storage-Clustern mit mindestens 3 und bis zu 8 Knoten. Das Management erfolgt ausschließlich über den vSphere Web Client, wobei auch die vCenter Server Appliance für diese Aufgabe geeignet ist. Bei der Installation eines vSAN-Clusters kann vSphere auf Wunsch alle leeren Disks automatisch ermitteln und in den Pool aufnehmen.

Implementierung im ESXi-Kernel

Im Gegensatz zur Virtual Storage Appliance läuft vSAN nicht in virtuellen Maschinen, sondern wurde in Form von Kernel-Modulen direkt im Hypervisor implementiert. Deshalb setzt es auch die Version 5.5 von ESXi voraus. Ein weiterer Unterschied besteht in der Anforderung, dass jeder Host neben Disk-Laufwerken auch über mindestens eine SSD (Solid State Disk) verfügen muss.

Diese schnellen Medien erhöhen nicht die Speicherkapazität des Gesamtsystems, sondern dienen der Performance-Verbesserung. Sie fungieren als Cache für Lese-Zugriffe und als Puffer für Schreiboperationen, so dass jeder Speichervorgang erst auf einer SSD erfolgt, bevor die Daten schließlich auf Plattenlaufwerken landen.

Ein verteiltes Storage-System wie vSAN stellt erwartungsgemäß auch hohe Anforderungen an das Netzwerk, so dass VMware die Verwendung von 10 GBit NICs empfiehlt, die auf Host-Ebene zudem über Teaming gebündelt werden können.

Die Kommunikation innerhalb des Clusters umfasst nicht nur den permanenten Abgleich von Metadaten zwischen den Knoten, sondern je nach geforderter Redundanz bewegt ein vSAN auch große Mengen an Nutzdaten zwischen den Hosts. Hinzu kommt, dass auch Server in ein vSAN-Cluster aufgenommen werden dürfen, die über keinen Massenspeicher verfügen. Sie bedienen sich dann aus dem Storage-Pool der anderen Hosts.

Policies definieren die Anforderungen von VMs

Das VMware vSAN beschränkt sich indes keineswegs darauf, nur Speicherkapazität zu einem gemeinsam nutzbaren Pool zusammenzufassen. Dem Konzept des Software Defined Data Center zufolge soll die Intelligenz im Virtualisierungs- und Management-Layer liegen, der auf Basis von Standard-Hardware komplexe und flexible Dienste bereitstellt sowie Aufgaben automatisiert.

Ein Virtual SAN bietet daher die Möglichkeit, Anforderungen an den Speicher in Form von Policies zu definieren. Hier lassen sich Werte für Ausfallsicherheit und Performance festlegen. Kriterien sind beispielsweise die Zahl der tolerierbaren Ausfälle von Disks bzw. Hosts, die Zahl der Laufwerke, über die die Daten verteilt werden (Striping), die Größe des reservierten SSD-Caches oder die Menge an Speicherplatz, die beim Thin Provisioning von VMDKs (Virtual Machine Disks) fest zugeteilt werden soll.

Je höher die Anforderungen an die Verfügbarkeit sind, desto mehr Repliken der Daten hält das vSAN vor und umso höher ist der Speicherverbrauch. Es trachtet dabei immer danach, die Last zwischen den Knoten des Clusters automatisch gleichmäßig zu verteilen.

Die Zuordnung von Policies zu VMs erlaubt eine große Flexibilität bei der Nutzung des Speicher-Pools, weil sich für jede einzelne virtuelle Maschine festlegen lässt, welche Service Levels sie in Bezug auf Verfügbarkeit und Performance erhalten soll. Daher lassen sich auf ein und demselben Datastore je nach Applikation unterschiedliche Anforderungen erfüllen.

Separate Lizenzen erforderlich

Virtual SAN ist mit den meisten Storage-bezogenen Features von vSphere kompatibel, darunter mit vMotion, HA oder Distributed Resource Scheduler (DRS). Allerdings unterstützt die Version 1.0 nur VMDKs mit dem alten Limit von 2 TB. Die mit vSphere 5.5 eingeführten, bis zu 62 TB großen virtuellen Disks lassen sich auf ihm nicht nutzen.

vSAN ist zwar ein integriertes Feature von vSphere, muss aber separat erworben werden. Die Lizenzierung erfolgt pro CPU-Sockel, so dass dem Speichervolumen oder der Zahl der Laufwerke pro Host keine Grenzen gesetzt sind. (rb)