Aggiornamento da BroadWorks release 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 22.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+: 10, 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
DBS da 2020.11 a 202.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; 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.

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 è 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 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 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.

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 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 è installato il monitoraggio della rete, è necessario un ulteriore passaggio; dalla versione 22.0 alla versione 2020.11 e quindi alla versione 202.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_22.0/v1.450/". Non applicare queste patch all'appliance 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 gli aggiornamenti alla versione 24.0, richiedere la conversione delle licenze PS e XSP in licenze ADP; ADP non accetta una licenza 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

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 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. 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 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.