Sie sind hier

HP IRF und In Service Software Upgrade

„Never change a running system!“ heißt es oft, denn Software-Updates gehen üblicherweise einher mit einem Serviceausfall des entsprechenden Netzwerkgeräts. Besonders, wenn die zu aktualisierenden Komponenten im Kern des Netzwerks untergebracht sind, muss abgewogen werden, ob ein Software-Update einen wirklichen Mehrwert gegenüber dem  bevorstehenden Ausfall bringt.

Im August haben wir uns bereits mit dem Thema IRF (Intelligent Resilient Framework) von HP beschäftigt (http://www.ingentive.net/hp/hp-irf-der-praxis).

Diese Virtualisierungstechnologie ermöglicht das Zusammenführen physikalischer Switches in einen logischen Verbund. Somit lassen sich ganze Netzwerkbereiche effizient und bequem redundant auslegen. Doch wie sieht es aus, wenn man einem derartig virtualisierten Verbund ein Software-Update zukommen lassen will? Muss dann dementsprechend der ganze Verbund auf einmal neu gestartet und ein damit verbundener Serviceausfall in Kauf genommen werden?

In Service Software Upgrade

Das „In Service Software Upgrade“ (kurz ISSU) beschreibt eine Technik, die das Aktualisieren eines Netzwerkgeräts ermöglicht ohne einen Ausfall der Netzwerkkonnektivität durch einen Neustart zu verursachen. Somit bleibt das Gerät „online“, und Daten können nach wie vor durch dieses Gerät geleitet werden. Die Verfügbarkeit von ISSU-Funktionalitäten in Netzwerkkomponenten hängt stark von den Vorlieben des Herstellers ab, und somit werden meist nur bestimmte Router oder Switches mit derartigen Features versehen.

Im Allgemeinen werden für ein ISSU-Update Netzwerkgeräte benötigt, die mit redundant ausgelegten Planes (Control, Switching, Routing) versehen sind. Eben diese Redundanz ermöglicht es, dass eine Engine aktualisiert wird, während die andere die Netzwerkfunktionalität sicherstellt.

Dieser Umstand bringt uns zurück zur Virtualisierungstechnologie IRF, denn hier werden Switches zu einem logischen Netzwerkgerät verbunden, womit auch redundante Planes (jeder physikalische Switch stellt eine dar) für ein ISSU-Update verfügbar wären. Somit ermöglicht ISSU das Aktualisieren eines kompletten IRF-Verbunds, ohne dass dieser dafür auf einen Rutsch neugestartet werden muss. In jeder Phase des Updates sind somit Switches innerhalb des Verbundes aktiv, um die Netzwerkkonnektivität sicherzustellen. Ein sog. Active/Standby-Switchover-Mechanismus ist zu diesem Zweck vorhanden.

Für Comware 5 OS gibt es drei verschiedene ISSU-Arten:

  • Compatible: Die vorhandene Systemsoftware ist mit der neuen kompatibel. Somit können beide Versionen in einem Verbund koexistieren.

  • Incompatible: Die vorhandene Systemsoftware ist nicht kompatibel mit der neuen Software. Es kann nur eine Software-Version im Verbund aktiv sein. Bei dieser Vorgehensweise ist eine implementierte MAD-Technologie eine Pflichtvoraussetzung.

  • Unknown: Die beiden Software-Versionen unterscheiden sich zu stark. ISSU ist nicht möglich.

Konfiguration IRF

Wie ein IRF-Verbund im Detail konfiguriert wird, wurde bereits im Beitrag „HP IRF in der Praxis“ (http://www.ingentive.net/hp/hp-irf-der-praxis) ausführlich erläutert. Um ISSU detaillierter erklären zu können, wird nun mit drei Switches im Verbund gearbeitet.

In diesem Verbund befindet sich der Master mit der Member-ID 1 in der Mitte. Die Slaves mit den Member-IDs 2 und 3 sind jeweils über und unter dem Master platziert worden. Eine 10G-SFP-DAC-Verbindung vereinigt alle Geräte zu einem Stack (schwarze Linien), welcher mittels MAD-BFD (rote Linien) gegenüber den Gefahren einer Split-Stack-Situation abgesichert ist. An diesem Stack könnten sich nun redundant angebundene Netzwerkbereiche befinden.

Die Stack-Situation sieht nun wie folgt aus:

[IRF-Stack]display irf
MemberID Role Priority CPU-Mac Description
*+1 Master 10 d07e-2886-ff5c -----
2 Slave 5 d07e-2886-b042 -----
3 Slave 1 001e-c170-b846 -----
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: d07e-2886-ff5b
Auto upgrade : yes
Mac persistent : 6 min
Domain ID : 0

MAD-BFD wurde konfiguriert und funktioniert:

[IRF-Stack]display mad verbose
Current MAD status: Detect
Excluded ports(configurable):
Excluded ports(can not be configured):
Ten-GigabitEthernet1/0/25
Ten-GigabitEthernet1/0/26
Ten-GigabitEthernet2/0/25
Ten-GigabitEthernet2/0/26
Ten-GigabitEthernet3/0/25
Ten-GigabitEthernet3/0/26
MAD ARP disabled.
MAD LACP disabled.
MAD BFD enabled interface:
Vlan-interface100
mad ip address 192.168.100.1 255.255.255.248 member 1
mad ip address 192.168.100.2 255.255.255.248 member 2
mad ip address 192.168.100.3 255.255.255.248 member 3

Alle IRF-Member sind initial mit der identischen Software-Version ausgestattet:

[IRF-Stack]display boot-loader
Slot 1
The current boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
The main boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
The backup boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
Slot 2
The current boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
The main boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
The backup boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
Slot 3
The current boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
The main boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
The backup boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin

ISSU Vorbereitung

Um einen IRF-Verbund mittels ISSU zu aktualisieren, sind die folgenden Schritte notwendig:

  1. Neue Software-Version in die Flash-Speicher der IRF-Member laden
  2. Status der Member überprüfen
  3. Softwarekompatibilitätsmatrix aufrufen
  4. Korrekte ISSU-Methode anwenden

Software

Die neue Software-Version lässt sich über verschiedene Arten in den Flash-Speicher eines IRF-Members laden. Gebräuchlich ist die Variante mittels FTP/TFTP. Sofern am Gerät vorhanden, kann auch ein USB-Anschluss in Verbindung mit einem USB-Stick verwendet werden. In diesem Beispiel entscheiden wir uns für den Upload der Software mittels TFTP. Der IRF-Stack soll nach dem Update mit der Version „5800-5820X_5.20.R1809P01“ ausgestattet sein:

tftp 10.10.14.100 get 5800-5820X_5.20.R1809P01.bin
...
File will be transferred in binary mode
Downloading file from remote TFTP server, please wait.....

Ist das Software-Image im Flash-Speicher des Masters vorhanden, lässt es sich einfach auf die anderen IRF-Member verteilen:

copy 5800-5820X_5.20.R1809P01.bin slot2#flash:/
copy 5800-5820X_5.20.R1809P01.bin slot3#flash:/

Status prüfen

Anschließend wird noch einmal geprüft, ob jeder IRF-Member die neue Version in seinem Flash hat:

dir flash:/
Directory of flash:/
2 -rw- 31633408 Apr 26 2000 17:21:04 a5800_5820x-cmw520-r1809p01.bin
dir slot2#flash:/
Directory of slot2#flash:/
3 -rw- 31633408 Apr 26 2000 17:15:50 a5800_5820x-cmw520-r1809p01.bin
dir slot3#flash:/
Directory of slot3#flash:/
3 -rw- 31633408 Apr 26 2000 17:15:50 a5800_5820x-cmw520-r1809p01.bin

Abschließend wird der Gerätestatus überprüft, um sicherzustellen, dass ein ISSU durchführbar ist. Sollte auch nur ein einziger IRF-Member hinsichtlich „State“ nicht auf „Normal“ stehen, kann ab diesem Punkt mit einem ISSU nicht weiter verfahren werden:

copy 5800-5820X_5.20.R1809P01.bin slot2#flash:/
copy 5800-5820X_5.20.R1809P01.bin slot3#flash:/

Anschließend wird noch einmal geprüft, ob jeder IRF-Member die neue Version in seinem Flash hat:

[IRF-Stack]display device
Slot 1
SubSNo PortNum PCBVer FPGAVer CPLDVer BootRomVer AddrLM Type State
0 28 Ver.B NULL 003 220 IVL MAIN Normal
Slot 2
SubSNo PortNum PCBVer FPGAVer CPLDVer BootRomVer AddrLM Type State
0 28 Ver.B NULL 003 220 IVL MAIN Normal
Slot 3
SubSNo PortNum PCBVer FPGAVer CPLDVer BootRomVer AddrLM Type State
0 28 Ver.B NULL 003 220 IVL MAIN Normal

In unserem Beispiel zeigen alle Slots „Normal“ an, und somit haben wir erstmal ‚grünes Licht‘ für ein ISSU.

Softwarekompatibilität

Wie bereits im Kapitel „In Service Software Upgrade“ erwähnt, kann die neue Software kompatibel zur vorhandenen sein oder eben nicht. Um dies herauszufinden, ruft man die Kompatibilitätsmatrix auf. Der IRF-Stack verrät uns dann automatisch, welcher Fall vorliegt:

[IRF-Stack]display version comp-matrix file a5800_5820x-cmw520-r1809p01.bin
Number of Matrices in Table = 1
Matrix for HP A5800-24G Switch
Running Version:R1808P27
Version Compatibility List:
R1809P01 (Incompatible)

In unserem Fall möchten wir die derzeitige Software „a5800_5820x-cmw520-r1808p27“ auf die nächste Version „a5800_5820x-cmw520-r1809p01“ aktualisieren. Die „Version Compatibility List“ gibt Aufschluss darüber, ob die beiden Versionen kompatibel sind oder nicht. Hier müssen wir nun offensichtlich mit einem Incompatible-ISSU fortfahren:

Incompatible ISSU

Da unsere beiden Software-Versionen inkompatibel sind, wird nun ein „Incompatible ISSU“ durchgeführt. Dieser unterscheidet sich von einem „Compatible ISSU“ dahingehend, dass Geräte mit unterschiedlichen Software-Versionen in einem IRF-Stack nicht koexistieren können. Somit wird der Stack kurzzeitig aufgebrochen, um ihn im Zuge des „Switchover“ wieder aktualisiert zusammenzufügen. Um hierbei ein „Split Stack“ zu verhindern, ist eine funktionsfähige MAD hier obligat.
Man beginnt das ISSU mit dem Slave, der nach dem Master die höchste Priorität aufweist. In unserem Beispiel wäre das der oberste Switch mit der Member-ID 2 und der Priorität 5.

Folgender Befehl leitet ein ISSU ein. Der Zusatz „force“ am Ende des Kommandos ist notwendig, da wir hier im inkompatiblen Modus arbeiten.

[IRF-Stack]issu load file a5800_5820x-cmw520-r1809p01.bin slot 2 force
This command will begin ISSU, and the specified board will reboot and be upgraded. Please save the current running configuration first; otherwise, the configuration may be lost. Continue? [Y/N]:y
%Apr 26 13:32:43:562 2000 IRF-Stack DEVM/5/BOARD_REBOOT: Board is rebooting on Chassis 0 Slot 2.
%Apr 26 13:32:43:692 2000 IRF-Stack ISSU/5/LOAD OK:

Der Slave mit der Member-ID 2 startet nun neu und aktualisiert seine Systemsoftware. Die beiden anderen Switches im IRF-Verbund gewährleisten in der Zwischenzeit, dass die Datenkommunikation aufrecht erhalten bleibt, da der Verbund nicht komplett neugestartet wird.

Nach dem Neustart des aktualisierten Slave-Switches sieht die Situation wie folgt aus:

Der Slave mit der Priorität 5 wird nun mit einer höheren, inkompatiblen Software betrieben als der Rest des IRF-Verbunds. Somit kann dieser Switch nicht mehr am ursprünglichen Verbund teilnehmen und isoliert sich zwangsläufig. Er eröffnet einen neuen IRF-Stack und nimmt dort die Rolle des Masters ein. Dank MAD-BFD kommt es zu keiner Split-Stack-Situation, da die Ports dieses Switches automatisch abgeschaltet werden (mit Ausnahme der Console sowie der IRF Ports).

Ein Blick auf das CLI des aktiven IRF-Stacks verdeutlicht diesen Umstand:

[IRF-Stack]display irf
MemberID Role Priority CPU-Mac Description
*+1 Master 10 d07e-2886-ff5c -----
3 Slave 1 001e-c170-b846 -----
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: d07e-2886-ff5b
Auto upgrade : yes
Mac persistent : 6 min
Domain ID : 0

Ein weiterer Blick auf das CLI des isolierten Switches (mittels Konsolen-Port) zeigt, dass wir es nun mit zwei separaten Stacks zu tun haben:

display irf
MemberID Role Priority CPU-Mac Description
*+2 Master 5 d07e-2886-b042 -----
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: d07e-2886-ff5b
Auto upgrade : yes
Mac persistent : 6 min
Domain ID : 0

Nun erfolgt der bereits angesprochene Switchover, der den noch aktiven, aber mit der ‚alten‘ Software ausgestatteten IRF-Stack aktualisiert und in den neuen Verbund, den der Switch mit der Member-ID 2 eröffnet hat, überführt. Hierbei werden nun alle verbleibenden Switches neugestartet, womit der oberste, bereits aktualisierte Switch die einzige verbleibende aktive IRF-Komponente ist. Somit bleibt der IRF-Stack zwar teilweise erhalten, aber die Netzkonnektivität steht und fällt hier mit der redundanten Anbindung der anderen Netzwerkbereiche.

[IRF-Stack]issu run switchover slot 2
Master will reboot, switch the specified board to master and update the line card. Continue? [Y/N]:

Nach dem Neustart der beiden übrigen Switches ändert sich die Situation:

Alle Geräte befinden sich nun wieder in einem gemeinsamen IRF-Stack. Der ehemalige Slave mit der Priorität 5 bleibt aber der Master des neuen Verbunds. Die anderen Switches wurden als Slaves eingegliedert. Diese Prozedur ist also nicht preemptive, der „alte“ Master bekommt seinen Status vorläufig nicht zurück.

display irf
MemberID Role Priority CPU-Mac Description
1 Slave 10 d07e-2886-ff5c -----
*+2 Master 5 d07e-2886-b042 -----
3 Slave 1 001e-c170-b846 -----
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: d07e-2886-b041
Auto upgrade : yes
Mac persistent : 6 min
Domain ID : 0

Das Ergebnis dieser Prozedur ist, dass alle Switches nun mit der gleichen, neuen Software-Version ausgestattet sind:

display boot-loader
Slot 2
The current boot app is: flash:/a5800_5820x-cmw520-r1809p01.bin
The main boot app is: flash:/a5800_5820x-cmw520-r1809p01.bin
The backup boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
Slot 1
The current boot app is: flash:/a5800_5820x-cmw520-r1809p01.bin
The main boot app is: flash:/a5800_5820x-cmw520-r1809p01.bin
The backup boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin
Slot 3
The current boot app is: flash:/a5800_5820x-cmw520-r1809p01.bin
The main boot app is: flash:/a5800_5820x-cmw520-r1809p01.bin
The backup boot app is: flash:/a5800_5820x-cmw520-r1808p27.bin

Um nun das Master-Slave-Verhalten wieder herzustellen, muss der aktuelle Master mit der Member-ID 2 neugestartet werden. In diesem Fall findet wieder eine Stack Election statt, bei der die Priorität entscheidet.

reboot slot 2
This command will reboot the specified board, Continue? [Y/N]:y

Compatible ISSU

Da die in diesem Beitrag verwendeten Software-Versionen inkompatibel zueinander sind, konnte kein „Compatible ISSU“ durchgeführt werden. Letztendlich gestaltet sich der Ablauf sehr ähnlich, allerdings mit dem Unterschied, dass kein neuer Stack gebaut wird, sondern die aktualisierten Switches wieder in den Ursprungsverbund aufgenommen werden können. Nehmen wir also beispielsweise an, dass die Versionen kompatibel sind, um ein „Compatible ISSU“ durchführen zu können. Normalerweise sind Softwareversionen aus demselben Release (bspw. R1808PXX) kompatibel zueinander.

[IRF-Stack]issu load file a5800_5820x-cmw520-r1809p01.bin slot 2
This command will begin ISSU, and the specified board will reboot and be upgraded. Please save the current running configuration first; otherwise, the configuration may be lost. Continue? [Y/N]:y
%Apr 26 13:32:43:562 2000 IRF-Stack DEVM/5/BOARD_REBOOT: Board is rebooting on Chassis 0 Slot 2.
%Apr 26 13:32:43:692 2000 IRF-Stack ISSU/5/LOAD OK:

Der Slave mit der Member-ID 2 startet nun neu und aktualisiert seine Systemsoftware. Die beiden anderen Switches im IRF-Verbund gewährleisten in der Zwischenzeit, dass die Datenkommunikation aufrecht erhalten bleibt, da der Verbund nicht komplett neugestartet wird.

Nach dem Neustart des Slave Switches sieht die Situation wie folgt aus:

Die Kommunikation innerhalb des Stacks bleibt durch die kompatible Software gewährleistet. Analog zum „Incompatible ISSU“ führt man nun einen Switchover durch, wodurch der bereits aktualisierte Slave-Switch zum neuen Master wird. Dies wird ermöglicht, in dem der derzeitige Master mit der Member ID 1 neugestartet wird.

[IRF-Stack]issu run switchover slot 2
Master will reboot, switch the specified board to master and update the line card. Continue? [Y/N]:y

Nach dem Neustart des Masters ändert sich die Situation:

Der obere Switch wurde zum Master befördert. Sollte das Update erfolgreich verlaufen sein, muss man zunächst für diesen Switch die neue Software akzeptieren.

[IRF]issu accept slot 2

Nun müssen noch die verbleibenden Switches aktualisiert werden. Dies kann beim „Compatible ISSU“ separat pro Switch geschehen, wodurch weniger Switches zeitgleich nicht verfügbar sind als bei der inkompatiblen Variante:

[IRF-Stack] issu commit slot 1
The specified board will reboot and be upgraded. Continue? [Y/N]:y
[IRF-Stack] issu commit slot 3
The specified board will reboot and be upgraded. Continue? [Y/N]:y

Danach ist auch dieser ISSU-Prozess abgeschlossen, und alle Switches sind mit der neuen Software-Version ausgestattet.

Bewertung

Das „In Service Software Upgrade“ soll die Aktualisierung der Systemsoftware von Netzwerkkomponenten ermöglichen und gleichzeitig die Auswirkungen eines Serviceausfalls minimieren. Vergleichen wir nun die beiden vorgestellten ISSU-Varianten anhand eines Extremfalls.

Nehmen wir an, wir hätten einen IRF-Verbund mit neun Switches, welches gleichzeitig die maximale Anzahl an Geräten in einem Stack wäre.

Compatible ISSU

Hier würde man die Software auf alle Switches verteilen. Daraufhin würde man den Slave mit der höchsten Priorität aktualisieren. Die anderen acht Geräte laufen unterdessen normal weiter.

Danach führt man den Switchover durch, um den bereits aktualisierten Slave zum Master zu befördern. Zu diesem Zweck wird also nur der derzeitige Master neu gestartet.

Nun lässt sich jeder Stack-Member separat per „issu commit“ aktualisieren. Somit kann immer ein Switch aktualisiert werden, bis alle mit der neuen Software ausgestattet sind.

Für jeden dieser Schritte gilt:

  • Anzahl betroffener Switches = 1

  • Vorübergehend nicht verfügbare Ports = 11%

Nur die Ports eines einzelnen Switches sind im Zuge eines Neustarts „offline“. Die verbleibenden acht Geräte würden die Netzwerkkonnektivität aufrechterhalten, und die Verfügbarkeit des IRF-Verbunds ist nur minimal beeinträchtigt. Sollten die weiteren Netzwerkbereiche ausreichend redundant angebunden sein, würde dieses Beispiel-Update nur eine sehr geringe bis gar keine Auswirkung auf die Netzwerkinfrastruktur haben. Diese Prozedur verdient also ihren Namen „ISSU“ tatsächlich.

Incompatible ISSU

Schauen wir uns die andere Variante an. Auch hier würde man die Software auf alle Switches verteilen. Daraufhin würde man den Slave mit der höchsten Priorität aktualisieren. Die anderen acht Geräte laufen unterdessen normal weiter.

Auswirkung:

  • Anzahl betroffener Switches: 1

  • Portverlust in Prozent: 11%

Nach dem Neustart des aktualisierten Switches kann sich dieser aber - aufgrund der inkompatiblen Software – nicht mehr in den bestehenden Stack integrieren und wird isoliert.

Auswirkung:

  • Split-Stack-Situation

  • Portverlust in Prozent: 11%

Nun wird der Switchover durchgeführt, wodurch alle übrigen nicht aktualisierten Switches die neue Software einspielen. Durch diesen Umstand ist der bereits aktualisierte Switch der letzte verbleibende aktive Stack-Member.

Auswirkung:

  • Anzahl betroffener Switches: 8

  • Portverlust in Prozent: 89%

An dieser Stelle wird deutlich, dass ein "incompatible" Upgrade nicht mit der Forderung nach Hochverfügbarkeit über den gesamten Stack zu vereinbaren ist. Lediglich diejenigen Endsysteme oder Downstream Switches, welche redundant sowohl an den ersten aktualisierten IRF Member als auch einen der weiteren Member angebunden sind, bleiben über das gesamte Zeitintervall des Upgrades ausfallfrei verfügbar. Bei einem Stack mit neun Switches kann das aber lediglich eine Minderheit der angeschlossenen Systeme sein, die Mehrzahl wird kurzzeitig vom Netz getrennt.

Somit sollte in einem ähnlichen Szenario grundsätzlich von einem "incompatible" Upgrade Abstand genommen werden. Schließlich bietet Comware ja auch ein Patch Management, welches für die Behebung akuter Fehlerzustände in Frage kommt, bis eine konsolidierte und kompatible Version des OS verfügbar ist. Alternativ sollten diese Überlegungen bereits bei der Planung des Verbunds berücksichtigt werden, indem etwa die wichtigsten Systeme am Master sowie dem Slave mit der höchsten Priorität angeschlossen werden.