BVQ Use Case Performance Bottleneck Analyse auf IBM SVC und IBM Storwize V7000

Transkript

1 Kein IT-Prozess, der nicht irgendwann durch einen Flaschenhals behindert wird. Deshalb muss man jedoch nicht gleich in neue Hardware investieren. Eine Analyse mit BVQ zeigt auf, wo die Gründe für den Flaschenhals zu suchen sind. BVQ Use Case Performance Bottleneck Analyse auf IBM SVC und IBM Storwize V7000 Michael Pirker Pirker SVA GmbH Dieses Whitepaper wurde in 2 Teilen auf Searchstorage veröffentlicht

2 Performance Bottleneck Analyse auf IBM SVC und IBM Storwize V7000 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 Analyseinstrument 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 30ms bis 70ms 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. 1

3 Abb. 1: Der typische Antwortzeit-Peak aus Applikationssicht. Ohne erkennbaren Grund treten Antwortzeiten auf, die teilweise um den Faktor 30 Faktor 50 höher sind als geplant. In der Unvorhersehbarkeit von Peaks liegt auch eine ihrer größten Gefahren. Man konnte nicht vorhersehen, dass ein Peak mit einem gewissen Ausmaß passieren würde. Wie soll man wissen, ob nicht ein Folge-Peak diese Ausmaße bei Weitem übertrifft? Mit dieser Überlegung ist es fahrlässig, hier einen Status Quo zu dulden, weil man damit den Kontrollverlust und Schäden durch Ausfälle akzeptieren würde. 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 Volume und der Speicherpool (MDG) blau dargestellt, was eine Indikation dafür ist, dass die zugrundeliegende Speicherinfrastruktur leistungsmäßig zu weniger als 20% genutzt wird. 2

4 Abb2: in dieser BVQ TreeMap-Darstellung wird der Speicheraufbau des SVCs visualisiert. Der Darstellungsaspekt ist auf Performance eingestellt, damit werden Volumes oder Pools je nach Performance größer oder kleiner dargestellt. Die Einfärbung der Objekte ist als Heat Map zu interpretieren. Blaue Objekte sind dabei Volumes oder Pools, die die Leistungsfähigkeit des Speichers nur sehr schwach (<20%) ausschöpfen. Die nächsten Stufen in der Heat Map sind grün, dann gelb und letztendlich rot. 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 tiefergehende Blick ist die Analyse der Volume IOPS verglichen mit der Antwortzeit des Volumes. Abbildung 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: 3

5 Abb. 3: 24h Schreib-/Lese-Operationen des Volumes in Grün mit den zugehörigen Antwortzeiten in Rot. Zum Zeitpunkt der aufgetretenen Peaks sieht man eine Vervielfachung der Antwortzeiten (Faktor 30) ohne ersichtlichen Grund. Die Antwortzeiten des Backend-Speichers (Bild rechts) sind auch stark erhöht, was auf ein Problem im Speicher oder in der Datenübertragung zum Speicher hinweist. 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 2ms bis 3ms. 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 50ms bis 85ms, 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. 4

6 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: Im fraglichen Zeitraum ist alles im normalen Bereich! Eine Analyse der SAN-Ports (Abb. 4) zeigt, dass im fraglichen Zeitraum von 5:00 bis 6:30 Uhr sehr große Datenmengen (lila) über das SAN transferiert wurden. Abb. 4: Die SAN-Ports des SVC-Nodes. In Lila wird der Datendurchsatz über alle Ports dargestellt. In Gelb wird der sogenannte Buffer Credit Wait % /(BCW%) dargestell,.eine Angabe, aus der man herauslesen kann, wie lange der SVC auf die Bereitstellung eines Kommunikationspuffers warten musste. Im fraglichen Zeitraum wurden große Datenmengen geschrieben und gelesen. Es gab jedoch in diesem Zeitraum kein vermehrtes Auftreten von Beeinträchtigungen wie BCW% oder SAN-Fehler. Gegen 4:00 Uhr gab es zwar eine Spitze von ca. 2.5% 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: Das SAN war nicht an den hohen Latenzzeiten des Volumes schuld! Ein proaktiv denkender Administrator wird sicherlich die gelben Nadeln zur Abendzeit im Kopf behalten. Offensichtlich treten Buffer Credit Wait % Situationen ab 800 MB/s häufiger auf. Eine tiefere Analyse zeigt hier auf, dass die SAN-Ports sehr ungleichmäßig belastet sind, was zu einer Verschlechterung der Gesamtleistung führt. 5

7 Abb. 5: Die gleiche Darstellung auf Basis der einzelnen Ports - man sieht deutlich, wie unterschiedlich die Ports ausgelastet werden. Das erzeugt einen Engpass lange bevor die Leistungsfähigkeit der Hardware erreicht ist. Dieser Engpass ist ein genereller Engpass, der ohne Investitionen in neue Hardware verbessert werden kann. In Abbildung 5 wird ein genereller Engpass deutlich, der - wie im ersten Abschnitt beschrieben - vorhersehbar ist und sich bei wachsenden Datenmengen 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 ab ca. 10% 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 ein Cache-Problem im Speicherpool nur in dem jeweiligen Pool auswirkt. Untersuchen wir den Cache des Speicherpools zum Zeitpunkt des Peaks, so finden wir hier Auffälligkeiten, die auf jeden Fall auf Probleme hinweisen. 6

8 Abb. 6: Ein Blick auf die Cache-Partition des betroffenen Storage Pools (MDG). In Grün ist der Füllgrad des Caches angegeben, der über lange Zeit 103 % aufweist. In diesem Zeitraum reagiert der SVC mit vielen Destage Operationen (weiß) um den Cache-Füllgrad zu reduzieren. So eine Situation führt zwangsweise zu einem zeitlich begrenzten Engpass. Aus Abbildung 6 kann man eine ganze Menge an Informationen herauslesen: Im Zeitraum von 5:00 bis 6:30 Uhr war die Cache-Partition mit teilweise 103 % 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 OPS wurden Datenpakete aus dem Cache auf den Backend- Speicher transferiert. Im Normalbetrieb wird aus dieser Cache-Partition mit nur 80 OPS bis 120 OPS destaged. Von 6:30 bis 8:15 Uhr wurde das Destaging auf von 1700 auf 500 OPS 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 % aufgefüllt, was die Destaging-Operationen lediglich auf 200 OPS bis 350 OPS erhöht hat. Man kann jetzt von zwei Ursachen für die schlechten Antwortzeiten der betroffenen Volumes ausgehen: Der SVC und das unterliegende Speichersystem haben sich auf das Destaging der Daten aus dem Cache konzentriert und konnten nicht mehr so schnell auf die Anfragen der anderen Volumes reagieren. Außerdem war der Cache zu mehr als 100 % aufgebraucht und anderen Volumes konnte für ihre Operationen kein Cache mehr zugeteilt werden. 7

9 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 von Servern große Datenvolumen 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 schnellerer Daten destagen) 3. Struktureller Ä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. Die Suche nach dem Verursacher 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. 8

10 Abb. 7: Die Write-Datenraten aller Volumes aus dem betroffenen Storage Pool und das Aggregat (Summe aller Writes). Man sieht, dass nur zwei Volumes für den Peak zwischen 5:00 und 6:30 Uhr verantwortlich sind. Die zwei Volumes aus Abbildung 7 werden in Abbildung 8 etwas genauer betrachtet. Wieder passt der Zeitraum der Schreiboperationen exakt zum Zeitraum, in dem die Probleme aufgezeichnet wurden und in dem der Partitions- Cache der Speicherpools übergelaufen war. Abb. 8: Aus diesem Bild lässt sich ablesen, wann welches Volume während der problematischen Zeit zwischen 5:00 und 6:30 Uhr geschrieben hat. Das Problem trat nur 9

11 auf, als beide Volumes parallel eine Gesamt-Datenrate von über 140 MB/s erzeugt haben. Mit dem Ende des Schreibens von Volume 1 ist die Datenrate von Volume 2 von 35MB/s auf 105MB/s angestiegen. Man sieht im kleinen Einschubbild, dass ab dieser Zeit die Cache-Belastung reduziert wurde. Damit war auch die problematische Cache-Situation im Speicherpool beendet. 105MB/s scheint eine Datenrate zu sein, die dieser Speicherpool gerade eben noch bewältigen kann. 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 MB/s startete, hat seine Performance auf 105 MB/s erhöht, als das erste Volume mit seiner Arbeit fertig war. In Summe haben beide Volumes versucht, bis zu maximal 155 MB/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 MB/s weitergearbeitet, ein Datenvolumen, das der Backendspeicher über einen längeren Zeitraum gerade noch aufnehmen konnte. Der Schreibcache wurde in diesem Zeitraum entlastet, aber - wie man in Abbildung 3 sehen kann - sind die Antwortzeiten des Backend-Speichers nach wie vor sehr hoch. Das bedeutet, wie haben hier eine gute Abschä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 MB/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 MB/s beendete. Ab 6:30 Uhr gab es keine Probleme mehr im Speicherpool. Offensichtlich sind die 105 MB/s für den Pool und das dahinter liegende Speichersystem kein Problem, 140 MB 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 Problem zu lösen. 10

12 Optionen, wenn man für diese Prozesse keine Einschränkung der Datenrate und damit in der Verarbeitungszeit hinnehmen möchte: Performanteren Speicher einsetzen, damit die 140 MB/s verarbeitet werden können. Sinnvollerweise plant man hier allerdings eine Speicherklasse ein, die mit mindestens 220 MB/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, am besten mit zwei getrennten Speichersystemen im Hintergrund 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. Weitere Optionen, wenn man Einschränkungen akzeptieren kann: 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 natürlich ü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 ist 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 analysieren. Die meisten dieser Situationen werden durch eine punktuelle Überlastung der Speicherinfrastruktur erzeugt und können durch 11

13 Umstrukturierung und bessere Verteilung beseitigt werden. Das bedeutet: Analyse vor Neukauf! Ein Neukauf oder eine Erweiterung erzeugen neue Hardwarekosten und sind oft nur eine vorübergehende Verbesserung, weil das Problem zwar in seinen Auswirkungen gemindert aber nicht gelöst wird. Schnelle Speichersysteme mit vielen Disks, großen Caches, SSD Speicher und automatischem Tiering ermöglichen eine hohe Leistung, die allerdings durch schlechte Planung und damit verbundener punktueller Überlastung leicht ausgehebelt werden kann. An diesem Punkt gewinnt der Einsatz guter Monitoring- und Analyseinstrumente an Bedeutung, die es ermöglichen, diese Hotspots in den Systemen zu finden und zu beseitigen. Hier wurde für das Monitoring und die Analysen Business Volume Qualicision (BVQ) verwendet. Dieses Softwareprodukt wurde vom IBM Business Partner SVA GmbH entwickelt und ist mittlerweile in Deutschland bei über 40 Kunden im Einsatz. BVQ ermöglicht Monitoring, Reporting, Analyse SLA Management und die Verrechnung von Speicherkosten für die Speichersysteme IBM San Volume Controller (SVC) und IBM Storwize V7000. BVQ wird von SVA und anderen IBM Geschäftspartnern vertrieben. Sprechen Sie uns an wenn Sie Interesse an BVQ oder einer Analyse Ihres SVC/Storwize V7000 Speicherumfeldes haben. BVQ Webseite BVQ Wiki (technische Inhalte) BVQ YouTube Filme Weitere Dokumente auf IBM Developerworks 12