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

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.

Anbieter zum Thema

Dell GmbH

Schneider Electric GmbH

DataCore Software GmbH

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.

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.

(ID:36553230)