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

4장. 설치

4.1. OpenShift Virtualization을 위한 클러스터 준비

OpenShift Virtualization을 설치하기 전에 이 섹션을 검토하여 클러스터가 요구 사항을 충족하는지 확인합니다.

중요
설치 방법 고려 사항
사용자 프로비저닝, 설치 관리자 프로비저닝 또는 지원 설치 프로그램을 포함하여 모든 설치 방법을 사용하여 OpenShift Container Platform을 배포할 수 있습니다. 그러나 설치 방법과 클러스터 토폴로지는 스냅샷 또는 실시간 마이그레이션 과 같은 OpenShift Virtualization 기능에 영향을 미칠 수 있습니다.
Red Hat OpenShift Data Foundation
Red Hat OpenShift Data Foundation을 사용하여 OpenShift Virtualization을 배포하는 경우 Windows 가상 머신 디스크용 전용 스토리지 클래스를 생성해야 합니다. 자세한 내용은 Windows VM용 ODF PersistentVolume 최적화 를 참조하십시오.
IPv6
단일 스택 IPv6 클러스터에서 OpenShift Virtualization을 실행할 수 없습니다.

FIPS 모드

FIPS 모드에서 클러스터를 설치하는 경우 OpenShift Virtualization에 추가 설정이 필요하지 않습니다.

4.1.1. 지원되는 플랫폼

OpenShift Virtualization에서 다음 플랫폼을 사용할 수 있습니다.

다른 클라우드 공급자가 제공하는 베어 메탈 인스턴스 또는 서버는 지원되지 않습니다.

4.1.1.1. AWS 베어 메탈의 OpenShift Virtualization

AWS(Amazon Web Services) 베어 메탈 OpenShift Container Platform 클러스터에서 OpenShift Virtualization을 실행할 수 있습니다.

참고

OpenShift Virtualization은 AWS 베어 메탈 클러스터와 동일한 구성 요구 사항이 있는 AWS(ROSA) 클래식 클러스터에서도 지원됩니다.

클러스터를 설정하기 전에 지원되는 기능 및 제한 사항에 대한 다음 요약을 검토하십시오.

설치

  • install-config.yaml 파일을 편집하여 작업자 노드의 베어 메탈 인스턴스 유형을 지정하도록 설치 관리자 프로비저닝 인프라를 사용하여 클러스터를 설치할 수 있습니다. 예를 들어 x86_64 아키텍처를 기반으로 하는 머신에 c5n.metal 유형 값을 사용할 수 있습니다.

    자세한 내용은 AWS에 설치하는 방법에 대한 OpenShift Container Platform 설명서를 참조하십시오.

VM(가상 머신) 액세스
  • virtctl CLI 도구 또는 OpenShift Container Platform 웹 콘솔을 사용하여 VM에 액세스하는 방법은 변경되지 않습니다.

  • NodePort 또는 LoadBalancer 서비스를 사용하여 VM을 노출할 수 있습니다.

    • OpenShift Container Platform이 AWS에서 로드 밸런서를 자동으로 생성하고 라이프사이클을 관리하므로 로드 밸런서 접근 방식을 사용하는 것이 좋습니다. 로드 밸런서에 대한 보안 그룹도 생성되며, 주석을 사용하여 기존 보안 그룹을 연결할 수 있습니다. 서비스를 제거하면 OpenShift Container Platform에서 로드 밸런서 및 관련 리소스를 제거합니다.
네트워킹
  • VLAN(Virtual LAN)을 포함하여 SR-IOV(Single Root I/O Virtualization) 또는 브리지 CNI(Container Network Interface) 네트워크를 사용할 수 없습니다. 애플리케이션에 플랫 계층 2 네트워크 또는 IP 풀을 제어해야 하는 경우 OVN-Kubernetes 보조 오버레이 네트워크를 사용하는 것이 좋습니다.
스토리지

  • 스토리지 벤더가 인증된 모든 스토리지 솔루션을 사용하여 기본 플랫폼으로 작업할 수 있습니다.

    중요

    AWS 베어 메탈 및 ROSA 클러스터에는 다른 지원되는 스토리지 솔루션이 있을 수 있습니다. 스토리지 벤더에 대한 지원을 확인하십시오.

  • OpenShift Virtualization과 함께 EBS(Amazon Elastic File System) 또는 Amazon Elastic Block Store(EBS)를 사용하면 성능 및 기능 제한이 발생할 수 있습니다. 실시간 마이그레이션, 빠른 VM 생성 및 VM 스냅샷 기능을 활성화하려면 RWX(ReadWriteMany), 복제 및 스냅샷을 지원하는 CSI 스토리지를 사용하는 것이 좋습니다.
호스트된 컨트롤 플레인(HCP)
  • OpenShift Virtualization의 HCP는 현재 AWS 인프라에서 지원되지 않습니다.

추가 리소스

4.1.2. 하드웨어 및 운영 체제 요구사항

OpenShift Virtualization에 대한 다음 하드웨어 및 운영 체제 요구 사항을 검토하십시오.

4.1.2.1. CPU 요구 사항

  • RHEL(Red Hat Enterprise Linux) 9에서 지원합니다.

    지원되는 CPU는 Red Hat Ecosystem Catalog 에서 참조하십시오.

    참고

    작업자 노드에 CPU가 다른 경우 CPU마다 기능이 다르기 때문에 실시간 마이그레이션 오류가 발생할 수 있습니다. 작업자 노드에 적절한 용량이 있고 가상 머신에 대한 노드 유사성 규칙을 구성하여 이 문제를 완화할 수 있습니다.

    자세한 내용은 필수 노드 유사성 규칙 구성 을 참조하십시오.

  • AMD 및 Intel 64비트 아키텍처(x86-64-v2) 지원
  • Intel 64 또는 AMD64 CPU 확장 지원
  • Intel VT 또는 AMD-V 하드웨어 가상화 확장 기능이 활성화되어 있습니다.
  • NX(실행 없음) 플래그가 활성화되어 있습니다.

4.1.2.2. 운영 체제 요구 사항

  • 작업자 노드에 RHCOS(Red Hat Enterprise Linux CoreOS)가 설치되어 있습니다.

    자세한 내용은 RHCOS 정보를 참조하십시오.

    참고

    RHEL 작업자 노드는 지원되지 않습니다.

4.1.2.3. 스토리지 요구사항

  • OpenShift Container Platform에서 지원합니다. 스토리지 최적화를 참조하십시오.
  • 기본 OpenShift Virtualization 또는 OpenShift Container Platform 스토리지 클래스를 생성해야 합니다. 이 문제의 목적은 VM 워크로드의 고유한 스토리지 요구 사항을 해결하고 최적화된 성능, 안정성 및 사용자 환경을 제공하는 것입니다. OpenShift Virtualization 및 OpenShift Container Platform 기본 스토리지 클래스가 둘 다 있는 경우 VM 디스크를 생성할 때 OpenShift Virtualization 클래스가 우선합니다.
참고

스토리지 클래스를 가상화 워크로드의 기본값으로 표시하려면 storageclass.kubevirt.io/is-default-virt-class 를 "true" 로 설정합니다.

  • 스토리지 프로비저너가 스냅샷을 지원하는 경우 VolumeSnapshotClass 오브젝트를 기본 스토리지 클래스와 연결해야 합니다.
4.1.2.3.1. 가상 머신 디스크의 볼륨 및 액세스 모드 정보

알려진 스토리지 공급자와 스토리지 API를 사용하는 경우 볼륨 및 액세스 모드가 자동으로 선택됩니다. 그러나 스토리지 프로필이 없는 스토리지 클래스를 사용하는 경우 볼륨 및 액세스 모드를 구성해야 합니다.

최상의 결과를 얻으려면 RWX( ReadWriteMany ) 액세스 모드와 Block 볼륨 모드를 사용합니다. 이는 다음과 같은 이유로 중요합니다.

  • 실시간 마이그레이션에는 RWX( ReadWriteMany ) 액세스 모드가 필요합니다.

  • 블록 볼륨 모드는 Filesystem 볼륨 모드보다 훨씬 더 잘 작동합니다. 이는 Filesystem 볼륨 모드가 파일 시스템 계층 및 디스크 이미지 파일을 포함하여 더 많은 스토리지 계층을 사용하기 때문입니다. 이러한 계층은 VM 디스크 스토리지에 필요하지 않습니다.

    예를 들어 Red Hat OpenShift Data Foundation을 사용하는 경우 CephFS 볼륨에 Ceph RBD 볼륨을 사용하는 것이 좋습니다.

중요

다음 구성으로 가상 머신을 실시간 마이그레이션할 수 없습니다.

  • RWO( ReadWriteOnce ) 액세스 모드가 있는 스토리지 볼륨
  • GPU와 같은 패스스루 기능

이러한 가상 머신에 대해 evictionStrategy 필드를 None 으로 설정합니다. None 전략은 노드를 재부팅하는 동안 VM의 전원을 끕니다.

4.1.3. 실시간 마이그레이션 요구 사항

  • RWX( ReadWriteMany ) 액세스 모드를 사용한 공유 스토리지.

  • 충분한 RAM 및 네트워크 대역폭.

    참고

    노드 드레이닝을 지원하기 위해 클러스터에 메모리 요청 용량이 충분한지 확인하여 실시간 마이그레이션을 수행해야 합니다. 다음 계산을 사용하여 필요한 예비 메모리를 확인할 수 있습니다. 

    Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)

    클러스터에서 병렬로 실행할 수 있는 기본 마이그레이션 수는 5입니다.

  • 가상 머신에서 호스트 모델 CPU를 사용하는 경우 노드는 가상 시스템의 호스트 모델 CPU를 지원해야 합니다.
  • 실시간 마이그레이션을 위한 전용 Multus 네트워크를 사용하는 것이 좋습니다. 전용 네트워크는 마이그레이션 중에 테넌트 워크로드에 대한 네트워크 포화 상태로 인한 영향을 최소화합니다.

4.1.4. 물리적 리소스 오버헤드 요구사항

OpenShift Virtualization은 OpenShift Container Platform의 추가 기능이며 클러스터를 계획할 때 고려해야 하는 추가 오버헤드를 적용합니다. 각 클러스터 머신은 OpenShift Container Platform 요구 사항 이외에도 다음과 같은 오버헤드 요구 사항을 충족해야 합니다. 클러스터에서 물리적 리소스를 초과 구독하면 성능에 영향을 미칠 수 있습니다.

중요

이 문서에 명시된 수치는 Red Hat의 테스트 방법론 및 설정을 기반으로 한 것입니다. 고유한 개별 설정 및 환경에 따라 수치가 달라질 수 있습니다.

메모리 오버헤드

아래 식을 사용하여 OpenShift Virtualization의 메모리 오버헤드 값을 계산합니다.

클러스터 메모리 오버헤드

Memory overhead per infrastructure node ≈ 150 MiB

Memory overhead per worker node ≈ 360 MiB

또한, OpenShift Virtualization 환경 리소스에는 모든 인프라 노드에 분산된 총 2179MiB의 RAM이 필요합니다.

가상 머신 메모리 오버헤드

Memory overhead per virtual machine ≈ (1.002 × requested memory) \
              + 218 MiB \ 1
              + 8 MiB × (number of vCPUs) \ 2
              + 16 MiB × (number of graphics devices) \ 3
              + (additional memory overhead) 4

1
virt-launcher Pod에서 실행되는 프로세스에 필요합니다.
2
가상 머신에서 요청한 가상 CPU 수입니다.
3
가상 머신에서 요청한 가상 그래픽 카드 수입니다.
4
추가 메모리 오버헤드:
  • 환경에 SR-IOV(Single Root I/O Virtualization) 네트워크 장치 또는 GPU(Graphics Processing Unit)가 포함된 경우 각 장치에 대해 1GiB의 추가 메모리 오버헤드를 할당합니다.
  • SEV(Secure Encrypted Virtualization)가 활성화된 경우 256MiB를 추가합니다.
  • 신뢰할 수 있는 플랫폼 모듈(TPM)이 활성화된 경우 53MiB를 추가합니다.
CPU 오버헤드

아래 식을 사용하여 OpenShift Virtualization에 대한 클러스터 프로세서 오버헤드 요구 사항을 계산합니다. 가상 머신당 CPU 오버헤드는 개별 설정에 따라 다릅니다.

클러스터 CPU 오버헤드

CPU overhead for infrastructure nodes ≈ 4 cores

OpenShift Virtualization은 로깅, 라우팅 및 모니터링과 같은 클러스터 수준 서비스의 전반적인 사용률을 높입니다. 이 워크로드를 처리하려면 인프라 구성 요소를 호스팅하는 노드에 4 개의 추가 코어 (4000밀리코어)가 해당 노드에 분산되어 있는지 확인합니다. 

CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine

가상 머신을 호스팅하는 각 작업자 노드는 가상 머신 워크로드에 필요한 CPU 외에도 OpenShift Virtualization 관리 워크로드에 대한 2개의 추가 코어(2000밀리코어)용 용량이 있어야 합니다.

가상 머신 CPU 오버헤드

전용 CPU가 요청되면 클러스터 CPU 오버헤드 요구 사항에 대한 1:1 영향이 있습니다. 그러지 않으면 가상 머신에 필요한 CPU 수에 대한 구체적인 규칙이 없습니다.

스토리지 오버헤드

아래 지침을 사용하여 OpenShift Virtualization 환경에 대한 스토리지 오버헤드 요구 사항을 추정할 수 있습니다.

클러스터 스토리지 오버헤드

Aggregated storage overhead per node ≈ 10 GiB

10GiB는 OpenShift Virtualization을 설치할 때 클러스터의 각 노드에 대해 예상되는 온디스크 스토리지 영향입니다.

가상 머신 스토리지 오버헤드

가상 머신당 스토리지 오버헤드는 가상 머신 내의 리소스 할당 요청에 따라 다릅니다. 이 요청은 클러스터의 다른 위치에서 호스팅되는 노드 또는 스토리지 리소스의 임시 스토리지에 대한 요청일 수 있습니다. 현재 OpenShift Virtualization은 실행 중인 컨테이너 자체에 대한 추가 임시 스토리지를 할당하지 않습니다.

예

클러스터 관리자가 클러스터에서 10개의 가상 머신을 호스팅하는 경우 1GiB RAM과 2개의 vCPU가 장착된 메모리의 클러스터 전체에 대한 영향은 11.68GiB입니다. 클러스터의 각 노드에 대한 디스크 스토리지 영향은 10GiB이며 호스트 가상 머신 워크로드가 최소 2개 코어인 작업자 노드에 대한 CPU 영향은 최소 2개입니다.

4.1.5. 단일 노드 OpenShift 차이점

단일 노드 OpenShift에 OpenShift Virtualization을 설치할 수 있습니다.

그러나 Single-node OpenShift는 다음 기능을 지원하지 않습니다.

  • 고가용성
  • Pod 중단
  • 실시간 마이그레이션
  • 제거 전략이 구성된 가상 머신 또는 템플릿

추가 리소스

4.1.6. 오브젝트 최대값

클러스터를 계획할 때 다음과 같은 테스트된 오브젝트 최대값을 고려해야 합니다.

4.1.7. 클러스터 고가용성 옵션

클러스터에 대해 다음과 같은 HA(고가용성) 옵션 중 하나를 구성할 수 있습니다.

  • 머신 상태 점검을 배포하여 설치 관리자 프로비저닝 인프라 (IPI)의 자동 고가용성을 사용할 수 있습니다.

    참고

    설치 관리자 프로비저닝 인프라를 사용하여 설치된 OpenShift Container Platform 클러스터에서는 올바르게 구성된 MachineHealthCheck 리소스를 사용하여 노드가 머신 상태 점검에 실패하고 클러스터에서 사용할 수 없게 되는 경우 재활용됩니다. 실패한 노드에서 실행된 VM에서 다음에 수행되는 작업은 일련의 조건에 따라 다릅니다. 잠재적 결과 및 실행 전략이 이러한 결과에 미치는 영향에 대한 자세한 내용은 전략 실행을 참조하십시오.

  • OpenShift Container Platform 클러스터에서 Node Health Check Operator 를 사용하여 NodeHealthCheck 컨트롤러를 배포하면 IPI 및 비 IPI에 대한 자동 고가용성을 사용할 수 있습니다. 컨트롤러는 비정상 노드를 식별하고 Self Node Remediation Operator 또는 Fence Agents Remediation Operator와 같은 수정 공급자를 사용하여 비정상 노드를 수정합니다. 노드 수정, 펜싱 및 유지 관리에 대한 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.

  • 모든 플랫폼의 고가용성은 모니터링 시스템 또는 자격을 갖춘 사람을 사용하여 노드 가용성을 모니터링합니다. 노드가 손실되면 노드를 종료하고 oc delete node <lost_node>를 실행합니다.

    참고

    외부 모니터링 시스템 또는 인증된 사용자 모니터링 노드 상태가 없으면 가상 머신의 가용성이 저하됩니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.