HPE Alletra / Nimble Storage software update „Precheck Fail“

Manchmal schlagen Firmware-Updates auf Alletra 5000 Storages (früher Nimble AF und HF) fehl. Die Fehlermeldung dazu lautet im GUI und an der Shell wenig hilfreich:

One of the HPE Nimble Storage services has become unreachable. If this occurred during a failover or planned outage, wait a minute and then refresh the GUI. This may also occur during security certificate update for group or array name changes or management ip and discovery ip changes. Wait a minute and then refresh the GUI. In some cases, you may also need to clear browser cache. If the service does not become reachable in a few minutes, contact HPE Nimble Storage Support.

Lösung

Es sieht so aus, als ob die Boot-Devices auf den aktiven (!) Controllern manchmal eine Zeitüberschreitung veraursachen. Das verursachte dann den Dienstfehler „Storage services has become unreachable“.

Dies kann man in den allermeisten Fällen durch einen Neustart des Controllers beheben – also durch einen einfachen Failover. Normalerweise kann man das im Web-GUI mit dem Button „Make active“ tun, was in diesem Fall aber ebenfalls nicht funktioniert.

Es hilft aber den Failover auf den anderen Controller an der SSH-Shell zu erzwingen:

failover --array <ARRAYNAME> --force

Und nach wenigen Minuten ist der Failover fertig, der Controller frisch neu gebootet und das Update läuft ohne Probleme durch.

HP 5400zl/zl2 Series Switch Port mirror (Port monitor) einrichten

Das gute alt port-mirror gibt es seit Release K12 (soweit ich weiss) der Switch-Firmware nicht mehr. HP hat auf das „Intelligent Mirroring and Monitoring“ umgestellt, das deutlich flexibler und mächter ist. Aber der alte Admin muss sich nun an das neue Konzept gewöhnen.

Immerhin kann man jetzt einzelne VLANs, MAC-Adressen, MAC’s in VLANs und dergleichen vernünftig monitoren, ohne ein Queue-Problem zu haben oder Software-Filter bemühen zu müssen. Außerdem gibt es bis zu vier Monitoring-Gruppen mit unterschiedlicher Konfiguration.

HPE 5400zl/zl2 Port Mirror konfigurieren

# Ziel-Port und Monitoring Gruppe "1" (mit Namen) festlegen
HP-E5406zl(config)# mirror 1 name <ZIELNAME> port <ZIELPORTNUMMER>

# Quell-Port und Inhalte festlegen
HP-E5406zl(config)# interface <QUELLPORTNUMMER> monitor all both mirror <ZIELNAME>

HPE 5400zl/zl2 Port Mirror entfernen

HP-E5406zl(config)# no mirror 1

HP-E5406zl(config)# no interface <QUELLPORTNUMMER> monitor

Dell/EMC DS-6505 (5500 und 300B) Series FC-Switch Password reset und Factory Reset

Manchmal gehen Kennwörter oder die Mensche die diese wussten verloren. Dann sollte ein gute Admin trotzdem den Zugriff auf die Hardware sicherstellen – manchmal auch mit „Gewalt“.

Leider hat DELL zwischenzeitlich beschlossen, eine ganze Menge KB-Artikel mit einer Paywall zu blockieren („Dieser Artikel ist berechtigungsbasiert. Suchen Sie einen anderen Artikel.“), so auch die „offiziellen“ Anleitungen 🤬

Wir hatten hier gleich mehrere (Dell) EMC DS-6505B zurückzusetzen. Daher hier die kompakte Anleitung für schnelle Admins. Ganz ohne Paywall.

Lösung

1. Boot-Console verbinden (Switch ist ausgeschaltet)

PC mit dem seriellen Anschluss (oder Adapter, FTDI FT232RL empfohlen) via Console-Kabel mit dem Serial-Port des Switches verbinden (das ist der port mit der „IOIO“ Beschriftung).

Mit PuTTY oder anderen Serial-Terminal Client den Port öffnen (9600baud, 8 data bits, 1 Stop bit, Parity none, Flow Control Xon/Xoff).

2. Switch einschalten, Recovery Command-Shell booten

Sofort nach dem Einschalten kann man den Boot-Prozess live bewundern. Ein paar Sekunden nach dem Start bei der Meldung „Hit ESC to stop autoboot:“ ESC drücken und mit „3“ die command shell starten.

3. Singele-User mode booten

Wenn es hier ein PROM-Kennwort gibt, einfach das Gerät noch einmal booten und selbiges Kennwort mit dem 2. Punkte „Recover password“ zurückesetzen.

An der boot-Shell kann man dem Bootloader jetzt den Parameter für den Single-User-Mode mitgeben und diesen auch gleich starten. Mit printenv sollte man vorher die Boot-Parameter anschauen (und am besten screenshotten). Möglicherweise werden die später noch gebraucht.

=> printenv

=> setenv OSLoadOptions "single"

=> boot

4. Dateisystem(e) mounten

Natürlich mountet der Singleuser-Mode alle Laufwerke ReadOnly (RO), daher muss das vor den Änderungen natürlich umgestellt werden. Wir brauchen außerdem das Boot-Medium mit dem Flashfilesystem gemountet. Das bekommen wir aus der printenv Ausgabe der Variable OSRootPartition (der erste Wert, meistens /dev/hda2).

sh-2.04# mount -o remount,rw,noatime /

sh-2.04# mount /dev/hda2 /mnt

5. Kennwörter zurücksetzen

Jetzt kann man an der frisch gebooteten (Linux-) Shell die Kennwörter zurücksetzen und den Switch neu starten.

sh-2.04# /sbin/passwddefault

sh-2.04# reboot -f

6. Neu starten und einloggen

Nach dem jetzt ungestörten Neustart kann sich der Benutzer admin wieder mit dem EMC/Brocade Default Passwort password einloggen.

Bonus: Factory Reset (Zurücksetzen auf Werkseinstellungen)

Wenn man schon mal dabei ist und der Switch „leer“ werden soll, kann man das Gerät jetzt noch direkt auf die Werkseinstellung zurücksetzen.

SWITCHNAME:admin> fosconfig --disable vf

SWITCHNAME:admin> switchcfgpersistentdisable

SWITCHNAME:admin> cfgDisable
[mit y bestätigen]

SWITCHNAME:admin> cfgClear
[mit y bestätigen]

SWITCHNAME:admin> cfgSave
[mit y bestätigen]

SWITCHNAME:admin> configDefault
[mit y bestätigen]

SWITCHNAME:admin> userconfig --change root -e yes

SWITCHNAME:admin> rootaccess --set consoleonly

SWITCHNAME:admin> cfgSave
[mit y bestätigen]

SWITCHNAME:admin> fastBoot

Das Default-Kennwort für den Standartmäßig abgeschalteten Benutzer root lautet übrigens fibranne.

HPE Nimble Storage (jetzt „Alletra“) verschickt Alarme die es nicht mehr gibt

Das HPE mit dem Kauf von Nimble einen guten Fang gemacht hat, hat sich ja mittlerweile herumgesprochen. Ein Nimble-Effekt wurde trotz fleißiger Updates aber bis heute nicht wirklich behoben: Die „toten“ Alarme, oder auch „Dead Alerts“.

Die Nimble (Alletra) verschickt in vielen Fällen auch noch weiterhin Alarme, wenn die Ursache gar nicht mehr existiert. Das gilt beispielsweise für neue vCenter-Server, abgeschaltete Array-Replikationsziele oder auch nur entfernte Volumes die „vorher“ noch offene Snapshots hatten.

Lösung: Nimble Alarme ansehen und löschen

Per SSH auf das betroffene Array verbinden und die vorhandenen Alarme ansehen:

alarm --list

Sobald man den „schuldigen“ gefunden hat, kann man den betroffenen Auslöser einfach löschen:

alarm --delete <ID>

Das betrifft natürlich auch nur berits ausgelöste Alarme, neue Ereignisse erzeugen auch wieder einen neuen Alarm.