Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

3.7. 통신사 핵심 클러스터 공통 사용 모델 엔지니어링 고려 사항

  • 클러스터 작업 부하에 대한 자세한 내용은 "애플리케이션 작업 부하"에 나와 있습니다.

  • 작업자 노드는 다음 CPU 중 하나에서 실행되어야 합니다.

    • OpenShift Container Platform에서 지원하는 Intel 3세대 Xeon(IceLake) CPU 이상이거나 실리콘 보안 버그(Spectre 등) 완화 기능이 꺼진 CPU입니다. Skylake 및 이전 CPU의 경우 Spectre 및 유사한 완화 조치를 활성화하면 트랜잭션 성능이 40% 감소할 수 있습니다. Skylake 및 이전 CPU가 전원 상태를 변경하면 지연이 발생할 수 있습니다.
    • AMD EPYC Zen 4 CPU(Genoa, Bergamo).
    • 작업자 노드에서 IRQ 밸런싱이 활성화되었습니다. PerformanceProfile CR은 globalDisableIrqLoadBalancing 매개변수를 false 값으로 설정합니다. 보장된 QoS 포드는 "CPU 분할 및 성능 튜닝"에 설명된 대로 격리를 보장하도록 주석이 달려 있습니다.

  • 모든 클러스터 노드에는 다음과 같은 기능이 있어야 합니다.

    • 하이퍼스레딩을 활성화하세요
    • x86_64 CPU 아키텍처를 가지고 있습니다
    • 스톡(비실시간) 커널을 활성화하세요
    • 작업 분할을 위해 구성되지 않았습니다.

  • 클러스터 내의 머신 구성 풀에 따라 전원 관리와 최대 성능 간의 균형이 다릅니다. 다음 구성은 머신 구성 풀 그룹의 모든 노드에서 일관되어야 합니다.

    • 클러스터 스케일링. 자세한 내용은 "확장성"을 참조하세요.
    • 클러스터는 최소 120개 노드까지 확장할 수 있어야 합니다.
  • CPU 파티셔닝은 PerformanceProfile CR을 사용하여 구성되며 MachineConfigPool 기준으로 노드에 적용됩니다. 추가 고려 사항은 "CPU 파티셔닝 및 성능 튜닝"을 참조하세요.

  • OpenShift Container Platform의 CPU 요구 사항은 구성된 기능 세트와 애플리케이션 워크로드 특성에 따라 달라집니다. kube-burner 노드 밀도 테스트에서 생성된 3000개 포드의 시뮬레이션 워크로드를 실행하는 참조 구성에 따라 구성된 클러스터의 경우 다음 CPU 요구 사항이 검증됩니다.

    • 제어 평면 및 작업자 노드에 예약된 CPU의 최소 수는 NUMA 노드당 2개의 CPU(4개의 하이퍼스레드)입니다.
    • DPDK가 아닌 네트워크 트래픽에 사용되는 NIC는 최대 32개의 RX/TX 대기열을 사용하도록 구성해야 합니다.
    • 포드나 기타 리소스가 많은 노드에는 추가로 예약된 CPU가 필요할 수 있습니다. 나머지 CPU는 사용자 작업 부하에 사용할 수 있습니다.
    참고

    OpenShift 컨테이너 플랫폼 구성, 작업 부하 크기 및 작업 부하 특성의 변화에 따라 OpenShift 플랫폼에 필요한 CPU 수에 미치는 영향을 파악하기 위해 추가 분석이 필요합니다.

3.7.1. 애플리케이션 워크로드
링크 복사

통신사 코어 클러스터에서 실행되는 애플리케이션 워크로드에는 고성능 클라우드 기반 네트워크 기능(CNF)과 기존의 베스트 이포트 또는 버스트 가능 포드 워크로드가 혼합되어 포함될 수 있습니다.

보장된 QoS 예약은 성능 또는 보안 요구 사항으로 인해 CPU를 독점적 또는 전용으로 사용해야 하는 Pod에서 사용할 수 있습니다. 일반적으로 사용자 평면 네트워킹(예: DPDK)을 사용하여 고성능 또는 지연에 민감한 CNF를 실행하는 Pod는 노드 튜닝과 보장된 QoS 스케줄링을 통해 달성된 전용 전체 CPU의 독점적인 사용이 필요합니다. 전용 CPU가 필요한 Pod 구성을 만들 때는 하이퍼스레드 시스템의 잠재적 영향을 알고 있어야 합니다. 전체 코어(2개의 하이퍼스레드)를 포드에 할당해야 하는 경우 포드는 2개의 CPU 배수를 요청해야 합니다.

높은 처리량이나 낮은 지연 네트워킹이 필요하지 않은 네트워크 기능을 실행하는 Pod는 최선의 노력 또는 버스트 가능 QoS Pod로 예약해야 하며 전용 또는 분리된 CPU 코어가 필요하지 않습니다.

엔지니어링 고려 사항

다음 정보를 사용하여 통신사 핵심 작업 부하와 클러스터 리소스를 계획하세요.

  • OpenShift Container Platform 4.19부터 cgroup v1은 더 이상 지원되지 않으며 제거되었습니다. 이제 모든 워크로드는 cgroup v2와 호환되어야 합니다. 자세한 내용은 Red Hat OpenShift 워크로드 컨텍스트에서 Red Hat Enterprise Linux 9의 변경 사항을 참조하세요.
  • CNF 애플리케이션은 Kubernetes를 위한 Red Hat 모범 사례 의 최신 버전을 준수해야 합니다.

  • 애플리케이션의 요구에 따라 베스트 이포트 및 버스트 가능 QoS 포드를 혼합하여 사용하세요.

    • 노드를 구성하는 PerformanceProfile CR에서 예약되거나 격리된 CPU를 적절히 구성하여 보장된 QoS 포드를 사용합니다.
    • 보장된 QoS Pod에는 CPU를 완전히 분리하기 위한 주석이 포함되어야 합니다.
    • 최선의 노력과 버스트 가능 포드는 독점적인 CPU 사용을 보장하지 않습니다. 작업 부하는 다른 작업 부하, 운영 체제 데몬 또는 커널 작업에 의해 우선 처리될 수 있습니다.

  • exec 프로브는 아껴서 사용하고 다른 적합한 옵션을 사용할 수 없는 경우에만 사용하세요.

    • CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오. 다른 프로브 구현(예: httpGet 또는 tcpSocket )을 사용합니다.
    • exec 프로브를 사용해야 하는 경우 exec 프로브 빈도 및 수량을 제한합니다. exec 프로브의 최대 개수는 10개 미만으로 유지해야 하며, 빈도는 10초 미만으로 설정해서는 안 됩니다.
    • 정상 상태 작동에서는 많은 리소스를 사용하지 않으므로 시작 프로브를 사용할 수 있습니다. exec 프로브의 제한은 주로 liveness 및 readiness 프로브에 적용됩니다. 실행 프로브는 프로세스 포킹이 필요하기 때문에 다른 프로브 유형에 비해 관리 코어에서 CPU 사용량이 훨씬 더 높습니다.

3.7.2. 신호 작업 부하
링크 복사

신호 작업 부하에서는 일반적으로 SCTP, REST, gRPC 또는 이와 유사한 TCP나 UDP 프로토콜을 사용합니다. 신호 작업 부하는 MACVLAN 또는 SR-IOV 인터페이스로 구성된 보조 멀티 CNI를 사용하여 초당 수십만 건의 트랜잭션(TPS)을 지원합니다. 이러한 작업 부하는 보장된 QoS나 버스트 가능한 QoS를 갖춘 포드에서 실행될 수 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat