Upgrade van BroadWorks 25.0

Inleiding

In dit document worden overwegingen en vereisten beschreven voor het plannen van een Cisco BroadWorks-systeemupgrade vanaf de bronversie 20.0.

Overzicht

Alle servers upgraden naar de nieuwste versie van de onafhankelijke versie die beschikbaar is (raadpleeg de sectie Software Compatibility Matrix met de titel 'Ondersteunde upgradekaarten').

Vereisten voor het besturingssysteem

Controleer of het besturingssysteem van de bron (OS) wordt ondersteund door de doelrelease.

Ondersteunde besturingssystemen zijn Red Hat Enterprise Linux, Oracle Linux en CentOS 7. CentOS 8, CentOS Stream, Rocky Linux en Alma Linux worden niet ondersteund.

De ondersteuning voor Linux 7 eindigde op 20 juni 2024 met 2024.07.

Ondersteuning voor Linux 9 is beschikbaar vanaf 2024.04.

Ondersteunde Linux-versies

2020,07+: 6,5+, 7, 8
2023,05+: 7, 8

2023.10+: 7, 8, 9 (Linux 9 wordt niet ondersteund op de Application Servers (AS) tot 2024.04)

2024,04+: 7, 8, 9
2024,07+: 8, 9

Databaseserver (DBS) ondersteunde Linux-versies

2020.11 tot 2022.06: alleen 7.5+
2022,07+: 7,5+, 8,5+

2024,07+: 8,5+

2024.09: Einde van het leven

Upgrades van het besturingssysteem

BroadWorks heeft in het verleden geen in-place upgrades ondersteund tussen belangrijke Linux-versies. Historisch gezien was de aanbeveling om een hardwareswap uit te voeren, een nieuwe server op de Linux-doelversie te bouwen en de bestaande server naar de nieuwe server te migreren. Vanaf versie 2023.12 worden in-place Linux-upgrades ondersteund van Linux 7 naar 8 en 8 naar 9. Om een in-place Linux-upgrade uit te voeren, moeten servers eerst worden geüpgraded naar 2023.12 of hoger.

Raadpleeg sectie 9 van de Software Management Guide voor documentatie over in-place Linux-upgrades. Raadpleeg voor documentatie over het hardwareswapproces punt 5.2.6 van de Softwarebeheergids en punt 12.2 van de Onderhoudshandleiding.

Het wordt niet aanbevolen om een hardwareswap te gebruiken om BroadWorks tegelijkertijd te upgraden of om een hardwareswap of in-place Linux-upgrade en een BroadWorks-upgrade uit te voeren in hetzelfde onderhoudsvenster. Servers met een database moeten het upgradeproces doorlopen; een database van de ene versie van BroadWorks kan niet worden geïmporteerd in een andere versie van BroadWorks.

Upgradebeperkingen en serverspecifieke opmerkingen

DBS

De DBS moet in meerdere sprongen upgraden om te upgraden naar de nieuwste RI-release vanwege beperkingen van het besturingssysteem. DBS 22.0 ondersteunt Linux 5 en 6. Als Linux 5 wordt uitgevoerd, kan de DBS niet verder upgraden dan 22.0. Release Independent builds van de DBS ondersteunen Linux 5 niet. Als Linux 6 wordt uitgevoerd, kan de DBS upgraden naar 2020.08. De DBS moet dan hardware ruilen naar Linux 7 waar het opnieuw kan upgraden. Bij het upgraden van de DBS- en Profielserver (PS) moeten de versies van DBManagement en DBSObserver overeenkomen met de versie van de DBS om ervoor te zorgen dat de onderliggende Oracle-versie overeenkomt met de compatibiliteit.

DBS Release en Oracle Release Alignment

22.0: Oracle 11
2018.11 tot 2020.08: Oracle 12
2020.11+: Oracle 19

De DBS-upgrade overslaan

Er is een optie om de DBS-upgrade over te slaan en de database (DB) vanaf 22.0 rechtstreeks in de DBS 2022.03+ te importeren. Dit proces is echter niet snel en moet in het laboratorium worden getest om de verwachte timing voor de productie te verifiëren. Raadpleeg sectie 6 van de DBS Release Notes, BWKS-3069, en de DBS Configuration Guide sectie 6.5.7.3.

Uitgebreide oproeplogboeken

Enhanced Call Logs (ECL) is het einde van de levensduur op de DBS na DBS 2020.08. De ECL-database moet worden gemigreerd naar een Network Database Server (NDS) voor voortgezet gebruik, de migratie is niet automatisch. Raadpleeg de handleiding voor uitgebreide oproeplogboeken en de beschrijving van de functie voor uitgebreide oproeplogboeken van NDS voor meer informatie. Raadpleeg de configuratiehandleiding van de netwerkdatabaseserver voor het instellen van een NDS en de beschrijving van de ECL-migratie van DBS naar NDS-functie voor de migratieprocedure. De migratie moet vóór de upgrade worden uitgevoerd.

Samenwerkende servers

Het einde van het onderhoud (EoM) voor de Messaging Server (UMS), Sharing Server (USS), Video Server (UVS), WebRTC Server (WRS), Business Communicator Client (BTBC) en Connect Client was 31 januari 2022. De nieuwste RI-versie die beschikbaar is voor de UMS is 22.0 en voor de USS, UVS en WRS is de nieuwste versie 2022.01.

De AS op 24.0 is compatibel met de UMS op 22.0 en 21.sp1. Het upgraden van de UMS naar 22.0 wordt niet aanbevolen. De UMS op 22.0 maakt gebruik van MariaDB in plaats van Oracle TimesTen die extra stappen nodig hebben om te upgraden, heeft een afzonderlijke methode van procedure (MoP) en vereist een extra node voor redundantie. Zie de UMS Upgrade MOP en de Field Notification over MariaDB 10.1 End of Life.

Het wordt aanbevolen om de Collaborate-services te vervangen door WebEx for BroadWorks. Raadpleeg de WebEx for BroadWorks Solutions Guide.

Documentatie bekijken

Releasenota's voor de doelrelease en eventuele releases tussen de doelrelease en de bronrelease moeten worden beoordeeld.

26.0 Opmerkingen bij de release
Upgrade methode van procedure (MOP)
Raadpleeg de softwarecompatibiliteitsmatrix voor de officiële ondersteunde upgradepaden.

Vergunningseisen

Een nieuwe licentie is vereist voor de doelrelease. Om een vergunning aan te vragen, open je een ticket.

beste praktijken

Brede werknemersondersteuning op de hoogte brengen vóór een upgrade

Het wordt aanbevolen om BroadWorks Support een paar dagen van tevoren op de hoogte te stellen met een ticket voor ernst 4 (s4). Als er een probleem optreedt tijdens het onderhoud, verhoog dan de ernst van het ticket naar s1, open een nieuw s1-ticket of bel de ondersteuningslijn om met een technicus te praten.

Testplannen

Een testplan is essentieel om een soepele upgrade te garanderen. Een testplan moet worden ontwikkeld en getest in een laboratorium voordat een productie-upgrade wordt uitgevoerd. Voer het testplan op het systeem uit vóór de upgrade en registreer de resultaten. Dit zorgt ervoor dat het systeem gezond is, verifieert dat alle testgebruikers en accounts correct zijn geconfigureerd en functioneren, biedt de mogelijkheid om potentiële hiaten in het testplan op te vangen en biedt een schatting van de tijd die het testen naar verwachting in beslag zal nemen.

Elke server moet worden getest nadat deze is bijgewerkt om ervoor te zorgen dat deze functioneert zoals verwacht voordat wordt overgegaan naar een upgrade naar de volgende server in de reeks.

Controlescript vooraf installeren

Het controlescript voor de installatie moet op elke server, elk laboratorium en elke productie worden uitgevoerd en eventuele waarschuwingen of fouten moeten worden aangepakt voordat de upgrade wordt uitgevoerd.

Lab-upgrade

Het wordt altijd aanbevolen om de upgrade, het testplan en de doelrelease te testen met tools, toepassingen of clients van derden in een laboratoriumomgeving die de productieomgeving repliceert. Het lab kan worden verkleind, maar moet dezelfde servertypen hebben, softwareversie, OS-versie, toegangsapparaten, Session Border Control (SBC), enzovoort. Behandel de lab-upgrade als een dry run voor de upgrade van de productieomgeving. Gebruik het laatste patchniveau voor de doelrelease bij het upgraden van het laboratorium. Houd de tijd tussen het laboratorium en de productie-upgrade tot 3 maanden of minder.

Volgorde voor planning en upgrade

Upgrades zullen naar verwachting plaatsvinden via meerdere onderhoudsvensters verspreid over meerdere nachten en worden uitgevoerd in de Installatie- en Upgradevolgorde zoals beschreven in sectie 4.2 van de Softwarebeheergids. Voer altijd upgrades uit tijdens een vooraf bepaald onderhoudsvenster (tijdens een niet-druk uur). Upgrade altijd één node tegelijk en zorg ervoor dat één of meer knooppunten van een cluster op elk gewenst moment down zijn. De duur van het onderhoudsvenster (MW), het aantal te upgraden servers, het servertype en de verwachte testduur bepalen hoeveel onderhoudsvensters vereist zijn. Alle servers in een cluster moeten in hetzelfde MW worden bijgewerkt. Laat de tijd beschikbaar in het geplande MW voor probleemoplossing en/of terugdraaien indien nodig.

Upgradefouten

Als een probleem wordt ontdekt tijdens het testen na de upgrade of als een upgrade mislukt, verzamelt u logboeken voordat u terugkeert naar de bronrelease of de server terugzet. Maak een back-up van de volledige logboekdirectory om ervoor te zorgen dat alle potentieel nuttige logboeken worden bewaard. Open onmiddellijk een ticket en bel Support voor hulp terwijl u nog in de MW bent.

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
1.0	19-May-2026	Eerste vrijgave