Leitfaden für das Upgrade von BroadWorks 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 2.0 unterstützt Upgrades auf die Versionen 23.0 und 24.0. Die Version 22.0 läuft Ende Juli 2024 aus, Version 23.0 ist Ende Juli 2024 und Ende Juli 2026 wird mit 24.0 EoM gerechnet. 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: 5,9+, 6,5+, 7
R23: 5,9+, 6,5+, 7 und 8,x (ap385046 erforderlich)
R24: 6,5+, 7, 8

Unabhängige unterstützte Linux-Versionen

2018:01+: 5,9+, 6,5+, 7
2019,10+: 6,5+, 7
2020,07+: 6,5+, 7, 8
2023,05+: 7, 8
2023,09+: 7, 8, 9

Datenbankserver (DBS) - unterstützte Linux-Versionen

DBS R22: 5,9+, 6,5+
DBS 2018.11 bis 2020.08: 6,5+, 7
DBS 2020.11 bis 2022.06: nur 7,5+
DBS 2022.07+: 7,5+, 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 2.0 unterstützt Linux 5 und 6. Wenn Linux 5 ausgeführt wird, kann der DBS kein Upgrade über 22.0 hinaus durchführen. Release Unabhängige Builds des DBS unterstützen Linux 5 nicht. Wenn Linux 6 ausgeführt wird, kann der DBS auf 2020.08 aktualisiert werden. Der DBS muss dann Hardware-Swap auf Linux 7, wo es wieder aktualisieren 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.3.

Erweiterte Anrufprotokolle

Enhanced Call Logs (ECL) ist Ende des Lebenszyklus auf dem DBS nach DBS 2020.08. 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 bei 22.0 und 21.sp1 kompatibel. Ein Upgrade von UMS auf 2.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 bereitgestellt wird, ist ein zusätzlicher Schritt erforderlich: von einem 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.107 5.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. ADP akzeptiert keine PS- oder XSP-Lizenzen.

Abstimmung von RI auf Major Release

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

Best Practices

Support anfordern

Das BroadWorks Upgrade Team bietet direkten Upgrade-Support.

Das BroadWorks Upgrade Team bietet einmal jährlich im Rahmen des Wartungs- und Supportvertrags Support für Upgrades auf eine aktuelle "In Support"-Version für Labor und Produktion. Das Upgrade-Team kann Sie bei der Vorbereitung eines Upgrades unterstützen und während des Upgrades Echtzeit-Support bereitstellen. Hierzu können Cisco Techniker gehören, die das Upgrade remote durchführen. Der Umfang des Upgrade-Teams ist auf die Upgrade-Aktivität beschränkt und bietet keine direkte Unterstützung für Probleme, die vor dem Upgrade gelöst werden müssen, wie Hardware- oder Betriebssystem-Updates, oder das Debuggen bereits vorhandener Probleme, und bietet keine umfassenden Tests nach dem Upgrade, die über allgemeine Serverzustandsprüfungen hinausgehen.

Wenden Sie sich über das Account Team an das BroadWorks Upgrade Team, oder senden Sie eine E-Mail an bwupgrade@cisco.com. Die Verfügbarkeit eines Echtzeit-Upgrade-Supports ist nicht kurzfristig, sondern im Voraus geplant.

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 (außerhalb der Geschäftszeiten) Aktualisieren Sie immer jeweils einen Knoten, und stellen Sie sicher, dass jeweils ein oder mehrere Knoten eines Clusters 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.