Konfiguration der Repair-Einstellungen im Scale-Out File Server
Da ich aktuell bei einem Kunden sitze und einen Scale-Out File Server konfiguriere ist mir aufgefallen, dass wir noch keinen Beitrag bzgl. den Repair-Einstellungen in einem Storage Pool und besonders die Änderungen durch das November-Update 2014 (Update2 für Server 2012 R2, KB3000850) geschrieben haben. Durch die Installation bekommt man mehr Möglichkeiten, um den Fast Rebuild / Quick Rebuild-Vorgang anzupassen. Dies wirkt sich auf die Performance aus, die Sie während einem Rebuild-Prozess haben.
Beim Einsatz von hochverfügbaren Storage Spaces gibt es zwei Möglichkeiten, den Ausfall von einem Datenträger möglichst zeitnah abzufangen: Der Einsatz von Hot Spare-Datenträgern oder die Nutzung der Fast Rebuild-Technik. Beim Einsatz einer oder mehreren Hot Spare-Datenträgern ist die Nutzung so wie bei RAID-Controllern, Block-Storage-Systemen usw: Es stehen ungenutzte Datenträger zur Verfügung, die bei Ausfall einer Produktiv-Festplatte einspringen und an Stelle von dem ausgefallenen Datenträger genutzt werden. Diese Variante hat den Nachteil, dass bei dem Ausfall von einem Datenträger die Daten von diesem auf die Hot Spare-Festplatte geschrieben werden müssen, damit die Redundanz wieder zur Verfügung steht. Dieser Vorgang kann recht lange dauern (abhängig von Größe, Geschwindigkeit und Menge der Daten) und im dümmsten Fall fällt dieser Datenträger, der lange Zeit entweder nicht lief oder nicht produktiv genutzt wurde, aus.
Microsoft setzt bei den Storage Spaces auf eine andere Technik. Alle Datenträger werden zu einem Pool hinzugefügt (eine logische Zusammenfassung aller Datenträger, die genutzt werden sollen inkl. den Festplatten, die eigentlich als Hot Spare-Datenträger genutzt werden sollen). Nun werden basierend auf dem Pool virtuelle Datenträger erzeugt. Bei der Erstellung dieser Datenträger nutzt man nicht den kompletten Speicherplatz, der in dem Pool zur Verfügung steht, sondern man lässt einen gewissen Bereich frei. Wie viel genau man freilassen muss ist nicht in direkten Zahlen festgestellt, sondern wird von Microsoft wie folgt beschrieben:
You need to keep sufficient unallocated disk space available to enable the repairs. Under-provision your storage pool (that is, limit the total capacity that you allocate to all storage spaces in the pool) so that the pool can tolerate multiple disk failures without degraded health. If you’re using storage tiers, keep the total free space in each of the storage pools equivalent to one HDD plus 8 GB (for storage pool and storage spaces overhead) and one SSD plus 8 GB per enclosure. For a space that does not have tiers, under-provision as though you have a single tier.
Quelle: https://technet.microsoft.com/en-us/library/dn782852.aspx
Theoretisch werden nun die physischen Datenträger in dem Pool nicht komplett mit Daten beschrieben, sondern man kann sich visuell vorstellen, dass auf jeder Festplatte noch ein gewisser freier Speicherplatz vorhanden ist. Fällt nun ein Datenträger aus, werden nun von allen restlichen Festplatten die fehlenden Blöcke auf alle anderen Datenträger geschrieben. Dieser Prozess dauert wesentlich kürzer als die Kopie von allen Daten auf eine einzelne Festplatte (der Hot Spare-Datenträger).
In den Standard-Einstellungen kann es vorkommen, dass der Repair-Vorgang bei freiem Speicherplatz innerhalb des Pools eine so hohe Priorität hat und somit so viele I/Os erzeugt, dass für die VMs in diesem Pool kaum noch Ressourcen übrig bleiben. Dies macht sich darin bemerkbar, dass die Performance teilweise extrem stark sinkt.
In kleineren Umgebungen mit 20 – 40 VMs habe ich bisher einen nicht so starken Impact erlebt, in größeren Umgebungen bei mehr als 100 oder mehr als 1000 VMs waren die Auswirkungen deutlich zu spüren. Aus diesem Grund hat Microsoft mit dem Update2 (November-Update 2014) eine Möglichkeit eingebracht, dieses Verhalten ein wenig zu steuern und die Priorität der Wiederherstellung zu senken, damit es nicht mehr zu einer Beeinflussung der Produktiv-Umgebung kommt.
Wie bereits angesprochen, achten Sie auf das installierte Update2. Sie können auf einem Server recht einfach herausfinden, ob dieses installiert ist. Geben Sie einfach in der PowerShell die folgende Zeile ein:
Get-Hotfix | where hotfixID –like KB3000850
tl;dr
Um die Einstellungen zu setzen, müssen Sie ein paar Zeilen PowerShell auf jedem! SOFS Knoten ausführen:
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters
-Name ReallocationsPerInterval 32
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters
-Name ReallocationInterval 15
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters
-Name RepairQueueDepth 4
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters
-Name RepairQueueWidth 8
Get-ClusterResourceType "Storage Pool" |
Set-ClusterParameter -Name ReEvaluatePlacementTimeout -Value $([uint32]300) –create
Prüfen kann man die Einstellungen mit den folgenden Zeilen:
Get-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters | Select-Object ReallocationsPerInterval,ReallocationInterval,RepairQueueDepth,RepairQueueWidth | Format-List
Get-ClusterResourceType ‚Storage Pool‘ | Get-ClusterParameter
Die Ausgabe sollte wie folgt aussehen:
ReallocationsPerInterval : 32 ReallocationInterval : 15 RepairQueueDepth : 4 RepairQueueWidth : 8 Object Name Value Type ------ ---- ----- ---- Storage Pool ReEvaluatePlacementTimeout 300 UInt32
Die Beschreibung von Microsoft zu diesen Werten ist im TechNet zu finden:
https://technet.microsoft.com/en-us/library/dn858079.aspx
P.S. Aktive Repair-Vorgänge können Sie mit dem PowerShell-Befehl
Get-StorageJob
beobachten.
