Ohne die von IBM mitgelieferten Tools ein graphisches Monitoring der Auslastung (I/Os, kb/s, cachehit) der DS4800 zu bekommen ist nicht so einfach – aber gelöst. Im folgenden das Wie? .

Teil I: Woher kommen die Daten ?

Die Daten bekommt man mit dem von IBM verfügbaren “SMcli” (Storage Manager Command Line Interface Utility). Dieses Programm kann sich mit den beiden Controllern eines Subsystems verbinden und gibt mit diversen Parametern einen “Haufen” Zahlen aus, die es im zweiten Schritt zu analysieren gilt.

Der Befehl:

/opt/IBM_DS/client/SMcli 192.168.12.100 192.168.12.101 -c "set session performanceMonitorInterval=60 performanceMonitorIterations=5; show allLogicalDrives performanceStats;"

Das Ergebnis (nach 5 Minuten):

Performing syntax check...

Syntax check complete.

Executing script...

Performance Monitor Statistics for Storage Subsystem: DS4800_1_EG
Date/Time: 1/26/10 11:29:05 AM
Polling interval in seconds: 60

Storage Subsystems,Total,Read,Cache Hit,Current,Maximum,Current,Maximum
,IOs,Percentage,Percentage,KB/second,KB/second,IO/second,IO/second
Capture Iteration: 1
Date/Time: 1/26/10 11:29:05 AM
CONTROLLER IN SLOT A,30661.0,59.4,63.6,42082.3,42082.3,502.6,502.6,

Logical Drive DLX001_VOL11_ASM7,1459.0,67.9,13.0,237.5,237.5,23.9,23.9,

Logical Drive DLX001_VOL3_MD1,102.0,2.9,0.0,28.0,28.0,1.7,1.7,

Logical Drive DLX001_VOL5_ASM3,2031.0,75.5,25.6,363.4,363.4,33.3,33.3,

Logical Drive DLX002_VOL1_ASM1,961.0,85.7,97.0,795.8,795.8,15.8,15.8,

Logical Drive DLX002_VOL5_ASM3,830.0,84.2,97.6,959.2,959.2,13.6,13.6,
...

Auf die Zahlen möchte ich an dieser Stelle nicht weiter eingehen. Das wichtige dabei zu wissen ist, dass dieses Programm alle 60 Sekunden die Zahlen erfasst, jedoch erst nach 5 Minuten (performanceMonitorIterations=5) die Zahlen ausgibt und ebenfalls konsolidiert. Danach beendet sich das Programm. Das macht die Integration in Cacti schwieriger. Cacti erwartet quasi “jetzt” Daten.

Das ganze wurde durch einen cronjob gelöst. Die SMcli Processe werden alle 5 Minuten gestartet – um eine Minute versetzt; also zu jeder 4,9,13… Minute. Dadurch hat SMcli noch genügend Zeit um die Daten auszugeben, bevor Cacti zu jeder 0,5,10… die Daten abfragt. Das Script für den cronjob sieht so aus:

#!/bin/bash
CACHE_PATH="/var/cache/cacti"
FILE_EXT=`date +%s`
# DS4800_1_eg
( /opt/IBM_DS/client/SMcli 192.168.12.100 192.168.12.101 -c "set session performanceMonitorInterval=60 performanceMonitorIterations=5; show allLogicalDrives performanceStats;" > ${CACHE_PATH}/1_eg_${FILE_EXT}; mv ${CACHE_PATH}/1_eg_${FILE_EXT} ${CACHE_PATH}/last_1_eg ) &

# DS4800_2_bu
( /opt/IBM_DS/client/SMcli 192.168.12.110 192.168.12.111 -c "set session performanceMonitorInterval=60 performanceMonitorIterations=5; show allLogicalDrives performanceStats;" > ${CACHE_PATH}/2_bu_${FILE_EXT}; mv ${CACHE_PATH}/2_bu_${FILE_EXT} ${CACHE_PATH}/last_2_bu ) &

Die IP Adressen sind dabei die Controller Adressen (ob dazu irgendwelche Rechte notwendig sind weiß ich leider nicht). Wie man sieht wird der Output zuerst in eine temporäre Datei geschrieben. Nachdem SMcli beendet ist, wird diese Datei zu last_X.. gemoved – das ganze muss man natürlich anpassen. Notwendig ist das, damit in der Theorie ein SMcli laufen kann, während ein anderes bereits für diese Datei gestartet wird.

Teil II: Das cacti Script (LUNs & Controller).

Am Ende möchten wir Graphen der Controller, als auch von den LUNs haben. Von daher gibt es für cacti zwei Scripte, welche die Daten der oben generierten Dateien auslesen. Das erste Script (ds_perfmon.pl) bekommt als Parameter den Namen einer LUN (so ist sie auch in Cacti (hostname) angelegt).

host#./ds_perfmon.pl SDS1_SILBER_DS4800_1_02
totios:1890.6 readpercent:0.26 cachehit:0 currentkb:127.9 maxkb:179.2 currentio:10.06 maxio:15.64

Nebenbei meldet das Script per logger (syslog) jeden morgen um 08:00 Uhr, wenn die gewünschte LUN nicht mehr vorhanden ist.

Download: DS Perfmon LUN Script.

Das zweite Script ist für die Auswertung der Controller zuständig.

Dabei gibt es zwei Aufrufmöglichkeiten:

1. als Parameter die Controller Nummer (entsprechend der Konfiguration innerhalb des Scripts)
2. als Parameter s – für “summary” (Statistik über alle Controller)

Innerhalb des Scripts werden die Controller und die zugehörigen Dateien definiert. Dabei gibt es – sofern in jeder DS zwei Controller stecken – immer einmal “CONTROLLER IN SLOT A” und “… IN SLOT B” für jede Datei. Die Variablen “all_controller” und “data_files” sind also korrespondierend und müssen jeweils über gleich viele Einträge verfügen. Am Ende werden dann die Controller durchnummeriert – entsprechend der Position im Array (all_controller/data_files; angefangen bei 1).

host# ./ds_perfmon_Controller.pl 1
readpercent:51.54 cachehit:66.2 currentkb:11804.82 currentio:542.58

host# ./ds_perfmon_Controller.pl s
readpercent:2846.4 cachehit:3345.6 currentkb:45.4075049471902 currentio:35744.4

Download: DS Perfmon Controller

Teil III: Die Cacti Konfiguration.

Die cacti Konfiguration ist – für Euch – ganz einfach. Die Konfiguration kann einfach per .xml heruntergeladen werden.

DS4000 Cacti Konfig (.tgz(.xml))

Danach kann mit Hilfe der folgenden Schritte das Monitoring eingerichtet werden:

1. “create new Host”
2. Description/Hostname für die LUNs = Name der LUN; für den Controller = beliebig (bspw. DS 4800 Controller 1)
3. “Host Template” für die LUNs = “DS4000″; für die Controller = “DS4000 Controller”
4. “Downed Device Detection” -> none
5. create
6. “create graphs for this host” -> alle angebotenen anklicken und “create”
7. (für Controller wird noch die Nummer des Controllers (s. Teil II) abgefragt)

Damit sollte dann alles erledigt sein.