Inhoud

Inleiding

Overzicht

Onafhankelijke versies vrijgeven

Besturingssysteemvereisten

Grote release ondersteunde Linux-versies

Releaseonafhankelijke ondersteunde Linux-versies

Door DBS ondersteunde Linux-versies van Database Server

Upgrades van besturingssysteem

Upgradebeperkingen en serverspecifieke opmerkingen

Terugdraaiing van netwerkservers

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

Databaseserver

DBS500 release en Oracle release uitlijning

De DBS-upgrade overslaan

Uitgebreide gesprekslogboeken

Collaborate servers

Element-beheersysteem en virtuele licentieserver

Netwerkfunctiebeheer

Documentatie bekijken

Licentievereisten

Uitlijning van RI naar hoofdrelease

Best practices

Ondersteuning aanvragen

Inleiding

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

Overzicht

BroadWorks release 21.sp1 ondersteunt upgrades naar releases 2.0, 23.0 en 24.0. Release 22.0 is End of Maintenance (EoM) en 23.0 is EoM eind juli 2024. 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.

Grote release ondersteunde Linux-versies

R21: 5, 6 en 7 (ap379473 vereist)

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 R21: 5, 6

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

Terugdraaiing van netwerkservers

De Network Server (NS) kan upgraden van 21.sp1 naar RI maar het terugdraaien wordt niet ondersteund, een omkeren is vereist als het terugkeren naar 21.sp1 is noodzakelijk. Een rollback verandert de serverversie terug naar de bronrelease en rolt alle wijzigingen terug in de DB met behoud van toegevoegde inhoud. Een terugkeer verandert de serverversie terug naar de bronversie en importeert de DB-back-up die net voor de upgrade genomen is, alle gegevens die aan de DB toegevoegd zijn sinds de upgrade verloren is op een terugkeer. De oplossing is om eerst de NS te upgraden naar 23.0 en vervolgens te upgraden naar de gewenste RI-versie. Als een dubbele upgrade niet gewenst is, zou een tijdelijke oplossing, als de terugdraaiing vereist is, zijn om de NS terug te draaien en vervolgens de procedure voor de synchronisatie van de netwerkserver en de toepassingsserver uit de onderhoudsgids te doorlopen om de NS-database te synchroniseren met de AS-database.

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.

Vanaf 21.sp1 is 2022.07 de nieuwste RI-versie van ADP die de PS en XSP’s kunnen upgraden. Voor een upgrade naar 2022.08+ is een upgrade in twee stappen vereist. 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 21.sp1 ondersteunt Linux 5 en 6. Bij Linux 5 kan de DBS alleen upgraden naar 22.0. Als Linux 6 wordt uitgevoerd, kan de DBS upgraden naar RI 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

21.sp1 en 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 21.sp1 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 vóór 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 een UMS op 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

De NFM vereist een tweefasige upgrade van 21.sp1. Het kan worden opgewaardeerd naar 2019.05 en vervolgens naar 2022.08+. Als Network Monitoring wordt geïmplementeerd, is er een extra stap vereist; van 21.sp1-upgrade naar 2019.05, vervolgens naar 2020.11 en vervolgens naar 2022.08+.

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.

2.0 Releaseopmerkingen

23.0 Releaseopmerkingen

24.0 Releaseopmerkingen

Upgrademethode

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

Er zijn een aantal functies die EoM zijn beginnend met release 2.0. Deze zijn gedocumenteerd in de beschrijving van de functie End of Maintenance Product Removal (Einde onderhoudsproduct verwijderen). Deze functies zijn na de upgrade niet meer beschikbaar.

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

2017.xx = R22

2018.xx = R22

2019.01 t/m 2020.06 = R23

2020,07 t/m 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 voorafgaand aan 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 voorafgaand aan 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 in een laboratorium worden ontwikkeld en worden getest voorafgaand aan een productieverbetering. Voer het testplan op het systeem uit vóór 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.

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.

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.