Software Updates auf Netzwerk-Infrastruktur ist ein heikles Thema. Einerseits muss man aus Gründen der Sicherheit die Software stets aktuell halten, andererseits ist ein Update mit einem Reboot der Hardware verbunden und damit mit Unterbrechung der Anbindung.
Einen Branch-Switch, der nur PC, Telefonie und Drucker bedient, kann man außerhalb der Arbeitszeiten durchaus neu starten. Sogenannte Endpoint Geräte verkraften einen Kontaktverlust in der Regel problemlos. Schwieriger wird es bei Core-Komponenten oder Top-of-Rack (TOR) Switches. Diese versorgen Server, oder andere Infrastruktur Komponenten, welche sehr empfndlich auf Unterbrechungen reagieren. Aus diesem Grund werden Core- und TOR-Switches auch redundant ausgelegt, so dass der Ausfall einer Einheit nicht den 24/7/365 Betrieb der Serversysteme gefährdet.
In diesem Artikel behandle ich das Thema, wie man einen HPE IRF-Cluster der 5700er Serie mittels In Service Software Upgrades (ISSU) ohne Downtime aktualisieren kann.
Der große Vorteil der ISSU Funktion besteht darin, daß redundante Member eines IRF-Clusters nacheinander aktualisiert werden können, ohne die Funktion des Clusters zu unterbrechen.
Es gibt zwei ISSU Methoden:
- Compatible upgrade: Beide Software Versionen können coexistieren. Die Funktion des Clusters bleibt beim Upgrade Prozess erhalten.
- Incompatible upgrade: Alte und neue Software-Versionen sind nicht kompatibel. Das Verfahren erfordert einen Kaltstart und die Funktion des gesamten IRF-Clusters ist unterbrochen.
Ich werde hier das Szenario eines kompatiblen Upgrades schildern.
Voraussetzungen für ISSU Upgrades
Auch wenn ein Live-Update einen gewissen Charme hat, so bedeutet dies nicht, dass der Update-Prozess komplett ohne Unterbrechung abläuft. Einzelne Einheiten des IRF-Clusters müssen im Laufe der Prozedur neu starten und damit verlieren alle daran angeschlossenen LAN-Adapter ihren Link. Es ist daher unbedingt notwendig, die angeschlossenen Server-Systeme redundant mit mehreren IRF-Einheiten zu verbinden. Entweder durch einen Trunk, oder alternative Verbindungen.
Beim Upgrade werden Image-Dateien entpackt und kopiert. Dazu wird freier Speicherplatz auf dem Flash-Medium benötigt.
Vorbereitung
Das aktuelle Firmware-Image für den jeweiligen Switch gibt es zum Download bei HPE. Zur Bereitstellung auf dem IRF-Cluster benötigt man einen FTP/TFTP-Server, oder einen kleinen TFTP Dienst, den man bei Bedarf auf dem PC ausführen kann (zum Beispiel Free TFTP-Server von Solarwinds).
Zunächst müssen wir den Status des IRF-Clusters abfragen und in Erfahrung bringen, welche Unit (Slot) aktuell die Master-Rolle hat. Wir brauchen hierfür einen Shell Zugang über SSH oder serielle Verbindung.
display irf
Wir sind per SSH mit dem Master (Unit2) verbunden. Das muss nicht zwingend so sein. Master könnte auch eine andere Einheit sein, oder ein serielles Terminal ist mit einem Slave verbunden.
Ablauf Kompakt
- Upload Image auf Master
- Test der Kompatibilität für ISSU
- Image auf Slave übertragen mit anschließendem Reboot des Slave
- Switchover der Masterrolle
- Commit auf weiteren Einheiten mit Reboot
Erst aufräumen!
Wir müssen sicher stellen, daß im Flash des Masters ausreichend Platz für das Image und den Upgrade Prozess ist. Als Richtwert wird das doppelte Volumen der Imagegröße als freier Speicher empfohlen. Der folgende Befehl zeigt den lokalen Flash (Master), der zweite den Flash weiterer Units (Slave).
dir
Wir können sehen, dass sich im Speicher zwei Versionen der Boot- und System-Images befinden, von denen eines sicherlich nicht mehr gebraucht wird. Wir bringen dies etwas weiter unten in Erfahrung.
Zum Auslesen den Flash Speichers anderer Units muss der folgende Befehl mit der jeweiligen Slot-Nummer eingegeben werden. Slot1 ist in diesem Fall Slave, mit dem wir indirekt verbunden sind.
dir slot1#flash:/
Falls nicht genügen Platz zur Verfügung stehen sollte, können ältere BIN Files gelöscht werden.
Achtung! Nicht die aktuell verwendeten Boot- und System-Images löschen!
Das aktuelle Boot-Image erfragt man mit:
display boot-loader
Aktuell wird im Cluster das Image R2418p06 verwendet. Das bedeutet, dass R2311p05 (DIr oben) gelöscht werden kann.
Löscht man Files im Flash mit delete, so wandern diese zunächt in den Papierkorb und belegen dort weiterhin Speicherplatz. Um das Boot- und System-Image R2311P05 dauerhaft zu löschen, verwendet man folgende Befehle.
delete /unreserved 5700-cmw710-boot-r2311p05.bin delete /unreserved 5700-cmw710-system-r2311p05.bin
Slot 1 bereinigt man analog mit dem Befehl:
delete /unreserved slot1#flash:/5700-cmw710-boot-r2311p05.bin delete /unreserved slot1#flash:/5700-cmw710-system-r2311p05.bin
Auch das IPE File der aktuellen Version R2418P06 kann entfernt werden. Daraus wurden beim letzten Update die BIN Images entpackt.
delete /unreserved 5700-CMW710-R2418P06.ipe delete /unreserved slot1#flash:/5700-CMW710-R2418P06.ipe
Nachdem wir Platz geschaffen haben kann es mit dem Upload des neuen Images weitergehen.
Upload
Im ersten Schritt wird das Software Image auf den Master geladen. Dazu habe ich einen kleinen TFTP Server auf meinem Client PC gestartet und in dessen Root-Verzeichnis das gewünschte IPE Image gelegt. Der Transfer erfolgt mit dem unten genannten Befehl, wobei <IP-TFTPSRV> die IP Adresse des TFTP Servers ist (= mein Client-PC).
tftp <IP-TFTPSRV> get 5700-CMW710-R2422P02.ipe
Das Boot-Image wird in den lokalen Flash des IRF-Masters geladen.
Test der Kompatibilität
Bevor man ein online ISSU durchführen kann, muss die Kompatibilität des neuen Images mit der aktuell aktiven Software erfragt werden.
display version comp-matrix file ipe flash:/5700-CMW710-R2422P02.ipe
Die aktuell verwendete Version R2418 ist auf der Liste der kompatiblen Versionen. Folglich kann ein online Upgrade durchgeführt werden. Es wird nun zunächst aus dem IPE File das Boot- und System-Image auf den Slave entpackt (Unit1) und dieser neu gestartet. Danach wechselt die Masterrolle von Unit2 auf Unit1.
Rollback Timer
Der ISSU Prozess hat einen Sicherheits Mechanismus, der nach einer definierten Zeitspanne wieder auf die ursprünglichen Software Images zurückspringt. Dieser Rollback-Timer ist default auf 45 Minuten eingestellt und startet mit dem issu load file Kommando (unten). Nach erfolgreichem Upgrade der ersten Einheit muss das Upgrade quittiert werden, andernfalls erfolgt nach 45 Minuten ein Rollback.
display issu rollback-timer
Der Timer ist noch nicht gestartet und auf den Standardwert 45 Minuten eingestellt.
Upgrade
Der Upgrade Vorgang beginnt mit Unit-1 (Slave).
issu load file ipe flash:/5700-CMW710-R2422P02.ipe slot 1
Das IPE wird entpackt, auf Slot1 kopiert (nicht dargestellt) und geprüft.
Auf Unit-1 läuft derzeit noch Version 2418P06, die nach dem Reboot (New Version) durch 2422P02 ersetzt wird.
Nach Rückfrage wird Slot 1 mit dem neuen Image gestartet. Dies führt zu Verbindungsverlust aller Ports auf Unit1. Daher müssen alle angeschlossen Systeme über Pfadredundanz verfügen.
Sobald Unit1 wieder online ist (IRF-Link aktiv und Ports haben Link), kann der Switchover der Master-Rolle erfolgen.
Switchover
Der bisherige Slave übernimmt nun die Master Rolle.
issu run switchover
Die SSH Shell zum ursprünglichen Master wird unterbrochen und muss neu verbunden werden.
display irf
Man kann erkennen, dass nun Unit1 die Masterrolle hat.
display device
Wir sehen, daß Slot1 nun bereits die aktuelle Firmware 2422P02 hat. Wenn die Funktionalität von Slot 1 gewährleistet ist kann der Rollback-Timer deaktiviert werden.
issu accept
Upgrade Slot 2
Nun muss auch Slot 2 auf den aktuellen Stand gebracht werden.
issu commit slot 2
Slot 2 führt einen Reboot aus, der vollständig abgewartet werden muss. Sobald Slot 2 wieder online ist, kann man die aktuellen Einstellungen überprüfen.
Die Masterrolle verbleibt auf Unit1.
Zum Abschluss kann die Software jeder Einheit kontrolliert werden.
display device
Es ist klar zu erkennen, dass nun beide Einheiten auf aktueller Firmware laufen.