Guida all'aggiornamento da BroadWorks 25.0

Introduzione

Questo documento descrive considerazioni e requisiti per pianificare un aggiornamento del sistema Cisco BroadWorks dalla versione di origine 20.0.

Panoramica

Tutti i server eseguono l'aggiornamento all'ultima versione. È disponibile una versione indipendente (consultare la sezione Matrice di compatibilità software intitolata 'Mappe di aggiornamento supportate').

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 7 è terminato il 20 giugno 2024 con 2024,07.

Il supporto per Linux 9 è disponibile da 2024.04+.

Versioni Linux supportate

2020.07+: 6,5+, 7, 8
2023.05+: 10, 8

2023.10+: 7, 8, 9 (Linux 9 non è supportato sugli Application Server (AS) fino al 2024.04)

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

Versioni Linux supportate da Database Server (DBS)

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 passato, era 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

DBS

Per eseguire l'aggiornamento all'ultima versione di IR a causa delle restrizioni del sistema operativo, il DBS deve eseguire l'aggiornamento in più passaggi. DBS 2.0 supporta Linux 5 e 6. Se è in esecuzione Linux 5, DBS non può eseguire l'aggiornamento oltre la versione 2.0. Le build indipendenti dalla release della DBS non supportano Linux 5. Se è in esecuzione Linux 6, DBS può eseguire l'aggiornamento alla versione 2020.08. DBS deve quindi eseguire lo scambio hardware a Linux 7 per eseguire di nuovo l'aggiornamento. Quando si aggiornano DBS e Profile Server (PS), le versioni di DBManagement e DBSObserver devono corrispondere alla versione di DBS per garantire che la versione Oracle sottostante corrisponda ai criteri di 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 DBS e importare il database (DB) dalla versione 2.0 direttamente in DBS 202.03+. Tuttavia, questo processo non è rapido e dovrebbe 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 sezione 6.5.7.3 della Guida alla configurazione di DBS.

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

La fine della manutenzione (EoM) per i server Messaging (UMS), Sharing Server (USS), Video Server (UVS), WebRTC Server (WRS), Business Communicator Client (BTBC) e Connect Client è stata 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 a 22.0 utilizza MariaDB invece di Oracle TimesTen che richiede passaggi aggiuntivi per l'aggiornamento, dispone di un MoP separato 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.

Note release 26.0
Metodo di aggiornamento (MOP)
Fare riferimento alla matrice di compatibilità software per i percorsi di aggiornamento ufficiali supportati.

Requisiti di licenza

Per la versione di destinazione è necessaria una nuova licenza. Per richiedere una licenza, aprire un ticket.

Procedure ottimali

Notifica il supporto BroadWorks prima di un 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 il livello di 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. Un piano di test deve essere sviluppato e testato in un laboratorio prima di un aggiornamento della produzione. 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.

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 3 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. Lasciare il tempo disponibile nella MW programmata per la risoluzione dei problemi e/o il rollback, se necessario.

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	19-May-2026	Versione iniziale