Procedura di aggiornamento dei server BroadWorks R25

Introduzione

In questo documento viene descritto il metodo di aggiornamento generico (MOP, Generic Upgrade Method Of Procedure) per l'aggiornamento dei server BroadWorks in conformità con quanto stabilito dal team di aggiornamento di BroadWorks da altre fonti di documentazione ufficiali.

I documenti di riferimento sono disponibili nella guida alla documentazione di Cisco BroadWorks, versione 25. Fare riferimento ai seguenti documenti principali:

• Guida alla gestione del software
• Guida alla configurazione del sistema
• Guida alla manutenzione
• Note sulla release 25.0
• Note sulla release di AS release 24.0

Per ulteriore supporto per l'aggiornamento, contattare il team di aggiornamento all'indirizzo bwupgrade@cisco.com.

Note sulla release

Prima di eseguire l'aggiornamento, consultare le note sulla versione di destinazione riportate nella guida alla documentazione di Cisco BroadWorks versione 25. Misurare l'impatto potenziale con le modifiche rilevate.

Se si esegue l'aggiornamento a una release con più di un numero principale superiore a quello della release corrente (ad esempio, se si esegue l'aggiornamento da R23 a R25), esaminare le note sulla release della release o delle release comprese tra (R24 in questo esempio).

Gli indirizzi possono essere trovati nella pagina della documentazione Cisco o tramite i collegamenti forniti.

Procedure standard

Ordine di aggiornamento dei server. Non è necessario aggiornare i server di rete (NS) e i server multimediali (MS) in un ordine specifico in relazione l'uno all'altro.

Le piattaforme di recapito delle applicazioni (ADP) sono menzionate due volte nella sequenza, in quanto il primo set di ADP è costituito da quelli che eseguono DBSObserver, DBManagement e altri servizi di profilo. Il secondo gruppo di ADP è costituito dai servizi XSI (Extended Services Interface), OCI-P (Open Client Interface - Provisioning), DMS (Device Management System) e NPS (Notification Push Server).

Per l'aggiornamento dei server BroadWorks, attenersi alla seguente procedura standard di alto livello:

1. Eseguire il backup del server.
2. Installare l'ultimo pacchetto software di installazione di Release Independent (RI). Lo swmanager è incluso nel pacchetto RI.
3. Installare la licenza di rilascio di destinazione.
4. Eseguire lo strumento di controllo dell'aggiornamento dalla CLI per verificare che non siano presenti avvisi:

   ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2021.02_1.50

Installare sempre la release di destinazione su tutti i peer dello stesso cluster prima di aggiornare uno dei membri del cluster.

Può essere utile verificare le attività completate per ogni server. Ad esempio:

Macchina	SERVER1	SERVER2	SERVER 3
Backup	Fine	Fine
Supporto tecnico	Fine	...ecc...
Installazione release di destinazione	Fine
Importazione licenza	Fine
Controllo Healthmon	Fine
Controllo aggiornamento	Fine

Aspettative sulle procedure

Nel presente documento si presume che:

1. Spazio su disco sufficiente per eseguire i backup, installare i nuovi file binari e aggiornare.
2. Ogni server ha la capacità di installare pacchetti.
3. Il sistema operativo è compatibile con la versione di destinazione.
4. Pre-InstallCheck è stato eseguito su ogni server e tutti gli avvisi o gli errori sono stati corretti.
5. Il sistema è in uno stato di integrità.
6. Sono state ottenute licenze appropriate.
7. È stato creato un piano di test post-aggiornamento, eseguito prima dell'aggiornamento e i risultati sono stati registrati.

Note specifiche del server

• Network Function Manager (NFM) è indipendente dagli altri server BroadWorks, quindi l'interoperabilità non rappresenta un problema. Si consiglia sempre di eseguire la versione più recente di NFM.
• L'aggiornamento al server di database (DBS) aggiorna il software, ma le modifiche dello schema al database non vengono eseguite finché l'ADP (che esegue l'applicazione EnhancedCallLogsDBManagement) non viene aggiornato.
• È consigliabile eseguire il backup del DBS o del server di database di rete prima di aggiornare qualsiasi ADP che esegue EnhancedCallLogsDBManagementNDS o CCReportingDBManagement.
• Aggiornare MS/NS prima di Application Server (AS). In genere, il sistema MS/NS rimane in esecuzione sull'ultima release per uno o due giorni fino all'aggiornamento del sistema operativo.

Fare riferimento alla matrice di compatibilità per ulteriori informazioni.

Piani di test precedenti e successivi all'aggiornamento

È consigliabile disporre di un piano di test completo ed eseguire e registrare i risultati del piano di test prima di un aggiornamento. In questo modo è possibile identificare i problemi prima di un aggiornamento, oltre a fornire un confronto con i risultati dei test successivi all'aggiornamento.

Ripristini e ripristini

Nel contesto di un aggiornamento BroadWorks, il ripristino e il rollback di un server non sono la stessa cosa. Un server ripristina l'ultimo backup del database (DB) eseguito per ripristinare lo stato del database precedente all'aggiornamento. Ripristinare tutti i dati aggiunti al database dopo la perdita dell'aggiornamento iniziale. Il rollback annulla tutte le modifiche apportate al database durante il processo di aggiornamento, lasciando invariati i dati aggiunti al database dopo l'aggiornamento iniziale.

Rilascia server indipendenti

Tutti i server sono di tipo RI. Tutte le nuove funzionalità, i bug e le correzioni alla protezione vengono forniti in una nuova versione del software. Le patch non saranno disponibili. I server devono essere aggiornati da una versione all'altra per ottenere una correzione. Si prevede che verrà rilasciata una nuova versione di ogni server al mese (anziché pacchetti di patch mensili).

Le versioni Ri hanno un formato diverso da quello standard Rel_25.0_1.944. Questo formato Ri è il seguente: Server_Rel_yyyy.mm_1.xxx:

• Il server è MS, ad esempio
• aaaa è l'anno a 4 cifre
• mm è il mese a 2 cifre
• xxx è la release incrementale del mese

Ad esempio, MS_Rel_2022.11_1.273.Linux-x86_64.bin è una versione di MS rilasciata nel novembre 2022.

ADP

Nella release 25, l'offerta funzionale di Xtended Services Platform (XSP) e Profile Server (PS) è passata all'ADP. Le applicazioni eseguite su XSP e PS sono suddivise in due categorie: applicazioni principali (che forniscono servizi all'infrastruttura di base) o applicazioni di confine (che forniscono accesso a API esterne). Le applicazioni installate definiscono la posizione dell'ADP nella rete.

Le applicazioni fornite con l'ADP vengono fornite in modalità RI o come Release Anchored (RA). RA indica che l'applicazione ha una dipendenza dello schema dalla versione AS, quindi esiste un componente della versione nel nome file dell'applicazione e viene consegnata una "diramazione" diversa associata alla versione AS.

Per un elenco delle applicazioni disponibili per l'ADP e le ultime versioni disponibili, vedere Download del software BroadWorks Application Delivery Platform.

Procedura di installazione

I programmi di installazione BroadWorks possono essere scaricati da Cisco BroadWorks - Download.

Installare il file binario della release di destinazione

L'installazione di questi componenti può essere eseguita senza alcuna interruzione del servizio. La procedura di installazione è la stessa per tutti i server, con una lieve differenza per i tipi di server. I server RI non dispongono di una patch di installazione.

In questi passaggi di esempio viene utilizzato un AS, ma la procedura è la stessa per tutti i file binari BroadWorks 25.x. Questa operazione deve essere eseguita come utente root (sudo non è accettabile). La umask è 0022 per root e 0002 per 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

Al termine dell'installazione, verificare se nell'output sono presenti azioni o avvisi aggiuntivi. Vengono visualizzati messaggi che indicano che è necessaria una nuova licenza e che la release di destinazione deve essere attivata manualmente.

==============================================================
           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

Una volta installato, immettere il qversions dalla bwcli per accertarsi che sia presente. Notare che lo stato è Installed (non 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

Rimuovere un file binario installato

Se il file binario non viene installato correttamente o deve essere rimosso, eseguire il comando uninstall-bwserver.pl script.

$ cd /bw/broadworks/
    
    
      /uninstall/ 
     
$ ./uninstall-bwserver.pl -r

Il parametro "-r" fornisce l'istruzione per rimuovere la struttura di cartelle rimanente in /bw/broadworks/<server>.

Installa licenza di rilascio destinazione

Questa sezione riguarda solo le licenze UUID (Universal Unique Identifier). Per le licenze basate su NFM, fare riferimento alla sezione Gestione licenze del nodo Network Function Manager e alla guida alla gestione delle licenze.

Per le licenze basate su UUID, i file di licenza potrebbero trovarsi all'interno di più file zip. Il server si aspetta che il file zip contenga i file .txt e .sig. Non decomprimere i file in un computer locale per copiare semplicemente i file con estensione txt e sig, poiché in questo modo la firma viene invalidata.

Importazione della licenza dalla CLI

Non è necessario decomprimere i file delle licenze e utilizzare il percorso completo.

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

Installa licenza dal sistema operativo

Non è necessario decomprimere i file delle licenze e utilizzare il percorso completo, come bwadmin o root run.

$ cd /usr/local/broadworks/bw_base/bin/
$ ./install-license.pl /path/to/licensefiles.zip

Eseguire lo strumento UpgradeCheck

Eseguire il upgradeCheck dalla bwcli e verificare che non siano presenti avvisi.

Di seguito è riportato un esempio del SA:

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)

Il modulo NFM implementa le funzioni di gestione della rete e delle licenze.

Verificare che Healthmon non presenti problemi:

--------------------------------
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 e supporto tecnico

Prima di qualsiasi aggiornamento del server, è consigliabile eseguire un backup e registrare un supporto tecnico da prima dell'aggiornamento:

$ bwBackup.pl -full -file=/var/broadworks/backup/bwBackup.bak
$ tech-support >> tsup_hostname_sourceRelease.txt

Pre-aggiornamento

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

Verificare se il monitoraggio della rete è presente nel modulo NFM in fase di aggiornamento

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

Switch di aggiornamento NFM

In un cluster, l'ordine in cui i server NFM vengono aggiornati non è rilevante. Tuttavia, aggiornarli uno alla volta.

Avviare l'aggiornamento immettendo questo comando:

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

Gestione delle licenze su NFM

Vedere la guida alla gestione di nodi e licenze NFM.

Controlli successivi all'aggiornamento di NFM

Dopo l'aggiornamento, controllare lo stato NFM dopo l'avvio:

• healthmon -l
• showrun
• bwshowver
• mdbctl status
• Se Network Monitoring è attivo:pgctl status
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.NFM.Rel_2022.11_1.274.<date-time>.log per individuare eventuali errori di attivazione potenziali.
• Se NFM esegue NetworkMonitoring, verificare che l'applicazione sia tornata in esecuzione nella versione di destinazione.

Test NFM post-aggiornamento consigliati

Verificare che le applicazioni connesse ai server NFM siano in grado di eseguire transazioni di database.

Questi test sono generici ed eseguono eventuali test aggiuntivi nel piano di test successivo all'aggiornamento.

Ripristino server NFM

La procedura di ripristino NFM è la stessa degli altri server.

Il ripristino di NFM a R21.SP1 non è supportato in quanto la crittografia del database non è supportata in tale release. Dobbiamo usare l'opzione di inversione. Il ripristino di un cluster NFM comporta tempi di inattività per le applicazioni, in quanto è necessario arrestare il database in tutti i membri del cluster per ripristinare il backup del database.

Per informazioni dettagliate sulle operazioni di ripristino, vedere la guida alla configurazione di NFM.

Ripristina

Se NFM non supera i controlli successivi all'aggiornamento, tornare alla release precedente.

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

Nell'esempio, viene ripristinato il valore 2022.10_1.318, ma può essere sostituito da qualsiasi versione precedente.

Server di database (DBS)

Poiché il DBS esegue un modulo di gestione di database diverso (Oracle 11g) rispetto agli altri prodotti BroadWorks, i prerequisiti di aggiornamento e i passaggi di aggiornamento e i comandi di backup sono molto diversi rispetto al resto della suite BroadWorks. Leggere attentamente questa sezione e inviare eventuali richieste di informazioni al Technical Assistance Center (TAC) per ottenere i chiarimenti necessari.

Una differenza che spicca, solo per il DBS e il DBS, è l'avvio dell'aggiornamento del server di standby. Questa operazione viene eseguita in quanto l'aggiornamento del DBS non modifica effettivamente lo schema del database. Questo si verifica quando CCReportingDBManagement viene aggiornato. Con un aggiornamento DBS, il software e il database vengono aggiornati ma lo schema rimane invariato.

Altre peculiarità includono la necessità di riavviare i server prima di eseguire un aggiornamento, nonché la rimozione manuale delle attività pianificate (in modo da non interferire con l'aggiornamento).

Nelle sezioni seguenti viene descritto in modo dettagliato tutto il necessario. Il diagramma della sequenza di aggiornamento è seguito da passaggi e comandi dettagliati per ogni passaggio.

Esegui backup di entrambi i database

Prendere nota delle dimensioni dei DATI con dbsctl diskinfo

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

Lo spazio richiesto per il backup è di circa 1/7^di tale spazio.

Immettere i seguenti comandi per eseguire il backup:

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$

Si noti che il backup viene eseguito come utente Oracle, pertanto è necessario che venga scritto in un luogo in cui Oracle dispone delle autorizzazioni di scrittura. Verificare che lo spazio su disco sia sufficiente per gestire questa condizione nella partizione.

I backup completi possono essere eseguiti utilizzando: questo comando:

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

Arresta DBSObserver

Per le configurazioni ridondanti, arrestare l'applicazione DBSObserver sull'ADP durante l'aggiornamento:

bwadmin@<ps1>$ stopbw DBSObserver

Il DBSObserver viene distribuito in uno degli ADP. Per determinare se un determinato ADP esegue il server DBSO, esaminare l'output del  showrun sull'ADP.

Verifiche integrità pre-aggiornamento

Assicurarsi che la replica sia in esecuzione e integra e che i database siano correttamente posizionati con dbsctl status su entrambi i DBS.

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 

Passi obbligatori pre-aggiornamento

Rimozione delle operazioni pianificate dallo scheduler

Sono state identificate attività pianificate che causano errori di aggiornamento e il ripristino automatico alla versione di origine. Prendere nota della configurazione iniziale:

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

Rimuovere quindi le attività pianificate. Quando si rimuove un'attività, i numeri ID cambiano. Iniziare rimuovendo prima l'ID più alto.

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

Verificare che le voci siano state eliminate con get

Riavvia il server (init 6) prima dell'aggiornamento

Prima di eseguire l'aggiornamento, accertarsi di riavviare ciascun server. Anche in questo caso, è possibile evitare errori di aggiornamento. Poiché l'aggiornamento viene eseguito sempre su un server DBS in standby, non influisce su alcun elemento e non determina la commutazione di un numero di ruoli superiore al normale.

Fare riferimento al diagramma della sequenza di aggiornamento per l'ordine. L'inizializzazione 6 viene eseguita dopo il backup e prima dell'attivazione di ciascun server.

Avvia l'aggiornamento

Il DBS differisce da tutti gli altri server BroadWorks in quanto il DBS di standby/secondario viene aggiornato per primo. Se si inizia con il server attualmente attivo, è necessario un ulteriore riavvio/cambiamento di ruolo.

In Standby/Secondario:

DBS_CLI/Maintenance/ManagedObjects> lock

Passare alla release di destinazione:

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

Al termine, sbloccare il server:

DBS_CLI/Maintenance/ManagedObjects> unlock

Controllare Healthmon per verificare che il DBS sia stato avviato correttamente.

Passare al DBS secondario/STANDBY appena aggiornato in modo che sia attivo/primario

  

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

  

In questa fase, il DBS aggiornato (dbs2) è ora principale.

Controlli successivi all'aggiornamento del server di database

• Effettua una chiamata a un Call Center e recupera i report che mostrano questa attività.
• Recuperare i report cronologici.
• Esaminare gli XSLogs sull'ASA per verificare che i dati siano stati inviati a DBS2 (e non nella coda file).

Aggiornare la versione primaria precedente (ora in standby)

Sul vecchio <dbs1> primario (ora in standby), bloccare:

DBS_CLI/Maintenance/ManagedObjects> lock

Passare alla versione di destinazione:

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

Sbloccare il database primario1:

DBS_CLI/Maintenance/ManagedObjects> unlock

Eseguire lo switchover per l'impostazione originale e lo standby come principale

Impostare DBS1 nuovamente su primario con peerctl setPrimary dbs1

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 

Ripristina lo stato precedente dello scheduler

Poiché le attività pianificate sono state rimosse dallo scheduler, è necessario aggiungerle di nuovo. Ad esempio, ecco tutti i tempi standard:

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

Controlli successivi all'aggiornamento del server di database primario

• Effettua una chiamata a un Call Center e recupera i report che mostrano questa attività.
• Recuperare i report cronologici.
• Esaminare i log XSL sull'appliance ASA per verificare che i dati siano stati inviati a DBS1 (e non nella coda file).

Verificare il corretto funzionamento di Healthmon, replica e redo log shipping:

bwadmin@dbs1$ repctl status
bwadmin@dbs1$ dbsctl status
bwadmin@dbs1$ dbsctl diskinfo
bwadmin@dbs1$ dbsctl redolog info

Eseguire questa operazione su entrambi i DBS per verificare che siano in buono stato dopo l'aggiornamento.

Convalida integrità da ADP

Dall'ADP che esegue CCReportingDBManagement, immettere i seguenti comandi:

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

Avvia DBSObserver

Una volta aggiornati entrambi i DBS, avviare l'applicazione DBSObserver per controllare il failover:

bwadmin@ADP1$ startbw DBSObserver
Starting DBSObserver...

Procedura di ripristino del server di database

La procedura generale di ripristino di Database Server è molto simile alla procedura generale di ripristino di BroadWorks descritta nella BroadWorks Software Management Guide.

Le principali differenze sono le seguenti:

• Rollback non supportato. È supportato solo il ripristino.
• Per le configurazioni ridondanti, il ripristino del software viene eseguito prima sul sito in standby.
• Dopo l'attivazione del software è necessario eseguire un controllo post-ripristino (vedere Database Server > Procedura di ripristino del server di database > Fasi procedurali dettagliate > Controllo post-ripristino) per verificare se il ripristino del database è stato eseguito correttamente e se sono necessarie azioni correttive.   

Rollback negato

Qualsiasi tentativo di eseguire il rollback della versione attiva del software sul server database viene rifiutato, come illustrato nell'esempio seguente:

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.

Fasi procedurali dettagliate

I passaggi necessari per ripristinare Cisco BroadWorks su un server standalone e su una configurazione di server ridondante sono identici e devono essere eseguiti in un ordine specifico. I passaggi descritti di seguito riguardano entrambe le configurazioni.

1. Attivare la versione precedente di Cisco BroadWorks. Per le configurazioni ridondanti, il server di standby deve prima essere ripristinato. Quando si ripristina la modalità standby, non specificare un percorso di backup.
2. Per le configurazioni ridondanti, procedere con l'inversione del server principale.
3. Eseguire la verifica successiva al ripristino.

Per aggiungere chiarezza ai passaggi corrispondenti al diagramma di sequenza, quando si ripristina il sito in standby SiteB non viene specificato il file di backup. È tuttavia possibile specificare il file di backup quando si ripristina il sito A. In alternativa, è possibile ripristinare il file di backup nel passaggio successivo. Il passaggio di sincronizzazione in standby sincronizza quindi i dati tra SiteA e SiteB.

Ripristina operazione

L'operazione di ripristino viene avviata dal livello ManagedObject della CLI di BroadWorks. Come per gli altri tipi di server, il percorso di backup può essere specificato direttamente nella CLI, come mostrato nell'esempio seguente:

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?

Quando l'operazione di ripristino viene eseguita sul sito in standby, non specificare il percorso di backup. Il sito in standby viene ricreato dal sito primario utilizzando importdb.pl dopo l'operazione di ripristino o automaticamente risincronizzata dallo script di ripristino stesso. Una volta completato il ripristino, vedere i risultati del test revertcheck per le azioni correttive consigliate.

Inoltre, se il ripristino viene eseguito prima dell'aggiornamento del database primario, il database in esecuzione sul database primario non viene influenzato dall'aggiornamento e il database in standby può essere ripristinato alla release precedente senza che sia necessaria un'operazione di ripristino o risincronizzazione.

In questo log di output dei comandi viene mostrata la sequenza di ripristino all'avvio senza specificare una directory di backup:

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

Registra controllo inverso

Lo script post-revertcheck è stato progettato per determinare se il ripristino del database è stato eseguito correttamente e se sono necessarie azioni correttive.  Deve essere eseguito dall'ultima directory bin di BroadWorks, utilizzando il percorso completo o il prefisso con la barra (./):

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

Ripristina backup

Se è stata specificata una directory di backup con il comando set activeSoftwareVersion server, il backup viene ripristinato automaticamente dal processo di ripristino.

In caso contrario, è necessario ripristinare il backup utilizzando questo comando:

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

Sincronizza standby

Se è necessario risincronizzare lo standby con il database, la importdb.pl viene utilizzato lo script.

Questo comando viene utilizzato per risincronizzare il database nel sito B se il database primario nel sito A non è stato aggiornato:

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

Se il sito A è stato aggiornato e ripristinato, è necessario ricreare il database in standby dal sito primario e riconfigurare la ridondanza. A tale scopo, viene utilizzato questo comando:

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

La procedura di ripristino per il DBS è descritta in dettaglio nella Guida alla configurazione del DBS.

Ripristino dello stato precedente l'aggiornamento dello switch primario/standby

Al termine dell'operazione di ripristino, utilizzare il pulsante peerctl per riportare i server allo stato di standby/primario precedente all'aggiornamento. Ad esempio:

bwadmin@dbs1$ peerctl setPrimary dbs1

Se DBSObserver non è in esecuzione sull'ADP, avviarlo.

NDS (Network Database Server)

Verificare che Healthmon non presenti problemi:

--------------------------------
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 e supporto tecnico

Prima di qualsiasi aggiornamento del server, è consigliabile eseguire un backup completo e registrare un supporto tecnico da prima dell'aggiornamento:

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

$ tech-support >> tsup_hostname_sourceRelease.txt

Controllo aggiornamento

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

Switch di aggiornamento NDS

In un cluster, l'ordine di aggiornamento degli NDS non è rilevante. Tuttavia, eseguire l'aggiornamento solo uno alla volta. Avviare l'aggiornamento immettendo questo comando:

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

Controlli post-aggiornamento NDS

Dopo l'aggiornamento, controllare lo stato NDS dopo l'avvio:

• healthmon -l
• showrun
• bwshowver
• mdbctl status
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.NDS.Rel_2022.11_1.273.<date-time>.log per individuare eventuali errori di attivazione potenziali.

Test di post-aggiornamento NDS consigliati

Verificare che le applicazioni connesse a NDS siano in grado di eseguire transazioni di database.

Questi test sono generici ed eseguono eventuali test aggiuntivi nel piano di test successivo all'aggiornamento.

Ripristino NDS Server

Il ripristino di un cluster NDS comporta tempi di inattività per le applicazioni, in quanto il database deve essere arrestato in tutti i membri del cluster per poter ripristinare il backup del database.

La procedura di ripristino di NDS è la stessa degli altri server.

Ripristina

Nel caso in cui NDS non superi i controlli post-aggiornamento, tornare alla versione precedente:

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

Nell'esempio, viene ripristinato il valore 2022.08_1.352, ma può essere sostituito da qualsiasi versione precedente.

Server di rete (NS)

Notare che il sistema NS è ora RI.

Verifica che Healthmon non presenti problemi

--------------------------------
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 e supporto tecnico

Prima di qualsiasi aggiornamento del server, è consigliabile eseguire un backup e registrare un file di supporto tecnico:

$ bwBackup.pl networkserver NS_hostname_sourceRelease.tar
$ tech-support >> tsup_hostname_sourceRelease.txt

Pre-aggiornamento

Effettuare una chiamata di prova che richiami il sistema NS e verifichi che il messaggio 302 sia stato inviato correttamente nel log di NSXSLog in /var/broadworks/logs/routingserver/.

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

Controllare il numero corrente di chiamate e così via in uso con qcurrent comando:

NS_CLI/Monitoring/Report> qcurrent

Controlla sincronizzazione database (synchcheck_basic.pl -a) su tutti gli NS peer non primari:

$ synchcheck_basic.pl -a

Switch di aggiornamento NS primario

Avviare l'aggiornamento immettendo questo comando:

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

Aggiornare le statistiche del database eseguendo il comando bwPeriodMaint.sh script.

$ bwPeriodMaint.sh

Controlli post-aggiornamento NS

Dopo l'aggiornamento, controllare lo stato di NS dopo l'avvio.

• healthmon -l
  • Indica che il peer non è sincronizzato, ma questo è previsto finché il secondario non viene aggiornato.
  • Se health thmon indica che alcune dimensioni di pagina del database sono superate, immettere: check_dbpages.pl networkserver modify.
• showrun
• bwshowver
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.log per verificare la presenza di eventuali errori di attivazione.
• Eseguire i test NS per verificare che il server NS elabori correttamente le chiamate.

Test di NS post-aggiornamento consigliati

• Convalida reindirizzamento 302 in entrata PSTN (Public Switched Telephone Network).
• Convalida come reindirizzamento 302 in uscita.
• Convalida AS su richiesta/risposta MS.
• Convalidare l'accesso CLI (accedere e andare a NS_CLI/System/Device/HostingNE; immettere il comando get).
• Convalida dell'accesso Web al sistema NS (se abilitato).
• Convalidare la ricerca utente da un ADP utilizzando la comunicazione in modalità NS eseguendo semplicemente il login a un ADP.

Attività di post-aggiornamento NS

Verificare che il server NS non sia impostato in modo da impedire agli ADP di accedere a un server AS con una versione diversa. Impostare ADP Version Equal to false per ogni hostNE in NS_CLI/System/Device/HostingNE>.

Ripristino NS

Nel caso in cui il sistema NS non superi i controlli successivi all'aggiornamento, tornare alla release precedente:

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

Nell'esempio, viene ripristinato il valore 2022.09_1.340, ma può essere sostituito da qualsiasi versione precedente.

Poiché il sistema NS secondario dispone di una versione corrente del database dalla release di origine, è possibile importare il database da tale release.

Sul sistema NS secondario,

$ repctl start

Sul sistema NS principale,

$ stopbw
$ repctl stop
$ importdb.pl networkserver <peer_ns2>
$ repctl start
$ startbw

Sbloccare i database NS secondari (e tutti gli altri):

$ peerctl unlock

Verificare che la replica sia in esecuzione sull'NS primario ripristinato:

$ repctl status

Verificare che la replica sia in esecuzione su tutti gli NS secondari e che il database sia sbloccato:

$ repctl status

Assegno healthmon -l su tutti i sistemi NS. Assicurarsi che la gravità riportata sia NOTIFICATION per tutti i server.

Verificare che i database NS secondario e primario siano sincronizzati (sul database secondario):

$ synchcheck_basic.pl -a

Switch di aggiornamento NS secondario

Avviare l'aggiornamento immettendo questo comando:

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

Non è necessario eseguire lo script di aggiornamento delle statistiche, poiché è stato eseguito prima dell'importazione che è stata eseguita automaticamente durante l'aggiornamento del sistema NS secondario.

Controlli post-aggiornamento NS

Dopo l'aggiornamento, controllare lo stato NS dopo l'avvio

• healthmon -l
  • Se health thmon indica che alcune dimensioni di pagina del database sono superate, immettere:check_dbpages.pl networkserver modify.
• showrun
• bwshowver
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.log per verificare la presenza di eventuali errori di attivazione.
• Eseguire i test NS per verificare che il server NS elabori correttamente le chiamate.

Test di NS post-aggiornamento consigliati

Bloccando il sistema NS primario, tutto il traffico passa attraverso il sistema secondario:

• Convalida reindirizzamento 302 in ingresso PSTN.
• Convalida come reindirizzamento 302 in uscita.
• Convalida AS su richiesta/risposta MS.
• Convalidare l'accesso CLI (accedere e andare a NS_CLI/System/Device/HostingNE; immettere il comando get).
• Convalida dell'accesso Web al sistema NS (se abilitato).
• Convalidare la ricerca utente da un XSP utilizzando la comunicazione in modalità NS effettuando semplicemente l'accesso a un XSP.
• Test post-cluster.
• Verificare che Healthmon segnali la notifica della gravità per tutti i server.
• Controllare la sincronizzazione del database.

$ healthmon -l
$ synchcheck_basic.pl –a

Server multimediale (MS)

Verificare che Healthmon non presenti problemi:

--------------------------------
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 e supporto tecnico

Prima di qualsiasi aggiornamento del server, è consigliabile eseguire un backup e registrare un supporto tecnico da prima dell'aggiornamento. Per quanto riguarda gli Stati membri, ciò sarebbe incompatibile con:

$ bwAutoBackup.sh
$ tech-support >> tsup_hostname_sourceRelease.txt

Pre-aggiornamento

Effettuare una chiamata di prova per richiamare Interactive Voice Response (IVR) o recuperare un messaggio vocale e assicurarsi che funzioni come previsto e che la chiamata venga visualizzata nei registri.

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

Verificare il numero corrente di porte in uso con qcurrent

MS_CLI/Monitoring/Report> qcurrent

Switch di aggiornamento MS

Avviare l'aggiornamento usando questo comando:

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

Controlli successivi all'aggiornamento MS

Dopo l'aggiornamento, controllare lo stato di MS dopo l'avvio e verificare se è stato lasciato un messaggio vocale e il recupero della segreteria.

• healthmon -l
• showrun
• bwshowver

Test MS post-aggiornamento consigliati

• Convalidare il deposito e il recupero della casella vocale.
• Convalida interazione IVR riuscita.
• Convalida chiamata tridirezionale riuscita.

Questi test sono generici ed eseguono eventuali test aggiuntivi nel piano di test successivo all'aggiornamento.

MS Revert

Nel caso in cui il server Microsoft non superi i controlli successivi all'aggiornamento, tornare alla versione precedente.

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

Nell'esempio precedente, viene ripristinato il valore 2022.08_1.350, ma può essere sostituito da qualsiasi versione precedente.

Server applicazioni (AS)

Verifica che Healthmon non presenti problemi

--------------------------------
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.

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

• Controllare i registri per assicurarsi che entrambi gli AS elaborino le chiamate (è possibile forzare nuove chiamate al database secondario bloccando AS1).
• Convalidare l'accesso Web tramite i server Web e ogni server di accesso.

Backup e supporto tecnico

È consigliabile eseguire un backup e registrare un supporto tecnico da prima di eseguire l'aggiornamento.

$ bwBackup.pl AppServer AS_hostname_sourceRelease.tar
$ tech-support >> tsup_hostname_sourceRelease.txt

Pre-aggiornamento

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi.

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

  

  

Controllare la sincronizzazione del database (synchcheck_basic.pl -a) sull'AS secondario:

$ synchcheck_basic.pl -a

Impostare extensionTimeInSeconds su 10800 (tre ore) in modo che corrisponda alla quantità di tempo riservata per l'aggiornamento del server:

AS_CLI/System/Registration> set extensionTimeInSeconds 10800

L'impostazione tipica è quando non si esegue l'aggiornamento a 2400 come indicato nella Guida alla configurazione di sistema.

La replica invia la modifica ai server rimanenti nel cluster.

Eliminare l'operazione di backup dallo scheduler:

AS_CLI/Maintenance/Scheduler> get
  Id         Name       Date        Day    Hour    Minute
=================================================================
   5       backup          -     saturday    4      03

Se il backup viene attivato durante l'aggiornamento, potrebbero verificarsi problemi durante l'attivazione:

AS_CLI/Maintenance/Scheduler> del 5

Blocca l'AS principale

Bloccare l'AS primario. Le nuove chiamate passano attraverso l'AS secondario, consentendo l'eliminazione del numero di chiamate attive sul server primario prima di eseguire lo switch (la commutazione o la forza di blocco causa l'eliminazione delle chiamate attive):

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

Al termine, controllare il numero di chiamate sull'appliance ASA con il qcurrent comando:

AS_CLI/Monitoring/Report> qcurrent

Switch di aggiornamento ASA primario

Una volta che le chiamate sono scese a un livello accettabile, avviare l'aggiornamento con:

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

Al termine, sbloccare il server:

AS_CLI/Maintenance/ManagedObjects> unlock

Aggiorna le statistiche del database con bwPeriodMaint.sh:

$ bwPeriodMaint.sh

Questo comando non restituisce alcun output.

Poiché l'operazione di backup è stata eliminata dallo scheduler, è necessario aggiungerla dopo l'aggiornamento. Questo è il valore suggerito. È necessario aggiungerlo nuovamente al valore configurato prima dell'aggiornamento:

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

Azioni principali di post-aggiornamento AS

Controlli successivi all'aggiornamento di AS

Dopo l'aggiornamento, controllare lo stato AS dopo l'avvio e verificare le registrazioni e le chiamate.

• healthmon -l
  • Indica che il peer non è sincronizzato, ma questo è previsto finché il secondario non viene aggiornato.
• showrun
• bwshowver
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411 .<date-time>.log per verificare la presenza di eventuali errori di attivazione.
• Eseguire i test AS per verificare che il server AS elabori correttamente le chiamate.

Test AS consigliati dopo l'aggiornamento

• Convalida chiamate in uscita SIP.
• Convalida delle chiamate in uscita MGCP (Media Gateway Control Protocol).
• Convalida da PSTN a chiamata in ingresso utente SIP.
• Convalida PSTN per chiamate in ingresso dell'utente MGCP.
• Convalida uscita/recupero posta vocale (portale voce).
• Convalidare le origini/cessazioni di CommPilot.
• Convalidare l'accesso CLI (andare a AS_CLI/System/Alias e usare il comando get).
• Convalida dell'accesso Web diretto all'AS.

Prompt vocali localizzati

Se si esegue l'aggiornamento a R25, i prompt audio personalizzati vengono copiati automaticamente dalla release di origine. Fate riferimento alla sezione 4.5 della descrizione della feature.

Ripristina

Se il SA non supera i controlli successivi all'aggiornamento, tornare alla release precedente.

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

Nell'esempio, viene ripristinato il valore 2022.08_1.354, ma può essere sostituito da qualsiasi versione precedente.

Poiché l'AS secondario dispone di una versione corrente del database, importare il database da tale versione.

Sul SA secondario:

$ repctl start

Nell'AS principale:

$ stopbw
$ repctl stop
$ importdb.pl appserver 
     
       appserver 
     
$ repctl start
$ startbw

Sbloccare il database AS secondario:

$ peerctl unlock

Verificare che la replica sia in esecuzione sull'AS primario ripristinato:

$ repctl status

Verificare che la replica sia in esecuzione sull'AS secondario e che il database sia sbloccato:

$ repctl status
$ peerctl unlock

Assegno healthmon -l su tutti gli AS. Assicurarsi che la gravità riportata sia NOTIFICATION per tutti i server.

Verificare che i database AS secondario e AS primario siano sincronizzati (sul database secondario):

$ synchcheck_basic.pl -a

Switch di aggiornamento AS secondario

Avviare l'aggiornamento immettendo questo comando:

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

Aggiornare le statistiche del database eseguendo il comando bwPeriodMaint.sh script:

$ bwPeriodMaint.sh

Azioni secondarie di post-aggiornamento di AS

Controlli successivi all'aggiornamento di AS

Dopo l'aggiornamento, controllare lo stato AS dopo l'avvio e verificare le registrazioni e le chiamate.

• healthmon -l
• showrun
• bwshowver
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411.<date-time>.log per verificare la presenza di eventuali errori di attivazione.
• Eseguire i test AS per verificare che il server di autenticazione elabori correttamente le chiamate.

Test AS consigliati dopo l'aggiornamento

• Bloccare l'AS primario per forzare nuove chiamate al database secondario.
• Convalida chiamate in uscita SIP.
• Convalida chiamate in uscita MGCP.
• Convalida da PSTN a chiamata in ingresso utente SIP.
• Convalida PSTN per chiamate in ingresso dell'utente MGCP.
• Convalida uscita/recupero posta vocale (portale voce).
• Convalidare le origini/cessazioni di CommPilot.
• Convalidare l'accesso CLI (andare a AS_CLI/System/Alias e usare il comando get).
• Convalida dell'accesso Web diretto all'AS.

Test post-cluster

• Verificare che Healthmon segnali la notifica della gravità per tutti i server.
• Controllare la sincronizzazione del database:

$ healthmon -l
$ synchcheck_basic.pl –a

Funzione Service Control (SCF)

Verificare che Healthmon non presenti problemi:

--------------------------------
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.

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

• Controllare i registri per verificare che SCF stia elaborando le chiamate.

Backup e supporto tecnico

Prima di qualsiasi aggiornamento del server, è consigliabile eseguire un backup e registrare un supporto tecnico da prima dell'aggiornamento. Questa operazione viene eseguita con:

$ bwAutoBackup.sh
$ tech-support >> tsup_hostname_sourceRelease.txt

Pre-aggiornamento

Verificare le chiamate dalla rete mobile per verificare che la funzione corrente funzioni normalmente.

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

In caso di configurazione ridondante, bloccare il server per forzare le chiamate all'altro SCF:

SCF_CLI/Maintenance/ManagedObjects> lock

Switch di aggiornamento SCF

Una volta che le chiamate sono scese a un livello accettabile, avviare l'aggiornamento con:

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

Al termine, sbloccare il server e le chiamate di test:

SCF_CLI/Maintenance/ManagedObjects> unlock

Controlli successivi all'aggiornamento di SCF

Dopo l'aggiornamento, controllare i registri SS7 per un avvio corretto:

• healthmon -l
• showrun
• bwshowver
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.SCF.Rel_2023.03_1.411.<date-time>.log per individuare eventuali errori di attivazione potenziali.
• Eseguire i test per verificare che il file SCF elabori correttamente le chiamate.
• Confermare che le chiamate dalla rete mobile al core BroadWorks funzionano come prima dell'aggiornamento.

Ripristino server SCF

Se il file SCF non supera i controlli successivi all'aggiornamento, tornare alla versione precedente:

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

Nell'esempio, viene ripristinato il valore 2022.10_1.313, ma può essere sostituito da qualsiasi versione precedente.

ADP (Application Delivery Platform)

Verificare che Healthmon non presenti problemi:

--------------------------------
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 e supporto tecnico

Prima di qualsiasi aggiornamento del server, è consigliabile eseguire un backup e registrare un supporto tecnico da prima dell'aggiornamento. A tal fine:

$ bwAutoBackup.sh
$ tech-support >> tsup_hostname_sourceRelease.txt

Pre-aggiornamento

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

Bloccare il server prima dell'attivazione della nuova versione del software:

ADP_CLI/Maintenance/ManagedObjects> lock

Disinstalla e disattiva l'applicazione ECLQuery durante lo spostamento da ADP/PS su R23 a RI

Prima di aggiornare l'ADP all'ultima RI, è necessario eseguire la migrazione dell'applicazione ECLQuery all'NDS SE l'ADP/PS di origine sull'R23 ha l'applicazione ECLQuery in esecuzione. Fare riferimento alla descrizione della funzione Migrazione avanzata log delle chiamate da server database a server database di rete.

ADP_CLI/Maintenance/ManagedObjects> undeploy application /ECLQuery

ADP_CLI/Maintenance/ManagedObjects> deactivate application /ECLQuery

In caso contrario, viene visualizzato un avviso "bwCentralizedDatabaseListenerFailure" sull'ADP dopo l'attivazione della nuova release.

Caricare le applicazioni RI/RA ADP corrispondenti alle applicazioni distribuite nella release di origine

Il server BroadWorks di ADP richiede che le versioni RI/RA delle applicazioni attualmente distribuite nella versione di origine vengano scaricate da Cisco.com. Per ottenere l'elenco delle applicazioni richieste, eseguire le azioni seguenti.

Nell'ADP immettere:

$ 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

Tutte le applicazioni elencate dopo le "Informazioni applicazioni" sono applicazioni distribuite nell'ADP e richiedono il download delle versioni compatibili con ADP da Cisco.com. Scarica le ultime versioni disponibili. Di seguito sono riportati alcuni esempi di applicazioni basate sull'esempio precedente:

OCS_2023.01_1.193.bwar

OCIOverSoap_2023.01_1.193.bwar

Xsi-Actions-24_2023.01_1.010.bwar

Xsi-Events-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

Copiare i file bwar / war scaricati nell'ADP e collocati nella directory /usr/local/broadworks/apps:

$ cd <bwar / war directory location>
$ cp OCS_2023.01_1.193.war /usr/local/broadworks/apps/
$ 
    
    

Il resto dell'aggiornamento è un normale aggiornamento di BroadWorks.

Pre-aggiornamento

Eseguire lo strumento upgradeCheck per verificare che non vengano emessi avvisi:

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

Switch di aggiornamento ADP

Avviare l'aggiornamento immettendo questo comando:

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

Azioni post-aggiornamento ADP

Aggiorna applicazioni

L'applicazione WebContainer viene aggiornata automaticamente. Le altre applicazioni sono di due tipi: applicazioni Cisco BroadWorks e applicazioni Web. La procedura di aggiornamento varia a seconda che l'applicazione sia un'applicazione Cisco BroadWorks o un'applicazione Web.

• Le applicazioni Cisco BroadWorks vengono inserite come file ARchive (.bwar) di BroadWorks.
• Applicazioni Web, raccolte come file Web ARchive (.war).

Immettere il qbw per visualizzare la versione attualmente attiva per ogni applicazione e il relativo percorso del contesto distribuito.

Aggiorna applicazioni Web

Le applicazioni Web vengono aggiornate disattivando e annullando la distribuzione della versione corrente, quindi attivando e distribuendo la nuova versione:

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

Aggiornamento delle applicazioni Cisco BroadWorks

Le applicazioni Cisco BroadWorks vengono aggiornate dalla libreria bwcli utilizzando  set activeSoftwareVersion application 

Per ulteriori informazioni, vedere le note sulla versione delle applicazioni e la guida alla configurazione di Application Deployment Platform.

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

Esegui rollback applicazioni ADP

Se, per qualche motivo, è necessario eseguire il rollback dell'applicazione a una versione precedente, il processo è simile a un aggiornamento. È importante notare che alcune modifiche potrebbero andare perse dopo l'esecuzione dell'operazione di rollback (ad esempio, le modifiche alla configurazione) perché l'applicazione attiva risultante si trova nello stato precedente all'aggiornamento.

Esegui rollback applicazioni Web

Le applicazioni Web vengono ripristinate disattivando e annullando la distribuzione della versione corrente, quindi attivando e distribuendo la nuova versione:

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

Ripristino dello stato precedente delle applicazioni Cisco BroadWorks

Le applicazioni Cisco BroadWorks vengono ripristinate dalla bwcli utilizzando  set activeSoftwareVersion application  comando:

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

Controlli successivi all'aggiornamento di ADP

Dopo l'aggiornamento, controllare i log per un avvio corretto e accedere alla GUI come in precedenza.

• healthmon -l
• showrun
• bwshowver
• Esaminare il file /var/broadworks/logs/maintenance/ setactiveserver.ADP.Rel_2023.03.0_1.1411.<date-time>.log per individuare eventuali errori di attivazione potenziali.

Test consigliati di aggiornamento successivo all'aggiornamento

• Verificare l'accesso a livello di amministratore.
• Verificare l'accesso a livello utente.
• Convalida funzionalità Call Manager CommPilot.
• Convalidare la funzionalità Client di controllo delle chiamate (ad esempio, BroadWorks Assistant-Enterprise) e Sistema di supporto alle operazioni (OSS)/Interfaccia client aperta (OCI).
• Verificare che il provisioning proxy di Open Client Server (OCS) per AS o NS funzioni correttamente.

Questi test sono generici ed eseguono eventuali test aggiuntivi nel piano di test successivo all'aggiornamento.

Ripristino server ADP

Se l'ADP non supera il controllo post-aggiornamento, tornare alla versione precedente:

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

Nell'esempio, viene ripristinato il valore 2022.10_1.313, ma può essere sostituito da qualsiasi versione precedente.