De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft overwegingen en vereisten om te helpen bij het plannen van een upgrade vanaf de bronrelease van BroadWorks 21.sp1.
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.
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:
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.
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.
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
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
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+
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.
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 terugval verandert de serverversie terug naar de bronrelease en importeert de DB back-up die vlak voor de upgrade genomen is, alle gegevens die aan de DB toegevoegd zijn sinds de upgrade verloren is op een terugval. 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.
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.
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.
21.sp1 en 22.0: Oracle 11
2018.11 tot 2020.08: Oracle 12
2020.11+: Oracle 19
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.
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.
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.
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.
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+.
Als u een Application Server upgradt naar 23.0 op Linux 6, mogen er geen verschillende patches worden toegepast of de upgrade mislukt bij het patchen van "Rel_2.0/v1.450/
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 verschillende 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.
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.
2017.xx = R22
2018.xx = R22
2019.01 t/m 2020.06 = R23
2020,07 t/m 2022,07 = R24
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.
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.
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.
Patch de bronrelease tot 6 maanden of minder van het laatste patchniveau voordat u de upgrade uitvoert.
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.
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.
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.
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.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
18-Oct-2023 |
Eerste vrijgave |