Gids voor Upgrading van BroadWorks 22.0

Inleiding

Dit document beschrijft overwegingen en vereisten om te helpen bij het plannen van een upgrade vanaf de bronrelease van BroadWorks 2.0.

Overzicht

BroadWorks release 2.0 ondersteunt upgrades naar releases, 23.0 en 24.0. Release 22.0 is End of Maintenance (EoM), 23.0 is EoM eind juli 2024, en 24.0 EoM wordt eind juli 2026 verwacht. Upgraden naar 24.0 is het aanbevolen pad.

Onafhankelijke versies vrijgeven

Vanaf release 23.0 is de MS Release Independent (RI) en op 24.0 alle servers behalve de AS Release Independent. Alle nieuwe functies, bugs en security fixes worden geleverd in een nieuwe versie. Patches zijn niet beschikbaar, in plaats daarvan moeten servers worden geüpgraded van de ene versie naar de andere om een oplossing te verkrijgen. Een nieuwe versie van elke server wordt elke maand uitgebracht (in plaats van maandelijkse patchbundels) of vaker als er een dringende oplossing nodig 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:
• yyyy is het jaar met 4 cijfers
• mm de maand met twee cijfers is
• x.xxx is de stapsgewijze release voor die maand

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

Besturingssysteemvereisten

Controleer of het besturingssysteem van de bron 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.

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

Linux 9 ondersteuning is beschikbaar vanaf 2023.09+.

Grote release ondersteunde Linux-versies

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

Releaseonafhankelijke ondersteunde Linux-versies

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

Door DBS ondersteunde Linux-versies van Database Server

DBS R22: 5,9+, 6,5+
DBS 2018.11 t/m 2020.08: 6,5+, 7
DBS 2020.11 t/m 2022.06: alleen 7.5+
DBS 2022,07+: 7,5+, 8,5+

Upgrades van besturingssysteem

BroadWorks ondersteunt geen in-place upgrade tussen grote Linux versies. Aanbevolen wordt om een hardwareswap uit te voeren, een nieuwe server op de beoogde Linux-versie te bouwen en de bestaande server naar de nieuwe server te migreren. Raadpleeg paragraaf 5.2.6 van de Software Management Guide en paragraaf 12.2 van de Onderhoudshandleiding.

Het is niet aan te raden om een hardware swap te gebruiken om BroadWorks tegelijkertijd te upgraden of om een hardware swap en 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 geïmporteerd worden in een andere versie van BroadWorks.

Upgradebeperkingen en serverspecifieke opmerkingen

Profile Server en Extended Service Platform - upgrade naar Application Delivery Platform

Vanaf release 24.0 worden de Profile Server (PS) en Xtended Service Platform (XSP) hetzelfde servertype, bekend als het Application Delivery Platform (ADP). De PS- en XSP-servers upgraden en worden na de upgrade het type ADP-server.

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

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

Databaseserver

De Database Server (DBS) moet in meerdere sprongen 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 gaan dan 2.0. Release Independent builds van de DBS ondersteunen Linux 5 niet. Als Linux 6 draait, kan de DBS upgraden naar 2020.08. De DBS moet dan hardwareswap naar Linux 7 waar het opnieuw kan upgraden. Bij het upgraden van de DBS en PS moeten de versies van DBMmanagement en DBSObserver overeenkomen met de versie van de DBS om ervoor te zorgen dat de onderliggende Oracle versie overeenkomt voor compatibiliteit.

DBS500 release en Oracle release uitlijning

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 direct in de DBS 2022.03+ te importeren. Dit proces is echter niet snel en moet worden getest in het lab om de verwachte timing voor productie te verifiëren. Raadpleeg sectie 6 van de DBS Release Notes, BWKS-3069 en sectie 6.5.7.3 van de DBS Config-gids.

Uitgebreide gesprekslogboeken

Enhanced Call Logs (ECL) is het einde van de levensduur van de DBS na DBS 2020.08. De ECL-database moet worden gemigreerd naar een Network Database Server (NDS) voor verder gebruik, de migratie is niet automatisch. Raadpleeg de Enhanced Call Logs Solution Guide en de NDS Enhanced Call Logs Feature Description voor meer informatie. Raadpleeg de configuratiehandleiding van de netwerkdatabaseserver voor het instellen van een NDS en de ECL-migratie van DBS naar NDS-functiebeschrijving voor de migratieprocedure. De migratie moet voor de upgrade worden uitgevoerd.

Collaborate servers

De End of Maintenance (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 voor de UMS is 22.0 en voor de USS, UVS en WRS is 2022.01 de laatste versie.

Het AS op 24.0 is compatibel met de UMS op 22.0 en 21.sp1. Upgraden van de UMS naar 2.0 wordt niet aanbevolen. De UMS op 22.0 gebruikt MariaDB in plaats van Oracle TimesTen, waardoor extra stappen nodig zijn om te upgraden, heeft een afzonderlijke Procedure (MOP), en vereist een extra knooppunt voor redundantie. Raadpleeg het UMS Upgrade MOP en de melding uit het veld 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.

Element-beheersysteem en virtuele licentieserver

Het Element Management System (EMS) en Virtual Licensing Server (VLS) zijn End of Life (EoL) vanaf Q2 2018 en hun functionaliteit is vervangen door de Network Functie Manager (NFM). Er is geen upgradepad naar de NFM of uitbedrijfname van EMS of VLS knooppunten.

Netwerkfunctiebeheer

Als Network Monitoring wordt geïmplementeerd, is er een extra stap vereist; van 22.0 upgrade naar 2020.11 en vervolgens naar 2022.08+.

Upgraden naar 23.0 op Linux 6

Als u een upgrade uitvoert van een Application Server naar 23.0 op Linux 6, mogen meerdere patches niet worden toegepast of de upgrade mislukt bij het patchen. "Rel_22.0/v1.450/ " Pas deze patches niet toe op het AS bij het upgraden naar 23.0: AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 en AP.as.23.0.1075.ap385453.

Documentatie bekijken

Releaseopmerkingen voor de doelrelease en eventuele releases tussen de doelrelease en de bronrelease moeten worden beoordeeld. Als de doelrelease 24.0 is, moeten de opmerkingen voor 22.0, 23.0 en 24.0 worden herzien.
23.0 Releaseopmerkingen

24.0 Releaseopmerkingen
Upgrademethode
Raadpleeg de Software Compatibility Matrix voor de officiële ondersteunde upgradepaden.

Licentievereisten

Er is een nieuwe licentie vereist voor de doelrelease. Om een licentie aan te vragen open je een ticket. Voor upgrades naar 24.0 moet u vragen dat de PS- en XSP-licenties worden geconverteerd naar ADP-licenties; de ADP accepteert geen PS- of XSP-licentie.

Uitlijning van RI naar hoofdrelease

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

Best practices

Ondersteuning aanvragen

Directe upgrade-ondersteuning is beschikbaar bij het BroadWorks Upgrade Team.

Het BroadWorks Upgrade Team biedt ondersteuning voor upgrades naar een huidige 'in support' release, voor lab en productie, eenmaal per jaar onder het onderhouds- en ondersteuningscontract. Het upgrade-team kan ondersteuning bieden bij de voorbereiding van een upgrade en real-time ondersteuning tijdens de upgrade, waaronder Cisco-engineers die de upgrade op afstand uitvoeren. Het bereik van het upgrade-team is beperkt tot de upgrade-activiteit en biedt geen directe ondersteuning voor problemen die voor de upgrade moeten worden opgelost, zoals hardware- of besturingssysteemupdates, of het debuggen van reeds bestaande problemen, en biedt geen uitgebreide tests na de upgrade die verder gaan dan algemene controles van de serverstatus.

Neem contact op met het BroadWorks Upgrade Team, via het accountteam, of e-mail naar bwupgrade@cisco.com. De beschikbaarheid voor real-time upgrade ondersteuning is niet beschikbaar op korte termijn, van te voren gepland.

BroadWorks-ondersteuning voor een upgrade melden

Als u een upgrade uitvoert zonder de ondersteuning van het upgrade-team, is het raadzaam om BroadWorks-ondersteuning een paar dagen van te voren op de hoogte te stellen met een tarief van ernst 4 (s4). Als er tijdens het onderhoud een probleem ontstaat, verhoog dan de ernst van het ticket naar S1, open een nieuw S1 ticket of bel de ondersteuningslijn om met een ingenieur te spreken.

Testplannen

Een testplan is essentieel om een soepele upgrade te garanderen. Een testplan moet worden ontwikkeld en getest in een laboratorium vóór een productieverbetering. Draai het testplan op het systeem voor de upgrade en registreer de resultaten. Dit waarborgt dat het systeem gezond is, verifieert dat alle testgebruikers en rekeningen correct worden gevormd en functionerend, biedt een kans om potentiële hiaten in het testplan te vangen en verstrekt een tijdschatting van hoe lang het testen naar verwachting zal duren.

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

Patching

Patch de bronrelease tot 6 maanden of minder van het laatste patchniveau voordat u de upgrade uitvoert.

Script voor voorinstallatie controleren

Het script voor de pre-install controle moet worden uitgevoerd op elke server, lab en productie en alle waarschuwingen of fouten die voor de upgrade worden aangepakt.

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

Scheduling en upgrade-reeks

Upgrades zullen naar verwachting plaatsvinden via meerdere onderhoudsperiodes verspreid over meerdere nachten en worden uitgevoerd in de installatie- en upgrade-volgorde zoals gedocumenteerd in paragraaf 4.2 van de Software Management Guide. Voer altijd upgrades uit tijdens een vooraf bepaald onderhoudsvenster (tijdens een niet-bezig uur). Altijd een knooppunt per keer upgraden en ervoor zorgen dat een of meer knooppunten van een cluster op een gegeven moment down zijn. De lengte van het onderhoudsvenster (MW), het aantal servers dat moet worden geüpgraded, het servertype en hoe lang testen naar verwachting zal duren, bepalen hoeveel onderhoudsvensters nodig zijn. Alle servers in een cluster moeten worden geüpgraded in dezelfde MW. Laat tijd beschikbaar in de geplande MW voor probleemoplossing en/of terugdraaiing indien nodig.

Upgradefouten

Als een probleem wordt ontdekt tijdens de tests na de upgrade of als een upgrade mislukt, verzamelt u logbestanden voordat u terugkeert naar de bronrelease of de server herstelt. Maak een back-up van de gehele logdirectory om er zeker van te zijn dat alle potentieel nuttige logbestanden worden bewaard. Open onmiddellijk een ticket en bel ondersteuning voor hulp terwijl nog in de MW.