Introduction
Ce document décrit les considérations et les exigences pour aider à planifier une mise à niveau à partir de la version source de BroadWorks 24.0.
Aperçu
BroadWorks version 24.0 prend en charge les mises à niveau vers les versions 25.0 et 26.0. La fin de maintenance (EoM) de la version 24.0 a été annoncée pour la fin du mois de juillet 2026. Tous les serveurs sont mis à niveau vers la dernière version indépendante de la version disponible (consultez la section Matrice de compatibilité logicielle intitulée « Mappages de mise à niveau pris en charge ») jusqu'à la version 2028.07.
Versions indépendantes de version
À la version 25.0, tous les serveurs sont indépendants de la version. 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 afin d'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.
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.
Le support de Linux 6 a pris fin le 30 avril 2023 avec 2023.05.
Le support de Linux 7 a pris fin le 20 juin 2024 avec 2024.07.
La prise en charge de Linux 9 est disponible à partir de 2023.09+.
Versions Linux prises en charge par les versions principales
R24 : 6,5+, 7, 8
R25 : 6,5+, 7, 8
Versions Linux indépendantes prises en charge
2020.07+ : 6,5+, 7, 8
2023.05+ : 7, 8
2023.10+ : 7, 8, 9 (Linux 9 n'est pas pris en charge sur les serveurs d'applications (AS) avant 2024.04)
2024.04+ : 7, 8, 9
2024.07+ : 8, 9
Versions Linux prises en charge par Database Server (DBS)
2020.11 à 2022.06 : 7,5+ uniquement
2022.07+ : 7,5+, 8,5+
2024.07+ : + de 8,5
2024.09: Version finale/fin de vie
Mises à niveau OS
BroadWorks n'a pas toujours pris en charge les mises à niveau sur place entre les principales versions de Linux. Historiquement, la recommandation était d'effectuer un remplacement de matériel, de construire un nouveau serveur sur la version Linux cible et de migrer le serveur existant vers le nouveau serveur. À partir de la version 2023.12, les mises à niveau Linux sur place sont prises en charge de Linux 7 à 8 et de 8 à 9. Pour effectuer une mise à niveau Linux sur place, les serveurs doivent d'abord être mis à niveau vers 2023.12 ou une version ultérieure.
Pour obtenir de la documentation sur les mises à niveau Linux sur place, reportez-vous à la section 9 du Guide de gestion des logiciels. Pour obtenir de la documentation sur le processus d'échange matériel, reportez-vous à la section 5.2.6 du Guide de gestion des logiciels 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 ou une mise à niveau Linux sur place et une mise à niveau BroadWorks dans la même fenêtre de maintenance. Les serveurs avec 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
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.
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 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.
Lors de la mise à niveau des serveurs ADP vers la version 2025.07 ou ultérieure, une modification de la version de Java JRE complique la mise à niveau si les applications Release Independent et Release Anchored sont mélangées sur le serveur ADP. Reportez-vous à cette aide pour plus d'informations.
SGD
La DBS est en fin de vie. 2024.09 est la version finale des applications DBS et ECCR. L'ECCR doit être remplacé par l'ECCER. Pour plus d'informations sur les options de la DBS, reportez-vous à ce document. Une fois que l'ECCR n'est plus utilisé, la DBS doit être désactivée.
Journaux d'appels améliorés (ECL)
ECL est la fin de vie sur la base de données 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.
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.
Notes de version 25.0
Notes de version 26.0
Méthode de procédure de mise à niveau (MoP)
Reportez-vous à la Matrice de compatibilité logicielle pour connaître les chemins de mise à niveau officiels pris en charge.
Conditions de licence
Une nouvelle licence est requise pour la version cible. Afin de demander une licence, ouvrez un billet. Demander que les licences PS et XSP soient converties en licences ADP ; l'ADP n'accepte pas de licence PS ou XSP.
Meilleures pratiques
Notifier l'assistance BroadWorks avant une 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, faites passer le niveau de 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 afin de 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 à six mois par rapport au dernier niveau de correctif avant de procéder à 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 tout avertissement ou échec doit être résolu 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. Limitez le délai entre la mise à niveau du laboratoire et celle de la production à trois mois maximum.
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 non-occupation). Effectuez toujours une mise à niveau d'un noeud à la fois et assurez-vous qu'un ou plusieurs noeuds d'un cluster 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 afin de 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.
Commentaires