자체 관리형 Red Hat OpenShift 서브스크립션 가이드

2025년 3월 10일•
리소스 유형: 기술 세부 정보

개요

이 문서는 자체 관리형 Red Hat® OpenShift® 오퍼링의 서브스크립션 모델에 대한 이해를 돕고 Red Hat OpenShift 환경에 필요한 권한의 수를 추정하는 방법에 대한 단계별 지침을 제공합니다. 더 정확한 규모 파악을 위한 정보는 요청 시 제공해 드립니다.

정의

가장 먼저, 고객이 이해해야 할 몇 가지 용어를 다음과 같이 정의해 드립니다.

  • 코어 페어(core-pair): 자체 관리형 OpenShift 서비스크립션의 기반 중 하나로, 2개의 물리 코어 또는 4개의 vCPU로 정의됩니다. 베어메탈 머신에서는 하이퍼스레딩 또는 대칭형 멀티스레딩 기술에 관계없이 언제나 물리 코어를 가리킵니다. 하이퍼스레딩이 켜진 경우 4개의 vCPU로 표시되는 2개의 물리 코어는 계속해서 1개의 코어 페어로 집계됩니다. 하이퍼스케일러 배포의 경우(예: AWS, Azure, GCP) 4개의 vCPU는 항상 1개의 코어 페어로 간주됩니다. 코어 페어 서브스크립션은 클러스터 수준에서 집계되므로 멀티플 클라우드 인스턴스, 가상 머신(VM), 물리 서버에 모두 적용될 수 있습니다.
  • 베어 메탈 소켓 페어(bare metal socket-pair): 자체 관리형 OpenShift 서비스크립션의 나머지 기반으로, 서버당 최소 1개의 베어 메탈 소켓 페어 서브스크립션이 필요하고, 이 1개의 서브스크립션을 최대 128개의 코어에 적용합니다. 1개의 베어 메탈 소켓 페어 서브스크립션은 2개 이상의 서버에 적용될 수 없으며 서브스크립션의 코어도 2개 이상의 서버에 적용될 수 없습니다. 베어 메탈 소켓 페어 서브스크립션은 스태킹을 통해 더 많은 수의 코어와 소켓을 포함할 수 있습니다.
  • AI Accelerator: 필요한 Red Hat AI Accelerator 서브스크립션 개수는 중앙 처리 장치(CPU) 외에 특정 컴퓨팅 기능을 가속화하는 물리적 하드웨어 애드온(add-on) 장치의 개수에 따라 달라집니다. 이렇게 애드온으로 설치되는 장치에는 별도의 그래픽 처리 장치(GPU), 텐서 처리 장치(TPU), 데이터 처리 장치(DPU), 필드 프로그래머블 게이트 어레이(FPGA), 애플리케이션별 집적 회로(ASIC), 네트워크 처리 장치(NPU) 등이 있으며 이에 국한되지 않습니다. 반면 메인 CPU와 긴밀하게 통합되는 가속기(예: 통합형 GPU, NPU, 기타 유형의 가속기)는 포함되지 않습니다. 이러한 가속기는 종종 가상화되고 2개 이상의 VM 또는 인스턴스에 표시되며 CPU 코어와 유사한 1개 또는 다수의 '코어'를 포함할 수 있지만 서브스크립션은 물리적 장치의 수를 기반으로 합니다.
  • SLA: Red Hat 서브스크립션을 이용하려면 지원 서비스 수준 계약(SLA)의 옵션을 선택해야 합니다. 옵션에는 스탠다드 8x5 SLA와 프리미엄 1년 365일 SLA 등 2가지가 있습니다.
  • 컴퓨팅 노드: 최종 사용자 애플리케이션 포드가 실행되는 Red Hat Enterprise Linux® 또는 Red Hat Enterprise Linux CoreOS의 인스턴스(VM 또는 베어메탈 호스트)입니다. OpenShift 환경에는 컴퓨팅 노드가 다수 포함될 수 있습니다. 이러한 노드에는 OpenShift 서브스크립션이 필요합니다. 컴퓨팅 노드를 지원하는 컨트롤 플레인 노드와 인프라 노드에는 서브스크립이 필요 없지만 인프라 비용이 발생할 수 있습니다.
  • 컨트롤 플레인 노드: Red Hat Enterprise Linux CoreOS의 인스턴스(VM 또는 베어메탈 호스트)로서 Red Hat OpenShift용 쿠버네티스 오케스트레이션 또는 관리 계층의 역할을 합니다. 컨트롤 플레인 노드 권한은 자체 관리형 OpenShift 서브스크립션에 포함되므로 구입할 서브스크립션의 개수를 결정할 때 포함시킬 필요가 없습니다. 자세한 정보는 Red Hat OpenShift 컨트롤 플레인 및 인프라 노드 섹션을 참조하세요.
  • 인프라 노드: 애플리케이션 인스턴스가 아닌 OpenShift 클러스터 인프라를 지원하는 포드를 실행하는 노드입니다. (예: 인그레스 트래픽용 HAProxy 기반 부하 분산기를 실행하는 노드.) 인프라 노드 권한은 자체 관리형 OpenShift 서브스크립션에 포함되므로 사용자 애플리케이션 인스턴스가 실행되지 않는 한 구입할 서브스크립션의 개수를 결정할 때 포함시킬 필요가 없습니다.
  • 클러스터: 하나의 컨트롤 플레인, 선택적 인프라 노드, 하나 이상의 컴퓨팅 노드로 구성된 OpenShift Kubernetes 클러스터입니다.

애플리케이션 인스턴스: 애플리케이션은 단일 포드 인스턴스이거나 애플리케이션 서비스를 구성하는 여러 포드 인스턴스 전반에 배포될 수 있습니다. 예를 들어 고가용성 애플리케이션 서비스는 2개 이상의 포드로 구성될 수 있습니다. 애플리케이션 인스턴스는 언제나 Red Hat OpenShift 서브스크립션을 통해 권한이 있는 컴퓨팅 노드에서 실행되어야 합니다.

Red Hat OpenShift 서브스크립션 버전

Red Hat OpenShift는 오픈 하이브리드 클라우드 환경 전반에 걸쳐 일관된 애플리케이션 개발 및 관리 플랫폼을 제공하며, 온프레미스, 가상 및 물리 인프라, 프라이빗 클라우드, 퍼블릭 클라우드, 엣지 배포를 지원합니다. Red Hat OpenShift는 자체 관리형 Red Hat OpenShift, 전체 관리형 OpenShift 클라우드 서비스 등 2가지로 운영하고 사용할 수 있습니다. 이 가이드에서는 자체 관리형 OpenShift를 중점적으로 소개합니다.

자체 관리형 OpenShift를 사용하면 최대한의 제어, 유연성, 커스터마이징으로 Red Hat OpenShift 환경을 설치, 운영, 관리할 수 있으므로 인프라부터 시작해 고유한 환경을 운영할 수 있습니다. 자체 관리형 Red Hat OpenShift는 물리 서버, 가상화를 사용할 뿐만 아니라 프라이빗 클라우드 환경과 지원되는 퍼블릭 클라우드 환경에서도 온프레미스로 지원됩니다. 업그레이드를 제어하고, 더 낮은 수준의 인프라를 관리하며, 서비스 수준 계약(SLA)을 유지 관리할 수 있습니다.

관리형 OpenShift 클라우드 서비스는 주요 퍼블릭 클라우드에서 Red Hat과 퍼블릭 클라우드 파트너가 전체를 관리하고 운영합니다. 전담 사이트 신뢰성 엔지니어링(SRE) 팀이 Red Hat OpenShift 핵심 서비스 및 인프라를 관리하고 유지하므로 DevSecOps 팀은 새로운 애플리케이션을 개발 및 배포하고 기존 애플리케이션을 현대화하는 데 집중할 수 있습니다.

Red Hat OpenShift 클라우드 서비스 제공 및 자세한 정보 문의처:

Red Hat OpenShift의 모든 버전은 모든 환경에서 개발자와 운영 팀에 일관된 사용자 환경을 제공하므로 애플리케이션이 가장 잘 작동하는 클라우드 환경으로 기술과 애플리케이션을 이전할 수 있습니다.

자체 관리형 OpenShift 서비스크립션 적용 대상

자체 관리형 OpenShift(Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform, Red Hat OpenShift Kubernetes Engine, Red Hat OpenShift Virtualization Engine)는 64비트 Red Hat Enterprise Linux가 인증 및 지원되는 모든 곳에서 사용할 수 있습니다. OpenShift 배포 방법 및 지원되는 인프라 유형에 대한 자세한 내용은 도큐멘테이션을 참조하세요. 

자체 관리형 OpenShift 소프트웨어 버전:

  • Red Hat OpenShift Kubernetes Engine: 하이브리드 클라우드, 엔터프라이즈급 쿠버네티스 런타임 엔진으로, 데이터센터, 퍼블릭 클라우드 또는 엣지 환경에서 설치 및 관리할 수 있는 애플리케이션을 배포하고 실행하는 핵심 Red Hat OpenShift 기능을 제공합니다.
  • Red Hat OpenShift Container Platform: 모든 기능을 갖춘 하이브리드 클라우드, 엔터프라이즈급 쿠버네티스 애플리케이션 플랫폼으로, 데이터센터, 퍼블릭 클라우드, 엣지 환경에서 설치 및 관리할 수 있는 애플리케이션을 빌드, 배포, 실행하는 데 사용됩니다.
  • Red Hat OpenShift Platform Plus: 기업이 다중 클러스터 및 클라우드 환경 전반에서 지능형 애플리케이션을 규모에 따라 빌드, 배포, 실행, 관리할 수 있는 하이브리드 클라우드 플랫폼입니다. 여러 계층으로 이루어진 보안, 관리 용이성, 자동화로 소프트웨어 공급망 전체에 일관성을 제공합니다. OpenShift Platform Plus 서브스크립션은 x86 기반 클러스터에만 제공됩니다.
  • Red Hat OpenShift Virtualization Engine: Red Hat OpenShift와 오픈소스 커널 기반 가상 머신(KVM)을 기반으로 한 베어메탈 전용의 가상화 인프라 오퍼링으로, 기업에 VM의 배포, 관리 및 확장을 위한 안정적인 엔터프라이즈급 솔루션을 제공하기 위한 목적으로 개발되었습니다. OpenShift 기능의 하위 집합인 이 OpenShift 버전은 가상 머신 전용 워크로드를 대상으로 하며, 컨테이너에서는 인프라 서비스만 지원됩니다(즉, 최종 사용자 애플리케이션 컨테이너 지원은 없음).

서브스크립션 유형

자체 관리형 OpenShift에는 2가지 유형의 서브스크립션(코어 페어, 베어 메탈 소켓 페어)이 있으며 각 서브스크립션에 2가지 지원 수준이 제공됩니다.

컴퓨팅 노드 서브스크립션은 기존 환경의 컴퓨팅 노드에 필요합니다. 이러한 서브스크립션은 코어 페어 또는 베어 메탈 소켓 페어에 의해 권한이 부여될 수 있습니다.

  1. 코어 페어(2개의 코어 또는 4개의 vCPU)
    • 이 서브스크립션 옵션은 OpenShift Kubernetes Engine, OpenShift Container Platform, OpenShift Platform Plus에 제공됩니다. 코어 페어 서브스크립션은 OpenShift Virtualization Engine에서는 사용할 수 없습니다.
    • CPU 코어에 권한을 부여할 때는 코어 페어 서브스크립션을 사용하여 권한을 부여할 모든 OpenShift 클러스터에서 실행되는 모든 OpenShift 컴퓨팅 노드 전반의 물리 코어 또는 vCPU의 총 개수를 집계하세요.
    • 표준 영업시간 내 지원 또는 프리미엄 1년 365일 지원 SLA로 제공됩니다.
  2. 베어 메탈 소켓 페어(1~2개의 소켓, 최대 총 128개의 코어)
    • 이 서브스크립션 옵션은 모든 자체 관리형 OpenShift 버전에 제공되며, OpenShift Virtualization Engine에 제공되는 유일한 옵션입니다.
    • 이 서브스크립션은 OpenShift가 하드웨어에 직접 설치되는 x86 및 ARM 베어메탈 물리 노드에만 제공됩니다. 타사 하이퍼바이저는 사용할 수 없습니다.
    • 명백히 '가상 데이터센터' 서브스크립션(예: 단일 서브스크립션으로 어느 하이퍼바이저 호스트에서도 무제한 VM 게스트 운영 체제 설치가 가능한 Red Hat Enterprise Linux for Virtual Datacenters)이 아닙니다.
    • 표준 영업시간 내 지원 또는 프리미엄 1년 365일 지원 SLA로 제공됩니다.
    • 스태킹을 통해 소켓이 2개를 초과하거나 코어가 128개를 초과하는 베어메탈 서버에 사용될 수 있지만 단일 서브스크립션이 여러 베어메탈 서버에 적용될 수는 없습니다.

아울러 기존 환경에 있는 가속기에는 Red Hat AI Accelerator 서브스크립션이 필요합니다.

  1. AI Accelerator(1개의 Accelerator)
    • 이 서브스크립션은 CPU 패키지에 포함되지 않는 별개의 애드온인 AI 워크로드용으로 컴퓨팅 가속화를 제공하는 가속기 카드(GPU, TPU, NPU, FPGA, DPU 등)에 필요합니다.
    • 같은 서브스크립션이 Red Hat OpenShift 버전에 상관없이 각각의 물리적 AI Accelerator에 사용됩니다.
    • Red Hat OpenShift와 OpenShift AI가 모두 클러스터에 설치된 경우 하나의 AI Accelerator 서브스크립션으로 충분합니다.
    • 이 서브스크립션은 가속기 기능이 컴퓨팅 가속화에 사용되고 있지 않는 동안에는 필요하지 않습니다(예: DPU는 사용되지 않으면서 어드레스할 수 있는 ARM 코어가 있는 경우에만 네트워크 가속화용으로 SmartNIC로 사용되고 GPU는 AI 가속화가 아닌 그래픽 렌더링에 사용).
    • 표준 영업시간 내 지원 또는 프리미엄 1년 365일 지원 SLA로 제공됩니다. SLA는 지원 코어 페어 또는 베어 메탈 소켓 페어 서브스크립션의 SLA과 일치해야 합니다.

코어 페어 서브스크립션을 선택해야 하는 경우

자체 관리형 OpenShift를 퍼블릭 클라우드 하이퍼스케일러에, 서비스로서의 인프라(IaaS) 프라이빗 클라우드 내에 또는 VMware vSphere, Red Hat OpenStack® Platform, Nutanix 등과 같은 하이퍼바이저에 배포하는 경우 코어 페어 서브스크립션을 가장 많이 선택하게 됩니다.

코어 페어 서브스크립션을 선택하면 물리 서버에 서브스크립션을 연결할 필요가 없고, 필요할 때 언제 어디서나 하이브리드 클라우드 전반에 포드를 배포할 수 있습니다.

또한 베어메탈 서버 또는 장치(즉, 하이퍼바이저가 없음)에 코어 페어 서브스크립션을 사용할 수 있습니다. 일반적으로 베어 메탈 소켓 페어 서브스크립션이 더 비용 효율적일 수 있는 컴퓨팅 포드 밀도가 있다는 점에 유의하십시오.

OpenShift Virtualization Engine을 전용 가상화 플랫폼으로 사용할 경우 이 하이퍼바이저 자체를 위한 베어 메탈 소켓 페어 외에도 코어 페어 서브스크립션을 사용하여 VM의 OpenShift 컨테이너에 권한을 부여할 수 있습니다. 구입 후 VM으로 실행할 수 있는 다른 모든 애플리케이션과 마찬가지로 OpenShift 자체 관리형 코어 페어 서브스크립션을 별도로 구입하여 이 환경에 있는 VM에 할당할 수 있습니다. 이러한 경우, 베어메탈 서버의 무제한 OpenShift 컨테이너와 OpenShift VM 내 해당 컨테이너 실행 지원이 포함된 자체 관리형 OpenShift용 베어 메탈 소켓 페어 모델로 전환하는 것이 더 비용 효율적일 수 있는 코어 밀도가 존재합니다.

코어 페어 서브스크립션은 분배를 통해 모든 OpenShift 클러스터에서 전체 OpenShift 컴퓨팅 노드에 적용될 수 있습니다. 예를 들어 코어 페어 Red Hat OpenShift Platform Plus 서브스크립션 100개로 코어 200개(vCPU 400개)를 제공할 수 있고, 이를 하이브리드 클라우드 환경 전반에서 실행 중인 모든 OpenShift 클러스터에서 개수에 상관없이 모든 컴퓨팅 노드에 사용할 수 있습니다.

베어 메탈 소켓 페어 서브스크립션을 선택해야 하는 경우

베어 메탈 소켓 페어 서브스크립션은 데이터센터 또는 지원되는 베어메탈 오퍼링 기반의 호스팅된 프라이빗 클라우드에 있거나 지원되는 베어메탈 오퍼링 기반의 하이퍼스케일러에 있는 전용 물리 서버에 배포된 OpenShift 컴퓨팅 노드에 대한 유일한 옵션입니다. 베어 메탈 소켓 페어 서브스크립션은 OpenShift Virtualization Engine의 유일한 옵션이며 다른 자체 관리형 OpenShift 버전의 OpenShift Virtualization 기능을 지원하기 위해 필요합니다.

각 베어 메탈 소켓 페어 서브스크립션은 소켓 페어 전반에서 최대 128개의 물리 코어에 권한을 부여합니다. 베어메탈 서브스크립션은 스태킹을 통해 총 코어 개수가 128개를 초과하는 소켓 페어와 소켓 페어가 2개 이상인 물리 서버에 적용될 수 있습니다.

물리 서버에 권한을 부여하려면 1개 이상의 서브스크립션을 스태킹하여 서버에 있는 총 소켓 수와 총 물리 코어 수 중 더 많은 쪽을 지원하세요. 예를 들어 어떤 서버에 2개의 소켓이 있고 각 CPU에 48개의 코어가 포함되어 있어 총 코어 수가 96개입니다. 이 경우 서버에 포함된 소켓은 1~2개이고 코어는 128개 미만이므로 필요한 서브스크립션은 1개입니다. 두 번째 서버에는 소켓이 2개이고 총 코어는 192개이므로 서브스크립션이 2개 필요합니다. 1개의 서브스크립션이 최대 128개의 코어를 지원하므로 192개의 코어를 지원하려면 2개의 서브스크립션이 필요합니다. (소켓이 각 1개인 서버 2개를 지원하거나 별도의 서버에서 코어를 지원하기 위해) 1개의 베어 메탈 소켓 페어 서브스크립션을 여러 개의 물리 호스트로 분배할 수는 없습니다.

소켓 기반 권한을 사용하는 각각의 물리 베어메탈 서버는 쿠버네티스의 내재적 아키텍처 때문에 1개의 OpenShift 노드로만 사용할 수 있습니다. 쿠버네티스의 각 노드는 1개의 클러스터에만 포함될 수 있으므로 베어메탈 서버의 모든 컨테이너는 동일한 클러스터에 위치하게 됩니다. 이는 각 워크로드가 1개의 VM 전체를 실행하고 있는 OpenShift Virtualization과 같은 리소스 집약적 워크로드에는 적합하지만 다른 워크로드에는 부적합할 수 있습니다. OpenShift가 단일 노드에서 최대 2,500개의 컨테이너를 지원하지만 성능 또는 아키텍처를 이유로 서로 다른 노드 또는 서로 다른 클러스터 간에 컨테이너를 나눠야 하는 상황이 있을 수 있습니다. 이는 가상화를 사용하여 베어메탈 서버에서 별도의 컴퓨팅 노드를 생성하지 않으면 불가능합니다.

컨테이너의 일반적인 배포 모델은 다수의 클러스터를 설계하고 각각에 더 작은 수의 컨테이너를 포함하는 것입니다. 이 모델은 하이퍼스케일러 환경에 일반적이며, 컨테이너가 배포되는 컴퓨팅 노드가 되는 VM을 생성하기 위해 하이퍼바이저를 사용함으로써 데이터센터에서 실현될 수 있습니다. VMware vSphere, Red Hat OpenStack Platform, Nutanix와 같은 하이퍼바이저의 경우 VM에 배포되는 OpenShift에 코어 페어 서브스크립션을 사용해야 합니다.

베어메탈 및 권한이 부여된 소켓 페어 서브스크립션에 배포되는 OpenShift Kubernetes Engine, OpenShift Container Platform 및 OpenShift Platform Plus 클러스터에는 OpenShift Virtualization과 배포된 동일 제품 유형의 가상 OpenShift 클러스터에 대한 서브스크립션이 포함됩니다. 따라서 가령 베어 메탈 OpenShift Container Platform 클러스터에 베포된 가상 OpenShift 클러스터는 호스팅 베어 메탈 클러스터로부터 OpenShift Container Platform 서브스크립션을 상속받습니다.

유의해야 할 점은 OpenShift Virtualization Engine 서브스크립션에는 컨테이너화된 애플리케이션 인스턴스에 대한 지원이 포함되지 않는다는 것입니다. 단, 아래 OpenShift Virtualization Engine 섹션에 정의된 인프라 워크로드는 예외입니다. OpenShift Virtualization Engine으로 컨테이너화된 자체 애플리케이션 워크로드를 실행하고자 한다면 자체 관리형 OpenShift용 코어 페어 서브스크립션을 사용하여 VM에 권한을 부여해야 합니다. 또는 밀도가 더 높은 경우라면 자체 관리형 OpenShift Kubernetes Engine, OpenShift Container Platform 또는 OpenShift Platform Plus에 대한 베어 메탈 소켓 페어 서브스크립션을 구입할 수 있습니다. 그러면 컨테이너 기반 애플리케이션을 베어 메탈 클러스터에서 기본적으로 실행하거나 앞서 설명한 대로 가상 클러스터가 서브스크립션을 상속받을 수 있습니다.

같은 클러스터 내에서 OpenShift 제품 유형을 혼합하여 사용할 수는 없습니다. 모든 노드는 동일한 OpenShift Virtualization Engine, OpenShift Kubernetes Engine, OpenShift Container Platform 또는 OpenShift Platform Plus 제품 유형을 사용하여 서브스크립션해야 합니다. 그러나 코어 페어와 소켓 페어 서브스크립션은 단일 클러스터 내에서 사용할 수 있습니다. 예를 들어 하나의 베어메탈 클러스터에서 일부 OpenShift Virtualization Engine 노드를 VM 호스팅에 사용하고 OpenShift Platform Plus를 사용하여 서브스크립션된 다른 노드를 컨테이너화된 애플리케이션과 가상 OpenShift 인스턴스를 호스팅하는 데 사용할 수 없습니다.

AI Accelerator 서브스크립션 집계 방법

최근, 특정 컴퓨팅 워크로드를 빠르게 실행할 수 있는 특정 하드웨어 기술이 출시되었습니다. 이러한 유형의 하드웨어 장치를 통틀어 가속기라고 하며 일부 Red Hat 콘텐츠에서는 AI 가속기라고 부릅니다. GPU, TPU, ASIC, NPU, FPGA 등을 포함하여 가속기로 분류될 수 있으면서 현대적인 서버에 제공되는 하드웨어 장치에는 여러 유형이 있습니다.

이러한 가속기는 일반적으로 카드, 보드 또는 기타 물리적 장치로, 서버에서 PCI(Peripheral Component Interconnect) 슬롯에 위치합니다. 대부분 가속기는 가속기 벤더로부터 구입한 장치 수와 일치합니다. 예를 들어 서버 벤더가 'GPU가 8개 포함됐다'라고 하면 거의 대부분의 경우 물리적 가속기 장치가 8개입니다.

각 AI Accelerator 서브스크립션은 1개의 물리적 가속기 장치를 지원합니다. AI Accelerator 서브스크립션만 놓고 예를 들어보겠습니다.

  • 4개의 물리적 GPU 장치가 포함된 1개의 물리적 컴퓨팅 노드에는 컴퓨팅 노드를 지원하는 CPU 코어 페어 또는 소켓 페어 서브스크립션 외에도 4개의 AI Accelerator 서브스크립션이 필요합니다.
  • 집계는 가상 가속기가 아닌 물리적 가속기를 기반으로 이뤄지므로, VM에는 vGPU가 여러 개로 표시되지만 실제 물리적 GPU 장치는 1개인 하나의 가상 컴퓨팅 노드에 필요한 AI Accelerator 서브스크립션은 1개입니다.

가속기는 컴퓨팅 워크로드 실행에 사용될 때만 집계됩니다. 워크로드의 주된 목적이 사용자 화면에 픽셀 아트를 거의 실시간으로 만들거나 네트워크 전반에서 데이터를 이동하는 것이 아닐 때 워크로드를 컴퓨팅 워크로드로 간주합니다.

VFX(시각 효과)와 스트리밍 애플리케이션의 경우 GPU와 기타 가속기 하드웨어가 사용될 수 있지만 주된 목적이 화면에 픽셀 아트를 만드는 것이므로 워크로드를 구분하는 것이 중요합니다. 워크로드의 주된 목적이 네트워크 전반에 데이터를 이동하는 경우도 있습니다(예: 네트워크 기능 전용의 데이터 처리 장치). 이 역시 컴퓨팅 노드로 간주되지 않습니다.

컴퓨팅 워크로드의 예는 다음과 같습니다.

  • Java, Python, Perl 등 기존 소프트웨어 애플리케이션
  • LLM 또는 기타 컴퓨팅 집약적 소프트웨어
  • 데이터 사이언스 모델 학습 및 조정
  • 단백질 접힘, 유체 역학 등과 같은 과학적 모델링 및 물리 시뮬레이션

집계 제외 대상

Red Hat OpenShift 컨트롤 플레인 및 인프라 노드

각 자체 관리형 OpenShift 서브스크립션은 Red Hat OpenShift와 기타 OpenShift 관련 구성 요소에 대한 권한을 포함합니다. OpenShift Kubernetes Engine, OpenShift Container Platform, OpenShift Platform Plus는 컴퓨팅 및 인프라 노드에 대한 Red Hat Enterprise Linux 권한을 포함합니다. Red Hat OpenShift Virtualization Engine은 스탠다드 Red Hat Enterprise Linux 작업자 또는 인프라 노드를 지원하지 않고, OpenShift 권한에 속한 Red Hat Enterprise Linux CoreOS OS만 지원합니다.

이러한 권한은 필수 OpenShift 컨트롤 플레인과 인프라를 실행하기 위해 포함되지만 필요한 Red Hat 서브스크립션 수를 결정할 때는 집계 대상에 포함될 필요가 없습니다.

Red Hat OpenShift Platform Plus 서브스크립션은 Red Hat Advanced Cluster Security for Kubernetes 및 Red Hat Advanced Cluster Management for Kubernetes를 통한 모든 노드의 관리도 포함합니다.

기본 설치 프로그램은 최종 사용자 애플리케이션을 실행하기 위한 최소 2개의 OpenShift 컴퓨팅 노드 외에도 3개의 컨트롤 플레인 노드로 구성된 고가용성 OpenShift 컨트롤 플레인을 배포합니다. 기본적으로 쿠버네티스 컨트롤 플레인 구성 요소(예: 애플리케이션 프로그래밍 인터페이스(API) 서버, etcd, 스케줄러) 및 지원 클러스터 서비스(예: 모니터링, 레지스트리)는 OpenShift 컨트롤 플레인 노드에 배포됩니다. 하지만 이러한 지원 클러스터 서비스 중 일부를 전용 '인프라 노드'로 이동할 수 있습니다.

인프라 노드의 자격을 얻어 그에 포함된 권한을 사용하기 위해 최종 사용자 애플리케이션의 일부가 아니라 클러스터를 지원하는 구성 요소만 해당 인스턴스에서 실행될 수 있습니다. 예를 들면 다음과 같습니다.

  • OpenShift 레지스트리
  • OpenShift Ingress Router(로컬/전역 및 멀티클러스터 수신)
  • OpenShift Observability
  • 클러스터 인그레스에 사용되는 HAProxy 기반 인스턴스
  • Red Hat Quay
  • Red Hat OpenShift Data Foundation
  • Red Hat Advanced Cluster Management for Kubernetes
  • Red Hat Advanced Cluster Security for Kubernetes
  • Red Hat OpenShift GitOps
  • Red Hat OpenShift Pipelines
  • Red Hat OpenShift용 호스팅된 컨트롤 플레인

모니터링, 로그 데이터 수집 및 전달, 하드웨어 드라이버, 인프라 통합을 위한 사용자 정의 및 타사 에이전트/툴(예: 가상화 에이전트)을 노드의 인프라 라이센싱 자격을 박탈하지 않고 인프라 노드에 배포하고 실행할 수 있습니다. 하지만 이는 오퍼레이터용 컨트롤러 포드를 포함한 에이전트 및 관련 구성 요소로 한정되며, 사용자 정의 또는 타사 소프트웨어 제품군은 포함하지 않습니다. 인프라 워크로드로서의 자격을 갖춘 Red Hat 소프트웨어 이외의 소프트웨어의 예시는 다음과 같습니다.

  • 사용자 정의 및 타사 모니터링 에이전트
  • 컨테이너 네트워크 인터페이스(CNI) 및 컨테이너 스토리지 인터페이스(CSI) 드라이버와 컨트롤러(플러그인)
  • 하드웨어 또는 가상화 지원 가속기
  • 쿠버네티스 사용자 정의 리소스 정의(CRD) 또는 오퍼레이터에 사용되는 컨트롤러 포드(사용자 정의 또는 타사 소프트웨어)

그 밖의 다른 최종 사용자 애플리케이션 인스턴스 또는 유형은 포함된 권한을 사용하는 인프라 노드에서 실행할 수 없습니다. 다른 인프라 워크로드를 Red Hat OpenShift에서 애플리케이션 인스턴스로 실행하려면 유효한 Red Hat OpenShift 서브스크립션을 통해 해당 인스턴스를 정규 애플리케이션 노드에서 실행해야 합니다. Red Hat을 통해 애플리케이션 또는 서비스가 인프라 워크로드의 자격을 갖추고 있는지 검증할 수 있습니다. 

Red Hat Enterprise Linux 권한

OpenShift 컴퓨팅 및 인프라 노드에 대한 Red Hat Enterprise Linux 권한은 OpenShift Kubernetes Engine, OpenShift Container Platform 및 OpenShift Platform Plus에 포함됩니다. 여기에는 애플리케이션에 대한 권한을 부여받은 포드와 VM에 대한 게스트 OS 권한도 포함됩니다. 그러나 Red Hat OpenShift 서브스크립션은 다음을 제외하고 Red Hat Enterprise Linux 노드에 대한 어떠한 권한도 포함하지 않습니다.

  • 베어메탈 IPI(Installer-Provisioned Infrastructure) 프로비저닝 전용 Red Hat Enterprise Linux 노드

OpenShift Virtualization Engine은 컴퓨팅 및 인프라 노드용으로도, VM에 대한 게스트 OS 권한용으로도 Red Hat Enterprise Linux를 포함하지 않습니다. OpenShift Virtualization Engine을 기반으로 하는 Red Hat Enterprise Linux 게스트에는 Red Hat Enterprise Linux for Virtual Datacenters 서브스크립션 또는 VM당 서브스크립션이 필요합니다.

Red Hat Enterprise Linux 권한의 경우 인터넷 프록시, 부하 분산기 또는 미러 레지스트리와 같이 OpenShift가 의존하는 외부 노드 호스팅 서비스용으로는 포함되지 않습니다. Red Hat Satellite는 권한의 일부로 포함되지 않습니다.

OpenShift 컨테이너 이미지 미러링을 위한 부트스트랩 컨테이너 레지스트리

OpenShift에 대한 미러 레지스트리는 연결되지 않은 OpenShift 클러스터를 부트스트래핑하는 데 필요한 미러링 콘텐츠 프로세스를 완화하는 단일 목적을 위한 Quay 권한으로, Red Hat OpenShift 서브스크립션의 일부로 포함되어 있습니다. 사전 프로비저닝된 고객 관리형 Red Hat Enterprise Linux 호스트에서 Quay 레지스트리를 실행하기 위한 특정 설치 프로그램에서 생성된 최소한의 Quay 배포를 위한 제한된 지원 권한입니다.

참고: Quay는 OpenShift 릴리스 페이로드, OperatorHub 콘텐츠, 샘플 오퍼레이터 이미지, Cincinnati 그래프 이미지, 그리고 Red Hat OpenStack Services on OpenShift, Red Hat OpenShift Data Foundation 등 Red Hat OpenStack Platform 오퍼링에 관련된 이미지를 미러링하기 위한 목적에 국한하여 레지스트리 미러로 사용할 수 있습니다.

OpenShift용 미러 레지스트리는 임의의 규모에서 작동하는 범용 레지스트리로 사용할 수 없습니다. 하지만 제한된 사용자 정의 이미지 세트의 경우 저장이 가능하며, 여기에는 필수 보조 소프트웨어(예: 자격이 있는 인프라 워크로드를 위한 에이전트와 컨테이너 이미지)가 포함됩니다. 다음 예가 이에 해당될 수 있습니다.

  • 모니터링 에이전트
  • CNI 및 CSI 제공업체
  • 하드웨어 또는 가상화 지원 에이전트
  • 독립 소프트웨어 벤더(ISV) 서비스를 지원하는 오퍼레이터
  • 배포 컨트롤러로서의 사용자 정의 오퍼레이터

호스팅된 컨트롤 플레인

전형적인 OpenShift 인프라의 경우 각 OpenShift 클러스터마다 최소 3개의 컨트롤 플레인 노드가 필요합니다. 이에 대한 대안은 호스팅된 컨트롤 플레인을 사용하는 것으로, 이 경우 컨트롤 플레인은 중앙 컨트롤 플레인 클러스터에서 실행되고 OpenShift 클러스터에 논리적 컨트롤 플레인을 제공합니다. 언제나 그렇듯이 컨트롤 플레인 노드와 인프라 노드는 서브스크립션에 포함되지 않지만 아키텍처에는 포함되어야 합니다.

호스팅된 컨트롤 플레인은 어떤 베어 메탈 OpenShift 클러스터에서든지 실행될 수 있지만 클러스터의 컴퓨팅 노드는 실행 기반이 되는 인프라에 따른 권한이 필요합니다. 예를 들어 OpenShift Virtualization Engine에 호스팅된 가상 클러스터는 컴퓨팅 노드에 대한 코어 페어 서브스크립션이 필요한 반면, 컨트롤 플레인이 OpenShift Virtualization Engine 클러스터에 의해 호스팅되고 베어메탈 컴퓨팅 노드를 사용 중인 클러스터는 베어 메탈 소켓 페어 서브스크립션이 필요합니다.

예외 1: 컨트롤 플레인 또는 인프라 노드에서 애플리케이션 인스턴스를 실행할 경우

OpenShift 컨트롤 플레인 노드는 기본적으로 컴퓨팅 노드로 사용되지 않으며, 따라서 애플리케이션 인스턴스를 실행하지 않습니다. 컨트롤 플레인 노드에 전체 Red Hat OpenShift 서브스크립션이 필요한지 여부는 지원 OpenShift 클러스터 구성 요소만 실행하는지, 아니면 최종 사용자 애플리케이션을 실행하는지에 따라 다릅니다. 최종 사용자 애플리케이션을 호스팅하기 위한 노드로 컨트롤 플레인 노드를 사용할 경우 모든 코어에 대한 서브스크립션이 필요합니다. 인프라 노드 섹션에서 서브스크립션이 필요하지 않은 자격을 갖춘 워크로드를 식별하는 방법을 참조하세요.

예외 2: 컴팩트한 클러스터 배포

3노드 OpenShift와 같은 컴팩트한 클러스터 배포에서 최종 사용자 애플리케이션 워크로드는 컨트롤 플레인 노드에서 실행됩니다. Red Hat OpenShift 서브스크립션에 대한 노드 3개의 코어는 역할에 상관없이 집계해야 합니다.

단일 노드 OpenShift 인스턴스는 모든 OpenShift 서비스 및 최종 사용자 애플리케이션을 단일 물리 또는 가상 노드로 배포하며, 최적화를 통해 풋프린트를 줄이고 애플리케이션에서 사용 가능한 리소스를 극대화합니다. 위에서 언급한 컴팩트한 3노드 클러스터와 마찬가지로, 이 배포 모델에 적용되는 특별한 요구 사항은 없으며 노드 상의 모든 코어는 권한이 있어야 합니다.

특별 활용 사례

재해 복구

Red Hat은 핫(Hot), 웜(Warm), 콜드(Cold) 등 3가지 유형의 재해 복구(DR) 환경을 정의합니다. 유료 Red Hat OpenShift 서브스크립션은 핫 DR에만 필요합니다.

  • 핫 DR 시스템은 올바르게 작동하고 프로덕션 시스템과 동시에 실행되는 것으로 정의됩니다. 이 시스템은 기본 환경 내 재해 발생 시 트래픽을 즉시 수신하여 대신 작업을 수행할 준비가 되어 있습니다. 데이터 볼륨이 클러스터 간에 동기식으로나 비동기식으로 활발히 복제되고 있는 경우에는 '핫' DR 시스템으로 간주됩니다.
  • 웜 DR 시스템은 기본 사이트에서 발견되는 워크로드의 알맞은 복제본을 나타내는 컨테이너화된 워크로드를 배포 및 호스팅할 준비를 이미 갖춘 상태로 정의되지만 소스 클러스터의 고객 워크로드는 포함하지 않습니다. 웜 DR 시스템은 클러스터 간에 동기식 또는 비동기식으로 활성화된 데이터 볼륨 복제에 참여해서는 안 됩니다. 웜 DR의 경우 기존 클러스터 외부에 있던 고객 데이터가 해당 클러스터 하드웨어로 복원되어야 합니다.
  • 콜드 DR 시스템은 인프라는 갖췄으나 서비스 복원에 필요한 전체 기술(하드웨어, 소프트웨어)은 보유하지 않은 것으로 정의됩니다.

수요가 낮아 임시로 하이버네이션하고 있는 클라우드 서비스에서 실행되는 클러스터와 같이 웜 또는 콜드 DR에 대하여 명시적으로 구성 및 설계되지 않은 하이버네이션 클러스터에는 서브스크립션이 필요합니다. 워크로드 실행을 위해 웜 또는 콜드 DR 클러스터의 하이버네이션을 제거하는 경우 서브스크립션이 필요합니다. 정기적인 유지 관리 또는 테스트를 위해 클러스터의 하이버네이션을 임시로 제거하는 경우 OpenShift 소프트웨어 오퍼링의 모든 구성 요소에 대해 추가적인 서브스크립션이 필요하지 않습니다.

웜 DR 및 콜드 DR의 경우 재해 발생 시 Red Hat OpenShift 서브스크립션을 기본 환경에서 DR 환경으로 이전하여 서비스를 복원하고 Red Hat 서브스크립션 약관에 대한 컴플라이언스를 유지할 수 있습니다.

마이그레이션 및 스윙 업그레이드

Red Hat OpenShift 4는 마이너 버전 간 인플레이스 업그레이드(in-place upgrade)를 제공합니다. 그렇지만 Red Hat OpenShift 3에서 업그레이드하거나 유지 관리 기간 또는 기타 고려 사항으로 인해 OpenShift 4 마이너 버전 간에 스윙 업그레이드를 수행해야 하는 경우 Red Hat OpenShift 서브스크립션은 단방향 마이그레이션의 원래 인프라와 대상 인프라 모두를 마이그레이션이 완료될 때까지 지원합니다. 마이그레이션 과정에서는 Red Hat의 서브스크립션 관리 툴에 고객이 구입한 Red Hat OpenShift 서브스크립션의 수에 따라 고객의 환경이 컴플라이언스 미준수 상태로 표시됩니다. Red Hat은 메이저 버전 업그레이드의 경우 이를 허용하며, 마이그레이션 중 컴플라이언스 상태의 복원을 위해 추가 서브스크립션 구매를 요구하지 않습니다. 마지막으로 Red Hat OpenShift는 이러한 마이그레이션을 지원하는 툴링을 제공하며, 원하는 경우 Red Hat Consulting 서비스도 함께 제공합니다. 컨테이너를 위한 마이그레이션 툴킷에 관한 도큐멘테이션을 참조하세요.

하이퍼스레딩을 사용하는 코어에 대한 권한

특정 OpenShift 노드가 한 개 이상의 물리적 코어를 사용하는지 파악하려면 시스템에 코어당 여러 스레드가 활성화되어 있는지를 알아야 합니다. 특정 시스템이 하이퍼스레딩을 지원하는지 확인하는 방법을 알아보세요.

AMD EPYC CPU용 동시 멀티스레딩(SMT) 또는 Intel CPU를 통한 하이퍼스레딩이라고도 하는 논리적 CPU 스레드를 사용하는 가상화된 OpenShift 노드는 할당된 코어/CPU의 수를 기반으로 Red Hat OpenShift 서브스크립션에 대한 코어 이용을 집계합니다. 그러나 논리적 CPU 스레드가 사용될 경우 각 서브스크립션에는 4개의 vCPU/코어가 포함됩니다. Red Hat의 서브스크립션 관리 툴은 논리적 CPU 스레드가 기본적으로 모든 시스템에서 활성화되어 있다고 가정합니다.

베어메탈 서브스크립션은 물리 코어만 집계하며, 베어 메탈에 필요한 서브스크립션 수를 계산할 때 논리적 CPU 스레드는 집계되지 않습니다.

대체 아키텍처(ARM, IBM Z, IBM LinuxONE, IBM Power)

참고: 지금부터 이 문서에서는 IBM Z만 언급하지만 IBM Z를 언급하는 모든 정보는 IBM LinuxONE에도 적용됩니다.

Red Hat OpenShift Container Platform은 ARM, IBM Z, IBM Power를 클라우드 네이티브 애플리케이션 및 마이크로서비스를 빌드하고 배포하기 위한 표준으로 사용하는 고객을 위해 해당 플랫폼에서도 실행될 수 있습니다. IBM Z 및 IBM Power 플랫폼에서는 코어 기반 서브스크립션 모델만 지원됩니다.

ARM 클러스터에는 x86 서버와 동일한 룰을 사용할 수 있는 권한이 부여됩니다.

IBM Z 고객에게는 Red Hat OpenShift가 전체 물리 노드에 대한 권한이 아닌 OpenShift가 사용하는 코어에 대한 권한만 요구합니다. IBM Z 고객은 이를 '하위 용량' 권한이라고 합니다. OpenShift Container Platform용 IBM Z 환경에서 사용 가능한 코어(컴퓨팅 용량)의 일부만 사용하는 고객은 컴퓨팅 노드에 사용되는 부분에 대한 서브스크립션만 필요합니다. 이것은 CPU 풀링, 최대 가용량 사용, 별도의 논리적 파티션(LPAR) 또는 기타 수단 중에서 어느 것을 사용하든 CPU를 분할하는 방식에 관계없이 적용됩니다.

IBM Z의 경우 하나의 IFL(Integrated Facility for Linux)에는 하나의 OpenShift 코어 페어 서브스크립션이 필요합니다. 파티셔닝을 사용하지 않는 경우 클러스터당 최대 3개의 IFL을 호스트에서 실행되는 컨트롤 플레인 또는 인프라 서비스에 대해 OpenShift 클러스터마다 식별할 수 있습니다. 이러한 IFL은 자격을 갖추려면 컨트롤 플레인 및/또는 인프라 서비스에 대해 적극적으로 사용되어야 하며, OpenShift 권한은 필요하지 않습니다. 컴팩트한 3노드 클러스터 배포에서는 모든 IFL에 대한 권한이 요구됩니다.

OpenShift Container Platform 외의 Red Hat OpenShift Platform Plus 구성 요소는 현재 IBM Z 및 IBM Power에서 지원되지 않으며, 다음과 같은 예외 사항이 있습니다.

  • x86 아키텍처에서 실행되는 Red Hat Quay의 독립형 서브스크립션은 IBM Z 및 IBM Power 클러스터를 포함하여 여러 아키텍처에 전역 레지스트리를 제공합니다. Red Hat Quay 자체는 IBM Z 또는 IBM Power에서 실행되지 않습니다.
  • Red Hat Advanced Cluster Management for Kubernetes는 IBM Z 또는 IBM Power 환경에 설치되어 해당 환경에서 실행되는 Red Hat OpenShift 노드를 관리할 수 있습니다.
  • Red Hat Advanced Cluster Security for Kubernetes를 통해 Red Hat Advanced Cluster Security Operator를 사용하면 IBM Z 또는 IBM Power 기반의 Red Hat OpenShift에서 실행되는 클러스터를 보호할 수 있습니다.
  • Red Hat OpenShift Data Foundation은 IBM Z 또는 IBM Power에서의 설치를 전적으로 지원합니다.

Red Hat OpenShift Platform Plus 서브스크립션의 구성 요소는 대체(x86 이외) 아키텍처에 다양한 수준의 지원을 제공합니다. 문서 Red Hat OpenShift Container Platform 4.16 Multi Architecture Component Availability Matrix를 참조하세요. OpenShift Platform Plus 구성 요소와 x86 외 아키텍처 간 상호 운용성에 대한 자세한 정보는 Red Hat OpenShift Container Platform, Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay 및 Red Hat OpenShift Data Foundation에 대한 호환성 매트릭스를 참조하세요.

Red Hat OpenShift Kubernetes Engine과 Red Hat OpenShift Virtualization Engine은 IBM Z와 IBM Power에서 지원되지 않습니다.

Microsoft Windows Server 컨테이너 지원

자체 관리형 OpenShift는 Microsoft Windows Server 컨테이너를 사용하는 설치 인프라 및 OpenShift 기능의 하위 집합을 지원합니다. Windows Server 컨테이너는 Microsoft Windows Server 기반의 컴퓨팅 노드에서만 지원됩니다. OpenShift 환경의 컨트롤 플레인과 인프라 플레인은 Red Hat Enterprise Linux 또는 Red Hat Enterprise Linux CoreOS를 사용하는 x86 인프라에서 실행 중이어야 합니다. 이러한 이유로 Windows Server 컨테이너 지원은 코어를 기준으로 가격이 책정되는 독립형 서브스크립션으로 판매됩니다.

Red Hat OpenShift Platform Plus 및 Red Hat OpenShift Container Platform 인프라를 사용해 Windows Server 컴퓨팅 노드를 배포하고 관리할 수 있습니다. Red Hat OpenShift 서브스크립션에 대한 Microsoft Windows Server 컨테이너 지원은 별도의 애드온(add-on)으로 구입해야 합니다.

Red Hat Advanced Cluster Management와 Red Hat Advanced Cluster Security는 Microsoft Windows 노드 관리를 지원하지 않지만 x86 아키텍처에서 실행되는 Red Hat Quay는 Microsoft Windows Server 기반의 워크로드용 컨테이너 이미지를 관리할 수 있습니다.

각 상황에 맞게 어디까지나 지침으로 활용

Red Hat OpenShift는 확장성, 포드 스케줄링, 유휴, 리소스 할당량/제한 기능에 영향을 미치는 여러 특징과 기능을 지원합니다. 위 계산은 지침으로 제시한 것이며, 실제 환경을 조정하여 리소스 사용을 개선하거나 총 환경 크기를 줄일 수 있습니다. OpenShift Platform Plus 고객은 추가 컴퓨팅 서브스크립션이 필요 없는 경우라도 스토리지 및 컴퓨팅 리소스를 포함한 추가 소프트웨어 애플리케이션(Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Quay)의 요구 사항을 고려해야 합니다.

타사 리셀러와 협업 관계인 경우에는 Red Hat 제품 및 서비스에 대한 구체적인 약관과 계약 사항을 확인하시기 바랍니다. 

Red Hat OpenShift Platform Plus 구성 요소 지원

Red Hat OpenShift Platform Plus에는 OpenShift Container Platform 외에도 추가 소프트웨어가 포함되어 있어 OpenShift 환경을 여러 클러스터 및 클라우드 전반에서 규모에 맞게 관리하고 안전하게 보호할 수 있습니다. Red Hat OpenShift Platform Plus는 코어 페어 및 베어 메탈 소켓 페어 서브스크립션 모델에서 제공되며 위에 나열된 제한 사항이 적용됩니다.

Red Hat OpenShift Platform Plus에 포함된 추가 소프트웨어는 일반적으로 OpenShift Platform Plus 서브스크립션 사용 권한이 있는 노드를 관리하는 역할만 합니다. 예를 들어, OpenShift Platform Plus에 포함된 Red Hat Advanced Cluster Management에 대한 서브스크립션은 OpenShift Platform Plus 권한이 있는 노드 및 클러스터를 관리하는 데만 사용할 수 있습니다. 고객이 Red Hat OpenShift Service on AWS 클러스터와 같이 OpenShift Platform Plus 이외의 환경에 대한 권한이 있는 노드 및 클러스터를 관리하려면 이러한 클러스터를 지원하는 Red Hat Advanced Cluster Management 애드온(add-on) 서브스크립션을 추가 구입해야 합니다.

추가 소프트웨어 서브스크립션도 OpenShift Platform Plus 서브스크립션에서 분리할 수 없습니다. 예를 들어, 100개의 OpenShift Platform Plus 서브스크립션을 구입해 Red Hat OpenShift Container Platform 서브스크립션의 코어 200개를 설치하고, Red Hat Advanced Cluster Management를 별도로 사용해 동일한 서브스크립션으로 Azure Red Hat OpenShift의 코어 200개를 관리할 수는 없습니다. 추가 소프트웨어는 핵심 OpenShift Platform Plus 소프트웨어가 설치된 동일한 코어 200개를 관리하는 데만 사용할 수 있습니다.

계층화된 각 제품에는 다음과 같은 특정 룰이 적용됩니다.

  • Red Hat Advanced Cluster Management for Kubernetes: OpenShift Platform Plus 서브스크립션을 사용하면 환경을 관리하는 데 필요한 만큼의 Red Hat Advanced Cluster Management 중앙 인스턴스를 설치할 수 있고, 컨트롤 플레인과 인프라 노드를 포함하여 OpenShift Platform Plus 권한이 있는 모든 노드 및 클러스터에 대한 관리가 지원됩니다. OpenShift Platform Plus 권한이 없는 노드와 클러스터를 관리하려는 경우(예: 자체 관리형 OpenShift Container Platform 또는 Red Hat OpenShift Kubernetes Engine에 대한 권한이 부여된 클러스터, 전체 관리형 OpenShift 클라우드에서 실행되는 클러스터 또는 Red Hat Advanced Cluster Management가 지원하는 타사 쿠버네티스 환경도 보유한 경우) 이러한 환경을 지원하는 Red Hat Advanced Cluster Management 애드온(add-on) 서브스크립션을 구입해야 합니다. OpenShift Platform Plus에 설치된 Red Hat Advanced Cluster Management 콘솔에서 중앙집중식으로 관리하거나 요구 사항을 충족하는 경우 별도의 중앙 애플리케이션에서 관리하는 방식을 선택할 수 있습니다. Red Hat Advanced Cluster Management 서브스크립션, Red Hat Advanced Cluster Management 지원 환경 및 Red Hat Advanced Cluster Management 모범 사례에 대해 자세히 알아보세요.
  • Red Hat Advanced Cluster Security for Kubernetes: OpenShift Platform Plus 서브스크립션을 사용하면 환경을 관리하는 데 필요한 만큼의 Red Hat Advanced Cluster Security 중앙 애플리케이션을 설치할 수 있고, 컨트롤 플레인과 인프라 노드를 포함하여 OpenShift Platform Plus 권한이 있는 모든 노드 및 클러스터에 대한 관리가 지원됩니다. OpenShift Platform Plus 권한이 없는 노드와 클러스터를 관리하려는 경우(예: 자체 관리형 OpenShift Container Platform 또는 OpenShift Kubernetes Engine에 대한 권한이 부여된 클러스터, 전체 관리형 Red Hat OpenShift 클라우드에서 실행되는 클러스터 또는 Red Hat Advanced Cluster Security가 지원하는 타사 쿠버네티스 환경도 보유한 경우) 이러한 환경을 지원하는 Red Hat Advanced Cluster Security 애드온(add-on) 서브스크립션을 구입해야 합니다. Red Hat이 제안하는 사례는 각 환경을 별도의 Red Hat Advanced Cluster Security 중앙 애플리케이션으로 관리하는 것입니다. Red Hat Advanced Cluster Security 지원 환경에 대해 자세히 알아보세요.
  • Red Hat Quay: OpenShift Platform Plus 서브스크립션을 통해 OpenShift Platform Plus 권한이 있는 모든 클러스터에 Red Hat Quay를 설치할 수 있습니다. OpenShift Platform Plus 클러스터에 설치할 수 있는 Quay 배포의 수에는 제한이 없습니다. 이후 Quay는 OpenShift Platform Plus 환경, 기타 자체 관리형 OpenShift 클러스터, 관리형 OpenShift 서비스, 지원되는 타사 쿠버네티스 등 원하는 모든 지원되는 쿠버네티스 환경에 서비스를 제공할 수 있습니다. OpenShift Platform Plus 환경이 아닌 곳에 Quay를 설치하려면 별도의 Red Hat Quay 서브스크립션을 구입해야 합니다. Quay는 전체 관리형 서비스로서의 소프트웨어(SaaS) 오퍼링으로도 제공됩니다.
  • Red Hat OpenShift Data Foundation OpenShift Platform Plus 서브스크립션을 통해 OpenShift Platform Plus 권한이 있는 모든 클러스터에 Red Hat OpenShift Data Foundation Essentials를 설치할 수 있습니다. Red Hat Data Foundation 권한은 Essentials에서 제공되는 기능과 OpenShift 클러스터당 256TB의 데이터 스토리지로 제한됩니다. 추가 서브스크립션을 통해 기능과 용량을 확장할 수 있습니다. OpenShift Data Foundation 서브스크립션 가이드(고객 포털 로그인 필요)를 참조하거나 Red Hat 영업 담당자에게 문의하여 자세한 안내를 받으시기 바랍니다.

Red Hat OpenShift Virtualization Engine 및 관련 제품

OpenShift Virtualization은 모든 자체 관리형 OpenShift 버전에 오랫동안 포함되어 온 기능으로, 고객은 클라우드 네이티브 애플리케이션에 VM 워크로드를 포함하고 VM을 마이크로서비스와 컨테이너로 현대화할 수 있습니다.

가상화 시장의 최근 변화로 인해 현대화 경로를 제공하는 가상화 플랫폼을 중심으로 대체 가상화 플랫폼에 대한 수요가 증가했습니다. 이러한 고객 중 상당수가 초기 VM 마이그레이션 시에는 OpenShift 기능이 전부 필요하지 않습니다. 따라서 그러한 활용 사례에는 자체 관리형 OpenShift의 간소화되고 저렴한 대체 버전을 선호할 것입니다.

Red Hat OpenShift Virtualization Engine은 특별히 대체 가상화 플랫폼으로 VM을 실행하고자 하는 고객을 대상으로 설계된 자체 관리형 OpenShift 버전입니다. OpenShift Virtualization Engine은 지원되는 물리 서버와 지원되는 하이퍼스케일러 베어메탈 인스턴스에서 베어 메탈 소켓 페어 서브스크립션을 통해 권한이 부여됩니다.

OpenShift Virtualization Engine은 다음과 같이 가상 머신을 배포, 관리, 실행하는 데 필요한 기능만을 제공합니다.

  • 서브스크립션한 호스트의 VM 무제한
  • 컨테이너에서 애플리케이션 인스턴스(예: 상업용 소프트웨어, 고객 애플리케이션)를 실행하는 데 사용될 수 없고, VM만 실행
  • VM 내에서 어떠한 Red Hat OpenShift 버전도 실행할 수 있는 서브스크립션이 없음(코어 페어 서브스크립션의 별도 구매 필요)
  • VM에 대한 Red Hat Enterprise Linux 게스트 권한이 포함되어 있지 않음(Red Hat Enterprise Linux for Virtual Datacenter 또는 VM당 서브스크립션의 별도 구매 필요)

현재 Red Hat에는 2가지의 OpenShift Virtualization Engine용 애드온 제품이 있습니다.

  • Red Hat Advanced Cluster Management for Virtualization은 가상화와 하이퍼바이저 라이프사이클 관리 및 운영을 풀 버전 Advanced Cluster Management보다 낮은 비용에 지원합니다(OpenShift Virtualization Engine 서브스크립션당 서브스크립션 1개).
  • Red Hat Ansible® Application Platform for Virtualization은 마이그레이션 및 Day 1 오퍼레이션을 목적으로 OpenShift Virtualization Engine을 실행하는 하이퍼바이저 노드에 대한 지원을 제공합니다(OpenShift Virtualization Engine 서브스크립션당 서브스크립션 1개).

기존 Advanced Cluster Management 및 Ansible Application Platform 고객의 경우 기존에 설치되어 있는 이 중앙 애플리케이션을 사용하여 환경의 나머지 부분을 지원하고 앞서 언급한 애드온 서브스크립션을 구매해 OpenShift Virtualization Engine 호스트를 관리할 수 있습니다.

Advanced Cluster Management 또는 Ansible Application Platform 중앙 애플리케이션이 기존에 설치되어 있지 않은 고객의 경우 앞서 언급된 애드온에 대한 서브스크립션을 통해 중앙 애플리케이션을 OpenShift Virtualization Engine 호스트에 인프라 컨테이너로 설치할 수 있습니다. Advanced Cluster Management 또는 Ansible Application Platform에 대한 도큐멘테이션에서 이러한 중앙 애플리케이션의 설치와 아키텍처 모범 사례를 참조하세요.

VM에 Day 2 자동화가 필요한 고객에게는 Ansible Automation Platform을 추천합니다. 위에 나열된 하이퍼바이저 노드 서브스크립션 외에도 고객은 각 VM 인스턴스에 대해 노드 서브스크립션이 필요합니다. 자세한 내용은 Ansible Automation Platform 도큐멘테이션을 참조하세요.

OpenShift Virtualization Engine에 대한 권한은 고객 애플리케이션 인스턴스를 VM으로 제한하지만 스토리지 드라이버, 백업 애플리케이션, 전달 에이전트, Advanced Cluster Management, Ansible Automation Platform 등과 같은 인프라 요구 사항의 대부분은 Red Hat OpenShift에서 인프라 컨테이너로 실행됩니다. 따라서 권한에 따라 컨테이너에서 그러한 인프라 기능을 실행할 수 있습니다. 뿐만 아니라 VM용 스토리지를 제공하지만 그 자체가 컨테이너에서 실행되는 소프트웨어 정의 스토리지 솔루션도 권한에 포함됩니다. 이러한 인프라 컨테이너에 적합한 항목에 대한 지침은 다른 Red Hat OpenShift 버전용 인프라 노드에 적합한 워크로드에 대한 지침과 동일합니다. '집계 제외 대상' 섹션에 있는 인프라 노드에 대한 정보를 참조하세요. OpenShift Virtualization Engine용 인프라 워크로드로 적합한 애플리케이션 또는 서비스인지 여부는 Red Hatter와 확인하세요.

자체 관리형 OpenShift 환경의 사이징에 접근하는 방법

자체 관리형 OpenShift(Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform 또는 Red Hat OpenShift Kubernetes Engine) 또는 애드온 서브스크립션이 몇 개나 필요한지 파악하려면 다음 질문과 예시를 사용하세요.

요약하면 다음과 같습니다.

  • 애플리케이션은 컨테이너 이미지 또는 VM에 패키징됩니다.
  • 컨테이너와 VM은 포드로 배포됩니다.
  • 포드는 OpenShift 컨트롤 플레인 노드를 통해 관리되는 OpenShift 컴퓨팅 노드에서 실행됩니다.

권한 요구 사항을 추산하는 방법

Red Hat OpenShift 서브스크립션은 애플리케이션 인스턴스를 제한하지 않습니다. 기본 하드웨어 및 인프라가 지원하는 수만큼의 애플리케이션 인스턴스를 Red Hat OpenShift 환경에서 실행할 수 있습니다. 용량이 더 큰 하드웨어는 적은 수의 호스트에서 다수의 애플리케이션 인스턴스를 실행할 수 있는 반면, 용량이 더 적은 하드웨어에서는 다수의 호스트가 다수의 애플리케이션 인스턴스를 실행해야 할 수 있습니다. Red Hat OpenShift 환경의 크기를 파악하는 데 있어 기본 요소는 주어진 시점에 실행되는 포드 또는 애플리케이션 인스턴스의 수입니다.

1단계: 필요한 애플리케이션 인스턴스의 개수 및 유형 파악

애플리케이션부터 시작합니다. 배포할 애플리케이션 인스턴스 또는 포드의 수를 결정합니다. 환경의 크기를 조정할 때 데이터베이스, 프론트엔드 정적 서버 또는 VM 인스턴스 등 Red Hat OpenShift에 배포되는 모든 애플리케이션 구성 요소는 애플리케이션 인스턴스로 간주됩니다.

이 수치는 Red Hat OpenShift 환경의 크기를 개략적으로 산출하는 데 도움이 되는 근사치일 수 있습니다. CPU, 메모리 오버서브스크립션, 할당량 및 한도, 기타 기능을 사용해 더욱 정확한 추정치를 계산할 수 있습니다.

표 1: 애플리케이션 및 인스턴스 사이징 관련 질문

 

관련 질문

예시 답변

  • 각 Red Hat OpenShift 환경에 몇 개의 애플리케이션 인스턴스를 배포할 것으로 예측하는가?
  • 어떤 유형의 애플리케이션인가(예: 언어, 프레임워크, 데이터베이스)?
  • VM 워크로드의 경우 VM의 표준 구성은 무엇인가? 모두 사용자 정의 구성인가? 아니면 애플리케이션별로 표준화되는가? 그리고 구성 요구 사항은 무엇인가?
  • 개발 환경에 약 1,250개의 애플리케이션 인스턴스를, 프로덕션에 약 250개의 애플리케이션 인스턴스를 보유하고 있습니다.
  • 주로 Java를 배포하지만 Microsoft.NET Core 및 Ruby 애플리케이션을 배포하는 경우도 있습니다. 또한 MySQL을 사용합니다.
  • 일반적인 VM에는 vCPU 4개와 8GB의 RAM이 필요합니다.
  • 일반적인 컨테이너에는 vCPU 2개와 2GB의 RAM이 필요합니다.

 

2단계: 필요한 총 메모리 및 총 코어 수 결정

1개의 애플리케이션 인스턴스에 대한 요구 사항과 애플리케이션 인스턴스 수를 결정했다면 컴퓨팅과 메모리 모두에 필요한 총 리소스 양을 결정하는 것은 간단합니다.

이때 컴퓨팅 노드가 충족해야 할 최대 활용도를 결정해야 합니다. 그러면 OpenShift의 관리 오버헤드를 줄일 수 있으며(일반적으로 코어 1개 또는 vCPU 1개 및 컴퓨팅 노드당 <1GB의 RAM. 자세한 내용은 도큐멘테이션 참조), 자동 스케일링(autoscaling)이 필요하기 전에 애플리케이션을 정상적으로 변형할 수 있습니다. 적극적인 활용도(80% 이상)를 가정하는 경우 메모리와 코어 리소스 계산에 OpenShift 오버헤드 요구 사항을 명시적으로 고려해야 할 수도 있습니다.

가상화 활용 사례의 경우 CPU 및 메모리 과다 할당, 이중화 및 고가용성 고려 사항, 전체적인 환경 아키텍처 등을 고려해야 합니다. 사이징 예 3의 그림을 살펴보겠습니다.

표 2: 선호하는 최대 OpenShift 노드 활용도 관련 질문

 

관련 질문

예시 답변

수요 증가에 대비해 얼마만큼의 공간을 예약하고 싶은가?

총 용량의 최대 평균 80% 수준으로 노드를 실행하고 싶습니다(20%는 여유 공간).

 

최대 활용도 = 아키텍트가 선택한 비율(%)

필요한 총 코어(또는 vCPU) = '애플리케이션 1개의 코어' X '애플리케이션 인스턴스 수' X 1 / '활용률'

필요한 총 메모리 = '애플리케이션 1개의 메모리' X '애플리케이션 인스턴스 수' X 1 / '활용률'

3단계: 표준 컴퓨팅 노드 선택(VM, 클라우드 인스턴스 또는 베어메탈 서버)

이제 수용할 총 코어 및 메모리가 결정되었습니다. 다음으로 애플리케이션에 대한 작업자 노드를 배포하기 위해 표준 컴퓨팅 노드를 선택해야 합니다.

가상화 인프라에서는 사용자 환경에 따라 컴퓨팅 노드의 역할을 담당할 VM의 구성을 선택하거나 몇 가지 표준 '티셔츠 사이즈' VM 유형 중 하나를 선택해야 할 수 있습니다.

하이퍼스케일러 클라우드에서는 일반적으로 컴퓨팅, 메모리, 그리고 AI 가속기 같은 옵션 장비에 대한 액세스 등이 다른 클라우드 인스턴스 유형을 선택해야 합니다.

온프레미스 또는 하이퍼스케일러 베어 메탈 인스턴스에서 베어 메탈에 배포하는 경우 표준 서버 구성을 선택할 수 있으며, 구성을 지정할 수 있는 경우도 있습니다.

가능하다면 비율 또는 코어 요구 사항 및 메모리 요구 사항에 가장 맞는 컴퓨팅 노드를 선택해야 합니다. 예를 들어 내 컨테이너의 총 요구 사항이 vCPU 400개와 1600GB의 RAM이라면 vCPU와 메모리의 비율이 약 1:4인 컴퓨팅 노드를 선택함으로써 가장 적합한 평균 통합 비율을 얻을 수 있습니다. 

표 3: VM 및 하드웨어 사이징 관련 질문

 

관련 질문

예시 답변

  • 노드에 사용할 VM의 메모리 용량은 얼마인가?
  • 노드에 사용할 VM의 vCPU는 몇 개인가?

     
  • 하이퍼스레딩을 사용 중인가?
  • 몇 개의 AI 가속기를 사용 중인가?
  • 현재 VM은 64GB 메모리와 vCPU 4개를 갖추고 있으며 하이퍼스레딩을 사용 중입니다.
  • 데이터센터에서 VM을 커스터마이징하여 컨테이너 워크로드에 사용할 수 있습니다.
  • Amazon EC2를 사용하고 있고, M6i 및 M7i 인스턴스 유형에 대한 액세스 권한이 있습니다.
  • 베어메탈 시스템은 128GB의 RAM과 CPU 소켓 2개(코어 64개)를 포함하며, 하이퍼스레딩을 사용 중이고, 1개의 GPU가 있습니다.

 

4단계: 필요한 총 서브스크립션 수 계산

끝으로, 1-3단계에서 수집된 데이터에 근거하여 필요한 Red Hat OpenShift 서브스크립션의 수를 결정합니다. VM 또는 하이퍼스케일러 클라우드 인스턴스의 서브스크립션의 경우 코어 페어 서브스크립션 모델을 사용해야 합니다. 베어메탈 서버의 경우 두 모델을 모두 사용하여 서브스크립션을 계산하고, 각 모델의 비용 및 유연성의 차이를 비교하고, 요구 사항에 가장 적합한 모델을 선택해야 합니다.

코어 페어 서브스크립션 모델

  • 자체 관리형 OpenShift 코어 페어 서브스크립션의 수
    = 총 코어 수/2(반올림) 또는
    = 총 vCPU 수/4(반올림)

베어 메탈 소켓 페어 서브스크립션 모델

  • 먼저, 베어 메탈 설치 시 코어 페어 모델을 사용할 수 있으므로 애플리케이션에 필요한 코어 페어 서브스크립션 수를 계산합니다.
  • 그다음, 베어메탈 코어 페어 서브스크립션 수를 다음과 같은 방식으로 계산합니다.
    • 베어메탈 서버 수 = 
      다음 2가지 계산 결과 중 더 큰 값:
      • 필요한 총 코어 수/베어메탈 서버 모델당 코어 수(소수점 이하 반올림)
        또는
      • 필요한 총 메모리/베어메탈 서버 모델당 메모리 양(소수점 이하 반올림)
    • 베어메탈 서버당 필요한 베어 메탈 코어 페어 서브스크립션 수 =
      베어메탈 서버의 소켓이 1~2개인 경우:
    • 베어메탈 서버 모델당 코어 수/코어 128개 또는 vCPU 256개(소수점 이하 반올림)
      베어메탈 서버의 >소켓이 2개인 경우:
      • 베어메탈 서버 모델당 코어 수/(128 X 소켓 페어 수)(소수점 이하 반올림)
    • 소켓 페어당 최소 1개의 서브스크립션이 필요하며, 총 소켓 수와 총 코어 수를 충족하기 위해 서브스크립션을 스태킹할 수 있습니다.
    • 서브스크립션은 소켓에 적용될 수 있으나 추가 서버에는 적용될 수 없습니다.
  • 마지막으로, 2가지 모델의 비용 및 유연성의 차이를 비교합니다.
    • 비용:
      • 크기를 조정한 환경에서는 아마도 어느 한 가지 서브스크립션 모델이 다른 서브스크립션 모델보다 비용이 낮을 것입니다.
      • 그러나 향후 계획 시 용량 면에서 손익 분기점에 도달하는 순간을 예측할 수 있는데, 손익 분기점 이후에는 그 다른 모델이 비용적으로 더 나은 선택이 될 수 있습니다.
    • 아키텍처:
      • 코어 페어 서브스크립션은 환경 내 어디에서나(VM, 클라우드 인스턴스, 베어메탈 서버) 사용할 수 있는 반면, 베어 메탈 소켓 페어는 베어메탈 서버에서만 사용할 수 있습니다.
      • 베어메탈 서버의 코어 페어 서브스크립션은 해당 베어 메탈 서버에서 컨테이너를 실행해야 하고, 하나의 동일한 클러스터에 있어야 합니다.
      • 베어메탈 서버에 OpenShift Virtualization Engine을 설치한 다음 컨테이너에 대해 코어 페어 OpenShift 서브스크립션을 그 위에 설치할 수 있습니다(OpenShift-on-OpenShift). 이러한 경우는 서버당 OpenShift가 상대적으로 적은 혼합 VM 환경에 가장 적합합니다.
      • 베어메탈 서버에 OpenShift 워크로드가 고밀도로 필요한 경우 베어 메탈 소켓 페어 서브스크립션을 선택하면 베어 메탈에 직접 또는 OpenShift Virtualization 기능을 통해 서버에서 실행되는 VM 내에 OpenShift 컨테이너가 무제한으로 제공됩니다.

5단계: 총 AI Accelerator 서브스크립션 수 계산(해당하는 경우)

위의 AI Accelerator 서브스크립션 수를 모두 합산합니다. 온프레미스 또는 베어메탈 서버에서는 물리 가속기당 1개의 AI Accelerator 서브스크립션이 필요합니다. 하이퍼스케일러 클라우드 환경에서는 가속화된 컴퓨팅의 인스턴스 유형에 따라 해당 인스턴스 유형에 포함된 물리 GPU 또는 가속기의 개수가 나열됩니다. 이때 AI Accelerator 서브스크립션의 SLA가 해당 Red Hat OpenShift 서브스크립션과 일치해야 합니다.

참고: Red Hat OpenShift는 확장성, 포드 스케줄링, 유휴, 리소스 할당량/제한 기능에 영향을 미치는 여러 특징과 기능을 지원합니다. 위 계산은 지침으로 제시한 것이며, 실제 환경을 조정하여 리소스 사용을 개선하거나 총 환경 크기를 줄일 수 있습니다. OpenShift Platform Plus 고객은 추가 컴퓨팅 서브스크립션이 필요 없는 경우라도 스토리지 및 컴퓨팅 리소스를 포함한 추가 소프트웨어 애플리케이션(Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Quay)의 요구 사항을 고려해야 합니다.

타사 리셀러와 협업 관계인 경우에는 Red Hat 제품 및 서비스에 대한 구체적인 약관과 계약 사항을 확인하시기 바랍니다. 

예 1: 하이퍼스케일러 클라우드에서 실행 중인 컨테이너화된 애플리케이션

애플리케이션의 컨테이너 인스턴스가 200개이며, 컨테이너 인스턴스마다 평균 1개의 vCPU와 4GB RAM을 사용합니다. 선호하는 최대 활용도는 80%입니다. AWS에서 애플리케이션을 실행 중이며, EC2 M6i 인스턴스 유형에 대한 액세스 권한이 있습니다. 애플리케이션에는 특정 하드웨어나 AI 가속기가 필요하지 않습니다. Red Hat OpenShift Platform Plus를 자체 관리형 버전으로 선택했으며, 현재는 필요한 서브스크립션 수의 추정치만 있으면 됩니다.

1단계: 필요한 애플리케이션 인스턴스의 개수 및 유형 파악

살펴본 예에서 수집한 정보는 다음과 같습니다.

  • 애플리케이션 인스턴스의 수 = 200
  • 선호하는 최대 노드 활용도 = 80%
  • 평균 애플리케이션 vCPU 요구 사항 = vCPU 1개
  • 평균 애플리케이션 메모리 풋프린트 = 4GB

2단계: 필요한 총 메모리 및 총 코어 수 결정

1단계에서 확인한 수치를 사용한 계산 결과는 다음과 같습니다.

  • 최대 활용도 = 80%
  • 필요한 총 vCPU 수 = 1 vCPU X 200 X 1/80% = vCPU 250개
  • 필요한 총 메모리 = 4 GB X 200 X 1/80% = 1000GB

3단계: 표준 컴퓨팅 노드 선택

제공된 정보에 따르면 GPU 또는 전문 하드웨어가 포함된 인스턴스 유형은 필요하지 않습니다. vCPU와 메모리의 비율은 vCPU 250개:1000GB, 즉 1:4입니다. 다행히 이러한 비율의 인스턴스 유형은 많습니다. 애플리케이션에 필요한 기타 요소들을 분석한 결과, m6i.4xlarge 인스턴스 유형이 요구 사항에 가장 적합하다는 결론에 이르렀습니다. 각 인스턴스의 vCPU는 16개이고 메모리는 64GB입니다.

4단계: 필요한 총 서브스크립션 수 계산

이 경우 하이퍼스케일러 클라우드에서 실행 중이므로 코어 페어 서브스크립션이 필요하며, 하이퍼스케일러 클라우드가 vCPU를 사용 중이므로 2단계의 코어 페어 서브스크립션 공식을 사용합니다.

총 코어 페어 서브스크립션 수 = 필요한 총 vCPU/4(반올림)

vCPU 250개/4 = 62.5 또는 반올림하여 63

5단계: 총 AI Accelerator 서브스크립션 수 계산(해당하는 경우)

AI Accelerator를 사용하고 있지 않으므로 이 사이징 예에서는 해당되는 사항이 없습니다.

결과

이 예 1의 경우 63개의 OpenShift Platform Plus 코어 페어 서브스크립션이 필요합니다.

예 2: 베어 메탈로 온프레미스에서 실행 중인 컨테이너화된 애플리케이션

지금부터는 Red Hat OpenShift에 포함된 OpenShift Virtualization 기능을 사용하여 VM 컴퓨팅 노드에 프로비저닝된 동일한 애플리케이션을 온프레미스와 베어메탈에서 실행해 보겠습니다. 애플리케이션의 컨테이너 인스턴스가 200개이며, 컨테이너 인스턴스마다 1개의 vCPU와 4GB RAM을 사용합니다. 선호하는 최대 활용도는 80%입니다. 애플리케이션에는 특정 하드웨어나 AI 가속기가 필요하지 않습니다. Red Hat OpenShift Platform Plus를 자체 관리형 버전으로 선택했으며, 지금은 필요한 서브스크립션 수의 추정치만 있으면 됩니다. 베어메탈 구성을 어느 정도 유연하게 선택할 수 있으나 지금은 일반 기성품 서버 구성을 사용하고 있습니다.

1단계: 필요한 애플리케이션 인스턴스의 개수 및 유형 파악

살펴본 예에서 수집한 정보는 다음과 같습니다.

  • 애플리케이션 인스턴스의 수 = 200
  • 선호하는 최대 노드 활용도 = 80%
  • 평균 애플리케이션 vCPU 요구 사항 = vCPU 1개
  • 평균 애플리케이션 메모리 풋프린트 = 4GB

2단계: 필요한 총 메모리 및 총 코어 수 결정

1단계에서 확인한 수치를 사용한 계산 결과는 다음과 같습니다.

  • 최대 활용도 = 80%
  • 필요한 총 vCPU 수 = 1 vCPU X 200 X 1/80% = vCPU 250개
  • 필요한 총 메모리 = 4 GB X 200 X 1/80% = 1000GB

3단계: 표준 컴퓨팅 노드 선택

현재 베어메탈 서버 표준은 코어 32개/소켓당 vCPU 64개인 2소켓 서버입니다. RAM은 선택할 수 있습니다. vCPU와 RAM의 비율이 1:4이므로 서버의 RAM 용량은 256GB로 하겠습니다. 이렇게 코어 32개/소켓당 vCPU 64개의 2소켓 서버와 256GB RAM의 베어메탈 서버를 선택했습니다.

4단계: 필요한 총 서브스크립션 수 계산

베어메탈 서버에서는 코어 페어 서브스크립션과 베어 메탈 소켓 페어 서브스크립션 중 선택할 수 있습니다. 그럼 두 가지를 모두 계산해보겠습니다.

총 코어 페어 서브스크립션 수 = 필요한 총 vCPU/4(반올림)

vCPU 250개/4 = 62.5 또는 반올림하여 63

총 소켓 페어 서브스크립션 수 =

  • 필요한 총 서버 수 = vCPU 250개/서버당 vCPU 128개(반올림 = 서버 2개)
  • 서버당 필요한 총 서브스크립션 수 = 소켓 페어당 코어 수/128(반올림 = 64/128 = 0.5  서브스크립션 1개로 반올림)
  • 서버 2개 x 서브스크립션 1개/서버 = 베어 메탈 소켓 페어 서브스크립션 2개

이 경우 vCPU와 메모리의 정확한 비율을 얻기 위해 서버를 선택할 수 있었기 때문에 메모리 요구 사항을 충족하기 위해 필요한 서버 수를 계산하여 2가지 결과 중 더 큰 값을 취할 필요가 없습니다. 만약 RAM 용량이 다른 서버를 선택한다면 달라진 수치를 고려해야 할 것입니다.

5단계: 총 AI Accelerator 서브스크립션 수 계산(해당하는 경우)

AI Accelerator를 사용하고 있지 않으므로 이 사이징 예에서는 해당되는 사항이 없습니다.

결과

이 예에서는 63개의 OpenShift Platform Plus 코어 페어 서브스크립션 또는 2개의 베어 메탈 소켓 페어 서브스크립션 이 필요합니다. 여기서의 결정이 최종적으로 가장 적합한 비용 및 아키텍처 결정이 될 것입니다. 

예 3: VM 전용 환경

가상 머신을 다른 하이퍼바이저에서 Red Hat으로 이동하겠습니다. 지금은 혼합 환경이지만 규모가 다양하고 개수가 다음과 같은 가상 머신들이 확인됐습니다.

  • 소규모 1000개 = vCPU 1000개, 4000GiB. 228GiB 메모리 오버헤드
  • 중간 규모 300개 = vCPU 600개, 2400GiB. 73GiB 메모리 오버헤드
  • 대규모 200개 = vCPU 800개, 4800GiB. 58GiB 메모리 오버헤드
  • 특대규모 200개 = vCPU 1600개, 9600GiB. 64GiB 메모리 오버헤드

1단계: 필요한 애플리케이션 인스턴스의 개수 및 유형 파악

살펴본 예에서 수집한 정보는 다음과 같습니다.

  • 애플리케이션 인스턴스의 수 = 1700
  • 총 vCPU 수 = vCPU 4000개
  • 총 메모리 = 20800GB + 423GB 오버헤드 = 21223GB
  • 평균 애플리케이션 vCPU 요구 사항 = vCPU 2.4개
  • 평균 애플리케이션 메모리 풋프린트 = 12.5GB

2단계: 필요한 총 메모리 및 총 코어 수 결정

1단계에서 확인한 수치를 사용한 계산 결과는 다음과 같습니다.

  • 필요한 총 메모리 = 20800GB + 423GB 오버헤드 = 21223GB
  • 필요한 총 vCPU 수 = vCPU 4000개

VM의 최대 활용도 메트릭은 컨테이너 연습 문제와는 약간 다르지만 가상화 관리자에게는 익숙할 것입니다.

일반적으로 VM에는 메모리 과다 할당을 추천하지 않습니다. 따라서 총 메모리 요구 사항이 일반적으로 컴퓨팅 노드 수를 결정하는 주요 인자가 됩니다.

컴퓨팅 리소스의 경우, 평균적으로 대부분의 VM이 컴퓨팅 리소스를 전부 소비하지 않으므로 CPU 과다 할당을 예상합니다. OpenShift Virtualization의 최대 CPU 과다 할당 비율은 10:1로 설정되어 있습니다. 따라서 4:1과 같은 비율은 낮게 잡아 선택한 것입니다. 이제 vCPU 1개에 해당하는 코어나 스레드 중 무엇을 사용할지(하이퍼스레딩 지원을 통해 각 코어는 스레드 2개가 될 수 있음) 선택할 수 있습니다. 낮게 잡아 vCPU 1개 = 코어 1개로 선택하고 하이퍼스레딩은 선택하지 않겠습니다. 이제 필요한 요건은 다음과 같습니다.

  • 필요한 총 메모리 = 20800GB + 423GB 오버헤드 = 21223GB
  • 필요한 총 코어 수 = vCPU 4000개 x 1/4 x 코어 1개/vCPU = 코어 1000개

3단계: 표준 컴퓨팅 노드 선택

가상화용 베어메탈 컴퓨팅 노드를 선택하려면 이중화 및 장애 영역, 클러스터 규모 등 여러 가지를 고려해야 합니다. 온프레미스에서는 서버당 RAM 증가 등 몇 가지 선택 사항이 있습니다. 일반적으로 메모리에 따라 서버 요구 사항이 달라지므로 거기서부터 시작해보겠습니다.

VM은 1,700개이고 소켓당 코어가 32개인 2소켓 서버를 선택하겠습니다. 서버 개수에 맞는 수의 코어를 사용하려면 필요한 사항은 다음과 같습니다.

  • 코어 1000개/서버당 코어 64개, 반올림하여 서버 16개

서버가 16개이므로 21223GB/서버 16개 = 서버당 1326GB RAM이 필요합니다. 사용 중인 서버에는 1536GB의 RAM을 선택할 수 있습니다. 베어메탈 구성은 다음과 같습니다.

  • 코어 32개/소켓인 2소켓 버서(총 코어 64개), 1536GB RAM

마지막으로, 구성이 이러할 때 서버 16개의 총 코어와 메모리는 다음과 같습니다.

  • 16 x 코어 64개 = 코어 1,024개
  • 16 x 1536GB = 24576GB 메모리

이 정도면 VM 로드를 실행하기에 충분하지만 이중화를 위해 추가 서버가 필요합니다. 지금은 운영 중단이나 심각한 성능 영향으로 인해 어떠한 서버에도 절대로 손실이 일어나서는 안 되는 상황입니다. 가상화 관리자는 페일오버와 이중화를 위해 25%의 예비 용량을 확보할 것을 권장합니다. 따라서 요구 사항은 다음과 같습니다.

  • 서버 16개 + (서버 16개 * 25%) = 서버 총 20개

20개 서버 모두에 VM을 배포해서 1~4개의 서버가 손실되더라도 VM 요구 사항을 계속 충족할 수 있도록 하겠습니다. (복구 요구 사항은 다를 수 있습니다.)

4단계: 필요한 총 서브스크립션 수 계산

가상화 전용 활용 사례의 경우 베어 메탈 소켓 페어 서브스크립션에만 제공되는 OpenShift Virtualization Engine을 사용 중입니다.

총 소켓 페어 서브스크립션 수 =

  • 필요한 총 서버 수 = 20
  • 서버당 필요한 총 서브스크립션 수 = 1(서버 개수는 코어 64개/소켓 페어일 때 최대이기 때문)
  • 서버 20개 x 서브스크립션 1개/서버 = 베어 메탈 소켓 페어 서브스크립션 20개

5단계: 총 AI Accelerator 서브스크립션 수 계산(해당하는 경우)

AI Accelerator를 사용하고 있지 않으므로 이 사이징 예에서는 해당되는 사항이 없습니다.

결과

이 예에서는 20개의 OpenShift Virtualization Engine 베어 메탈 소켓 페어 서브스크립션 이 필요합니다. 

부록 1: 자체 관리형 OpenShift 버전과 포함 사항

표 1: Red Hat OpenShift 버전별 전반적인 특징 차이

특징

Red Hat OpenShift Kubernetes Engine

Red Hat OpenShift Container Platform

Red Hat OpenShift Platform Plus

Red Hat OpenShift Virtualization Engine

관리자 웹 콘솔

예

예

예

예

인증 통합, 역할 기반 액세스 제어(RBAC), 보안 컨텍스트 제한 조건(SCC), 멀티 테넌시 권한 컨트롤러

예

예

예

예

자동 스케일링(클러스터 및 포드)

예

예

예

예

클러스터 모니터링

예

예

예

예

비용 관리 SaaS 서비스

예

예

예

예

Open Container Initiative(OCI) 호환 런타임 또는 CRI-O 런타임을 위한 쿠버네티스 컨테이너 런타임 인터페이스(CRI)

예

예

예

예

엔터프라이즈 보안 쿠버네티스

예

예

예

예

완전 자동화된 설치 프로그램

예

예

예

예

Kubectl 및 oc 자동화된 커맨드라인

예

예

예

예

OpenShift Virtualization

예

예

예

예

오퍼레이터 라이프사이클 관리자(OLM)

예

예

예

예

무선(OTA) 스마트 업그레이드

예

예

예

예

암호 관리

예

예

예

예

스토리지 드라이버

예

예

예

예

사용자 제공 가상 머신 워크로드

예

예

예

예

Red Hat OpenShift GitOps

VM 활용 사례 전용

예

예

VM 활용 사례 전용

플랫폼 로깅

VM 활용 사례 전용

예

예

VM 활용 사례 전용

사용자 워크로드 모니터링

VM 활용 사례 전용

예

예

VM 활용 사례 전용

Red Hat Enterprise Linux 지원과 작업자 및 인프라 노드에 대한 권한

예

예

예

 

Red Hat Enterprise Linux VM 게스트 운영 체제 및 컨테이너 빌드에 대한 권한

예

예

예

 

사용자 제공 컨테이너 워크로드

예

예

예

 

Red Hat OpenShift에 대한 빌드

 

예

예

 

개발자 애플리케이션 카탈로그

 

예

예

 

개발자 웹 콘솔

 

예

예

 

IBM Cloud Pak 및 Red Hat Application Services 번들의 구성 요소 포함

 

예

예

 

통합 개발 환경(IDE)

 

예

예

 

분산 추적

 

예

예

 

odo

 

예

예

 

Red Hat OpenShift Pipelines

 

예

예

 

Red Hat OpenShift 샌드박스 처리된 컨테이너

 

예

예

 

Red Hat OpenShift Serverless

 

예

예

 

Red Hat OpenShift Service Mesh

 

예

예

 

Red Hat Advanced Cluster Management for Kubernetes

  

예

 

Red Hat Advanced Cluster Security for Kubernetes

  

예

 

Red Hat OpenShift Data Foundation Essentials

  

예

 

Red Hat Quay

  

예

 

표 2: Red Hat OpenShift 버전 간 상세 차이점(해당 특징을 제공하는 오퍼레이터 포함)

특징

Red Hat OpenShift Kubernetes Engine

Red Hat OpenShift Container Platform

Red Hat OpenShift Platform Plus

Red Hat OpenShift Virtualization Engine

오퍼레이터 이름

AWS EFS CSI 드라이버 오퍼레이터

예

예

예

예

aws-efs-csi-driver-operator

AWS 로드 밸런서 오퍼레이터

예

예

예

예

aws-load-balancer-operator

Red Hat OpenShift에 대한 cert-manager 오퍼레이터

예

예

예

예

openshift-cert-manager-operator

클러스터 모니터링

예

예

예

예

클러스터 모니터링

클러스터 관측성 오퍼레이터

예

예

예

예

cluster-observability-operator

ClusterResourceOverride 오퍼레이터

예

예

예

예

clusterresourceoverride

CNI 플러그인 ISV 호환성

예

예

예

예

해당 없음

컴플라이언스 오퍼레이터

예

예

예

예

컴플라이언스 오퍼레이터

기밀 컴퓨팅 증명

예

예

예

예

trustee-operator

CSI 플러그인 ISV 호환성

예

예

예

예

해당 없음

커스텀 메트릭스 오토스케일러

예

예

예

예

openshift-custom-metrics-autoscaler-operator

장치 관리자(예: GPU)

예

예

예

예

해당 없음

DPU 네트워크 오퍼레이터

예

예

예

예

dpu-network-operator

이그레스 포드 및 네임스페이스 세부 제어

예

예

예

예

해당 없음

마켓플레이스 포함

예

예

예

예

해당 없음

OperatorHub 포함

예

예

예

예

해당 없음

레지스트리 포함

예

예

예

예

해당 없음

외부 DNS 오퍼레이터

예

예

예

예

external-dns-operator

펜스 에이전트 문제 해결

예

예

예

예

fence-agents-remediation

파일 무결성 오퍼레이터

예

예

예

예

파일 무결성 오퍼레이터

GCP FileStore CSI 드라이버 오퍼레이터

예

예

예

예

gcp-filestore-csi-driver-operator

HAProxy 인그레스 컨트롤러

예

예

예

예

해당 없음

Helm

예

예

예

예

해당 없음

인그레스 클러스터 전체 방화벽

예

예

예

예

해당 없음

인그레스 비표준 포트

예

예

예

예

해당 없음

IPv6 단일 및 이중 스택

예

예

예

예

해당 없음

Red Hat이 제공하는 Kube 디스케줄러 오퍼레이터

예

예

예

예

Kube 디스케줄러 오퍼레이터

쿠버네티스 NMState 오퍼레이터

예

예

예

예

kubernetes-nmstate-operator

로컬 스토리지 오퍼레이터

예

예

예

예

로컬 스토리지 오퍼레이터

로그 전달

예

예

예

예

Red Hat OpenShift Logging 오퍼레이터

Loki 오퍼레이터

예

예

예

예

loki-operator

논리 볼륨 관리자 스토리지

예

예

예

예

lvms-operator

머신 삭제 문제 해결

예

예

예

예

machine-deletion-remediation

MetalLB 오퍼레이터

예

예

예

예

metallb-operator

가상화를 위한 마이그레이션 툴킷

예

예

예

예

mtv-operator

다중 아키텍처 튜닝

예

예

예

예

multiarch-tuning-operator

Multus 및 사용 가능한 Multus 플러그인

예

예

예

예

해당 없음

네트워크 바운드 디스크 암호화(nbde) tang 서버

예

예

예

예

nbde-tang-server

네트워크 정책

예

예

예

예

해당 없음

Red Hat이 제공하는 Node Feature Discovery

예

예

예

예

nfd

노드 상태 점검

예

예

예

예

node-healthcheck-operator

노드 유지 관리

예

예

예

예

node-maintenance-operator

NUMA Resources 오퍼레이터

예

예

예

예

numaresources-operator

OpenShift API for Data Protection(OADP)

예

예

예

예

OADP 오퍼레이터

OpenShift 클라우드 관리자 SaaS 서비스

예

예

예

예

해당 없음

OpenShift 업데이트 서비스

예

예

예

예

cincinnati-operator

OpenShift Virtualization

예

예

예

예

OpenShift Virtualization 오퍼레이터

OVS 및 OVN SDN

예

예

예

예

해당 없음

Red Hat OpenShift의 전력 모니터링

예

예

예

예

power-monitoring-operator

Red Hat이 제공하는 PTP 오퍼레이터

예

예

예

예

PTP 오퍼레이터

Red Hat Quay 호환성

예

예

예

예

해당 없음

Red Hat Enterprise Linux Software Collections 및 RHT SSO 일반 서비스

예

예

예

예

해당 없음

Run Once Duration Override 오퍼레이터

예

예

예

예

run-once-duration-override-operator

Red Hat OpenShift의 보조 스케줄러 오퍼레이터

예

예

예

예

openshift-secondary-scheduler-operator

암호 저장 CSI

예

예

예

예

암호 저장 CSI 오퍼레이터

보안 프로필

예

예

예

예

보안 프로필 오퍼레이터

서비스 바인딩 오퍼레이터

예

예

예

예

rh-service-binding-operator

SR-IOV 네트워크 오퍼레이터

예

예

예

예

SR-IOV 네트워크 오퍼레이터

텔레미터 및 인사이트 연결 경험

예

예

예

예

해당 없음

수직 포드 오토스케일러

예

예

예

예

수직 포드 오토스케일러

웹 터미널

예

예

예

예

web-terminal

비용 관리

예

예

예

 

costmanagement-metrics-operator

플랫폼 로깅

VM 활용 사례 전용

예

예

VM 활용 사례 전용

Red Hat OpenShift Logging 오퍼레이터

사용자 워크로드 모니터링

VM 활용 사례 전용

예

예

VM 활용 사례 전용

cluster-monitoring-operator

Red Hat OpenShift에 대한 빌드

 

예

예

 

openshift-builds-operator

개발자 애플리케이션 카탈로그

 

예

예

 

해당 없음

개발자 웹 콘솔

 

예

예

 

해당 없음

Kourier 인그레스 컨트롤러

 

예

예

 

OpenShift Serverless

애플리케이션을 위한 마이그레이션 툴킷

 

예

예

 

mta-operator

컨테이너를 위한 마이그레이션 툴킷

 

예

예

 

mtc-operator

런타임용 마이그레이션 툴킷

 

예

예

 

mtr-operator

네트워크 관측성 오퍼레이터

 

예

예

 

netobserv-operator

ODF 멀티클러스터 오케스트레이터

  

예

 

odf-multicluster-orchestrator

Red Hat OpenShift Dev Spaces

 

예

예

 

devspaces

OpenTelemetry의 Red Hat 빌드

 

예

예

 

klusterlet-product

분산 추적

 

예

예

 

tempo-operator

OpenShift DR 클러스터 오퍼레이터

  

예

 

odr-cluster-operator

OpenShift DR Hub 오퍼레이터

  

예

 

odr-hub-operator

OpenShift Elasticsearch 오퍼레이터(참고 1)

 

예

예

 

elasticsearch-operator

Red Hat OpenShift GitOps

VM 활용 사례 전용

예

예

VM 활용 사례 전용

openshift-gitops-operator

Kiali

 

예

예

 

Kiali 오퍼레이터

Red Hat OpenShift Local

 

예

예

 

해당 없음

Red Hat OpenShift에 대한 로깅

 

예

예

 

cluster-logging

Red Hat OpenShift Pipelines

 

예

예

 

openshift-pipelines-operator-rh

Red Hat OpenShift 샌드박스 처리된 컨테이너

 

예

예

 

sandboxed-containers-operator

Red Hat OpenShift Serverless

 

예

예

 

serverless-operator

Red Hat OpenShift Service Mesh

 

예

예

 

servicemeshoperator

Red Hat이 제공하는 Quay Bridge 오퍼레이터

 

예

예

 

Quay Bridge 오퍼레이터

Red Hat이 제공하는 Quay 컨테이너 보안

 

예

예

 

컨테이너 보안 오퍼레이터

Keycloak의 Red Hat 빌드

 

예

예

 

keycloak-operator

Red Hat build of Quarkus

 

예

예

 

해당 없음

single sign-on

 

예

예

 

rhsso-operator

이미지 및 빌더 자동화 소스

 

예

예

 

OpenShift Pipelines

토폴로지 인식 라이프사이클 관리자

 

예

예

 

topology-aware-lifecycle-manager

VolSync

 

예

예

 

volsync-product

Red Hat이 제공하는 웹 터미널

 

예

예

 

웹 터미널

Windows 머신 구성 오퍼레이터

 

예

예

 

Windows 머신 구성 오퍼레이터

참고 1: Red Hat OpenShift에 포함된 OpenShift Elasticsearch 오퍼레이터는 OpenShift 클러스터의 내부 인프라 검색 요구 사항을 지원하기 위한 용도로만 라이센스가 부여되며 고객 애플리케이션에 독립형으로 사용될 수 없습니다.

모든 Red Hat OpenShift 버전에 포함되지 않는 일반 Red Hat 소프트웨어

별도로 명시되지 않는 한, OpenShift와 함께 일반적으로 사용되는 다음 Red Hat 소프트웨어 오퍼링은 별도로 권한을 부여받아야 합니다. Red Hat OpenShift Platform Plus에는 Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay, Red Hat OpenShift Data Foundation Essentials가 포함되어 있습니다. 다른 자체 관리형 OpenShift 서브스크립션에는 이러한 추가 제품이 포함되어 있지 않으나 별도 구입이 가능합니다. Red Hat OpenShift와 함께 사용되지만 이 서브스크립션 가이드에는 포함되지 않은 기타 Red Hat 소프트웨어는 다음과 같습니다.

  • Red Hat Ansible Automation Platform
  • Red Hat Application Foundations
  • Red Hat Enterprise Linux AI
  • 3scale, AMQ, Camel K, Fuse 등이 포함된 Red Hat Integration 포트폴리오
  • Red Hat JBoss EAP
  • Red Hat Middleware 번들
  • Red Hat OpenShift Developer Hub(Backstage 프로젝트의 Red Hat 빌드)
  • Red Hat OpenShift AI
  • Red Hat Satellite(Red Hat Enterprise Linux의 관리용)
  • IBM CloudPaks

위 오퍼링에 대한 자세한 정보는 Red Hat 판매자 또는 파트너에게 문의하세요.

태그:클라우드 서비스