Introduzione
Questo documento descrive considerazioni e requisiti per pianificare un aggiornamento dalla versione di origine di BroadWorks 24.0.
Panoramica
BroadWorks release 24.0 supporta gli aggiornamenti alle release 25.0 e 26.0. La release 24.0 End of Maintenance (EoM) è stata annunciata per la fine di luglio 2026. Tutti i server eseguono l'aggiornamento all'ultima versione Indipendente disponibile (consultare la sezione della matrice di compatibilità software intitolata 'Mappe di aggiornamento supportate') fino al 2028.07.
Versioni indipendenti
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.
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
R24 6,5+, 7, 8
R25 6,5+, 7, 8
Versioni Linux supportate indipendenti dalla release
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
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 del sistema operativo. 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.
Quando si esegue l'aggiornamento dei server ADP alla versione 2025.07 o successiva, la versione Java JRE presenta una modifica che complica l'aggiornamento se le applicazioni Release Independent e Release Anchored sono mescolate nel server ADP. Per ulteriori informazioni, consultare questa Guida.
DBS
Il DBS è End of Life. 2024.09 è la versione finale delle applicazioni DBS ed ECCR. L'ECCR deve essere sostituito da CCER. Per ulteriori informazioni sulle opzioni per il DBS, fare riferimento a questo documento. Una volta terminato l'ECCR, il DBS deve essere disattivato.
Enhanced Call Logs (ECL)
ECL è la fine del ciclo di vita nel DBS dopo DBS 2020.08. È necessario eseguire la migrazione del database ECL a un server di database di rete (NDS) 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.
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 25.0
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 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
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.
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.
Feedback