HP SmartArray Cache-Controller Ratio mit Vmware ESXi

Aus Knowledgebase
Version vom 17. September 2018, 10:58 Uhr von PoC (Diskussion | Beiträge) (Neu)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Aus der Praxis heraus hat sich gezeigt, dass die Standardeinstellungen für die HP SmartArray Cache-Controller Ratio zwischen Schreib- und Lesecache oftmals nicht optimal sind. Ebenso ist ein komplett abgeschalteter Schreibcache (z. B. durch leere Stützbatterie) suboptimal für die Performance.

Im Praxisbetrieb prasseln auf die Controller eine erhebliche Anzahl I/O-Requests ein, zufällig über die im vmfs belegten Blöcke verteilt und bunt gemischt zwischen Lesen und Schreiben. Je mehr VMs über einen Controller laufen, desto zufälliger wird die Blockverteilung.

Die gezeigten Optimierungen gelten für einen Controller, der direkt in einem ESXi-Host verbaut ist und lokalen Storage bedient.

Performanceeinbußen durch Overhead

Die Controllerfirmware versucht die Anfragen sinnvoll abzuarbeiten (auch außerhalb der Eingangsreihenfolge), was wegen der zufälligen Natur der Requests nur unwesentlich zu optimieren ist. Dieser Elevator Sort bringt in diesem Fall nur noch wenig Beschleunigung.

Im Gegenzug kann sich dafür die Latenz zwischen Anfrageeingang und den letztendlich gelieferten Daten erhöhen (die CPU muss ja auch erst umsortieren) und die Schreibperformance verringern (die CPU muss je nach RAID-Level auch noch die Prüfsumme berechnen).

Derzeit existieren keine empirischen Messungen, um die aufgeführten Überlegungen mit konkreten Zahlen zu unterfüttern.

Performanceeinbußen durch Schreibcache-Management

Ab einer gewissen Last auf dem Controller ist der Schreibcache irgendwann voll, da die Disks mit den Anforderungen nicht mehr hinterherkommen. Der Controller schaltet dann je nach Konfigurationseinstellung Wait for Cache Room den Schreibcache auf Bypass (bis wieder eine undefinierte Menge freier Platz vorhanden ist) oder versucht nebenher, die ausstehenden Daten auf die Disks zu schreiben.

Zusammengenommen kommen also im schlechtesten Falle die üblichen Anfragen vom Host Plus Schreibanforderungen vom wegzuschreibenden Controllercache zusammen. Oder Schreibzugriffe vom Host werden von der Firmware ausgebremst, bis wieder Platz im Cache ist, je nach Einstellung. Je größer der Schreibcache eingestellt ist, desto extremer fällt dieser Performanceknick durch vollen Schreibcache aus. Dadurch dass die Disks unabhängig von der Einstellung für den Cache-Room bereits gut ausgelastet sind, steigt die Latzenz für Leseanforderungen: Die Requests „verhungern“ unterwegs.
Bei kleinem Cachespeicher und großen Disks kann der Controller zudem vergleichsweise wenig Anforderungen aus dem Lesecache bedienen, was wiederum die Latenz noch weiter steigert.

Tests haben eine Ratio von 90 % Read- und 10 % Write-Cache als hinreichend optimal aufgezeigt, ± ein paar Prozent hoch oder runter, die nicht getestet wurden. Der Cache wird bei vielen Schreibanforderungen zwar schnell voll, er ist aber im Verhältnis gesehen schnell wieder leer. Das verschlechtert zwar die mögliche Schreibperformance in Gänze, aber die Verschlechterung ist hinreichend gleichmäßig. Leseanforderungen sind nicht spürbar betroffen.

Einstellungen

Wenn bei einer ESXi-Installation der HPSA-Treiber (scsi-hpsa) und des Kommandozeilen-Tools für die Controllersteuerung (hpssacli) vorgenommen wurde, können die betreffenden Parameter bequem zur Laufzeit über eine SSH-Sitzung ausgelesen und ggfs. angepasst werden. Leider ist je nach installiertem Vmware-Image und Treibern der Name als auch der Pfad unterschiedlich. Manchmal ist der Kram unter /opt/smartstorageadmin/ssacli/bin/ssacli zu finden, manchmal unter /opt/hp/hpssacli/bin/hpssacli, potentiell weitere.

ssacli controller slot=1 modify elevatorsort=disable[1]
ssacli controller slot=1 modify waitforcacheroom=disable
ssacli controller slot=1 modify cacheratio=90/10

Falls die Einstellung mit einer Fehermeldung ähnlich Error: "cacheratio=90/10" is not a valid option… abgebrochen wird, ist eventuell ausgeschaltet, dass der Write-Cache auch ohne Stützakku/Elko erlaubt ist. Korrektur:

ssacli controller slot=1 modify nobatterywritecache=enable[2]

Mehr Schreibperformance kann auch durch Einschalten des Schreibcaches der lokalen Platten erreicht werden.[3]

ssacli controller slot=1 modify drivewritecache=enable

Weblinks

Fußnoten

  1. Bei einem P212 ist dies z. B. nicht möglich: Feature requires license key
  2. Achtung, bei akutem Stromausfall gehen im schlechtesten Fall 10 % des Caches verloren. Je nach dem, wo das passiert, ist das fatal.
  3. Achtung, bei akutem Stromausfall gehen im schlechtesten Fall Daten in den Caches verloren.