Upgrade von BroadWorks Version 2.0

Einleitung

In diesem Dokument werden die Überlegungen und Anforderungen beschrieben, die bei der Planung eines Upgrades von der Quellversion von BroadWorks 2.0 behilflich sein sollen.

Überblick

BroadWorks Release 22.0 unterstützt Upgrades auf die Versionen 23.0 und 24.0. Version 22.0 stellt den Wartungsvertrag (End of Maintenance, EoM) ein, Version 23.0 den Wartungsvertrag (End of July 2024) und Version 24.0 den Wartungsvertrag (End of July) 2026 Ein Upgrade auf 24.0 wird empfohlen.

Unabhängige Versionen freigeben

Ab Version 23.0 ist der MS Release Independent (RI) und ab Version 24.0 alle Server außer dem AS 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 Fehlerbehebung 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:

• Der Server ist MS, z.B.:
• yyyy ist das vierstellige Jahr.
• mm ist der zweistellige Monat
• x.xxx ist die inkrementelle Version für diesen Monat

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.

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 6 Support endete am 30. April 2023 mit 2023.05.
Der Linux 7 Support endet am 20. Juni 2024 mit 2024.07.

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

Hauptversion Unterstützte Linux-Versionen

R22: Über 5,9, 6,5, 7
R23: 5.9+, 6.5+, 7 und 8.x (ap385046 erforderlich)
R24: Über 6,5, 7, 8

Unabhängige unterstützte Linux-Versionen

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,09+: 7, 8, 9

Datenbankserver (DBS) - unterstützte Linux-Versionen

DBS R22: Über 5,9, über 6,5
DBS 2018.11 bis 2020.08: Über 6,5, 7
DBS 2020.11 bis 2022.06: Nur 7,5+
DBS 2022.07+: Über 7,5, über 8,5

Betriebssystem-Upgrades

BroadWorks unterstützt kein direktes Upgrade zwischen wichtigen Linux-Versionen. Es wird empfohlen, einen Hardware-Swap durchzuführen, einen neuen Server auf der Linux-Zielversion zu erstellen und den vorhandenen Server auf den neuen Server zu migrieren. Siehe Abschnitt 5.2.6 des Software Management Guide und Abschnitt 12.2 des Maintenance Guide.

Es wird nicht empfohlen, gleichzeitig ein Hardware-Upgrade von BroadWorks durchzuführen oder ein Hardware-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

Profilserver und Xtended Service Platform - Upgrade auf eine Plattform zur Anwendungsbereitstellung

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.

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.

Datenbankserver

Der Datenbankserver (DBS) muss in mehreren Sprüngen auf die neueste RI-Version aktualisiert werden, da das Betriebssystem Einschränkungen aufweist. 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 PS müssen die Versionen von DBManagement und DBSObserver mit der Version des DBS übereinstimmen, um sicherzustellen, dass die zugrunde liegende Oracle-Version kompatibel ist.

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 DB aus 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 Config Guide Section 6.5.7.

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, verfügt über eine separate Verfahrensweise (Method of Procedure, MOPP) 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.

Element Management System und Virtual Licensing Server

Das Element Management System (EMS) und der Virtual Licensing Server (VLS) haben im zweiten Quartal 2018 den End-of-Life (EoL)-Status erreicht. Ihre Funktionalität wurde durch den Network Function Manager (NFM) ersetzt. Es gibt keinen Upgrade-Pfad zum NFM oder die Außerbetriebnahme von EMS- oder VLS-Knoten.

Network Function Manager

Wenn die Netzwerküberwachung implementiert ist, ist ein zusätzlicher Schritt erforderlich. Upgrade von 22.0 auf 2020.11 und dann auf 2022.08+.

Upgrade auf 23.0 unter Linux 6

Wenn Sie einen Anwendungsserver auf Linux 6 auf 23.0 aktualisieren, dürfen mehrere Patches nicht angewendet werden, oder das Upgrade schlägt beim Patchen fehl. "Rel_22.0/v1.450/". Wenden Sie diese Patches beim Upgrade auf 23.0 nicht auf das AS an: AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 und AP.as.23.0.1075.ap385453.

Dokumentation überprüfen

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 22.0, 23.0 und 24.0 überprüft werden.
23.0 Versionshinweise

24.0 Versionshinweise
Upgrade-Verfahren
Die offiziell unterstützten Upgrade-Pfade finden Sie in der Software Compatibility Matrix.

Lizenzanforderungen

Für die Zielversion ist eine neue Lizenz erforderlich. Um eine Lizenz zu beantragen, öffnen Sie ein Ticket. Fordern Sie für Upgrades auf 24.0 an, dass die PS- und XSP-Lizenzen in ADP-Lizenzen umgewandelt werden. Der ADP akzeptiert keine PS- oder XSP-Lizenz.

Abstimmung von RI auf Major Release

2018.xx = R22
2019.01 to 2020.06 = R23
2020.07 to 2022.07 = R24

Best Practices

Vor einem Upgrade BroadWorks-Support benachrichtigen

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. 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 für ein reibungsloses Upgrade unerlässlich. 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.

Patching

Patchen Sie die Quellversion vor dem Upgrade auf maximal 6 Monate des neuesten Patch-Levels.

Prüfskript vor der Installation

Das Skript zur Überprüfung vor der Installation muss auf jedem Server, jedem Labor und jeder Produktionsumgebung ausgeführt werden. Vor dem Upgrade müssen ggf. Warnungen oder Fehler 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 ggf. Zeit für Fehlerbehebung und/oder Rollback in der geplanten MW verfügbar.

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.