Nachts von Performance-Überlegungen träumen? IOPS zum Frühstück? Willkommen in der schönen neuen Welt des VMware-Admin == Storage-Admin. In der schwingt man bekanntlich gerne mal das Iometer um Storage mit einem genau bekannten I/O-Profil zu befeuern, dadurch das Verhalten einer Anwendung zu simulieren und an der Storage-Konfiguration zu feilen. “Bekannt” bedeutet dabei, die Aufteilung der Storage-Zugriffe in Random/Sequential bzw. Read/Write sowie die verwendeten IO-Größen zu kennen. Was aber, wenn man genau dieses Profil nicht kennt und somit ratlos vor den Iometer-Einstellmöglichkeiten steht?

Trügerische Sicherheit

Willkürliche Einstellungen vorzunehmen oder Iometer mit einem der mitgelieferten Standard-Profile auszuführen ist hier nicht (wiederhole: NICHT) zielführend. Denn auch wenn ein Storage mit einem I/O-Profil XY gut klar kommt, ist das absolut unaussagekräftig über das konkrete Verhalten einer einzusetzenden Anwendung mit ggf. komplett anderen I/O-Profil. Überspitzes und einfaches Beispiel: Storage-seitig RAID5 konfiguriert, kann das bei Lese-intensiven Tests super performen. Konfrontiert man das gute Teil aber mit viel Schreib-Zugriffen kanns schnell eng werden (Stichwort partial-stripe writes).

Kenne deinen Feind

Es gilt also, das konkrete I/O-Profil des zum Einsatz kommenden Dienstes kennen zu lernen, um aussagekräftige Performance-Tests durchführen zu können. Glücklicherweise leben wir im 21. Jahrhundert und sind umgeben von Tools die einem bei der Suche nach dem I/O-Profil helfen können. Hier ein paar Beispiele, zweimal Windows-basiert, einmal genereller Natur.

—-

Variante #1 (Basic): perfmon

Der bunte Strauß an perfmon-Metriken gibt meist was her. So – zumindest ansatzweise – auch bei der I/O-Profil-Suche. Unter “Physical Disk” gibts mit “Average Disk Bytes/Read” und “Average Disk Bytes/Write” die mittlere I/O-Größe pro I/O und Festplatte. Gefährlich, da gemittelt, aber für eine erste Orientierung ausreichend (sprechen wir eher von 4K I/O oder 256K I/O?). “Disk Reads/secs” und “Disk Writes/sec” liefern einen Eindruck über die Read/Write-Verteilung. Bei der Frage nach Random/Sequential muss Perfmon passen.

Variante #2 (im Detail): Process Monitor / Disk Monitor

Eine Stufe detaillierter gehts mit den ehemaligen Sysinternals Tools. Process Monitor dient eigentlich zum Mitschneiden diverser Prozess-Aktivitäten, zeichnet dabei aber auch I/O-Details mit. Das lässt sich in bester MacGyver-Manier missbrauchen, um die I/O-Größen-Verteilung zu bestimmen (Login erforderlich). Anstatt SQL zur Auswertung kann man natürlich alternativ die Skripting-Sprache der Wahl draufloslassen. Wem das verständlicherweise zu fummelig ist, der weicht auf Disk Monitor aus. Der ist wie für diesen Zweck gedacht und mit etwas Excelei, entlockt man seinem System so im Handumdrehen die gewünschten Daten.

Variante #3 (auf anderer Ebene): Storage-seitig

Auf ganz anderer Ebene kann man ansetzen, wenn einem ein Storage-System gegönnt ist, das mit Performance-Werten nur so um sich schmeißt. Das kann im Idealfall direkt berichten, wie eingehender I/O zusammensetzt ist. Solche Diagnose-Möglichkeiten sollten übrigens bei jeder ernsthaften Storage-Evaluierung dazugehören. Was bringt einem ein zentrales Storage, wenn man bei Performance-Engpässen nicht feststellen kann, woran es liegt?!

Eine einfache Variante fürs eigene Lab wäre ein Solaris / OpenSolaris mit DTrace obendrauf. bitesize.d, iopattern und seeksize.d nehmen I/O auseinander und bereiten das statistisch auf. Kombiniert mit einer exportierten iSCSI LUN, ist so ein Filer denkbar, dessen Platten man zu Testzwecken flexibel an verschiedene OSe hängen kann. Oder alternativ mal die Sun Oracle Unified Storage VM runterladen, aus deren Performance-Graphen lässt sich so einiges rauslesen.

—-

Weitere Ideen oder Tools zum Bestimmen von I/O-Profilen? Was kommt in den Labs auf der anderen Seite meines Monitors zum Einsatz?