Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit la méthode de procédure de mise à niveau générique (MOP) pour la mise à niveau des serveurs BroadWorks, telle qu'elle a été mise en oeuvre par l'équipe de mise à niveau BroadWorks à partir d'autres sources de documentation officielles.
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 :
Pour obtenir une assistance supplémentaire pour la mise à niveau, contactez l'équipe de mise à niveau à l'adresse bwupgrade@cisco.com.
notes de version
Avant la mise à niveau, consultez les notes de version de la version cible figurant dans le Guide de documentation Cisco BroadWorks version 25. Mesurer l'impact potentiel avec les changements notés.
Si vous effectuez une mise à niveau vers une version supérieure de plusieurs numéros majeurs à la version actuelle (par exemple, une mise à niveau de R23 vers R25), consultez les notes de version de la ou des versions intermédiaires (R24 dans cet exemple).
Vous pouvez les trouver sur la page de documentation Cisco ou via les liens fournis.
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, procédez comme suit :
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 peut être utile de vérifier les tâches terminées pour chaque serveur. Exemple :
Machine |
SERVEUR1 |
SERVEUR2 |
SERVEUR3 |
---|---|---|---|
Sauvegarde |
done |
done |
|
Support technique |
done |
...etc.. |
|
Installation de la version cible |
done |
||
Importation de licence |
done |
||
Contrôle Healthmon |
done |
||
Contrôle de mise à niveau |
done |
Ce document suppose que :
Référez-vous à la Matrice de compatibilité pour plus de détails.
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.
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.
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 seront pas 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 suivent un format différent du format standard Rel_25.0_1.944. Ce format d'adresse IP est le suivant, Server_Rel_yyy.mm_1.xxx :
Par exemple, MS_Rel_2022.11_1.273.Linux-x86_64.bin est une version de MS publiée en novembre 2022.
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.
Les programmes d'installation de BroadWorks peuvent être téléchargés à partir de Cisco BroadWorks - Downloads.
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é, entrez la commande qversions
à partir de l'interface bwcli afin de s'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
Si le fichier binaire ne s'installe pas correctement ou doit être supprimé, exécutez la commande uninstall-bwserver.pl
script.
$ 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>.
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 peuvent se trouver dans plusieurs fichiers zip. Le serveur attend le fichier zip contenant les fichiers .txt et .sig. Ne décompressez pas les fichiers sur une machine locale pour copier simplement les fichiers .txt et .sig, car cela invalide la signature.
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
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
Exécutez la commande upgradeCheck
à 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.
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. --------------------------------
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 -full -file=/var/broadworks/backup/bwBackup.bak $ tech-support >> tsup_hostname_sourceRelease.txt
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
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
Dans un cluster, l'ordre dans lequel les serveurs NFM sont mis à niveau n'est pas pertinent. Cependant, mettez-les à niveau un par un.
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
Reportez-vous au NFM Node and License Management Guide.
Après la mise à niveau, vérifiez l'état NFM après le démarrage :
healthmon -l
showrun
bwshowver
mdbctl status
pgctl status
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.
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.
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.
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. Le schéma de la séquence de mise à niveau est suivi des étapes et des commandes détaillées pour chaque étape.
Notez la taille des DONNÉES avec la dbsctl diskinfo
erasecat4000_flash:.
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/7e 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 la commande suivante :
bwadmin@dbs1$ bwBackup.pl -f -type=full -tag=$TAG -device=/var/broadworks/backup/$TAG
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 commande showrun
sur l'ADP.
Assurez-vous que la réplication fonctionne et qu'elle est saine et que les bases de données sont correctement en place avec le dbsctl status
sur les deux 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
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 avec le get
erasecat4000_flash:.
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.
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, cela nécessite un redémarrage supplémentaire / un 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.
Remarque : exécutez cette commande sur le serveur récemment mis à niveau (et non sur le serveur DBS encore présent dans 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.
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
Rétablissez la connexion DBS1 principale à l'aide de peerctl setPrimary dbs1
erasecat4000_flash:.
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
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é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.
À 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
Une fois les deux DBS mis à niveau, démarrez l'application DBSObserver pour contrôler le basculement :
bwadmin@ADP1$ startbw DBSObserver
Starting DBSObserver...
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 :
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.
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.
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ée 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, la importdb.pl
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.
Une fois le rétablissement terminé, utilisez la peerctl
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.
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.
--------------------------------
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 -full -file=/var/broadworks/backup/bwBackup.bak
$ tech-support >> tsup_hostname_sourceRelease.txt
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
Dans un cluster, l'ordre dans lequel les NDS sont mis à niveau n'est pas pertinent. Cependant, 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
Après la mise à niveau, vérifiez l'état NDS après le démarrage :
healthmon -l
showrun
bwshowver
mdbctl status
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.
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.
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.
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.
--------------------------------
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
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 le 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 principaux :
$ synchcheck_basic.pl -a
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 bwPeriodMaint.sh
script.
$ bwPeriodMaint.sh
Après la mise à niveau, vérifiez l'état NS après le démarrage.
healthmon -l
check_dbpages.pl networkserver modify
.showrun
bwshowver
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>.
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
Chèque healthmon -l
sur tous 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
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.
Après la mise à niveau, vérifiez l'état NS après le démarrage
healthmon -l
check_dbpages.pl networkserver modify
.showrun
bwshowver
En verrouillant le NS principal, cette commande achemine tout le trafic via le NS secondaire :
$ healthmon -l
$ synchcheck_basic.pl –a
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.
--------------------------------
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
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 le qcurrent
erasecat4000_flash:.
MS_CLI/Monitoring/Report> qcurrent
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
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
Ces tests sont génériques, exécutez tout test supplémentaire dans le plan de test post-mise à niveau.
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.
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.
-------------------------------
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
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 la présence 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 peut entraîner des problèmes lors de l'activation :
AS_CLI/Maintenance/Scheduler> del 5
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 avec le qcurrent
commande :
AS_CLI/Monitoring/Report> qcurrent
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
Mettre à jour les statistiques DB 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
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
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é.
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
Chèque healthmon -l
sur tous 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
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 bwPeriodMaint.sh
script :
$ bwPeriodMaint.sh
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
$ healthmon -l
$ synchcheck_basic.pl –a
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.
--------------------------------
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
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
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
Après la mise à niveau, vérifiez les journaux SS7 pour un bon démarrage :
healthmon -l
showrun
bwshowver
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.
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.
--------------------------------
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
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
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.
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. Voici des exemples d'applications basées 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.
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
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
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.
Saisissez la commande qbw
pour 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 set activeSoftwareVersion application
erasecat4000_flash:.
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
Si, pour une raison quelconque, l'application doit être restaurée vers une version précédente, le processus est similaire à une mise à niveau. Il est important de noter que certaines modifications peuvent être perdues après l'exécution de l'opération de restauration (par exemple, des modifications de configuration) car l'application active résultante est dans l'état où elle était avant la mise à niveau.
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
commande :
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
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
Ces tests sont génériques, exécutez tout test supplémentaire dans le plan de test post-mise à niveau.
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.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
21-Jul-2023 |
Première publication |