Stor IT Back - Ihr Speicherspezialist
Überwachung und Monitoring von Storage- und Backup-Lösungen V1.5 (c) Stor IT Back 2023
Eine Storage-Lösung ist implementiert, es laufen einige VMware ESX oder
Hyper-V Server mit einer großen Anzahl von virtuellen Maschinen, die natürlich
auch gesichert werden. Aber wer überwacht die gesamte Umgebung?
Muss man das überhaupt monitoren oder ist alles so sicher, dass es
ohne menschliche Kontrolle läuft? Schließlich nutzt man ja Cluster Lösungen ...
Auch hochredundante Storage-Systeme müssen überwacht werden.
Wer merkt es sonst, dass eine Festplatte ausgefallen ist? Das Storage-System
merkt es und verschickt evtl. sogar eine Mail an den Administrator. Wenn dieser
aber im Urlaub ist und die Vertretung diese Mail nicht überwacht? Alles
kein Problem: Die Hot Spare springt ja ein... Aber ist sie wirklich eingesprungen?
Was passiert beim nächsten Ausfall? Es ist ja keine Hot Spare mehr da ...
Alles Fragen über Fragen.
Was auch häufig vergessen wird, das sind die Tape-Libraries. In vielen großen Unternehmen sind sie im Einsatz,
Bänder werden erstellt, sie werden kopiert und ausgelagert, aber die Hardware wird selten überwacht. Aber
auch dort kann ein Tape-Laufwerk ausfallen, oder ein redundantes Netzteil.
Also muss eine zentrale Monitoringstelle her. Ein Server, der alle anderen
Systeme überwachen kann und ständig den Status meldet. Wenn etwas
schief läuft, so sollte das System eine Mail verschicken können, oder
eine SMS oder einen Anruf ausführen. Diese Alarmierungspfade sollten natürlich
nicht alle von den gleichen Komponenten abhängen sein bzw. es sollten so
wenig Abhängigkeiten wie möglich vorhanden sein. Ein einfaches Beispiel:
Der E-Mail Server fällt aus und wird auch überwacht. Die Überwachung
bemerkt den Fehler und verschickt eine E-Mail an den Administrator. Das klappt
jetzt aber nicht wegen dem fehlenden Mail-Server. Für diesen Fall muss
ein zweiter Weg vorhanden sein. Entweder eine direkte Alarmierung oder zusätzlich
eine SMS über einen anderen Weg.
Und natürlich muss das Monitoring auch überwacht werden. Wenn
eine Überwachung "problemlos" läuft, dann verlässt
man sich sehr schnell zu 100% darauf. Fällt jetzt aber dieser zentrale
Monitoringserver aus, so kann er auch nicht mehr alarmieren. Also sieht
alles so aus, als ob keine Probleme da sind, obwohl sich die Server so "langsam
alle auflösen". Einfach Lösung für diesen Fall: Ein zweiter
Überwachungsserver, der den ersten überwacht. Hört sich seltsam
an, ist aber sinnvoll und auch einfach zu realisieren. Und der sollte natürlich nicht auf der Virtualisierungs-Lösung oder dem Storage laufen ...
Für diesen Zweck gibt es viele Programme, komplette Umgebungen, aber auch
einfache kleine Überwachungssysteme. Basierend auf Windows Betriebssystemen
oder Linux, oder ... Prinzipiell sollte die Überwachung auf einem zuverlässigen
System laufen und auf einem Betriebssystem, mit dem man sich gut auskennt. Wenn
zum Beispiel die Überwachung auf einer virtuellen Umgebung läuft und
auch diese soll überwacht werden, dann wird der Ausfall des physikalischen
Servers sicherlich nicht mehr bemerkt werden, außer die Überwachung
wird auch wieder überwacht (siehe oben). Eine häufig angewendete Lösung ist
die zentrale Überwachung als virtuelle Maschine auszuführen und einen
kleinen Server (auf einer Hardware, die zum Beispiel bei der Virtualisierung
überflüssig geworden ist) als Überwachung für die "virtuelle
Überwachung" aufzubauen. Mehr kann man dann schon nicht mehr machen,
für die meisten Unternehmen ist dies sicherlich ausreichend.
Wir stellen hier als Beispiel die Nagios Software vor.
Warum gerade Nagios?
1. Nagios ist kostenfrei (die Core Version) und läuft unter Linux, daher fallen keine zusätzlichen
Lizenzkosten an.
2. Es gibt aber auch kostenpflichtige Versionen (Nagios XI) mit Support vom Hersteller Nagios Enterprises LLC, für alle größeren Umgebungen.
3. Nagios ist weit verbreitet, bei Problemen findet man im Internet schnell
und kostenfrei Hilfe.
4. Für Nagios gibt es unzählige Plugins (sehr viele kostenfreie) um alle möglichen und
unmöglichen Geräte zu überwachen.
5. Nagios lässt sich sehr einfach durch eigene Skripte oder Programme erweitern.
6. Nagios läuft sogar auf einem Raspberry Pi, also auch für kleine Umgebungen gut geeignet oder für die Überwachung des eigentlichen Monitorings.
Was benötigt man für den Betrieb von Nagios?
1. Einen Server (egal ob virtuell oder physikalisch) mit Linux als Betriebssystem (sogar ein Raspberry Pi reicht).
2. Know How in der Bedienung eines Systems über die Command Line.
3. Know How im Betrieb eines Linux Systems.
4. Etwas Zeit und Mühe zur Einarbeitung.
Für die Installation von Nagios gibt es zahlreiche Anleitungen im Internet. Ein guter Startpunkt für Nagios ist die offizielle Seite www.nagios.org. Dort gibt es die Software zum Download, Anleitungen und Foren. Alles was man braucht, um die Software zum Laufen zu bekommen. Unsere Anleitungen basieren immer auf einem lauffähigen Nagios-Server mit allen für Nagios benötigten Erweiterungen. Wird spezielle Software für ein Plugin benötigt, so weisen wir darauf hin.
Zur Grundkonfiguration gibt es auch viele Seiten im Internet. Eine lauffähige Konfiguration sollte man schon nach der Installation haben. Es sollte mindestens der Nagios Server selbst überwacht sein. Die Webseite zur Anzeige sollte fehlerfrei laufen und E-Mail (oder SMS) sollten im Fehlerfalle den Empfänger erreichen.
Auch VMware ESXi Server lassen sich über Nagios überwachen, aber natürlich auch andere Virtualisierungen. Fertige Plugins basieren auf verschiedenen Möglichkeiten der Überwachung eines ESXi-Server. Entweder die Auswertung der Webseite des ESX oder über das Command-Line-Tools von VMware. Damit lassen sich alle Informationen aus einem ESX oder ESXi Server herauslesen. Bei passender Hardwareunterstützung auch der komplette Hardware-Status der Maschine, sowie der Zustand von Festplatten und RAID-Verbünden.
Unser Beispiel basiert auf einem Python Skript, welches die Webseite des ESX über https abfragt und auswertet. Da dieses Skript sehr kurz und übersichtlich ist, lassen sich dort auch spezielle Funktionen abfragen, wie zum Beispiel der Status des RAID.
1. Python installiert und konfiguriert auf dem Nagios Server
2. "Python WBEM Client and Provider Interface": pywbem-1.4.1 (oder
neuer, bzw. dem Plugin angepasst, https://pywbem.github.io/)
3. Download des Plugin: http://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/VMWare/Check-hardware-running-VMware-ESXi/details
Aufruf des Plugin: ./check_esx_wbem.py hostname user password [verbose]
Sehr wichtig ist hierbei der Parameter "verbose". Er bewirkt, dass dieses Skript alle Informationen, egal ob gut oder schlecht ausgibt. Damit lassen sich Fehler schnell finden und es gibt einen Überblick, wie dieses Skript an die eigenen Bedürfnisse angepasst werden kann. Hier mal eine gekürzte Ausgabe des Skriptes im verbose-Modus:
20110326 17:26:28 Element Name = System Board 1 1.8V PG 0 20110326 17:26:28 Element Op Status = 2 20110326 17:26:28 Element Name = System Board 1 1.25V PG 0 20110326 17:26:28 Element Op Status = 2 20110326 17:26:28 Element Name = System Board 1 PROC VTT 0 20110326 17:26:28 Element Op Status = 2 20110326 17:26:28 Element Name = Processor 1 VCORE 0
Durch kleine Änderungen im Skript können aber auch Ergebnisse angezeigt werden. Sollen zum Beispiel Festplatten, RAID-Controller und RAID-Sets überwacht und aufgelistet werden, so kann dies leicht erreicht werden. Die Ausgabe des Skriptes ist dann:
Element Name = Drive 0 on controller 0 Fw: SN06 - ONLINE Element Name = Drive 1 on controller 0 Fw: SN06 - ONLINE Element Name = Drive 2 on controller 0 Fw: SN06 - ONLINE Element Name = Drive 3 on controller 0 Fw: SN06 - ONLINE Element Name = Controller 0 (SAS6IR) Element Name = RAID 1 Logical Volume 2 on controller 0, Drives(2,3) - OPTIMAL Element Name = RAID 1 Logical Volume 0 on controller 0, Drives(0,1) - OPTIMAL
Also eine einfache und sichere Überwachung auch von kostenlosen ESXi Varianten, auch wenn eine größere Anzahl davon betrieben wird.
EMC VNX und Dell EMC Unity Systeme lassen sich mit Nagios einfach und sicher überwachen.
Hierzu wird die für das zu überwachende System passende NaviCLI bzw.
NaviSecCLI auf dem Nagios Server benötigt. Diese Software liegt einmal
auf den Installations-CDs der Clariion- bzw. Unity-Systeme oder auch zum Download auf der Supportseite von Dell EMC.
Ein kleiner Hinweis zur NaviCLI Software: Mit der Software können alle
Aktionen durchgeführt werden, die auch über Navisphere bzw. Unisphere
durchgeführt werden können. Es können also Storage Groups manipuliert
und RAID Gruppen oder Pools zerstört werden. Daher ist es wichtig den genutzten
User möglichst genau an die eigenen Bedürfnisse anzupassen. Wichtig
hierbei ist es, das dieser User keine Änderungen am System durchführen
darf. Die Zugriffsberechtigung liegt ja mehr oder minder ungeschützt auf dem Überwachungsserver.
1. Perl installiert auf dem Nagios Server
2. NaviCLI (Command Line Interface für VNX / Clariion): Download unter
https://support.emc.com
oder auf der Server CD des Unity / VNX / Clariion Systems
3. Nagios Plugin Clariion: http://exchange.nagios.org/directory/Addons/Configuration/Configuration-Wizards/EMC-CLARiiON-Monitoring-Wizard/details
4. Nagios Plugin Unity: https://exchange.nagios.org/directory/Plugins/Hardware/Storage-Systems/SAN-and-NAS/EMC-Unity/details
Der Aufruf erfolgt über das Skript "check_emc_Clariion.pl". Dies wird dann entsprechend in die Konfiguration für das System eingebunden. Der Test kann jedoch auch durch den direkten Aufruf durchgeführt werden. Als erstes erfolgen die Ergebnisse, wenn das System ohne Fehler läuft:
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t sp --sp A SP A Present, Power ok, Power ok, SPS ok, Cabling ok, nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t sp --sp B SP B Present, Power ok, Power ok, SPS ok, Cabling ok,
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t faults The array is operating normally.
Der erste Befehl kontrolliert den ServiceProzessor A auf der VNX / Clariion mit der IP-Adresse 10.0.0.20. Das Skript gibt die Ergebnisse jeweils komplett aus, der Returncode des Skriptes ist 0. Das zweite Skript dann entsprechend für den Service Prozessor B und das dritte Skript kontrolliert den Zustand des kompletten Systems und gibt im Normalfall diese Meldung aus mit einem Returncode 0. Im Fehlerfalle wird das Problem angezeigt und der Returncode ist ungleich 0.
Der Output gibt an, das die SPS (die EMC eigene USV) wohl ausgefallen ist, da auch die Verbindung zur USV fehlt:
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t sp --sp B SP B Present, Power ok, Power failed, SPS failed, Cabling failed,
In diesem Beispiel ist ein Netzteil ausgefallen (oder die Versorgung für dieses Netzteil), die USV ist aber OK:
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t sp --sp A SP A Present, Power ok, Power failed, SPS ok, Cabling ok,
Das ist jetzt die entsprechende Meldung für diese Skript-Parameter. Das Netzteil 1 ist für die beiden ServiceProzessoren ausgefallen:
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t faults Faulted Subsystem: MASTER Enclosure SPE Power A1 : Faulted Enclosure SPE Power B1 : Faulted Bus 0 Enclosure 0 : Faulted Bus 0 Enclosure 0 Power B : Faulted
Aber nicht nur die Hardware kann überwacht werden. In diesem Beispiel wird überprüft, das der Server dell2 Null Pfade zur Clariion nutzt. Ist dies erfüllt, so gibt das Skript einen Returncode von 0 aus. In der Praxis wäre dies ein Test für einen Cold-Standby-Server. Im Normalfall möchte man aber wohl häufiger testen, ob die theoretischen Pfade wirklich vorhanden sind.
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t hbastate --node=dell2. --path=0 dell2. 20:00:00:E0:8B:94:F8:56:21:00:00:E0:8B:94:F8:56 connected to: SP B, port: 0, Logged in: NO; 20:00:00:E0:8B:94:F8:56:21:00:00:E0:8B:94:F8:56 connected to: SP A, port: 0, Logged in: NO; 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 1, Logged in: NO; 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 1, Logged in: NO; 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 1, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 0, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 1, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 0, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 2, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 3, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 2, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 3,
Dieses Skript prüft jetzt, ob der Server dell2 wirklich über 2 Pfade angeschlossen ist. So kann zum Beispiel der Ausfall eines FC-Switches oder eines HBA-Kanals geprüft werden:
nagios:~/check_emc_clariion# ./check_emc_clariion.pl -H 10.0.0.20 -u admin -p test -t hbastate --node=dell2. --path=2 dell2. 20:00:00:E0:8B:94:F8:56:21:00:00:E0:8B:94:F8:56 connected to: SP B, port: 0, Logged in: NO; 20:00:00:E0:8B:94:F8:56:21:00:00:E0:8B:94:F8:56 connected to: SP A, port: 0, Logged in: NO; 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 1, Logged in: NO; 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 1, Logged in: NO; 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 1, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 0, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 1, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 0, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 2, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP B, port: 3, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 2, 20:01:00:E0:8B:B4:F8:56:21:01:00:E0:8B:B4:F8:56 connected to: SP A, port: 3, error in pathcount from client to SAN: suggested 2 detected 0
Hinweis: Dieses Skript wird nicht mehr gepflegt, daher sollte es genau vor dem Einsatz geprüft werden.
Brocade Fibre Channel Switche lassen über SNMP sehr einfach überwachen. Brocade stellt hierfür eine eigene MIB zur Verfügung, die dieses Plugin auch benötigt. Es gibt in diesem Bereich verschiedene Plugins. In diesem Beispiel beschränken wir uns auf die Überwachung der Hardware. Denkbar sind auch Überwachungen von Durchsatzmengen mit Alarmierungen ab einem bestimmten Auslastungsgrad.
1. SNMP für Nagios, zur Fehlersuche auch snmpwalk (oder ähnliche
Tools)
2. SNMP MIB von Brocade für den FC Switch
3. Nagios Plugin für Brocade FC Switche: http://exchange.nagios.org/directory/Plugins/Hardware/Network-Gear/Brocade/Monitor-FC-Brocade-Switch/details
4. Freigabe des Nagios Server für SNMP Abfragen auf dem Brocade Switch
Dieses Plugin ist ein Shell Skript. Es kann also direkt auf der Command Line aufgerufen werden. Wie üblich werden die IP-Adresse mit -H und die Community mit -c angegeben.
nagios:~# ./check_FCBrocade_hardware.sh -H 10.0.0.128 -c public HARDWARE OK : SLOT#0TEMP#1=29C, SLOT#0TEMP#2=27C, SLOT#0TEMP#3=28C, SLOT#0TEMP#4=28C, FAN#1=5273RPM, FAN#2=5443RPM, FAN#3=5443RPM, FAN#4=5443RPM, PowerSupply#1=1, PowerSupply#2=1,|29;27;28;28;5273;5443;5443;5443;1;1;
Hinweis: Die Zahlen in dem "|" sind die Performance-Daten aus der Auswertung, also die Temperaturen und Umdrehungen.
Sollte ein Netzteil ausgefallen sein, so ändert sich die Auswertung auf die folgende Ausgabe:
nagios:~# ./check_FCBrocade_hardware.sh -H 10.0.0.128 -c public HARDWARE CRITICAL : SLOT#0TEMP#1=29C, SLOT#0TEMP#2=27C, SLOT#0TEMP#3=28C, SLOT#0TEMP#4=28C, FAN#1=5273RPM, FAN#2=5443RPM, FAN#3=5443RPM, FAN#4=5532RPM, PowerSupply#1=0, status=faulty|29;27;28;28;5273;5443;5443;5532;0;1;
Damit bekommt Nagios dann auch den Return-Code vom Skript für die Fehlermeldung.
Die Infortrend Raid-Systeme lassen sich über SNMP überwachen. Auch hierfür gibt es bereits fertige Plugins aus der Nagios-Gemeinde. Das Basis-Skript haben wir von: Infortrend Nagios Plugin.
1. SNMP für Nagios, zur Fehlersuche auch snmpwalk (oder ähnliche
Tools)
2. Nagios Plugin: Infortrend Nagios Plugin
3. Test des Infortrend Gerätes mit snmpwalk auf die richtigen SNMP Einstellungen
Es sind insgesamt 3 Skripte, einmal zur Überwachung der Hardware, dann zur Überwachung der Festplatten und als drittes die Überwachung der Logical Drives.
Skript zur Überwachung der Hardware:
nagios:~/Infortrend-1.2# ./check_ift_dev.pl -H 10.1.1.71 -c public WARNING: PSUs: OK SLOT1: Inactive, Empty
In diesem Beispiel ist ein Netzteil ausgeschaltet bzw. nicht eingesteckt.
Skript zur Überwachung der Festplatten:
nagios:~/Infortrend-1.2# ./check_ift_hdd.pl -H 10.1.1.71 -c public CRITICAL: Drive 1: Drive Absend () Drive 3: Drive Absend () Drive 4: Drive Absend () Drive 5: Drive Absend () Drive 6: Drive Absend () Drive 7: Drive Absend () Drive 8: Drive Absend () Drive 9: Drive Absend () Drive 10: Drive Absend () Drive 11: Drive Absend () Drive 12: Drive Absend ()
In diesem Beispiel ist nur eine Festplatte vorhanden, alle anderen werden als "nicht vorhanden" gekennzeichnet.
Skript zur Überwachung der Logical Drives (RAID Sets):
nagios:~# ./check_ift_ld.pl -H 10.1.1.71 -c public OK: LD1: (Good) Online-HDD=1 HotSpare=0 HDDs=1 Failed=0 NON-RAID
In diesem Fall ist ein Logical Drive vorhanden, es hat eine Festplatte, ist
damit von dem Typ "NON-RAID" und hat keine Hot Spare Platte.
Ist kein Logical Drive angelegt (z.B. weil das Gerät gerade neu ist), dann
kommt eine etwas "seltsame" Fehlermeldung:
nagios:~# ./check_ift_ld.pl -H 10.1.1.71 -c public CRITICAL: The requested table is empty or does not exist for 0
