Handleiding voor het upgraden van BroadWorks 23.0

Inleiding

Dit document beschrijft de overwegingen en vereisten om te helpen bij het plannen van een upgrade van de bronversie van BroadWorks 23.0.

Overzicht

BroadWorks Release 23.0 ondersteunt upgrades naar releases, 24.0 en 25.0. Release 23.0 was EoM eind juli 2024, en 24.0 End of Maintenance (EoM) wordt eind juli 2026 verwacht. Niet-toepassingsservers upgraden naar de meest recente versie die beschikbaar is (raadpleeg de sectie Software Compatibility Matrix getiteld 'Supported Upgrade Maps'). Toepassingsservers upgraden naar 2024.07. Zodra alle servers zijn geüpgraded, moeten de toepassingsservers opnieuw worden geüpgraded naar de nieuwste versie tot 2026.07.

Onafhankelijke versies vrijgeven

Vanaf versie 23.0 is de MS Release Independent (RI), vanaf 24.0 zijn alle servers behalve de Application Servers (AS) RI en vanaf 25.0 zijn alle servers Release Independent. Alle nieuwe functies, bugs en beveiligingsoplossingen worden geleverd in een nieuwe versie. Er zijn geen patches beschikbaar, maar servers moeten van de ene versie naar de andere worden geüpgraded om een oplossing te vinden. Elke maand wordt een nieuwe versie van elke server uitgebracht (in plaats van maandelijkse patchbundels) of vaker als een dringende oplossing vereist is.

RI-versies gebruiken een ander formaat dan het standaard Rel_24.0_1.944-formaat. Dit RI-formaat is Server_Rel_yyyy.mm_x.xxx:

• De server is bijvoorbeeld MS:
• JJJJ is het jaar met vier cijfers
• MM is de maand met twee cijfers
• X.xxx is de incrementele release voor die maand

MS_Rel_2022.11_1.273.Linux-x86_64.bin is een versie van de MS die in november 2022 is uitgebracht. Vaak wordt dit afgekort tot 2022.11 als dit niet verwijst naar een specifiek servertype of stapsgewijze versie.

Vereisten voor besturingssystemen

Controleer of het bronbesturingssysteem (OS) wordt ondersteund door de doelversie.

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

Linux 6 ondersteuning eindigde op 30 april 2023 met 2023.05.
Linux 7 ondersteuning eindigde op 20 juni 2024 met 2024.07.

Linux 9 ondersteuning is beschikbaar vanaf 2023.09+.

Belangrijkste versie ondersteunde Linux versies

R23: 5,9+, 6,5+, 7 en 8,x (ap385046 vereist)
R24: 6,5+, 7, 8

Onafhankelijke ondersteunde Linux-versies uitbrengen

2018.01+: 5,9+, 6,5+, 7
2019,10+: 6,5+, 7
2020,07+: 6,5+, 7, 8
2023.05+: 7, 8

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

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

Ondersteunde Linux-versies van Database Server (DBS)

2018,11 tot 2020,08: 6,5+, 7
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 besturingssysteem

BroadWorks heeft in het verleden geen in-place upgrades tussen de belangrijkste Linux-versies ondersteund. Historisch gezien is de aanbeveling om een hardwareswap uit te voeren, een nieuwe server te bouwen op de beoogde Linux-versie en de bestaande server naar de nieuwe server te migreren. Vanaf release 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 later.

Voor documentatie over in-place Linux-upgrades, raadpleegt u sectie 9 van de Software Management Guide. Voor documentatie over het hardwareswapproces raadpleegt u sectie 5.2.6 van de Software Management Guide en sectie 12.2 van de Maintenance Guide.

Het wordt niet aanbevolen om een hardwareswap te gebruiken om tegelijkertijd BroadWorks 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

Upgrade van profielserver en uitgebreid serviceplatform naar platform voor levering van toepassingen

Vanaf release 24.0 worden de Profielserver (PS) en het XSP-platform (Xtended Service Platform) hetzelfde servertype, bekend als het Application Delivery Platform (ADP). De PS- en XSP-servers upgraden en worden na de upgrade het ADP-servertype. Bij het upgraden van 23.0 kunnen de PS en XSP alleen upgraden tot ADP 2024.07. Daarna moet de ADP opnieuw worden geüpgraded om naar de nieuwste versie te komen.

Een ADP-licentie en een bijgewerkte versie van de geïmplementeerde apps zijn vereist. XSP-upgrades moeten plaatsvinden nadat de Application Servers (AS) zijn geüpgraded. Er zijn RI-versies van de PS en XSP op het downloadportaal, maar deze zijn alleen voor systemen die de XS-server (Execution Server) in plaats van het AS implementeren. Alle systemen met een AS moeten PS en XSP's upgraden naar ADP.

Cisco BroadWorks-toepassingen en webtoepassingen moeten handmatig worden geüpgraded op XSP, PS en ADP.

Databaseserver

De databaseserver (DBS) moet in meerdere sprongen upgraden om te upgraden naar de nieuwste RI-versie vanwege beperkingen van het besturingssysteem. DBS 22.0 ondersteunt Linux 5 en 6. Als Linux 5 wordt uitgevoerd, kan de DBS niet meer upgraden dan 22.0. RI-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 wisselen naar Linux 7 waar het opnieuw kan upgraden. Bij het upgraden van de DBS en 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 compatibiliteit.

Uitlijning DBS-release en Oracle-release

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 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 de DBS Release Notes sectie 6, BWKS-3069 en de DBS Config Guide sectie 6.5.7.3.

Verbeterde 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 met uitgebreide oproeplogboeken en de beschrijving van de NDS Enhanced Call Logs-functie voor meer informatie. Raadpleeg de Configuratiehandleiding voor netwerkdatabaseservers voor het instellen van een NDS en de beschrijving van de ECL-migratie van DBS naar NDS voor de migratieprocedure. De migratie moet vóór de upgrade worden uitgevoerd.

Servers voor samenwerking

De 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 beschikbaar 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, waardoor extra stappen nodig zijn om te upgraden, heeft een aparte methode van procedure (MoP) en vereist een extra knooppunt voor redundantie. Zie de MOP UMS-upgrade en de veldmelding over MariaDB 10.1 End of Life.

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

Documentatie controleren

Releaseopmerkingen voor de doelrelease en eventuele releases tussen de doelrelease en de bronrelease moeten worden beoordeeld. Als de doelrelease 24.0 is, moeten de releasenotes voor 24.0 en 25.0 worden herzien.
24.0 Releaseopmerkingen

25.0 en hoger Release Notes
Upgrademethode van procedure
Raadpleeg de Matrix voor softwarecompatibiliteit voor de officiële ondersteunde upgradepaden.

Licentievereisten

Een nieuwe licentie is vereist voor de doelrelease. Om een licentie aan te vragen, open je een ticket. Verzoek om omzetting van de PS- en XSP-licenties naar ADP-licenties; de ADP accepteert geen PS- of XSP-licentie.

best practices

BroadWorks-ondersteuning op de hoogte brengen voordat een upgrade wordt uitgevoerd

Als u een upgrade uitvoert zonder de ondersteuning van het upgradeteam, wordt u aangeraden om BroadWorks Support een paar dagen van tevoren op de hoogte te stellen met een ticket voor de prioriteitscode 4 (s4). Als er een probleem optreedt tijdens het onderhoud, verhoogt u de ernst van het ticket naar s1, opent u een nieuw s1-ticket of belt u 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 voorafgaand aan een productie-upgrade. Voer het testplan op het systeem uit voordat u de upgrade uitvoert en noteer de resultaten. Dit zorgt ervoor dat het systeem gezond is, verifieert of alle testgebruikers en -accounts correct zijn geconfigureerd en functioneren, biedt een mogelijkheid om potentiële hiaten in het testplan op te vangen en biedt een tijdsschatting van hoe lang het testen naar verwachting zal duren.

Elke server moet worden getest nadat deze is geüpgraded om er zeker van te zijn dat deze functioneert zoals verwacht voordat wordt overgegaan op een upgrade naar de volgende server in de reeks.

patchen

Patch de bronversie tot zes maanden of minder van het nieuwste patchniveau voordat u een upgrade uitvoert.

Controlescript vooraf installeren

Het controlescript voor de pre-installatie moet worden uitgevoerd op elke server, elk laboratorium en elke productie en alle waarschuwingen of storingen die vóór de upgrade zijn verholpen.

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 geschaald, maar moet dezelfde servertypen hebben, softwareversie, OS-versie, toegangsapparaten, Session Border Control (SBC), enzovoort. Behandel de lab upgrade als een dry run voor de productie-omgeving upgrade. Gebruik het nieuwste patchniveau voor doelrelease bij het upgraden van het lab. Houd de tijd tussen het lab en de productie-upgrade tot drie maanden of minder.

Volgorde van planning en upgrade

Upgrades zullen naar verwachting plaatsvinden over meerdere onderhoudsvensters verspreid over meerdere nachten en worden uitgevoerd in de Installatie- en upgradevolgorde zoals beschreven in sectie 4.2 van de Software Management Guide. Voer altijd upgrades uit tijdens een vooraf bepaald onderhoudsvenster (tijdens een niet-bezet uur). Upgrade altijd één knooppunt tegelijk en zorg ervoor dat één of meer knooppunten van een cluster op elk gewenst moment zijn uitgeschakeld. De lengte van het onderhoudsvenster (MW), het aantal te upgraden servers, het servertype en de duur van de tests bepalen hoeveel onderhoudsvensters nodig zijn. Alle servers in een cluster moeten in hetzelfde MW worden geüpgraded. Laat tijd vrij in het geplande MW voor probleemoplossing en/of terugdraaiing indien nodig.

Upgradefouten

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

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
1.0	06-Aug-2026	Eerste vrijgave