[Support]  [Forum]  [Newsletter]       [Site-Map]  [Suche]  [Kontakt]  [Impressum]

Stor IT Back - Ihr Speicherspezialist

[Angebote]   [Produkte]   [Schulungen]   [Firmenprofil]   [Partner]   [Kunden]   [Information]   [Download]   [News]

LOGO Stor IT Back

Überwachung von Storage- und Backup-Lösungen V1.2 (c) Stor IT Back 2016


Überwachung von Storage Systemen, Tape Libraries und Virtualisierungen

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 müssen. Aber wer überwacht die gesamte Umgebung? Muss man das überhaupt kontrollieren oder ist alles so sicher, dass es ohne menschliche Kontrolle läuft?

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 Überwachungsstelle her. Ein Server, der alle anderen Systeme überwachen kann und ständig den Status meldet. Wenn etwas schief läuft 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 die Überwachung 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 Überwachungsserver aus, so kann er auch nicht mehr alarmieren. Also sieht alles so aus, als ob keine Probleme da sind, obwohl sich die Server so "langsame 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.

Beispiel einer Überwachungssoftware

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. 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 Nagios?
1. Nagios ist kostenfrei und läuft unter Linux, daher fallen keine zusätzlichen Lizenzen an.
2. Nagios ist weit verbreitet, bei Problemen findet man im Internet schnell und kostenfrei Hilfe.
3. Für Nagios gibt es unzählige Plugins um alle möglichen und unmöglichen Geräte zu überwachen.
4. Nagios lässt sich sehr einfach durch eigene Skripte oder Programme erweitern.

Was benötigt man für den Betrieb von Nagios?
1. Einen Server (egal ob virtuell oder physikalisch) mit Linux als Betriebssystem.
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.

Installation von Nagios

Für die Installation von Nagios gibt es unzählige 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.

Konfiguration von Nagios

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.

Nagios MAP Übersicht

Nagios und EMC VNX / Unity Systeme (VNX, VNXe und Unity-Serie)

EMC VNX und 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-Systeme oder auch zum Download auf der Supportseite von 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.

Voraussetzungen

1. Perl installiert auf dem Nagios Server
2. NaviCLI (Command Line Interface für VNX / Clariion): Download unter http://support.emc.com oder auf der Server CD des Clariion Systems
3. Nagios Plugin: http://exchange.nagios.org/directory/Addons/Configuration/Configuration-Wizards/EMC-CLARiiON-Monitoring-Wizard/details

Aufruf / Beispiel

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.

Nagios und Brocade FC Switche

Brocade FC 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.

Voraussetzungen

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

Aufruf / Beispiel

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.

 

Nagios und Infortrend RAID-Systeme

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: http://oss.isg.inf.ethz.ch/nagiosplug/. Einige Anpassungen haben wir direkt vorgenommen (alles natürlich komplett ohne Gewähr von unserer Seite). Die angepassten Skripte finden Sie hier: Infortrend Nagios Plugin.

Voraussetzungen

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

Aufruf / Beispiel

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

Nagios und VMware ESX und ESXi

Auch VMware ESX und ESXi Server lassen sich über Nagios überwachen, aber natürlich auch andere Virtualisierungen. Fertige Plugins basieren auf verschiedenen Möglichkeiten der Überwachung eines ESX-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.

Voraussetzungen

1. Python installiert und konfiguriert auf dem Nagios Server
2. "Python WBEM Client and Provider Interface": pywbem-0.7.0 (oder neuer, bzw. dem Plugin angepasst)
3. Download des Plugin: http://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/VMWare/Check-hardware-running-VMware-ESXi/details

Aufruf / Beispiel

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.


Angebote der Stor IT Back

Angebot EMC VNXe1600
EMC VNXe1600 RAID - SMB Preis
Dual Controller, Block-Only Storage

8 / 16 Gbit/s FC oder 10 Gbit/s iSCSI
SSD, SAS, NL-SAS Platten / BBU / EMC Support
ab 8.573,00 Euro
zzgl. MwSt.
Angebot Netapp E2700
NetApp E2700 Fibre Channel / iSCSI / SAS RAID
16 Gbit/s FC / 10 Gbit/S iSCSI / 12 Gbit/s SAS

mit 600 bis 900 GB SAS- und/oder 2 bis 4 TB NL-SAS-Festplatten
Preis
auf Anfrage
Angebot Infortrend ESDS 1000
Infortrend EonStor ESDS 1000 Serie
SAS/iSCSI/FC - to - SAS RAID-System

mit 12/16/24 x SAS Einschüben (Hot Swap)
Infortrend ESDS 1012R/G, 1016R/G, 1024RB/GB/G
ab 2.166,00 Euro
zzgl. MwSt.
 
 
Zurück zur Übersicht
Übersicht
nach oben
nach oben
Übersicht der Angebote
Angebote
Kontakt zur Stor IT Back
Kontakt
Suche auf der Webseite
Suche