Inleiding
Dit document beschrijft overwegingen en vereisten om te helpen bij het plannen van een upgrade vanaf de bronversie van BroadWorks 24.0.
Overzicht
BroadWorks Release 24.0 ondersteunt upgrades naar releases, 25.0 en 26.0. Release 24.0 End of Maintenance (EoM) is aangekondigd voor eind juli 2026. Alle servers upgraden naar de nieuwste versie van de onafhankelijke versie die beschikbaar is (raadpleeg de sectie Software Compatibility Matrix met de titel 'Ondersteunde upgradekaarten') tot 2028.07.
Onafhankelijke versies vrijgeven
Bij 25.0 zijn alle servers 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.
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.
De ondersteuning voor Linux 7 eindigde op 20 juni 2024 met 2024.07.
Ondersteuning voor Linux 9 is beschikbaar vanaf 2023.09+.
Belangrijke release ondersteunde Linux-versies
R24: 6,5+, 7, 8
R25: 6,5+, 7, 8
Onafhankelijke ondersteunde Linux-versies vrijgeven
2020,07+: 6,5+, 7, 8
2023,05+: 7, 8
2023.10+: 7, 8, 9 (Linux 9 wordt niet ondersteund op de Application Servers (AS) tot 2024.04)
2024,04+: 7, 8, 9
2024,07+: 8, 9
Databaseserver (DBS) ondersteunde Linux-versies
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 het besturingssysteem
BroadWorks heeft in het verleden geen in-place upgrades ondersteund tussen belangrijke Linux-versies. Historisch gezien was de aanbeveling 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. Vanaf versie 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 hoger.
Raadpleeg sectie 9 van de Software Management Guide voor documentatie over in-place Linux-upgrades. Raadpleeg voor documentatie over het hardwareswapproces punt 5.2.6 van de Softwarebeheergids en punt 12.2 van de Onderhoudshandleiding.
Het wordt niet aanbevolen om een hardwareswap te gebruiken om BroadWorks tegelijkertijd 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 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 het AS is 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.
Bij het upgraden van ADP-servers naar 2025.07 of hoger is er een wijziging in de Java JRE-versie die de upgrade bemoeilijkt als Release Independent en Release Anchored-apps worden gecombineerd op de ADP-server. Raadpleeg dit Help-document voor meer informatie.
DBS
DBS staat voor End of Life. 2024.09 is de definitieve release van de DBS- en ECCR-apps. Het ECCR moet worden vervangen door het CCER. Voor meer informatie over opties voor de DBS raadpleegt u dit document. Zodra de ECCR niet langer in gebruik is, moet de DBS worden ontmanteld.
Verbeterde oproeplogboeken (ECL)
ECL is het einde van het leven 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.
Documentatie bekijken
Releasenota's voor de doelrelease en eventuele releases tussen de doelrelease en de bronrelease moeten worden beoordeeld.
25.0 Opmerkingen bij de release
26.0 Opmerkingen bij de release
Upgrade methode van procedure (MoP)
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. Verzoek om de PS- en XSP-licenties om te zetten in ADP-licenties; de ADP accepteert geen PS- of XSP-licentie.
beste praktijken
Brede werknemersondersteuning op de hoogte brengen vóór een upgrade
Het wordt aanbevolen om BroadWorks Support een paar dagen van tevoren op de hoogte te stellen met een ticket voor ernst 4 (s4). Als er een probleem optreedt tijdens het onderhoud, verhoog dan de ernst van het ticket naar s1, open een nieuw s1-ticket of bel 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 zes maanden of minder van het nieuwste patchniveau voordat u een upgrade uitvoert.
Controlescript vooraf installeren
Het controlescript voor de installatie moet op elke server, elk laboratorium en elke productie worden uitgevoerd en eventuele waarschuwingen of fouten moeten worden aangepakt voordat de upgrade wordt uitgevoerd.
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 drie 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 duur 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.
Feedback