19.6. vDU 애플리케이션 워크로드에 권장되는 단일 노드 OpenShift 클러스터 구성
다음 참조 정보를 사용하여 클러스터에서 vDU(가상 분산 단위) 애플리케이션을 배포하는 데 필요한 단일 노드 OpenShift 구성을 파악합니다. 구성에는 고성능 워크로드를 위한 클러스터 최적화, 워크로드 파티셔닝 활성화, 설치 후 필요한 재부팅 횟수 최소화가 포함됩니다.
19.6.1. OpenShift Container Platform에서 짧은 대기 시간 애플리케이션 실행 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform을 사용하면 다음과 같은 여러 기술 및 특수 하드웨어 장치를 사용하여 COTS(상용 장치) 하드웨어에서 실행되는 애플리케이션의 대기 시간을 단축할 수 있습니다.
- RHCOS용 실시간 커널
- 높은 수준의 프로세스 결정성으로 워크로드 처리 가능.
- CPU 격리
- CPU 스케줄링 지연을 방지하고 CPU 용량을 일관되게 사용할 수 있도록 합니다.
- NUMA 인식 토폴로지 관리
- CPU 및 PCI 장치와 메모리 및 대규모 페이지를 조정하여 보장된 컨테이너 메모리 및 대규모 페이지를 NUMA(Non-Uniform Memory Access) 노드에 고정합니다. 모든 QoS(Quality of Service) 클래스에 대한 Pod 리소스는 동일한 NUMA 노드에 남아 있습니다. 이렇게 하면 대기 시간이 줄어들고 노드의 성능이 향상됩니다.
- 대규모 페이지 메모리 관리
- 대규모 페이지 크기를 사용하면 페이지 테이블에 액세스하는 데 필요한 시스템 리소스의 양을 줄임으로써 시스템 성능이 향상됩니다.
- PTP를 사용한 정밀 타이밍 동기화
- 네트워크의 노드 간 동기화를 하위 마이크로초 정확도로 허용합니다.
19.6.2. vDU 애플리케이션 워크로드에 대한 권장되는 클러스터 호스트 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
vDU 애플리케이션 워크로드를 실행하려면 OpenShift Container Platform 서비스 및 프로덕션 워크로드를 실행하기에 충분한 리소스가 있는 베어 메탈 호스트가 필요합니다.
Profile | vCPU | 메모리 | 스토리지 |
---|---|---|---|
최소 | 4에서 8 vCPU | 32GB RAM | 120GB |
하나의 vCPU는 하나의 물리적 코어와 동일합니다. 그러나 동시 멀티스레딩(SMT) 또는 Hyper-Threading을 활성화하면 다음 공식을 사용하여 하나의 물리적 코어를 나타내는 vCPU 수를 계산합니다.
- (threads per core × cores) × sockets = vCPUs
가상 미디어를 사용하여 부팅할 때 서버에 BMC(Baseboard Management Controller)가 있어야 합니다.
19.6.3. 짧은 대기 시간과 고성능을 위해 호스트 펌웨어 구성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 호스트를 사용하려면 호스트를 프로비저닝하기 전에 펌웨어를 구성해야 합니다. 펌웨어 구성은 특정 하드웨어 및 설치 요구 사항에 따라 다릅니다.
절차
-
UEFI/BIOS 부팅 모드 를
UEFI
로 설정합니다. - 호스트 부팅 순서 순서에서 먼저 하드 드라이브를 설정합니다.
하드웨어에 대한 특정 펌웨어 구성을 적용합니다. 다음 표에서는 Intel Xeon Skylake 또는 Intel Cascade Lake 서버에 대한 대표 펌웨어 구성을 설명합니다. 이는 IntelECDHERAN 4G 및 5G 베이스bandECDHEY 참조 설계를 기반으로 합니다.
중요정확한 펌웨어 구성은 특정 하드웨어 및 네트워크 요구 사항에 따라 다릅니다. 다음 샘플 구성은 설명 목적으로만 사용됩니다.
Expand 표 19.7. Intel Xeon Skylake 또는 Cascade Lake 서버의 펌웨어 구성 샘플 펌웨어 설정 설정 CPU 전원 및 성능 정책
성능
Uncore Frequency Scaling
disabled
성능 P-limit
disabled
강화된 Intel SpeedStep ® Tech
enabled
Intel Configurable TDP
enabled
구성 가능한 TDP 수준
수준 2
Intel® declared Boost Technology
enabled
기술 지원
disabled
하드웨어 P-States
disabled
패키지 C-State
C0/C1 상태
C1E
disabled
프로세서 C6
disabled
호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.
19.6.4. 관리형 클러스터 네트워크에 대한 연결 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
zero touch provisioning(ZTP) GitOps 파이프라인을 사용하여 관리 클러스터를 설치하고 프로비저닝하려면 먼저 관리 클러스터 호스트가 다음 네트워킹 사전 요구 사항을 충족해야 합니다.
- hub 클러스터의 ZTP GitOps 컨테이너와 대상 베어 메탈 호스트의 BMC(Baseboard Management Controller) 간에 양방향 연결이 있어야 합니다.
관리 클러스터는 hub hostname 및
*.apps
호스트 이름의 API 호스트 이름을 확인하고 도달할 수 있어야 합니다. 다음은 허브의 API 호스트 이름과*.apps
호스트 이름의 예입니다.-
api.hub-cluster.internal.domain.com
-
console-openshift-console.apps.hub-cluster.internal.domain.com
-
hub 클러스터는 관리형 클러스터의 API 및
*.apps
호스트 이름을 확인하고 도달할 수 있어야 합니다. 다음은 관리형 클러스터의 API 호스트 이름과*.apps
호스트 이름의 예입니다.-
api.sno-managed-cluster-1.internal.domain.com
-
console-openshift-console.apps.sno-managed-cluster-1.internal.domain.com
-
19.6.5. GitOps ZTP를 사용한 단일 노드 OpenShift의 워크로드 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
워크로드 파티셔닝에서는 예약된 수의 호스트 CPU에서 실행되도록 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 구성합니다.
GitOps ZTP를 사용하여 워크로드 파티셔닝을 구성하려면 site Config
CR(사용자 정의 리소스)의 cpuset
필드와 그룹 PolicyGenTemplate
CR의 reserved
필드를 사용하여 클러스터 관리 CPU 리소스를 지정합니다. GitOps ZTP 파이프라인은 이러한 값을 사용하여 단일 노드 OpenShift 클러스터를 구성하는 워크로드 파티셔닝 MachineConfig
CR(CPU세트
) 및 PerformanceProfile
CR(reserved
)의 필수 필드를 채웁니다.
최대 성능의 경우 예약
된 CPU 세트와 분리된
CPU 세트가 NUMA 영역의 CPU 코어를 공유하지 않는지 확인합니다.
-
워크로드 파티셔닝
MachineConfig
CR은 OpenShift Container Platform 인프라 Pod를 정의된cpuset
구성에 고정합니다. -
PerformanceProfile
CR은 systemd 서비스를 예약된 CPU에 고정합니다.
PerformanceProfile
CR에 지정된 reserved
필드의 값은 워크로드 파티셔닝 MachineConfig
CR의 cpuset
필드와 일치해야 합니다.
19.6.6. 권장되는 설치 시간 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
ZTP 파이프라인은 클러스터 설치 중에 다음 CR(사용자 정의 리소스)을 적용합니다. 이러한 구성 CR은 클러스터가 vDU 애플리케이션 실행에 필요한 기능 및 성능 요구 사항을 충족하는지 확인합니다.
클러스터 배포에 ZTP GitOps 플러그인 및 siteConfig
CR을 사용하는 경우 기본적으로 다음 MachineConfig
CR이 포함됩니다.
site Config
extraManifests
필터를 사용하여 기본적으로 포함된 CR을 변경합니다. 자세한 내용은 SiteConfig CR을 사용한 고급 관리 클러스터 구성 을 참조하십시오.
19.6.6.1. 워크로드 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 워크로드 분할이 필요합니다. 이로 인해 플랫폼 서비스를 실행할 수 있는 코어가 제한되어 애플리케이션 페이로드에 대한 CPU 코어가 증가합니다.
워크로드 파티션은 클러스터 설치 중에만 활성화할 수 있습니다. 워크로드 파티션 설치 후 비활성화할 수 없습니다. 그러나 성능 프로필에 정의된 cpu
값과 관련 MachineConfig
사용자 정의 리소스(CR)를 업데이트하여 워크로드 파티션을 재구성할 수 있습니다.
워크로드 파티셔닝을 가능하게 하는 base64로 인코딩된 CR에는 관리 워크로드가 제한된 CPU 세트가 포함됩니다.
crio.conf
및kubelet.conf
의 호스트별 값을 base64로 인코딩합니다. 클러스터 성능 프로필에 지정된 CPU 세트와 일치하도록 콘텐츠를 조정합니다. 클러스터 호스트의 코어 수와 일치해야 합니다.권장되는 워크로드 파티션 구성
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터 호스트에 구성하면
/etc/crio/crio.conf.d/01-workload-partitioning
의 내용은 다음과 같아야 합니다.[crio.runtime.workloads.management] activation_annotation = "target.workload.openshift.io/management" annotation_prefix = "resources.workload.openshift.io" resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }
[crio.runtime.workloads.management] activation_annotation = "target.workload.openshift.io/management" annotation_prefix = "resources.workload.openshift.io" resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpuset
값은 설치에 따라 다릅니다. Hyper-Threading이 활성화된 경우 각 코어에 대해 두 스레드를 모두 지정합니다.cpuset
값은 성능 프로필의spec.cpu.reserved
필드에 정의된 예약된 CPU와 일치해야 합니다.
클러스터에서 구성하면
/etc/kubernetes/openshift-workload-pinning
의 내용은 다음과 같아야 합니다.{ "management": { "cpuset": "0-1,52-53" } }
{ "management": { "cpuset": "0-1,52-53"
1 } }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpuset
는/etc/crio/crio.conf.d/01-workload-partitioning
의cpuset
값과 일치해야 합니다.
검증
애플리케이션과 클러스터 시스템 CPU 고정이 올바른지 확인합니다. 다음 명령을 실행합니다.
관리 클러스터에 대한 원격 쉘 연결을 엽니다.
oc debug node/example-sno-1
$ oc debug node/example-sno-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift 인프라 애플리케이션 CPU 고정이 올바른지 확인합니다.
pgrep ovn | while read i; do taskset -cp $i; done
sh-4.4# pgrep ovn | while read i; do taskset -cp $i; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 시스템 애플리케이션 CPU 고정이 올바른지 확인합니다.
pgrep systemd | while read i; do taskset -cp $i; done
sh-4.4# pgrep systemd | while read i; do taskset -cp $i; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
pid 1's current affinity list: 0-1,52-53 pid 938's current affinity list: 0-1,52-53 pid 962's current affinity list: 0-1,52-53 pid 1197's current affinity list: 0-1,52-53
pid 1's current affinity list: 0-1,52-53 pid 938's current affinity list: 0-1,52-53 pid 962's current affinity list: 0-1,52-53 pid 1197's current affinity list: 0-1,52-53
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.6.6.2. 플랫폼 관리 공간 감소 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼의 전반적인 관리 풋프린트를 줄이기 위해 MachineConfig
사용자 정의 리소스 (CR)는 새 네임스페이스에 모든 Kubernetes별 마운트 지점을 호스트 운영 체제와 별도로 배치해야합니다. 다음 base64로 인코딩된 예제 MachineConfig
CR은 이 구성을 보여줍니다.
권장되는 컨테이너 마운트 네임스페이스 구성
19.6.6.3. SCTP 링크 복사링크가 클립보드에 복사되었습니다!
SCTP(스트림 제어 전송 프로토콜)는 RAN 애플리케이션에서 사용되는 주요 프로토콜입니다. 이 MachineConfig
오브젝트는 이 프로토콜을 활성화하기 위해 SCTP 커널 모듈을 노드에 추가합니다.
권장되는 SCTP 구성
19.6.6.4. 컨테이너 시작 가속화 링크 복사링크가 클립보드에 복사되었습니다!
다음 MachineConfig
CR은 시스템 시작 및 종료 중에 사용 가능한 모든 CPU 코어를 사용하도록 핵심 OpenShift 프로세스 및 컨테이너를 구성합니다. 따라서 초기 부팅 및 재부팅 중에 시스템 복구가 빨라집니다.
권장되는 가속화 컨테이너 시작 구성
19.6.6.5. kdump를 사용한 자동 커널 충돌 덤프 링크 복사링크가 클립보드에 복사되었습니다!
kdump
Linux 커널 기능은 커널이 충돌할 때 커널 크래시 덤프를 생성합니다. kdump
기능은 다음 MachineConfig
CR을 사용하여 활성화됩니다.
컨트롤 플레인 kdump 로그에서 원래 드라이버를 제거하려면 MachineConfig
CR을 권장함 (05-kdump-config-master.yaml
)
권장 컨트롤 플레인 노드 kdump 구성 (06-kdump-master.yaml
)
작업자 노드 kdump 로그에서 원래 드라이버를 제거하려면 MachineConfig
CR을 권장함 (05-kdump-config-worker.yaml
)
권장 kdump 작업자 노드 구성 (06-kdump-worker.yaml
)
19.6.7. 설치 후 클러스터 구성 권장 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 설치가 완료되면 ZTP 파이프라인에서 DU 워크로드를 실행하는 데 필요한 다음 CR(사용자 정의 리소스)을 적용합니다.
{ztp} v4.10 및 이전 버전에서는 MachineConfig
CR을 사용하여 UEFI 보안 부팅을 구성합니다. {ztp} v4.11 이상에서는 더 이상 필요하지 않습니다. v4.11에서는 클러스터를 설치하는 데 사용하는 site Config
CR에서 spec.clusters.nodes.bootMode
필드를 업데이트하여 단일 노드 OpenShift 클러스터에 대해 UEFI 보안 부팅을 구성합니다. 자세한 내용은 site Config 및 {ztp}를 사용하여 관리되는 클러스터 배포를 참조하십시오.
19.6.7.1. Operator 네임스페이스 및 Operator groups 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 다음 OperatorGroup
및 Namespace
CR(사용자 정의 리소스)이 필요합니다.
- Local Storage Operator
- Operator 로깅
- PTP Operator
- SR-IOV 네트워크 Operator
다음 YAML은 이러한 CR을 요약합니다.
권장되는 Operator 네임스페이스 및 OperatorGroup 구성
19.6.7.2. Operator 서브스크립션 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 다음과 같은 Subscription
CR이 필요합니다. 서브스크립션은 다음 Operator를 다운로드할 수 있는 위치를 제공합니다.
- Local Storage Operator
- Operator 로깅
- PTP Operator
- SR-IOV 네트워크 Operator
권장되는 Operator 서브스크립션
19.6.7.3. 클러스터 로깅 및 로그 전달 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 디버깅을 위해 로깅 및 로그 전달이 필요합니다. 다음 예제 YAML은 필수 ClusterLogging
및 ClusterLogForwarder
CR을 보여줍니다.
권장되는 클러스터 로깅 및 로그 전달 구성
19.6.7.4. 성능 프로필 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 실시간 호스트 기능 및 서비스를 사용하려면 Node Tuning Operator 성능 프로파일이 필요합니다.
이전 버전의 OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다.
다음 예제 PerformanceProfile
CR은 필요한 클러스터 구성을 보여줍니다.
권장되는 성능 프로파일 구성
- 1
이름
값이TunedPerformancePatch.yaml
의spec.profile.data
필드에 지정된 값과 일치하고validatorCRs/informDuValidator.yaml
의status.configuration.source.name
필드와 일치하는지 확인합니다.- 2
- 클러스터 호스트에 대한 UEFI 보안 부팅을 구성합니다.
- 3
- 분리된 CPU를 설정합니다. 모든 하이퍼 스레딩 쌍이 일치하는지 확인합니다.중요
예약 및 분리된 CPU 풀은 겹치지 않아야 하며 함께 사용 가능한 모든 코어에 걸쳐 있어야 합니다. 고려하지 않은 CPU 코어로 인해 시스템에서 정의되지 않은 동작이 발생합니다.
- 4
- 예약된 CPU를 설정합니다. 워크로드 파티셔닝이 활성화되면 시스템 프로세스, 커널 스레드 및 시스템 컨테이너 스레드가 이러한 CPU로 제한됩니다. 분리되지 않은 모든 CPU는 예약해야 합니다.
- 5
- 대규모 페이지 수를 설정합니다.
- 6
- 대규모 페이지 크기를 설정합니다.
- 7
node
를hugepages
가 할당된 NUMA 노드로 설정합니다.- 8
- 실시간 Linux 커널을 설치하려면
enabled
를true
로 설정합니다.
19.6.7.5. 클러스터 시간 동기화 구성 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인 또는 작업자 노드에 대한 일회성 시스템 시간 동기화 작업을 실행합니다.
컨트롤 플레인 노드에 대해 한 번의 시간 동기화 (99-sync-time-once-master.yaml
)
작업자 노드에 대해 한 번의 시간 동기화 (99-sync-time-once-worker.yaml
)
19.6.7.6. PTP 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 클러스터는 네트워크 시간 동기화에 PTP(Precision Time Protocol)를 사용합니다. 다음 예제 PtpConfig
CR은 필요한 PTP 슬레이브 구성을 보여줍니다.
권장되는 PTP 구성
- 1
- PTP 클럭 신호를 수신하는 데 사용되는 인터페이스를 설정합니다.
19.6.7.7. 확장 Tuned 프로파일 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 고성능 워크로드에 필요한 추가 성능 튜닝 구성이 필요합니다. 다음 예제 Tuned
CR은 Tuned
프로필을 확장합니다.
권장되는 확장 Tuned 프로파일 구성
19.6.7.8. SR-IOV 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV(Single Root I/O virtualization)는 일반적으로 fronthaul 및 midhaul 네트워크를 활성화하는 데 사용됩니다. 다음 YAML 예제에서는 단일 노드 OpenShift 클러스터에 대해 SR-IOV를 구성합니다.
권장되는 SR-IOV 구성
19.6.7.9. Console Operator 링크 복사링크가 클립보드에 복사되었습니다!
console-operator는 클러스터에서 웹 콘솔을 설치하고 유지 관리합니다. 노드를 중앙에서 관리할 때 Operator가 필요하지 않고 애플리케이션 워크로드를 위한 공간을 만듭니다. 다음 콘솔
CR(사용자 정의 리소스) 예에서는 콘솔을 비활성화합니다.
권장되는 콘솔 구성
19.6.7.10. Alertmanager 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 OpenShift Container Platform 모니터링 구성 요소에서 사용하는 CPU 리소스가 감소해야 합니다. 다음 ConfigMap
CR(사용자 정의 리소스)은 Alertmanager를 비활성화합니다.
권장되는 클러스터 모니터링 구성
19.6.7.11. Operator Lifecycle Manager 링크 복사링크가 클립보드에 복사되었습니다!
분산 단위 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 CPU 리소스에 대한 일관된 액세스 권한이 필요합니다. OLM(Operator Lifecycle Manager)은 정기적으로 Operator에서 성능 데이터를 수집하여 CPU 사용률이 증가합니다. 다음 ConfigMap
CR(사용자 정의 리소스)은 OLM의 Operator 성능 데이터 수집을 비활성화합니다.
권장되는 클러스터 OLM 구성(ReduceOLMFootprint.yaml
)
19.6.7.12. 네트워크 진단 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 Pod에서 생성하는 추가 로드를 줄이기 위해 포드 간 네트워크 연결 검사가 줄어듭니다. 다음 CR(사용자 정의 리소스)은 이러한 검사를 비활성화합니다.
권장되는 네트워크 진단 구성