Überblick: Windows Server 2016 Storage Spaces Direct im 2-Node-Cluster

    Storage Spaces Direct auf Cluster mit 2 KnotenStorage Spaces Direct (S2D) verbinden zerti­fizierte Standard-Hardware samt lokalen Lauf­werken zu einem Cluster und stellen so hoch­verfügbaren Speicher für Hyper-V bereit­. Die kleinste Konfi­guration für eine Hyper-converged Infra­structure erfordert nur zwei Knoten.

    Storage Spaces Direct ist eine Weiter­entwicklung der bereits mit Windows Server 2012 eingeführten Storage Spaces, welche ein Pooling lokaler Platten und darauf die Einrichtung virtueller Volumes ermöglicht. S2D geht einen Schritt weiter und schafft auf Basis lokaler Disks hochver­fügbaren Speicher.

    Im Beitrag "Storage Spaces Direct: Hyper-converged Infrastructure mit Windows Server 2016 einrichten" zu Zeiten der TP4 habe ich bereits einen Überblick zum neuen Feature verfasst, welcher in diesem Artikel detaillierter das 2-Knoten Design beleuchtet.

    Eigener Storage-Tier versus hyperkonvergent

    S2D nutzt dafür bekannte Technologien und Features von Windows Server wie das Failover-Clustering, Cluster Shared Volumes, SMB und PowerShell. Shared Storage in Form von kostspieligen proprietären Appliances mit dazugehörigem SAN sind somit nicht mehr erforderlich, um einen Hyper-V-Cluster zu implementieren.

    Die kleinste Konfiguration in einem Cluster mit 2 Knoten eignet sich zudem gut für den Einsatz in Zweig­nieder­lassungen oder in kleineren und mittleren Unter­nehmen.

    Es gibt zwei Einsatz­szenarien für Storage Spaces Direct: Zum einen die Ein­richtung eines eigen­ständigen Storage-Tiers und eines separaten Hyper-V Clusters (disaggregiert), zum anderen die Kombination von Hyper-V mit gemeinsamen Speicher auf der gleichen Hardware (Hyper-converged).

    Cluster-Design und Hardware-Umgebung

    Bei einer Hyper-converged Infrastructure (HCI) entfällt die Rolle des Scale-out File Server (SoFS), und virtuelle Maschinen werden hochverfügbar auf dem "lokalen" Cluster Shared Volume (CSV) abgelegt. Ermöglicht wird das durch den virtuellen Software Storage Bus (SSB), welcher den physikalischen Speicher der Cluster-Knoten für alle Nodes sichtbar und zugänglich macht.

    ClusPort und ClusBflt ermöglichen es, lokalen Speicher für die Knoten zugänglich zu machen, Quelle: MSFT

    Durch den Knotenverbund über SMB 3.1.1, idealerweise mit redundanten RDMA Karten (Remote Direct Memory Access), und lokalem Massenspeicher entfällt auch die bei 2012 SoFS nötige SAS-Kreuzverkabelung mit Shared JBODs. Live Migrationen sind ebenfalls performant über die RDMA-Infrastruktur möglich.

    Skalieren (Scale-out) müssen die Knoten im HCI-Design dann als komplette Einheit. Für die Intra-Cluster-Kommunikation sind mindestens 10 Gbps-NICs erforderlich. Storage Spaces Direct lassen sich im Cluster-Verbund aus 2 bis 16 Knoten mit Windows Server 2016 Datacenter und lokalem SATA-, SAS- am "einfachen" SAS HBA oder NVMe-Speicher betreiben. Kommen beispielsweise SSDs oder NVMe als Cache plus HDDs zum Einsatz, dann besteht eine minimale hybride Konfiguration aus zwei SSDs oder NVMe und vier HDDs pro Host.

    Architektur eines Hyper-converged Stack mit 2 Knoten

    In diesem Blog-Post richte ich den Fokus auf das Layout für eine Hyper-converged Infrastructure, wo die Knoten auch die Rolle des Microkernel-Hypervisor Hyper-V erhalten. Storage und virtuelle Workloads sind somit auf den Nodes im Hyper-V Cluster vereint und stellen eine kompakte Einheit dar. Dadurch lassen sich auch die zusätzlichen Kosten für die Infrastruktur einer disaggregierten Lösung einsparen.

    Hyper-converged Stack über zwei Hosts

    Betrachtet man den Hyper-converged Stack, bestehend aus zwei identischen Knoten mit SSDs für das Caching und HDDs für VHDs, dann erstrecken sich darüber die Storage Spaces Direct. Die Hosts erhalten eine Version von Windows Server 2016 Datacenter (Core oder Desktop Experience) und werden dem Active Directory hinzugefügt.

    Danach wird die Hypervisor-Ebene mit der Aktivierung von Hyper-V eingezogen, um virtuelle Maschinen später im CSV ablegen zu können und hochverfügbar vorzuhalten. Die Hosts sind untereinander mit RDMA-Adaptern verbunden, welche entweder RoCE (RDMA over Converged Ethernet) oder iWARP (internet Wide Area RDMA Protocol) sprechen und niedrige Latenzen gewährleisten.

    Auf beiden Knoten wird außerdem das Feature Failover-Clustering installiert und ein Zwei-Knoten-Verbund ohne Storage gebildet. SMB-Multichannel im selben Subnet vereinfacht die Konfiguration. Der Cluster-Witness kann dabei in der Azure Cloud (Deutschland) liegen. Eine Validierung des Clusters ist wie immer auch hier wichtig.

    Danach aktiviert man den Software Storage Bus mit dem PowerShell-Cmdlet Enable-ClusterStorageSpacesDirect, um die physikalischen Platten beider Hosts für das Cluster zugänglich zu machen.

    Hybrid-Konfiguration für das Caching und die Kapazität, Quelle: MSFT

    Dabei wird automatisch ein Pool gebildet, wobei die performanten Flash-Speicher für das Read-Write-Caching und die HDDs als Kapazitäts­speicher dienen. Automatisch erkannte SSDs oder NVMe werden nicht gepoolt. Anschließend erstellt man Zwei-Wege Mirror Storage Spaces (Virtual Disks), die mit ReFS formatiert und als Cluster Shared Volumes eingerichtet werden.

    18 Kommentare

    Bild von Mark
    Mark sagt:
    21. Februar 2017 - 12:31

    Hallo Marcel,

    vielen Dank für deine super Artikel zum Thema "Storage Spaces Direct".

    In der Vergangenheit (Server 2012 R2) war beim Thema "Storage Spaces" immer auch vom Scale out Fileserver die Rede.

    Ist dieser überhaupt noch relevant? Ich sehe zumindest in hyperconverged Umgebungen hierfür keinen Einsatzzweck mehr.

    Vielen Dank im Voraus!

    Gruß,
    Mark

    Bild von Mark
    Mark sagt:
    21. Februar 2017 - 12:33

    Ok, ich habe den Abschnitt überlesen, wo du die Frage schon beantwortest. :)

    Bild von Marcel Küppers
    21. Februar 2017 - 13:26

    Hallo Mark,

    vorab: Danke für Dein positives Feedback!

    Scale-out Fileserver bleiben auch weiterhin ein Thema, nicht in einem hyper-converged Design, jedoch beim disaggregierten (converged) Layout.

    Hier skalieren beide Tiers (Compute & Storage) unabhängig voneinander, die Scale-out Fileserver Nodes brauchen dabei jedoch keine externe SAS-Verkabelung samt JBODs. Sie satteln eben hier auf S2D inkl. lokalem Storage.

    Dieses Konzept zielt eher auf größere Infrastrukturen ab. Eine Update-Versorgung kann dabei unabhängig stattfinden.

    Hoffe ich konnte noch etwas Klarheit reinbringen.

    Gruß,
    Marcel

    Bild von Mark
    Mark sagt:
    21. Februar 2017 - 15:33

    Hallo Marcel,

    vielen Dank für die Informationen.

    Wie kommunizieren Compute und Storage bei einem converged Layout miteinander? Ebenfalls über SMB 3.1?

    Gruß,
    Mark

    Bild von Marcel Küppers
    21. Februar 2017 - 17:06

    Hi Mark,

    Wie kommunizieren Compute und Storage bei einem converged Layout miteinander? Ebenfalls über SMB 3.1?

    Ganz genau. SMB 3.1.1 -> Shares

    Bild von Stefano
    Stefano sagt:
    25. April 2017 - 10:28

    Hallo Marcel. So ich habe nun einen 2Node Cluster seit geraumer Zeit mehr oder weniger produktiv am laufen (2xHPDL380G9 mit je 22HDD Storage Pool).
    Wenn ich aber jeweils einen Node runterfahre, dann habe ich Probleme mit den VM's (paused-critical, Start der VM's geht nach Live Migraton lang und Windows ist schwarz).

    Ich habe 2 Fragen:
    Hätte ich evtl. doch nicht alle HDD automatisch für den S2S Pool nehmen können? solch ich resizen und irgendwie pro Node 2 HDD als Hotspare machen?
    Cluster Validator gibt diese Warning: The storage pool does not have the minimum recommended reserve capacity. This may limit your ability to restore data resiliency in the event of drive failure(s).

    2. Frage:
    Bei beiden Nodes sind für die Virtual Disk jeweils alle HDD ersichtlich aber immer unter dem GLEICHEN Node (in Klammer). Sollte das nicht halb halb angezeigt werden? Selbst wenn ich im Cluser Manager den Storage und Pool move passiert nichts.

    Gruss Stefan

    **Betreffend Resizen? einfach Virtual Disk um 2 Diskeinheiten (2TB) verkleineren und dann 2 HDD removen? Und dann irgendwie die 2 entfernten als Hotspare konfigurieren?

    Bild von Marcel Küppers
    25. April 2017 - 13:16

    Hallo Stefan,

    zum Thema "Reserve" hatte ich Dir aber schon mal was geschrieben in der Vergangenheit:

    https://www.windowspro.de/marcel-kueppers/anleitung-storage-spaces-direc...

    Das sollte Dir weiterhelfen:

    https://blogs.technet.microsoft.com/filecab/2016/11/21/deep-dive-pool-in...

    Gruß,
    Marcel

    Bild von Marcel Küppers
    29. September 2017 - 12:45

    Der aktuelle Blog-Post zur "S2D Speicher-Planung" bringt hier zusätzliche Hintergrundinfos:

    https://www.windowspro.de/marcel-kueppers/controller-cache-laufwerkstype...

    Bild von Stefano
    Stefano sagt:
    25. April 2017 - 13:19

    Hallo Marcel. Danke für deine Antwort. Ja das mit der Reserve habe ich in der Theorie verstanden. Wie kann ich aber den Storage Pool verkleinern und dann 2 HDD rauspicken für Hotspare? Und wie ist es mit der zweiten Frage betreffen Host name?
    Gruss Stefan

    Bild von Marcel Küppers
    25. April 2017 - 14:13

    Es gibt keine "Hot spare" Platte als solche, es sollte einfach Luft im Pool gelassen werden (unallocated) als Reserve, der TechNet Beitrag geht näher darauf ein.

    Ein Storage Pool kann in diese Richtung nicht verkleinert werden, er stellt die "raw" Kapazität dar.

    Gibt es bei der Cluster-Validierung grundsätzlich weitere Hinweise/Fehler?

    Bild von Stefano
    Stefano sagt:
    26. April 2017 - 19:26

    Hallo Marcel. Ja es ist die einzige Fehlermeldung. Ich lasse viel Luft im Storage Pool (ca. 50%). Leider ist die verbaute HP 10GB NIC nicht RDMA fähig. Das erkärt wohl auch, dass das Backup und das Mergen von VM's viel länger dauert, da pratkisch synchorn repliziert wird, gell?

    Bild von Mark
    Mark sagt:
    26. April 2017 - 21:54

    Hallo Marcel,

    da ich die Kommentare dieses Artikels abonniert habe, ist mir heute noch eine Frage gekommen.

    Gibt es seitens Microsoft Support für Storage Spaces inkl. SLA etc? Das ist ja vor allem auf Kundenseite ein wichtiges Kriterium, wenn man sich für eine Storage-Lösung entscheidet.

    Danke und Gruß
    Mark

    Bild von Focko
    Focko sagt:
    27. April 2017 - 12:13

    Hallo Marcel,
    hallo Mark,

    da ich gewerblich tätig bin, möchte ich mich zunächst vorstellen: Mein Name ist Focko Migge und ich arbeite seit 23 Jahren bei der Dell GmbH. Meine aktuelle Rolle ist die des Consultant für Hyper-converged Infrastrukturen (HCI).

    Die Frage der SLA für HCI Umgebungen ist - mit Ausnahme natürlich von konkreten Vertragsinhalten mit einem dafür spezialisisierten Provider - nicht singulär beantwortbar, sondern gliedert sich in folgende drei Bereiche:

    - Die SLAs für die Hardware (Server, Switche) sind Bestandteil des Herstellerangebotes und von der späteren Nutzung (weitestgehend) unabhängig. Hier hat sich ein 24x7x4 Vertrag bewährt, der garantiert, das defekte Systeme oder Komponenten innerhalb von vier Stunden getauscht bzw. wieder in einen betriebsfähigen Zustand versetzt werden.

    - Die Verfügbarkeit der S2D Umgebung als Ganzes wird - außer durch die Auswahl qualitativ hochwertiger Hardware - besonders durch die konfigurierbaren Redundanz-Optionen bestimmt. Server sind keine hochverfügbaren Systeme. Eine 2-fach, oder 3-fach Redundanz der System-Ressourcen entscheidet darüber, wieviel Compute/Storage-Einheiten ausfallen dürfen, ohne dass der Betrieb der gesamten Infrastruktur gefährdet ist. Der Preis für eine stabile Betriebskontinuität ist hier ein den Redundanzfaktoren entsprechend reduzierter 'Wirkungsgrad' der eingesetzten Hardware (Compute & Storage).

    - Zu guter Letzt gilt es, sich für einen kompetenten Software-Support (inkl. Updates/Upgrades) zu entscheiden, der eine Beratungs- und Lösungs-Dienstleistung auf Platform-Ebene beinhaltet.

    Bild von Marcel Küppers
    29. April 2017 - 8:38

    Hallo Marc,
    hallo Focko,

    es freut mich, dass DELL hier Stellung bezieht und ich finde diese Frage absolut berechtigt. S2D ist gerade durch seine HA im HCI Design interessant. Compute + Storage sind hier hochverfügbar ausgelegt und bei einem verlässlichen Hardware-Partner greifen dann die vereinbarten SLAs. Schon alleine darum ist es wichtig, dass zertifizierte Hardware zum Einsatz kommt.

    Vielleicht auch interessant sind Partner wie DataON, welche komplette Appliances (HCCA = Hyper-converged Cluster Appliances) anbieten mit Ihrer MUST Software und lokalen Premium Partnern. Allerdings bei S2D erst ab 4 Nodes und somit für ein ROBO oder KMU eventuell nicht attraktiv genug.

    Übrigens ist DataON und Howard Lo als Gold Partner vertreten auf der Datacenter Conference in München. https://www.cdc-germany.de/

    Technisch sollte die Cluster Validierung erfolgreich abschließen und als Grundlage für den Support dienen. Wie immer wichtig ist Redundanz, beispielsweise bei Switchen.

    Erfahrungsgemäß leistet DELL einen sehr guten Service.

    Gruß,
    Marcel

    Bild von Stefano
    Stefano sagt:
    28. April 2017 - 13:41

    Hallo Marcel. Jetzt ist mir klar was mit Reserve gemeint ist. Ich habe Volume gelöscht und neu 2 Volumes gemacht und dabei 2 HDD Kapazitäten als Reserve gemacht. Nun kommt beim Cluster Validation auch kein Fehler mehr. Was aber interessant ist: beim Volume1 steht Layout: Mirror Clustered: Ja Tiered: no. Beim Volume2 steht: Layout leer, Clustered: Yes, Tiered: Yes. Beide Volumes habe ich im GUI erstellt. Ich dachte beim einem 2Node Cluster gibt es eh nur Mirroring. Beim erstellen des zweiten Volumes konnte ich das Layout gar nicht angeben. Wo könnte das Problem liegen?

    Bild von Marcel Küppers
    29. April 2017 - 8:34

    Hallo Stefan,

    da Du mir parallel eine Mail inkl. Screenshot gesendet hast, bleibe ich gerne mit Dir in Kontakt, dann versuchen wir den Rest zu klären.

    Gruß,
    Marcel

    Bild von Stefano
    Stefano sagt:
    5. Mai 2017 - 16:58

    Hallo Marcel. Mir ist aufgefallen, dass bei allen CSV Volumes jeweils *redirected* angezeigt wird. Ist das normal, weil ReFS den Coordinator spielt? Gruss Stefano

    Bild von Marcel Küppers
    6. Mai 2017 - 19:36

    Hallo Stefan,

    das hast Du absolut richtig erkannt, im Fall von Storage Spaces Direct sollte bevorzugt für die CSVs ReFS zum Einsatz kommen, bei einer "State" Abfrage des CSV erscheint hier "FileSystemRedirected", der I/O wird über das Cluster Netzwerk zur Coordinator Node umgeleitet. (FileSystemRedirectedIOReason: FileSystemReFs)

    Daraus resultierend sollte das Netzwerk performant sein und ich würde auch die Metric der Cluster-Netzwerke abfragen und analysieren.

    CSV Beitrag allgemein:

    https://www.windowspro.de/marcel-kueppers/hyper-v-cluster-shared-volumes...

    Gruß,
    Marcel