배포 계획

Red Hat OpenShift Container Storage 4.7

RHOCS 4.7을 배포할 때 고려해야 할 중요한 고려 사항

초록

Red Hat OpenShift Container Storage 배포를 계획할 때 고려해야 할 중요한 사항은 이 문서를 읽어보십시오.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 이를 개선하는 방법을 알려 주십시오. 피드백을 제공하려면 다음을 수행하십시오.

  • 특정 문구에 대한 간단한 주석은 다음과 같습니다.

    1. 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 Feedback (피드백) 버튼이 있는지 확인합니다.
    2. 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
    3. 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
    4. 표시된 지침을 따릅니다.
  • 보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.

    1. Bugzilla 웹 사이트로 이동하십시오.
    2. Component로 Documentation을 선택하십시오.
    3. Description 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
    4. Submit Bug를 클릭하십시오.

1장. Red Hat OpenShift Container Storage 소개

Red Hat OpenShift Container Storage는 Red Hat OpenShift Container Platform을 위한 클라우드 스토리지 및 데이터 서비스의 고도로 통합된 컬렉션입니다. 간단한 배포 및 관리를 용이하게 하기 위해 운영자로 패키징된 Red Hat OpenShift Container Platform Service Catalog의 일부로 제공됩니다.

Red Hat OpenShift Container Storage 서비스는 주로 다음 구성 요소를 나타내는 스토리지 클래스를 통해 애플리케이션에서 사용할 수 있습니다.

  • 주로 데이터베이스 워크로드에 의존하는 블록 스토리지 장치입니다. 예에는 Red Hat OpenShift Container Platform 로깅 및 모니터링, PostgreSQL이 있습니다.
  • 주로 소프트웨어 개발, 메시징 및 데이터 집계 워크로드에 주력하는 공유 및 분산 파일 시스템입니다. Jenkins 빌드 소스 및 아티팩트, Wordpress 업로드 콘텐츠, Red Hat OpenShift Container Platform 레지스트리, JBoss AMQ를 사용한 메시징 등이 있습니다.
  • Multicloud 오브젝트 스토리지: 여러 클라우드 오브젝트 저장소에서 데이터를 추상화하고 검색할 수 있는 경량 S3 API 엔드포인트가 있습니다.
  • 온프레미스 오브젝트 스토리지에는 주로 데이터 집약적 애플리케이션을 대상으로 하는 수십 페타바이트 및 수십억 개의 오브젝트로 확장되는 강력한 S3 API 엔드포인트가 있습니다. 예를 들어 Spark, Presto, Red Hat AMQ Streams(Kafka) 및 TensorFlow 및 Pytorch와 같은 머신 학습 프레임워크가 포함된 행, 열리기, 반구조적 데이터 스토리지 및 액세스 등이 있습니다.

Red Hat OpenShift Container Storage 버전 4.x는 다음을 포함한 소프트웨어 프로젝트 컬렉션을 통합합니다.

  • Ceph, 블록 스토리지, 공유 및 분산 파일 시스템, 사내 오브젝트 스토리지 제공
  • Ceph CSI: 영구 볼륨 및 클레임의 프로비저닝 및 라이프사이클 관리
  • NooBaa - Multicloud Object Gateway 제공
  • OpenShift Container Storage 서비스를 초기화하고 관리하는 OpenShift Container Storage, Rook-Ceph 및 NooBaa 운영자.

2장. OpenShift Container Storage의 아키텍처

Red Hat OpenShift Container Storage는 에 대한 서비스를 제공하며 Red Hat OpenShift Container Platform에서 내부적으로 실행할 수 있습니다.

Red Hat OpenShift Container Storage 아키텍처

Red Hat OpenShift Container Storage architecture

Red Hat OpenShift Container Storage는 설치 프로그램 프로비저닝 인프라 또는 사용자 프로비저닝 인프라에 배포된 Red Hat OpenShift Container Platform 클러스터에 배포할 수 있도록 지원합니다. 이러한 두 가지 접근 방식에 대한 자세한 내용은 OpenShift Container Platform - 설치 프로세스를 참조하십시오. Red Hat OpenShift Container Storage 및 Red Hat OpenShift Container Platform의 구성 요소의 상호 운용성에 대한 자세한 내용은 상호 운용성 매트릭스 를 참조하십시오.

OpenShift Container Platform의 아키텍처 및 라이프사이클에 대한 자세한 내용은 OpenShift Container Platform 아키텍처를 참조하십시오.

참고

IBM Power Systems의 경우 OpenShift Container Platform - 설치 프로세스를 참조하십시오.

2.1. Operator 정보

Red Hat OpenShift Container Storage는 작업 및 리소스 특성을 쉽게 자동화할 수 있도록 관리 작업과 사용자 지정 리소스를 정리하는 세 가지 기본 연산자로 구성됩니다. 관리자는 원하는 클러스터의 최종 상태를 정의하고 OpenShift Container Storage 운영자는 클러스터가 해당 상태에 있는지 또는 최소한의 관리자 개입으로 해당 상태에 접근하는지 확인합니다.

OpenShift Container Storage Operator

테스트된 특정 방법으로 다른 Operator를 표시하여 지원되는 Red Hat OpenShift Container Storage 배포의 권장 사항 및 요구 사항을 조정하고 적용하는 meta-operator입니다. 이 운영자는 Rook-Ceph 및 NooBaa 운영자가 제공하는 리소스를 래핑하는 스토리지 클러스터 리소스를 제공합니다.

Rook-Ceph Operator

이 운영자는 영구 스토리지 및 파일, 블록 및 오브젝트 서비스의 패키징, 배포, 관리, 업그레이드 및 확장을 자동화합니다. 모든 환경에 대해 블록 및 파일 스토리지 클래스를 생성하고 온프레미스 환경에서 해당 오브젝트 스토리지 클래스 및 서비스 개체 버킷 클레임을 생성합니다.

또한 내부 모드 클러스터의 경우 다음을 나타내는 배포 및 서비스를 관리하는 Ceph 클러스터 리소스를 제공합니다.

  • 오브젝트 스토리지 데몬(OSD)
  • 모니터(MON)
  • 관리자 (MGR)
  • 메타데이터 서버(MDS)
  • 온프레미스 전용 RGW(오브젝트 게이트웨이)

NooBaa Operator

이 운영자는 Multicloud Object Gateway 오브젝트 서비스의 패키징, 배포, 관리, 업그레이드 및 확장을 자동화합니다. 이를 위해 만들어진 오브젝트 스토리지 클래스 및 서비스 오브젝트 버킷 클레임을 생성합니다.

또한 NooBaa 코어, 데이터베이스 및 엔드포인트의 배포 및 서비스를 관리하는 NooBaa 클러스터 리소스를 제공합니다.

2.2. 스토리지 클러스터 배포 접근 방식

유연성은 Red Hat OpenShift Container Storage의 핵심 원칙으로, 날로 확대되는 운영 모듈 목록으로 입증되었습니다. 이 섹션에서는 환경에 가장 적합한 접근 방식을 선택하는 데 도움이 되는 정보를 제공합니다. OpenShift Container Storage는 OpenShift Container Platform (내부 접근법)에 완전히 배포하거나 OpenShift Container Platform (외부 접근법) 외부에서 실행되는 클러스터에서 서비스를 사용할 수 있습니다.

2.2.1. 내부 접근 방식

Red Hat OpenShift Container Platform에 완전히 Red Hat OpenShift Container Storage를 배포하면 운영자 기반 배포 및 관리의 모든 이점이 있습니다. 그래픽 사용자 인터페이스에서 내부 연결 장치 접근 방식은 로컬 스토리지 운영자 및 로컬 스토리지 장치를 사용하여 내부 모드로 Red Hat OpenShift Container Storage를 배포하는 데 사용할 수 있습니다.

Red Hat OpenShift Container Storage가 Red Hat OpenShift Container Platform 내에서 완전히 실행될 때 두 가지 배포 모드를 사용할 수 있습니다.

  • 단순
  • 최적화

간단한 배포

Red Hat OpenShift Container Storage 서비스는 Red Hat OpenShift Container Platform의 운영자가 관리하는 애플리케이션과 공동 ID를 실행합니다.

간단한 배포는 다음과 같은 경우에 가장 적합합니다.

  • 스토리지 요구사항이 명확하지 않음
  • OpenShift Container Storage 서비스는 애플리케이션과 함께 실행됩니다.
  • 특정 크기의 노드 인스턴스를 생성하기가 어렵습니다(베어 메탈)

Red Hat OpenShift Container Storage를 애플리케이션과 함께 실행하려면 로컬 스토리지 장치 또는 EC2의 EBS 볼륨, VMware의 vSphere Virtual Volumes 또는 PowerVC에서 동적으로 프로비저닝한 SAN 볼륨과 같이 동적으로 연결된 이동식 스토리지 장치가 있어야 합니다.

최적화된 배포

OpenShift Container Storage 서비스는 Red Hat OpenShift Container Platform에서 관리하는 전용 인프라 노드에서 실행됩니다.

최적화된 접근 방식은 다음과 같은 경우에 가장 적합합니다.

  • 스토리지 요구 사항이 명확합니다.
  • OpenShift Container Storage 서비스는 전용 인프라 노드에서 실행됩니다.
  • 특정 크기의 노드 인스턴스를 쉽게 만들 수 있습니다(클라우드, 가상화 환경 등)

2.2.2. 외부 접근 방식

Red Hat OpenShift Container Storage는 OpenShift Container Platform 클러스터 외부에서 실행되는 Red Hat Ceph Storage 서비스를 스토리지 클래스로 표시합니다.

다음과 같은 경우 외부 접근법을 사용하는 것이 가장 좋습니다.

  • 스토리지 요구 사항은 매우 큽니다 (600 개 이상의 스토리지 장치)
  • 여러 OpenShift Container Platform 클러스터에서 공통 외부 클러스터의 스토리지 서비스를 사용해야 합니다.
  • 또 다른 팀(SRE, Storage 등)은 스토리지 서비스를 제공하는 외부 클러스터를 관리해야 합니다. 기존 상태일 수 있습니다.

2.3. 노드 유형

노드는 컨테이너 런타임과 서비스를 실행하여 컨테이너가 실행 중인지 확인하고 포드 간 네트워크 통신과 분리를 유지 관리합니다. OpenShift Container Storage에는 다음 세 가지 유형의 노드가 있습니다.

표 2.1. 노드 유형

노드 유형설명

Master

이러한 노드는 Kubernetes API를 노출하고, 새로 생성된 포드를 감시 및 예약하고, 노드 상태 및 수량을 유지 관리하며, 기본 클라우드 프로바이더와의 상호 작용을 제어하는 프로세스를 실행합니다.

인프라(Infra)

인프라 노드는 로깅, 지표, 레지스트리 및 라우팅과 같은 클러스터 수준 인프라 서비스를 실행합니다. OpenShift Container Platform 클러스터에서는 선택 사항입니다. 가상화 및 클라우드 환경에서 OpenShift Container Storage에 인프라 노드를 사용하는 것이 좋습니다.

Infra 노드를 생성하려면 infra 로 레이블이 지정된 새 노드를 프로비저닝할 수 있습니다. Red Hat OpenShift Container Storage 전용 작업자 노드를 사용하는 방법을 참조하십시오. https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/4.7/html-single/managing_and_allocating_storage_resources/index#how-to-use-dedicated-worker-nodes-for-openshift-container-storage_rhocs

Worker

작업자 노드는 애플리케이션을 실행하기 때문에 애플리케이션 노드라고도 합니다.

OpenShift Container Storage를 내부 모드로 배포하면 3개의 작업자 노드로 최소 클러스터가 필요합니다. 여기서 노드는 가용성을 보장하기 위해 세 개의 다른 랙 또는 가용성 영역에 분산하는 것이 좋습니다. OpenShift Container Storage를 작업자 노드에서 실행하려면 로컬 스토리지 장치 또는 이식 가능한 스토리지 장치가 동적으로 연결되어 있어야 합니다.

외부 모드로 배포하면 여러 노드에서 실행되어 오류가 발생할 경우 사용 가능한 노드에서 K8S로 다시 예약할 수 있습니다.

이동식 스토리지 장치의 예로는 EC2의 EBS 볼륨 또는 VMware의 vSphere Virtual Volumes 또는 PowerVC에 의해 동적으로 프로비저닝되는 SAN 볼륨이 있습니다.

참고

스토리지 워크로드만 실행하는 노드에는 Red Hat OpenShift Container Storage에 대한 서브스크립션이 필요합니다. 스토리지 워크로드 외에도 다른 워크로드를 실행하는 노드에는 Red Hat OpenShift Container Storage 및 Red Hat OpenShift Container Platform 서브스크립션이 모두 필요합니다. 자세한 내용은 6장. 서브스크립션를 참조하십시오.

3장. 내부 스토리지 서비스

Red Hat OpenShift Container Storage 서비스는 다음 인프라에서 실행되는 Red Hat OpenShift Container Platform에서 내부적으로 사용할 수 있습니다.

  • Amazon Web Services
  • 베어 메탈
  • VMware vSphere
  • Red Hat Virtualization 4.4.x 이상(IPI)
  • Microsoft Azure
  • Google Cloud [기술 프리뷰]
  • Red Hat OpenStack 13 이상(IPI) [기술 프리뷰]
  • IBM Power Systems
  • IBM Z 및 LinuxONE

배포 및 관리가 OpenShift Container Platform에서 내부적으로 실행되는 OpenShift Container Storage 서비스의 주요 요소입니다. 내부 클러스터 리소스를 생성하면 OpenShift Container Storage 기본 서비스의 내부 프로비저닝이 생성되고 애플리케이션에서 추가 스토리지 클래스를 사용할 수 있습니다.

4장. 외부 스토리지 서비스

Red Hat OpenShift Container Storage는 다음 플랫폼에서 실행되는 OpenShift Container Platform 클러스터를 통해 외부 Red Hat Ceph Storage 클러스터에서 사용할 수 있는 서비스를 만들 수 있습니다.

  • VMware vSphere
  • 베어 메탈
  • Red Hat OpenStack 플랫폼(기술 프리뷰)

OpenShift Container Storage 운영자는 외부 서비스에 대한 영구 볼륨 및 오브젝트 버킷 클레임을 충족하기 위해 서비스를 생성하고 관리합니다. 외부 클러스터는 OpenShift Container Platform에서 실행되는 애플리케이션에 대해 블록, 파일 및 오브젝트 스토리지 클래스를 제공할 수 있습니다. 외부 클러스터는 운영자가 배포하거나 관리하지 않습니다.

5장. 보안 고려 사항

5.1. FIPS-140-2

연방 정보 처리 표준 발행 140-2(FIPS-140-2)는 암호화 모듈 사용을 위한 보안 요구 사항을 정의하는 표준입니다. 이 표준은 미국 정부 기관과 계약자를 위한 법률에 따라 규정되며 기타 국제 및 업계별 표준에서 참조됩니다.

Red Hat OpenShift Container Storage는 이제 RHCOS(Red Hat Enterprise Linux OS/CoreOS)에서 제공하는 FIPS 검증 암호화 모듈을 사용합니다.

암호화 모듈은 현재 CMVP(Cryptographic Module Validation Program)에 의해 처리되고 있으며 해당 상태는 진행 중인 Modules in Process List 에서 확인할 수 있습니다. 최신 정보는 기술 자료 문서를 참조하십시오.

참고

OpenShift Container Storage를 설치하기 전에 OpenShift Container Platform에서 FIPS 모드를 활성화해야 합니다. RHEL 7의 OpenShift Container Storage 배포는 이 기능에 대해 지원되지 않으므로 OpenShift Container Platform은 RHCOS 노드에서 실행해야 합니다.

자세한 내용은 FIPS 모드에서 클러스터 설치 및 FIPS 암호화 지원을 참조하십시오.

5.2. 프록시 환경

프록시 환경은 인터넷에 대한 직접 액세스를 거부하고 대신 사용 가능한 HTTP 또는 HTTPS 프록시를 제공하는 프로덕션 환경입니다. Red Hat Openshift Container Platform은 기존 클러스터의 프록시 오브젝트를 수정하거나 새 클러스터의 install-config.yaml 파일에서 프록시 설정을 구성하여 프록시를 사용하도록 구성됩니다.

Red Hat은 클러스터 전체 프록시 구성에 따라 OpenShift Container Platform을 구성하는 경우 프록시 환경에서 Openshift Container Storage 버전 4.5 이상 배포를 지원합니다.

5.3. 데이터 암호화 옵션

암호화를 사용하면 필요한 암호화 키 없이 데이터를 읽을 수 없도록 인코딩할 수 있습니다. 이 메커니즘은 물리적 보안 위반 시 물리적 미디어가 보호되지 않도록 만드는 경우 데이터의 기밀성을 보호합니다. 데이터는 디스크에 기록될 때 암호화되며 디스크에서 읽을 때 암호를 해독합니다. 암호화된 데이터로 작업하면 성능이 저하될 수 있습니다.

암호화는 OpenShift Container Storage 4.6 이상을 사용하여 배포된 새 클러스터에서만 지원됩니다. 외부 KMS(Key Management System)를 사용하지 않는 기존 암호화된 클러스터는 외부 KMS를 사용하도록 마이그레이션할 수 없습니다.

현재는 클러스터 전체 및 영구 볼륨 암호화에 대해 지원되는 유일한 KMS입니다. OpenShift Container Storage 4.7.0 및 4.7.1에서는 KV(HookCorp Vault Key/Value) 시크릿 엔진 API만 지원되고 버전 1이 지원됩니다. OpenShift Container Storage 4.7.2부터 H¢Corp Vault KV 시크릿 엔진 API, 버전 1 및 2가 지원됩니다.

중요

Red Hat은 기술 파트너와 협력하여 이 문서를 고객에게 서비스로 제공하고 있습니다. 하지만 Red Hat은 H¢corp 제품에 대한 지원을 제공하지 않습니다. 이 제품에 대한 기술 지원이 필요한 경우 Hsea corp에 문의하십시오.

5.3.1. 클러스터 전체 암호화

Red Hat OpenShift Container Storage는 스토리지 클러스터의 모든 디스크 및 Multicloud Object Gateway 작업에 대해 클러스터 전체 암호화(encryption-at-rest)를 지원합니다. OpenShift Container Storage는 키 크기가 512비트이고 각 장치에 다른 암호화 키가 있는 aes-xts-plain64 암호와 함께 Linux 통합 키(LUKS) 버전 2 기반 암호화를 사용합니다. 키는 Kubernetes 시크릿 또는 외부 KMS를 사용하여 저장됩니다. 두 방법 모두 상호 배타적이며 메서드 간에 마이그레이션할 수 없습니다.

암호화는 기본적으로 비활성화되어 있습니다. 배포 시 클러스터의 암호화를 활성화할 수 있습니다. 자세한 내용은 배포 가이드를 참조하십시오.

클러스터 전체 암호화는 KMS(Key Management System) 없이 OpenShift Container Storage 4.6에서 지원되지만 KMS 포함 또는 없는 OpenShift Container Storage 4.7에서 지원됩니다.

현재 HCorp Vault는 유일하게 지원되는 KMS입니다. OpenShift Container Storage 4.7.0 및 4.7.1에서는 H¢Corp Vault KV 시크릿 엔진만 지원되고 API 버전 1이 지원됩니다. OpenShift Container Storage 4.7.2부터 H¢Corp Vault KV 시크릿 엔진 API, 버전 1 및 2가 지원됩니다.

중요

Red Hat은 기술 파트너와 협력하여 이 문서를 고객에게 서비스로 제공하고 있습니다. 하지만 Red Hat은 H¢corp 제품에 대한 지원을 제공하지 않습니다. 이 제품에 대한 기술 지원이 필요한 경우 Hsea corp에 문의하십시오.

5.3.2. 스토리지 클래스 암호화 [기술 프리뷰]

외부 KMS(키 관리 시스템)를 사용하여 스토리지 클래스 암호화로 영구 볼륨(블록 전용)을 암호화하여 장치 암호화 키를 저장할 수 있습니다. 영구 볼륨 암호화는 RADOS 블록 장치(RBD) 영구 볼륨에만 사용할 수 있습니다. 영구 볼륨 암호화를 사용하여 스토리지 클래스를 생성하는 방법을 참조하십시오.

OpenShift Container Storage 4.7 이상에서 스토리지 클래스 암호화가 지원됩니다.

6장. 서브스크립션

6.1. 서브스크립션 제품

Red Hat OpenShift Container Storage 서브스크립션은 Red Hat OpenShift Container Platform과 비슷한 "코어 쌍"을 기반으로 합니다. Red Hat OpenShift Container Storage 2-코어 서브스크립션은 OpenShift Container Platform이 실행되는 시스템의 CPU의 논리 코어 수를 기반으로 합니다.

OpenShift Container Platform과 마찬가지로:

  • OpenShift Container Storage 서브스크립션은 대규모 호스트를 처리할 수 있도록 스택킹할 수 있습니다.
  • 필요한 만큼 코어를 VM(가상 시스템)에 배포할 수 있습니다. 예를 들어, 10개의 2-코어 서브스크립션이 20개 코어를 제공하며 IBM Power Systems의 경우 SMT 레벨 8의 2-코어 서브스크립션이 2개 코어 또는 16개 vCPU를 제공하여 원하는 수의 VM에서 사용할 수 있습니다.
  • OpenShift Container Storage 서브스크립션은 프리미엄 또는 표준 지원에서 사용할 수 있습니다.

6.2. 재해 복구 서브스크립션

Red Hat OpenShift Container Storage는 재해 복구(DR), 콜드 백업 또는 기타 서브스크립션 유형을 제공하지 않습니다. OpenShift Container Storage가 설치되어 있거나 전원이 켜져 있거나 전원이 꺼져 있는 모든 시스템이 워크로드 실행 여부에 따라 활성 서브스크립션이 필요합니다.

6.3. 코어 대 vCPU 및 하이퍼 스레딩

특정 시스템에서 하나 이상의 코어를 사용하는지 여부를 판단하는 것은 현재 해당 시스템에 사용 가능한 하이퍼 스레딩이 있는지 여부에 따라 달라집니다. 하이퍼 스레딩은 Intel CPU의 기능일 뿐입니다. Red Hat 고객 포털을 방문하여 특정 시스템이 하이퍼 스레딩을 지원하는지 확인합니다.

하이퍼 스레딩이 활성화되어 있고 하나의 하이퍼 스레드가 표시된 시스템 코어와 같은 경우 코어 계산은 2 코어에서 4 vCPU의 비율입니다. 따라서 2코어 서브스크립션은 하이퍼스레드 시스템의 vCPU 4개를 지원합니다. 대규모 VM(가상 시스템)에는 8개의 vCPU(예: 4개의 서브스크립션 코어)가 있을 수 있습니다. 서브스크립션이 2코어 단위로 제공되면 이 4코어 또는 8개 vCPU를 적용하려면 2-코어 서브스크립션 2개가 필요합니다.

하이퍼 스레딩이 활성화되지 않고 볼 수 있는 각 시스템 코어가 기본 물리적 코어와 직접 연결되어 있는 경우 코어 계산은 2개 코어에서 2개의 vCPU의 비율입니다.

6.3.1. IBM Power Systems의 코어와 vCPU(SMT) 및 동시 멀티스레딩(SMT) 비교

특정 시스템이 하나 이상의 코어를 사용하는지 여부를 판단하는 것은 현재 구성된 SMT(동시 멀티스레딩) 수준에 따라 달라집니다. IBM Power 시스템은 아래 표와 같이 vCPU 수에 해당하는 각 코어에 대해 1, 2, 4 또는 8의 동시 멀티스레딩 수준을 제공합니다.

표 6.1. 다른 SMT 수준 및 해당 vCPU

SMT 수준SMT=1SMT=2SMT=4SMT=8

코어 1개

# vCPUs=1

# vCPUs=2

# vCPUs=4

# vCPUs=8

2개 코어

# vCPUs=2

# vCPUs=4

# vCPUs=8

# vCPUs=16

4개 코어

# vCPUs=4

# vCPUs=8

# vCPUs=16

# vCPUs=32

SMT가 구성된 시스템의 경우 서브스크립션 목적에 필요한 코어 수에 대한 계산은 SMT 수준에 따라 다릅니다. 따라서 2코어 서브스크립션은 SMT 레벨의 SMT 레벨 2의 vCPU 2개, SMT 레벨 2의 vCPU 4개, SMT 레벨 4개 및 SMT 레벨 8의 vCPU 16개 vCPU에 해당합니다. 대형 가상 머신(VM)에는 16개의 vCPU가 있을 수 있습니다. SMT 수준 8에서는 vCPU #을 SMT-8 = 2의 경우 SMT 수준(16 vCPUs / 8)으로 나누는 2코어 서브스크립션이 필요합니다. 서브스크립션이 2코어 단위로 제공되면 이 2코어 또는 16개 vCPU를 적용하려면 2코어 서브스크립션이 1개 필요합니다.

6.4. 코어 분할

홀수 코어가 필요한 시스템은 전체 2-코어 서브스크립션을 사용해야 합니다. 예를 들어, 1코어만 요구하도록 계산된 시스템은 등록 및 서브스크립션이 완료되면 전체 2-코어 서브스크립션을 사용합니다.

2개의 vCPU가 있는 단일 VM(가상 시스템)이 하이퍼 스레딩을 사용하므로 계산된 vCPU 1개를 사용하면 전체 2-코어 서브스크립션이 필요합니다. 2-코어 서브스크립션은 하이퍼 스레딩을 사용하여 두 개의 VM으로 분할되지 않을 수 있습니다. 자세한 내용은 코어 vs vCPU 및 하이퍼 스레딩 섹션을 참조하십시오.

다수의 코어가 필요하도록 가상 인스턴스의 크기를 조정하는 것이 좋습니다.

6.4.1. IBM Power Systems용 공유 프로세서 풀

IBM Power Systems에는 공유 프로세서 풀이라는 개념이 있습니다. 공유 프로세서 풀의 프로세서는 클러스터의 노드 전체에서 공유할 수 있습니다. OpenShift Container Storage에 필요한 집계 컴퓨팅 용량은 여러 코어 쌍이어야 합니다.

6.5. 서브스크립션 요구 사항

OpenShift Container Storage 구성 요소는 OpenShift Container Platform 작업자 또는 인프라 노드에서 실행할 수 있으며, 여기에서 Red Hat CoreOS (RHCOS) 또는 RHEL(Red Hat Enterprise Linux) 7을 호스트 운영 체제로 사용할 수 있습니다. 비율이 1:1인 모든 OpenShift Container Platform 서브스크립션 코어에는 OpenShift Container Storage 서브스크립션이 필요합니다.

인프라 노드를 사용하는 경우 OpenShift Container Platform 또는 OpenShift Container Storage 서브스크립션이 없어도 OpenShift Container Storage의 모든 OpenShift 작업자 노드 코어를 구독하는 규칙이 적용됩니다. 레이블을 사용하여 노드가 작업자인지 인프라 노드인지 상태를 나타낼 수 있습니다. 자세한 내용은 스토리지 관리 및 할당 가이드의 Red Hat OpenShift Container Storage 전용 작업자 노드를 사용하는 방법을 참조하십시오.

7장. 인프라 요구 사항

7.1. 플랫폼 요구 사항

OpenShift Container Storage 4.7부터 다음 버전만 지원됩니다.

  • OpenShift Container Platform 4.7 (동일한 버전)
  • OpenShift Container Platform 4.8 (한 가지 이전 버전)

이전 버전의 OpenShift Container Storage의 버그 수정은 버그 수정 버전으로 릴리스됩니다. 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.

외부 클러스터 서브스크립션 요구 사항은 이 Red Hat 지식베이스 문서를 참조하십시오.

지원되는 플랫폼 버전의 전체 목록은 Red Hat OpenShift Container Storage 및 Red Hat OpenShift Container Platform 상호 운용성 매트릭스 를 참조하십시오.

7.1.1. Amazon EC2

내부 Red Hat Openshift Container Storage 클러스터만 지원합니다.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 스토리지 클래스가 모두 제공되어야 합니다.

  • aws-ebs 프로비전 프로그램을 통한 EBS 스토리지
  • Local Storage Operator를 통한 인스턴스 스토리지

7.1.2. 베어 메탈

내부 클러스터 지원 및 외부 클러스터 사용.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.

7.1.3. VMware vSphere

내부 클러스터 지원 및 외부 클러스터 사용.

권장 버전: vSphere 6.7, 업데이트 2

자세한 내용은 VMware vSphere 인프라 요구 사항을 참조하십시오.

또한 내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 스토리지 클래스를 제공합니다.

  • vsphere-volume 프로비전 프로그램을 통한 VSAN 또는 VMFS 데이터 저장소
  • Local Storage Operator를 통한 VMDK, RDM 또는 DirectPath 스토리지 장치.

7.1.4. Red Hat Virtualization Platform

내부 Red Hat Openshift Container Storage 클러스터만 지원합니다.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.

7.1.5. Microsoft Azure

내부 Red Hat Openshift Container Storage 클러스터만 지원합니다.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 스토리지 클래스를 제공하는 스토리지 클래스를 보유해야 합니다.

  • azure-disk 프로비저너를 통한 Azure 디스크

7.1.6. Google Cloud [기술 프리뷰]

내부 Red Hat Openshift Container Storage 클러스터만 지원합니다.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 스토리지 클래스를 제공하는 스토리지 클래스를 보유해야 합니다.

  • gce-pd 프로비저너를 통한 GCE 영구 디스크

7.1.7. Red Hat OpenStack Platform [기술 프리뷰]

내부 Red Hat Openshift Container Storage 클러스터 지원 및 외부 클러스터 사용.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 스토리지 클래스를 제공하는 스토리지 클래스를 보유해야 합니다.

  • Cinder 프로비저너를 통한 표준 디스크

7.1.8. IBM Power Systems

내부 Red Hat Openshift Container Storage 클러스터만 지원합니다.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.

7.1.9. IBM Z 및 LinuxONE

내부 Red Hat Openshift Container Storage 클러스터만 지원합니다.

내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.

7.2. 외부 모드 요구 사항

7.2.1. Red Hat Ceph Storage

RHCS(Red Hat Ceph Storage) 버전 4.2z1 이상이 필요합니다. 지원되는 버전에 대한 자세한 내용은 Red Hat Ceph Storage 릴리스 및 해당 Ceph 패키지 버전에 대한 기술 자료 문서를 참조하십시오.

RHCS 4 클러스터 설치 방법에 대한 지침은 설치 가이드를 참조하십시오.

7.3. 리소스 요구사항

OpenShift Container Storage 서비스는 기본 서비스의 초기 세트로 구성되며 추가 장치 세트를 사용하여 확장할 수 있습니다. 이러한 모든 OpenShift Container Storage 서비스 Pod는 리소스 요구 사항에 따라 OpenShift Container Platform 노드에서 kubernetes에 의해 예약됩니다. 각 장애 도메인에 있는 하나의 노드인 3개의 배수로 클러스터를 확장하면 포드 배치 규칙을 쉽게 충족할 수 있습니다.

표 7.1. OpenShift Container Storage에만 사용 가능한 리소스 요구 사항 집계

배포 모드기본 서비스추가 장치 세트

내부

  • CPU 30개(논리)
  • 72GiB 메모리
  • 스토리지 장치 3개
  • CPU 6개(논리)
  • 15GiB 메모리
  • 스토리지 장치 3개

외부

  • CPU 4개(논리)
  • 16GiB 메모리

해당 없음

예제: 단일 장치 세트가 있는 내부 모드 배포에서 3개의 노드 클러스터의 경우 최소 3 x 10 = 30개의 CPU 단위가 필요합니다.

자세한 내용은 6장. 서브스크립션CPU 단위를 참조하십시오.

OpenShift Container Storage 클러스터 설계에 대한 추가 지침은 OCS 크기 조정 도구를 참조하십시오.

CPU 단위

이 섹션에서는 1개의 CPU 유닛이 Kubernetes 개념인 1 CPU 단위에 매핑됩니다.

  • CPU의 1 단위는 하이퍼바이저가 아닌 CPU의 경우 1코어에 해당합니다.
  • 2개의 CPU 단위는 하이퍼스레딩된 CPU의 경우 1코어에 해당합니다.
  • OpenShift Container Storage 코어 기반 서브스크립션은 항상 쌍(2코어)으로 제공됩니다.

표 7.2. IBM Power Systems에 대한 최소 리소스 요구 사항 집계

배포 모드기본 서비스

내부

  • 48 CPU(논리적)
  • 192GB 메모리
  • 스토리지 장치 3개, 추가 500GB의 디스크 포함

외부

  • 해당 없음

예제: 내부 연결 장치 모드 배포에서 3개의 노드 클러스터의 경우 최소 3 x 16 = 48개의 CPU 및 3 x 64 = 192GB의 메모리가 필요합니다.

7.3.1. 최소 배포 리소스 요구 사항 [기술 프리뷰]

표준 배포 리소스 요구 사항이 충족되지 않은 경우 OpenShift Container Storage 클러스터는 최소 구성으로 배포됩니다.

표 7.3. OpenShift Container Storage의 집계 리소스 요구 사항만

배포 모드기본 서비스

내부

  • 24 CPU (논리적)
  • 72GiB 메모리
  • 스토리지 장치 3개

장치 세트를 추가하려면 최소 배포를 표준 배포로 변환하는 것이 좋습니다.

중요

최소 구성을 사용하는 OpenShift Container Storage 배포는 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

7.3.2. 소형 배포 리소스 요구 사항 [기술 프리뷰]

OpenShift Container Storage는 모든 워크로드가 3개의 강력한 마스터 노드에서 실행되는 3노드 OpenShift 소형 베어 메탈 클러스터에 설치할 수 있습니다. 작업자 또는 스토리지 노드가 없습니다.

표 7.4. OpenShift Container Storage의 집계 리소스 요구 사항만

배포 모드기본 서비스추가 장치 세트

내부

  • 24 CPU (논리적)
  • 72GiB 메모리
  • 스토리지 장치 3개
  • CPU 6개(논리)
  • 15GiB 메모리
  • 스토리지 장치 3개

소형 베어 메탈 클러스터에서 OpenShift Container Platform을 구성하려면 3-노드 클러스터 구성에지 배포를 위한 3-노드 아키텍처 제공을 참조하십시오.

중요

3노드 소형 클러스터에 OpenShift Container Storage를 배포하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

7.4. Pod 배치 규칙

Kubernetes는 선언적 배치 규칙에 따라 포드 배치를 담당합니다. 내부 클러스터에 대한 OpenShift Container Storage 기본 서비스 배치 규칙은 다음과 같이 요약할 수 있습니다.

  • 노드는 cluster.ocs.openshift.io/openshift-storage 키로 레이블이 지정됩니다.
  • 노드가 없는 경우 노드가 의사 장애 도메인으로 정렬됩니다.
  • 고가용성을 필요로 하는 구성 요소가 장애 도메인 전체에 분산됨
  • 스토리지 장치는 각 장애 도메인에서 액세스할 수 있어야 합니다.

이렇게 하면 노드가 3개 이상 있고 기존 토폴로지 라벨이 있는 경우 노드가 3개의 개별 랙 또는 영역 장애 도메인에 있어야 합니다.

추가 장치 세트의 경우 스토리지 장치가 있어야 하며 3개의 실패 도메인 각각에 해당 장치를 사용하는 포드에 충분한 리소스가 있어야 합니다. 수동 배치 규칙을 사용하여 기본 배치 규칙을 재정의할 수 있지만, 일반적으로 이 방법은 베어 메탈 배포에만 적합합니다.

7.5. 스토리지 장치 요구 사항

이 섹션을 사용하여 내부 모드 배포 및 업그레이드를 계획할 때 고려할 수 있는 다양한 스토리지 용량 요구 사항을 설명합니다. 일반적으로 노드당 9개의 장치 이하를 권장합니다. 이 권장 사항은 두 노드가 클라우드 프로바이더 동적 스토리지 장치 연결 제한보다 작게 유지되고 로컬 스토리지 장치를 사용하여 노드 장애 후 복구 시간을 제한하도록 합니다. 각 장애 도메인에 있는 하나의 노드인 3개의 배수로 클러스터를 확장하면 포드 배치 규칙을 쉽게 충족할 수 있습니다.

참고

설치 시 선택한 용량의 증가에서만 스토리지 용량을 확장할 수 있습니다.

7.5.1. 동적 스토리지 장치

Red Hat OpenShift Container Storage에서는 0.5TiB, 2TiB 또는 4TiB 용량을 동적 스토리지 장치 크기에 대한 요청 크기로 선택할 수 있습니다. 노드당 실행할 수 있는 동적 스토리지 장치의 수는 노드 크기, 기본 프로비저너 제한 및 리소스 요구 사항 의 기능입니다.

7.5.2. 로컬 스토리지 장치

로컬 스토리지 배포의 경우 4TiB 이하의 디스크 크기를 사용할 수 있으며 모든 디스크는 동일한 크기와 유형이어야 합니다. 노드별로 실행할 수 있는 로컬 스토리지 장치의 수는 노드 크기 및 리소스 요구 사항 의 기능입니다. 각 장애 도메인에 있는 하나의 노드인 3개의 배수로 클러스터를 확장하면 포드 배치 규칙을 쉽게 충족할 수 있습니다.

참고

디스크 파티셔닝은 지원되지 않습니다.

7.5.3. 용량 계획

항상 사용 가능한 스토리지 용량이 소비보다 먼저 유지되도록 합니다. 사용 가능한 스토리지 용량이 완전히 고갈되면 복구가 어려워지며 단순히 용량을 추가하거나 콘텐츠를 삭제하거나 마이그레이션하는 것보다 더 많은 개입이 필요합니다.

클러스터 스토리지 용량이 75%(near-full) 및 85%(전체)에 도달하면 용량 경고가 발생합니다. 항상 용량 경고를 즉시 처리하고 정기적으로 스토리지를 검토하여 스토리지 공간이 부족하지 않도록 합니다. 사용 가능한 공간 중 75%(near-full)가 수행되거나 클러스터를 확장합니다. 85%(전체) 경고가 표시되면 스토리지 공간이 부족하고 표준 명령을 사용하여 공간을 확보할 수 없음을 나타냅니다. 이때 Red Hat 고객 지원에 문의하십시오.

다음 표는 동적 스토리지 장치가 있는 Red Hat OpenShift Container Storage의 노드 구성의 예를 보여줍니다.

표 7.5. 3개의 노드를 사용한 초기 구성 예

저장 장치 크기노드당 스토리지 장치총 용량사용 가능한 스토리지 용량

0.5 TiB

1

1.5 TiB

0.5 TiB

2 TiB

1

6 TiB

2 TiB

4 TiB

1

12TiB

4 TiB

표 7.6. 30개의 노드가 있는 확장 구성 예(N)

저장 장치 크기 (D)노드당 스토리지 장치 (M)총 용량 (D * M * N)사용 가능한 스토리지 용량 (D*M*N/3)

0.5 TiB

3

45TiB

15TiB

2 TiB

6

360TiB

120TiB

4 TiB

9

collectd TiB

360TiB

8장. 재해 복구

DR(재해 복구)은 조직이 중단 또는 재해 발생 시 비즈니스 크리티컬 기능이나 일반적인 작업을 복구하고 재개하는 데 도움이 됩니다.

Red Hat OpenShift Container Storage는 다음 두 가지 플레이버를 제공합니다.

  • 지역 DR: 두 개의 Openshift Container Platform 클러스터를 지원하는 두 OpenShift Container Storage 클러스터에서 스토리지 볼륨의 다중 클러스터 비동기 복제입니다. 상태 비저장 항목을 포함한 모든 상태 저장 애플리케이션은 피어 클러스터에 동일한 배포를 수행하기 전에 몇 가지 준비가 필요합니다.

    중요

    이는 개발자 미리보기 기능이며 개발자 미리보기 지원 제한 사항을 따릅니다. 개발자 미리보기 릴리스는 프로덕션 환경에서 실행되도록 설계되지 않으며 Red Hat 고객 포털 케이스 관리 시스템을 통해 지원되지 않습니다. 개발자 미리보기 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 리스트에 연락하여 Red Hat 개발 팀 구성원이 최대한 신속하게 지원해 드립니다.

  • Metro DR (Stretched Cluster - Arbiter): 이 경우 단일 클러스터는 Arbiter의 위치로 세 번째 영역으로 두 영역으로 확장됩니다. 현재 OpenShift Container Platform 온프레미스에 배포하기 위한 기술 프리뷰 기능입니다.

    참고

    이 솔루션은 대기 시간이 위치 간에 4밀리초의 왕복 시간(RTT)을 초과하지 않는 배포되도록 설계되었습니다. 대기 시간이 길어질 경우 Red Hat 고객 지원팀에 문의하십시오.

    Arbiter 확장 클러스터를 사용하려면

    • 다음 세 영역에 최소 5개의 노드가 있어야 합니다.

      • 각 데이터 센터 영역에는 영역당 두 개의 노드가 사용됩니다.
      • 하나의 노드가 있는 한 개의 추가 영역은 중재자 영역에 사용됩니다(rbiter는 마스터 노드에 있을 수 있음).
    • 클러스터를 생성하기 전에 모든 노드에 영역 라벨을 사용하여 수동으로 레이블이 지정되어야 합니다.

      예를 들어 영역에 다음과 같이 레이블이 지정될 수 있습니다.

      • topology.kubernetes.io/zone=arbiter (마스터 또는 작업자 노드)
      • topology.kubernetes.io/zone=datacenter1 (최소 두 개의 작업자 노드)
      • topology.kubernetes.io/zone=datacenter2 (최소 두 개의 작업자 노드)
중요

이는 기술 프리뷰 기능이며 로컬 스토리지 장치를 사용하는 배포에서만 사용할 수 있습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

9장. 연결이 끊긴 환경

연결이 끊긴 환경은 OLM(Operator Lifecycle Manager)이 인터넷 연결이 필요한 기본 Operator Hub 및 이미지 레지스트리에 액세스할 수 없는 네트워크 제한 환경입니다.

Red Hat은 OpenShift Container Platform이 제한된 네트워크에 설치된 연결이 끊긴 환경에서 OpenShift Container Storage 배포를 지원합니다.

참고

제한된 네트워크 환경에 OpenShift Container Storage를 설치하는 경우 기본적으로 OpenShift Container Platform에서 인터넷 연결을 가정하고 chronyd는 *.rhel.pool.ntp.org 서버를 사용하도록 구성되어 있으므로 노드에 사용자 지정 NTP(Network Time Protocol) 구성을 적용합니다. 자세한 내용은 Red Hat Knowledgebase 문서 및 chrony 타임 서비스 구성을 참조하십시오.

자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용에 대한 Operator 가이드를 참조하십시오.

10장. IBM Power Systems 및 IBM Z 인프라에서 지원되지 않는 기능

  • IBM Power Systems 및 IBM Z 인프라의 OpenShift Container Storage 4.7은 오브젝트 스토리지가 아닌 블록 및 파일 스토리지만 지원합니다.
  • FIPS 자체는 RHEL에서 지원되지 않으므로 IBM Power Systems 및 IBM Z 인프라의 OpenShift Container Storage 4.7에서는 FIPS가 지원되지 않습니다.
  • 외부 모드는 IBM Power Systems 및 IBM Z 인프라에 적용되지 않습니다.
  • IBM Power Systems 및 IBM Z의 OpenShift Container Storage 4.7은 연결되지 않은 환경을 지원하지 않습니다.
  • IBM Power Systems 및 IBM Z infrstructure의 OpenShift Container Storage 4.7은 동적 스토리지 장치를 지원하지 않습니다.
  • IBM Power Systems 및 IBM Z 인프라는 OpenShift Container Storage 4.7에 도입된 다음과 같은 새로운 기능을 지원하지 않습니다.

    1. 외부 KMS(키 관리 시스템)를 사용한 스토리지 클래스 암호화.
    2. 클러스터 전체 암호화.
    3. 재해 복구.
    4. OpenShift Container Storage 클러스터의 유연한 확장.

11장. 다음 단계

OpenShift Container Storage 배포를 시작하려면 OpenShift Container Platform 내에서 내부 모드를 사용하거나 외부 모드를 사용하여 OpenShift Container Platform 외부에서 실행되는 클러스터에서 사용 가능한 서비스를 만들 수 있습니다.

요구 사항에 따라 해당 배포 가이드로 이동합니다.