In diesem Dokument werden die Überlegungen und Anforderungen beschrieben, die bei der Planung eines Upgrades von der Quellversion von BroadWorks 23.0 behilflich sein können.
BroadWorks Version 23.0 unterstützt Upgrades auf die Versionen 24.0 und 25.0. Version 23.0 war Ende Juli 2024 EoM, und Ende Juli 2026 wird mit 24.0 EoM gerechnet. Upgrade von Nicht-Anwendungsservern auf die neueste verfügbare Version (siehe Software Compatibility Matrix Abschnitt "Supported Upgrade Maps"). Anwendungsserver führen ein Upgrade auf 2024.07 durch. Nachdem alle Server aktualisiert wurden, müssen die Anwendungsserver erneut auf die neueste Version bis 2026.07 aktualisiert werden.
Ab Version 23.0 ist die MS Release Independent (RI), bei 24.0 sind alle Server mit Ausnahme der Application Servers (AS) RI und bei 25.0 alle Server Release Independent. Alle neuen Funktionen, Bugs und Sicherheitskorrekturen werden in einer neuen Version bereitgestellt. Patches sind nicht verfügbar, stattdessen müssen Server von einer Version auf eine andere aktualisiert werden, um eine Korrektur zu erhalten. Eine neue Version jedes Servers wird jeden Monat (statt monatlicher Patchpakete) oder häufiger veröffentlicht, wenn eine dringende Reparatur erforderlich ist.
RI-Versionen verwenden ein anderes Format als das Standardformat Rel_24.0_1.944. Dieses RI-Format lautet Server_Rel_yyyy.mm_x.xxx:
MS_Rel_2022.11_1.273.Linux-x86_64.bin ist eine Version der MS, die im November 2022 veröffentlicht wurde. Oft wird dies als 2022.11 abgekürzt, wenn es sich nicht um einen bestimmten Servertyp oder eine inkrementelle Version handelt.
Ü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 6 Support endete am 30. April 2023 mit 2023.05.
Der Linux 7 Support endete am 20. Juni 2024 mit 2024.07.
Linux 9-Unterstützung ist ab 2023.09+ verfügbar.
R23: 5.9+, 6.5+, 7 und 8.x (ap385046 erforderlich)
R24: Über 6,5, 7, 8
2018.01+: Über 5,9, 6,5, 7
2019,10+: Über 6,5, 7
2020.07+: Über 6,5, 7, 8
2023,05+: 7, 8
2023.10+: 7, 8, 9 (Linux 9 wird auf dem AS bis 2024.04 nicht unterstützt)
2024,04+: 7, 8, 9
2024.07+: 8, 9
2018.11 bis 2020.08: Über 6,5, 7
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
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.
Ab Version 24.0 werden Profile Server (PS) und Xtended Service Platform (XSP) zum gleichen Servertyp, der als Application Delivery Platform (ADP) bezeichnet wird. Die PS- und XSP-Server werden nach dem Upgrade aktualisiert und zum ADP-Servertyp. Beim Upgrade von 23.0 können PS und XSP nur bis ADP 2024.07 aufrüsten. Danach muss der ADP wieder aufgerüstet werden, um auf die neueste Version zu gelangen.
Eine ADP-Lizenz und eine aktualisierte Version der bereitgestellten Anwendungen sind erforderlich. XSP-Upgrades müssen nach dem Upgrade der Anwendungsserver (AS) erfolgen. Im Download-Portal sind RI-Versionen des PS und des XSP verfügbar. Diese gelten jedoch nur für Systeme, die anstelle des AS den Execution Server (XS)-Server bereitstellen. Alle Systeme mit einem AS müssen ein Upgrade von PS und XSP auf ADP durchführen.
Cisco BroadWorks-Anwendungen und -Webanwendungen müssen manuell auf XSP, PS und ADP aktualisiert werden.
Der Datenbankserver (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 das DBS nicht über 22.0 hinaus aktualisiert werden. RI-Builds des DBS unterstützen Linux 5 nicht. Wenn Linux 6 ausgeführt wird, kann das DBS auf 2020.08 aktualisiert werden. Das DBS muss dann Hardware auf Linux 7 austauschen, wo es erneut aktualisiert werden kann. Beim Upgrade von DBS und 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.
22.0: Oracle 11
2018.11 bis 2020.08: Oracle 12
2020.11+: Oracle 19
Es besteht die Möglichkeit, das DBS-Upgrade zu überspringen und die DB aus 22.0 direkt in das DBS 202.03+ zu importieren. Dieser Prozess ist jedoch nicht schnell und muss 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 Config Guide Section 6.5.7.3.
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.
Die EoM für Messaging Server (UMS), Sharing Server (US), Video Server (UVS), WebRTC Server (WRS), Business Communicator Client (BTBC) und Connect Client wurde am 31. Januar 2022 abgeschlossen. 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 für das Upgrade zusätzliche Schritte erfordert, verfügt über eine separate Verfahrensweise (Method of Procedure, MoP) und erfordert einen zusätzlichen Knoten für die Redundanz. 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.
Versionshinweise für die Ziel-Version und alle Versionen zwischen der Ziel- und der Quell-Version müssen überprüft werden. Wenn die Zielversion 24.0 ist, müssen die Versionshinweise für 24.0 und 25.0 überprüft werden.
24.0 Versionshinweise
Versionshinweise 25.0 und höher
Upgrade-Verfahren
Die offiziell unterstützten Upgrade-Pfade finden Sie in der Software Compatibility Matrix.
Für die Zielversion ist eine neue Lizenz erforderlich. Um eine Lizenz zu beantragen, öffnen Sie ein Ticket. die Umwandlung der PS- und XSP-Lizenzen in ADP-Lizenzen beantragen; Der ADP akzeptiert keine PS- oder XSP-Lizenz.
Wenn Sie ein Upgrade ohne Unterstützung des Upgrade-Teams durchführen, sollten Sie den BroadWorks Support einige Tage im Voraus mit einem Ticket mit Schweregrad 4 (s4) benachrichtigen. Tritt während der Wartung ein Problem auf, 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.
Ein Testplan ist notwendig, um ein reibungsloses Upgrade zu gewährleisten. Vor einem Produktions-Upgrade muss ein Testplan entwickelt und in einem Lab 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.
Patchen Sie die Quellversion vor dem Upgrade auf höchstens sechs Monate des neuesten Patch-Levels.
Das Skript zur Überprüfung vor der Installation muss auf jedem Server, jeder Übung und jeder Produktion ausgeführt werden. Außerdem müssen etwaige Warnungen oder Fehler vor dem Upgrade behoben werden.
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 der Übung und dem Produktions-Upgrade auf maximal drei Monate.
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 ggf. Zeit für Fehlerbehebung und/oder Rollback in der geplanten MW verfügbar.
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.
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
06-Aug-2026
|
Erstveröffentlichung |