Inhalt

Einleitung

Offizielle Dokumentation

Standardverfahren

Installationsverfahren

Network Function Manager (NFM)

Datenbankserver (DBS)

Netzwerk-Datenbankserver (NDS)

Netzwerkserver (NS)

Medienserver (MS)

Anwendungsserver (AS)

Dienststeuerfunktion (Service Control Function, SCF)

Application Delivery Platform (ADP)

Einleitung

In diesem Dokument wird das Verfahren zum Upgrade von BroadWorks-Servern beschrieben, das vom BroadWorks Upgrade Team von anderen offiziellen Quellen durchgeführt wird.

Offizielle Dokumentation

Diese Referenzdokumente finden Sie auf der Seite Cisco BroadWorks Documentation Guide Release 25. Verweisen Sie auf folgende Hauptdokumente:

- Software-Management-Leitfaden

- Leitfaden zur Systemkonfiguration

- Wartungshandbuch

- 26.0 Versionshinweise

- 25.0 Versionshinweise

- 24.0 AS Versionshinweise

Versionshinweise

Überprüfen Sie vor dem Upgrade die Versionshinweise für die Zielversion, und messen Sie die potenziellen Auswirkungen der Änderungen. Lesen Sie die Versionshinweise für die Zielversion und alle Zwischenversionen zwischen der Quell- und der Zielversion. Wenn Sie beispielsweise ein Upgrade von 23.0 auf 25.0 durchführen, müssen Sie die Versionshinweise für 24.0 und 25.0 überprüfen.

Diese finden Sie auf der Seite mit der Cisco Dokumentation oder über die bereitgestellten Links.

Standardverfahren

Dies ist die Reihenfolge, in der Server aktualisiert werden. Die Netzwerkserver (NSs) und Medienserver (MSs) müssen nicht in einer bestimmten Reihenfolge zueinander aktualisiert werden.

Die Application Delivery Platforms (ADPs) werden in der Sequenz zweimal erwähnt, da die ersten ADPs aus den ADPs bestehen, auf denen DBSObserver, DBManagement und andere Profile-Services ausgeführt werden. Die zweite Gruppe von ADPs umfasst die Xtended Services Interface (XSI)-, Open Client Interface - Provisioning (OCI-P)-, Device Management System (DMS)- und Notification Push Server (NPS)-Services.

Wenn Sie ein Upgrade von BroadWorks-Servern durchführen, befolgen Sie die folgenden grundlegenden Schritte:

1. Sichern Sie den Server.

2. Installieren Sie das neueste RI-Installationspaket (Release Independent). Der swmanager ist im RI-Paket enthalten.

3. Installieren Sie die Lizenz für die Zielversion.

4. Führen Sie das Tool zur Aktualisierungsprüfung über die CLI aus, um sicherzustellen, dass keine Warnungen vorhanden sind:
ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2021.02_1.50

Installieren Sie die Zielversion immer auf allen Peers desselben Clusters, bevor Sie ein Upgrade für eines der Mitglieder des Clusters durchführen.

Es ist nützlich, abgeschlossene Tasks für jeden Server abzuschalten. Beispiele:

Maschine

SERVER1

SERVER 2

SERVER3

Backup

Fertig

Fertig

Technischer Support

Fertig

... usw.

Installation der Zielversion

Fertig

Lizenzimport

Fertig

Gesundheitscheck

Fertig

Upgrade-Prüfung

Fertig

Prozedurerwartungen

In diesem Dokument wird Folgendes vorausgesetzt:

1. Es ist ausreichend Speicherplatz vorhanden, um Backups durchzuführen, die neuen Binärdateien zu installieren und ein Upgrade durchzuführen.

2. Jeder Server kann Pakete installieren.

3. Das Betriebssystem ist mit der Zielversion kompatibel.

4. Der pre-InstallCheck wurde auf jedem Server ausgeführt und alle Warnungen oder Fehler wurden behoben.

5. Das System befindet sich in einem Zustand.

6. Es wurden die entsprechenden Lizenzen erworben.

7. Es wurde ein Testplan erstellt, der vor dem Upgrade ausgeführt wurde, und die Ergebnisse wurden aufgezeichnet.

Serverspezifische Hinweise

- Der Network Function Manager (NFM) ist unabhängig von den anderen BroadWorks-Servern, sodass die Interoperabilität kein Problem darstellt. Es wird immer empfohlen, die neueste Version von NFM auszuführen.

- Beim Upgrade auf den Datenbankserver (DBS) wird die Software aktualisiert. Die Schemaänderungen an der Datenbank erfolgen jedoch erst, wenn das ADP (auf dem die Anwendung EnhancedCallLogsDBManagement ausgeführt wird) aktualisiert wurde.

- Es wird empfohlen, das DBS oder den Network Database Server (NDS) zu sichern, bevor ein ADP-Upgrade durchgeführt wird, auf dem EnhancedCallLogsDBManagementNDS oder CCReportingDBManagement ausgeführt wird.

- Aktualisieren Sie die MS/NS vor dem Anwendungsserver (AS). In der Regel läuft MS/NS bis zum Upgrade des AS für einen oder zwei Tage auf der neuesten Version.

Weitere Informationen finden Sie in der Kompatibilitätsmatrix.

Testpläne vor und nach dem Upgrade

Es wird empfohlen, einen vollständigen Testplan zu erstellen und die Ergebnisse dieses Testplans vor einem Upgrade auszuführen und aufzuzeichnen. Dies hilft, Probleme vor einem Upgrade zu identifizieren, und bietet außerdem einen Vergleich mit den Testergebnissen nach dem Upgrade.

Zurücksetzen und Rollbacks

Bei einem BroadWorks-Upgrade ist das Zurücksetzen und Zurücksetzen eines Servers nicht dasselbe. Ein Server stellt die letzte Datenbanksicherung wieder her, die vor dem Upgrade durchgeführt wurde, um den Zustand der Datenbank wiederherzustellen. Mit einer Zurücksetzung werden alle Daten zurückgesetzt, die der DB nach dem ersten Upgrade hinzugefügt wurden. Bei einem Rollback werden alle Änderungen an der DB im Zuge des Upgrades zurückgesetzt, sodass alle Daten, die der DB nach dem ersten Upgrade hinzugefügt wurden, intakt bleiben.

Unabhängige Server freigeben

Alle Server sind RI. Alle neuen Funktionen, Bugs und Sicherheitskorrekturen werden in einer neuen Version der Software bereitgestellt. Patches können nicht bereitgestellt werden. Server müssen von einer Version auf eine andere aktualisiert werden, um einen Fix zu erhalten. Es wird erwartet, dass eine neue Version jedes Servers pro Monat veröffentlicht wird (anstelle von monatlichen Patch-Paketen).

RI-Versionen verwenden ein anderes Format als das Standardformat Rel_25.0_1.944. Dieses RI-Format ist: Server_Release_yyy.mm_1.xxx:

- Server ist z.B. MS

- yyyy ist die vierstellige Jahresangabe.

- mm ist der zweistellige Monat

- xxx die inkrementelle Version für diesen Monat ist.

MS_Rel_2022.11_1.273.Linux-x86_64.bin ist beispielsweise eine Version von MS, die im November 2022 veröffentlicht wurde.

HINZUFÜGEN

In Version 25 wurden die Xtended Services Platform (XSP) und Profile Server (PS) auf den ADP umgestellt. Die Anwendungen, die auf dem XSP und dem PS ausgeführt werden, werden in zwei Kategorien unterteilt: Kernanwendungen (die Dienste für die Kerninfrastruktur bereitstellen) oder Grenzanwendungen (die externen API-Zugriff bereitstellen). Die installierten Anwendungen legen fest, wo sich die ADP im Netzwerk befindet.

Die auf dem ADP bereitgestellten Anwendungen werden entweder als RI-Version oder als Release Anchored (RA) bereitgestellt. RA bedeutet, dass die Anwendung eine Schemaabhängigkeit von der AS-Version aufweist, sodass eine Release-Komponente zum Namen der Anwendungsdatei vorhanden ist und eine andere "Verzweigung" bereitgestellt wird, die der AS-Version zugeordnet ist.

Eine Liste der verfügbaren Anwendungen für die ADP und die neuesten verfügbaren Versionen finden Sie unter BroadWorks Application Delivery Platform Software Download.

Installationsverfahren

BroadWorks-Installationsprogramme können von Cisco BroadWorks - Downloads heruntergeladen werden.

Binary für die Zielversion installieren

Die Installation kann ohne Unterbrechungszeiten erfolgen. Das Installationsverfahren ist für alle Server gleich, mit einem geringfügigen Unterschied bei den Servertypen. RI-Server haben keinen Installations-Patch.

In diesen Beispielschritten wird ein AS verwendet, das Verfahren ist jedoch für alle 25.x BroadWorks-Binärdateien identisch. Dies muss als root-Benutzer durchgeführt werden (sudo ist nicht akzeptabel.). Die umask ist 0022 für root und 0002 für bwadmin.

$ chmod +x AS-25_Rel_2023.03_1.411.Linux-x86_64.bin

$ ./AS-25_Rel_2023.03_1.411.Linux-x86_64.bin

Überprüfen Sie nach Abschluss der Installation die Ausgabe auf weitere Aktionen oder Warnungen. Es werden Meldungen angezeigt, dass eine neue Lizenz erforderlich ist und die Zielversion manuell aktiviert werden muss.

==============================================================

The installation is now completed.

==============================================================

+++ Warnings summary +++

+++WARNING --- 1001 <You may have to install new license files>

+++WARNING --- 1002 <You will need to manually activate the new software version>

Please refer to the information reported in file:

/var/broadworks/logs/installation/installation.230418.20h03m19s.warning

for details as some warnings may require manual intervention.

done

Moving logs, steps and warnings to /var/broadworks/logs/installation

Geben Sie nach der Installation den qversions Befehl aus der bwcli ein, um sicherzustellen, dass der Befehl vorhanden ist. Beachten Sie, dass der Status Installed (nicht Active) lautet.

AS_CLI> qversions

Identity        Version  Install Date     Status

==================================================

AS  2023.03_1.411  Apr 18, 2023  Installed

AS     24.0_1.944  Feb 11, 2022  Active

Eine installierte Binärdatei entfernen

Wenn die Binärdatei nicht richtig installiert wird oder entfernt werden muss, führen Sie das uninstall-bwserver.pl Skript aus.

$ cd /bw/broadworks/

/uninstall/

$ ./uninstall-bwserver.pl -r

Der Parameter "-r" gibt die Anweisung, die verbleibende Ordnerstruktur in /bw/Broadworks/<Server> zu entfernen.

Zielversionslizenz installieren

In diesem Abschnitt werden nur UUID-Lizenzen (Universal Unique Identifier) behandelt. Informationen zu NFM-basierten Lizenzen finden Sie im Abschnitt zur Lizenzverwaltung im Network Function Manager Node and License Management Guide.

Bei UUID-basierten Lizenzen befinden sich die Lizenzdateien in mehreren ZIP-Dateien. Der Server erwartet die ZIP-Datei mit den TXT- und SIG-Dateien. Entpacken Sie die Dateien nicht auf einem lokalen Computer, um die TXT- und SIG-Dateien einfach zu kopieren, da dies die Signatur ungültig macht.

Lizenz aus CLI importieren

Sie müssen die Lizenzdateien nicht entpacken und den vollständigen Pfad verwenden.

AS_CLI/System/Licensing/LicenseManager/LicenseStore> import /path/to/licensefiles.zip

Installieren der Lizenz vom Betriebssystem

Es ist nicht erforderlich, die Lizenzdateien zu entpacken und den vollständigen Pfad wie bwadmin oder root run zu verwenden.

$ cd /usr/local/broadworks/bw_base/bin/

$ ./install-license.pl /path/to/licensefiles.zip

Installieren der Lizenz vom Betriebssystem für die Konvertierung von XSP in ADP

Gehen Sie zu ADP taraget release foalder cd /usr/local/Broadworks/ADP_Rel_2024.11_1.311/ und führen Sie install-license.pl scrpit aus.

$ cd /usr/local/broadworks/ADP_Rel_2024.11_1.311/bw_base/bin/

$ ./install-license.pl /path/to/licensefiles.zip

Führen Sie das UpgradeCheck-Tool aus

Führen Sie das upgradeCheck Tool von der bwcli aus, und vergewissern Sie sich, dass keine Warnungen vorhanden sind.

Ein Beispiel aus dem AS ist hier zu sehen:

AS_CLI/Maintenance/Tools> upgradeCheck AS_Rel_2023.03_1.411

This is a dry-run upgrade.

BroadWorks SW Manager checking AS server version 2023.03_1.411...

Checking license file information

Checking configuration file presences

Checking installation.conf file

Checking version presences

Checking Broadworks version dependencies

Checking target Broadworks version present

Checking for available disk space

Space required = 32768 Mb

[done]

Checking System configuration

BW Daemon configuration validation

testing /etc/xinetd.d...         [done]

Validating MoDaemon

Checking upgrade compatibility

Checking for dangling softlink

...Monitoring directory tree starting at: /var/broadworks

Running /usr/local/broadworks/AS_Rel_2023.03_1.411 /bin/preUpgradeCheck

Executing transform...  [ok]

####### CCRS Support Check START #######

No need to check for CCRS devices, upgrading from release 19 or later

####### CCRS Support Check END #######

####### Conference Access Check START #######

No need to check for duplicate conference Id's and Moderator Pins , upgrading from release 19 or later

####### Conference Access Check END #######

####### trunk group check START #######

####### Startup Parameters IP Addresses Check START #######

####### Startup Parameters IP Addresses Check END #######

####### Reporting File Queues Check START #######

####### Reporting File Queues Check END #######

####### Domains table sanity check START #######

####### Domains table sanity check END #######

####### DNIS UID sanity check START #######

####### DNIS UID sanity check END #######

####### File System Protocol Check START #######

No need to check for use of WebDav interface for custom media files.

Upgrading from release 20 or later

####### File System Protocol Check END #######

####### Disk space check for Announcement repository START #######

No need to check for available diskspace for announcement repository.

Upgrading from release 20 or later

####### Disk space check for Announcement repository END #######

####### DeviceProfileAuthMode Check START #######

####### DeviceProfileAuthMode Check END #######

####### Activatable Feature Validation START #######

Validation Successful

####### Activatable Feature Validation END #######

####### Database Manual Connections START #######

No manual database connections detected..

####### Database Manual Connections END #######

Waiting for maintenance tasks to complete if any

Checking sshd configuration

Checking for critical patches

Checking for feature patches conformity between source and target version

Checking TimesTen permanent memory size

Checking version of active TimesTen

####### Database Impacts Check START #######

Database impacts detected: datastore will be unloaded, replication will be restarted, database will be imported on non-primary nodes.

####### Database Impacts Check END #######

setactiveserver command successfully executed.

Dry-run upgrade completed.

Network Function Manager (NFM)

Der NFM implementiert die Funktionen für das Netzwerk- und Lizenzmanagement.

Stellen Sie sicher, dass bei HealthMon keine Probleme auftreten:

--------------------------------

System Health Report Page

BroadWorks Server Name: nfm1

Date and time         : Thu Nov  8 05:19:16 EST 2022

Report severity       : NOTIFICATION

Server type           : NetworkFunctionManager

Server state          : Unlock

--------------------------------

No abnormal condition detected.

--------------------------------

Backup und technischer Support

Vor einem Server-Upgrade wird empfohlen, ein Backup durchzuführen und einen technischen Support von vor dem Upgrade zu protokollieren:

$ bwBackup.pl -type=full -file=/var/broadworks/backup/bwBackup.bak

$ tech-support >> tsup_hostname_sourceRelease.txt

Vor dem Upgrade

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

NFM_CLI/Maintenance/Tools> upgradeCheck NFM_Rel_2022.11_1.274

Überprüfen Sie, ob auf dem NFM, der aktualisiert wird, eine Netzwerküberwachung vorhanden ist.

NFM_CLI/Applications/NetworkMonitoring/Replication> status

Admin state = standby

Effective state = standby

Name  Admin State  Effective State

================================================

PostgreSQL       Online           Online

OpenNMS      Offline          Offline

File replication       Online          Offline

Monitoring       Online          Offline

4 entries found.

NFM_CLI/Applications/NetworkMonitoring/Replication> exit

Please confirm (Yes, Y, No, N): y

This session is now ending...

bwadmin@nfm02-cormac.local$ pgctl status

Database Status:       Running

Accepting Connections: TRUE

Configured Mode:       standby

Effective Mode:        standby

Replication stats:

WAL files: 66

NFM-Upgrade-Switch

Wenn in einem NFM-Cluster die Netzwerküberwachung auf dem NFM ausgeführt wird, muss zuerst der NFM aktualisiert werden, der als primärer Netzwerküberwachungsserver fungiert, und anschließend der Server, der als Netzwerküberwachungsstandby fungiert. Wenn die Netzwerküberwachung nicht verwendet wird, kann das Upgrade in beliebiger Reihenfolge durchgeführt werden. NFM-Server müssen immer einzeln aktualisiert werden.

Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

NFM_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NFM 2022.11_1.274

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NFM to 2022.11_1.274. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Lizenzverwaltung auf dem NFM

Siehe NFM Node and License Management Guide.

NFM-Prüfungen nach dem Upgrade

Überprüfen Sie nach dem Upgrade den NFM-Status nach dem Start:

- healthmon -l

- showrun

- bwshowver

- mdbctl status

- Wenn die Netzwerküberwachung aktiv ist:pgctl status

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/setactiveserver.NFM.Rel_2022.11_1.274.<date-time>.log auf mögliche Aktivierungsfehler.

- Wenn auf dem NFM NetworkMonitoring ausgeführt wird, stellen Sie sicher, dass die Anwendung in der Zielversion wieder verfügbar ist.

Empfohlene NFM-Tests nach dem Upgrade

Stellen Sie sicher, dass die mit den NFM-Servern verbundenen Anwendungen Datenbanktransaktionen ausführen können.

Diese Tests sind allgemein gehalten. Führen Sie nach dem Upgrade alle weiteren Tests aus.

NFM-Server zurücksetzen

Die NFM-Wiederherstellungsprozedur ist mit der anderer Server identisch.

Die Rücksetzung von NFM auf R21.SP1 wird nicht unterstützt, da die Datenbankverschlüsselung in dieser Version nicht unterstützt wird. Wir müssen dort die Option "Umkehren" verwenden. Das Zurücksetzen eines NFM-Clusters führt zu Ausfallzeiten für Anwendungen, da die Datenbank für alle Cluster-Mitglieder angehalten werden muss, um die Datenbanksicherung wiederherzustellen.

Ausführliche Informationen zum Zurücksetzen finden Sie im NFM-Konfigurationsleitfaden.

Zurücksetzen

Falls der NFM die Prüfungen nach dem Upgrade nicht besteht, setzen Sie die vorherige Version wieder ein.

NFM_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NFM 2022.10_1.318 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NFM to 2022.10_1.318 NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

In diesem Beispiel wird wieder 2022.10_1.318 verwendet. Dies kann jedoch für jede vorherige Version ersetzt werden.

Datenbankserver (DBS)

Da das DBS eine andere Datenbank-Engine (Oracle 11g) als andere BroadWorks-Produkte ausführt, unterscheiden sich die Upgrade-Voraussetzungen und die Upgrade-Schritte sowie die Backup-Befehle erheblich vom Rest der BroadWorks-Suite. Lesen Sie diesen Abschnitt aufmerksam durch, und zögern Sie nicht, Informationskarten für das Technical Assistance Center (TAC) zu erstellen, um die erforderlichen Klarstellungen zu erhalten.

Ein Unterschied: Nur für das DBS und das DBS muss zuerst das Upgrade des Standby-Servers gestartet werden. Dies geschieht, da das DBS-Upgrade das DB-Schema nicht ändert. Dies geschieht beim Upgrade von CCReportingDBManagement. Bei einem DBS-Upgrade werden die Software und die Datenbank aktualisiert, das Schema wird jedoch nicht geändert.

Weitere Besonderheiten sind der erforderliche Neustart der Server vor der Durchführung eines Upgrades sowie das manuelle Entfernen geplanter Aufgaben (um das Upgrade nicht zu stören).

Alle erforderlichen Informationen werden in den nächsten Abschnitten ausführlich beschrieben.

Backup beider DBS

Beachten Sie die Größe von DATA mit dem dbsctl diskinfo Befehl.

bwadmin@dbs1$ dbsctl diskinfo

Disk Group Usage Summary

DATA  12.32 % used (8075/65530 MB)

FRA  11.12 % used (7286/65530 MB)

FRA LIM  11.50 % used (7156/62253 MB)

FRA  11.12 % used (7286/65530 MB) , w/o Reclaimable data

Disk Usage Summary

DATA  12.32 % used (8075/65530 MB)

FRA  11.12 % used (7286/65530 MB)

Rebalancing in progress: no

Der erforderliche Speicherplatz für die Sicherung beträgt etwa ein Siebtel davon.

Geben Sie die folgenden Befehle zum Sichern ein:

bwadmin@dbs1$ export TAG=`echo -n $(showver | grep Rel | sed -e ‘s|.*Rel_||’);echo -n “-“; date +%Y.%m.%d`

bwadmin@dbs1$ bwBackup.pl -type=Full -tag=$TAG -path= /var/broadworks/backup/$TAG -compressed

BroadWorks Database Server Backup Tool version 1.10

Checking for sufficient disk space…[DONE]

Backing up database...[DONE]

bwadmin@dbs1$

Beachten Sie, dass das Backup als Oracle-Benutzer ausgeführt wird, sodass es an einen Speicherort geschrieben werden muss, für den Oracle Schreibrechte hat. Stellen Sie sicher, dass ausreichend Speicherplatz vorhanden ist, um dies auf der Partition zu verarbeiten.

Vollständige Sicherungen können wie folgt ausgeführt werden: dieser Befehl:

bwadmin@dbs1$ bwBackup.pl -f -type=full -tag=$TAG -device=/var/broadworks/backup/$TAG

DBSObserver anhalten

Beenden Sie bei redundanten Konfigurationen die DBSObserver-Anwendung auf dem ADP während des Upgrades:

bwadmin@<ps1>$ stopbw DBSObserver

Der DBSObserver wird auf einem der ADPs bereitgestellt. Um festzustellen, ob ein bestimmter ADP den DBSObserver ausführt, sehen Sie sich die Ausgabe des  showrun Befehls auf dem ADP an.

Integritätsprüfungen vor dem Upgrade

Stellen Sie sicher, dass die Replikation ordnungsgemäß ausgeführt wird und dass die DBs mit dem dbsctl status Befehl auf beiden DBSs korrekt eingerichtet sind.

bwadmin@dbs1$ dbsctl status

Database Name                    : bwCentralizedDb0

Database Instance                : DBSI0

Database Service                 : bwCentralizedDb

Database Status (Mode)           : running (Read Write)

Database Service Status          : running

Database Role (Expected Role)    : Primary (Primary)

bwadmin@dbs2$ dbsctl status

Database Name                    : bwCentralizedDb1

Database Instance                : DBSI0

Database Service                 : bwCentralizedDb

Database Status (Mode)           : running (Read Only w/Apply)

Database Service Status          : running

Database Role (Expected Role)    : Secondary (Secondary)

Check repctl status to ensure that logs are shipping and both DBS are in sync.

bwadmin@dbs1$ repctl status

Gathering site information, please be patient...[DONE]

Redundancy/Replication Status

-----------------------------

Database Name                          = bwCentralizedDb1

Database Service Name                  = bwCentralizedDb

Dataguard Replication pid              = 26502

Primary Database                       = bwCentralizedDb0 [DBS1]

Standby Database                       = bwCentralizedDb1 [DBS2]

Primary Database Reachable             = yes

Standby Database Reachable             = yes

Replication gap summary                = OK

Replication gap details

Primary SCN: 842675099

Standby SCN: 842675095

Redo Apply Lag                         = +00 00:00:00

Estimated Redo Rate                    = 0.01 MB/s

Primary Estimated Redo Log Space       = 791991 MB

Primary Estimated Log Space Exhaustion = +916 15:45:00

Primary Redo free space condition      = NORMAL

Primary Lag vs Redo state              = N/A

Standby Estimated Redo Log Space       = 788521 MB

Standby Estimated Log Space Exhaustion = +912 15:21:40

Standby Redo free space condition      = NORMAL

Standby Lag vs Redo state              = N/A

Archive gap summary                    = N/A

Archive gap details                      N/A

Obligatorische Schritte vor dem Upgrade

Geplante Aufgaben aus dem Scheduler entfernen

Geplante Tasks wurden identifiziert, um einen Upgrade-Fehler zu verursachen und automatisch zur Quellversion zurückzukehren. Notieren Sie zunächst die Erstkonfiguration:

DBS_CLI/Maintenance/Scheduler> get

Id         Name       Date        Day    Hour    Minute

=================================================================

1 tech-support          -          -  4      33

2       cpuMon          -          -      -      5

3    healthmon          -          -      -      30(offset: 1)

4  autoCleanup          -     saturday    2      33

5       backup          -     saturday    4      03

Entfernen Sie dann die geplanten Aufgaben. Achten Sie beim Entfernen einer Aufgabe darauf, dass sich die ID-Nummern verschieben. Beginnen Sie, indem Sie zuerst die höchste ID entfernen.

DBS_CLI/Maintenance/Scheduler> del 5

DBS_CLI/Maintenance/Scheduler> del 4

DBS_CLI/Maintenance/Scheduler> del 3

DBS_CLI/Maintenance/Scheduler> del 2

DBS_CLI/Maintenance/Scheduler> del 1

Überprüfen Sie mit dem get Befehl, ob die Einträge gelöscht wurden.

Starten Sie den Server vor dem Upgrade neu (init 6)

Starten Sie jeden Server neu, bevor Sie ein Upgrade durchführen. Auch dies trägt zur Vermeidung von Upgrade-Fehlern bei. Da wir das Upgrade immer auf einem Standby-DBS-Server durchführen, hat dies keine Auswirkungen auf irgendetwas und führt nicht zu mehr Rollenwechseln als normalerweise.

Informationen zur Bestellung finden Sie im Diagramm der Upgrade-Reihenfolge. Die init 6 wird nach der Sicherung und vor der Aktivierung jedes Servers ausgeführt.

Starten Sie das Upgrade

Das DBS unterscheidet sich von allen anderen BroadWorks-Servern dadurch, dass das Standby-/sekundäre DBS zuerst aktualisiert wird. Wenn Sie mit dem derzeit aktiven Server beginnen; Es ist ein zusätzlicher Neustart/eine Rollenänderung erforderlich.

Im Standby-/sekundären Modus:

DBS_CLI/Maintenance/ManagedObjects> lock

Zur Zielversion wechseln:

DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server 2023.03_1.411

Sobald Sie fertig sind, entsperren Sie den Server:

DBS_CLI/Maintenance/ManagedObjects> unlock

Überprüfen Sie den Zustand, um sicherzustellen, dass das DBS ordnungsgemäß gestartet wurde.

Switchover des neu aufgerüsteten STANDBY/sekundären DBS auf Aktiv/Primär

Anmerkung: Führen Sie diesen Befehl auf dem neu aktualisierten Server aus (nicht auf dem DBS noch in der vorherigen Version).

bwadmin@dbs1$ peerctl ls

PEER                     Role        Status      State

===========================================================

dbs1                     PRIMARY     ACTIVE      Unlocked

dbs2                     SECONDARY   STANDBY     Unlocked

bwadmin@dbs1$ peerctl setPrimary dbs2

Setting 'dbs2' as new primary.

Switch over may take a few moments to complete, do you still want to proceed? (y/n) [y]?y

Switching over to 'bwCentralizedDb1', this may take a few moments to complete.[DONE]

Switch over completed.

bwadmin@dbs1$ peerctl ls

PEER                     Role        Status      State

===========================================================

dbs1                     SECONDARY   STANDBY     Unlocked

dbs2                     PRIMARY     ACTIVE      Unlocked

Zu diesem Zeitpunkt ist das aktualisierte DBS (dbs2) nun primär.

Prüfungen nach dem Upgrade des Datenbankservers

- Tätigen Sie einen Anruf in einem Callcenter, und rufen Sie Berichte ab, die diese Aktivität zeigen.

- Abrufen von Verlaufsberichten

- Überprüfen Sie die XSLogs auf dem AS, um zu bestätigen, dass die Daten an DBS2 gesendet werden (und nicht in der Dateiwarteschlange).

Upgrade der früheren primären Appliance (jetzt Standby)

Sperren Sie auf dem ehemaligen primären <dbs1> (jetzt im Standby-Modus):

DBS_CLI/Maintenance/ManagedObjects> lock

In Zielversion umschalten:

DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2023.03_1.411

Entsperren Sie die primäre DB1:

DBS_CLI/Maintenance/ManagedObjects> unlock

Führen Sie den Switchover als Original-Setup und den Standby als Primär durch.

Setzen Sie DBS1 mithilfe des peerctl setPrimary dbs1 Befehls wieder auf Primary (Primär).

bwadmin@dbs1$ peerctl ls

PEER                       Role        Status      State

===========================================================

dbs1                       SECONDARY   STANDBY     Unlocked

dbs2                       PRIMARY     ACTIVE      Unlocked

bwadmin@dbs1$ peerctl setPrimary dbs1

Setting 'dbs1' as new primary.

Switch over may take a few moments to complete, do you still want to proceed? (y/n) [y]?y

Switching over to 'bwCentralizedDb0', this may take a few moments to complete.[DONE]

Switch over completed.

bwadmin@dbs1$ peerctl ls

PEER                       Role        Status      State

===========================================================

dbs1                       PRIMARY     ACTIVE      Unlocked

dbs2                       SECONDARY   STANDBY     Unlocked

Planer wie zuvor zurücksetzen

Da wir die geplanten Aufgaben aus dem Scheduler entfernt haben, müssen wir sie erneut hinzufügen. Nur für den Fall, hier sind alle Standard-Timings:

DBS_CLI/Maintenance/Scheduler> add tech-support daily 4 33

DBS_CLI/Maintenance/Scheduler> add cpuMon minute 5

DBS_CLI/Maintenance/Scheduler> add healthmon minute 30 1

DBS_CLI/Maintenance/Scheduler> add autoCleanup day saturday 2 33

DBS_CLI/Maintenance/Scheduler> add backup day saturday 4 3

Prüfungen nach dem Upgrade für den primären Datenbankserver

- Tätigen Sie einen Anruf in einem Callcenter, und rufen Sie Berichte ab, die diese Aktivität zeigen.

- Abrufen von Verlaufsberichten

- Überprüfen Sie die XSLogs auf dem AS, um zu bestätigen, dass die Daten an DBS1 gesendet werden (und nicht in der Dateiwarteschlange).

Überprüfen Sie den Versand von Gesundheits-, Replikations- und Wiederholungsprotokollen:

bwadmin@dbs1$ repctl status

bwadmin@dbs1$ dbsctl status

bwadmin@dbs1$ dbsctl diskinfo

bwadmin@dbs1$ dbsctl redolog info

Führen Sie diesen Schritt für beide DBSs aus, um sicherzustellen, dass sie sich nach dem Upgrade in einem einwandfreien Zustand befinden.

Integritätsüberprüfung mithilfe des ADP

Geben Sie im ADP, der CCReportingDBManagement ausführt, folgende Befehle ein:

bwadmin@ps1$ bwcli

ADP_CLI/Applications/CCReportingDBManagement/Database/Databases/Sites> validate

Host  Name Database   Status

===========================================================

dbs01 bwCentralizedDb Primary

dbs02 bwCentralizedDb Standby

ADP_CLI/Applications/CCReportingDBManagement/Database/Schemas> validate

Name Status

===========================================================bweccr Read/Write

DBSObserver starten

Sobald beide DBSs aktualisiert wurden, starten Sie die DBSObserver-Anwendung, um das Failover zu steuern:

bwadmin@ADP1$ startbw DBSObserver

Starting DBSObserver...

Datenbankserver-Wiederherstellungsprozedur

Das allgemeine Wiederherstellungsverfahren für Database Server ähnelt dem allgemeinen Zurücksetzungsverfahren für BroadWorks, das im BroadWorks Software Management Guide beschrieben wird.

Die Hauptunterschiede sind:

- Rollback wird nicht unterstützt. Nur Zurücksetzen wird unterstützt.

- Bei redundanten Konfigurationen wird die Software zuerst am Standby-Standort zurückgesetzt.

- Nach der Software-Aktivierung muss eine nachträgliche Überprüfung (siehe Database Server > Database Server Revert Procedure > Detailed Procedure Steps > Post Revert Check) durchgeführt werden, um zu überprüfen, ob die Wiederherstellung der Datenbank ordnungsgemäß durchgeführt wurde und ob Korrekturmaßnahmen erforderlich sind.

Rollback verweigert

Jeder Versuch, ein Rollback der aktiven Softwareversion auf dem Datenbankserver durchzuführen, wird abgelehnt, wie in diesem Beispiel gezeigt:

DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2022.12_1.371

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of DBS to 2022.12_1.371. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

SW Manager initialized!

[Error] This server type does not support rollback. The revert flag is mandatory.

Detaillierte Verfahrensschritte

Die erforderlichen Schritte zum Zurücksetzen von Cisco BroadWorks auf einem Standalone-Server und auf einer redundanten Serverkonfiguration sind identisch und müssen in einer bestimmten Reihenfolge durchgeführt werden. Diese Schritte decken beide Konfigurationen ab.

1. Aktivieren Sie die alte Cisco BroadWorks-Version. Bei redundanten Konfigurationen muss der Standby-Server zuerst zurückgesetzt werden. Wenn Sie den Standby-Modus zurücksetzen, geben Sie keinen Sicherungsspeicherort an.

2. Bei redundanten Konfigurationen fahren Sie mit der Umkehr des primären Servers fort.

3. Führen Sie die Überprüfung nach dem Zurücksetzen durch.

Um die Schritte, die dem Sequenzdiagramm entsprechen, übersichtlicher zu gestalten, wird beim Zurücksetzen des Standby-Standorts B die Sicherungsdatei nicht angegeben. Wir können jedoch die Sicherungsdatei angeben, wenn wir SiteA zurücksetzen. Alternativ können wir die Sicherungsdatei im nächsten Schritt wiederherstellen. Der Schritt "Standby synchronisieren" synchronisiert dann die Daten zwischen SiteA und SiteB.

Vorgang zurücksetzen

Der Wiederherstellungsvorgang wird von der BroadWorks CLI ManagedObject-Ebene initiiert. Wie bei den anderen Servertypen kann der Sicherungsspeicherort direkt in der CLI angegeben werden, wie in diesem Beispiel gezeigt:

DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2022.12_1.371 revert /var/broadworks/backup/2022.12_1.371-2022.12.28-12.15.43

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of DBS to 2022.12_1.371. NOTE that this action will cause downtime.

Continue?

Wenn der Wiederherstellungsvorgang am Standby-Standort ausgeführt wird, geben Sie den Sicherungsspeicherort jedoch nicht an. Der Standby-Standort wird mithilfe des primären Revert-Vorgangs neu erstellt. Nach importdb.pl dem Revert-Vorgang wird der Standort automatisch vom Revert-Skript selbst resynchronisiert. Sobald die Wiederherstellung abgeschlossen ist, finden Sie in den Testergebnissen der Rückgängig-Prüfung die empfohlenen Korrekturmaßnahmen.

Wenn der Revert-Vorgang vor dem Upgrade des primären Servers ausgeführt wird, bleibt die Datenbank, die auf dem primären Server ausgeführt wird, von dem Upgrade unberührt, und der Standby-Server kann sicher auf die vorherige Version zurückgesetzt werden, ohne dass ein Wiederherstellungs- oder Neusynchronisierungsvorgang erforderlich ist.

Dieses Befehlsausgabeprotokoll zeigt die Rücksetzsequenz beim Start ohne Angabe eines Sicherungsverzeichnisses an:

DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2022.12_1.371 revert

Nach Rückgängig-Prüfung

Das Skript post revertcheck soll feststellen, ob die Datenbankwiederherstellung ordnungsgemäß durchgeführt wurde und ob Korrekturmaßnahmen erforderlich sind.  Sie muss vom neuesten BroadWorks-Release-bin-Verzeichnis ausgeführt werden, wobei der vollständige Pfad oder das Schrägstrich-Präfix (./) verwendet wird:

bwadmin@dbs01.example.com$ cd /usr/local/broadworks/DBS_Rel_2022.12_1.371/bin/

bwadmin@dbs01.example.com$ ./dbsctl validate revertcheck

The last activation completed 0d 18h 23m 39s ago.

Running database post revert checks...

Oracle version already active.

Grid version already active.

... reverting init check                               [success]

... reverting check permissions                        [skipped]

... reverting check hardware                           [skipped]

... reverting check peer time                          [skipped]

... reverting check kernel                             [skipped]

... reverting check inventory                          [skipped]

... reverting check archivelog                         [skipped]

... reverting check backup                             [skipped]

... reverting check standby count                      [skipped]

... reverting check remote versions                    [skipped]

... reverting check patch level                        [skipped]

... reverting check peer idle                          [skipped]

... reverting check node id                            [skipped]

... reverting check replication                        [success]

... reverting check peer status                        [success]

... reverting check peer name lookup                   [skipped]

... reverting check traced event                       [skipped]

... reverting check invalid objects                    [skipped]

... reverting check active tasks                       [skipped]

... reverting check supported data types               [skipped]

... reverting check dbcontrol                          [skipped]

... reverting check database status                    [skipped]

Post check...                                                         [DONE]

No corrective action necessary

Sicherung wiederherstellen

Wenn mit dem Befehl set activeSoftwareVersion server ein Sicherungsverzeichnis angegeben wurde, wird die Sicherung durch den Wiederherstellungsvorgang automatisch wiederhergestellt.

Andernfalls muss die Sicherung mithilfe des folgenden Befehls wiederhergestellt werden:

bwadmin@dbs01$ bwRestore.pl -recover -path=/var/broadworks/backup/<backup_name>

Standby synchronisieren

Wenn der Standby-Modus mit der Datenbank resynchronisiert werden muss, wird das importdb.pl Skript verwendet.

Dieser Befehl wird verwendet, um die Datenbank an Standort B erneut zu synchronisieren, wenn der primäre Standort an Standort A nicht aktualisiert wurde:

bwadmin@dbs02$ importdb.pl --peer=dbs01

Wenn Standort A aktualisiert und zurückgesetzt wurde, muss die Standby-Datenbank vom primären Standort aus neu erstellt und die Redundanz neu konfiguriert werden. Hierzu wird stattdessen der folgende Befehl verwendet:

bwadmin@dbs02$ importdb.pl --peer=dbs01 --cleanup

Die Vorgehensweise zum Zurücksetzen des DBS wird im DBS-Konfigurationsleitfaden genauer beschrieben.

Primärer Switch/Standby-Switch zurück in den Zustand vor dem Upgrade

Sobald die Wiederherstellung abgeschlossen ist, setzen Sie die Server mit dem peerctl Befehl auf den Status "Pre-Upgrade Primary/Standby" (Primär/Standby) zurück. Beispiele:

bwadmin@dbs1$ peerctl setPrimary dbs1

Wenn der DBSObserver nicht auf dem ADP ausgeführt wird, starten Sie ihn.

Netzwerk-Datenbankserver (NDS)

Stellen Sie sicher, dass bei HealthMon keine Probleme auftreten:

--------------------------------

System Health Report Page

BroadWorks Server Name: nds1

Date and time         : Thu Nov  7 05:19:16 EST 2022

Report severity       : NOTIFICATION

Server type           : NDS

Server state          : Unlock

--------------------------------

No abnormal condition detected.

--------------------------------

Backup und technischer Support

Vor einem Server-Upgrade wird empfohlen, ein vollständiges Backup durchzuführen und einen technischen Support von vor dem Upgrade zu protokollieren:

$ bwBackup.pl -type=full -file=/var/broadworks/backup/bwBackup.bak

$ tech-support >> tsup_hostname_sourceRelease.txt

Upgrade-Prüfung

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

NDS_CLI/Maintenance/Tools> upgradeCheck NDS_Rel_2022.11_1.273

NDS-Upgrade-Switch

In einem Cluster ist die Reihenfolge, in der NDSs aktualisiert werden, nicht relevant. Es ist jedoch nur jeweils ein Upgrade möglich. Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

NDS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NDS 2022.11_1.273

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NDS to 2022.11_1.273. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

NDS-Prüfungen nach dem Upgrade

Überprüfen Sie nach dem Upgrade den NDS-Status nach dem Start:

- healthmon -l

- showrun

- bwshowver

- mdbctl status

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/setactiveserver.NDS.Rel_2022.11_1.273.<date-time>.log auf mögliche Aktivierungsfehler.

Empfohlene NDS-Tests nach dem Upgrade

Stellen Sie sicher, dass die mit dem NDS verbundenen Anwendungen Datenbanktransaktionen ausführen können.

Diese Tests sind allgemein gehalten. Führen Sie nach dem Upgrade alle weiteren Tests aus.

NDS-Server zurücksetzen

Das Zurücksetzen eines NDS-Clusters führt zu Ausfallzeiten für Anwendungen, da die Datenbank für alle Cluster-Mitglieder angehalten werden muss, um das Datenbank-Backup wiederherzustellen.

Das NDS-Wiederherstellungsverfahren ist mit dem anderer Server identisch.

Zurücksetzen

Falls der NDS die Prüfungen nach dem Upgrade nicht bestehen sollte, kehren Sie zur vorherigen Version zurück:

NDS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NDS 2022.08_1.352 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NDS to 2022.08_1.352 NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

In diesem Beispiel wird wieder "2022.08_1.352" verwendet. Dies kann jedoch für jede vorherige Version ersetzt werden.

Netzwerkserver (NS)

Beachten Sie, dass die NS jetzt RI ist.

Sicherstellen, dass der HealthMon keine Probleme aufweist

--------------------------------

System Health Report Page

BroadWorks Server Name: ns1

Date and time         : Thu Oct  3 15:50:21 BST 2022

Report severity       : NOTIFICATION

Server type           : NetworkServer

Server state          : Unlock

--------------------------------

No abnormal condition detected.

--------------------------------

Backup und technischer Support

Vor einem Server-Upgrade wird empfohlen, ein Backup durchzuführen und eine Datei für den technischen Support zu protokollieren:

$ bwBackup.pl NetworkServer NS_hostname_sourceRelease.tar

$ tech-support >> tsup_hostname_sourceRelease.txt

Vor dem Upgrade

Führen Sie einen Testanruf aus, der das NS aufruft, und überprüfen Sie, ob sich eine erfolgreiche 302-Meldung im NSXSLog-Protokoll unter /var/Broadworks/logs/routingserver/ befindet.

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

NS_CLI/Maintenance/Tools> upgradeCheck NS_Rel_2022.11_1.27

Überprüfen Sie die aktuelle Anzahl der Anrufe usw., die mit dem folgenden qcurrent Befehl verwendet werden:

NS_CLI/Monitoring/Report> qcurrent

Datenbanksynchronisierung (synchcheck_basic.pl -a) auf allen nicht primären Peer-NSs überprüfen:

$ synchcheck_basic.pl -a

Primärer NS Upgrade-Switch

Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

NS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NS 2022.11_1.27

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NS to 2022.11_1.27. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Aktualisieren Sie die Datenbankstatistik, indem Sie das bwPeriodMaint.sh Skript ausführen.

$ bwPeriodMaint.sh

Prüfungen nach dem Upgrade für NS

Überprüfen Sie nach dem Upgrade den NS-Status nach dem Start.

- healthmon -l

- Es zeigt an, dass der Peer nicht synchronisiert ist, dies wird jedoch erwartet, bis das Upgrade des sekundären Geräts abgeschlossen ist.

- Wenn health mon anzeigt, dass einige Datenbankseitengrößen überschritten werden, geben Sie check_dbpages.pl networkserver modifyein.

- showrun

- bwshowver

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.log auf mögliche Aktivierungsfehler.

- Führen Sie NS-Tests aus, um sicherzustellen, dass das NS-System Anrufe ordnungsgemäß verarbeitet.

Empfohlene Tests nach dem Upgrade für NS

- Validierung der eingehenden 302-Umleitung für das Public Switched Telefone Network (PSTN)

- Die AS-Outbound-302-Umleitung validieren.

- Validierung der AS-zu-MS-Anfrage/-Antwort

- Validieren Sie den CLI-Zugriff (melden Sie sich an, und gehen Sie zu NS_CLI/System/Device/HostingNE; den Befehl get eingeben).

- Validierung des Web-Zugriffs auf die NS (falls aktiviert)

- Validieren Sie die Benutzersuche von einem ADP mithilfe der Kommunikation im NS-Modus, indem Sie sich einfach bei einem ADP anmelden.

NS-Aktivitäten nach dem Upgrade

Vergewissern Sie sich, dass das NS-System nicht so konfiguriert ist, dass ADPs die Anmeldung bei einem AS mit einer anderen Version verweigern. Legen Sie unter NS_CLI/System/Device/HostingNE> ADP-Version auf false für jede hostendeNE fest.

NS-Zurücksetzen

Falls das NS die Prüfungen nach dem Upgrade nicht bestehen sollte, kehren Sie zur vorherigen Version zurück:

NS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NS 2022.09_1.340 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NS to 2022.09_1.340. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

In diesem Beispiel wird wieder "2022.09_1.340" verwendet. Dies kann jedoch für jede vorherige Version ersetzt werden.

Da die sekundäre NS über eine aktuelle Version der Datenbank aus der Quellversion verfügt, kann die DB von dort importiert werden.

Auf der sekundären NS

$ repctl start

Auf dem primären NS

$ stopbw

$ repctl stop

$ importdb.pl networkserver <peer_ns2>

$ repctl start

$ startbw

Schalten Sie die sekundäre (und alle anderen) NS-Datenbank frei:

$ peerctl unlock

Stellen Sie sicher, dass die Replikation auf dem zurückgesetzten primären NS ausgeführt wird:

$ repctl status

Stellen Sie sicher, dass die Replikation auf allen sekundären NS-Systemen ausgeführt wird und dass die Datenbank entsperrt ist:

$ repctl status

Überprüfen Sie healthmon -l alle NS. Stellen Sie sicher, dass der gemeldete Schweregrad für alle Server NOTIFICATION lautet.

Überprüfen Sie, ob die sekundäre NS- und primäre NS-Datenbank synchronisiert sind (auf sekundärer Ebene):

$ synchcheck_basic.pl -a

Sekundärer NS-Upgrade-Switch

Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

NS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NS 2022.11_1.27

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of NS to 2022.11_1.27. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Das Skript für die Aktualisierungsstatistik muss nicht ausgeführt werden, da es vor dem Import ausgeführt wurde, der während des Upgrades der sekundären NS automatisch durchgeführt wurde.

Prüfungen nach dem Upgrade für NS

Überprüfen Sie nach dem Upgrade den NS-Status nach dem Start.

- healthmon -l

- Wenn gesund anzeigt, dass einige Datenbankseitengrößen überschritten werden, geben Siecheck_dbpages.pl networkserver modifyein.

- showrun

- bwshowver

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.log auf mögliche Aktivierungsfehler.

- Führen Sie NS-Tests aus, um sicherzustellen, dass das NS-System Anrufe ordnungsgemäß verarbeitet.

Empfohlene Tests nach dem Upgrade für NS

Durch Sperren des primären NS wird der gesamte Datenverkehr über das sekundäre Netzwerk geleitet:

- Validierung der eingehenden PSTN 302-Umleitung

- Die AS-Outbound-302-Umleitung validieren.

- Validierung der AS-zu-MS-Anfrage/-Antwort

- Validieren Sie den CLI-Zugriff (melden Sie sich an, und gehen Sie zu NS_CLI/System/Device/HostingNE; den Befehl get eingeben).

- Validierung des Web-Zugriffs auf die NS (falls aktiviert)

- Validieren Sie die Benutzersuche von einem XSP mithilfe der Kommunikation im NS-Modus, indem Sie sich einfach bei einem XSP anmelden.

- Postcluster-Tests.

- Stellen Sie sicher, dass für alle Server eine BENACHRICHTIGUNG über den Schweregrad von HealthMon-Berichten erfolgt.

- Datenbanksynchronisierung überprüfen.

$ healthmon -l

$ synchcheck_basic.pl –a

Medienserver (MS)

Stellen Sie sicher, dass bei HealthMon keine Probleme auftreten:

--------------------------------

System Health Report Page

BroadWorks Server Name: ms1

Date and time         : Thu Mar  3 11:10:53 BST 2022

Report severity       : NOTIFICATION

Server type           : MediaServer

Server state          : Unlock

--------------------------------

No abnormal condition detected.

--------------------------------

Backup und technischer Support

Vor einem Server-Upgrade wird empfohlen, ein Backup durchzuführen und einen technischen Support von vor dem Upgrade zu protokollieren. In den Mitgliedstaaten wäre dies mit folgenden Faktoren nicht möglich:

$ bwAutoBackup.sh

$ tech-support >> tsup_hostname_sourceRelease.txt

Vor dem Upgrade

Führen Sie einen Testanruf aus, der die interaktive Sprachsteuerung (IVR) aufruft, oder rufen Sie eine Voicemail ab, und stellen Sie sicher, dass sie wie erwartet funktioniert und der Anruf in den Protokollen angezeigt wird.

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

MS_CLI/Maintenance/Tools> upgradeCheck MS_Rel_2022.11_1.273

Überprüfen Sie die aktuelle Anzahl der Ports, die mit dem qcurrent Befehl verwendet werden.

MS_CLI/Monitoring/Report> qcurrent

Bevor Sie mit der Aktivierung der neuen Version beginnen, setzen Sie den MS-Status in der NS auf "offline", damit die Medien nicht mehr vom NS gesendet werden.

NS_CLI/System/Device/ResourceNE> set ms1 state OffLine

...Done

NS_CLI/System/Device/ResourceNE> get

About to filter through 2 entries. Continue?

Please confirm (Yes, Y, No, N): y

Retrieving data... Please wait...

Resource NE Type Location Stat Cost Stat Weight Poll OpState State Dflt Dflt Cost Dflt Weight Services

======================================================================================================================

ms1    ms    1847744        1         99  false enabled OffLine true      1       99       all

ms2    ms    1847744        1         99  false enabled OnLine  true      1       99       all

2 entries found.

NS_CLI/System/Device/ResourceNE>

MS Upgrade-Switch

Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

MS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server MS 2022.11_1.273

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of MS to 2022.11_1.273. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

MS-Prüfungen nach dem Upgrade

Überprüfen Sie nach dem Upgrade den MS-Status nach dem Start, und vergewissern Sie sich, dass eine Zurücksetzung für Voicemail und Voicemail erfolgt ist.

- healthmon -l

- showrun

- bwshowver

- set back the MS state to onLine in NS to receive the media

Empfohlene MS-Tests nach dem Upgrade

- Validieren Sie die erfolgreiche Einzahlung und den Abruf von Voicemail.

- Validierung der erfolgreichen IVR-Interaktion

- Validieren eines erfolgreichen Dreiergesprächs

Diese Tests sind allgemein gehalten. Führen Sie nach dem Upgrade alle weiteren Tests aus.

MS Zurücksetzen

Falls die MS die Prüfungen nach dem Upgrade nicht bestehen sollte, kehren Sie zur vorherigen Version zurück.

MS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server MS 2022.08_1.350 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of MS to 2022.08_1.350. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Im vorherigen Beispiel wird der Wert auf 2022.08_1.350 zurückgesetzt. Dies kann jedoch für jede vorherige Version ersetzt werden.

Anwendungsserver (AS)

Sicherstellen, dass der HealthMon keine Probleme aufweist

--------------------------------

System Health Report Page

BroadWorks Server Name: as1

Date and time         : Thu Oct  3 15:50:21 BST 2022

Report severity       : NOTIFICATION

Server type           : AppServer

Server state          : Unlock

--------------------------------

No abnormal condition detected.

-------------------------------

- Überprüfen Sie die Protokolle, um sicherzustellen, dass beide ASs Anrufe verarbeiten (das Erzwingen neuer Anrufe beim sekundären AS kann durch Sperren von AS1 erfolgen).

- Validieren Sie den Webzugriff über Webserver und jedes AS.

Backup und technischer Support

Es wird empfohlen, vor dem Upgrade eine Sicherung durchzuführen und einen technischen Support von zu protokollieren.

$ bwBackup.pl AppServer AS_hostname_sourceRelease.tar

$ tech-support >> tsup_hostname_sourceRelease.txt

Vor dem Upgrade

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden.

AS_CLI/Maintenance/Tools> upgradeCheck AS_Rel_2023.03_1.411

Anmerkung: Wenn der UpgradeCheck aufgrund von Dateien im Verzeichnis /var/Broadworks/eccr oder /var/Broadworks/ecl fehlschlägt, warten Sie, bis eine "Lock Force" von der bwcli ausgeführt wird. Dadurch werden die Dateien innerhalb weniger Minuten in das DBS gelöscht.

Überprüfen Sie die Datenbanksynchronisierung (synchcheck_basic.pl -a) auf dem sekundären AS:

$ synchcheck_basic.pl -a

Legen Sie den Wert "extensionTimeInSeconds" auf 10800 (drei Stunden) fest, um der für das Upgrade des Servers reservierten Zeit zu entsprechen:

AS_CLI/System/Registration> set extensionTimeInSeconds 10800

Die typische Einstellung hierfür ist, wenn kein Upgrade auf 2400 gemäß Systemkonfigurationshandbuch durchgeführt wird.

Bei der Replikation wird diese Änderung auf die verbleibenden Server im Cluster übertragen.

Löschen Sie den Sicherungsvorgang aus dem Scheduler:

AS_CLI/Maintenance/Scheduler> get

Id         Name       Date        Day    Hour    Minute

=================================================================

5       backup          -     saturday    4      03

Wenn die Sicherung während des Upgrades ausgelöst wird, führt sie bei der Aktivierung zu Problemen:

AS_CLI/Maintenance/Scheduler> del 5

Primärer AS sperren

Primäres AS sperren, neue Anrufe durch das sekundäre AS führen dazu, dass die Anzahl der aktiven Anrufe auf dem primären AS vor Ausführung des Switches unterbrochen wird (Switching oder Lock Force führen dazu, dass die aktiven Anrufe beendet werden):

AS_CLI/Maintenance/ManagedObjects> lock

+++ WARNING +++ WARNING +++ WARNING +++

This command will lock the server. Note that this action could cause downtime.

The server state is persisted across server restarts and upgrade.

A server in "Locked" state will need to be manually unlocked after a server

restart or upgrade. Continue?

Please confirm (Yes, Y, No, N): y

...Done

Überprüfen Sie anschließend die Anzahl der Anrufe auf dem AS mithilfe des folgenden qcurrent  Befehls:

AS_CLI/Monitoring/Report> qcurrent

Primärer AS-Upgrade-Switch

Sobald die Anzahl der Anrufe auf ein akzeptables Niveau gesunken ist, starten Sie das Upgrade mit:

AS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server AS 2023.03_1.411

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of AS to 2023.03_1.411  . NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Sobald Sie fertig sind, entsperren Sie den Server:

AS_CLI/Maintenance/ManagedObjects> unlock

Aktualisieren Sie die DB-Statistik mit bwPeriodMaint.sh:

$ bwPeriodMaint.sh

Dieser Befehl gibt keine Ausgabe zurück.

Da wir den Sicherungsvorgang aus dem Scheduler gelöscht haben, müssen wir ihn nach dem Upgrade wieder hinzufügen. Dies ist der empfohlene Wert. Wir müssen sie wieder zu dem Wert hinzufügen, der vor dem Upgrade konfiguriert wurde:

AS_CLI/Maintenance/Scheduler> add backup day saturday 4 3

Primäre AS-Aktionen nach dem Upgrade

AS-Prüfungen nach dem Upgrade

Überprüfen Sie nach dem Upgrade den AS-Status nach dem Start, und überprüfen Sie die Registrierungen und Anrufe.

- healthmon -l

- Es zeigt an, dass der Peer nicht synchronisiert ist, dies wird jedoch erwartet, bis das Upgrade des sekundären Geräts abgeschlossen ist.

- showrun

- bwshowver

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411 .<date-time>.log auf mögliche Aktivierungsfehler.

- Führen Sie AS-Tests aus, um sicherzustellen, dass dieses AS Anrufe ordnungsgemäß verarbeitet.

Empfohlene Tests nach dem Upgrade

- Validieren Sie ausgehende SIP-Anrufe.

- Validierung der ausgehenden MGCP-Anrufe (Media Gateway Control Protocol)

- Validieren eingehender Anrufe vom PSTN an SIP-Benutzer

- Validieren eingehender Anrufe vom PSTN zum MGCP-Benutzer.

- Validierung von Abgang/Abruf von Voicemail (Voiceportal)

- Validierung der CommPilot-Originationen/-Terminierungen

- Validieren Sie den CLI-Zugriff (gehen Sie zu AS_CLI/System/Alias, und verwenden Sie den Befehl get).

- Validierung des direkten Webzugriffs auf das AS

Lokalisierte Sprachansagen

Beim Upgrade auf R25 werden die benutzerdefinierten Audio-Aufforderungen automatisch aus der Quellversion kopiert. Siehe Abschnitt 4.5 der Funktionsbeschreibung.

AS-Zurücksetzen

Wenn das AS die Prüfungen nach dem Upgrade nicht besteht, kehren Sie zur vorherigen Version zurück.

AS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server AS 2022.08_1.354 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of AS to 2022.08_1.354. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

In diesem Beispiel wird wieder "2022.08_1.354" verwendet. Dies kann jedoch für jede vorherige Version ersetzt werden.

Da das sekundäre AS über eine aktuelle Version der Datenbank verfügt, importieren Sie die DB von dort.

Sekundäres AS:

$ repctl start

Auf primärem AS:

$ stopbw

$ repctl stop

$ importdb.pl appserver

appserver

$ repctl start

$ startbw

Sekundärdatenbank entsperren:

$ peerctl unlock

Stellen Sie sicher, dass die Replikation auf dem zurückgesetzten primären AS ausgeführt wird:

$ repctl status

Überprüfen Sie, ob die Replikation auf dem sekundären AS ausgeführt wird und die Datenbank entsperrt ist:

$ repctl status

$ peerctl unlock

Aktivieren Sie healthmon -l alle AS. Stellen Sie sicher, dass der gemeldete Schweregrad für alle Server NOTIFICATION lautet.

Überprüfen Sie, ob die Datenbanken des sekundären AS und des primären AS synchronisiert sind (auf sekundärem AS):

$ synchcheck_basic.pl -a

Sekundärer AS-Upgrade-Switch

Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

AS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server AS 2023.03_1.411

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of AS to 2023.03_1.411. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Aktualisieren Sie die Datenbankstatistik, indem Sie das folgende bwPeriodMaint.sh Skript ausführen:

$ bwPeriodMaint.sh

Sekundäre AS-Aktionen nach dem Upgrade

AS-Prüfungen nach dem Upgrade

Überprüfen Sie nach dem Upgrade den AS-Status nach dem Start, und überprüfen Sie die Registrierungen und Anrufe.

- healthmon -l

- showrun

- bwshowver

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411.<date-time>.log auf mögliche Aktivierungsfehler.

- Führen Sie AS-Tests aus, um sicherzustellen, dass das AS Anrufe ordnungsgemäß verarbeitet.

Empfohlene Tests nach dem Upgrade

- Sperren des primären AS, um neue Anrufe beim sekundären AS zu erzwingen

- Validieren Sie ausgehende SIP-Anrufe.

- Validierung der ausgehenden MGCP-Anrufe

- Validieren eingehender Anrufe vom PSTN an SIP-Benutzer

- Validieren eingehender Anrufe vom PSTN zum MGCP-Benutzer.

- Validierung von Abgang/Abruf von Voicemail (Voiceportal)

- Validierung der CommPilot-Originationen/-Terminierungen

- Validieren Sie den CLI-Zugriff (gehen Sie zu AS_CLI/System/Alias, und verwenden Sie den Befehl get).

- Validierung des direkten Webzugriffs auf das AS

Test nach dem Cluster

- Stellen Sie sicher, dass für alle Server eine BENACHRICHTIGUNG über den Schweregrad von HealthMon-Berichten erfolgt.

- Datenbanksynchronisierung überprüfen:

$ healthmon -l

$ synchcheck_basic.pl –a

Dienststeuerfunktion (Service Control Function, SCF)

Stellen Sie sicher, dass bei HealthMon keine Probleme auftreten:

--------------------------------

System Health Report Page

BroadWorks Server Name: scf1

Date and time         : Fri Nov  8 11:30:38 GMT 2022

Report severity       : NOTIFICATION

Server type           : ServiceControlFunction

Server state          : Unlock

--------------------------------

No abnormal condition detected.

--------------------------------

- Überprüfen Sie die Protokolle, um sicherzustellen, dass der SCF Anrufe verarbeitet.

Backup und technischer Support

Vor einem Server-Upgrade wird empfohlen, ein Backup durchzuführen und einen technischen Support von vor dem Upgrade zu protokollieren. Dies geschieht mit:

$ bwAutoBackup.sh

$ tech-support >> tsup_hostname_sourceRelease.txt

Vor dem Upgrade

Testen Sie Anrufe aus dem Mobilnetz, um sicherzustellen, dass die aktuelle Funktion normal funktioniert.

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

SCF_CLI/Maintenance/Tools> upgradeCheck SCF_Rel_2023.03_1.411

Wenn eine redundante Konfiguration vorliegt, den Server sperren, um Anrufe an die andere SCF zu erzwingen:

SCF_CLI/Maintenance/ManagedObjects> lock

SCF-Upgrade-Switch

Sobald die Anzahl der Anrufe auf ein akzeptables Niveau gesunken ist, starten Sie das Upgrade mit:

SCF_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server SCF 2023.03_1.411

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of SCF to 2023.03_1.411. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

Entsperren Sie nach Abschluss des Vorgangs den Server, und führen Sie die Testanrufe aus:

SCF_CLI/Maintenance/ManagedObjects> unlock

SCF-Prüfungen nach dem Upgrade

Überprüfen Sie nach dem Upgrade die SS7-Protokolle auf einen guten Start:

- healthmon -l

- showrun

- bwshowver

- Überprüfen Sie die Datei /var/broadcast/logs/maintenance/setactiveserver.SCF.Rel_2023.03_1.411.<date-time>.log auf mögliche Aktivierungsfehler.

- Führen Sie Tests durch, um sicherzustellen, dass dieser SCF Anrufe ordnungsgemäß verarbeitet.

- Bestätigung, dass Anrufe vom mobilen Netzwerk zum BroadWorks-Kern wie vor dem Upgrade funktionieren.

SCF-Server zurücksetzen

Falls der SCF die Prüfungen nach dem Upgrade nicht bestehen sollte, kehren Sie zur vorherigen Version zurück:

SCF_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server SCF 2022.10_1.313 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of SCF to 2022.10_1.313. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

In diesem Beispiel wird wieder 2022.10_1.313 verwendet. Dies kann jedoch durch eine frühere Version ersetzt werden.

Application Delivery Platform (ADP)

Stellen Sie sicher, dass bei HealthMon keine Probleme auftreten:

--------------------------------

System Health Report Page

BroadWorks Server Name: adp1

Date and time         : Fri Nov  8 11:30:38 GMT 2022

Report severity       : NOTIFICATION

Server type           : ApplicationDeliveryPlatform

Server state          : Unlock

--------------------------------

No abnormal condition detected.

--------------------------------

Backup und technischer Support

Vor einem Server-Upgrade wird empfohlen, ein Backup durchzuführen und einen technischen Support von vor dem Upgrade zu protokollieren. Dies würde durch Folgendes erreicht:

$ bwAutoBackup.sh

$ tech-support >> tsup_hostname_sourceRelease.txt

Vor dem Upgrade

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2022.10_1.313

Sperren des Servers vor der Aktivierung der neuen Softwareversion:

ADP_CLI/Maintenance/ManagedObjects> lock

Bereitstellung aufheben und ECLQuery-Anwendung deaktivieren beim Wechsel von ADP/PS auf R23 zu RI

Bevor wir den ADP auf die neueste RI aktualisieren, müssen wir die ECLQuery-Anwendung auf den NDS migrieren, WENN die ECLQuery-Anwendung auf dem R23-Quellsystem für ADP/PS ausgeführt wird. Weitere Informationen finden Sie unter Erweiterte Anrufprotokollmigration vom Datenbankserver zum Netzwerkdatenbankserver - Funktionsbeschreibung.

ADP_CLI/Maintenance/ManagedObjects> undeploy application /ECLQuery

ADP_CLI/Maintenance/ManagedObjects> deactivate application /ECLQuery

Andernfalls wird nach der Aktivierung der neuen Version ein Alarm "bwCentralizedDatabaseListenerFailure" auf dem ADP angezeigt.

Laden Sie die ADP RI/RA-Anwendungen entsprechend der bereitgestellten Anwendungen auf die Quellversion hoch.

Für den ADP BroadWorks-Server müssen die RI/RA-Versionen der Anwendungen, die derzeit auf der Quellversion installiert sind, von Cisco.com heruntergeladen werden. Führen Sie diese Aktionen aus, um die Liste der erforderlichen Anwendungen zu erhalten.

Geben Sie im ADP Folgendes ein:

$ bwshowver

ADP version Rel_2022.11_1.273

Applications Info:

- OpenClientServer version 2022.11_1.273

- WebContainer version 2022.11_1.273

- OCIOverSoap version 2022.11_1.273 context path /webservice

- CommPilot version 2022.11_1.273 context path /

- Xsi-Actions version 2022.11_1.273 context path /com.broadsoft.xsi-actions

- Xsi-Events version 2022.11_1.273 context path /com.broadsoft.xsi-events

- Xsi-VTR version 2022.11_1.273 context path /vtr

- OCIFiles version 2022.11_1.273 context path /ocifiles

- BroadworksDms version 2022.11_1.273 context path /dms

- AuthenticationService version 2022.11_1.273 context path /authservice

Alle Anwendungen, die nach den "Anwendungsinformationen" aufgelistet werden, sind Anwendungen, die auf dem ADP bereitgestellt werden und die ein Herunterladen der ADP-kompatiblen Versionen von Cisco.com erfordern. Laden Sie die aktuellen Versionen herunter. Anwendungsbeispiele auf Basis des vorherigen Beispiels:

OCS_2023,01_1,193.bwar

OCIOverSoap_2023,01_1,193.bwar

XSI-Aktionen-24_2023.01_1.010.bwar

XSI-Ereignisse-24_2023,01_1,010.bwar

CommPilot-24_2023,01_1,010.bwar

XSI-VTR-24_2023,01_1,010,bWar

OCIFiles_2023,01_1,010.bwar

dms_2023,01_1,193.bwar

Kopieren Sie die heruntergeladenen Dateien bwar/war in den ADP und legen Sie sie im Verzeichnis /usr/local/Broadworks/apps ab:

$ cd <bwar / war directory location>

$ cp OCS_2023.01_1.193.war /usr/local/broadworks/apps/

$

Der Rest des Upgrades ist ein normales BroadWorks-Upgrade.

Vor dem Upgrade

Führen Sie das upgradeCheck-Tool aus, um sicherzustellen, dass keine Warnungen ausgegeben werden:

ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2023.03_1.411

ADP-Upgrade-Switch

Starten Sie das Upgrade, indem Sie den folgenden Befehl eingeben:

ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server ADP 2023.03_1.411

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of ADP to 2023.03_1.411. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

ADP-Aktionen nach dem Upgrade

Upgrades von Anwendungen

Die WebContainer-Anwendung wird automatisch aktualisiert Die anderen Anwendungen lassen sich in zwei Typen unterteilen: Cisco BroadWorks-Anwendungen und Webanwendungen. Das Upgrade-Verfahren hängt davon ab, ob es sich um eine Cisco BroadWorks-Anwendung oder eine Webanwendung handelt.

- Cisco BroadWorks-Anwendungen werden als BroadWorks-Archivdatei (.bwar) gepackt.

- Webanwendungen, als Web-ARchive-Datei (.war) verpackt.

Geben Sie den qbw Befehl ein, um festzustellen, welche Version für die einzelnen Anwendungen derzeit aktiv ist, und den bereitgestellten Kontextpfad anzuzeigen.

Webanwendungen aktualisieren

Webanwendungen werden aktualisiert, indem die aktuelle Version deaktiviert und die Bereitstellung wieder aufgehoben wird. Anschließend wird die neue Version aktiviert und bereitgestellt:

ADP_CLI/Maintenance/ManagedObjects> undeploy application /callcenter

ADP_CLI/Maintenance/ManagedObjects> deactivate application /callcenter

ADP_CLI/Maintenance/ManagedObjects> activate application BWCallCenter 2023.04_1.150 /callcenter

ADP_CLI/Maintenance/ManagedObjects> deploy application /callcenter

Upgrade von Cisco BroadWorks-Anwendungen

Cisco BroadWorks-Anwendungen werden mithilfe des  set activeSoftwareVersion application  Befehls bwcli aktualisiert.

Weitere Informationen finden Sie in den Versionshinweisen zu Anwendungen und im Konfigurationsleitfaden für die Plattform zur Anwendungsbereitstellung.

ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion application LoadBalancer 2023.02_1.090

+++ WARNING +++ WARNING +++ WARNING +++ Upgrading an application will cause downtime for the targeted component. Continue?

Please confirm (Yes, Y, No, N): y

--> Stopping application LoadBalancer <--

Stopping [done]

BroadWorks SW Manager upgrading LoadBalancer to version 2023.02_1.090 ...Done

ADP-Anwendungen zurücksetzen

Wenn die Anwendung aus irgendeinem Grund auf eine vorherige Version zurückgesetzt werden muss, ähnelt der Prozess einem Upgrade. Konfigurationsänderungen, die nach dem Upgrade und vor dem Rollback durchgeführt wurden, gehen nach dem Rollback verloren, da sie an der nicht aktiven Softwareversion vorgenommen wurden.

Rollback für Webanwendungen

Webanwendungen werden zurückgesetzt, indem die aktuelle Version deaktiviert und die Bereitstellung wieder aufgehoben wird. Anschließend wird die neue Version aktiviert und bereitgestellt:

ADP_CLI/Maintenance/ManagedObjects> undeploy application /callcenter

ADP_CLI/Maintenance/ManagedObjects> deactivate application /callcenter

ADP_CLI/Maintenance/ManagedObjects> activate application BWCallCenter 2023.04_1.150 /callcenter

ADP_CLI/Maintenance/ManagedObjects> deploy application /callcenter

Rollback für Cisco BroadWorks-Anwendungen

Cisco BroadWorks-Anwendungen werden mithilfe des folgenden Befehls von der bwcli-  set activeSoftwareVersion application  zurückgesetzt:

ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion application LoadBalancer 2020.09_1.090

+++ WARNING +++ WARNING +++ WARNING +++ Upgrading an application will cause downtime for the targeted component. Continue?

Please confirm (Yes, Y, No, N): y

--> Stopping application LoadBalancer <--

Stopping [done]

BroadWorks SW Manager upgrading LoadBalancer to version 2020.09_1.090 ...Done

Prüfungen nach dem Upgrade für ADP

Überprüfen Sie nach dem Upgrade die Protokolle auf einen ordnungsgemäßen Start, und melden Sie sich wie zuvor bei der GUI an.

- healthmon -l

- showrun

- bwshowver

- Prüfen Sie die Datei /var/Broadworks/logs/maintenance/setactiveserver.ADP.Rel_2023.03.0_1.1411.<date-time>.log auf mögliche Aktivierungsfehler.

Empfohlene ADP-Tests nach dem Upgrade

- Überprüfen der Anmeldung auf Administratorebene

- Überprüfen der Anmeldung auf Benutzerebene

- Validieren Sie die CommPilot Call Manager-Funktionalität.

- Validierung der Funktionen des Anrufsteuerungsclients (z. B. BroadWorks Assistant-Enterprise) und des Operations Support System (OSS)/Open Client Interface (OCI)

- Überprüfen Sie, ob die OCS-Proxy-Bereitstellung (Open Client Server) für das AS oder NS ordnungsgemäß funktioniert.

Diese Tests sind allgemein gehalten. Führen Sie nach dem Upgrade alle weiteren Tests aus.

ADP-Server zurücksetzen

Wenn der ADP die Prüfung nach dem Upgrade nicht besteht, kehren Sie zur vorherigen Version zurück:

ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server ADP 2022.10_1.313 revert

+++ WARNING +++ WARNING +++ WARNING +++

This command will change the active software version of ADP to 2022.10_1.313. NOTE that this action will cause downtime.

Continue?

Please confirm (Yes, Y, No, N): y

In diesem Beispiel wird wieder 2022.10_1.313 verwendet. Dies kann jedoch durch eine frühere Version ersetzt werden.