Guide de mise à niveau à partir de BroadWorks 21.sp1

Introduction

Ce document décrit les considérations et les exigences pour aider à la planification d'une mise à niveau à partir de la version source de BroadWorks 21.sp1.

Aperçu

BroadWorks version 21.sp1 prend en charge les mises à niveau vers les versions 22.0, 23.0 et 24.0. La version 22.0 correspond à la fin de la maintenance (EoM) et 23.0 à la fin du mois de juillet 2024. La mise à niveau vers 24.0 est le chemin recommandé.

Versions indépendantes de version

À partir de la version 23.0, le MS est Release Independent (RI) et à partir de la version 24.0, tous les serveurs sauf le AS Release Independent. Toutes les nouvelles fonctionnalités, bogues et correctifs de sécurité sont fournis dans une nouvelle version. Les correctifs ne sont pas disponibles, mais les serveurs doivent être mis à niveau d'une version à une autre pour obtenir un correctif. Une nouvelle version de chaque serveur est publiée tous les mois (au lieu de paquets de correctifs mensuels) ou plus fréquemment si une correction urgente est requise.

Les versions RI utilisent un format différent du format standard Rel_24.0_1.944. Le format de cette adresse IP est Server_Real_yyy.mm_x.xxx :

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

MS_Rel_2022.11_1.273.Linux-x86_64.bin est une version de MS publiée en novembre 2022. Il est souvent abrégé en 2022.11 s'il ne fait pas référence à un type de serveur spécifique ou à une version incrémentielle.

Configuration système requise

Vérifiez que le système d'exploitation source est pris en charge par la version cible.

Les systèmes d'exploitation pris en charge sont Red Hat Enterprise Linux, Oracle Linux et CentOS 7. CentOS 8, CentOS Stream, Rocky Linux et Alma Linux ne sont pas pris en charge.

La prise en charge de Linux 6 a pris fin le 30 avril 2023 avec 2023.05.
La prise en charge de Linux 7 se termine le 20 juin 2024 avec 2024.07.

Versions Linux prises en charge par les versions principales

R21 : 5, 6 et 7 (ap379473 requis)
R22 : 5,9+, 6,5+, 7
R23 : 5.9+, 6.5+, 7 et 8.x (ap385046 requis)
R24 : 6,5+, 7, 8

Versions Linux indépendantes prises en charge

2018.01+ : 5.9+, 6.5+, 7
2019.10+ : 6.5+, 7
2020.07+ : 6.5+, 7, 8
2023.05+ : 7, 8
2023.09+ : 7, 8, 9

Versions Linux prises en charge par Database Server (DBS)

DBS R21 : 5, 6
DBS R22 : 5,9+, 6,5+
DBS 2018.11 à 2020.08 : 6.5+, 7
DBS 2020.11 à 2022.06 : 7.5+ uniquement
DBS 2022.07+ : 7.5+, 8.5+

Mises à niveau OS

BroadWorks ne prend pas en charge une mise à niveau sur place entre les versions principales de Linux. Il est recommandé d'effectuer un remplacement matériel, de créer un nouveau serveur sur la version Linux cible et de migrer le serveur existant vers le nouveau serveur. Reportez-vous à la section 5.2.6 du Guide de gestion du logiciel et à la section 12.2 du Guide de maintenance.

Il n'est pas recommandé d'utiliser un échange matériel pour mettre à niveau BroadWorks en même temps ou d'effectuer un échange matériel et une mise à niveau BroadWorks dans la même fenêtre de maintenance. Les serveurs dotés d'une base de données doivent passer par le processus de mise à niveau ; une base de données d'une version de BroadWorks ne peut pas être importée dans une autre version de BroadWorks.

Limites de mise à niveau et remarques spécifiques au serveur

Restauration du serveur réseau

Le serveur réseau (NS) peut effectuer une mise à niveau de 21.sp1 vers RI, mais la restauration n'est pas prise en charge. Si le retour à 21.sp1 est nécessaire, une restauration est requise. Une restauration permet de restaurer la version source du serveur et d'annuler toutes les modifications apportées à la base de données tout en conservant le contenu ajouté. Un retour modifie la version du serveur en version source et importe la sauvegarde de la base de données effectuée juste avant la mise à niveau, toutes les données ajoutées à la base de données depuis la mise à niveau sont perdues lors d'un retour. La solution consiste à mettre à niveau le NS vers la version 23.0, puis vers la version RI souhaitée. Si une double mise à niveau n'est pas souhaitée, une solution de contournement, si la restauration est requise, serait de rétablir le NS, puis d'exécuter la procédure de synchronisation du serveur réseau et du serveur d'applications à partir du Guide de maintenance pour synchroniser la base de données NS avec la base de données AS.

Mise à niveau de Profile Server et Xextended Service Platform vers Application Delivery Platform

À partir de la version 24.0, Profile Server (PS) et Xextended service platform (XSP) deviennent le même type de serveur, connu sous le nom d'Application Delivery Platform (ADP). Les serveurs PS et XSP sont mis à niveau et deviennent le type de serveur ADP après la mise à niveau.

À partir de 21.sp1, la dernière version RI d'ADP vers laquelle les PS et XSP peuvent effectuer une mise à niveau est 202.07. Pour effectuer la mise à niveau vers la version 202.08+, une mise à niveau en deux étapes est nécessaire. Une licence ADP et une version mise à jour des applications déployées sont requises. Les mises à niveau XSP doivent avoir lieu après la mise à niveau des serveurs d'applications (AS). Le portail de téléchargement contient des versions RI de PS et XSP, mais uniquement pour les systèmes qui déploient le serveur d'exécution (XS) à la place du système autonome. Tous les systèmes avec un AS doivent mettre à niveau PS et XSP vers ADP.

Les applications Cisco BroadWorks et Web doivent être mises à niveau manuellement sur XSP, PS et ADP.

Serveur de base de données

Le serveur de base de données (DBS) doit effectuer une mise à niveau en plusieurs sauts pour passer à la dernière version RI en raison des restrictions du système d'exploitation. DBS 21.sp1 prend en charge Linux 5 et 6. Si vous exécutez Linux 5, la DBS peut uniquement effectuer une mise à niveau vers 2.0. Si vous exécutez Linux 6, la DBS peut effectuer une mise à niveau vers RI 2020.08. La DBS doit ensuite procéder à un remplacement matériel vers Linux 7, où elle peut à nouveau effectuer une mise à niveau. Lors de la mise à niveau de DBS et de PS, les versions de DBManagement et de DBSObserver doivent correspondre à la version de DBS pour garantir la compatibilité de la version Oracle sous-jacente.

Alignement des versions DBS et Oracle Release

21.sp1 et 22.0 : Oracle 11
2018.11 à 2020.08 : Oracle 12
2020.11+ : Oracle 19

Ignorer la mise à niveau DBS

Il existe une option permettant d'ignorer la mise à niveau DBS et d'importer la base de données de 21.sp1 directement dans la base de données 202.03+. Cependant, ce processus n'est pas rapide et doit être testé en laboratoire pour vérifier le calendrier prévu pour la production. Reportez-vous aux Notes de version de DBS section 6, BWKS-3069 et au Guide de configuration de DBS section 6.5.7.3.

Journaux d'appels améliorés

Les journaux d'appels améliorés (ECL) sont en fin de vie sur la DBS après DBS 2020.08. La base de données ECL doit être migrée vers un serveur de base de données réseau (NDS) pour une utilisation continue, la migration n'est pas automatique. Référez-vous au Guide de la solution des journaux d'appels améliorés et à la Description de la fonctionnalité des journaux d'appels améliorés de NDS pour plus d'informations. Reportez-vous au Guide de configuration du serveur de base de données réseau pour configurer un NDS et à la Description de la fonctionnalité de migration ECL de DBS vers NDS pour la procédure de migration. La migration doit être effectuée avant la mise à niveau.

Serveurs de collaboration

La fin de la maintenance (EoM) pour le serveur de messagerie (UMS), le serveur de partage (USS), le serveur vidéo (UVS), le serveur WebRTC (WRS), Business Communicator Client (BTBC) et le client Connect a été fixée au 31 janvier 2022. La dernière version RI disponible pour l'UMS est 22.0 et pour l'USS, l'UVS et le WRS, la dernière version disponible est 202.01.

L'AS à 24.0 est compatible avec un UMS à 21.sp1. La mise à niveau de l'UMS vers 22.0 n'est pas recommandée. L'UMS à la version 2.0 utilise MariaDB au lieu d'Oracle TimesTen, ce qui nécessite des étapes supplémentaires pour la mise à niveau, dispose d'une méthode de procédure (MOP) distincte et nécessite un noeud supplémentaire pour la redondance. Reportez-vous à la MOP de mise à niveau d'UMS et à la notification de champ concernant la fin de vie de MariaDB 10.1.

Il est recommandé de remplacer les services de collaboration par WebEx pour BroadWorks. Reportez-vous au Guide des solutions WebEx pour BroadWorks.

Element Management System et Virtual Licensing Server

Element Management System (EMS) et Virtual Licensing Server (VLS) sont en fin de vie (EoL) depuis le 2e trimestre 2018 et leur fonctionnalité a été remplacée par Network Function Manager (NFM). Il n'existe pas de chemin de mise à niveau vers le NFM ou de désactivation des noeuds EMS ou VLS.

Gestionnaire de fonctions réseau

Le NFM nécessite une mise à niveau en deux étapes à partir de 21.sp1. Il peut effectuer une mise à niveau vers 2019.05, puis vers 2022.08+. Si la surveillance du réseau est déployée, une étape supplémentaire est requise : de la mise à niveau de 21.sp1 vers 2019.05, puis vers 2020.11, puis vers 2022.08+.

Mise à niveau vers 23.0 sur Linux 6

Si vous mettez à niveau un serveur d'applications vers la version 23.0 sur Linux 6, plusieurs correctifs ne doivent pas être appliqués ou la mise à niveau échoue lors de l'application du correctif « Rel_22.0/v1.450/ ». N'appliquez pas ces correctifs au système autonome lors de la mise à niveau vers 23.0 : AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 et AP.as.23.0.1075.ap385453.

Consulter la documentation

Les notes de version de la version cible et de toutes les versions comprises entre la version cible et la version source doivent être révisées. Si la version cible est 24.0, les notes de version de 22.0, 23.0 et 24.0 doivent être révisées.

Notes de version 2.0
Notes de version 23.0

Notes de version 24.0
méthode de mise à niveau
Reportez-vous à la Matrice de compatibilité logicielle pour connaître les chemins de mise à niveau officiels pris en charge.
Il existe plusieurs fonctionnalités qui sont EoM à partir de la version 2.0. Ces éléments sont documentés dans la Description de la fonction de retrait du produit de fin de maintenance. Ces fonctionnalités ne sont plus disponibles après la mise à niveau.

Exigences de licence

Une nouvelle licence est requise pour la version cible. Pour demander une licence, ouvrez un billet. Pour les mises à niveau vers la version 24.0, demandez que les licences PS et XSP soient converties en licences ADP ; l'ADP n'accepte pas de licence PS ou XSP.

Alignement du RI sur la version majeure

2017.xx = R2
2018.xx = R2
2 019,01 à 2 020,06 = R23
2 020,07 à 2 022,07 = R24

Meilleures pratiques

Demander une assistance

Une assistance directe pour la mise à niveau est disponible auprès de l'équipe BroadWorks Upgrade.

L'équipe de mise à niveau de BroadWorks fournit une assistance pour les mises à niveau vers une version « in support » actuelle, pour le laboratoire et la production, une fois par an dans le cadre du contrat de maintenance et d'assistance. L'équipe de mise à niveau peut fournir une assistance pour la préparation d'une mise à niveau et une assistance en temps réel pendant la mise à niveau, qui peut inclure des ingénieurs Cisco effectuant la mise à niveau à distance. La portée de l'équipe de mise à niveau est limitée à l'activité de mise à niveau et ne fournit pas de support direct pour les problèmes qui doivent être résolus avant la mise à niveau, tels que les mises à jour matérielles ou du système d'exploitation, ou le débogage de problèmes préexistants et ne fournit pas de test post-mise à niveau complet au-delà des vérifications générales de l'état du serveur.

Contactez l'équipe de mise à niveau BroadWorks, par l'intermédiaire de l'équipe chargée du compte, ou envoyez un e-mail à l'adresse bwupgrade@cisco.com. La disponibilité d'une assistance de mise à niveau en temps réel n'est pas disponible dans un bref délai, programmée à l'avance.

Notifier l'assistance BroadWorks avant une mise à niveau

Si vous effectuez une mise à niveau sans l'assistance de l'équipe de mise à niveau, il est recommandé d'avertir l'assistance BroadWorks quelques jours à l'avance avec un ticket de gravité 4 (s4). Si un problème survient pendant la maintenance, augmentez la gravité du ticket à s1, ouvrez un nouveau ticket s1 ou appelez la ligne d'assistance pour parler à un ingénieur.

Plans de test

Un plan de test est essentiel pour garantir une mise à niveau en douceur. Un plan de test doit être développé et testé dans un laboratoire avant une mise à niveau de production. Exécutez le plan de test sur le système avant la mise à niveau et notez les résultats. Cela permet de s'assurer que le système est sain, de vérifier que tous les utilisateurs et comptes de test sont correctement configurés et qu'ils fonctionnent correctement, de détecter les éventuelles lacunes dans le plan de test et de fournir une estimation du temps nécessaire au test.

Chaque serveur doit être testé après sa mise à niveau pour s'assurer qu'il fonctionne comme prévu avant de passer au serveur suivant dans l'ordre.

Correctif

Appliquez à la version source un correctif d'une durée inférieure ou égale à 6 mois par rapport au dernier niveau de correctif avant la mise à niveau.

Script de vérification avant installation

Le script de vérification de la pré-installation doit être exécuté sur chaque serveur, laboratoire et production et tous les avertissements ou échecs doivent être résolus avant la mise à niveau.

Mise à niveau de TP

Il est toujours recommandé de tester la mise à niveau, le plan de test et la version cible avec des outils, applications ou clients tiers dans un environnement de laboratoire qui réplique l'environnement de production. Les travaux pratiques peuvent être réduits, mais doivent avoir les mêmes types de serveurs, la même version de logiciel, la même version de système d’exploitation, les mêmes périphériques d’accès, le même contrôle de frontière de session (SBC), etc. Considérez la mise à niveau des travaux pratiques comme un essai à blanc pour la mise à niveau de l'environnement de production. Utilisez le dernier niveau de correctif de la version cible lors de la mise à niveau du TP. Conserver le délai entre la mise à niveau du laboratoire et celle de la production à 3 mois ou moins. 

Séquence de planification et de mise à niveau

Les mises à niveau doivent s'effectuer sur plusieurs fenêtres de maintenance réparties sur plusieurs nuits et sont effectuées dans l'ordre d'installation et de mise à niveau, comme indiqué à la section 4.2 du Guide de gestion des logiciels. Effectuez toujours des mises à niveau pendant une période de maintenance prédéterminée (pendant une heure de disponibilité). Mettez toujours à niveau un noeud à la fois et assurez-vous qu'un ou plusieurs noeuds d'une grappe sont inactifs à un moment donné. La durée de la fenêtre de maintenance (MW), le nombre de serveurs à mettre à niveau, le type de serveur et la durée prévue des tests déterminent le nombre de fenêtres de maintenance requises. Tous les serveurs d'un cluster doivent être mis à niveau dans le même MW. Laissez du temps disponible dans le MW planifié pour le dépannage et/ou la restauration si nécessaire.

Échecs de mise à niveau

Si un problème est détecté lors du test post-mise à niveau ou si une mise à niveau échoue, collectez les journaux avant de revenir à la version source ou de restaurer le serveur. Sauvegardez l'intégralité du répertoire des journaux pour vous assurer que tous les journaux potentiellement utiles sont conservés. Ouvrez immédiatement un ticket et appelez le support technique pour obtenir de l'aide lorsque vous êtes toujours dans le MW.