4.4. RAN DU 사용 모델에 대한 엔지니어링 고려 사항
RAN DU 사용 모델은 RAN 분산 단위(DU) 워크로드를 호스팅하기 위해 상용 하드웨어에서 실행되는 OpenShift 컨테이너 플랫폼 클러스터를 구성합니다. 모델 및 시스템 수준의 고려 사항은 아래와 같습니다. 개별 구성 요소에 대한 구체적인 제한, 요구 사항 및 엔지니어링 고려 사항은 이후 섹션에서 자세히 설명합니다.
통신사 RAN DU RDS KPI 테스트 결과에 대한 자세한 내용은 통신사 RAN DU 4.19 참조 설계 사양 KPI 테스트 결과를 참조하세요. 이 정보는 고객 및 파트너사만 사용할 수 있습니다.
- 클러스터 토폴로지
RAN DU 워크로드에 권장되는 토폴로지는 단일 노드 OpenShift입니다. DU 워크로드는 필요에 따라 3노드 컴팩트 클러스터, 고가용성(3개 제어 평면 + n개 작업자 노드) 또는 SNO+1과 같은 다른 클러스터 토폴로지에서 실행될 수 있습니다. SNO+1 토폴로지보다는 여러 개의 SNO 클러스터 또는 고가용성 3노드 컴팩트 클러스터가 권장됩니다.
원격 작업자 노드(RWN) 클러스터 토폴로지는 이 참조 설계 사양에 권장되거나 포함되지 않습니다. RAN DU와 같이 서비스 수준 계약 요구 사항이 높은 작업 부하의 경우 다음과 같은 단점으로 인해 RWN이 고려 대상에서 제외됩니다.
- 이미지 기반 업그레이드에 대한 지원이 없고, 더 빠른 업그레이드와 롤백 기능 등 해당 기능이 제공하는 이점도 없습니다.
- 2일차 운영자에 대한 업데이트는 롤링 업데이트를 수행할 수 없는 모든 RWN에 동시에 적용됩니다.
- 제어 평면이 손실되는 경우(재난 시나리오) 해당 제어 평면이 서비스를 제공하는 사이트 수가 많아져 전체 서비스 가용성에 훨씬 더 큰 영향을 미칩니다.
- 모니터링 유예 기간과 허용 시간 초과를 초과하는 기간 동안 RWN과 제어 평면 간의 네트워크 연결이 끊어지면 Pod가 추방되고 서비스가 중단될 수 있습니다.
- 컨테이너 이미지 사전 캐싱을 지원하지 않습니다.
- 작업 친화도의 추가적인 복잡성.
- 워크로드
- DU 워크로드는 Telco RAN DU 애플리케이션 워크로드 에 설명되어 있습니다.
- DU 워커 노드는 최대 성능을 위해 호스트 펌웨어가 조정된 Intel 3세대 Xeon(IceLake) 2.20GHz 이상입니다.
- Resources
- 애플리케이션 워크로드와 OpenShift Container Platform Pod를 포함하여 시스템에서 실행 가능한 Pod의 최대 수는 120개입니다.
- 리소스 사용률
OpenShift Container Platform 리소스 활용도는 다음과 같은 애플리케이션 워크로드 특성 등 여러 요인에 따라 달라집니다.
- Pod 수
- 프로브 유형 및 빈도
- 커널 네트워킹을 사용한 기본 또는 보조 CNI의 메시징 속도
- API 액세스 속도
- 로깅 속도
- 스토리지 IOPS
리소스 활용도는 다음과 같이 구성된 클러스터에 대해 측정됩니다.
- 클러스터는 단일 노드 OpenShift가 설치된 단일 호스트입니다.
- 클러스터는 "참조 애플리케이션 워크로드 특성"에 설명된 대표적인 애플리케이션 워크로드를 실행합니다.
- 클러스터는 "허브 클러스터 관리 특성"에 자세히 설명된 제약 조건에 따라 관리됩니다.
- 사용 모델 구성에서 "선택 사항"으로 표시된 구성 요소는 포함되지 않습니다.
참고이러한 기준을 충족하지 않는 RAN DU RDS 범위를 벗어나는 구성에는 리소스 활용도와 KPI 목표 달성 능력에 미치는 영향을 확인하기 위한 추가 분석이 필요합니다. 이러한 요구 사항을 충족하려면 추가 클러스터 리소스를 할당해야 할 수도 있습니다.
- 참조 애플리케이션 워크로드 특성
- 관리 및 제어 기능을 포함하여 vRAN 애플리케이션에 15개의 포드와 30개의 컨테이너를 사용합니다.
-
포드당 평균 2개의
ConfigMap
과 4개의Secret
CR을 사용합니다. - 10초 미만의 빈도로 최대 10 exec 프로브 사용
kube-apiserver의 증분 애플리케이션 로드는 클러스터 플랫폼 사용량의 10% 이하입니다.
참고플랫폼 지표에서 CPU 로드를 추출할 수 있습니다. 예를 들면 다음과 같습니다.
query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
$ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 애플리케이션 로그는 플랫폼 로그 수집기에 의해 수집되지 않습니다.
- 기본 CNI의 총 트래픽은 8Mbps 미만입니다.
- hub 클러스터 관리 특성
RHACM은 권장되는 클러스터 관리 솔루션이며 다음과 같은 제한 사항에 따라 구성됩니다.
- 최대 10개의 RHACM 구성 정책을 사용하세요. 이 중에는 Red Hat에서 제공하는 정책 5개와 사용자 정의 구성 정책 최대 5개가 포함되며, 평가 간격은 최소 10분입니다.
- 클러스터 정책에서 관리되는 클러스터 템플릿을 최소 수(최대 10개)로 사용합니다. 허브 측 템플릿을 사용하세요.
-
policyController
를 제외한 RHACM 애드온을 비활성화하고 기본 구성으로 관찰성을 구성합니다.
다음 표는 참조 애플리케이션 부하 하의 리소스 활용도를 설명합니다.
Expand 표 4.1. 참조 애플리케이션 부하 하의 리소스 활용 지표 제한 참고 OpenShift 플랫폼 CPU 사용량
4000mc 미만 – 2코어(4HT)
플랫폼 CPU는 각 예약된 코어의 하이퍼스레드 모두를 포함하여 예약된 코어에 고정됩니다. 이 시스템은 주기적인 시스템 작업과 급증을 허용하기 위해 정상 상태에서 3개의 CPU(3000mc)로 설계되었습니다.
OpenShift 플랫폼 메모리
16G 미만