4.3. 스토리지 클러스터 생성
OpenShift Data Foundation 운영자는 자체적으로 스토리지 기능을 제공하지 않으며 원하는 스토리지 구성을 정의해야 합니다.
Operator를 설치한 후 OpenShift Container Platform 콘솔 마법사 또는 CLI 및 ocs-operator를 사용하여 새 StorageCluster
를 생성합니다. ocs-operator
는 이 StorageCluster
를 조정합니다. OpenShift Data Foundation은 설치당 단일 StorageCluster
를 지원합니다. ocs-operator
조정을 통해 첫 번째 항목 이후에 생성된 StorageCluster
CR은 모두 무시됩니다.
OpenShift Data Foundation에서는 다음과 같은 StorageCluster 구성을 허용합니다.
- 내부
-
Internal 모드에서 모든 구성 요소는 OpenShift Container Platform 클러스터 내에서 컨테이너화되고 설치 마법사에서 관리자가 지정한
StorageClass
에 대해 생성된 PV(영구 볼륨)를 사용합니다. - 내부 연결
-
이 모드는 Internal 모드와 유사하지만 관리자가 백업 스토리지에 사용하는 클러스터 노드에 직접 연결된 로컬 스토리지 장치를 정의해야 합니다. 또한 관리자는 로컬 스토리지 Operator가
StorageClass
를 제공하기 위해 조정하는 CR을 생성해야 합니다.ocs-operator
는 이StorageClass
를 Ceph의 백업 스토리지로 사용합니다. - 외부
- 이 모드에서는 애플리케이션이 PV를 생성할 수 있는 외부 OpenShift Container Storage 설치에 Ceph 구성 요소가 OpenShift Container Platform 클러스터 내부에서 실행되지 않습니다. 다른 구성 요소는 필요에 따라 클러스터 내에서 실행됩니다.
- MCG Standalone
- 이 모드를 사용하면 CephCluster 없이 Multicloud Object Gateway 시스템을 쉽게 설치할 수 있습니다.
StorageCluster
CR이 발견되면 ocs-operator
는 이를 검증하고 스토리지 구성 요소를 정의하는 후속 리소스를 생성하기 시작합니다.
4.3.1. 내부 모드 스토리지 클러스터
내부 및 내부 연결 스토리지 클러스터 모두 다음과 같은 설정 프로세스를 갖습니다.
| 클러스터 애플리케이션이 Ceph 볼륨을 생성하는 데 사용하는 스토리지 클래스를 생성합니다. |
| 클러스터 애플리케이션에서 Ceph 볼륨의 스냅샷을 생성하는 데 사용하는 볼륨 스냅샷 클래스를 생성합니다. |
Ceph RGW 구성 | Ceph RGW 오브젝트 스토리지 끝점을 활성화하고 액세스할 수 있도록 다양한 Ceph 오브젝트 CR을 생성합니다. |
Ceph RBD 구성 |
|
CephFS 설정 |
|
Rook-Ceph 설정 |
기본 Ceph 클러스터의 전반적인 동작을 관리하는 |
|
|
|
|
작업 템플릿 |
작업을 정의하는 |
빠른 시작 |
웹 콘솔에 빠른 시작 가이드를 표시하는 |
4.3.1.1. 클러스터 생성
ocs-operator
에서 CephCluster
CR을 생성한 후 rook-operator
는 원하는 구성에 따라 Ceph 클러스터를 생성합니다. rook-operator
는 다음 구성 요소를 구성합니다.
Ceph |
클러스터의 다른 노드에서 3개의 Ceph |
Ceph | 이 데몬은 시작되어 클러스터의 지표를 수집하여 Prometheus에 보고합니다. |
Ceph OSD |
이러한 OSD는 |
CSI 프로비저너 |
이러한 프로비저너는 RBD 및 |
CSI 볼륨 플러그인 및 |
RBD 및 |
CephCluster
CR을 구성한 후 Rook은 나머지 Ceph CR을 조정하여 설정을 완료합니다.
|
|
|
|
|
|
|
|
Operator는 Ceph 상태를 모니터링하여 스토리지 플랫폼을 정상으로 유지합니다. mon
daemon이 너무 긴 기간(10분) 동안 다운된 경우 Rook은 새로운 mon
을 그 자리에 시작하여 전체 쿼럼을 완전히 복원할 수 있습니다.
ocs-operator
에서 CephCluster
CR을 업데이트하면 Rook은 클러스터 구성을 업데이트하기 위해 요청된 변경 사항에 즉시 응답합니다.
4.3.1.2. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator
는 다음을 조정합니다.
기본 BackingStore
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다양한 옵션은 다음과 같습니다.
AWS(Amazon Web Services) 배포 |
|
Microsoft Azure 배포 |
|
GCP(Google Cloud Platform) 배포 |
|
온프레미스 배포 |
RGW가 있는 경우 |
이전에 언급한 배포는 적용되지 않습니다. |
|
기본 BucketClass
기본 BackingStore
에 대한 배치 정책이 포함된 BucketClass
가 생성됩니다.
NooBaa Pod
다음과 같은 NooBaa Pod가 생성되고 시작됩니다.
데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 저장 중인 실제 데이터는 유지되지 않습니다. |
코어 | 이는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 Pod입니다. |
끝점 |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고 데이터를 작성하고 읽는 다양한 서비스와 통신합니다. 끝점은 |
경로
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
서비스
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 서비스가 생성됩니다.
4.3.2. 외부 모드 스토리지 클러스터
외부 스토리지 클러스터의 경우 ocs-operator
는 약간 다른 설정 프로세스를 따릅니다. ocs-operator
는 관리자 또는 콘솔 중 하나가 생성해야 하는 rook-ceph-external-cluster-details
ConfigMap
을 찾습니다. ConfigMap
을 생성하는 방법에 대한 자세한 내용은 Creating an OpenShift Data Foundation Cluster for external mode 를 참조하십시오. 그런 다음 ocs-operator
는 ConfigMap
에 지정된 대로 다음 리소스 중 일부 또는 모두를 생성합니다.
외부 Ceph 구성 |
외부 |
외부 Ceph 자격 증명 시크릿 | 외부 Ceph 인스턴스에 연결하는 자격 증명이 포함된 시크릿입니다. |
외부 Ceph StorageClasses | RBD, CephFS 및/또는 RGW용 볼륨 생성을 활성화하는 하나 이상의 StorageClasses. |
Enable CephFS CSI Driver |
|
Ceph RGW 구성 | RGW StorageClass가 지정된 경우 다양한 Ceph Object CR을 생성하여 Ceph RGW 오브젝트 스토리지 끝점에 대한 액세스를 활성화하고 제공합니다. |
ConfigMap
에 지정된 리소스를 생성하면 StorageCluster 생성 프로세스가 다음과 같이 진행됩니다.
|
|
|
애플리케이션이 Ceph 볼륨의 스냅샷을 생성하는 데 사용하는 |
|
|
|
콘솔에 |
4.3.2.1. 클러스터 생성
CephCluster
CR이 외부 모드에서 생성될 때 Rook Operator는 다음 작업을 수행합니다.
-
Operator는 원격 Ceph 클러스터에서 연결을 사용할 수 있는지 확인합니다. 연결을 수행하려면
mon
끝점과 시크릿을 로컬 클러스터로 가져와야 합니다. -
CSI 드라이버는 Ceph에 대한 원격 연결로 구성됩니다. RBD 및
CephFS
프로비저너 및 볼륨 플러그인은 내부 모드로 구성된 경우 CSI 드라이버와 유사하게 시작됩니다. Ceph에 대한 연결은 OpenShift 클러스터 외부에 있습니다. - 주소 변경 사항을 정기적으로 감시하고 Ceph-CSI 구성을 적절하게 업데이트합니다.
4.3.2.2. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator
는 다음을 조정합니다.
기본 BackingStore
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다양한 옵션은 다음과 같습니다.
AWS(Amazon Web Services) 배포 |
|
Microsoft Azure 배포 |
|
GCP(Google Cloud Platform) 배포 |
|
온프레미스 배포 |
RGW가 있는 경우 |
이전에 언급한 배포는 적용되지 않습니다. |
|
기본 BucketClass
기본 BackingStore
에 대한 배치 정책이 포함된 BucketClass
가 생성됩니다.
NooBaa Pod
다음과 같은 NooBaa Pod가 생성되고 시작됩니다.
데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 저장 중인 실제 데이터는 유지되지 않습니다. |
코어 | 이는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 Pod입니다. |
끝점 |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고 데이터를 작성하고 읽는 다양한 서비스와 통신합니다. 끝점은 |
경로
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
서비스
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 서비스가 생성됩니다.
4.3.3. MCG Standalone StorageCluster
이 모드에서는 CephCluster가 생성되지 않습니다. 대신 OpenShift Container Platform 대시보드의 기존 StorageClass를 활용하기 위해 기본값을 사용하여 NooBaa 시스템 CR이 생성됩니다.
4.3.3.1. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator
는 다음을 조정합니다.
기본 BackingStore
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다양한 옵션은 다음과 같습니다.
AWS(Amazon Web Services) 배포 |
|
Microsoft Azure 배포 |
|
GCP(Google Cloud Platform) 배포 |
|
온프레미스 배포 |
RGW가 있는 경우 |
이전에 언급한 배포는 적용되지 않습니다. |
|
기본 BucketClass
기본 BackingStore
에 대한 배치 정책이 포함된 BucketClass
가 생성됩니다.
NooBaa Pod
다음과 같은 NooBaa Pod가 생성되고 시작됩니다.
데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 저장 중인 실제 데이터는 유지되지 않습니다. |
코어 | 이는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 Pod입니다. |
끝점 |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고 데이터를 작성하고 읽는 다양한 서비스와 통신합니다. 끝점은 |
경로
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
서비스
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 서비스가 생성됩니다.
4.3.3.2. StorageSystem 생성
StorageCluster 생성의 일부로 odf-operator
는 StorageCluster를 OpenShift Data Foundation에 노출하는 해당 StorageSystem
CR을 자동으로 생성합니다.