Méthode de procédure de mise à niveau R25 des serveurs BroadWorks

Introduction

Ce document décrit la procédure de mise à niveau des serveurs BroadWorks telle qu'elle a été effectuée par l'équipe de mise à niveau BroadWorks à partir d'autres sources officielles.

Documentation officielle

Ces documents de référence se trouvent sur la page 25 du guide de documentation Cisco BroadWorks Version 25. Reportez-vous à ces documents principaux :

• Guide de gestion du logiciel
• Guide de configuration du système
• Guide de maintenance
• Notes de version 26.0
• Notes de version 25.0
• Notes de version 24.0 AS

notes de version

Avant la mise à niveau, consultez les notes de version de la version cible et mesurez l'impact potentiel des modifications notées. Consultez les notes de version de la version cible et de toute version intermédiaire entre la version source et la version cible. Par exemple, si vous effectuez une mise à niveau de 23.0 vers 25.0, les notes de version de 24.0 et 25.0 doivent être révisées.

Vous pouvez les trouver sur la page de documentation Cisco ou via les liens fournis.

Procédures standard

Il s'agit de l'ordre dans lequel les serveurs doivent être mis à niveau. Les serveurs réseau (NS) et les serveurs multimédias (MS) n'ont pas besoin d'être mis à niveau dans un ordre spécifique les uns par rapport aux autres.

Les plates-formes de livraison d'applications (ADP) sont mentionnées deux fois dans la séquence, car le premier ensemble d'ADP est constitué de ceux qui exécutent DBSObserver, DBManagement et d'autres services Profile. Le deuxième ensemble de protocoles ADP comprend les services XSI (Xtended Services Interface), OCI-P (Open Client Interface - Provisioning), DMS (Device Management System) et NPS (Notification Push Server).

Lors de la mise à niveau d'un serveur BroadWorks, respectez les étapes de haut niveau standard suivantes :

1. Sauvegardez le serveur.
2. Installez le dernier package logiciel d'installation Release Independent (RI). Le swmanager est inclus dans le package RI.
3. Installez la licence de la version cible.
4. Exécutez l'outil de vérification de la mise à niveau à partir de la CLI pour vous assurer qu'il n'y a aucun avertissement :

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

Installez toujours la version cible sur tous les homologues du même cluster avant de mettre à niveau l'un des membres du cluster.

Il est utile de vérifier les tâches terminées pour chaque serveur. Exemple :

Attentes des procédures

Ce document suppose que :

1. L'espace disque est suffisant pour effectuer des sauvegardes, installer les nouveaux fichiers binaires et effectuer la mise à niveau.
2. Chaque serveur a la possibilité d'installer des packages.
3. Le système d'exploitation est compatible avec la version cible.
4. La vérification préalable à l'installation a été exécutée sur chaque serveur et tous les avertissements ou échecs ont été corrigés.
5. Le système est dans un état d'intégrité.
6. Des licences appropriées ont été obtenues.
7. Un plan de test post-mise à niveau a été créé, exécuté avant la mise à niveau et les résultats ont été enregistrés.

Remarques spécifiques au serveur

• Le Network Function Manager (NFM) est indépendant des autres serveurs BroadWorks, l'interopérabilité n'est donc pas un problème. Il est toujours recommandé d'exécuter la dernière version du NFM.
• La mise à niveau vers le serveur de base de données (DBS) met à niveau le logiciel, mais les modifications de schéma apportées à la base de données n'ont pas lieu tant que l'ADP (qui exécute l'application EnhancedCallLogsDBManagement) n'a pas été mis à niveau.
• Il est recommandé de sauvegarder la base de données ou le serveur de base de données réseau (NDS) avant de mettre à niveau un ADP exécutant EnhancedCallLogsDBManagementNDS ou CCReportingDBManagement.
• Mettez à niveau le MS/NS avant le serveur d'applications (AS). Il est habituel de laisser MS/NS en cours d'exécution sur la dernière version pendant un jour ou deux jusqu'à ce que le système autonome soit mis à niveau.

Référez-vous à la Matrice de compatibilité pour plus de détails.

Plans de tests avant et après la mise à niveau

Il est recommandé de disposer d'un plan de test complet et d'exécuter et d'enregistrer les résultats de ce plan de test avant une mise à niveau. Cela permet d'identifier les problèmes avant une mise à niveau et de comparer les résultats des tests post-mise à niveau.

Inversions et annulations

Dans le contexte d'une mise à niveau BroadWorks, la restauration et la restauration d'un serveur ne sont pas la même chose. Une restauration de serveur restaure la dernière sauvegarde de base de données (DB) effectuée pour restaurer la base de données à son état antérieur à la mise à niveau. Avec un retour, toutes les données ajoutées à la base de données après la mise à niveau initiale sont perdues. Un retour arrière annule toutes les modifications apportées à la base de données au cours du processus de mise à niveau, laissant intactes toutes les données ajoutées à la base de données après la mise à niveau initiale.

Libérer les serveurs indépendants

Tous les serveurs sont RI. Toutes les nouvelles fonctionnalités, les bogues et les correctifs de sécurité sont fournis dans une nouvelle version du logiciel. Les correctifs ne peuvent pas être disponibles. Les serveurs doivent être mis à niveau d'une version à une autre pour obtenir une correction. Une nouvelle version de chaque serveur devrait être publiée chaque mois (au lieu des ensembles de correctifs mensuels).

Les versions RI utilisent un format différent du format standard Rel_25.0_1.944. Le format de cette adresse IP est : Serveur_Réel_aaaa.mm_1.xxx :

• Le serveur est MS, par exemple
• yyy est l'année à 4 chiffres
• mm est le mois à 2 chiffres
• xxx est la version incrémentielle pour ce mois

Par exemple, MS_Rel_2022.11_1.273.Linux-x86_64.bin est une version de MS publiée en novembre 2022.

ADP

Dans la version 25, l'offre fonctionnelle XSP (Xtended Services Platform) et Profile Server (PS) est passée à l'ADP. Les applications qui s'exécutent sur XSP et PS se répartissent en deux catégories : les applications principales (fournissant des services à l'infrastructure principale) ou les applications périphériques (fournissant un accès API externe). Les applications installées définissent l'emplacement du protocole ADP sur le réseau.

Les applications livrées sur l'ADP sont livrées soit en mode RI, soit en mode Release Anchored (RA). RA signifie que l'application a une dépendance de schéma sur la version AS de sorte qu'il y a un composant de version au nom de fichier de l'application et une « branche » différente est fournie qui est associée à la version AS.

Reportez-vous à la section Téléchargement du logiciel de la plate-forme de distribution d'applications BroadWorks pour une liste des applications disponibles pour l'ADP et les dernières versions disponibles.

Procédure d'installation

Les programmes d'installation de BroadWorks peuvent être téléchargés à partir de Cisco BroadWorks - Downloads.

Installer le fichier binaire de la version cible

L'installation peut être effectuée sans interruption de service. La procédure d'installation est la même pour tous les serveurs, avec une légère différence pour les types de serveurs. Les serveurs RIP ne disposent pas de correctif d'installation.

Dans ces étapes d'exemple, nous utilisons un AS, mais la procédure est la même pour tous les binaires BroadWorks 25.x. Cette opération doit être effectuée en tant qu'utilisateur racine (sudo n'est pas acceptable). Le umask est 0022 pour root et 0002 pour 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

Une fois l'installation terminée, vérifiez le résultat pour toute action ou avertissement supplémentaire. Il affiche des messages indiquant qu'une nouvelle licence est requise et que la version cible doit être activée manuellement.

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

Une fois installée, entrez la qversions commande de l'interface bwcli afin de vous assurer qu'elle est présente. Notez que l'état est Installed (pas 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

Supprimer un fichier binaire installé

Si le fichier binaire ne s'installe pas correctement ou doit être supprimé, exécutez le script uninstall-bwserver.pl.

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

Le paramètre « -r » donne l'instruction de supprimer la structure de dossiers restante dans /bw/broadworks/<server>.

Installer la licence de version cible

Cette section couvre uniquement les licences UUID (Universal Unique Identifier). Pour les licences basées sur NFM, reportez-vous à la section License Management du Network Function Manager Node and License Management Guide.

Pour les licences UUID, les fichiers de licence se trouvent dans plusieurs fichiers zip. Le serveur attend le fichier zip contenant les fichiers .txt et .sig. Ne décompressez pas les fichiers sur un ordinateur local pour copier simplement les fichiers .txt et .sig, car cela invalide la signature.

Importer une licence depuis la CLI

Inutile de décompresser les fichiers de licence et d'utiliser le chemin d'accès complet.

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

Installer la licence à partir du système d'exploitation

Il n'est pas nécessaire de décompresser les fichiers de licence et d'utiliser le chemin complet, comme bwadmin ou root run.

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

Installer la licence à partir du système d'exploitation pour convertir XSP en ADP

Vous devez accéder au dossier de version cible ADP cd /usr/local/broadworks/ADP_Rel_2024.11_1.311/ et exécuter le script install-license.pl

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

Exécuter l'outil UpgradeCheck

Exécutez l'upgradeCheckoutil à partir de l'interface bwcli et vérifiez qu'il n'y a aucun avertissement.

Un exemple du système autonome est illustré ci-dessous :

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)

Le NFM met en oeuvre les fonctions de gestion du réseau et des licences.

Assurez-vous que healthmon ne présente aucun problème :

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

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

Sauvegarde et assistance technique

Avant toute mise à niveau du serveur, il est recommandé de prendre une sauvegarde et de consigner un support technique avant la mise à niveau :

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

Pré-mise à niveau

Exécutez l'outil upgradeCheck afin de vous assurer qu'aucun avertissement n'est émis :

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

Vérifiez si la surveillance du réseau est présente sur le NFM en cours de mise à niveau

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

Commutateur de mise à niveau NFM

Dans un cluster NFM, si le NFM exécute la surveillance du réseau, le NFM qui agit en tant que principal de surveillance du réseau doit être mis à niveau en premier et le serveur qui est en veille de surveillance du réseau doit être mis à niveau en second. Si la surveillance du réseau n'est pas utilisée, la mise à niveau peut avoir lieu dans n'importe quel ordre. Les serveurs NFM doivent toujours être mis à niveau individuellement.

Lancez la mise à niveau en entrant la commande suivante :

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

Gestion des licences sur le NFM

Reportez-vous au NFM Node and License Management Guide.

Contrôles post-mise à niveau NFM

Après la mise à niveau, vérifiez l'état NFM après le démarrage :

• healthmon -l
• showrun
• bwshowver
• mdbctl status
• Si la surveillance du réseau est active :pgctl status
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.NFM.Rel_2022.11_1.274.<date-time>.log pour détecter d'éventuelles erreurs d'activation.
• Si le NFM exécute NetworkMonitoring, assurez-vous que l'application a été réactivée dans la version cible.

Tests de post-mise à niveau NFM recommandés

Vérifiez que les applications connectées aux serveurs NFM peuvent effectuer des transactions de base de données.

Ces tests sont génériques, exécutez tout test supplémentaire dans le plan de test post-mise à niveau.

NFM Server Revert

La procédure de rétablissement NFM est la même que pour les autres serveurs.

Le retour NFM à R21.SP1 n'est pas pris en charge car le chiffrement de base de données n'est pas pris en charge dans cette version. Nous devons utiliser l'option de retour ici. La restauration d'un cluster NFM crée des temps d'arrêt pour les applications, car la base de données doit être arrêtée sur tous les membres du cluster pour restaurer la sauvegarde de la base de données.

Les étapes détaillées de rétablissement sont disponibles dans le Guide de configuration de NFM.

Rétablir

Si le NFM ne réussit pas les vérifications post-mise à niveau, revenez à la version précédente.

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

Dans l'exemple, il revient à 2022.10_1.318 mais peut être remplacé par n'importe quelle version précédente.

Serveur de base de données (DBS)

Comme la solution DBS exécute un moteur de base de données (Oracle 11g) différent de celui des autres produits BroadWorks, les conditions préalables à la mise à niveau, les étapes de mise à niveau et les commandes de sauvegarde sont très différentes de celles du reste de la suite BroadWorks. Lisez attentivement cette section et n'hésitez pas à demander des tickets d'information au Centre d'assistance technique (TAC) afin d'obtenir les clarifications nécessaires.

Une différence qui ressort, pour la DBS, et la DBS uniquement, commencez par mettre à niveau le serveur en veille. Cela est possible car la mise à niveau de la base de données ne modifie pas réellement le schéma de la base de données. Cela se produit lorsque CCReportingDBManagement est mis à niveau. Avec une mise à niveau DBS, le logiciel et la base de données sont mis à niveau mais le schéma ne change pas.

D'autres particularités incluent la nécessité de redémarrer les serveurs avant d'exécuter une mise à niveau, ainsi que la suppression manuelle des tâches planifiées (afin de ne pas interférer avec la mise à niveau).

Tout ce dont vous avez besoin est décrit en détail dans les sections suivantes. 

Sauvegarder les deux DBS

Notez la taille des DONNÉES à l'aide de la dbsctl diskinfo commande.

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

L'espace requis pour la sauvegarde est d'environ 1/7^e de celui-ci.

Entrez les commandes suivantes pour effectuer la sauvegarde :

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$

Notez que la sauvegarde est exécutée en tant qu'utilisateur Oracle et qu'elle doit donc être écrite dans un emplacement pour lequel Oracle dispose d'autorisations d'écriture. Assurez-vous que l'espace disque est suffisant pour gérer cette opération sur la partition.

Les sauvegardes complètes peuvent être exécutées à l'aide de : cette commande :

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

Arrêter DBSObserver

Pour les configurations redondantes, arrêtez l'application DBSObserver sur l'ADP lors de la mise à niveau :

bwadmin@<ps1>$ stopbw DBSObserver

Le serveur DBSOb est déployé sur l'un des ADP. Afin de déterminer si un ADP donné exécute le DBSObserver, regardez le résultat de la  showrun commande sur l'ADP.

Contrôles de santé préalables à la mise à niveau

Assurez-vous que la réplication fonctionne et qu'elle est saine et que les bases de données sont correctement en place à l'aide de la dbsctl status commande sur les deux bases de données.

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 

Étapes obligatoires avant la mise à niveau

Supprimer les tâches planifiées du planificateur

Les tâches planifiées ont été identifiées comme étant à l'origine de l'échec de la mise à niveau et du retour automatique à la version source. Commencez par prendre note de la configuration initiale :

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

Supprimez ensuite les tâches planifiées. Attention lorsque vous supprimez une tâche, les numéros d'identification changent. Commencez par supprimer l'ID le plus élevé.

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

Vérifiez que les entrées ont été supprimées à l'aide de la get commande.

Redémarrer le serveur (init 6) avant la mise à niveau

Veillez à redémarrer chaque serveur avant de procéder à la mise à niveau. Là encore, cela permet d'éviter les échecs de mise à niveau. Comme nous effectuons toujours la mise à niveau sur un serveur DBS de secours, elle n'affecte rien et ne provoque pas plus de changements de rôles que d'habitude.

Reportez-vous au schéma de la séquence de mise à niveau pour la commande. L'initialisation 6 est exécutée après la sauvegarde et avant l'activation de chaque serveur.

Lancer la mise à niveau

La DBS diffère de tous les autres serveurs BroadWorks en ce sens que la DBS secondaire/de secours est mise à niveau en premier. Si vous commencez par le serveur actif ; il nécessite un redémarrage supplémentaire / changement de rôle.

En veille/secondaire :

DBS_CLI/Maintenance/ManagedObjects> lock

Basculer vers la version cible :

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

Une fois terminé, déverrouillez le serveur :

DBS_CLI/Maintenance/ManagedObjects> unlock

Vérifiez healthmon afin de vous assurer que la DBS a démarré correctement.

Basculement de la DBS SECONDAIRE/EN VEILLE récemment mise à niveau vers l'état Actif/Principal

Remarque : Exécutez cette commande sur le serveur récemment mis à niveau (et non sur le serveur de base de données de la version précédente).

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

À ce stade, la DBS mise à niveau (dbs2) est désormais principale.

Vérifications après mise à niveau du serveur de base de données

• Passer un appel à un centre d'appels et récupérer les rapports qui montrent cet exercice.
• Récupérer des rapports historiques.
• Vérifiez les journaux XSL sur le système autonome afin de confirmer que les données sont envoyées à DBS2 (et non dans la file d'attente de fichiers).

Mise à niveau de l'ancien serveur principal (désormais en veille)

Sur l'ancien commutateur principal <dbs1> (maintenant en veille), verrouillez :

DBS_CLI/Maintenance/ManagedObjects> lock

Basculez-le vers la version de destination :

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

Déverrouillez la base de données dbs1 principale :

DBS_CLI/Maintenance/ManagedObjects> unlock

Effectuez la permutation comme configuration d'origine et la configuration de secours comme configuration principale.

Rétablissez DBS1 sur primary à l'aide de la peerctl setPrimary dbs1 commande.

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 

Réinitialiser le planificateur comme avant

Puisque nous avons supprimé les tâches planifiées du planificateur, nous devons les ajouter à nouveau. Juste au cas où, voici tous les chronométrages 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

Vérifications post-mise à niveau du serveur de base de données principal

• Passer un appel à un centre d'appels et récupérer les rapports qui montrent cet exercice.
• Récupérer des rapports historiques.
• Vérifiez les journaux XSL sur le système autonome afin de confirmer que les données sont envoyées à DBS1 (et non dans la file d'attente de fichiers).

Vérifier l'expédition des fichiers de journalisation, de réplication et de santé :

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

Effectuez cette opération sur les deux DBS afin de confirmer qu'ils sont en bonne santé après la mise à niveau.

Valider l'intégrité à partir de l'ADP

À partir de l'ADP exécutant CCReportingDBManagement, entrez les commandes suivantes :

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

Démarrer DBSObserver

Une fois les deux DBS mis à niveau, démarrez l'application DBSObserver pour contrôler le basculement :

bwadmin@ADP1$ startbw DBSObserver
Starting DBSObserver...

Procédure de restauration du serveur de base de données

La procédure globale de rétablissement du serveur de base de données est très similaire à la procédure générale de rétablissement de BroadWorks décrite dans le Guide de gestion du logiciel BroadWorks.

Les principales différences sont les suivantes :

• La restauration n'est pas prise en charge. Seul le retour est pris en charge.
• Pour les configurations redondantes, la restauration du logiciel s'effectue d'abord sur le site de secours.
• Une vérification après rétablissement (voir Serveur de base de données > Procédure de rétablissement du serveur de base de données > Étapes procédurales détaillées > Vérification après rétablissement) doit être exécutée après l'activation du logiciel pour vérifier si le rétablissement de la base de données a été effectué correctement et si une action corrective est nécessaire.   

Restauration refusée

Toute tentative de restauration de la version logicielle active sur le serveur de base de données est refusée, comme indiqué dans cet exemple :

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.

Étapes de procédure détaillées

Les étapes requises pour rétablir Cisco BroadWorks sur un serveur autonome et sur une configuration de serveur redondant sont identiques et doivent être effectuées dans un ordre spécifique. Ces étapes couvrent les deux configurations.

1. Activez l'ancienne version de Cisco BroadWorks. Pour les configurations redondantes, le serveur en veille doit être réinitialisé en premier. Lorsque vous rétablissez la veille, ne spécifiez pas d'emplacement de sauvegarde.
2. Pour les configurations redondantes, procédez à l'inversion du serveur principal.
3. Effectuez la vérification post-rétablissement.

Afin d'ajouter de la clarté aux étapes correspondant au diagramme de séquence, lorsque nous rétablissons SiteB de secours, nous ne spécifions pas le fichier de sauvegarde. Mais nous pouvons spécifier le fichier de sauvegarde lorsque nous rétablissons SiteA. Vous pouvez également restaurer le fichier de sauvegarde à l'étape suivante. L'étape de synchronisation en veille synchronise ensuite les données entre SiteA et SiteB.

Opération De Rétablissement

L'opération de rétablissement est initiée à partir du niveau ManagedObject de l'interface de ligne de commande BroadWorks. Comme pour les autres types de serveurs, l'emplacement de sauvegarde peut être spécifié directement dans l'interface de ligne de commande, comme indiqué dans cet exemple :

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?

Cependant, lorsque l'opération de rétablissement est effectuée sur le site de secours, ne spécifiez pas l'emplacement de sauvegarde. Le site de secours est recréé à partir du site principal à l'aide de importdb.pl après l'opération de rétablissement ou automatiquement resynchronisé par le script de rétablissement lui-même. Une fois le rétablissement terminé, consultez les résultats du test de rétablissement pour les actions correctives recommandées.

En outre, si la restauration est exécutée avant la mise à niveau du serveur principal, la base de données exécutée sur le serveur principal n'est toujours pas affectée par la mise à niveau et le serveur de secours peut être restauré en toute sécurité vers la version précédente sans nécessiter d'opération de restauration ou de resynchronisation.

Le journal de sortie de cette commande affiche la séquence de rétablissement au démarrage sans spécifier de répertoire de sauvegarde :

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

Vérification après rétablissement

Le script post-revertcheck est conçu pour déterminer si la restauration de la base de données a été effectuée correctement et si une action corrective est nécessaire.  Il doit être exécuté à partir du dernier répertoire bin de BroadWorks, en utilisant le chemin complet ou le préfixe de barre oblique (./) :

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

Restaurer la sauvegarde

Si un répertoire de sauvegarde a été spécifié avec la commande set activeSoftwareVersion server, la sauvegarde est automatiquement restaurée par le processus de rétablissement.

Sinon, la sauvegarde doit être restaurée à l'aide de la commande suivante :

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

Synchroniser la veille

Si la veille doit être resynchronisée avec la base de données, le importdb.pl script est utilisé.

Cette commande est utilisée pour resynchroniser la base de données sur le site B si la base de données principale sur le site A n'a pas été mise à niveau :

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

Si le site A a été mis à niveau et rétabli, la base de données de secours doit être recréée à partir du site principal et la redondance doit être reconfigurée. Pour ce faire, cette commande est utilisée à la place :

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

La procédure de rétablissement pour la DBS est détaillée plus en détail dans le Guide de configuration de DBS.

Revenir à l'état de pré-mise à niveau du commutateur principal/de secours

Une fois le rétablissement terminé, utilisez la peerctl commande pour rétablir l'état principal/veille avant la mise à niveau des serveurs. Exemple :

bwadmin@dbs1$ peerctl setPrimary dbs1

Si le serveur DBSOb n'est pas en cours d'exécution sur l'ADP, démarrez-le.

Serveur de base de données réseau (NDS)

Assurez-vous que healthmon ne présente aucun problème :

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

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

Sauvegarde et assistance technique

Avant toute mise à niveau du serveur, il est recommandé de procéder à une sauvegarde complète et de consigner une demande d'assistance technique auprès de avant la mise à niveau :

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

$ tech-support >> tsup_hostname_sourceRelease.txt

Contrôle de mise à niveau

Exécutez l'outil upgradeCheck afin de vous assurer qu'aucun avertissement n'est émis :

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

Commutateur de mise à niveau NDS

Dans un cluster, l'ordre dans lequel les NDS sont mis à niveau n'est pas pertinent. Toutefois, mettez à niveau une seule fois à la fois. Lancez la mise à niveau en entrant la commande suivante :

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

Contrôles après mise à niveau NDS

Après la mise à niveau, vérifiez l'état NDS après le démarrage :

• healthmon -l
• showrun
• bwshowver
• mdbctl status
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.NDS.Rel_2022.11_1.273.<date-time>.log pour détecter d'éventuelles erreurs d'activation.

Tests de post-mise à niveau NDS recommandés

Vérifiez que les applications connectées au NDS sont capables d'effectuer des transactions de base de données.

Ces tests sont génériques, exécutez tout test supplémentaire dans le plan de test post-mise à niveau.

Restauration du serveur NDS

La restauration d'un cluster NDS crée des temps d'arrêt pour les applications, car la base de données doit être arrêtée sur tous les membres du cluster afin de restaurer la sauvegarde de la base de données.

La procédure de rétablissement NDS est la même que pour les autres serveurs.

Rétablir

Si le NDS ne réussit pas les vérifications post-mise à niveau, revenez à la version précédente :

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

Dans l'exemple, il revient à 2022.08_1.352 mais peut être remplacé par n'importe quelle version précédente.

Serveur réseau (NS)

Notez que le NS est maintenant RI.

Assurez-vous que healthmon ne présente aucun problème

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

Sauvegarde et assistance technique

Avant toute mise à niveau du serveur, il est recommandé de prendre une sauvegarde et de consigner un fichier de support technique :

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

Pré-mise à niveau

Effectuez un appel de test qui appelle le NS et vérifiez qu'un message 302 réussi se trouve dans le journal NSXSLog situé dans /var/broadworks/logs/routingserver/.

Exécutez l'outil upgradeCheck afin de vous assurer qu'aucun avertissement n'est émis :

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

Vérifiez le nombre actuel d'appels, etc., utilisés avec la qcurrent commande :

NS_CLI/Monitoring/Report> qcurrent

Vérifier la synchronisation de base de données (synchcheck_basic.pl -a) sur tous les NS homologues non primaires :

$ synchcheck_basic.pl -a

Commutateur principal de mise à niveau NS

Lancez la mise à niveau en entrant la commande suivante :

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

Mettez à jour les statistiques de la base de données en exécutant le bwPeriodMaint.sh script.

$ bwPeriodMaint.sh

Contrôles post-mise à niveau NS

Après la mise à niveau, vérifiez l'état NS après le démarrage.

• healthmon -l
  • Il indique que l'homologue est désynchronisé, mais ceci est attendu jusqu'à ce que le secondaire soit mis à niveau.
  • Si healthmon indique que certaines tailles de page de base de données sont dépassées, saisissez check_dbpages.pl networkserver modify.
• showrun
• bwshowver
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.log pour détecter d'éventuelles erreurs d'activation.
• Exécutez les tests NS pour vous assurer que ce NS traite correctement les appels.

Tests post-mise à niveau recommandés pour NS

• Validez la redirection 302 entrante du réseau téléphonique public commuté (RTPC).
• Validez la redirection 302 sortante AS.
• Validez la requête/réponse AS vers MS.
• Validez l'accès CLI (connectez-vous et accédez à NS_CLI/System/Device/HostingNE ; entrez la commande get).
• Validez l'accès Web au NS (si activé).
• Validez la recherche utilisateur à partir d'un ADP en utilisant la communication en mode NS en vous connectant simplement à un ADP.

Activités post-mise à niveau NS

Vérifiez que le NS n'est pas configuré pour empêcher les ADP de se connecter à un AS d'une version différente. Définissez ADP Version Equal sur false pour chaque élément hostNE sous NS_CLI/System/Device/HostingNE>.

NS Revert

Si le NS ne réussit pas les vérifications post-mise à niveau, revenez à la version précédente :

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

Dans l'exemple, il revient à 2022.09_1.340 mais peut être remplacé par n'importe quelle version précédente.

Comme le NS secondaire possède une version actuelle de la base de données de la version source, la base de données peut être importée à partir de cette version.

Sur le NS secondaire,

$ repctl start

Sur le NS principal,

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

Déverrouillez les bases de données NS secondaires (et toutes les autres) :

$ peerctl unlock

Vérifiez que la réplication s'exécute sur le NS principal réinitialisé :

$ repctl status

Vérifiez que la réplication s'exécute sur tous les NS secondaires et que la base de données est déverrouillée :

$ repctl status

Vérifiez tous healthmon -l les NS. Assurez-vous que le niveau de gravité indiqué est NOTIFICATION pour tous les serveurs.

Vérifiez que les bases de données NS secondaire et NS principale sont synchronisées (sur les bases de données secondaires) :

$ synchcheck_basic.pl -a

Commutateur de mise à niveau NS secondaire

Lancez la mise à niveau en entrant la commande suivante :

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

Il n'est pas nécessaire d'exécuter le script de mise à jour des statistiques, car il a été exécuté avant l'importation qui a été effectuée automatiquement lors de la mise à niveau du NS secondaire.

Contrôles post-mise à niveau NS

Après la mise à niveau, vérifiez l'état NS après le démarrage

• healthmon -l
  • Si healthmon indique que certaines tailles de page de base de données sont dépassées, saisissezcheck_dbpages.pl networkserver modify.
• showrun
• bwshowver
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.log pour détecter d'éventuelles erreurs d'activation.
• Exécutez les tests NS pour vous assurer que ce NS traite correctement les appels.

Tests post-mise à niveau recommandés pour NS

En verrouillant le NS principal, cette commande achemine tout le trafic via le NS secondaire :

• Validez la redirection 302 entrante PSTN.
• Validez la redirection 302 sortante AS.
• Validez la requête/réponse AS vers MS.
• Validez l'accès CLI (connectez-vous et accédez à NS_CLI/System/Device/HostingNE ; entrez la commande get).
• Validez l'accès Web au NS (si activé).
• Validez la recherche utilisateur à partir d'un XSP à l'aide de la communication en mode NS en vous connectant simplement à un XSP.
• Tests post-cluster.
• Assurez-vous que healthmon signale la NOTIFICATION de gravité pour tous les serveurs.
• Vérifiez la synchronisation de base de données.

$ healthmon -l
$ synchcheck_basic.pl –a

Serveur multimédia (MS)

Assurez-vous que healthmon ne présente aucun problème :

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

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

Sauvegarde et assistance technique

Avant toute mise à niveau du serveur, il est recommandé de prendre une sauvegarde et de consigner un support technique avant la mise à niveau. Sur le MS, cela ne fonctionnerait pas avec :

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

Pré-mise à niveau

Effectuez un appel test qui appelle la réponse vocale interactive (IVR) ou récupérez une messagerie vocale et assurez-vous qu'elle fonctionne comme prévu et que l'appel est visible dans les journaux.

Exécutez l'outil upgradeCheck afin de vous assurer qu'aucun avertissement n'est émis :

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

Vérifiez le nombre actuel de ports utilisés avec la qcurrent commande.

MS_CLI/Monitoring/Report> qcurrent

Avant de commencer l'activation de la nouvelle version, définissez l'état MS sur Offline dans NS pour arrêter l'envoi des médias à partir du NS

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

NS_CLI/System/Device/ResourceNE> get
About to filter through 2 entries. Continue?

Please confirm (Yes, Y, No, N): y
Retrieving data... Please wait...
 Resource NE Type Location Stat Cost Stat Weight Poll OpState State Dflt Dflt Cost Dflt Weight Services 
======================================================================================================================
      ms1    ms    1847744        1         99  false enabled OffLine true      1       99       all 
      ms2    ms    1847744        1         99  false enabled OnLine  true      1       99       all 

2 entries found.

NS_CLI/System/Device/ResourceNE> 

Commutateur de mise à niveau MS

Lancez la mise à niveau en exécutant la commande suivante :

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

Contrôles MS post-mise à niveau

Après la mise à niveau, vérifiez l'état de MS après le démarrage et assurez-vous de laisser une messagerie vocale et de la récupérer.

• healthmon -l
• showrun
• bwshowver
• set back the MS state to onLine in NS to receive the media

Tests post-mise à niveau recommandés pour MS

• Validez le dépôt et la récupération de la messagerie vocale.
• Validez l'interaction IVR réussie.
• Validez l'appel à trois interlocuteurs réussi.

Ces tests sont génériques, exécutez tout test supplémentaire dans le plan de test post-mise à niveau.

MS Revert

Si le MS ne réussit pas les vérifications post-mise à niveau, revenez à la version précédente.

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

Dans l'exemple précédent, il revient à 2022.08_1.350 mais peut être remplacé par n'importe quelle version précédente.

Serveur d'applications (AS)

Assurez-vous que healthmon ne présente aucun problème

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

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

• Vérifiez les journaux pour vous assurer que les deux AS traitent les appels (forcer de nouveaux appels vers le secondaire peut être fait en verrouillant AS1).
• Validez l'accès Web via les serveurs Web et chaque système autonome.

Sauvegarde et assistance technique

Il est recommandé de prendre une sauvegarde et de consigner un support technique avant la mise à niveau.

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

Pré-mise à niveau

Exécutez l'outil upgradeCheck pour vous assurer qu'aucun avertissement n'est émis.

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

Remarque : Si upgradeCheck échoue en raison de fichiers dans le répertoire /var/broadworks/eccr ou /var/broadworks/ecl, attendez qu'une « force de verrouillage » soit exécutée à partir de l'interface de ligne de commande bwcli. Les fichiers sont ainsi purgés dans la base de données en quelques minutes.

Vérifiez la synchronisation de base de données (synchcheck_basic.pl -a) sur le système autonome secondaire :

$ synchcheck_basic.pl -a

Définissez l'extensionTimeInSeconds sur 10800 (trois heures) pour correspondre à la durée réservée pour la mise à niveau du serveur :

AS_CLI/System/Registration> set extensionTimeInSeconds 10800

Ce paramètre est généralement défini lorsque vous ne mettez pas à niveau 2400, conformément au Guide de configuration du système.

La réplication répercute cette modification sur les serveurs restants du cluster.

Supprimez l'opération de sauvegarde du planificateur :

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

Si la sauvegarde est déclenchée lors de la mise à niveau, elle entraîne des problèmes lors de l'activation :

AS_CLI/Maintenance/Scheduler> del 5

Verrouiller le système autonome principal

Verrouiller le système autonome principal, les nouveaux appels passent par le système secondaire, ce qui permet d'abandonner le nombre d'appels actifs sur le système principal avant d'effectuer le commutateur (la commutation ou la force de verrouillage entraîne l'abandon des appels actifs) :

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

Une fois terminé, vérifiez le nombre d'appels sur le système autonome à l'aide de la qcurrent commande suivante :

AS_CLI/Monitoring/Report> qcurrent

Commutateur de mise à niveau AS principal

Une fois que les appels ont atteint un niveau acceptable, commencez la mise à niveau avec :

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

Une fois terminé, déverrouillez le serveur :

AS_CLI/Maintenance/ManagedObjects> unlock

Mettez à jour les statistiques de base de données avec bwPeriodMaint.sh:

$ bwPeriodMaint.sh

Cette commande ne renvoie aucun résultat.

Comme nous avons supprimé l'opération de sauvegarde du planificateur, nous devons l'ajouter à nouveau après la mise à niveau. Il s'agit de la valeur suggérée. Nous devons le rajouter à la valeur qui a été configurée avant la mise à niveau :

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

Actions principales post-mise à niveau du système autonome

Contrôles post-mise à niveau AS

Après la mise à niveau, vérifiez l'état du système autonome après le démarrage et les enregistrements et appels.

• healthmon -l
  • Il indique que l'homologue est désynchronisé, mais ceci est attendu jusqu'à ce que le secondaire soit mis à niveau.
• showrun
• bwshowver
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411 .<date-heure>.log pour détecter d'éventuelles erreurs d'activation.
• Exécutez des tests AS pour vous assurer que ce système autonome traite correctement les appels.

Tests de post-mise à niveau AS recommandés

• Validez les appels sortants SIP.
• Validez les appels sortants MGCP (Media Gateway Control Protocol).
• Validez les appels entrants PSTN vers SIP.
• Validez les appels entrants PSTN vers MGCP des utilisateurs.
• Valider la sortie/récupération de la messagerie vocale (portail vocal).
• Valider les origines/terminaisons CommPilot.
• Validez l'accès CLI (accédez à AS_CLI/System/Alias et utilisez la commande get).
• Validez l'accès Web direct au système autonome.

Invites vocales localisées

Si vous effectuez une mise à niveau vers R25, les invites audio personnalisées sont copiées automatiquement à partir de la version source. Reportez-vous à la Section 4.5 de la Description de la fonctionnalité.

AS Revert

Si le système autonome ne réussit pas les vérifications de post-mise à niveau, revenez à la version précédente.

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

Dans l'exemple, il revient à 2022.08_1.354, mais peut être remplacé par n'importe quelle version précédente.

Comme le système autonome secondaire possède une version actuelle de la base de données, importez la base de données à partir de cette dernière.

Sur le système autonome secondaire :

$ repctl start

Sur le système autonome principal :

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

Déverrouiller la base de données AS secondaire :

$ peerctl unlock

Vérifiez que la réplication s'exécute sur le système autonome principal restauré :

$ repctl status

Vérifiez que la réplication s'exécute sur le système autonome secondaire et que la base de données est déverrouillée :

$ repctl status
$ peerctl unlock

Vérifiez tous healthmon -l les AS. Assurez-vous que le niveau de gravité indiqué est NOTIFICATION pour tous les serveurs.

Vérifiez que les bases de données du système autonome secondaire et du système autonome principal sont synchronisées (sur le système secondaire) :

$ synchcheck_basic.pl -a

Commutateur de mise à niveau AS secondaire

Lancez la mise à niveau en entrant la commande suivante :

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

Mettez à jour les statistiques de la base de données en exécutant le bwPeriodMaint.sh script :

$ bwPeriodMaint.sh

Actions secondaires post-mise à niveau du système autonome

Contrôles post-mise à niveau AS

Après la mise à niveau, vérifiez l'état du système autonome après le démarrage et les enregistrements et appels.

• healthmon -l
• showrun
• bwshowver
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411.<date-time>.log pour détecter d'éventuelles erreurs d'activation.
• Exécuter des tests AS afin de s'assurer que ce AS traite correctement les appels.

Tests de post-mise à niveau AS recommandés

• Verrouillez le système autonome principal pour forcer les nouveaux appels vers le système autonome secondaire.
• Validez les appels sortants SIP.
• Validez les appels sortants MGCP.
• Validez les appels entrants PSTN vers SIP.
• Validez les appels entrants PSTN vers MGCP des utilisateurs.
• Valider la sortie/récupération de la messagerie vocale (portail vocal).
• Valider les origines/terminaisons CommPilot.
• Validez l'accès CLI (accédez à AS_CLI/System/Alias et utilisez la commande get).
• Validez l'accès Web direct au système autonome.

Test Post-Cluster

• Assurez-vous que healthmon signale la NOTIFICATION de gravité pour tous les serveurs.
• Vérifier la synchronisation de base de données :

$ healthmon -l
$ synchcheck_basic.pl –a

Fonction de contrôle des services (SCF)

Assurez-vous que healthmon ne présente aucun problème :

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

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

• Vérifiez les journaux pour vous assurer que le SCF traite les appels.

Sauvegarde et assistance technique

Avant toute mise à niveau du serveur, il est recommandé de prendre une sauvegarde et de consigner un support technique avant la mise à niveau. Pour ce faire, vous devez :

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

Pré-mise à niveau

Testez les appels à partir du réseau mobile afin de vous assurer que le fonctionnement actuel fonctionne normalement.

Exécutez l'outil upgradeCheck afin de vous assurer qu'aucun avertissement n'est émis :

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

En cas de configuration redondante, verrouillez le serveur pour forcer les appels vers l'autre SCF :

SCF_CLI/Maintenance/ManagedObjects> lock

Commutateur de mise à niveau SCF

Une fois que les appels ont atteint un niveau acceptable, commencez la mise à niveau avec :

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

Une fois terminé, déverrouillez le serveur et testez les appels :

SCF_CLI/Maintenance/ManagedObjects> unlock

Contrôles SCF post-mise à niveau

Après la mise à niveau, vérifiez les journaux SS7 pour un bon démarrage :

• healthmon -l
• showrun
• bwshowver
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.SCF.Rel_2023.03_1.411.<date-time>.log pour détecter d'éventuelles erreurs d'activation.
• Exécutez des tests pour vous assurer que ce SCF traite correctement les appels.
• Confirmez que les appels du réseau mobile vers le coeur de réseau BroadWorks fonctionnent comme avant la mise à niveau.

Restauration du serveur SCF

Si le SCF ne réussit pas les vérifications post-mise à niveau, revenez à la version précédente :

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

Dans l'exemple, il revient à 202.10_1.313 mais peut être remplacé par n'importe quelle version précédente.

Plate-forme ADP (Application Delivery Platform)

Assurez-vous que healthmon ne présente aucun problème :

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

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

Sauvegarde et assistance technique

Avant toute mise à niveau du serveur, il est recommandé de prendre une sauvegarde et de consigner un support technique avant la mise à niveau. Pour ce faire, il faut :

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

Pré-mise à niveau

Exécutez l'outil upgradeCheck pour vous assurer qu'aucun avertissement n'est émis :

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

Verrouiller le serveur avant l'activation de la nouvelle version du logiciel :

ADP_CLI/Maintenance/ManagedObjects> lock

Annuler le déploiement et désactiver l'application ECLQuery lors du passage d'ADP/PS sur R23 à RI

Avant de mettre à niveau l'ADP vers le dernier RI, nous devons migrer l'application ECLQuery vers le NDS SI l'application ECLQuery est en cours d'exécution sur l'ADP/PS source sur R23. Reportez-vous à la Description de la fonctionnalité Migration améliorée du journal des appels du serveur de base de données vers le serveur de base de données réseau.

ADP_CLI/Maintenance/ManagedObjects> undeploy application /ECLQuery

ADP_CLI/Maintenance/ManagedObjects> deactivate application /ECLQuery

Si ce n'est pas le cas, une alarme « bwCentralizedDatabaseListenerFailure » s'affiche sur l'ADP après l'activation de la nouvelle version.

Télécharger les applications ADP RI/RA correspondant aux applications déployées sur la version source

Le serveur ADP BroadWorks nécessite que les versions RI/RA des applications actuellement déployées sur la version source soient téléchargées à partir de Cisco.com. Afin d'obtenir la liste des applications requises, complétez ces actions.

Sur l'ADP, saisissez :

$ 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

Toutes les applications répertoriées après les « Informations sur les applications » sont des applications qui sont déployées sur l'ADP et qui nécessitent le téléchargement des versions compatibles avec l'ADP à partir de Cisco.com. Téléchargez les dernières versions disponibles. Exemples d'applications basés sur l'exemple précédent :

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

Copiez les fichiers bwar / war téléchargés dans l'ADP et placez-les dans le répertoire /usr/local/broadworks/apps :

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

Le reste de la mise à niveau est une mise à niveau BroadWorks normale.

Pré-mise à niveau

Exécutez l'outil upgradeCheck afin de vous assurer qu'aucun avertissement n'est émis :

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

Commutateur de mise à niveau ADP

Lancez la mise à niveau en entrant la commande suivante :

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

Actions post-mise à niveau ADP

Mettre à niveau les applications

L'application WebContainer est automatiquement mise à niveau. Les autres applications sont de deux types : les applications Cisco BroadWorks et les applications Web. La procédure de mise à niveau est différente selon que l'application est une application Cisco BroadWorks ou une application Web.

• Les applications Cisco BroadWorks sont regroupées dans un fichier BroadWorks Archive (.bwar).
• Applications Web, regroupées sous forme de fichier Web ARchive (.war)

Entrez la qbw commande permettant de voir quelle version est actuellement active pour chaque application et son chemin de contexte déployé.

Mise à niveau des applications Web

Les applications Web sont mises à niveau en désactivant et en dédéployant la version actuelle, puis en activant et en déployant la nouvelle version :

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

Mise à niveau des applications Cisco BroadWorks

Les applications Cisco BroadWorks sont mises à niveau à partir de l'interface bwcli à l'aide de la commande  set activeSoftwareVersion application.

Pour plus d'informations, reportez-vous aux Notes de version des applications et au Guide de configuration de la plate-forme de déploiement d'applications.

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

Restauration des applications ADP

Si, pour une raison quelconque, l'application doit être restaurée vers une version précédente, le processus est similaire à une mise à niveau. Les modifications de configuration effectuées après la mise à niveau et avant la restauration sont perdues après l'exécution de l'opération de restauration, car elles ont été apportées à la version de logiciel non active.

Restauration des applications Web

Les applications Web sont réinitialisées en désactivant et en dédéployant la version actuelle, puis en activant et en déployant la nouvelle version :

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

Restauration des applications Cisco BroadWorks

Les applications Cisco BroadWorks sont rétablies à partir de l'interface bwcli à l'aide de la commande  set activeSoftwareVersion application  suivante :

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

Contrôles post-mise à niveau ADP

Après la mise à niveau, vérifiez les journaux pour un bon démarrage et connectez-vous à l'interface utilisateur graphique comme avant.

• healthmon -l
• showrun
• bwshowver
• Consultez le fichier /var/broadworks/logs/maintenance/ setactiveserver.ADP.Rel_2023.03.0_1.1411.<date-time>.log pour détecter d'éventuelles erreurs d'activation.

Tests de post-mise à niveau ADP recommandés

• Vérifiez la connexion au niveau administrateur.
• Vérifiez la connexion au niveau utilisateur.
• Validez la fonctionnalité Call Manager de CommPilot.
• Validez la fonctionnalité Call Control Client (par exemple, BroadWorks Assistant-Enterprise) et Operations Support System (OSS)/Open Client Interface (OCI).
• Vérifiez que tout provisionnement de proxy Open Client Server (OCS) vers le système autonome ou le système autonome fonctionne correctement.

Ces tests sont génériques, exécutez tout test supplémentaire dans le plan de test post-mise à niveau.

Revenir au serveur ADP

Si l'ADP ne réussit pas la vérification post-mise à niveau, revenez à la version précédente :

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

Dans l'exemple, il revient à 202.10_1.313 mais peut être remplacé par n'importe quelle version précédente.