Leitfaden für das Upgrade von BroadWorks 25.0

Einleitung

In diesem Dokument werden die Überlegungen und Anforderungen für die Planung eines Cisco BroadWorks-Systemupgrades ab der Quellversion 20.0 beschrieben.

Überblick

Alle Server aktualisieren auf die neueste Version Verfügbare unabhängige Version (siehe Software Compatibility Matrix Abschnitt "Unterstützte Upgrade-Karten").

Betriebssystemanforderungen

Überprüfen Sie, ob das Quellbetriebssystem (OS) von der Zielversion unterstützt wird.

Unterstützte Betriebssysteme sind Red Hat Enterprise Linux, Oracle Linux und CentOS 7. CentOS 8, CentOS Stream, Rocky Linux und Alma Linux werden nicht unterstützt.

Der Linux 7 Support endete am 20. Juni 2024 mit 2024.07.

Linux 9-Unterstützung ist ab 2024.04+ verfügbar.

Unterstützte Linux-Versionen

2020.07+: Über 6,5, 7, 8
2023,05+: 7, 8

2023.10+: 7, 8, 9 (Linux 9 wird auf den Anwendungsservern (AS) erst ab 2024.04 unterstützt)

2024,04+: 7, 8, 9
2024.07+: 8, 9

Datenbankserver (DBS) - unterstützte Linux-Versionen

2020.11 bis 2022.06: Nur 7,5+
2.02.07+: Über 7,5, über 8,5

2024.07+: Über 8,5

2024.09: Endgültige Version/End-of-Life

Betriebssystem-Upgrades

BroadWorks hat bisher keine Vor-Ort-Upgrades zwischen wichtigen Linux-Versionen unterstützt. Bisher wurde empfohlen, einen Hardware-Austausch durchzuführen, einen neuen Server auf der Linux-Zielversion zu erstellen und den vorhandenen Server auf den neuen Server zu migrieren. Ab Version 2023.12 werden direkte Linux-Upgrades von Linux 7 auf 8 und 8 auf 9 unterstützt. Um ein direktes Linux-Upgrade durchzuführen, müssen Server zunächst auf 2023.12 oder höher aktualisiert werden.

Eine Dokumentation zu Linux-Upgrades vor Ort finden Sie in Abschnitt 9 des Software Management Guide. Eine Dokumentation des Hardware-Austauschprozesses finden Sie unter Abschnitt 5.2.6 des Software Management Guide und Abschnitt 12.2 des Maintenance Guide.

Es wird nicht empfohlen, einen Hardware-Swap zu verwenden, um gleichzeitig ein Upgrade von BroadWorks durchzuführen oder ein Hardware-Swap oder ein direktes Linux-Upgrade und ein BroadWorks-Upgrade im gleichen Wartungsfenster durchzuführen. Server mit einer Datenbank müssen den Upgrade-Prozess durchlaufen. Eine Datenbank aus einer Version von BroadWorks kann nicht in eine andere Version von BroadWorks importiert werden.

Einschränkungen für Upgrades und serverspezifische Hinweise

DBS

Das DBS muss in mehreren Sprüngen aktualisiert werden, um aufgrund von Betriebssystembeschränkungen auf die neueste RI-Version zu aktualisieren. DBS 22.0 unterstützt Linux 5 und 6. Wenn Linux 5 ausgeführt wird, kann DBS nicht über 22.0 hinaus aktualisiert werden. Release Independent Builds des DBS unterstützen Linux 5 nicht. Wenn Linux 6 ausgeführt wird, kann DBS auf 2020.08 aktualisiert werden. Das DBS muss dann Hardware auf Linux 7 austauschen, wo es wieder aktualisiert werden kann. Beim Upgrade von DBS und Profile Server (PS) müssen die Versionen von DBManagement und DBSObserver mit der Version des DBS übereinstimmen, um sicherzustellen, dass die zugrunde liegende Oracle-Version aus Kompatibilitätsgründen übereinstimmt.

DBS Release und Oracle Release Alignment

22.0: Oracle 11
2018.11 bis 2020.08: Oracle 12
2020.11+: Oracle 19

DBS-Upgrade überspringen

Es besteht die Möglichkeit, das DBS-Upgrade zu überspringen und die Datenbank (DB) von 22.0 direkt in das DBS 202.03+ zu importieren. Dieser Prozess ist jedoch nicht schnell und sollte im Labor getestet werden, um den erwarteten Zeitpunkt für die Produktion zu überprüfen. Weitere Informationen finden Sie in den DBS Release Notes Section 6, BWKS-3069 und im DBS Configuration Guide Section 6.5.7.3.

Erweiterte Anrufprotokolle

Enhanced Call Logs (ECL) sind nach DBS 2020.08 abgelaufen. Die ECL-Datenbank muss zu einem Network Database Server (NDS) migriert werden, damit sie weiter verwendet werden kann. Die Migration erfolgt nicht automatisch. Weitere Informationen finden Sie im Enhanced Call Logs Solution Guide und in der NDS Enhanced Call Logs Feature Description (Funktionsbeschreibung für erweiterte Anrufprotokolle). Informationen zum Migrationsprozess finden Sie im Konfigurationsleitfaden für Network Database Server zum Einrichten eines NDS und in der ECL-Migration von DBS zu NDS. Die Migration muss vor dem Upgrade durchgeführt werden.

Server für Zusammenarbeit

Das Ende der Wartung (End of Maintenance, EoM) für Messaging Server (UMS), Sharing Server (USS), Video Server (UVS), WebRTC Server (WRS), Business Communicator Client (BTBC) und Connect Client wurde am 31. Januar 2022 erreicht. Die neueste RI-Version für UMS ist 22.0, für die USA, UVS und WRS ist die neueste Version 2022.01 verfügbar.

Das AS bei 24.0 ist mit dem UMS auf 22.0 und 21.sp1 kompatibel. Ein Upgrade des UMS auf 22.0 wird nicht empfohlen. Das UMS mit 22,0 verwendet MariaDB anstelle von Oracle TimesTen, was zusätzliche Schritte für das Upgrade erfordert, eine separate Verfahrensweise (Method of Procedure, MoP) und einen zusätzlichen Knoten für die Redundanz erfordert. Siehe UMS-Upgrade-MOPP und Benachrichtigung zur Einstellung von MariaDB 10.1.

Es wird empfohlen, die Collaborate-Services durch WebEx für BroadWorks zu ersetzen. Weitere Informationen finden Sie im WebEx for BroadWorks Solutions Guide.

Dokumentation überprüfen

Versionshinweise für die Ziel-Version und alle Versionen zwischen der Ziel- und der Quell-Version müssen überprüft werden.

26.0 Versionshinweise
Upgrade-Verfahrensweise (MOPP)
Die offiziell unterstützten Upgrade-Pfade finden Sie in der Software Compatibility Matrix.

Lizenzanforderungen

Für die Zielfreigabe ist eine neue Lizenz erforderlich. Um eine Lizenz anzufordern, öffnen Sie ein Ticket.

Best Practices

Vor einem Upgrade BroadWorks-Support benachrichtigen

Es wird empfohlen, den BroadWorks Support einige Tage im Voraus mit einem Ticket mit Schweregrad 4 (s4) zu benachrichtigen. Wenn während der Wartung ein Problem auftritt, heben Sie den Schweregrad des Tickets auf s1, öffnen Sie ein neues s1-Ticket, oder rufen Sie die Support-Leitung an, um mit einem Techniker zu sprechen.

Testpläne

Ein Testplan ist notwendig, um ein reibungsloses Upgrade zu gewährleisten. Vor einem Produktions-Upgrade muss ein Testplan in einem Lab entwickelt und getestet werden. Führen Sie vor dem Upgrade den Testplan auf dem System aus, und zeichnen Sie die Ergebnisse auf. Dies stellt sicher, dass das System fehlerfrei ist, verifiziert, dass alle Testbenutzer und -konten korrekt konfiguriert und funktionsfähig sind, bietet eine Möglichkeit, potenzielle Lücken im Testplan zu erkennen, und liefert eine Zeitschätzung, wie lange die Tests voraussichtlich dauern werden.

Jeder Server muss nach dem Upgrade getestet werden, um sicherzustellen, dass er wie erwartet funktioniert, bevor mit dem Upgrade auf den nächsten Server in der Sequenz fortgefahren wird.

Prüfskript vor der Installation

Das Skript zur Überprüfung vor der Installation muss auf jedem Server, jeder Übung und jeder Produktion ausgeführt werden, und etwaige Warnungen oder Fehler müssen vor dem Upgrade behoben werden.

Lab-Upgrade

Es wird immer empfohlen, das Upgrade, den Testplan und die Zielversion mit Tools, Anwendungen oder Clients von Drittanbietern in einer Laborumgebung zu testen, die die Produktionsumgebung repliziert. Die Übung kann verkleinert werden, sollte jedoch dieselben Servertypen, Softwareversionen, Betriebssystemversionen, Zugriffsgeräte, SBC (Session Border Control) usw. umfassen. Behandeln Sie das Lab-Upgrade wie einen Probelauf für das Upgrade der Produktionsumgebung. Verwenden Sie beim Upgrade der Übung die neueste Patch-Stufe für die Zielversion. Halten Sie die Zeit zwischen Übung und Produktions-Upgrade auf maximal 3 Monate.

Reihenfolge für Planung und Upgrade

Upgrades werden über mehrere Wartungsfenster, die über mehrere Nächte verteilt sind, vorgenommen und in der Installations- und Upgrade-Bestellung gemäß Abschnitt 4.2 des Software Management Guide ausgeführt. Durchführen von Upgrades immer während eines vorbestimmten Wartungsfensters (während einer nicht ausgelasteten Zeit). Aktualisieren Sie immer jeweils einen Knoten, und stellen Sie sicher, dass ein oder mehrere Knoten eines Clusters zu einem bestimmten Zeitpunkt ausgefallen sind. Die Länge des Wartungsfensters (MW), die Anzahl der zu aktualisierenden Server, der Servertyp und die zu erwartende Dauer der Tests bestimmen, wie viele Wartungsfenster benötigt werden. Alle Server in einem Cluster müssen mit derselben MW aktualisiert werden. Lassen Sie die Zeit in der geplanten MW für die Fehlerbehebung und/oder Rollback, falls erforderlich.

Upgrade-Fehler

Wenn ein Problem während des Tests nach dem Upgrade erkannt wird oder ein Upgrade fehlschlägt, sammeln Sie Protokolle, bevor Sie zur Quellversion zurückkehren oder den Server wiederherstellen. Sichern Sie das gesamte Protokollverzeichnis, um sicherzustellen, dass alle potenziell hilfreichen Protokolle gespeichert werden. Öffnen Sie sofort ein Ticket und rufen Sie den Support an, um Unterstützung zu erhalten, während Sie sich noch in der MW befinden.

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	19-May-2026	Erstveröffentlichung