Workshop I/O-Analyse am Beispiel SVC und Storwize V7000, Teil 2 Die Suche nach dem Verursacher der verlorenen Antwortzeit

Autor / Redakteur: Michael Pirker, SVA / Rainer Graefen

Der Stau im Datenpfad ist nicht immer leicht zu finden. Mit dem Finden allein ist es jedoch nicht getan, da es danach um die bestmögliche Optimierung des Datenflusses geht. Die I/O-Analyse bietet häufig einige überraschende Optionen.

(Michael Pirker, SVA)

SVC segmentiert seinen Cache und teilt jedem Speicherpool (MDG) eine gewisse Menge Maximalcache zu. Der Vorteil aus dieser Segmentierung ist, dass die Pools untereinander abgeschottet sind.

Das hat zur Folge, dass die hohe Belastung der Cache-Ressourcen mit dem zugehörigen Speicherpool korreliert. Untersucht man den Cache des Speicherpools zum Zeitpunkt des Peaks, so findet man hier Auffälligkeiten, die deutlich auf Probleme hinweisen.

Bildergalerie
Bildergalerie mit 9 Bildern

Die Suche nach den Volumes, die für die Überfüllung des Caches verantwortlich sind, gestaltet sich recht einfach. Man erzeugt eine Grafik mit allen Volumes aus dem Speicherpool und lässt sich deren Write-Datenraten anzeigen. (Abb. 7: Die Write-Datenraten aller Volumes)

In der Summe überlastet

Die zwei Volumes aus Abb. 7 werden in Abb. 8 detaillierter betrachtet. Wieder passt der Zeitraum der Schreiboperationen exakt zum Zeitraum, in dem die Probleme aufgezeichnet wurden und in dem der Partitions-Cache der Speicherpools überfüllt war. (Abb. 8: Limitierung der Volumes-Datenraten)

Bei genauerem Hinsehen stellt man fest, dass sich die beiden Volumes, die für die Überfüllung des Caches verantwortlich sind, in ihrer Ausführung gegenseitig behindert haben. Das zweite Volume (in rot), das anfangs mit 35 MByte/s startete, hat seine Performance auf 105 MByte/s erhöht, als das erste Volume mit seiner Arbeit fertig war.

  • In Summe haben beide Volumes versucht, bis zu maximal 155 MByte/s Daten zu schreiben. Das war zu viel und hat zu einem Cache Overflow geführt.
  • Als das erste Volume fertig war, hat das zweite Volume mit 105 bis 110 MByte/s weitergearbeitet, ein Datenvolumen, das der Backend-Speicher über einen längeren Zeitraum gerade noch aufnehmen konnte. Der Schreibcache wurde in diesem Zeitraum entlastet, aber - wie man in Abb. 3 sehen kann - sind die Antwortzeiten des Backend-Speichers nach wie vor sehr hoch. Das bedeutet, wir haben hier eine gute Einschätzung über die maximale Leistungsfähigkeit des Storage Backends gefunden.
  • Wir erinnern uns: Die Probleme starteten um 5:00 Uhr und waren um 6:30 Uhr zu Ende. Von 5:00 bis 6:30 Uhr versuchten beide Volumes eine Datenrate von über 140 MByte/s zu erzeugen. Ab 6:30 Uhr war Volume 1 fertig und Volume 2 fuhr mit seiner Arbeit fort, die es mit bis zu 105 MByte/s beendete. Ab 6:30 Uhr gab es keine Probleme mehr im Speicherpool. Offensichtlich sind die 105 MByte/s für den Pool und das dahinter liegende Speichersystem kein Problem, 140 MByte/s und mehr jedoch schon.

Beide Volumes gehören zu einem Server und wahrscheinlich gehören beide Volumes auch zu einem Backup-Prozess. Wenn man die Ausführung der beiden Schreibprozesse hintereinander schalten könnte, würde sich die gesamte Laufzeit beider Schreibprozesse nur um 30 Minuten verlängern. Durch diese „schonende“ Art des Schreibens würden in diesem Zeitraum keine Latenzprobleme für die anderen Volumes auftreten.

Hurra! Das Problem ist gefunden - und was jetzt?

Mit SVC hat man an diesem Punkt eine große Menge von Optionen, die man einsetzen kann um das Performance-Problem zu lösen.

Optionen zur Kollisionsvermeidung, sofern man für diese Prozesse keine Reduzierung der Datenrate und damit in der Verarbeitungszeit hinnehmen möchte:

  • Einen performanteren Speicher einsetzen, damit die 140 MByte/s verarbeitet werden können. Sinnvollerweise plant man hier allerdings eine Speicherklasse ein, die mit mindestens 220 MByte/s oder mehr zurecht kommen wird, da der Server diese neue Freiheit nutzen wird, um die Daten noch schneller in den Speicher zu pumpen.
  • Aufteilen der beiden Volumes auf zwei verschiedene Speicherpools, die am besten auf zwei unterschiedlichen Speichersystemen liegen.
  • Isolierung der zwei Volumes in einen getrennten Speicherpool, damit durch die großen Datenvolumen keine anderen Volumes gestört werden. Hier muss man in Betracht ziehen, dass durch einen weiteren Pool der Cache im SVC weiter partitioniert wird.

Optionen mit verlängerten Antwortzeiten, sofern Einschränkungen akzeptierbar sind:

  • Wenn möglich die Verarbeitung der zwei Volumes entzerren und hintereinander schalten.
  • Überprüfen, ob im Server die schreibenden Prozesse auf einen maximalen Durchsatz begrenzt werden können.
  • IO Governing im SVC einsetzen, um die Datenrate zu begrenzen. Das führt allerdings zu künstlich hohen Antwortzeiten für die Volumes. Es muss zusätzlich überprüft werden, wie die Serverprozesse auf diese Beschränkung reagieren.
  • In der Analyse hat sich gezeigt, dass diese Volumes auch beim Lesen wenig Vorteile durch den SVC-Cache haben. Eine Option wäre es daher auch, das Caching für diese Volumes komplett abzudrehen. Damit würden sie im SVC keine weiteren Störungen verursachen.

Fazit

Latenzzeit-Peaks finden wir heute in vielen Kundenumgebungen, die wir bei SVA analysieren. Die meisten I/O-Probleme entstehen durch eine punktuelle Überlastung der Speicherinfrastruktur. Mittels Umstrukturierung und besserer Verteilung lassen sich viele Engpässe selbst im Nachhinein mit geringem Aufwand beseitigen.

Ressourcen:

BVQ Webseite

BVQ YouTube Filme

Dokumente auf IBM Developerworks

SVC Treff - das Forum der SVC User Group Deutschland

(ID:36553230)