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

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.

Anbieter zum Thema

Nexus Industrial Memory

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.

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.

(ID:36533790)