Guida all'aggiornamento da BroadWorks 2.0

Introduzione

Questo documento descrive considerazioni e requisiti per pianificare un aggiornamento dalla versione di origine di BroadWorks 2.0.

Panoramica

BroadWorks release 22.0 supporta gli aggiornamenti alle release 23.0 e 24.0. La release 2.0 è End of Maintenance (EoM), la 23.0 è EoM alla fine di luglio 2024, e la 24.0 EoM è prevista per la fine di luglio 2026. L'aggiornamento alla versione 24.0 è il percorso consigliato.

Versioni indipendenti

A partire dalla versione 23.0, MS è indipendente dalla release (RI) e alla versione 24.0 tutti i server ad eccezione di AS Release Independent. 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 all'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 4 cifre
• mm è il mese a 2 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 termina il 20 giugno 2024 con 2024.07.

Il supporto per Linux 9 è disponibile da 2023.09+.

Versioni principali di Linux supportate

R22: 5,9+, 6,5+, 7
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+: 7, 8
2023.09+: 7, 8, 9

Versioni Linux supportate da Database Server (DBS)

DBS R22: 5,9+, 6,5+
DBS da 2018.11 a 2020.08: 6,5+, 7
da DBS 2020.11 a 2022.06: solo 7,5+
DBS 2022.07+: 7,5+, 8,5+

Aggiornamenti del sistema operativo

BroadWorks non supporta un aggiornamento sul posto tra le principali versioni di Linux. Si consiglia di eseguire uno scambio hardware, creare un nuovo server sulla versione Linux di destinazione ed eseguire la migrazione del server esistente al nuovo server. Fare riferimento alla sezione 5.2.6 della Guida alla gestione del software e alla sezione 12.2 della Guida alla manutenzione.

Non è consigliabile utilizzare uno swap hardware per aggiornare contemporaneamente BroadWorks o per eseguire uno swap hardware e un aggiornamento BroadWorks nella stessa finestra di manutenzione. I server con un database devono passare attraverso il processo di aggiornamento; un database di una versione di BroadWorks non può essere importato 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.

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

È necessario eseguire l'aggiornamento di Database Server (DBS) in più passaggi per eseguire l'aggiornamento all'ultima versione di RI a causa delle restrizioni del sistema operativo. DBS 2.0 supporta Linux 5 e 6. Se si esegue Linux 5, il DBS non può eseguire l'aggiornamento oltre la versione 2.0. Le build di rilascio indipendenti del DBS non supportano Linux 5. Se si esegue Linux 6, il DBS può eseguire l'aggiornamento a 2020.08. Il DBS deve quindi passare a Linux 7, dove può eseguire di nuovo 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

2.0: Oracle 11
Da 2018.11 a 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 dovrebbe essere testato in laboratorio per verificare i tempi previsti per la produzione. Fare riferimento alle note sulla versione del DBS, sezione 6, BWKS-3069 e alla guida alla configurazione del DBS, sezione 6.5.7.3.

Registri chiamate migliorati

L'ECL (Enhanced Call Logs) non è più disponibile nel DBS dopo DBS 2020.08. È necessario eseguire la migrazione del database ECL a un server di database di rete (NDS, Network Database Server) per continuare a utilizzare il database. 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 a 24.0 è compatibile con l'UMS a 22.0 e 21.sp1. Si sconsiglia di aggiornare UMS alla versione 2.0. La versione UMS a 22.0 utilizza MariaDB invece di Oracle TimesTen che richiede passaggi aggiuntivi per l'aggiornamento, dispone di un metodo procedurale 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.

Sistema di gestione degli elementi e server licenze virtuale

Il sistema di gestione degli elementi (EMS) e il server di licenze virtuali (VLS) sono fuori produzione (EoL) a partire dal secondo trimestre 2018 e la loro funzionalità è stata sostituita da Network Function Manager (NFM). Non è disponibile un percorso di aggiornamento al modulo NFM o la disattivazione di alcun nodo EMS o VLS.

Network Function Manager

Se si implementa il monitoraggio della rete, è necessario eseguire un passaggio aggiuntivo: dall'aggiornamento 22.0 a 2020.11 e quindi a 2022.08+.

Aggiornamento alla versione 23.0 su Linux 6

Se si esegue l'aggiornamento di un server applicazioni alla versione 23.0 su Linux 6, non è necessario applicare più patch, altrimenti l'aggiornamento non riesce. "Rel_2.0/v1.450/ ". Non applicare queste patch all'ASA durante l'aggiornamento alla versione 23.0: AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 e AP.as.23.0.1075.ap385453.

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 22.0, 23.0 e 24.0.
Note release 23.0

Note release 24.0
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. Per l'aggiornamento alla versione 24.0, richiedere la conversione delle licenze PS e XSP in licenze ADP; l'ADP non accetta licenze PS o XSP.

Allineamento dell'indice di rischio alla release principale

2018.xx = R22
2019.01 to 2020.06 = R23
2020.07 to 2022.07 = R24

Procedure ottimali

Richiedi supporto

Il supporto per l'aggiornamento diretto è disponibile presso il team di aggiornamento BroadWorks.

Il team BroadWorks Upgrade fornisce supporto per gli aggiornamenti a una versione 'in support' corrente, per laboratorio e produzione, una volta all'anno in base al contratto di manutenzione e supporto. Il team che si occupa dell'aggiornamento può fornire supporto per la preparazione dell'aggiornamento e supporto in tempo reale durante l'aggiornamento, che può includere tecnici Cisco che eseguono l'aggiornamento in remoto. L'ambito del team di aggiornamento è limitato solo all'attività di aggiornamento e non fornisce supporto diretto per i problemi che devono essere risolti prima dell'aggiornamento, ad esempio gli aggiornamenti dell'hardware o del sistema operativo o il debug di problemi preesistenti. Inoltre, non fornisce test completi successivi all'aggiornamento oltre ai controlli generali dello stato del server.

Contattare il team per l'aggiornamento di BroadWorks, tramite il team degli account, oppure inviare un messaggio di posta elettronica all'indirizzo bwupgrade@cisco.com. Il supporto per l'upgrade in tempo reale non è disponibile con breve preavviso, se ne pianifica l'implementazione in anticipo.

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 alcuni giorni prima 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.

Dopo l'aggiornamento, ogni server deve essere sottoposto a test 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 6 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 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 prestabilito (in un'ora non occupata). Aggiornare sempre un nodo alla volta e verificare 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.