소개
이 문서에서는 BroadWorks 22.0의 소스 릴리스에서 업그레이드를 계획하는 데 도움이 되는 고려 사항 및 요구 사항에 대해 설명합니다.
개요
BroadWorks Release 22.0은 릴리스 23.0 및 24.0으로의 업그레이드를 지원합니다. 릴리스 22.0은 EoM(End of Maintenance)이고, 23.0은 2024년 7월 말에 EoM이며, 24.0 EoM은 2026년 7월 말에 예상됩니다. 24.0으로 업그레이드하는 것이 좋습니다.
릴리스 독립 버전
릴리스 23.0부터 MS는 RI(Release Independent)이며 24.0부터는 AS Release Independent를 제외한 모든 서버가 사용됩니다. 모든 새로운 기능, 버그 및 보안 수정 사항이 새로운 버전으로 제공됩니다. 패치를 사용할 수 없습니다. 대신 해결 방법을 얻으려면 서버를 한 버전에서 다른 버전으로 업그레이드해야 합니다. 각 서버의 새 버전은 매월 릴리스되며(매월 패치 번들이 아님) 긴급한 해결이 필요할 경우 더 자주 릴리스됩니다.
RI 버전은 표준 Rel_24.0_1.944 형식과 다른 형식을 사용합니다. 이 RI 형식은 Server_Rel_yyyy.mm_x.xxx입니다.
- 서버는 MS입니다(예:
- yyyy는 4자리 연도이다
- mm은 2자리 월입니다.
- x.xxx는 해당 월의 변동분 릴리스입니다.
MS_Rel_2022.11_1.273.Linux-x86_64.bin은 2022년 11월에 릴리스된 MS의 버전입니다. 특정 서버 유형 또는 증분 버전을 참조하지 않는 경우 이를 2022.11로 축약하는 경우가 많습니다.
운영 체제 요구 사항
대상 릴리스에서 소스 OS(운영 체제)가 지원되는지 확인합니다.
지원되는 운영 체제는 Red Hat Enterprise Linux, Oracle Linux 및 CentOS 7입니다. CentOS 8, CentOS Stream, Rocky Linux 및 Alma Linux는 지원되지 않습니다.
Linux 6 지원은 2023년 4월 30일에 2023.05로 종료되었습니다.
Linux 7 지원은 2024년 6월 20일에 2024.07로 종료됩니다.
Linux 9는 2023.09 이상에서 지원됩니다.
주요 릴리스 지원 Linux 버전
R22 5.9+, 6.5+, 7
R23 5.9+, 6.5+, 7 및 8.x(ap385046 필요)
R24 6.5+, 7, 8
릴리스 독립 지원 Linux 버전
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(데이터베이스 서버) 지원되는 Linux 버전
DBS R22: 5.9 이상, 6.5 이상
DBS 2018.11 ~ 2020.08: 6.5 이상, 7
DBS 2020.11 ~ 2022.06: 7.5+ 전용
DBS 2022.07+: 7.5 이상, 8.5 이상
OS 업그레이드
BroadWorks는 주요 Linux 버전 간의 내부 업그레이드를 지원하지 않습니다. 하드웨어 스왑을 수행하고 대상 Linux 버전에 새 서버를 구축하고 기존 서버를 새 서버로 마이그레이션하는 것이 좋습니다. 소프트웨어 관리 설명서의 5.2.6절 및 유지 관리 설명서의 12.2절을 참조하십시오.
하드웨어 스왑을 사용하여 BroadWorks를 동시에 업그레이드하거나 동일한 유지 보수 창에서 하드웨어 스왑과 BroadWorks 업그레이드를 수행하는 것은 권장되지 않습니다. 데이터베이스가 있는 서버는 업그레이드 프로세스를 거쳐야 합니다. 한 버전의 BroadWorks에서 가져온 데이터베이스를 다른 버전의 BroadWorks로 가져올 수 없습니다.
업그레이드 제한 사항 및 서버별 참고 사항
프로필 서버 및 확장 서비스 플랫폼을 애플리케이션 제공 플랫폼으로 업그레이드
릴리스 24.0부터는 프로파일 서버(PS)와 확장 서비스 플랫폼(XSP)이 동일한 서버 유형(ADP(Application Delivery Platform)이라고 함)이 됩니다. PS 및 XSP 서버는 현재 위치에서 업그레이드되며 업그레이드 후 ADP 서버 유형이 됩니다.
ADP 라이센스 및 배포된 앱의 업데이트 버전이 필요합니다. XSP 업그레이드는 AS(Application Servers)를 업그레이드한 후에 수행해야 합니다. 다운로드 포털에 PS 및 XSP의 RI 버전이 있지만 이는 AS 대신 Execution Server(XS) 서버를 구축하는 시스템에만 적용됩니다. AS가 있는 모든 시스템은 PS 및 XSP를 ADP로 업그레이드해야 합니다.
Cisco BroadWorks 애플리케이션 및 웹 애플리케이션은 XSP, PS 및 ADP에서 수동으로 업그레이드해야 합니다.
데이터베이스 서버
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 업그레이드를 건너뛰고 22.0에서 DBS 2022.03+로 DB를 직접 가져오는 옵션이 있습니다. 그러나 이 프로세스는 빠르지 않으며 생산에 필요한 시간을 확인하기 위해 실험실에서 테스트해야 합니다. DBS 릴리스 노트 섹션 6, BWKS-3069 및 DBS 컨피그레이션 가이드 섹션 6.5.7을 참조하십시오.
향상된 통화 로그
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 솔루션 가이드를 참조하십시오.
Element Management System 및 Virtual Licensing 서버
EMS(Element Management System)와 VLS(Virtual Licensing Server)는 2018년 2분기부터 EoL(End of Life)이며 그 기능은 NFM(Network Function Manager)으로 대체되었습니다. NFM으로의 업그레이드 경로 또는 EMS 또는 VLS 노드의 서비스 중단이 없습니다.
네트워크 기능 관리자
네트워크 모니터링이 구축된 경우 추가 단계가 필요합니다. 22.0에서 2020.11로 업그레이드한 다음 2022.08+로 업그레이드합니다.
Linux 6에서 23.0으로 업그레이드
Application Server를 Linux 6에서 23.0으로 업그레이드할 경우 몇 가지 패치를 적용하지 않아야 합니다. 그렇지 않으면 패치 적용 시 업그레이드가 실패합니다. "Rel_22.0/v1.450/". 23.0으로 업그레이드할 때 다음 패치를 AS에 적용하지 마십시오. AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 및 AP.as.23.0.1075.ap385453.
문서 검토
대상 릴리스에 대한 릴리스 정보와 대상 릴리스와 원본 릴리스 사이의 모든 릴리스를 검토해야 합니다. 대상 릴리스가 24.0인 경우 22.0, 23.0 및 24.0에 대한 릴리스 정보를 검토해야 합니다.
23.0 릴리스 정보
24.0 릴리스 정보
절차의 업그레이드 방법
지원되는 공식 업그레이드 경로는 Software Compatibility Matrix를 참조하십시오.
라이센스 요구 사항
대상 릴리스에는 새 라이센스가 필요합니다. 라이센스를 요청하려면 티켓을 여십시오. 24.0으로 업그레이드하려면 PS 및 XSP 라이센스를 ADP 라이센스로 전환하도록 요청하십시오. adp는 PS 또는 XSP 라이센스를 승인하지 않습니다.
주요 릴리스에 대한 RI 정렬
2018.xx = R22
2019.01 to 2020.06 = R23
2020.07 to 2022.07 = R24
모범 사례
업그레이드 전에 BroadWorks 지원 부서에 알림
업그레이드 팀의 지원 없이 업그레이드를 수행할 경우, BroadWorks Support에 심각도 4(S4) 티켓으로 며칠 전에 알리는 것이 좋습니다. 유지 관리 중에 문제가 발생하면 티켓의 심각도를 S1로 높이거나, 새로운 S1 티켓을 열거나, 지원 라인에 전화하여 엔지니어와 통화하십시오.
테스트 계획
원활한 업그레이드를 위해서는 테스트 계획이 필수적입니다. 프로덕션 업그레이드 전에 테스트 계획을 개발하여 랩 환경에서 테스트해야 합니다. 업그레이드 전에 시스템에서 테스트 계획을 실행하고 결과를 기록합니다. 이를 통해 시스템이 정상 상태인지 확인하고, 모든 테스트 사용자 및 계정이 올바르게 구성되어 작동하는지 확인하고, 테스트 계획에서 잠재적인 차이를 포착할 수 있는 기회를 제공하고, 테스트가 얼마나 오래 걸릴 것으로 예상되는지에 대한 시간 예상치를 제공합니다.
각 서버는 업그레이드된 후 테스트하여 정상적으로 작동하는지 확인한 다음 시퀀스의 다음 서버로 업그레이드해야 합니다.
패치
업그레이드하기 전에 소스 릴리스를 최신 패치 수준의 6개월 이하로 패치합니다.
사전 설치 확인 스크립트
업그레이드 전에 모든 서버, 랩 및 프로덕션 및 모든 경고 또는 장애에 대해 설치 전 확인 스크립트를 실행해야 합니다.
랩 업그레이드
프로덕션 환경을 복제하는 랩 환경에서 타사 툴, 애플리케이션 또는 클라이언트를 사용하여 업그레이드, 테스트 계획 및 타겟 릴리스를 테스트하는 것이 항상 좋습니다. Lab을 축소할 수 있지만 서버 유형, 소프트웨어 버전, OS 버전, 액세스 디바이스, SBC(Session Border Control) 등이 동일해야 합니다. 랩 업그레이드를 프로덕션 환경 업그레이드를 위한 리허설로 처리합니다. Lab을 업그레이드할 때 최신 타겟 릴리스 패치 레벨을 사용하십시오. 랩과 프로덕션 업그레이드 사이의 시간을 3개월 이하로 유지합니다.
예약 및 업그레이드 순서
업그레이드는 며칠 밤 사이에 여러 개의 유지 보수 기간을 거치면서 이루어질 것으로 예상되며, 소프트웨어 관리 가이드의 4.2항에 설명된 대로 설치 및 업그레이드 주문에서 수행됩니다. 항상 사전 결정된 유지 관리 기간 동안(업무 외 시간 동안) 업그레이드를 수행합니다. 항상 한 번에 하나의 노드를 업그레이드하고 지정된 시간에 하나 이상의 클러스터 노드가 중단되었는지 확인합니다. 유지 보수 기간(MW), 업그레이드할 서버 수, 서버 유형 및 테스트에 걸리는 시간에 따라 필요한 유지 보수 기간 수가 결정됩니다. 클러스터의 모든 서버는 동일한 MW에서 업그레이드해야 합니다. 필요한 경우 문제 해결 및/또는 롤백을 위해 예약된 MW에서 사용 가능한 시간을 유지합니다.
업그레이드 실패
업그레이드 후 테스트 중에 문제가 발견되거나 업그레이드가 실패할 경우, 소스 릴리스로 되돌리거나 서버를 복원하기 전에 로그를 수집합니다. 도움이 될 수 있는 모든 로그를 유지하기 위해 전체 로그 디렉토리를 백업합니다. MW에 있는 동안 즉시 티켓을 열고 고객 지원에 지원을 요청합니다.
피드백