MultiStore Schema with 3 vFilers, Source: http://media.netapp.com/images/tot-netapp-multistore.jpg

Die MultiStore Software von NetApp ermöglich ein physisches NetApp Gerät in mehrere virtuelle vFiler aufzuteilen. Jeder dieser vFiler kann für sich von den anderen strikt getrennt verwaltet werden –  wie wenn es sich jeweils um ein eigenes, physisches Gerät handeln würde:

• Der Administrator eines vFilers kann nur dessen Dateien verwalten
• Die Daten fremder vFiler sind für den vFiler-Admin nicht sichtbar.
• Volumes und Qtrees können einem vFiler exklusiv zugeteilt werden.

Der physische Storage wird damit mandantenfähig.

Für das Monitoring kann es natürlich interessant sein, die Volumes eines bestimmten vFilers zu überwachen. Das um so mehr als dank “Over-All”-Checks dynamisch erkannt wird, welche Volumes am Filer gerade existieren.

Um die Überwachung ebenfalls mandantenfähig gestalten zu können, muss es möglich sein gezielt den vFiler ansprechen zu können, dessen Volumes überwacht werden sollen.

Die Nagios-Plugins für NetApp ermöglichen dies seit der Version 2.3.0. Bei jedem Check kann mittels der Option –vfiler=My_vFiler angegeben werden, welcher der vFiler in einer MultiStore-Umgebung geprüft werden soll.

Link: Leistungsbeschreibung Nagios Plugins für NetApp(mit vFiler-Switch).pdf

Weitere Informationen: http://netapp-monitoring.info/

Beispiel:

$ perl check_netapp.pl Status -H toaster
NETAPP OK - Status: ok, The system's global status is normal.
===== EXTENDED SYSTEM INFORMATION =====
ONTAPI-Version: 1.12
Data ONTAP Version: NetApp Release 7.3.4P3: Thu Oct 7 15:23:27 PDT 2010
Vendor-Info, OID-Prefix: .1.3.6.1.4.1.789
vendor-id: NetApp
system-name: filer
partner-system-id: 0131185999
cpu-processor-type: Intel Xeon
board-type: System Board X
cpu-part-number: 110-00035
system-machine-type: FAS3020
system-serial-number: 20588990
memory-size: 2048
cpu-firmware-release: CFE 3.1.0
cpu-serial-number: 0322221
board-speed: 2797
cpu-microcode-version: 45
supports-raid-array: false
partner-system-name: filer2
system-model: FAS3020
system-id: 0001142064
number-of-processors: 2
cpu-processor-id: 0xf29
system-revision: D0
cpu-revision: B1

Derzeit verfolge ich diese Konferenz über die NetApp DevCon2011 in Japan-Update Seite.

Doch was, wenn die Storage-Gruppe nachweisen will oder muss, dass die Volumes grundsätzlich schreib- und lesbar sind? Hier wäre ein Check gefragt, der je Volume eine Datei anlegt, liest und löscht – und das ganze am direkten Weg über die NetApp API. Dieser Check wäre von anderen Services (wie z.B. einem Domaincontroller) weitestgehend unabhängig.

Um herauszufinden, ob Bedarf an einem solcher Check besteht, haben wir eine Umfrage gestartet:

Nagios SLA-Monitoring-Plugin für NetApp: http://netapp-monitoring.info/de/umfragen/sla.html

Links:

[1] http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/check_diskwrite2/details

NetApps’s SnapManager for Virtual Infrastructure (SMVI) zum Beispiel macht es: Snapshots im Volume zu hinterlassen, die manuell gelöscht werden müssten. Diese verwaisten Snapshots verbrauchen mehr und mehr Platz am Volume und binnen kurzem kann dieses voll sein. Für diese und ähnliche Anwendungsfälle wird nun das Check-Module Snapshots der  Nagios Plugins für NetApp erweitert. So soll es möglich werden, die zu überwachenden Snapshots nach Alter zu filtern. Somit wäre es beispielsweise möglich, dass man sich warnen lässt, wenn auf einem Volume über 50% der Snapreserve für Snapshots älter als 14 Tage belegt werden.

Aber auch ein Filter nach Namen wäre denkbar. Dann könnten nur jene Snapshots in die Alarmierung miteinbezogen werden, die einem bestimmten Muster entsprechen wie bespielsweise  ’*smvi*’ oder ‘hourly*’.

Gerne können Sie Ihre Wünsche dazu mittels dieser Umfrage deponieren:

http://netapp-monitoring.info/de/umfragen/snapshot-age.html

$ ./check_netapp.pl –explore

Available Check-Plugins:    
Cluster		Checks the cluster service (state and time-master).
Hardware	Checks temperature-sensors, fans, power-supplies,
                nvram and disks on NetApp filers.    
iSCSI		Checks the state (online, offline, ...) of
                iSCSI-adapters on NetApp filers.    
PerfCpu		System CPUs resource utilization.    
PerfDisk	Check for system disks resource utilization.    
PerfIf		Checks transfer and errors per ethernet-interface.    
PerfSys		Checks operations/second and transfer-rate.    
PerfVolume	Checks a volumes latency or operations/second.    
Quotas		Checks the usage of disk- and file-quotas.    
Raidstatus	Checks the raid-status of volumes or aggregates.    
SnapMirror	Checks the state, lag-time and transfer-duration of
		SnapMirros.
Snapshots	Checks the space occupied by volume-snapshops.
SnapVault	Checks the SnapVaults-state, duration of last
		transfer and lag-time on secondary filers.
Status		Checks the global status of NetApp filers.    
Usage		Checks the used space of aggregates or volumes.

Der Workaround dafür schaut so aus:

define service {
	use                  netapp-service
        host_name            san.mycomp.net
	service_description  Temperature-Sensors
        check_command	     check_netapp!Hardware!-o temp 2>/dev/null
 }

Für alle die neugierig sind, was wir denn da für Warnungen ausgeben: Bei einigen NetApp-Modellen gibt es “potentielle” Hardware-Komponenten, die aber auch einfach fehlen dürfen. Die werden von DataONTAP dann als missing ausgegeben. Damit die Checks das einerseits nicht laufend als Fehler alarmieren andererseits der Admin über diese fehlenden Komponenten zumindest auf der Kommandozeile hingewiesen wird, geben wir diese Hinweise nach stderr aus.

Nagios-Plugins für NetApp (und Icinga)

In der Praxis ist es dann oft so, dass ein System sich sang- und klanlos verabschiedet und wenn der zugrundeliegende Fehler dann endlich erkannt und behoben ist  so dass das System wieder hochfährt, dann versendet es frisch fröhlich jene Traps, die es ausfallsbedingt zuvor nicht mehr losgeworden ist.

Diese grundlegenden Probleme von Traps kommen zu den SNMP-spezifischen Schwierigkeiten wie in dem Artikel “Monitoring NetApp: SNMP vs. NetApp API” beschrieben noch hinzu. Ich habe daher darauf verzichtet, noch genauer nachzuforschen, inwieweit die komplexe NetApp-Technik durch definierte Traps abgedeckt wird.

Utilization: Percentage of time there was at least one outstanding request to the disk

Neu ist, dass bei Perfdisk ein Filter für das Aggregat gesetzt werden kann. Sinnvoll ist das vor allem um heraus zu finden, ob für ein Aggregat weitere Festplatten nötig sind, um der Belastung gewachsen zu sein.

Nagios-Plugins für NetApp

Es lag daher nahe, auf Basis des NetApp SDK ein Nagios-Plugin zu entwickeln, das die Latenz eines Volumes regelmäßig prüft und aufzeichnet. Mit PerfVolume steht ein solches seit heute zur Verfügung.

Unterstützte Counter

Wie auch die anderen Plugins, verfügt PerfVolume.pm über eine Option zur Erkennung der auf einem NetApp-System angebotenen Leistungskennzahlen.

Aufgerufen wird dieses Check-Plugin übrigens mit dem zu der Version 2 gehörigen Startskript check_netapp.pl.

$ ./check_netapp.pl PerfVolume -H sim8a -f ../auth --explore=counters
Volume Performance Counters available on this filer:
================================================================================
Counter-Name                Description (Unit, Privilege)
--------------------------------------------------------------------------------
read_latency                Average time for reads to the volume (microsec,
			    basic)

avg_latency                 Average latency in microseconds for all operations
			    on the volume (microsec, basic)

total_ops                   Number of operations per second serviced by the
			    volume (per_sec, basic)

other_latency               Average time for other operations to the volume
			    (microsec, basic)

other_ops                   Number of other operations per second to the volume
			    (per_sec, basic)

write_ops                   Number of writes per second to the volume (per_sec,
			    basic)

write_latency               Average time for writes to the volume (microsec,
			    basic)

read_ops                    Number of reads per second to the volume (per_sec,
			    basic)

Beispiel

Nehmen wir den Counter avg_latency als Beispiel. Folgend der Aufruf über die Komandozeile und die Ausgabe.

$ ./check_netapp.pl PerfVolume -H sim8a -f ../auth -z avg_latency -n vol0 -w 20 -c 200
NETAPP OK - avg_latency: 3.2 µs | avg_latency=3.20µs;20;200

Verdächtig flott – aber dieser Filer hat nicht viel zu tun …

Link

[1]
Storage Performance Management