Workshop I/O-Analyse am Beispiel SVC und Storwize V7000, Teil 1 Eine Performance-Bottleneck-Analyse erspart Hardware-Updates

Autor / Redakteur: Michael Pirker, SVA / Rainer Graefen

Kein IT-Prozess, der nicht irgendwann durch einen Flaschenhals behindert wird. Deshalb muss man jedoch nicht gleich in neue Hardware investieren. Häufig reicht eine kleine Reorganisation von Ports wie unser Autor detailliert ausführt.

Auslastungsgrad bei der dedizierten Port-Darstellung.
Auslastungsgrad bei der dedizierten Port-Darstellung.
(Michael Pirker, SVA)

In der IT sind Latenzzeit-Spitzen, auch wenn sie sporadisch auftreten, gefährliche Störenfriede und es bedarf gezielter Methoden, um sie aufzuspüren und zu verhindern. Die gezeigten Möglichkeiten beziehen sich auf das IBM Speichersystem SAN Volume Controller (SVC) oder IBM Storwize V7000, das auch SVC Code verwendet.

Als Analyse-Instrument wird Business Volume Qualicision (BVQ) verwendet, da es sehr interaktiv ist und die von SVC bereitgestellten Metriken vollständig auswerten kann.

Bildergalerie
Bildergalerie mit 9 Bildern

Welche Formen von Bottlenecks gibt es?

Bottlenecks (dt. Engpässe) lassen sich in zwei verschiedene Gruppen aufspalten. Der generelle Engpass zeigt sich durch konstant hohe Antwortzeiten und damit verbundene schlechte Performance. Dieser Engpass ist relativ leicht zu analysieren und in den Griff zu bekommen, da man hier meist einen direkten Zusammenhang zwischen aktueller Belastung und Antwortzeit herstellen kann.

Das Problem einer generellen Überlastung wird meistens mit der Erweiterung der technischen Systeme gelöst. Das muss nicht unbedingt die beste Maßnahme sein, da hier durch Umstrukturierung kostengünstigere und vor allen Dingen nachhaltigere Verbesserungen möglich sind.

Der zweite Typ Bottleneck – oder auch „Peak“ - hat die lästige Eigenschaft, nur sporadisch und scheinbar unvorhersehbar aufzutreten. Die Antwortzeit von Volumes schießt unvermittelt auf Werte von 30 bis 70 Millisekunden und höher.

Das verschlechtert im einfachsten Fall die Antwortzeiten der betroffenen Server und verlängert damit die Ausführungszeit von Prozessen, kann aber im schlimmsten Fall auch zum Absturz einzelner Systeme führen. (Abb. 1: Der typische Antwortzeit-Peak aus Applikationssicht)

Wenn es keine aus dem Nutzer oder Applikationsverhalten nachvollziehbaren Gründe für den Peak gibt, wird man sich zuerst die betroffenen Volumes ansehen, für die die schlechte Performance gemeldet wurde.

Nur zu oft stellt man hier allerdings fest, dass das Zugriffsverhalten der Volumes in diesem Zeitraum keinen Anlass für eine schlechtere Antwortzeit gab. Also muss man das Volume im Speichersystem, sein Umfeld und das SAN als Transportmedium untersuchen.

Analyse eines Antwortzeit-Peaks

Ausgangspunkt der Analyse ist ein Volume, in dessen Betrieb immer wieder Spitzen in der Antwortzeit auftreten. In der BVQ Treemap Darstellung mit „IO Density Analyse“ werden das untersuchte Volume und dessen Speicherpool (MDG) blau dargestellt, was eine Indikation dafür ist, dass die zugrundeliegende Speicherinfrastruktur leistungsmäßig zu weniger als 20 Prozent ausgelastet wird. (Abb. 2: Die BVQ TreeMap-Darstellung visualisiert den Speicheraufbau des SVCs.)

Aus diesem Grund haben wir hier kein generelles Bottleneck, sondern müssen von einer punktuellen Überlastungssituation ausgehen. Um diese näher zu analysieren, müssen wir tiefer in die Analyse des Speichers einsteigen. Der erste tiefer gehende Blick ist die Analyse der I/O-Last des Volumes (IOPS) verglichen mit dessen Antwortzeit wie in Abb. 3 dargestellt.

Abb. 3: beschreibt das Schreib- und Leseverhalten (RW-Verhalten) des Volumes über einen kompletten Tag von 0 Uhr bis 24 Uhr. Folgende Aussagen kann man aus der Graphik ablesen:

  • Das Volume arbeitet kontinuierlich auf einem kleineren Niveau, einmal pro Stunde werden allerdings größere Mengen von Daten geschrieben und gelesen. In diesen Zeiträumen erreicht die Aktivität ca. 120 IOPS. Die normalen Antwortzeiten liegen bei zwei bis drei Millisekunden.
  • In der Zeit von 5:00 bis 6:30 Uhr steigt die Antwortzeit des Volumes, bei gleichbleibender Belastung, sprunghaft an. Statt mit 3ms antwortet das Volume nun mit 50 bis 85 Millisekunden, also eine Verschlechterung der Antwortzeit fast um den Faktor 30 ohne Veränderungen im Arbeitsverhalten des Volumes.
  • Es ist unerheblich, ob das Volume auf einem niedrigen oder hohen Niveau arbeitet. Im gesamten Zeitraum von 5:00 bis 6:30 Uhr wird das Antwortverhalten des Volumes als schlecht wahrgenommen. Bei höherer Belastung treten jetzt Peaks auf.
  • Im Zeitraum von 6:30 bis 8:15 Uhr hat sich die die Latenzzeit des Volumes verbessert. Die Latenzzeit des Backendspeichers (Bildausschnitt rechts) ist immer noch hoch.

Da die hohen Antwortzeiten von 5:00 bis 6:30 Uhr nicht mit der Aktivität des Volumes zusammenhängen, müssen sie aus einer Überlastungssituation herrühren, die an einer anderen Stelle im Speichersystem oder im SAN passiert.

Der nächste sinnvolle Schritt ist, die Stelle zu finden, an der die Überlastung auftritt, um daraufhin die Ursache für diese Überlastung zu suchen.

Ein Blick in das SAN sagt: Alles im grünen Bereich!

Eine Analyse der SAN-Ports (Abb. 4: Datendurchsatz der SAN-Ports der SVC-Knoten) zeigt, dass im fraglichen Zeitraum von 5:00 bis 6:30 Uhr signifikant größere Datenmengen (lila) über das SAN transferiert wurden.

Gegen 4:00 Uhr gab es zwar eine Spitze von ca. 2,5 Prozent Buffer Credit Wait (gelb). Im fraglichen Zeitraum von 5:00 bis 6:30 Uhr war diese Behinderung allerdings nicht relevant ausgeprägt. Auch weitere typische SAN-Fehler wurden vom SVC im fraglichen Zeitraum nicht aufgezeichnet, so dass man sagen kann: Es gibt keine Anzeichen, das SAN als Ursache der hohen Latenzzeiten zu betrachten!

Ein proaktiv denkender Administrator wird sicherlich die gelben Nadeln zur Abendzeit im Kopf behalten. Offensichtlich treten Buffer Credit Wait % Situationen ab 800 MByte/s häufiger auf. Eine tiefere Analyse zeigt, dass die SAN-Ports sehr ungleichmäßig belastet sind, was zu einer Verschlechterung der Gesamtleistung führt. (Abb. 5: Dedizierte Port-Darstellung)

In Abbildung 5 wird ein genereller Engpass deutlich, der - wie im ersten Abschnitt beschrieben - vorhersehbar ist und sich bei wachsenden Datenmengen und Last in der Zukunft als Problem zeigen wird. Man könnte in neue Hardware investieren oder wesentlich kostengünstiger die Belastung der Ports besser ausgleichen.

Buffer Credit Wait % wird mit zunehmendem Anstieg verstärkt zu einer ernsthaften Behinderung und muss dann bei vermehrtem Auftreten dringend gelöst werden. Die Ursachen für häufiges Auftreten können in nicht ausreichenden Buffer Credits in den Switch Ports liegen oder in sogenannten „Slow Draining Devices“, die den Datenverkehr im SAN stören.

Ein Blick in den Cache des Speicherpools sagt: Da ist was!

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 und sich eine hohe Anforderung an Cache-Ressourcen im Speicherpool nur in dem jeweiligen Pool auswirkt.

Untersucht man den Cache des Speicherpools zum Zeitpunkt des Peaks, so findet man hier Auffälligkeiten, die deutlich auf Probleme hinweisen. (Abb. 6: Überlastzustand der Cache-Partition)

Aus Abbildung 6 können einige wichtige Informationen herauslesen werden:

  • Im Zeitraum von 5:00 bis 6:30 Uhr war die Cache-Partition mit teilweise 103 Prozent komplett überlastet (grüne Kurve). Man sieht, dass der SVC sich in dieser Zeit intensiv um das Destaging der Daten bemüht hat. Mit bis zu 1700 IOPS wurden Datenpakete aus dem Cache auf den Backend-Speicher transferiert. Im Normalbetrieb wird aus dieser Cache-Partition mit nur 80 bis 120 IOPS destaged.
  • Von 6:30 bis 8:15 Uhr wurde das Destaging auf von 1700 auf 500 IOPS zurückgefahren. In dieser Zeit sieht man immer noch hohe Latenzzeiten im Backend Storage. Im Volume selbst treten durch den freigewordenen SVC Cache weniger Latenzprobleme auf.
  • Um 21:00 und 23:00 Uhr sieht man weitere Spitzen in der Cache-Auslastung. Allerdings wurde hier der SVC-Cache mit maximal 100 Prozent aufgefüllt, was die Destaging-Operationen lediglich auf 200 bis 350 IOPS erhöht hat.

Man kann jetzt von zwei Ursachen für die schlechten Antwortzeiten der betroffenen Volumes ausgehen: Das unterliegende Speichersystem ist durch das intensive Destaging der Daten aus dem Cache überlastet und konnten nicht mehr so schnell auf die Anfragen der anderen Volumes reagieren. Außerdem war der Cache zu mehr als 100 Prozent aufgebraucht und anderen Volumes konnte für ihre Operationen kein Cache mehr zugeteilt werden.

Der Überfüllung des Caches liegt ein Problem zugrunde, das man auf verschiedene Arten lösen kann. Die Ursache liegt darin begründet, dass in einer relativ kurzen Zeiteinheit große Datenvolumen von Servern geschrieben wurden, die beim Destaging nicht schnell genug vom angeschlossenen Speichersystem aufgenommen werden konnten.

Möglichen Lösungen sind:

  • 1. Reduzierung der Schreibgeschwindigkeit (vom Server langsamer schreiben)
  • 2. Verbesserung der Leistungsfähigkeit des angeschlossenen Speichers (aus SVC Cache schneller Daten destagen)
  • 3. Strukturelle Änderungen im Ablauf der Schreiboperationen (Prozesse zeitlich entzerren, Volumes isolieren)

Um hier die richtige Antwort zu finden, muss man jetzt herausfinden, welche Prozesse für das hohe Datenvolumen verantwortlich sind. Im nächsten Schritt werden daher die Volumes gesucht, die in dieser Zeit solche großen Datenmengen geschrieben haben. Wenn die Volumes gefunden sind, sollte es kein Problem sein, die entsprechenden Server und deren Prozesse genau zu lokalisieren.

Im zweiten Teil des Artikels untersucht Michael Pirker wie man das I/O-Bottleneck durch konzeptuelle Maßnahmen beseitigt.

Ressourcen:

BVQ Webseite

BVQ YouTube Filme

Dokumente auf IBM Developerworks

SVC Treff - das Forum der SVC User Group Deutschland

(ID:36533790)