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

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

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

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

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가 지원됩니다.

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

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

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

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개 필요합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenShift Container Storage 서비스는 기본 서비스의 초기 세트로 구성되며 추가 장치 세트를 사용하여 확장할 수 있습니다.

이러한 모든 OpenShift Container Storage 서비스 Pod는 리소스 요구 사항에 따라 OpenShift Container Platform 노드의 kubernetes에 의해 예약됩니다.

각 장애 도메인에서 하나의 노드 3개로 클러스터를 확장하는 것은 Pod 배치 규칙을 쉽게 충족할 수 있습니다.

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

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

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

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

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

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

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

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

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

Kubernetes에서 컨테이너 네트워킹은 컨테이너 네트워크 인터페이스(CNI)를 구현하는 네트워킹 플러그인에 위임됩니다.

OpenShift Container Platform은 Multus CNI 플러그인을 사용하여 CNI 플러그인 체인을 허용합니다. 클러스터 설치 중에 기본 pod 네트워크를 구성합니다. 기본 네트워크는 클러스터의 모든 일반 네트워크 트래픽을 처리합니다. 사용 가능한 CNI 플러그인을 기반으로 추가 네트워크를 정의하고 이러한 네트워크 중 하나 이상을 pod에 연결할 수 있습니다. 필요에 따라 클러스터에 2개 이상의 추가 네트워크를 정의 할 수 있습니다. 따라서 스위칭 또는 라우팅과 같은 네트워크 기능을 제공하는 pod를 구성할 때 유연성이 제공됩니다.

Multus를 사용하려면 배포 전에 나중에 클러스터에 연결될 NAT(네트워크 연결 정의)를 생성해야 합니다. 자세한 내용은 다음을 참조하십시오.

Multus를 사용하면 하드웨어 설정 또는 VMWare 인스턴스 네트워크 설정에 따라 다음 구성이 가능합니다.

Multus 구성을 활용하기로 결정한 경우 다음 사전 요구 사항을 충족해야 합니다.

베어 메탈 에서 Multus 기반 구성을 구성하는 데 필요한 단계는 Multus 네트워크 생성 을 참조하십시오.

VMware 에서 Multus 기반 구성을 구성하는 데 필요한 단계는 Multus 네트워크 생성 을 참조하십시오.