Guida all'aggiornamento da BroadWorks 23.0

Introduzione

Questo documento descrive le considerazioni e i requisiti per pianificare un aggiornamento dalla release di origine di BroadWorks 23.0.

Panoramica

BroadWorks release 23.0 supporta gli aggiornamenti alle release 24.0 e 25.0. La release 23.0 era EoM alla fine di luglio 2024, mentre la release 24.0 End of Maintenance (EoM) è prevista per la fine di luglio 2026. Aggiornamento di server non applicativi all'ultima versione disponibile - Versione indipendente (consultare la sezione Compatibilità software "Mappe di aggiornamento supportate"). Gli Application Server vengono aggiornati alla versione 2024.07. Dopo l'aggiornamento di tutti i server, gli Application Server devono essere aggiornati alla versione più recente fino alla versione 2026.07.

Versioni indipendenti

A partire dalla versione 23.0, MS è indipendente dalla release (RI), alla versione 24.0 tutti i server ad eccezione dell'RI Application Server (AS) e alla versione 25.0 tutti i server sono indipendenti dalla release. Tutte le nuove funzionalità, i bug e le correzioni alla sicurezza vengono fornite in una nuova versione. Le patch non sono disponibili, ma è necessario aggiornare i server da una versione a un'altra per ottenere una correzione. Ogni mese viene rilasciata una nuova versione di ciascun server (anziché pacchetti di patch mensili) o più frequentemente se è necessario un intervento urgente.

Le versioni RI utilizzano un formato diverso dal formato standard Rel_24.0_1.944. Questo formato Ri è Server_Rel_yyyy.mm_x.xxx:

• Il server è MS, ad esempio:
• aaaa è l'anno a quattro cifre
• mm è il mese a due cifre
• x.xxx è la release incrementale del mese

MS_Rel_2022.11_1.273.Linux-x86_64.bin è una versione di MS rilasciata nel novembre 2022. Spesso viene abbreviato in 2022.11 se non si riferisce a un tipo di server specifico o a una versione incrementale.

Requisiti del sistema operativo

Verificare che il sistema operativo di origine sia supportato dalla release di destinazione.

I sistemi operativi supportati sono Red Hat Enterprise Linux, Oracle Linux e CentOS 7. CentOS 8, CentOS Stream, Rocky Linux e Alma Linux non sono supportati.

Il supporto per Linux 6 è terminato il 30 aprile 2023 con 2023.05.
Il supporto per Linux 7 è terminato il 20 giugno 2024 con 2024,07.

Il supporto per Linux 9 è disponibile da 2023.09+.

Versioni principali di Linux supportate

R23 5.9+, 6.5+, 7 e 8.x (richiesto ap385046)
R24 6,5+, 7, 8

Versioni Linux supportate indipendenti dalla release

2018.01+: 5,9+, 6,5+, 7
2019.10+: 6,5+, 7
2020.07+: 6,5+, 7, 8
2023.05+: 10, 8

2023.10+: 7, 8, 9 (Linux 9 non è supportato sull'ASA fino al 2024.04)

2024.04+: 7, 8, 9
2024.07+: 10, 9

Versioni Linux supportate da Database Server (DBS)

dal 2018.11 al 2020.08: 6,5+, 7
da 2020.11 a 2022.06: Solo 7.5+
2022.07+: 7,5+, 8,5+

2024.07+: 8,5+

2024.09: Versione finale/Fine del ciclo di vita

Aggiornamenti del sistema operativo

Storicamente, BroadWorks non supporta gli aggiornamenti sul posto tra le principali versioni di Linux. In genere, è consigliabile eseguire uno scambio hardware, creare un nuovo server sulla versione Linux di destinazione e migrare il server esistente sul nuovo server. A partire dalla versione 2023.12, gli aggiornamenti in-place di Linux sono supportati da Linux 7 a 8 e da 8 a 9. Per eseguire un aggiornamento in-place di Linux, i server devono prima essere aggiornati alla versione 2023.12 o successive.

Per la documentazione sugli aggiornamenti Linux sul posto, consultare la sezione 9 della Guida alla gestione del software. Per la documentazione sul processo di sostituzione dell'hardware, consultare sezione 5.2.6 della Guida alla gestione del software e sezione 12.2 della Guida alla manutenzione.

Non è consigliabile utilizzare uno swap hardware per aggiornare contemporaneamente BroadWorks o per eseguire uno swap hardware o un aggiornamento Linux sul posto e un aggiornamento BroadWorks nella stessa finestra di manutenzione. I server con un database devono passare attraverso il processo di aggiornamento; Impossibile importare un database di una versione di BroadWorks in un'altra versione di BroadWorks.

Limitazioni all'aggiornamento e note specifiche del server

Aggiornamento del server dei profili e della piattaforma di servizio estesa alla piattaforma di distribuzione delle applicazioni

A partire dalla versione 24.0, Profile Server (PS) e Extended Service Platform (XSP) diventano lo stesso tipo di server, noto come Application Delivery Platform (ADP). I server PS e XSP vengono aggiornati e diventano il tipo di server ADP dopo l'aggiornamento. Quando si esegue l'aggiornamento dalla versione 23.0, PS e XSP possono eseguire l'aggiornamento solo fino alla versione 2024.07. Dopo tale aggiornamento, è necessario aggiornare di nuovo l'ADP per ottenere la versione più recente.

Sono necessarie una licenza ADP e una versione aggiornata delle app distribuite. Gli aggiornamenti XSP devono essere eseguiti dopo l'aggiornamento degli Application Server (AS). Sul portale di download sono disponibili versioni RRI di PS e XSP, ma solo per i sistemi che distribuiscono il server Execution Server (XS) al posto del server ASA. Tutti i sistemi dotati di ASA devono aggiornare PS e XSP a ADP.

Le applicazioni Cisco BroadWorks e le applicazioni Web devono essere aggiornate manualmente su XSP, PS e ADP.

Server di database

Per eseguire l'aggiornamento all'ultima versione di IR a causa delle restrizioni del sistema operativo, è necessario eseguire l'aggiornamento in più passaggi del server di database (DBS). DBS 2.0 supporta Linux 5 e 6. Se si esegue Linux 5, la DBS non può eseguire l'aggiornamento oltre la versione 2.0. Le build RI della DBS non supportano Linux 5. Se si esegue Linux 6, la DBS può eseguire l'aggiornamento alla versione 2020.08. La DBS deve quindi passare a Linux 7 per eseguire nuovamente l'aggiornamento. Quando si aggiornano DBS e PS, le versioni di DBManagement e DBSObserver devono corrispondere alla versione di DBS per garantire che la versione Oracle sottostante corrisponda per la compatibilità.

Allineamento release DBS e release Oracle

22.0: Oracle 11
dal 2018.11 al 2020.08: Oracle 12
2020.11+: Oracle 19

L'aggiornamento di DBS verrà ignorato

È possibile ignorare l'aggiornamento di DBS e importare il database dalla versione 2.0 direttamente in DBS 2022.03+. Tuttavia, questo processo non è rapido e deve essere testato in laboratorio per verificare i tempi previsti per la produzione. Fare riferimento alla sezione 6 Note sulla versione di DBS, BWKS-3069 e alla Guida alla configurazione di DBS, alla sezione 6.5.7.3.

Registri chiamate migliorati

I registri di chiamate avanzate (ECL) non sono più disponibili nel DBS dopo DBS 2020.08. È necessario eseguire la migrazione del database ECL a un server di database di rete (NDS) per continuare a utilizzarlo. La migrazione non è automatica. Per ulteriori informazioni, consultare la guida alla soluzione dei registri di chiamate migliorati e la descrizione della funzionalità dei registri di chiamate migliorati NDS. Per la procedura di migrazione, consultare la Guida alla configurazione di Network Database Server per la configurazione di un NDS e la descrizione delle funzionalità di migrazione ECL da DBS a NDS. La migrazione deve essere eseguita prima dell'aggiornamento.

Server di collaborazione

L'EoM per Messaging Server (UMS), Sharing Server (USS), Video Server (UVS), WebRTC Server (WRS), Business Communicator Client (BTBC) e Connect Client era il 31 gennaio 2022. L'ultima versione di RI disponibile per UMS è la 22.0, mentre per USS, UVS e WRS l'ultima versione disponibile è la 202.01.

L'ASA versione 24.0 è compatibile con l'UMS versione 22.0 e 21.sp1. Si consiglia di non aggiornare l'UMS alla versione 22.0. La versione UMS alla 22.0 utilizza MariaDB invece di Oracle TimesTen che richiede passaggi aggiuntivi per l'aggiornamento, dispone di un metodo di procedura separato (MoP) e richiede un nodo aggiuntivo per la ridondanza. Vedere il MOP di aggiornamento UMS e la Notifica sul campo relativa a MariaDB 10.1 End of Life.

Si consiglia di sostituire i servizi di collaborazione con WebEx per BroadWorks. Fare riferimento alla Guida alle soluzioni WebEx per BroadWorks.

Verifica documentazione

Le note sulla release per la release di destinazione e le release comprese tra la release di destinazione e quella di origine devono essere riviste. Se la release di destinazione è la 24.0, è necessario esaminare le note di release relative alle versioni 24.0 e 25.0.
Note release 24.0

Note sulla release 25.0 e successive
Metodo di aggiornamento
Fare riferimento alla matrice di compatibilità software per i percorsi di aggiornamento ufficiali supportati.

Requisiti di licenza

Per la release di destinazione è richiesta una nuova licenza. Per richiedere una licenza, aprite un ticket. Richiedere la conversione delle licenze PS e XSP in licenze ADP; ADP non accetta una licenza PS o XSP.

Procedure ottimali

Notifica il supporto BroadWorks prima di un aggiornamento

Se si esegue un aggiornamento senza il supporto del team di aggiornamento, si consiglia di informare il supporto BroadWorks con alcuni giorni di anticipo con un ticket di gravità 4 (s4). Se si verifica un problema durante la manutenzione, aumentare la gravità del ticket a s1, aprire un nuovo ticket s1 o chiamare la linea di supporto per parlare con un tecnico.

Piani di test

Un piano di prova è essenziale per garantire un aggiornamento senza problemi. Prima di aggiornare la produzione, è necessario sviluppare e testare un piano di test in un laboratorio. Eseguire il piano di test sul sistema prima dell'aggiornamento e registrare i risultati. In questo modo il sistema è integro, viene verificato che tutti gli utenti e gli account di test siano configurati e funzionanti correttamente, viene offerta la possibilità di rilevare eventuali lacune nel piano di test e viene fornita una stima del tempo previsto per il test.

Ogni server deve essere sottoposto a test dopo l'aggiornamento per verificare che funzioni come previsto prima di passare al server successivo nella sequenza.

Applicazione di patch

Applicare una patch alla release di origine fino a sei mesi o meno dell'ultimo livello di patch prima di eseguire l'aggiornamento.

Script di controllo preinstallazione

Lo script di controllo pre-installazione deve essere eseguito su ogni server, laboratorio e produzione e tutti gli avvisi o gli errori devono essere risolti prima dell'aggiornamento.

Aggiornamento lab

Si consiglia sempre di testare l'aggiornamento, il piano di test e la release di destinazione con strumenti, applicazioni o client di terze parti in un ambiente lab che replica l'ambiente di produzione. Il lab può essere ridimensionato ma deve avere gli stessi tipi di server, versione del software, versione del sistema operativo, dispositivi di accesso, SBC (Session Border Control) e così via. Trattare l'aggiornamento in laboratorio come un'operazione a secco per l'aggiornamento dell'ambiente di produzione. Quando si aggiorna il lab, utilizzare il livello di patch della release di destinazione più recente. Il tempo tra l'aggiornamento in laboratorio e quello in produzione deve essere inferiore o pari a tre mesi.

Sequenza di programmazione e aggiornamento

Gli aggiornamenti devono essere eseguiti in più finestre di manutenzione distribuite in diverse notti e vengono eseguiti nell'ordine di installazione e aggiornamento, come documentato nella sezione 4.2 della guida alla gestione del software. Eseguire sempre gli aggiornamenti durante un intervallo di manutenzione predeterminato (in un'ora non occupata). Aggiornare sempre un nodo alla volta e assicurarsi che uno o più nodi di un cluster siano inattivi in un determinato momento. La lunghezza della finestra di manutenzione (MW), il numero di server da aggiornare, il tipo di server e il tempo previsto per il test determinano il numero di finestre di manutenzione necessarie. Tutti i server di un cluster devono essere aggiornati nello stesso MW. Se necessario, lasciare a disposizione il tempo di inattività per la risoluzione dei problemi e/o il rollback.

Errori di aggiornamento

Se viene rilevato un problema durante il test successivo all'aggiornamento o se l'aggiornamento non riesce, raccogliere i registri prima di ripristinare la versione di origine o il server. Eseguire il backup dell'intera directory dei log per garantire la conservazione di tutti i log potenzialmente utili. Aprire immediatamente un biglietto e chiamare il Supporto per l'assistenza mentre ancora in MW.

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
1.0	06-Aug-2026	Versione iniziale