Scale-out File-Server: Microsofts SAN-Alternative

    SOFS mit JBODs und Storage SpacesWindows 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.

    Mit zunehmender Virtualisierung von x86-Systemen steigt auch der Bedarf an Shared Storage, weil viele fortgeschrittene Features eine zentrale Speicherung der virtuellen Maschinen erfordern. Das sind gute Nachrichten für SAN-Hersteller, allerdings entpuppen sich die Kosten für solche Speichersysteme für kleinere und mittlere Unternehmen als eine wesentliche Hürde zur Private Cloud.

    Microsoft und VMware bieten preiswertes Shared Storage

    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.

    Dennoch arbeiten beide Anbieter an preiswerten und leistungsfähigen Alternativen zu SANs, auch wenn sie dabei unterschiedliche Konzepte verfolgen. Bei VMware spielt Virtual SAN eine zentrale Rolle, bei Microsoft dagegen der Scale-out File-Server in Kombination mit Clustering und verschiedenen Storage-Funktionen von Windows Server.

    Scale-out File-Server nicht für User-Daten

    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-Cluster in Kombination mit JBODs eignen sich besonders als Storage für Images von VMs.

    SOFS nehmen wie SAN Controller eine Zwischenposition zwischen Speichermedien und Applikations-Server ein, wobei Letztere primär Hyper-V-Hosts oder SQL-Server sind. Im Unterschied zu SANs operiert ein Scale-out File-Server nicht auf Block-, sondern auf Dateiebene. Die Anbindung der Applikations-Server erfolgt nämlich nicht über iSCSI oder Fibre Channel, sondern über SMB 3.

    Deutliche Verbesserungen von SMB in Version 3

    Die neue Version von 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, das Daten über RDMA-fähige NICs direkt in das RAM des Servers übertragen kann und so die Prozessor-Last reduziert.

    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

    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 ebenfalls 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 dieselben Netzwerk-Shares verarbeiten. Das Gesamtsystem lässt sich somit durch Hinzufügen von Knoten zum Cluster skalieren, und gleichzeitig bietet es 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, also sich über iSCSI, Fibre Channel, SAS und dgl. ansprechen lassen. Microsoft argumentiert, dass es auch Vorteile bringt, wenn Applikations-Server nicht direkt mit SANs kommunizieren, sondern über den Umweg von SOFS.

    Scale-out File-Server lassen sich auch zwischen Applikations-Server und SANs schalten.

    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 HBA, weil die Kommunikation zwischen den SMB-Clients und SOFS normalerweise über 1 oder 10 Gbit-Ethernet erfolgt. Ähnlches gilt für Switches, 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, die über 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.

    Microsoft positioniert SOFS mit JBODs als Storage der Enterprise-Klasse und überlässt nur das High-end den SAN-Herstellern.

    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.

    Verbesserte Storage Spaces in Server 2012 R2

    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 durch das Auto-Tiering auf ein langsameres Medium verschoben werden kann.

    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 mit dem Storage-System kommuniziert, 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ählte etwa die schlechte Kompatibilität mit bestehenden Tools für Backup, Defrag­mentierung 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.

    Support für Shared VHDX

    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 abgelegt werden, die ein Guest-Cluster als Shared Storage nutzen kann.

    Ein anderes in Windows Server 2012 neu eingeführtes Storage-Feature, nämlich die Deduplizierung, eignet sich indes nur eingeschränkt für eine solche Konfiguration. Sie wird nur für virtuelle Desktops unterstützt, wobei diese auf separaten Maschinen laufen müssen und keine lokalen Laufwerke als Speicher verwenden.

    Hohe Ausfallsicherheit

    Wenn man alle Komponenten einer SOFS-basierten Storage-Lösung redundant auslegt, dann vermeidet man einen Single Point of Failure. Die Applikation-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.

    Keine Kommentare