Windows Server 2016: Storage Spaces Direct mit Health Service überwachen


    Tags: , ,

    Health Service für Storage Spaces DirectWindows Server 2016 bringt Tools für das Monitoring von Speicher­funk­tionen wie Storage Spaces Direct, Replica und QoS mit. Dabei berück­sichtigt der Health Service nicht nur Metri­ken, sondern analy­siert auch die Fehler­ursachen und erleichtert so das Trouble­shooting.

    Der Health Service in einem Windows Server 2016 Cluster ist aktiv, sobald Storage Spaces Direct (S2D) aktiviert wird, eine separate Konfiguration ist nicht nötig. Dieser Dienst aggregiert in Echtzeit Daten wie beispielsweise IOPS, Durchsatz oder Latenzen und offenbart zusätzlich Probleme im Cluster-Verbund, speziell beim Software-defined Storage.

    Darüber hinaus kann das Storage Management API (SM-API) auch Drittanbietern zur Gestaltung von Dashboards dienen, ein Beispiel dafür ist die MUST-Verwaltungs­oberfläche von DataON. Auch Power BI oder die Azure Operations Management Suite (OMS) helfen hier bei der Visualisierung und Sammlung von Daten mit der Möglichkeit diese von überall einzusehen. Dadurch erreicht man ein flexibles Monitoring und ein Alerting wie man es von SAN-Appliances gewohnt ist.

    Doch Metriken oder Fehler samt Ursachen und Schweregrad lassen sich auch bequem über PowerShell Cmdlets ausgeben und analysieren. Das hilft bei der Fehlersuche auch ohne Dashboard oder System Center Operations Manager (SCOM) und macht Engpässe bei Storage Spaces Direct schneller sichtbar.

    Beispiel für ein selbst gestaltetes Dashboard

    Probleme im S2D-Cluster erkennen

    Bevor wir nun die Fehlerdiagnose starten, lohnt sich ein Blick auf die generelle Verfügbarkeit des Health Services. Dazu öffne ich zu Beginn die PowerShell_ISE und frage nach den Cluster-Ressourcen:

    Get-ClusterResource

    Der Health Service ist verfügbar, nachdem S2D aktiviert wurde

    Der Health Service überwacht den S2D-Verbund kontinuierlich und unterteilt mögliche Fehlermeldungen in fünf Bereiche:

    • Einstufung des Schweregrads (gering, bedeutend, kritisch)
    • möglichen Fehlergrund
    • Empfehlung zum Troubleshooting
    • Standort & Position (abhängig vom Fault Domain Location Tag)
    • Bauteil, Beschreibung

    Dabei deckt er folgende Komponenten und Funktionen ab:

    • Grundlegendes zur Cluster-Hardware (Knoten down, isoliert, Netzwerk­adapter-Fehler, Temperaturen, …)
    • Grundlegendes zur Storage-Hardware (Festplatten-Fehler, Gehäuse-Fehler wie Lüfter oder Netzteil, …)
    • Storage Spaces Software-Stack (unerkannte Pool-Metadaten, geringe Kapazität der Volumes, …)
    • Storage QoS (Einhaltung der Richtlinien)
    • Storage Replica (Fehler bei der Synchronisation, Replikations­gruppen-Fehler, RPO Prüfung, …)
    • Health Service (Automations­probleme, Fest­platten in Quarantäne)

    Fehler werden mit dem entsprechenden Cmdlet angezeigt:

    Get-StorageSubSystem Cluster* | Debug-StorageSubSystem

    Gibt das Cmdlet keinen Inhalt zurück, besteht für den Health Service auch kein Problem. Im Lab generiere ich einen synthetischen Fehler, indem ich eine Festplatte entferne und dem Pool entziehe. Das Ergebnis erscheint mit etwas Verzögerung, dieses zeigt der folgende Screenshot:

    Künstlich herbeigeführter Fehler wird erkannt und eingestuft

    Auch hier ist das SES-Protokoll (SCSI Enclosure Services) erforderlich, um beispielsweise Daten zum Zustand der Lüfter und Sensoren abzugreifen. SES spielt bei Storage Spaces Direct generell eine wichtige Rolle, auch beim Platzieren der slabs über die Fault Domains.

    Metriken in Echtzeit darstellen

    Zusätzlich zur Fehlerdiagnose liefert der Health Service auch Metriken des kompletten Verbundes in Echtzeit. Dabei berücksichtigt der Service auch zusammengefasste Daten wie die durchschnittliche CPU Auslastung (%), betrachtet über alle Knoten. Weitere Daten werden wie folgt bewertet:

    • Pool Kapazität (Gesamt, restliche Verfügbarkeit)
    • Physische Kapazität (Gesamt, nicht gepoolt, verfügbar)
    • Volume Kapazität (Gesamt, restliche Verfügbarkeit)
    • IO Latenz (Lesen, Schreiben, Durchschnitt)
    • IOPS (Lesen, Schreiben, Gesamt)
    • IO Durchsatz (Lesen, Schreiben, Gesamt)
    • RAM (Gesamt über alle Nodes, restliche Verfügbarkeit)

    Eine Abfrage dieser aggregierten Metriken erfolgt über das Cmdlet

    Get-StorageSubSystem Cluster* | Get-StorageHealthReport

    Abfrage der Metriken des Storage Spaces Direct-Verbundes in Echtzeit, hier im virtuellen Labor.

    Interessant ist eine Ausgabe mit dem Schalter -Count, welcher sekündlich eine Bewertung abbildet. In meinem Beispiel gebe ich einen Wert von 20 für diesen Parameter an und das Resultat ist, dass die Metriken jede Sekunde insgesamt 20x dargestellt werden. Das vereinfacht eine Analyse und Bewertung des Storage Spaces Direct-Clusters erheblich. Die sekündliche Ausgabe lässt sich mit folgendem Cmdlet beeinflussen (hier 5 Sekunden):

    Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Reports.ReportingPeriodSeconds" -Value 5

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Marcel Küppers

    Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infra­structure Architect unter anderem für den japani­schen Konzern JTEKT/TOYODA mit Verant­wortung über die Europa­standorte Krefeld und Paris. Da­rüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Loka­tionen des Kon­zerns mit und ist spezia­lisiert auf hoch­verfügbare virtuali­sierte Microsoft-Umgebungen plus Hybrid Cloud Solutions. Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
    // Kontakt: E-Mail, Twitter, LinkedIn //

    Verwandte Beiträge

    Weitere Links