BroadWorks 25.0에서 업그레이드 가이드

소개

이 문서에서는 소스 릴리스 20.0에서 Cisco BroadWorks 시스템 업그레이드를 계획하기 위한 고려 사항 및 요구 사항에 대해 설명합니다.

개요

모든 서버가 사용 가능한 최신 릴리스 Independent 버전으로 업그레이드합니다('지원되는 업그레이드 맵'이라는 Software Compatibility Matrix 섹션 참조).

운영 체제 요구 사항

대상 릴리스에서 소스 OS(운영 체제)가 지원되는지 확인합니다.

지원되는 운영 체제는 Red Hat Enterprise Linux, Oracle Linux 및 CentOS 7입니다. CentOS 8, CentOS Stream, Rocky Linux 및 Alma Linux는 지원되지 않습니다.

Linux 7 지원은 2024년 6월 20일에 2024.07로 종료되었습니다.

Linux 9는 2024.04 이상에서 지원됩니다.

지원되는 Linux 버전

2020.07년 이상: 6.5+, 7, 8
2023.05년 이상: 7, 8

2023.10년 이상: 7, 8, 9(Linux 9는 2024.04년까지 애플리케이션 서버(AS)에서 지원되지 않음)

2024.04+: 7, 8, 9
2024.07+: 8, 9

DBS(데이터베이스 서버) 지원되는 Linux 버전

2020.11~2022.06: 7.5+ 전용
2022.07+: 7.5 이상, 8.5 이상

2024.07+: 8.5 이상

2024.09: 최종 릴리스/단종

OS 업그레이드

BroadWorks는 지금까지 주요 Linux 버전 간의 내부 업그레이드를 지원하지 않았습니다. 지금까지는 하드웨어 스왑을 수행하고 대상 Linux 버전에 새 서버를 구축하며 기존 서버를 새 서버로 마이그레이션하는 것이 좋습니다. 2023.12 릴리스부터 Linux 7에서 8로, 8에서 9로 Linux를 즉시 업그레이드할 수 있습니다. Linux를 즉시 업그레이드하려면 먼저 서버를 2023.12 이상으로 업그레이드해야 합니다.

In-place Linux 업그레이드에 대한 설명서는 소프트웨어 관리 설명서의 섹션 9를 참조하십시오. 하드웨어 스왑 프로세스에 대한 설명서는 을 참조하십시오. 소프트웨어 관리 가이드의 섹션 5.2.6 및 유지 관리 가이드의 섹션 12.2.

BroadWorks를 동시에 업그레이드하거나 하드웨어 스왑 또는 In-place Linux 업그레이드 및 BroadWorks 업그레이드를 동일한 유지 관리 창에서 수행하기 위해 하드웨어 스왑을 사용하지 않는 것이 좋습니다. 데이터베이스가 있는 서버는 업그레이드 프로세스를 거쳐야 합니다. 한 버전의 BroadWorks에서 가져온 데이터베이스를 다른 버전의 BroadWorks로 가져올 수 없습니다.

업그레이드 제한 사항 및 서버별 참고 사항

DBS

OS 제한 때문에 DBS를 최신 RI 릴리스로 업그레이드하려면 여러 번의 점프로 업그레이드해야 합니다. DBS 22.0은 Linux 5 및 6을 지원합니다. Linux 5를 실행하는 경우 DBS는 22.0 이상으로 업그레이드할 수 없습니다. DBS의 Release Independent 빌드는 Linux 5를 지원하지 않습니다. Linux 6를 실행하는 경우 DBS는 2020.08로 업그레이드할 수 있습니다. 그러면 DBS는 다시 업그레이드할 수 있는 Linux 7로 하드웨어를 교체해야 합니다. DBS 및 프로파일 서버(PS)를 업그레이드할 때 DBManagement 및 DBSObserver의 버전이 DBS의 버전과 일치해야 기본 Oracle 버전이 호환되는지 확인할 수 있습니다.

DBS 릴리즈 및 Oracle 릴리즈 정렬

22.0: Oracle 11
2018.11~2020.08: Oracle 12
2020.11년 이상: Oracle 19

DBS 업그레이드 건너뛰기

DBS 업그레이드를 건너뛰고 데이터베이스(DB)를 22.0에서 DBS 2022.03+로 직접 가져오는 옵션이 있습니다. 그러나 이 프로세스는 빠르지 않으며 생산에 필요한 시간을 확인하기 위해 실험실에서 테스트해야 합니다. DBS 릴리스 노트 섹션 6, BWKS-3069 및 DBS 컨피그레이션 가이드 섹션 6.5.7.3을 참조하십시오.

향상된 통화 로그

ECL(Enhanced Call Logs)은 DBS 2020.08 이후의 DBS에서 단종됩니다. ECL 데이터베이스를 NDS(Network Database Server)로 마이그레이션해야 계속 사용할 수 있으며 마이그레이션이 자동으로 수행되지 않습니다. 자세한 내용은 Enhanced Call Logs Solution Guide 및 NDS Enhanced Call Logs Feature Description을 참조하십시오. 마이그레이션 절차에 대한 NDS 설정 및 DBS에서 NDS로의 ECL 마이그레이션 기능 설명은 Network Database Server Configuration Guide를 참조하십시오. 업그레이드하기 전에 마이그레이션을 수행해야 합니다.

협업 서버

메시징 서버(UMS), 공유 서버(USS), 비디오 서버(UVS), WebRTC 서버(WRS), Business Communicator Client(BTBC) 및 Connect Client에 대한 EoM(End of Maintenance)은 2022년 1월 31일이었습니다. UMS에 사용할 수 있는 최신 RI 버전은 22.0이며 USS, UVS 및 WRS에 사용할 수 있는 최신 버전은 2022.01입니다.

24.0의 AS는 22.0 및 21.sp1의 UMS와 호환됩니다. UMS를 22.0으로 업그레이드하는 것은 권장되지 않습니다. 22.0의 UMS는 Oracle TimesTen 대신 MariaDB를 사용하여 업그레이드해야 하며 별도의 MoP(Method of Procedure)가 있으며 이중화를 위해 추가 노드가 필요합니다. UMS 업그레이드 MOP 및 MariaDB 10.1 End of Life에 대한 필드 알림을 참조하십시오.

Collaborate 서비스를 BroadWorks용 WebEx로 대체하는 것이 좋습니다. WebEx for BroadWorks 솔루션 가이드를 참조하십시오.

문서 검토

대상 릴리스에 대한 릴리스 정보와 대상 릴리스와 원본 릴리스 사이의 모든 릴리스를 검토해야 합니다.

26.0 릴리스 정보
프로시저 업그레이드 방법(MOP)
지원되는 공식 업그레이드 경로는 Software Compatibility Matrix를 참조하십시오.

라이센스 요구 사항

대상 릴리스에 대해 새 라이선스가 필요합니다. 라이선스를 요청하려면 티켓을 여십시오.

모범 사례

업그레이드 전에 BroadWorks 지원 부서에 알림

심각도 4(s4) 티켓으로 며칠 전에 BroadWorks Support에 알리는 것이 좋습니다. 유지 관리 중에 문제가 발생하면 티켓의 심각도를 s1로 높이거나, 새로운 s1 티켓을 열거나, 지원 라인에 전화하여 엔지니어와 통화하십시오.

테스트 계획

원활한 업그레이드를 위해서는 테스트 계획이 필수적입니다. 프로덕션 업그레이드 전에 테스트 계획을 개발하여 랩 환경에서 테스트해야 합니다. 업그레이드 전에 시스템에서 테스트 계획을 실행하고 결과를 기록합니다. 이를 통해 시스템이 정상 상태인지 확인하고, 모든 테스트 사용자 및 계정이 올바르게 구성되어 작동하는지 확인하고, 테스트 계획에서 잠재적인 차이를 포착할 수 있는 기회를 제공하고, 테스트에 소요되는 시간을 예측할 수 있습니다.

각 서버는 업그레이드된 후 테스트해야 정상적으로 작동하는지 확인한 후 시퀀스의 다음 서버로 업그레이드해야 합니다.

사전 설치 확인 스크립트

설치 전 확인 스크립트는 모든 서버, 랩 및 프로덕션에서 실행해야 하며 업그레이드 전에 경고 또는 장애를 해결해야 합니다.

랩 업그레이드

프로덕션 환경을 복제하는 랩 환경에서 타사 툴, 애플리케이션 또는 클라이언트를 사용하여 업그레이드, 테스트 계획 및 타겟 릴리스를 테스트하는 것이 항상 좋습니다. Lab을 축소할 수 있지만 서버 유형, 소프트웨어 버전, OS 버전, 액세스 디바이스, SBC(Session Border Control) 등이 동일해야 합니다. 랩 업그레이드를 프로덕션 환경 업그레이드를 위한 리허설로 처리합니다. Lab을 업그레이드할 때 최신 타겟 릴리스 패치 레벨을 사용하십시오. 랩과 프로덕션 업그레이드 사이의 시간을 3개월 이하로 유지합니다.

예약 및 업그레이드 순서

업그레이드는 며칠 밤 사이에 여러 개의 유지 보수 기간을 거치면서 이루어질 것으로 예상되며, 소프트웨어 관리 가이드의 4.2항에 설명된 대로 설치 및 업그레이드 주문에서 수행됩니다. 항상 사전 결정된 유지 관리 기간 동안(업무 외 시간 동안) 업그레이드를 수행합니다. 항상 한 번에 하나의 노드를 업그레이드하고 지정된 시간에 하나 이상의 클러스터 노드가 중단되었는지 확인합니다. 유지 보수 기간(MW), 업그레이드할 서버 수, 서버 유형 및 테스트에 걸리는 시간에 따라 필요한 유지 보수 기간 수가 결정됩니다. 클러스터의 모든 서버는 동일한 MW에서 업그레이드해야 합니다. 필요한 경우 문제 해결 및/또는 롤백을 위해 예약된 MW에서 사용 가능한 시간을 유지합니다.

업그레이드 실패

업그레이드 후 테스트 중에 문제가 발견되거나 업그레이드가 실패할 경우, 소스 릴리스로 되돌리거나 서버를 복원하기 전에 로그를 수집합니다. 도움이 될 수 있는 모든 로그를 유지하기 위해 전체 로그 디렉토리를 백업합니다. MW에 있는 동안 즉시 티켓을 열고 고객 지원에 지원을 요청합니다.

개정 이력

개정	게시 날짜	의견
1.0	19-May-2026	최초 릴리스