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

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.

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 ü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:

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

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