Einleitung
In diesem Dokument werden die Überlegungen und Anforderungen beschrieben, die bei der Planung eines Upgrades von der Quellversion von BroadWorks 24.0 behilflich sein sollen.
Überblick
BroadWorks 24.0 unterstützt Upgrades auf die Versionen 25.0 und 26.0. Die Einstellung der Wartung für Version 24.0 wurde für Ende Juli 2026 angekündigt. Alle Server führen ein Upgrade auf die neueste unabhängige Version durch (siehe Software Compatibility Matrix im Abschnitt "Supported Upgrade Maps"), bis 2028.07.
Unabhängige Versionen freigeben
Bei 25.0 sind 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.
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 endete am 20. Juni 2024 mit 2024.07.
Linux 9-Unterstützung ist ab 2023.09+ verfügbar.
Hauptversion Unterstützte Linux-Versionen
R24: Über 6,5, 7, 8
R25: Über 6,5, 7, 8
Unabhängige 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
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 der Aktualisierung der 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.
Beim Upgrade von ADP-Servern auf 2025.07 oder höher gibt es eine Änderung in der Java JRE-Version, die das Upgrade kompliziert, wenn Release Independent und Release Anchored Apps auf dem ADP-Server vermischt werden. Weitere Informationen finden Sie in diesem Hilfedokument.
DBS
Der DBS hat das Ende des Lebenszyklus erreicht. 2024.09 ist die finale Version der DBS- und ECCR-Apps. ECCR muss durch CCER ersetzt werden. Weitere Informationen zu den DBS-Optionen finden Sie in diesem Dokument. Sobald ECCR nicht mehr verwendet wird, muss das DBS stillgelegt werden.
Erweiterte Anrufprotokolle (ECL)
ECL ist das 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.
Dokumentation überprüfen
Versionshinweise für die Ziel-Version und alle Versionen zwischen der Ziel- und der Quell-Version müssen überprüft werden.
25.0 Versionshinweise
26.0 Versionshinweise
Upgrade-Verfahren (MoP)
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. die Umwandlung der PS- und XSP-Lizenzen in ADP-Lizenzen beantragen; Der ADP akzeptiert keine PS- oder XSP-Lizenz.
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 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 höchstens sechs Monate des neuesten Patch-Levels.
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 der Übung und dem Produktions-Upgrade auf maximal drei 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.
Feedback