Red Hat Summit배포 계획
Red Hat OpenShift Data Foundation 4.13을 배포할 때 중요한 고려 사항
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 개선할 내용에 대해 알려주십시오.
피드백을 제공하려면 Bugzilla 티켓을 생성합니다.
- Bugzilla 웹 사이트로 이동하십시오.
- 구성 요소 섹션에서 설명서 를 선택합니다.
- 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
- 버그 제출을 클릭합니다.
1장. OpenShift Data Foundation 소개
Red Hat OpenShift Data Foundation은 Red Hat OpenShift Container Platform을 위한 클라우드 스토리지 및 데이터 서비스의 고도로 통합된 컬렉션입니다. 간단한 배포 및 관리를 용이하게 하기 위해 Operator로 패키지로 제공되는 Red Hat OpenShift Container Platform Service Catalog의 일부로 제공됩니다.
Red Hat OpenShift Data Foundation 서비스는 주로 다음 구성 요소를 나타내는 스토리지 클래스를 통해 애플리케이션에서 사용할 수 있습니다.
- 주로 데이터베이스 워크로드를 처리하는 블록 스토리지 장치입니다. Cryostat 예로는 Red Hat OpenShift Container Platform 로깅 및 모니터링 및 PostgreSQL이 있습니다.
블록 스토리지는 여러 컨테이너에서 데이터를 공유할 필요가 없는 경우에만 모든 워크로드에 사용해야 합니다.
- 공유 및 분산 파일 시스템으로, 주로 소프트웨어 개발, 메시징 및 데이터 집계 워크로드를 지원합니다. 예를 들면 Jenkins 빌드 소스 및 아티팩트, Wordpress 업로드 콘텐츠, Red Hat OpenShift Container Platform 레지스트리 및 JBoss AMQ를 사용한 메시징이 있습니다.
- Multicloud 오브젝트 스토리지: 여러 클라우드 오브젝트 저장소의 스토리지를 추상화하고 데이터를 검색할 수 있는 경량 S3 API 엔드포인트를 제공합니다.
- 프레미스 오브젝트 스토리지에서는 수십 개의 페타바이트 및 10억 개의 오브젝트로 확장되는 강력한 S3 API 엔드포인트를 제공하며 주로 데이터 집약적 애플리케이션을 대상으로 합니다. 예를 들면 Spark, Presto, Red Hat AMQ Streams(Kafka) 및 TensorFlow 및 Pytorch와 같은 머신 학습 프레임워크를 사용하여 행, columnar 및 반정형 데이터의 스토리지 및 액세스가 포함됩니다.
CephFS 영구 볼륨에서 PostgresSQL 워크로드를 실행할 수 없으며 RADOS Block Device(RBD) 볼륨을 사용하는 것이 좋습니다. 자세한 내용은 ODF 데이터베이스 워크로드 CephFS PV/PVC를 사용하지 않는 지식베이스 솔루션을 참조하십시오.
Red Hat OpenShift Data Foundation 버전 4.x는 다음을 포함하여 소프트웨어 프로젝트 컬렉션을 통합합니다.
- Ceph: 블록 스토리지, 공유 및 분산 파일 시스템, 온-프레미스 개체 스토리지 제공
- 영구 볼륨 및 클레임의 프로비저닝 및 라이프사이클을 관리하기 위한 Ceph CSI
- NooBaa: 멀티클라우드 오브젝트 게이트웨이를 제공
- OpenShift Data Foundation, Rook-Ceph 및 NooBaa Operator가 OpenShift Data Foundation 서비스를 초기화하고 관리합니다.
2장. OpenShift Data Foundation의 아키텍처
Red Hat OpenShift Data Foundation은 서비스를 제공하며 Red Hat OpenShift Container Platform에서 내부적으로 실행할 수 있습니다.
그림 2.1. Red Hat OpenShift Data Foundation 아키텍처
Red Hat OpenShift Data Foundation은 설치 관리자 프로비저닝 또는 사용자 프로비저닝 인프라에 배포된 Red Hat OpenShift Container Platform 클러스터에 대한 배포를 지원합니다.
이러한 두 가지 접근 방식에 대한 자세한 내용은 OpenShift Container Platform - 설치 프로세스를 참조하십시오.
Red Hat OpenShift Data Foundation 및 Red Hat OpenShift Container Platform의 구성 요소의 상호 운용성에 대한 자세한 내용은 Red Hat OpenShift Data Foundation Supportability and Interoperability Checker 를 참조하십시오.
OpenShift Container Platform의 아키텍처 및 라이프사이클에 대한 자세한 내용은 OpenShift Container Platform 아키텍처를 참조하십시오.
IBM Power의 경우 OpenShift Container Platform - 설치 프로세스를 참조하십시오.
2.1. Operator 정보
Red Hat OpenShift Data Foundation은 작업 및 리소스 특성을 쉽게 자동화할 수 있도록 관리 작업 및 사용자 정의 리소스를 협력하는 세 가지 주요 Operator로 구성됩니다. 관리자는 원하는 클러스터 최종 상태를 정의하고 OpenShift Data Foundation 운영자는 클러스터가 해당 상태에 있거나 최소한의 관리자 개입으로 해당 상태에 접근하도록 합니다.
OpenShift Data Foundation operator
지원되는 Red Hat OpenShift Data Foundation 배포의 권장 사항 및 요구 사항을 강제 적용하고 시행하기 위해 다른 운영자를 특정 테스트된 방식으로 실행하는 meta-operator입니다. rook-ceph 및 noobaa Operator는 이러한 리소스를 래핑하는 스토리지 클러스터 리소스를 제공합니다.
rook-ceph Operator
이 Operator는 영구 스토리지 및 파일, 블록 및 오브젝트 서비스의 패키징, 배포, 관리, 업그레이드 및 스케일링을 자동화합니다. 모든 환경에 대한 블록 및 파일 스토리지 클래스를 생성하고 온-프레미스 환경에서 만든 오브젝트 스토리지 클래스 및 서비스 OBC(Object Bucket Claims)를 생성합니다.
또한 내부 모드 클러스터의 경우 다음을 나타내는 배포 및 서비스를 관리하는 ceph 클러스터 리소스를 제공합니다.
- OSD(Object Storage Daemons)
- 모니터(MON)
- 관리자 (MGR)
- 메타데이터 서버(MDS)
- RADOS Object Gateways (RGWs) 온-프레미스만
Multicloud Object Gateway Operator
이 Operator는 MCG(Multicloud Object Gateway) 오브젝트 서비스의 패키징, 배포, 관리, 업그레이드 및 스케일링을 자동화합니다. 개체 스토리지 클래스를 생성하고 이를 상대로 만든 object storage 클래스를 서비스합니다.
또한 NooBaa 코어, 데이터베이스 및 엔드포인트의 배포 및 서비스를 관리하는 NooBaa 클러스터 리소스를 제공합니다.
MCG에 대한 OpenShift Data Foundation의 기본 구성은 낮은 리소스 소비에 최적화되고 성능이 아닙니다. MCG를 자주 사용하려는 경우 Multicloud Object Gateway의 knowledebase 문서 성능 튜닝 가이드의 리소스 제한 증가에 대한 정보를 참조하십시오.
2.2. 스토리지 클러스터 배포 접근 방식
운영 모드가 증가하고 있는 목록은 유연성이 Red Hat OpenShift Data Foundation의 핵심 십자라는 증거가 됩니다. 이 섹션에서는 환경에 가장 적합한 접근 방식을 선택하는 데 도움이 되는 정보를 제공합니다.
Red Hat OpenShift Data Foundation은 OpenShift Container Platform (내부 접근 방식) 내에서 배포하거나 OpenShift Container Platform 외부에서 실행되는 클러스터에서 서비스를 사용할 수 있습니다 (외부 접근 방식).
2.2.1. 내부 접근 방식
Red Hat OpenShift Container Platform에 전적으로 Red Hat OpenShift Data Foundation을 배포하면 Operator 기반 배포 및 관리의 모든 이점이 있습니다. GUI(그래픽 사용자 인터페이스)에서 내부 연결 장치 접근 방식을 사용하여 로컬 스토리지 Operator 및 로컬 스토리지 장치를 사용하여 내부 모드로 Red Hat OpenShift Data Foundation을 배포할 수 있습니다.
배포 및 관리의 용이성은 OpenShift Container Platform에서 내부적으로 OpenShift Data Foundation 서비스를 실행하는 주요 요인입니다. Red Hat OpenShift Data Foundation은 Red Hat OpenShift Container Platform 내에서 전적으로 실행되는 경우 다음 두 가지 배포 모드를 사용할 수 있습니다.
- simple
- 최적화
간단한 배포
Red Hat OpenShift Data Foundation 서비스는 애플리케이션과의 공동 상주 서비스를 실행합니다. Red Hat OpenShift Container Platform의 Operator는 이러한 애플리케이션을 관리합니다.
간단한 배포는 경우에 가장 적합합니다.
- 스토리지 요구 사항은 명확하지 않습니다.
- Red Hat OpenShift Data Foundation 서비스는 애플리케이션과의 공동 상주 서비스를 실행합니다.
- 특정 크기의 노드 인스턴스를 생성하기가 어렵습니다(예: 베어 메탈).
Red Hat OpenShift Data Foundation이 애플리케이션과 함께 작동하려면 노드에 로컬 스토리지 장치 또는 EC2의 EBS 볼륨 또는 VMware의 vSphere 가상 볼륨과 같이 동적으로 연결된 이동식 스토리지 장치가 있어야 합니다.
PowerVC는 SAN 볼륨을 동적으로 프로비저닝합니다.
최적화된 배포
Red Hat OpenShift Data Foundation 서비스는 전용 인프라 노드에서 실행됩니다. Red Hat OpenShift Container Platform은 이러한 인프라 노드를 관리합니다.
최적화된 접근 방식은 상황에 가장 적합한 경우
- 스토리지 요구 사항은 명확합니다.
- Red Hat OpenShift Data Foundation 서비스는 전용 인프라 노드에서 실행됩니다.
- 특정 크기의 노드 인스턴스를 쉽게 생성할 수 있습니다(예: 클라우드, 가상화 환경 등).
2.2.2. 외부 접근 방식
Red Hat OpenShift Data Foundation은 OpenShift Container Platform 클러스터 외부에서 실행되는 Red Hat Ceph Storage 서비스를 스토리지 클래스로 공개합니다.
외부 접근 방식은 경우에 가장 잘 사용됩니다.
- 스토리지 요구 사항은 상당한 스토리지 장치(600개 이상의 스토리지 장치)입니다.
- 여러 OpenShift Container Platform 클러스터에서 공통 외부 클러스터의 스토리지 서비스를 사용해야 합니다.
- 다른 팀, 사이트 안정성 엔지니어링(SRE), 스토리지 등은 스토리지 서비스를 제공하는 외부 클러스터를 관리해야 합니다. Pre-existing될 수 있습니다.
2.3. 노드 유형
노드는 컨테이너 런타임과 서비스를 실행하여 컨테이너가 실행 중인지 확인하고 포드 간 네트워크 통신 및 분리를 유지합니다. OpenShift Data Foundation에는 세 가지 유형의 노드가 있습니다.
| 노드 유형 | 설명 |
|---|---|
| Master | 이러한 노드는 Kubernetes API를 노출하고, 새로 생성된 pod를 감시 및 예약하고, 노드 상태 및 수량을 유지 관리하며, 기본 클라우드 공급자와의 상호 작용을 제어하는 프로세스를 실행합니다. |
| 인프라(Infra) | 인프라 노드는 로깅, 메트릭, 레지스트리 및 라우팅과 같은 클러스터 수준 인프라 서비스를 실행합니다. OpenShift Container Platform 클러스터에서는 선택 사항입니다. OpenShift Data Foundation 계층 워크로드를 애플리케이션과 분리하려면 가상화 및 클라우드 환경에서 OpenShift Data Foundation의 인프라 노드를 사용해야 합니다.
Infra 노드를 만들려면 |
| Worker | 작업자 노드는 애플리케이션을 실행하기 때문에 애플리케이션 노드라고도 합니다. OpenShift Data Foundation이 내부 모드로 배포되는 경우 작업자 노드 3개로 구성된 최소 클러스터가 필요합니다. 가용성을 보장하기 위해 노드가 3개의 다른 랙 또는 가용 영역에 분산되어 있는지 확인합니다. OpenShift Data Foundation이 작업자 노드에서 작동하려면 로컬 스토리지 장치 또는 이식 가능한 스토리지 장치를 작업자 노드에 동적으로 연결해야 합니다. OpenShift Data Foundation이 외부 모드로 배포되면 여러 노드에서 실행됩니다. 그러면 오류가 발생할 경우 Kubernetes에서 사용 가능한 노드에서 다시 예약할 수 있습니다. |
OpenShift Data Foundation에는 OpenShift Container Platform과 동일한 수의 하위 검사가 필요합니다. 그러나 OpenShift Data Foundation이 인프라 노드에서 실행되는 경우 OpenShift에는 이러한 노드에 OpenShift Container Platform 서브스크립션이 필요하지 않습니다. 따라서 OpenShift Data Foundation 컨트롤 플레인에는 추가 OpenShift Container Platform 및 OpenShift Data Foundation 서브스크립션이 필요하지 않습니다. 자세한 내용은 6장. 서브스크립션의 내용을 참조하십시오.
3장. 내부 스토리지 서비스
Red Hat OpenShift Data Foundation 서비스는 다음 인프라에서 실행되는 Red Hat OpenShift Container Platform의 내부적으로 사용할 수 있습니다.
- AWS(Amazon Web Services)
- 베어 메탈
- VMware vSphere
- Microsoft Azure
- Google Cloud [기술 프리뷰]
- Red Hat Virtualization 4.4.x 이상(installer 프로비저닝 인프라)
- Red Hat OpenStack 13 이상(installer 프로비저닝 인프라) [기술 프리뷰]
- IBM Power
- IBM Z 및 IBM® LinuxONE
내부 클러스터 리소스를 생성하면 OpenShift Data Foundation 기본 서비스가 내부 프로비저닝되고 애플리케이션에서 추가 스토리지 클래스를 사용할 수 있습니다.
4장. 외부 스토리지 서비스
Red Hat OpenShift Data Foundation은 IBM FlashSystems를 사용하거나 다음 플랫폼에서 실행되는 OpenShift Container Platform 클러스터를 통해 사용할 수 있는 외부 Red Hat Ceph Storage 클러스터의 서비스를 만들 수 있습니다.
- VMware vSphere
- 베어 메탈
- Red Hat OpenStack 플랫폼 (기술 프리뷰)
- IBM Power
- IBM Z
OpenShift Data Foundation Operator는 영구 볼륨(PV) 및 오브젝트 버킷 클레임(OBC)을 충족하기 위해 서비스를 생성하고 관리합니다. 외부 클러스터는 OpenShift Container Platform에서 실행되는 애플리케이션의 블록, 파일 및 오브젝트 스토리지 클래스를 제공할 수 있습니다. Operator는 외부 클러스터를 배포하거나 관리하지 않습니다.
5장. 보안 고려 사항
5.1. FIPS-140-2
연방 정보 처리 표준 (FIPS-140-2)은 암호화 모듈 사용에 대한 일련의 보안 요구 사항을 정의하는 표준입니다. 법률은 미국 정부 기관 및 계약자에 이러한 표준을 규정하고 다른 국제 및 산업별 표준에서도 참조됩니다.
Red Hat OpenShift Data Foundation은 이제 FIPS 검증 암호화 모듈을 사용합니다. RHCOS(Red Hat Enterprise Linux OS/CoreOS)는 이러한 모듈을 제공합니다.
현재 CMVP(Module Validation Program)는 암호화 모듈을 처리합니다. 이러한 모듈의 상태는 프로세스 목록의 모듈 ( Modules in Process List )에서 확인할 수 있습니다. 최신 정보는 Red Hat Knowledgebase 솔루션 RHEL 핵심 암호화 구성 요소를 참조하십시오.
OpenShift Data Foundation을 설치하기 전에 OpenShift Container Platform에서 FIPS 모드를 활성화합니다. 이 기능이 Red Hat Enterprise Linux 7 (RHEL 7)에서 OpenShift Data Foundation 배포를 지원하지 않으므로 OpenShift Container Platform은 RHCOS 노드에서 실행해야 합니다.
자세한 내용은 FIPS 모드에서 클러스터 설치 및 OpenShift Container Platform 설명서의 설치 가이드 의 FIPS 암호화 지원을 참조하십시오.
5.2. 프록시 환경
프록시 환경은 인터넷에 대한 직접 액세스를 거부하고 대신 사용 가능한 HTTP 또는 HTTPS 프록시를 제공하는 프로덕션 환경입니다. Red Hat Openshift Container Platform은 기존 클러스터의 프록시 오브젝트를 수정하거나 새 클러스터의 install-config.yaml 파일에서 프록시 설정을 구성하여 프록시를 사용하도록 구성됩니다.
Red Hat은 클러스터 전체 프록시 구성에 따라 OpenShift Container Platform이 구성된 경우 프록시 환경에서 OpenShift Data Foundation의 배포를 지원합니다.
5.3. 데이터 암호화 옵션
암호화를 사용하면 필요한 암호화 키 없이 데이터를 읽을 수 없도록 데이터를 인코딩할 수 있습니다. 이 메커니즘은 물리적 보안 위반이 발생할 경우 데이터의 기밀성을 보호하여 물리적 미디어로 인해 추적을 피할 수 있습니다. PV별 암호화는 동일한 OpenShift Container Platform 클러스터 내부의 다른 네임스페이스에서 액세스를 보호합니다. 데이터는 디스크에 쓸 때 암호화되고 디스크에서 읽힐 때 암호 해독됩니다. 암호화된 데이터 작업으로 인해 성능이 저하될 수 있습니다.
Red Hat OpenShift Data Foundation 4.6 이상을 사용하여 배포된 새 클러스터에서만 암호화가 지원됩니다. 외부 KMS(Key Management System)를 사용하지 않는 기존 암호화된 클러스터는 외부 KMS를 사용하도록 마이그레이션할 수 없습니다.
이전에는 HashiCorp Vault가 클러스터 전체 및 영구 볼륨 암호화에 지원되는 유일한 KMS였습니다. OpenShift Data Foundation 4.7.0 및 4.7.1에서는 KV(HashiCorp Vault Key/Value) 시크릿 엔진 API만 버전 1이 지원됩니다. OpenShift Data Foundation 4.7.2부터 HashiCorp Vault KV 시크릿 엔진 API, 버전 1 및 2가 지원됩니다. OpenShift Data Foundation 4.12부터 Thales CipherTrust Manager가 추가로 지원되는 KMS로 도입되었습니다.
- KMS는 StorageClass 암호화에 필요하며 클러스터 전체 암호화의 경우 선택 사항입니다.
- 먼저 스토리지 클래스 암호화에는 유효한 Red Hat OpenShift Data Foundation Advanced 서브스크립션이 필요합니다. 자세한 내용은 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
Red Hat은 기술 파트너와 협력하여 이 문서를 고객에게 서비스로 제공합니다. 그러나 Red Hat은 Hashicorp 제품에 대한 지원을 제공하지 않습니다. 이 제품에 대한 기술 지원을 받으려면 Hashicorp 에 문의하십시오.
5.3.1. 클러스터 전체 암호화
Red Hat OpenShift Data Foundation은 스토리지 클러스터의 모든 디스크 및 Multicloud Object Gateway 작업에 대해 클러스터 전체 암호화(암호화-at-rest)를 지원합니다. OpenShift Data Foundation은 키 크기가 512비트이고 각 장치에 다른 암호화 키가 있는 aes-xts-plain64 암호를 사용하는 Linux Unified Key System(LUKS) 버전 2 기반 암호화를 사용합니다. 키는 Kubernetes 시크릿 또는 외부 KMS를 사용하여 저장됩니다. 두 방법 모두 함께 사용할 수 없으며 방법 간에 마이그레이션할 수 없습니다.
블록 및 파일 스토리지에 대해 기본적으로 암호화가 비활성화됩니다. 배포 시 클러스터에 대한 암호화를 활성화할 수 있습니다. MultiCloud Object Gateway는 기본적으로 암호화를 지원합니다. 자세한 내용은 배포 가이드를 참조하십시오.
클러스터 전체 암호화는 KMS(Key Management System) 없이 OpenShift Data Foundation 4.6에서 지원됩니다. OpenShift Data Foundation 4.7부터는 HashiCorp Vault KMS를 포함하거나 포함하지 않고 지원합니다. OpenShift Data Foundation 4.12부터는 HashiCorp Vault KMS 및 Thales CipherTrust Manager KMS를 모두 포함하거나 사용하지 않고 지원합니다.
유효한 Red Hat OpenShift Data Foundation Advanced 서브스크립션이 필요합니다. OpenShift Data Foundation 서브스크립션의 작동 방식을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
HashiCorp Vault KMS를 사용한 클러스터 전체 암호화는 다음 두 가지 인증 방법을 제공합니다.
- token: 이 방법은 자격 증명 모음 토큰을 사용한 인증을 허용합니다. 자격 증명 모음 토큰을 포함하는 kubernetes 시크릿은 openshift-storage 네임스페이스에서 생성되며 인증에 사용됩니다. 이 인증 방법을 선택하면 관리자는 암호화 키가 저장되는 Vault의 백엔드 경로에 대한 액세스를 제공하는 자격 증명 모음 토큰을 제공해야 합니다.
Kubernetes: 이 방법은 serviceaccounts를 사용하여 자격 증명 모음 인증을 허용합니다. 이 인증 방법을 선택하면 관리자는 암호화 키가 저장된 백엔드 경로에 대한 액세스를 제공하는 Vault에 구성된 역할의 이름을 제공해야 합니다. 그런 다음 이 역할의 값이
ocs-kms-connection-details구성 맵에 추가됩니다. 이 방법은 OpenShift Data Foundation 4.10에서 사용할 수 있습니다.현재 HashiCorp Vault는 지원되는 유일한 KMS입니다. OpenShift Data Foundation 4.7.0 및 4.7.1을 사용하면 HashiCorp Vault KV 시크릿 엔진만 API 버전 1이 지원됩니다. OpenShift Data Foundation 4.7.2부터 HashiCorp Vault KV 시크릿 엔진 API, 버전 1 및 2가 지원됩니다.
IBM Cloud 플랫폼의 OpenShift Data Foundation은 HashiCorp Vault KMS 외에 암호화 솔루션으로서 HPCS(Hyper Protect IRQ Services) KMS를 지원합니다.
Red Hat은 기술 파트너와 협력하여 이 문서를 고객에게 서비스로 제공합니다. 그러나 Red Hat은 Hashicorp 제품에 대한 지원을 제공하지 않습니다. 이 제품에 대한 기술 지원을 받으려면 Hashicorp 에 문의하십시오.
5.3.2. 스토리지 클래스 암호화
외부 Key Management System(KMS)을 사용하여 스토리지 클래스 암호화로 영구 볼륨(블록만 해당)을 암호화하여 장치 암호화 키를 저장할 수 있습니다. 영구 볼륨 암호화는 RADOS 블록 장치(RBD) 영구 볼륨에서만 사용할 수 있습니다. 영구 볼륨 암호화를 사용하여 스토리지 클래스를 생성하는 방법을 참조하십시오.
스토리지 클래스 암호화는 OpenShift Data Foundation 4.7 이상에서 HashiCorp Vault KMS에서 지원됩니다. 스토리지 클래스 암호화는 HashiCorp Vault KMS 및 Thales CipherTrust Manager KMS에서 OpenShift Data Foundation 4.12 이상에서 지원됩니다.
유효한 Red Hat OpenShift Data Foundation Advanced 서브스크립션이 필요합니다. OpenShift Data Foundation 서브스크립션의 작동 방식을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
5.3.3. CipherTrust 관리자
Red Hat OpenShift Data Foundation 버전 4.12에는 Thales CipherTrust Manager가 배포를 위해 추가 KMS(Key Management System) 공급자로 도입되었습니다. Thales CipherTrust Manager는 중앙 집중식 키 라이프사이클 관리를 제공합니다. CipherTrust Manager는 키 관리 시스템 간의 통신을 가능하게 하는 KMIP(Key Management Interoperability Protocol)를 지원합니다.
배포 중에 CipherTrust Manager가 활성화되어 있습니다.
5.3.4. Red Hat Ceph Storage의 메시징 버전 2 프로토콜을 통해 전송되는 데이터 암호화
OpenShift Data Foundation 버전 4.13부터 Red Hat Ceph Storage의 메시징 버전 2 프로토콜을 사용하여 전송 내 데이터를 암호화할 수 있습니다. 이는 인프라에 중요한 보안 요구 사항을 제공합니다. 배포 중에 전송 내 암호화를 활성화할 수 있습니다.
5.4. Transit의 암호화
OVN-Kubernetes CNI(Container Network Interface) 클러스터 네트워크의 노드 간 모든 네트워크 트래픽이 암호화된 터널을 통과하도록 IPsec을 활성화해야 합니다.
기본적으로 IPsec은 비활성화되어 있습니다. 클러스터 설치 중 또는 설치 후 이를 활성화할 수 있습니다. 클러스터를 설치한 후 IPsec을 활성화해야 하는 경우 IPsec ESP IP 헤더의 오버헤드를 고려하여 먼저 클러스터 MTU의 크기를 조정해야 합니다.
IPsec 암호화를 구성하는 방법에 대한 자세한 내용은 OpenShift Container Platform 설명서의 네트워킹 암호화 구성을 참조하십시오.
6장. 서브스크립션
6.1. 서브스크립션 제품
Red Hat OpenShift Data Foundation 서브스크립션은 Red Hat OpenShift Container Platform과 유사한 "코어 쌍"을 기반으로 합니다. Red Hat OpenShift Data Foundation 2-core 서브스크립션은 OpenShift Container Platform이 실행되는 시스템의 CPU에 대한 논리 코어 수를 기반으로 합니다.
OpenShift Container Platform과 마찬가지로
- OpenShift Data Foundation 서브스크립션은 대규모 호스트를 지원하기 위해 누적할 수 있습니다.
- 필요에 따라 코어를 여러 VM(가상 머신)에 배포할 수 있습니다. 예를 들어, 10개의 2코어 서브스크립션은 20개의 코어를 제공하며, IBM Power의 경우 SMT 수준 8의 2코어 서브스크립션의 경우 여러 VM에서 사용할 수 있는 2개의 코어 또는 16개의 vCPU를 제공합니다.
- OpenShift Data Foundation 서브스크립션은 Premium 또는 Standard 지원을 통해 사용할 수 있습니다.
6.2. 재해 복구 서브스크립션 요구 사항
Red Hat OpenShift Data Foundation에서 지원하는 재해 복구 기능을 사용하려면 재해 복구 솔루션을 성공적으로 구현하기 위해 다음과 같은 사전 요구 사항이 모두 필요합니다.
- 유효한 Red Hat OpenShift Data Foundation Advanced 인타이틀먼트
- 유효한 Red Hat Advanced Cluster Management for Kubernetes 서브스크립션
소스 또는 대상으로 활성 복제에 참여하는 PV가 포함된 Red Hat OpenShift Data Foundation 클러스터에는 OpenShift Data Foundation Advanced 인타이틀먼트가 필요합니다. 이 서브스크립션은 소스 클러스터와 대상 클러스터에서 모두 활성화되어야 합니다.
OpenShift Data Foundation 서브스크립션의 작동 방식을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
6.3. 코어 대 vCPU 및 하이퍼 스레딩
특정 시스템이 하나 이상의 코어를 사용하는지 여부를 결정하는 것은 현재 해당 시스템에 하이퍼 스레딩을 사용할 수 있는지 여부에 따라 달라집니다. 하이퍼 스레딩은 Intel CPU의 기능일 뿐입니다. Red Hat 고객 포털을 방문하여 특정 시스템이 하이퍼 스레딩을 지원하는지 여부를 확인합니다.
하이퍼 스레딩이 활성화되어 있고 하이퍼스레딩이 하나의 눈에 보이는 시스템 코어와 작동하는 시스템의 경우 코어 계산은 코어 2개 코어에서 4개의 vCPU의 비율입니다. 따라서 2코어 서브스크립션은 하이퍼스레드 시스템에서 4개의 vCPU를 지원합니다. 대규모 VM(가상 머신)에는 4개의 서브스크립션 코어와 같은 8개의 vCPU가 있을 수 있습니다. 서브스크립션이 2코어 단위로 제공되면 이 4개 코어 또는 8개의 vCPU를 포함하려면 2코어 서브스크립션이 필요합니다.
하이퍼 스레딩이 활성화되지 않은 상태에서 볼 수 있는 각 시스템 코어가 기본 물리적 코어와 직접 연결되어 있는 경우 코어 계산은 코어 2개 코어에서 2개의 vCPU의 비율입니다.
6.3.1. IBM Power의 코어 대 vCPU 및 동시 멀티 스레딩(SMT)
특정 시스템이 하나 이상의 코어를 사용하는지 여부를 결정하는 것은 현재 SMT(동시 멀티 스레딩) 수준에 따라 달라집니다. IBM Power는 아래 표와 같이 vCPU 수에 해당하는 각 코어에 대해 1, 2, 4 또는 8의 동시 멀티스레딩 수준을 제공합니다.
| SMT 수준 | SMT=1 | SMT=2 | SMT=4 | SMT=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 수준 1의 2개 vCPU와 SMT 수준 4개, 위의 표에 표시된 대로 SMT 수준 8개 vCPU에서 최대 8개의 vCPU에 해당합니다. 대규모 가상 머신(VM)에는 16개의 vCPU가 있을 수 있으며, SMT 수준 8에서는 vCPU #을 SMT 수준 16개(SMT-8 = 2의 경우 16 vCPU/8)로 분할하는 데 따라 2개의 코어 서브스크립션이 필요합니다. 서브스크립션이 2코어 단위로 제공되면 2코어 또는 16개의 vCPU를 처리하기 위해 하나의 2코어 서브스크립션이 필요합니다.
6.4. 코어 분할
홀수의 코어가 필요한 시스템은 전체 2코어 서브스크립션을 사용해야 합니다. 예를 들어, 1개의 코어만 요구하도록 계산된 시스템은 등록 및 서브스크립션된 후 전체 2코어 서브스크립션을 사용하게 됩니다.
vCPU가 2개인 단일 가상 머신(VM)에서 하이퍼 스레딩을 사용하는 경우 전체 2코어 서브스크립션이 필요합니다. 하이퍼 스레딩을 사용하여 2개의 vCPU로 단일 2코어 서브스크립션을 분할하지 못할 수 있습니다. 자세한 내용은 섹션 코어 대 vCPU 및 하이퍼 스레딩 을 참조하십시오.
짝수의 코어가 필요하므로 가상 인스턴스의 크기를 조정하는 것이 좋습니다.
6.5. 서브스크립션 요구사항
Red Hat OpenShift Data Foundation 구성 요소는 OpenShift Container Platform 작업자 또는 인프라 노드에서 실행할 수 있으며, 이 노드는 RHCOS(Red Hat CoreOS) 또는 RHEL(Red Hat Enterprise Linux) 8.4를 호스트 운영 체제로 사용할 수 있습니다. RHEL 7은 더 이상 사용되지 않습니다. OpenShift Data Foundation 서브스크립션은 모든 OpenShift Container Platform 서브스크립션 코어에 1 : 1의 비율로 필요합니다.
인프라 노드를 사용하는 경우 OpenShift Data Foundation의 모든 OpenShift 작업자 노드 코어를 서브스크립션하는 규칙은 OpenShift Container Platform 또는 OpenShift Data Foundation 서브스크립션이 필요하지 않은 경우에도 적용됩니다. 라벨을 사용하여 노드가 작업자인지 인프라 노드인지 여부를 확인할 수 있습니다.
자세한 내용은 스토리지 리소스 관리 및 할당 가이드의 Red Hat OpenShift Data Foundation 전용 작업자 노드를 사용하는 방법을 참조하십시오.
7장. 인프라 요구 사항
7.1. 플랫폼 요구 사항
Red Hat OpenShift Data Foundation 4.13은 OpenShift Container Platform 버전 4.13 및 다음 마이너 버전에서만 지원됩니다.
이전 버전의 Red Hat OpenShift Data Foundation에 대한 버그 수정은 버그 수정 버전으로 릴리스됩니다. 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.
외부 클러스터 서브스크립션 요구 사항은 Red Hat 지식베이스 문서 OpenShift Data Foundation 서브스크립션 가이드를 참조하십시오.
지원되는 플랫폼 버전의 전체 목록은 Red Hat OpenShift Data Foundation Supportability 및 Interoperability Checker 에서 참조하십시오.
7.1.1. Amazon EC2
내부 Red Hat OpenShift Data Foundation 클러스터만 지원합니다.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 aws-ebs 프로비전 프로그램을 통해 EBS 스토리지인 스토리지 클래스가 있어야 합니다.
OpenShift Data Foundation은 AWS(Amazon Web Services)에서 도입한 gp2-csi 및 gp3-csi 드라이버를 지원합니다. 이러한 드라이버는 향상된 스토리지 확장 기능과 월간 가격 감소 (gp3-csi)를 제공합니다. 이제 스토리지 클래스를 선택할 때 새 드라이버를 선택할 수 있습니다. 처리량이 높은 경우, OpenShift Data Foundation을 배포할 때 gp3-csi 를 사용하는 것이 좋습니다.
7.1.2. Bare Metal
내부 클러스터 및 외부 클러스터 소비를 지원합니다.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.
7.1.3. VMware vSphere
내부 클러스터 및 외부 클러스터 소비를 지원합니다.
권장 버전:
- vSphere 6.7, Update 2 이상
- vSphere 7.0 이상.
자세한 내용은 VMware vSphere 인프라 요구 사항을 참조하십시오.
VMware ESXi에서 장치를 Flash로 인식하지 못하는 경우 장치를 플래쉬 장치로 표시합니다. Red Hat OpenShift Data Foundation 배포 전에 Mark Storage Devices를 Flash로 참조하십시오.
또한 내부 클러스터는, 스토리지 장치 요구 사항을 모두 충족해야 하며 다음 중 하나를 제공하는 스토리지 클래스가 있어야 합니다.
- vsphere-volume 프로비전 프로그램을 통한 vSAN 또는 VMFS 데이터 저장소
- Local Storage Operator를 통해 VMDK, RDM 또는 DirectPath 스토리지 장치
7.1.4. Microsoft Azure
내부 Red Hat OpenShift Data Foundation 클러스터만 지원합니다.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족해야 하며 azure-disk 프로비전 프로그램을 통해 azure 디스크를 제공하는 스토리지 클래스가 있어야 합니다.
7.1.5. Google Cloud [기술 프리뷰]
내부 Red Hat OpenShift Data Foundation 클러스터만 지원합니다.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 gce-pd 프로비전 프로그램을 통해 GCE 영구 디스크인 스토리지 클래스가 있어야 합니다.
7.1.6. Red Hat Virtualization Platform
내부 Red Hat OpenShift Data Foundation 클러스터만 지원합니다.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.
7.1.7. Red Hat OpenStack Platform [Technology Preview]
내부 Red Hat OpenShift Data Foundation 클러스터 지원 및 외부 클러스터 소비.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 Cinder 프로비저너를 통해 표준 디스크를 제공하는 스토리지 클래스가 있어야 합니다.
7.1.8. IBM Power
내부 Red Hat OpenShift Data Foundation 클러스터 지원 및 외부 클러스터 소비.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.
7.1.9. IBM Z 및 IBM® LinuxONE
내부 Red Hat OpenShift Data Foundation 클러스터 지원 또한 Red Hat Ceph Storage가 x86에서 실행되는 외부 모드를 지원합니다.
내부 클러스터는 스토리지 장치 요구 사항을 모두 충족하고 Local Storage Operator를 통해 로컬 SSD(NVMe/SATA/SAS, SAN)를 제공하는 스토리지 클래스가 있어야 합니다.
7.2. 외부 모드 요구 사항
7.2.1. Red Hat Ceph Storage
Red Hat Ceph Storage(RHCS)의 외부 모드에서 Red Hat OpenShift Data Foundation의 지원 가능성 및 상호 운용성을 확인하려면 Red Hat OpenShift Data Foundation 지원 및 상호 운용성 검사 랩으로 이동하십시오.
-
자체 관리 서비스로 ODF로 서비스 유형을선택합니다. - 드롭다운 에서 적절한 버전을 선택합니다.
- 버전 탭에서 지원되는 RHCS 호환성 탭을 클릭합니다.
RHCS 클러스터 설치 방법에 대한 자세한 내용은 설치 가이드를 참조하십시오.
7.2.2. IBM FlashSystem
IBM FlashSystem을 다른 공급자의 플러그형 외부 스토리지로 사용하려면 먼저 설치해야 IBM FlashSystem 스토리지 클래스를 백업 스토리지로 사용하는 OpenShift Data Foundation을 배포할 수 있습니다.
지원되는 최신 FlashSystem 스토리지 시스템 및 버전은 ODF FlashSystem 드라이버 설명서를 참조하십시오.
OpenShift Data Foundation 배포 방법에 대한 자세한 내용은 IBM FlashSystem 스토리지용 OpenShift Data Foundation 클러스터 생성을 참조하십시오.
7.3. 리소스 요구사항
Red Hat OpenShift Data Foundation 서비스는 초기 기본 서비스 세트로 구성되며 추가 장치 세트를 통해 확장할 수 있습니다. 이러한 Red Hat OpenShift Data Foundation 서비스 Pod는 모두 OpenShift Container Platform 노드의 kubernetes에 의해 예약됩니다. 각 장애 도메인에서 하나의 노드로 구성된 3개의 노드로 클러스터를 확장하는 것은 Pod 배치 규칙을 충족하기 쉽게 수행할 수 있는 방법입니다.
이러한 요구 사항은 해당 노드에서 실행 중인 다른 서비스, 운영자 또는 워크로드에만 관련이 없습니다.
| 배포 모드 | 기본 서비스 | 추가 장치 세트 |
|---|---|---|
| 내부 |
|
|
| 외부 |
| 해당 없음 |
예: 단일 장치 세트가 있는 내부 모드 배포의 경우 최소 3 x 10 = 30 단위의 CPU가 필요합니다.
자세한 내용은 6장. 서브스크립션 및 CPU 단위를 참조하십시오.
Red Hat OpenShift Data Foundation 클러스터 설계에 대한 추가 지침은 ODF Sizing Tool 을 참조하십시오.
CPU 단위
이 섹션에서는 하나의 CPU 장치가 하나의 CPU 단위의 Kubernetes 개념에 매핑됩니다.
- CPU의 1 단위는 하이퍼스레인 스레드가 아닌 CPU의 경우 1 코어와 동일합니다.
- 하이퍼스레드 CPU의 경우 CPU 2 단위는 1 코어와 동일합니다.
- Red Hat OpenShift Data Foundation 코어 기반 서브스크립션은 항상 쌍(2코어)으로 제공됩니다.
| 배포 모드 | 기본 서비스 |
|---|---|
| 내부 |
|
| 외부 |
|
예: 내부 연결 장치 모드 배포의 3 노드 클러스터의 경우 최소 3 x 16 = 48 단위의 CPU와 3 x 64 = 192GB의 메모리가 필요합니다.
7.3.1. IBM Z 및 IBM LinuxONE 인프라에 대한 리소스 요구 사항
Red Hat OpenShift Data Foundation 서비스는 초기 기본 서비스 세트로 구성되며 추가 장치 세트를 통해 확장할 수 있습니다.
이러한 Red Hat OpenShift Data Foundation 서비스 Pod는 모두 OpenShift Container Platform 노드의 kubernetes에 의해 예약됩니다. 각 장애 도메인에서 하나의 노드로 구성된 3개의 노드로 클러스터를 확장하는 것은 Pod 배치 규칙을 충족하기 쉽게 수행할 수 있는 방법입니다.
| 배포 모드 | 기본 서비스 | 추가 장치 세트 | IBM Z 및 IBM® LinuxONE 최소 하드웨어 요구 사항 |
|---|---|---|---|
| 내부 |
|
| 1 IFL |
| 외부 |
| 해당 없음 | 해당 없음 |
- CPU
- 하이퍼바이저, IBM Z/VM, KVM(커널 가상 시스템) 또는 둘 다에 정의된 가상 코어 수입니다.
- IFL (Integrated Facility for Linux)
- IBM Z 및 IBM® LinuxONE의 물리적 코어입니다.
최소 시스템 환경
- LPAR(Logical partition)로 최소 클러스터를 운영하려면 6개의 IFL 상단에 하나의 추가 IFL이 필요합니다. OpenShift Container Platform에서는 이러한 IFL을 사용합니다.
7.3.2. 최소 배포 리소스 요구사항
표준 배포 리소스 요구 사항이 충족되지 않으면 OpenShift Data Foundation 클러스터는 최소 구성으로 배포됩니다.
이러한 요구 사항은 해당 노드에서 실행 중인 다른 서비스, 운영자 또는 워크로드에만 관련이 없습니다.
| 배포 모드 | 기본 서비스 |
|---|---|
| 내부 |
|
장치 세트를 추가하려면 최소 배포를 표준 배포로 변환하는 것이 좋습니다.
7.3.3. 컴팩트한 배포 리소스 요구사항
Red Hat OpenShift Data Foundation은 세 개의 강력한 마스터 노드에서 모든 워크로드가 실행되는 3-노드 OpenShift 컴팩트 베어 메탈 클러스터에 설치할 수 있습니다. 작업자 또는 스토리지 노드가 없습니다.
이러한 요구 사항은 해당 노드에서 실행 중인 다른 서비스, 운영자 또는 워크로드에만 관련이 없습니다.
| 배포 모드 | 기본 서비스 | 추가 장치 세트 |
|---|---|---|
| 내부 |
|
|
컴팩트한 베어 메탈 클러스터에 OpenShift Container Platform을 구성하려면 3-노드 클러스터 구성 및 에지 배포를 위한 3-노드 아키텍처 제공 을 참조하십시오.
7.3.4. MCG만 배포에 대한 리소스 요구 사항
MCG(Multicloud Object Gateway) 구성 요소로만 배포된 OpenShift Data Foundation 클러스터는 배포의 유연성을 제공하며 리소스 사용을 줄이는 데 도움이 됩니다.
| 배포 모드 | 코어 | 데이터베이스(DB) | endpoint |
|---|---|---|---|
| 내부 |
|
|
참고 지연된 자동 스케일은 1에서 2 사이입니다. |
7.3.5. 네트워크 파일 시스템 사용을 위한 리소스 요구 사항
Red Hat OpenShift Data Foundation 버전 4.13이 릴리스되면 OpenShift 클러스터에서 외부에서 액세스할 수 있는 NFS(Network File System)를 사용하여 내보내기를 생성할 수 있습니다. 이 기능을 사용하려는 경우 NFS 서비스는 3 개의 CPU와 Ram의 8Gi를 사용합니다. NFS는 선택 사항이며 기본적으로 비활성화되어 있습니다.
NFS 볼륨은 다음 두 가지 방법으로 액세스할 수 있습니다.
- in-cluster: Openshift 클러스터 내부의 애플리케이션 포드별.
- 클러스터 없음: Openshift 클러스터 외부에서.
NFS 기능에 대한 자세한 내용은 NFS를 사용하여 내보내기 생성을참조하십시오.
7.4. Pod 배치 규칙
Kubernetes는 선언적 배치 규칙을 기반으로 Pod 배치를 담당합니다. 내부 클러스터에 대한 Red Hat OpenShift Data Foundation 기본 서비스 배치 규칙은 다음과 같이 요약할 수 있습니다.
-
노드는
cluster.ocs.openshift.io/openshift-storage키로 레이블이 지정됩니다. - 노드가 존재하지 않는 경우 의사 실패 도메인으로 정렬됩니다.
- 고가용성이 필요한 구성 요소가 장애 도메인에 분산됨
- 각 장애 도메인에서 스토리지 장치에 액세스할 수 있어야 합니다.
이로 인해 노드가 3개 이상 있고 기존 토폴로지 라벨 의 경우 3개의 개별 랙 또는 영역 장애 도메인에 노드가 있어야 합니다.
추가 장치 세트의 경우 세 개의 장애 도메인마다 사용하는 Pod에 대한 스토리지 장치 및 충분한 리소스가 있어야 합니다. 수동 배치 규칙은 기본 배치 규칙을 재정의하는 데 사용할 수 있지만 일반적으로 이 방법은 베어 메탈 배포에만 적합합니다.
7.5. 스토리지 장치 요구 사항
이 섹션을 사용하여 내부 모드 배포 및 업그레이드를 계획할 때 고려할 수 있는 다양한 스토리지 용량 요구 사항을 파악할 수 있습니다. 일반적으로 노드당 9 개의 장치 또는 적은 것을 권장합니다. 이 권장 사항은 노드를 클라우드 공급자 동적 스토리지 장치 연결 제한 미만으로 유지하고 로컬 스토리지 장치에서 노드 장애 발생 후 복구 시간을 제한하는 것이 좋습니다. 각 장애 도메인에서 하나의 노드로 구성된 3개의 노드로 클러스터를 확장하는 것은 Pod 배치 규칙을 충족하기 쉽게 수행할 수 있는 방법입니다.
스토리지 노드에는 운영 체제용 디스크와 OpenShift Data Foundation 구성 요소의 나머지 디스크용 디스크가 두 개 이상 있어야 합니다.
설치 시 선택한 용량 증가에서만 스토리지 용량을 확장할 수 있습니다.
7.5.1. 동적 스토리지 장치
Red Hat OpenShift Data Foundation은 0.5 TiB, 2TiB 또는 4TB 용량을 동적 스토리지 장치 크기에 대한 요청 크기로 선택할 수 있습니다. 노드당 실행할 수 있는 동적 스토리지 장치의 수는 노드 크기, 기본 프로비저너 제한 및 리소스 요구 사항 의 기능입니다.
7.5.2. 로컬 스토리지 장치
로컬 스토리지 배포의 경우 4TTiB 이하의 디스크 크기를 사용할 수 있으며 모든 디스크를 동일한 크기와 유형이어야 합니다. 노드당 실행할 수 있는 로컬 스토리지 장치의 수는 노드 크기 및 리소스 요구 사항 의 기능입니다. 각 장애 도메인에서 하나의 노드로 구성된 3개의 노드로 클러스터를 확장하는 것은 Pod 배치 규칙을 충족하기 쉽게 수행할 수 있는 방법입니다.
디스크 파티션은 지원되지 않습니다.
7.5.3. 용량 계획
항상 사용 가능한 스토리지 용량이 소비보다 먼저 유지되도록 해야 합니다. 사용 가능한 스토리지 용량이 완전히 소모되면 복구하기 어렵고 간단히 용량을 추가하거나 콘텐츠를 삭제하거나 마이그레이션하는 것보다 더 많은 개입이 필요합니다.
클러스터 스토리지 용량이 75% (near-full)에 도달하면 용량 경고가 발행되고 총 용량의 85%(완전)가 발생합니다. 항상 용량 경고를 신속하게 해결하고 스토리지를 정기적으로 검토하여 스토리지 공간이 부족하지 않도록 합니다. 75%(near-full)에 도달하면 공간을 확보하거나 클러스터를 확장합니다. 85%(완전) 경고가 표시되면 스토리지 공간이 완전히 부족하여 표준 명령을 사용하여 공간을 확보할 수 없음을 나타냅니다. 이 시점에서 Red Hat 고객 지원에 문의하십시오.
다음 표는 동적 스토리지 장치가 있는 Red Hat OpenShift Data Foundation의 노드 구성 예를 보여줍니다.
| 스토리지 장치 크기 | 노드당 스토리지 장치 | 총 용량 | 사용 가능한 스토리지 용량 |
|---|---|---|---|
| 0.5 TiB | 1 | 1.5 TiB | 0.5 TiB |
| 2 TiB | 1 | 6 TiB | 2 TiB |
| 4 TiB | 1 | 12 TiB | 4 TiB |
| 스토리지 장치 크기(D) | 노드당 스토리지 장치 (M) | 총 용량 (D * M * N) | 사용 가능한 스토리지 용량(D*M*N/3) |
|---|---|---|---|
| 0.5 TiB | 3 | 45 TiB | 15 TiB |
| 2 TiB | 6 | 360 TiB | 120 TiB |
| 4 TiB | 9 | 1080 TiB | 360 TiB |
8장. 네트워크 요구 사항
이 섹션을 사용하여 배포를 계획할 때 다양한 네트워크 고려 사항을 파악할 수 있습니다.
8.1. IPv6 지원
Red Hat OpenShift Data Foundation 버전 4.12에는 IPv6 지원이 도입되었습니다. IPv6는 단일 스택에서만 지원되며 IPv4에서는 동시에 사용할 수 없습니다. Openshift Container Platform에서 IPv6를 사용하도록 설정한 경우 IPv6는 OpenShift Data Foundation의 기본 동작입니다.
Red Hat OpenShift Data Foundation IPv4를 사용한 OpenShift Container Platform 듀얼 스택은 버전 4.13 이상에서 지원됩니다. Red Hat OpenShift Data Foundation IPv6의 듀얼 스택은 지원되지 않습니다.
8.2. 다중 네트워크 플러그인(Multus) 지원 [기술 프리뷰]
OpenShift Data Foundation은 베어 메탈 인프라에서 다중 네트워크 플러그인을 사용하여 다양한 유형의 네트워크 트래픽을 격리하여 보안 및 성능을 개선할 수 있는 기능을 지원합니다. Multus를 사용하면 호스트의 하나 이상의 네트워크 인터페이스를 OpenShift Data Foundation을 독점적으로 사용하도록 예약할 수 있습니다.
Multus 지원은 베어 메탈 배포에서만 지원 및 테스트된 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Multus를 사용하려면 먼저 Multus 사전 요구 사항 검증 툴을 실행합니다. 툴 사용 지침은 OpenShift Data Foundation - Multus 사전 요구 사항 검증 툴 을 참조하십시오. Multus 네트워크에 대한 자세한 내용은 여러 네트워크를참조하십시오.
8.2.1. Multus를 사용하여 스토리지 트래픽 분리
기본적으로 Red Hat OpenShift Data Foundation은 Red Hat OpenShift Software Defined Network(SDN)를 사용하도록 구성되어 있습니다. 기본 SDN은 다음과 같은 유형의 트래픽을 전달합니다.
- pod-to-pod 트래픽
- 스토리지가 OpenShift Data Foundation인 경우 공용 네트워크 트래픽이라고 하는 pod-to-storage 트래픽
- OpenShift Data Foundation 내부 복제 및 클러스터 네트워크 트래픽이라는 트래픽 재조정
OpenShift Data Foundation을 OpenShift 기본 네트워크에서 분리하는 방법은 다음 세 가지가 있습니다.
OpenShift Data Foundation의 공용 네트워크에 대해 호스트에 네트워크 인터페이스 예약
- pod-to-storage 및 내부 스토리지 복제 트래픽은 pod-to-pod 네트워크 트래픽과 분리된 네트워크에서 공존합니다.
- OpenShift Data Foundation 클러스터가 정상이면 애플리케이션 pod는 최대 공용 네트워크 스토리지 대역폭에 액세스할 수 있습니다.
- OpenShift Data Foundation 클러스터가 장애에서 복구되면 지속적인 복제 및 트래픽 재조정으로 인해 애플리케이션 pod가 대역폭을 줄일 수 있습니다.
OpenShift Data Foundation의 클러스터 네트워크의 호스트에 네트워크 인터페이스 예약
- pod-to-pod 및 pod-to-storage 트래픽 모두 OpenShift의 기본 네트워크를 계속 사용합니다.
- pod-to-storage 대역폭은 OpenShift Data Foundation 클러스터의 상태에 의해 덜 영향을 받습니다.
- 사용 중인 OpenShift 클러스터에서 pod-to-pod 및 pod-to-storage OpenShift Data Foundation 트래픽이 네트워크 대역폭에 적합할 수 있습니다.
- 스토리지 내부 네트워크에는 장애 발생 시 사용하도록 예약된 사용되지 않는 대역폭이 초과되는 경우가 많습니다.
OpenShift Data Foundation의 호스트에 두 개의 네트워크 인터페이스 예약: 하나는 공용 네트워크용이고 다른 하나는 클러스터 네트워크용입니다.
- pod-to-pod, pod-to-storage, 스토리지 내부 트래픽은 모두 분리되어 있으며 트래픽 유형은 리소스에 적합하지 않습니다.
- 모든 트래픽 유형에 대한 서비스 수준 계약을 보다 보장할 수 있습니다.
- 정상 런타임 중에 더 많은 네트워크 대역폭이 예약되지만 세 네트워크 모두에서 사용되지 않습니다.
듀얼 네트워크 인터페이스의 구성 스키마 예:
Triple 네트워크 인터페이스 가득 차 있는 구성 스키마 예제:
8.2.2. Multus 사용 시기
다음이 필요할 때 OpenShift Data Foundation에 Multus를 사용합니다.
개선된 대기 시간 - ODF를 사용한 Multus는 항상 대기 시간을 향상시킵니다. 거의 호스트 네트워크 속도로 호스트 인터페이스를 사용하고 OpenShift의 소프트웨어 정의 포드 네트워크를 바이패스합니다. 각 인터페이스에 대해 인터페이스 수준 튜닝당 Linux를 수행할 수도 있습니다.
대역폭 개선 - OpenShift Data Foundation 클라이언트 데이터 트래픽 및 내부 데이터 트래픽을 위한 전용 인터페이스입니다. 이러한 전용 인터페이스는 전체 대역폭을 예약합니다.
향상된 보안 - Multus는 보안 향상을 위해 스토리지 네트워크 트래픽을 애플리케이션 네트워크 트래픽과 분리합니다. 네트워크가 인터페이스를 공유할 때 대역폭 또는 성능은 분리되지 않을 수 있지만 QoS 또는 트래픽 셰이핑을 사용하여 공유 인터페이스의 대역폭 우선 순위를 지정할 수 있습니다.
8.2.3. Multus 구성
Multus를 사용하려면 나중에 클러스터에 연결된 OpenShift Data Foundation 클러스터를 배포하기 전에 네트워크 연결 정의(NAD)를 생성해야 합니다. 자세한 내용은 네트워크 연결 정의 생성 을 참조하십시오.
Pod에 추가 네트워크 인터페이스를 연결하려면 인터페이스 연결 방법을 정의하는 구성을 생성해야 합니다. NetworkAttachmentDefinition CR(사용자 정의 리소스)을 사용하여 각 인터페이스를 지정합니다. 각 CR 내부의 CNI(Container Network Interface) 구성은 해당 인터페이스의 생성 방법을 정의합니다.
OpenShift Data Foundation은 다음 두 가지 유형의 드라이버를 지원합니다. 다음 표에서는 드라이버 및 해당 기능에 대해 설명합니다.
|
|
|
| 각 연결은 자체 MAC 주소가 있는 상위 인터페이스의 하위 인터페이스를 가져오고 호스트 네트워크에서 격리됩니다. | 각 연결은 자체 IP 주소를 가져오고 동일한 MAC 주소를 공유합니다. |
|
더 적은 CPU를 사용하고 Linux 브리지 또는 |
|
| 거의 항상 브리지 모드가 필요합니다. |
|
| NIC(네트워크 인터페이스 카드)가 하드웨어에서 VLAN(가상 로컬 영역 네트워크)을 지원하는 경우 호스트 가까운 성능. |
NIC가 하드웨어에서 VLAN을 지원하지 않는 경우 |
OpenShift Data Foundation은 다음 두 가지 유형의 IP 주소 관리를 지원합니다.
|
| DHCP |
|
OpenShift/Kubernetes |
|
| 포드에 IP를 제공하는 DHCP 서버가 필요하지 않습니다. | 네트워크 DHCP 서버는 Multus Pod와 동일한 네트워크의 다른 호스트에 동일한 범위를 제공할 수 있습니다. |
DHCP 서버가 있는 경우 Multus configured IPAM이 동일한 범위를 제공하지 않도록 네트워크에서 여러 MAC 주소가 동일한 IP를 가질 수 없도록 합니다.
8.2.4. Multus 구성 요구사항
사전 요구 사항
- 공용 네트워크에 사용되는 인터페이스는 각 OpenShift 스토리지 및 작업자 노드에서 동일한 인터페이스 이름을 사용해야 하며 인터페이스는 모두 동일한 기본 네트워크에 연결되어 있어야 합니다.
- 클러스터 네트워크에 사용되는 인터페이스는 각 OpenShift 스토리지 노드에서 동일한 인터페이스 이름을 사용해야 하며 인터페이스는 모두 동일한 기본 네트워크에 연결되어 있어야 합니다. 클러스터 네트워크 인터페이스는 OpenShift 작업자 노드에 있을 필요가 없습니다.
- 공용 또는 클러스터 네트워크에 사용되는 각 네트워크 인터페이스는 최소 10기가비트 네트워크 속도를 사용할 수 있어야 합니다.
- 각 네트워크에는 별도의 VLAN(가상 로컬 영역 네트워크) 또는 서브넷이 필요합니다.
베어 메탈 에서 Multus 기반 구성을 구성하는 데 필요한 단계는 Multus 네트워크 생성 을 참조하십시오.
9장. Disaster Recovery
재해 복구(DR)는 조직이 중단 또는 재해가 있을 때 비즈니스 크리티컬 기능 또는 정상적인 작업을 복구 및 재개하는 데 도움이 됩니다. OpenShift Data Foundation은 다음 두 가지 범주로 널리 분류되는 상태 저장 앱을 위한 HA(고가용성) 및 DR 솔루션을 제공합니다.
- Metro-DR: 데이터 손실없이 단일 리전 및 교차 데이터 센터 보호
- 확장 클러스터로 재해 복구: 단일 OpenShift Data Foundation 클러스터는 스토리지 인프라에 재해 복구 기능을 제공하기 위해 두 위치 간에 확장됩니다.
- regional-DR: 잠재적 데이터 손실을 최소화하여 지역 간 보호 [기술 프리뷰]
확장 클러스터가 포함된 Red Hat Advanced Cluster Management for Kubernetes 2.8 및 Disaster Recovery의 Red Hat OpenShift Data Foundation Metro-DR 기능은 General Available입니다.
Blocks 및 Files 둘 다에 대한 regional-DR 솔루션은 기술 프리뷰로 제공되며 기술 프리뷰 지원 제한이 적용됩니다.
9.1. Metro-DR
Metropolitan 재해 복구(Metro-DR)는 OpenShift Container Platform 클러스터 전체에서 애플리케이션 및 데이터 이동성을 제공하기 위해 RHACM(Red Hat Advanced Cluster Management for Kubernetes), Red Hat Ceph Storage 및 OpenShift Data Foundation 구성 요소로 구성됩니다.
이번 Metro-DR 솔루션 릴리스는 지리적으로 분산된 사이트 전반에 볼륨 영구 데이터 및 메타데이터 복제를 제공합니다. 퍼블릭 클라우드에서 이러한 문제는 가용 영역 장애로부터 보호하는 것과 유사합니다. Metro-DR은 데이터 손실 없이 데이터 센터를 사용할 수 없는 동안 비즈니스 연속성을 보장합니다. 이 솔루션은 RHACM(Red Hat Advanced Cluster Management) 및 OpenShift Data Foundation Advanced SKUs 및 관련 번들을 사용할 수 있습니다.
사전 요구 사항
Red Hat OpenShift Data Foundation에서 지원하는 재해 복구 기능을 사용하려면 재해 복구 솔루션을 성공적으로 구현하기 위해 다음과 같은 사전 요구 사항이 모두 필요합니다.
- 유효한 Red Hat OpenShift Data Foundation Advanced 인타이틀먼트
- 유효한 Red Hat Advanced Cluster Management for Kubernetes 서브스크립션
OpenShift Data Foundation 서브스크립션의 작동 방식을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
자세한 솔루션 요구 사항은 Metro-DR 요구 사항,Red Hat Ceph Storage의 배포 요구 사항 및 중재자 및 RHACM 요구 사항을 참조하십시오.
9.2. 확장 클러스터를 사용한 재해 복구
이 경우 단일 클러스터가 두 개의 영역으로 확장되고 세 번째 영역이 중재자의 위치로 확장됩니다. 이 기능은 현재 OpenShift Container Platform 온-프레미스 및 동일한 위치에 배포하기 위한 것입니다. 이 솔루션은 여러 데이터 센터를 확장한 배포에는 권장되지 않습니다. 대신 대기 시간이 짧은 여러 데이터 센터에 배포된 데이터 손실 DR 솔루션이 없는 첫 번째 옵션으로 Metro-DR을 고려하십시오.
확장 클러스터 솔루션은 최대 RTT(Round-trip time)가 10ms인 영역 간에 대기 시간이 5ms를 초과하지 않는 배포를 위해 설계되었습니다. 대기 시간 내에 배포하려는 경우 Red Hat 고객 지원에 문의하십시오.
확장 클러스터를 사용하려면 다음을 수행합니다.
다음과 같은 세 영역에 최소 5개의 노드가 있어야 합니다.
- 영역당 두 개의 노드가 각 데이터 센터 영역에 사용되며 하나의 노드가 있는 추가 영역은 중재자 영역에 사용됩니다(주요자가 마스터 노드에 있을 수 있음).
모든 노드는 클러스터 생성 전에 영역 레이블을 사용하여 수동으로 레이블을 지정해야 합니다.
예를 들어 영역에 다음과 같이 레이블이 지정될 수 있습니다.
-
topology.kubernetes.io/zone=arbiter(마스터 또는 작업자 노드) -
topology.kubernetes.io/zone=datacenter1(minimum two worker nodes) -
topology.kubernetes.io/zone=datacenter2(minimum two worker nodes)
-
자세한 내용은 확장 클러스터의 OpenShift Data Foundation 구성을 참조하십시오.
OpenShift Data Foundation 서브스크립션의 작동 방식을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
9.3. regional-DR [기술 프리뷰]
지역 재해 복구(Regional-DR)는 OpenShift Container Platform 클러스터 전체에서 애플리케이션 및 데이터 이동성을 제공하기 위해 RHACM(Red Hat Advanced Cluster Management for Kubernetes) 및 OpenShift Data Foundation 구성 요소로 구성됩니다. 비동기 데이터 복제를 기반으로 구축되므로 잠재적인 데이터 손실이 발생할 수 있지만 광범위한 오류 집합에 대한 보호 기능을 제공합니다.
Red Hat OpenShift Data Foundation은 Ceph에서 제공하는 스토리지 공급자로서 Rook에 의해 관리되고 다음과 같은 기능이 향상되었습니다.
- 미러링을 위해 풀을 활성화합니다.
- RBD 풀에서 이미지를 자동으로 미러링합니다.
- 영구 볼륨 클레임 미러링별로 관리할 csi-addons를 제공합니다.
이번 Regional-DR 릴리스는 다양한 리전 및 데이터 센터에 배포되는 다중 클러스터 구성을 지원합니다. 예를 들어 두 개의 서로 다른 지역 또는 데이터 센터에 있는 두 개의 관리 클러스터에 걸쳐 양방향 복제를 수행할 수 있습니다. 이 솔루션은 RHACM(Red Hat Advanced Cluster Management) 및 OpenShift Data Foundation Advanced SKUs 및 관련 번들을 사용할 수 있습니다.
사전 요구 사항
Red Hat OpenShift Data Foundation에서 지원하는 재해 복구 기능을 사용하려면 재해 복구 솔루션을 성공적으로 구현하기 위해 다음과 같은 사전 요구 사항이 모두 필요합니다.
- 유효한 Red Hat OpenShift Data Foundation Advanced 인타이틀먼트
- 유효한 Red Hat Advanced Cluster Management for Kubernetes 서브스크립션
OpenShift Data Foundation 서브스크립션의 작동 방식을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서를 참조하십시오.
자세한 솔루션 요구 사항은 Regional-DR 요구 사항 및 RHACM 요구 사항을 참조하십시오.
Advanced Cluster Management를 사용하여 Regional-DR용 OpenShift Data Foundation을 구성하는 것은 기술 프리뷰 기능이며 기술 프리뷰 지원 제한의 영향을 받습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
10장. 연결이 끊긴 환경
연결이 끊긴 환경은 OLM(Operator Lifecycle Manager)이 인터넷에 연결해야 하는 기본 Operator Hub 및 이미지 레지스트리에 액세스할 수 없는 네트워크 제한된 환경입니다.
Red Hat은 제한된 네트워크에 OpenShift Container Platform을 설치한 연결이 끊긴 환경에서 OpenShift Data Foundation 배포를 지원합니다.
연결이 끊긴 환경에 OpenShift Data Foundation을 설치하려면 OpenShift Container Platform 설명서의 Operator 가이드의 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.
제한된 네트워크 환경에 OpenShift Data Foundation을 설치할 때 기본적으로 인터넷 연결이 OpenShift Container Platform에서 가정되고 chronyd 가 *.rhel.pool.ntp.org 서버를 사용하도록 구성되어 있기 때문에 사용자 지정 NTP(Network Time Protocol) 구성을 노드에 적용합니다.
자세한 내용은 Red Hat Knowledgebase 솔루션 A newly deployed OCS 4 클러스터 상태가 "Degraded", why? 및 Configuring chrony time service of the Installing guide in OpenShift Container Platform 설명서에서 참조하십시오.
Red Hat OpenShift Data Foundation 버전 4.12에는 연결이 끊긴 환경 배포를 위한 에이전트 기반 설치 프로그램이 도입되었습니다. 에이전트 기반 설치 관리자를 사용하면 연결이 끊긴 설치에 미러 레지스트리를 사용할 수 있습니다. 자세한 내용은 에이전트 기반 설치 관리자를 사용하여 설치 준비를 참조하십시오.
OpenShift Data Foundation에 포함할 패키지
redhat-operator 인덱스 이미지를 정리하는 경우 OpenShift Data Foundation 배포의 다음 패키지 목록을 포함합니다.
-
ocs-operator -
odf-operator -
mcg-operator -
odf-csi-addons-operator -
odr-cluster-operator -
odr-hub-operator 선택 사항:
local-storage-operator로컬 스토리지 배포에만 해당됩니다.
선택사항:
odf-multicluster-orchestrator지역 재해 복구(Regional-DR) 구성만 해당됩니다.
CatalogSource 의 이름을 redhat-operators 로 지정합니다.
11장. IBM Power 및 IBM Z에서 지원되는 기능
| 기능 | IBM Power | IBM Z |
|---|---|---|
| 컴팩트 배포 | 지원되지 않음 | 지원되지 않음 |
| 동적 스토리지 장치 | 지원되지 않음 | 지원됨 |
| 스트레치된 클러스터 - prebiter | 지원됨 | 지원되지 않음 |
| 연방 정보 처리 표준 (FIPS) | 지원됨 | 지원되지 않음 |
| 풀 압축 메트릭 표시 기능 | 지원됨 | 지원되지 않음 |
| MCG(Multicloud Object Gateway) 끝점 Pod 자동 스케일링 | 지원됨 | 지원되지 않음 |
| 오버 프로비저닝 제어에 대한 경고 | 지원됨 | 지원되지 않음 |
| Ceph 모니터가 공간이 부족할 때 경고 | 지원됨 | 지원되지 않음 |
| 독립 실행형 Multicloud Object Gateway 구성 요소 배포 | 지원됨 | 지원되지 않음 |
| IBM Flashsystem과 같은 플러그형 외부 스토리지를 허용하는 확장 OpenShift Data Foundation 컨트롤 플레인 | 지원되지 않음 | 지원되지 않음 |
| IPV6 지원 | 지원되지 않음 | 지원되지 않음 |
| Multus | 지원되지 않음 | 지원되지 않음 |
| MCG(Multicloud Object Gateway) 버킷 복제 | 지원됨 | 지원되지 않음 |
| 오브젝트 데이터에 대한 할당량 지원 | 지원됨 | 지원되지 않음 |
| 최소 배포 | 지원되지 않음 | 지원되지 않음 |
| RHACM(Red Hat Advanced Cluster Management)을 사용한 지역-다양-DR(Regional-DR) | 지원됨 | 지원되지 않음 |
| RHACM이 포함된 메트로-DR(Metro-DR) 다중 클러스터 | 지원됨 | 지원되지 않음 |
| RAN(Radio Access Network)을 위한 단일 노드 솔루션 | 지원되지 않음 | 지원되지 않음 |
| NFS(네트워크 파일 시스템) 서비스 지원 | 지원됨 | 지원되지 않음 |
| MCG(Multicloud Object Gateway) 계정 인증 정보 변경 기능 | 지원됨 | 지원되지 않음 |
| Red Hat Advanced Cluster Management 콘솔의 멀티 클러스터 모니터링 | 지원됨 | 지원되지 않음 |
| Multicloud Object Gateway 라이프사이클에서 만료된 오브젝트 삭제 | 지원됨 | 지원되지 않음 |
| Openshift 지원 플랫폼에서 OpenShift Data Foundation의 무관한 배포 | 지원되지 않음 | 지원되지 않음 |
| 설치 프로그램에서 베어 메탈 인프라를 사용하여 OpenShift Data Foundation 배포 | 지원되지 않음 | 지원되지 않음 |
| IPv4를 사용하는 OpenShift Data Foundation의 OpenShift 듀얼 스택 | 지원되지 않음 | 지원되지 않음 |
| 배포 중 Multicloud Object Gateway 외부 서비스를 비활성화하는 기능 | 지원되지 않음 | 지원되지 않음 |
| 기본 NooBaa 백업 저장소의 덮어쓰기를 허용하는 기능 | 지원되지 않음 | 지원되지 않음 |
| ocs-operator에서 두 개의 MGR Pod, 하나의 활성 및 대기 시간을 배포하도록 허용 | 지원되지 않음 | 지원되지 않음 |
12장. 다음 단계
OpenShift Data Foundation 배포를 시작하려면 OpenShift Container Platform 내에서 내부 모드를 사용하거나 외부 모드를 사용하여 OpenShift Container Platform 외부에서 실행되는 클러스터의 서비스를 사용할 수 있습니다.
요구 사항에 따라 해당 배포 가이드로 이동하십시오.
내부 모드
- Amazon 웹 서비스를 사용하여 OpenShift Data Foundation 배포
- 베어 메탈을 사용하여 OpenShift Data Foundation 배포
- VMWare vSphere를 사용하여 OpenShift Data Foundation 배포
- Deploying OpenShift Data Foundation using Microsoft Azure
- Google Cloud를 사용하여 OpenShift Data Foundation 배포 [기술 프리뷰]
- Red Hat OpenStack Platform을 사용하여 OpenShift Data Foundation 배포 [기술 프리뷰]
- Deploying OpenShift Data Foundation using Red Hat Virtualization Platform
- Deploying OpenShift Data Foundation on IBM Power
- IBM Z에 OpenShift Data Foundation 배포
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}