NetApp-Systeme in CMDB einpflegen?

18. November 2011

Um einen oder mehrere NetApp-Filer  in die Konfigurations-Datenbank zu übernehmen, kann man auf das Check-Modul ‘Status’ zurückgreifen. Alle relevanten Werte werden von diesem direkt vom System ausgelesen und können dann weiter verarbeitet werden.

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

Kommentar schreiben » | NetApp | Permalink
Verfasst von lanti

NetApp DevCon2011 in Japan

29. September 2011

NetApp DevCon2011 in JapanSoftware-Entwickler, spezialisiert auf  Produkte rund um NetApps DataONTAP treffen sich zur Zeit in Japan. Eine ähnliche Konferenz ist auch für Europa geplant – würde mich freuen, wenn daraus etwas wird.

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

Kommentar schreiben » | NetApp | Permalink
Verfasst von lanti

NetApp SLA-Monitoring mit Nagios?

9. Juni 2011

Ist ein Storage-System nun verfügbar oder nicht? Das ist auch eine Frage des Standpunktes. Aus Benutzersicht ist er nur dann verfügbar, wenn auch alle Services am Weg dorthin „up and running“ sind. Dafür gibt es Nagios-Plugins, die dies regelmäßig überprüfen und aufzeichnen (z.B. check_diskwrite2 [1]).

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

 

 

Kommentar schreiben » | SLA | Permalink
Verfasst von lanti

Monitoring verwaister Snapshots (SMVI, …)

10. Mai 2011

Monitoring Snapshot-Age – veraltete Snapshots finden und überwachen

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

Kommentar schreiben » | Age of Snapshots, Alarmierung, Nagios Plugins für NetApp, snapshot date, Snapshots | Mit Tag(s) versehen: | Permalink
Verfasst von lanti

check_netapp.pl: Übersicht und Funktionsbeschreibung installierter Plugins

11. April 2011

Die Suite Nagios Plugins für NetApp besteht aus mehreren Check-Plugins, die jeweils einzeln gekauft und installiert werden können. Praktisch ist hier der Überblick, den der Schalter –explore bietet: Es werden alle installierten Plugins aufgelistet zusammen mit einer kurzen Funktionsbeschreibung.

$ ./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.

Kommentar schreiben » | Nagios Plugins für NetApp, Userinterface | Permalink
Verfasst von lanti

NetApp Plugins für Icinga

10. März 2011

Icinga Screenshot in dem die nach stderr ausgegebenen Meldungen zu sehen sind.Erstmals sind die Nagios Plugins für NetApp auf einem Icinga System zur Überwachung zweier NetApp-Filer im Einsatz. Die Tests verliefen erwartungsgemäß ohne große Aufregung. Lediglich bei den Hardware-Tests gibt es ein kleine Besonderheit: Icinga sendet nicht nur stdout sindern auch stderr an das Monitoring-System weiter. Damit landen einige Warnungen der Perl-Scripts, die bewusst auch ausgegeben werden, in der Icinga-Webobefläche.

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)

Kommentar schreiben » | Icinga, NetApp Überwachung, NetApp Monitoring | Permalink
Verfasst von lanti

SNMP-Traps als Alternative zur ZAPI?

3. Dezember 2010

Vor kurzem erreichte mich eine Anfrage, ob denn nicht das NetApp-Monitoring auch über die SNMP-Traps möglich sei. Der Ansatz erschien mir ungewöhnlich doch gerade deswegen wollte ich der Sache auf den Grund gehen. So hielt ich zunächst einmal Rücksprache mit meinem Kollegen Christian Rusa. Des längeren Telefonates kurze Zusammenfassung lautet in etwa so: SNMP-Traps waren noch nie für die laufende Überwachung oder gar Aufzeichnungen zur Trendanalyse gedacht. Auf Grund ihrer Natur,  aktive Meldungen des zu überwachenden Systems zu sein, bekommen wir bei Systemausfall keine Traps mehr. Es muss also das Monitoringsystem erst einmal auf Grund des Ausbleibens von Meldungen die richtigen Schlüsse ziehen. Die große Frage, sollte man sich dennoch dazu entschliessen diesen Weg zu gehen: Kann das zu  überwachende System überhaupt regelmäßig Traps senden?

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.

Kommentar schreiben » | NetApp Monitoring, SNMP | Permalink
Verfasst von lanti

Disk-Utilization auf Aggregatebene

26. August 2010

Der Version 2-Check PerfDisk macht verglichen mit seinem Vorgänger check_netapp_utilization nichts Neues: er misst in regelmässigen Abständen die utilization je vorhandener Disk.

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

Kommentar schreiben » | disk utilization, NetApp Monitoring, Performance | Permalink
Verfasst von lanti

Latenz („per volume latency“) mit Nagios überwachen

16. Juni 2010

NetApp empfiehlt[1] die Überwachung der „per-volume-latency“ (Latenz je Volume) als primären Indikator für zu erwartende Performance-Engpässe. Da dieser Indikator über SNMP nicht verfügbar war, gibt es meines Wissens nach kein Nagios-Plugin, das sich dafür geeignet hätte.

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

Kommentar schreiben » | latency, NetApp Monitoring, Performance | Mit Tag(s) versehen: , , , , | Permalink
Verfasst von lanti

SSL für die Nagios-NetApp-Kommunikation

12. April 2010

Die NetApp API (ZAPI) kommuniziert mittels HTTP mit den sie aufrufenden Programmen. Selbstverständlich ist das auch über Secure Socket Layer (ssl), also HTTPS möglich und eigentlich auch einfacher, da dann die ab Werk eingestellten Optionen auf einem NetApp-Filer nicht verändert werden müssen. Hinzu kommt, dass diese Einstellung natürlich die sicherere ist. Es lag also nahe, HTTPS als Kommunikationsprotokoll in die Nagios Plugins für NetApp zu integrieren. Und das wurde heute auch erfolgreich für die Plugins der Version 2.x implementiert.

Vorsichtshalber sehe ich noch nach, ob auch wirklich verschlüsselt wird. Folgend die durchaus beruhigenden Screenshots aus meinem Wireshark.

XML-Ausschnitt: size-total und Anzahl der Bytes im Klartext

Unverschlüsselte HTTP-Kommunikation: Ein Sniffer sieht alle Daten im Klartext.

wireshark: http-credentials im Klartext

HTTP ohne Verschlüsselung: Benutzernahme und Passwort werden im Klartext übertragen.

Networktrace HTTPS

Mit Schalter --ssl=yes werden die XML-Daten verschlüsselt übertragen.

Implementiert wurde für check_netapp.pl ein zusätzlicher Schalter

 --ssl=yes|no

Default ist yes . Lässt man diesen Schalter weg oder stellt ihn auf yes, muss man am Filer eigentlich gar nichts mehr konfigurieren da die Option httpd.admin.ssl.enable ab Werk auf on steht. Der Filer kann somit out-of-the-box mittels dieser Plugins überwacht werden. Das geht dann auch problemlos über WAN-Links, die vielleicht unsicher sind oder SNMP gar nicht erst erlauben.

Kommentar schreiben » | Nagios Plugins für NetApp, NetApp Monitoring | Permalink
Verfasst von lanti

« Vorherige Beiträge
Follow

Get every new post delivered to your Inbox.