Upgrade van BroadWorks versie 22.0

Inleiding

In dit document worden overwegingen en vereisten beschreven om te helpen bij het plannen van een upgrade vanaf de bronversie van BroadWorks 22.0.

Overzicht

BroadWorks Release 22.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 versie 23.0 is de MS Release Independent (RI) en vanaf 24.0 zijn alle servers behalve de AS Release Independent. Alle nieuwe functies, bugs en beveiligingsoplossingen worden geleverd in een nieuwe versie. Patches zijn niet beschikbaar, in plaats daarvan moeten servers van de ene versie naar de andere worden geüpgraded om een oplossing te krijgen. Elke maand wordt een nieuwe versie van elke server uitgebracht (in plaats van maandelijkse patchbundels) of vaker als 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 MS, bijvoorbeeld:
• JJJJ is het 4-cijferige jaar
• 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 uitgebracht in november 2022. Vaak wordt dit afgekort tot 2022.11 als het niet verwijst naar een specifiek servertype of incrementele versie.

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 6 eindigde op 30 april 2023 met 2023.05.
Linux 7-ondersteuning eindigt op 20 juni 2024 met 2024.07.

Ondersteuning voor Linux 9 is beschikbaar vanaf 2023.09+.

Belangrijke 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

Onafhankelijke ondersteunde Linux-versies vrijgeven

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

Databaseserver (DBS) ondersteunde Linux-versies

DBS R22: 5,9+, 6,5+
DBS 2018.11 tot en met 2020.08: 6,5+, 7
Alleen DBS 2020.11 tot en met 2022.06: 7.5+
DBS 2022.07+: 7.5+, 8.5+

Upgrades van het besturingssysteem

BroadWorks ondersteunt geen in-place upgrade tussen grote Linux-versies. Het wordt aanbevolen 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. Zie paragraaf 5.2.6 van de Softwarebeheergids en paragraaf 12.2 van de Onderhoudshandleiding.

Het wordt niet aanbevolen om een hardwareswap te gebruiken om BroadWorks tegelijkertijd te upgraden of om een hardwareswap 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 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 versie 24.0 worden de Profielserver (PS) en het Xtended Service Platform (XSP) hetzelfde servertype, bekend als het Application Delivery Platform (ADP). De PS- en XSP-servers worden bijgewerkt en worden na de upgrade het ADP-servertype.

Een ADP-licentie en een bijgewerkte versie van de geïmplementeerde apps zijn vereist. XSP-upgrades moeten plaatsvinden nadat de toepassingsservers (AS) zijn bijgewerkt. Er zijn RI-versies van de PS en XSP op het downloadportaal, 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's upgraden naar ADP.

Cisco BroadWorks-toepassingen en webtoepassingen moeten handmatig worden bijgewerkt op XSP, PS en ADP.

Databaseserver

De databaseserver (DBS) moet in meerdere sprongen 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 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 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 DB van 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.

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.

Elementbeheersysteem en virtuele licentieserver

Het Element Management System (EMS) en Virtual Licensing Server (VLS) zijn End of Life (EoL) vanaf het tweede kwartaal van 2018 en hun functionaliteit is vervangen door de Network Function 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 toepassingsserver opwaardeert naar 23.0 op Linux 6, mogen er geen verschillende patches worden toegepast of mislukt de upgrade bij het patchen. "Rel_22.0/v1.450/". Pas deze patches niet toe op de AS bij een upgrade 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

Releasenota's voor de doelrelease en eventuele releases tussen de doelrelease en de bronrelease moeten worden beoordeeld. Als de beoogde release 24.0 is, moeten de release notes voor 22.0, 23.0 en 24.0 worden beoordeeld.
23.0 Opmerkingen bij de release

24.0 Opmerkingen bij de release
Upgrademethode van procedure
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. Voor upgrades naar 24.0 kunt u vragen om de PS- en XSP-licenties om te zetten naar ADP-licenties; de ADP accepteert geen PS- of XSP-licentie.

Afstemming van RI op Major Release

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

beste praktijken

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

Als u een upgrade uitvoert zonder de ondersteuning van het upgradeteam, wordt aanbevolen om BroadWorks Support een paar dagen van tevoren op de hoogte te stellen met een S4-ticket (ernst 4). 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 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.

lappen

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

Controlescript vooraf installeren

Het controlescript voor de installatie moet worden uitgevoerd op elke server, elk laboratorium en elke productie en alle waarschuwingen of storingen die vóór 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 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 lengte 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 tijd beschikbaar in de 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.