Menu Close

16.4. 실시간 및 짧은 대기 시간 워크로드 프로비저닝

많은 업계와 조직에서 매우 높은 성능의 컴퓨팅을 필요로 하고 있으며 특히 금융 및 통신 업계에서는 짧고 예측 가능한 대기 시간이 요구될 수 있습니다. 고유한 요구사항을 가지고 있는 이러한 업계에서 사용할 수 있도록 OpenShift Container Platform에서는 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능과 일관된 응답 시간을 실현할 수 있도록 자동 튜닝을 구현하는 Performance Addon Operator를 제공합니다.

클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 수행할 수 있습니다. 관리자는 커널을 kernel-rt(실시간)로 업데이트할지 여부를 지정하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하여 워크로드를 실행할 수 있습니다.

주의

보장된 CPU가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 대기 시간이 급증할 수 있습니다. 올바르게 구성된 네트워크 프로브 세트와 같은 기타 프로브를 대안으로 사용하는 것이 좋습니다.

16.4.1. 실시간에 대한 알려진 제한 사항

참고

대부분의 배포에서 kernel-rt는 3개의 컨트롤 플레인 노드와 3개의 작업자 노드가 있는 표준 클러스터를 사용하는 경우에만 작업자 노드에서 지원됩니다. OpenShift Container Platform 배포에서는 소형 노드와 단일 노드의 예외가 있습니다. 단일 노드에 설치하는 경우 단일 컨트롤 플레인 노드에서 kernel-rt가 지원됩니다.

실시간 모드를 완전히 활용하려면 상승된 권한으로 컨테이너를 실행해야 합니다. 권한 부여에 대한 자세한 내용은 컨테이너에 대한 기능 설정을 참조하십시오.

OpenShift Container Platform에서는 허용되는 기능을 제한하므로 SecurityContext를 생성해야 할 수도 있습니다.

참고

RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 사용하는 베어 메탈 설치에서는 이러한 절차가 완전하게 지원됩니다.

적합한 성능 기대치를 설정한다는 것은 실시간 커널이 만능 해결책이 아니라는 것을 나타냅니다. 설정의 목표는 예측 가능한 응답 시간을 제공하는 일관되고 대기 시간이 짧은 결정성을 갖추는 것입니다. 실시간 커널에는 연관된 추가 커널 오버헤드가 있습니다. 이러한 오버헤드는 주로 별도로 예약된 스레드에서 하드웨어 중단을 처리하는 데서 발생합니다. 일부 워크로드에서 오버헤드가 증가하면 전반적으로 처리량 성능이 저하됩니다. 정확한 저하 수치는 워크로드에 따라 달라지며, 범위는 0%에서 30% 사이입니다. 하지만 이러한 저하는 결정성에 대한 대가입니다.