BroadWorks Server R25-Upgrade-Verfahren
Einleitung
In diesem Dokument wird die allgemeine Upgrade-Methode (Method Of Procedure, MOPP) für das Upgrade von BroadWorks-Servern beschrieben, die vom BroadWorks-Upgrade-Team von anderen offiziellen Dokumentationsquellen eingehalten wird.
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
- Versionshinweise für Version 25.0
- AS Release 24.0 - Versionshinweise
Wenden Sie sich für zusätzlichen Upgrade-Support an das Upgrade-Team unter bwupgrade@cisco.com.
Versionshinweise
Lesen Sie vor dem Upgrade die Versionshinweise für die Zielversion in Cisco BroadWorks Documentation Guide Release 25. Messen Sie die potenziellen Auswirkungen mit den angegebenen Änderungen.
Wenn das Upgrade auf eine Version mehr als eine größere Nummer als die aktuelle Version umfasst (z. B. das Upgrade von R23 auf R25), lesen Sie die Versionshinweise der dazwischen liegenden Version(en) (in diesem Beispiel R24).
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.
Führen Sie beim Upgrade von BroadWorks-Servern die folgenden grundlegenden Schritte aus:
- Sichern Sie den Server.
- Installieren Sie das neueste RI-Installationspaket (Release Independent). Der swmanager ist im RI-Paket enthalten.
- Installieren Sie die Lizenz für die Zielversion.
- 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 kann hilfreich sein, 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:
- Es ist ausreichend Speicherplatz vorhanden, um Backups durchzuführen, die neuen Binärdateien zu installieren und ein Upgrade durchzuführen.
- Jeder Server kann Pakete installieren.
- Das Betriebssystem ist mit der Zielversion kompatibel.
- Der pre-InstallCheck wurde auf jedem Server ausgeführt und alle Warnungen oder Fehler wurden behoben.
- Das System befindet sich in einem Zustand.
- Es wurden die entsprechenden Lizenzen erworben.
- 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 werden nicht zur Verfügung gestellt. 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 haben ein anderes Format als das Standardformat Rel_25.0_1.944. Dieses RI-Format lautet: Server_Rel_yyyy.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 das qversions aus der bwcli heraus, um sicherzustellen, dass es vorhanden ist. Beachten Sie, dass der Status Installed (nicht Active).
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 den uninstall-bwserver.pl Skript.
$ 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 können sich die Lizenzdateien in mehreren ZIP-Dateien befinden. 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
Führen Sie das UpgradeCheck-Tool aus
Führen Sie upgradeCheck aus der bwcli heraus und vergewissern Sie sich, dass es keine Warnungen gibt.
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 -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
In einem Cluster ist die Reihenfolge, in der NFM-Server aktualisiert werden, nicht relevant. Führen Sie jedoch nacheinander Upgrades durch.
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): yLizenzverwaltung 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 -lshowrunbwshowvermdbctl 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): yIn 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. Auf das Upgrade-Sequenzdiagramm folgen die detaillierten Schritte und Befehle für die einzelnen Schritte.
Backup beider DBS
Beachten Sie die Größe der DATEN mit dem dbsctl diskinfo aus.
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 mit folgendem Befehl ausgeführt werden:
bwadmin@dbs1$ bwBackup.pl -f -type=full -tag=$TAG -device=/var/broadworks/backup/$TAGDBSObserver 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 auf dem ADP-Gerät.
Integritätsprüfungen vor dem Upgrade
Stellen Sie sicher, dass die Replikation ausgeführt wird und fehlerfrei ist und dass die DBs korrekt mit dem dbsctl status auf beiden DBSs.
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 03Entfernen 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
Vergewissern Sie sich, dass die Einträge mit dem get aus.
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 aktuell aktiven Server beginnen, 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
Hinweis: Führen Sie diesen Befehl auf dem neu aktualisierten Server aus (nicht auf dem DBS, der sich noch in der vorherigen Version befindet).
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> lockIn Zielversion umschalten:
DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2023.03_1.411Entsperren Sie die primäre DB1:
DBS_CLI/Maintenance/ManagedObjects> unlockFühren Sie den Switchover als Original-Setup und den Standby als Primär durch.
Setzen Sie DBS1 mithilfe des peerctl setPrimary dbs1 aus.
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 3Prü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 infoFü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 folgende:
- 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.
- 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.
- Bei redundanten Konfigurationen fahren Sie mit der Umkehr des primären Servers fort.
- 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 importdb.pl nach dem Wiederherstellungsvorgang oder automatisch durch das Wiederherstellungsskript 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 revertNach 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 necessarySicherung 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, 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=dbs01Wenn 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 --cleanupDie 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, verwenden Sie die peerctl , um die Server auf den Status "Pre-Upgrade Primary/Standby" zurückzusetzen. Beispiele:
bwadmin@dbs1$ peerctl setPrimary dbs1Wenn 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 -full -file=/var/broadworks/backup/bwBackup.bak
$ tech-support >> tsup_hostname_sourceRelease.txtUpgrade-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.273NDS-Upgrade-Switch
In einem Cluster ist die Reihenfolge, in der NDSs aktualisiert werden, nicht relevant. Führen Sie jedoch jeweils nur ein Upgrade durch. 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): yNDS-Prüfungen nach dem Upgrade
Überprüfen Sie nach dem Upgrade den NDS-Status nach dem Start:
healthmon -lshowrunbwshowvermdbctl 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): yIn 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.txtVor 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 qcurrent command:
NS_CLI/Monitoring/Report> qcurrentDatenbanksynchronisierung überprüfen (synchcheck_basic.pl -a) auf allen nicht primären Peer-NSs:
$ synchcheck_basic.pl -aPrimä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): yAktualisieren Sie die Datenbankstatistik, indem Sie den bwPeriodMaint.sh Skript.
$ bwPeriodMaint.shPrü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 gesund anzeigt, dass einige Datenbankseitengrößen überschritten werden, geben Sie Folgendes ein:
check_dbpages.pl networkserver modify.
showrunbwshowver- Ü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; geben Sie den Befehl get ein).
- 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): yIn 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 startAuf dem primären NS
$ stopbw
$ repctl stop
$ importdb.pl networkserver <peer_ns2>
$ repctl start
$ startbwSchalten Sie die sekundäre (und alle anderen) NS-Datenbank frei:
$ peerctl unlockStellen Sie sicher, dass die Replikation auf dem zurückgesetzten primären NS ausgeführt wird:
$ repctl statusStellen Sie sicher, dass die Replikation auf allen sekundären NS-Systemen ausgeführt wird und dass die Datenbank entsperrt ist:
$ repctl statusÜberprüfen healthmon -l auf allen NSs. 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 -aSekundä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): yDas 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 Sie Folgendes ein:
check_dbpages.pl networkserver modify.
- Wenn gesund anzeigt, dass einige Datenbankseitengrößen überschritten werden, geben Sie Folgendes ein:
showrunbwshowver- Ü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; geben Sie den Befehl get ein).
- 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 –aMedienserver (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.txtVor 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 aus.
MS_CLI/Monitoring/Report> qcurrentMS 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): yMS-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 -lshowrunbwshowver
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): yIm 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.txtVor 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
Hinweis: 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 -aLegen 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 10800Die 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 03Wenn die Sicherung während des Upgrades ausgelöst wird, kann sie bei der Aktivierung zu Problemen führen:
AS_CLI/Maintenance/Scheduler> del 5Primä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 qcurrent command:
AS_CLI/Monitoring/Report> qcurrentPrimä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): ySobald Sie fertig sind, entsperren Sie den Server:
AS_CLI/Maintenance/ManagedObjects> unlockDB-Statistiken aktualisieren mit bwPeriodMaint.sh:
$ bwPeriodMaint.shDieser 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 3Primä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.
showrunbwshowver- Ü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): yIn 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 startAuf primärem AS:
$ stopbw
$ repctl stop
$ importdb.pl appserver
appserver
$ repctl start
$ startbwSekundärdatenbank entsperren:
$ peerctl unlockStellen 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Überprüfen healthmon -l auf allen ASs. 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 -aSekundä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): yAktualisieren Sie die Datenbankstatistik, indem Sie den bwPeriodMaint.sh Skript:
$ bwPeriodMaint.shSekundä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 -lshowrunbwshowver- Ü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 –aDienststeuerfunktion (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.txtVor 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.411Wenn eine redundante Konfiguration vorliegt, den Server sperren, um Anrufe an die andere SCF zu erzwingen:
SCF_CLI/Maintenance/ManagedObjects> lockSCF-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): yEntsperren Sie nach Abschluss des Vorgangs den Server, und führen Sie die Testanrufe aus:
SCF_CLI/Maintenance/ManagedObjects> unlockSCF-Prüfungen nach dem Upgrade
Überprüfen Sie nach dem Upgrade die SS7-Protokolle auf einen guten Start:
healthmon -lshowrunbwshowver- Ü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): yIn 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.txtVor 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.313Sperren des Servers vor der Aktivierung der neuen Softwareversion:
ADP_CLI/Maintenance/ManagedObjects> lockBereitstellung 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 /ECLQueryAndernfalls 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 /authserviceAlle 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, die auf dem vorherigen Beispiel basieren:
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.411ADP-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): yADP-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 qbw -Befehl, um zu sehen, welche Version für die einzelnen Anwendungen derzeit aktiv ist, und um 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 /callcenterUpgrade von Cisco BroadWorks-Anwendungen
Ein Upgrade der Cisco BroadWorks-Anwendungen von der bwcli mithilfe des set activeSoftwareVersion application aus.
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 ...DoneADP-Anwendungen zurücksetzen
Wenn die Anwendung aus irgendeinem Grund auf eine vorherige Version zurückgesetzt werden muss, ähnelt der Prozess einem Upgrade. Ein wichtiger Punkt ist, dass einige Änderungen verloren gehen können, nachdem der Rollback-Vorgang ausgeführt wurde (z. B. Konfigurationsänderungen), da sich die resultierende aktive Anwendung im Zustand vor dem Upgrade befindet.
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 set activeSoftwareVersion application command:
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 ...DonePrü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 -lshowrunbwshowver- 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): yIn diesem Beispiel wird wieder 2022.10_1.313 verwendet. Dies kann jedoch durch eine frühere Version ersetzt werden.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
21-Jul-2023 |
Erstveröffentlichung |
Feedback