Red Hat SummitRed Hat OpenShift Data Foundation 아키텍처
OpenShift Data Foundation 아키텍처 및 구성 요소 및 서비스가 수행하는 역할에 대한 개요입니다.
초록
preface
이 문서에서는 OpenShift Data Foundation 아키텍처에 대한 개요를 제공합니다.
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. Red Hat이 이를 개선하는 방법을 알려 주십시오. 피드백을 제공하려면 다음을 수행하십시오.
특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.
- 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
- 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
- 표시된 지침을 따릅니다.
보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.
- Bugzilla 웹 사이트로 이동하십시오.
- 구성 요소 섹션에서 문서 를 선택합니다.
- Description 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
- Submit Bug를 클릭하십시오.
1장. OpenShift Data Foundation 소개
Red Hat OpenShift Data Foundation은 Red Hat OpenShift Container Platform을 위한 클라우드 스토리지 및 데이터 서비스의 고도로 통합된 컬렉션입니다. 간단한 배포 및 관리를 용이하게 하기 위해 운영자로 패키징된 Red Hat OpenShift Container Platform Service Catalog의 일부로 제공됩니다.
Red Hat OpenShift Data Foundation 서비스는 주로 다음 구성 요소를 나타내는 스토리지 클래스를 통해 애플리케이션에서 사용할 수 있습니다.
- 주로 데이터베이스 워크로드에 의존하는 블록 스토리지 장치입니다. 예에는 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와 같은 머신 학습 프레임워크가 포함된 행, 열리기, 반구조적 데이터 스토리지 및 액세스 등이 있습니다.
CephFS 영구 볼륨에서 PostgresSQL 워크로드를 실행하는 것은 지원되지 않으며 RADOS Block Device(RBD) 볼륨을 사용하는 것이 좋습니다.
Red Hat OpenShift Data Foundation 버전 4.x는 다음을 포함한 소프트웨어 프로젝트 컬렉션을 통합합니다.
- Ceph, 블록 스토리지, 공유 및 분산 파일 시스템, 사내 오브젝트 스토리지 제공
- Ceph CSI: 영구 볼륨 및 클레임의 프로비저닝 및 라이프사이클 관리
- NooBaa - Multicloud Object Gateway 제공
- OpenShift Data Foundation, Rook-Ceph 및 NooBaa 운영자로 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의 구성 요소의 상호 운용성에 대한 자세한 내용은 상호 운용성 매트릭스 를 참조하십시오.
OpenShift Container Platform의 아키텍처 및 라이프사이클에 대한 자세한 내용은 OpenShift Container Platform 아키텍처를 참조하십시오.
3장. OpenShift Data Foundation Operator
Red Hat OpenShift Data Foundation은 세 가지 OLM(Operator Lifecycle Manager) Operator 번들로 구성되어 있으며, 작업 및 리소스 특성을 쉽게 자동화할 수 있도록 관리 작업과 사용자 지정 리소스를 구성하는 4개의 운영자를 배포합니다.
OpenShift Data Foundation
-
odf-operator
-
OpenShift Container Storage
-
ocs-operator -
rook-ceph-operator
-
Multicloud Object Gateway
-
mcg-operator
-
관리자는 원하는 클러스터의 최종 상태를 정의하고 OpenShift Data Foundation 운영자가 최소한의 관리자 개입으로 클러스터가 해당 상태에 있거나 해당 상태에 접근하는지 확인합니다.
3.1. OpenShift Data Foundation Operator
The odf-operator 는 OpenShift Data Foundation의 "메타" 운영자, 즉 다른 operator에 영향을 미치는 운영자로 설명할 수 있습니다.
The odf-operator 에는 다음과 같은 기본 기능이 있습니다.
OpenShift Data Foundation을 구성하는 다른 운영자의 구성 및 버전 지정을 적용합니다. 이는 운영자 종속성과 서브스크립션 관리의 두 가지 기본 메커니즘을 사용하여 이 작업을 수행합니다.
-
The
odf-operator번들은 다른 OLM Operator에 대한 종속성을 지정하여 항상 특정 버전에 설치되도록 합니다. - Operator 자체는 다른 모든 운영자에 대한 서브스크립션을 관리하여 OLM에서 원하는 버전의 Operator를 설치할 수 있도록 합니다.
-
The
- OpenShift 콘솔의 OpenShift Data Foundation 외부 플러그인을 제공합니다.
- OpenShift 콘솔과 스토리지 솔루션을 통합하는 API를 제공합니다.
3.1.1. 구성 요소
The odf-operator 에는 ocs-operator 패키지에 종속되어 있습니다. mcg-operator 의 서브스크립션을 관리합니다. 또한, the odf-operator 번들은 OpenShift 콘솔용 OpenShift Data Foundation 외부 플러그인에 대한 두 번째 배포를 정의합니다. 이는 OpenShift Data Foundation 대시보드를 OpenShift Container Platform 콘솔에 직접 등록하고 통합하는 데 필요한 파일을 제공하는 nginx기반 포드를 정의합니다.
3.1.2. 설계 다이어그램
이 다이어그램에서는 OpenShift Container Platform 과 통합되는 방법을 설명합니다.
그림 3.1. OpenShift Data Foundation Operator
3.1.3. 응답
odf-operator는 다음 CRD를 정의합니다.
-
StorageSystem
StorageSystem CRD는 OpenShift Container Platform의 데이터 스토리지 및 서비스를 제공하는 기본 스토리지 시스템을 나타냅니다. 지정된 스토리지 시스템에 대한 서브스크립션이 있는지 확인하도록 운영자를 트리거합니다.
3.1.4. Resources
ocs-operator 는 지정된 StorageSystem의 사양에 응답하여 다음 CR을 생성합니다.
Operator Lifecycle Manager 리소스
지정된 StorageSystem의 유형을 정의하고 조정하는 운영자에 대한 생성합니다.
서브스크립션 을
3.1.5. 제한
The odf-operator 는 데이터 스토리지 또는 서비스 자체를 제공하지 않습니다. 다른 스토리지 시스템의 통합 및 관리 계층으로 존재합니다.
3.1.6. 고가용성
고가용성은 다른 대부분의 Operator와 유사한 the odf-operator Pod의 기본 요구 사항이 아닙니다. 일반적으로 프로세스 배포의 필요나 이점을 얻는 작업이 없습니다. 현재 Pod를 사용할 수 없거나 삭제될 때마다 OpenShift Container Platform은 대체 Pod를 신속하게 실행합니다.
3.1.7. 관련 구성 파일
The odf-operator 는 Operator의 동작을 수정하는 데 사용할 수 있는 변수 ConfigMap 과 함께 제공됩니다.
3.1.8. 관련 로그 파일
OpenShift Data Foundation을 이해하고 문제를 해결하려면 다음을 참조하십시오.
- Operator Pod 로그
-
StorageSystemstatus - 기본 스토리지 시스템 CRD 상태
Operator Pod 로그
각 Operator는 조정 및 발생한 오류에 대한 정보를 포함하는 표준 Pod 로그를 제공합니다. 이러한 로그에는 필터링 및 무시할 수 있는 성공적인 조정에 대한 정보가 있는 경우가 많습니다.
StorageSystem 상태 및 이벤트
StorageSystem CR은 CR의 상태에 조정 세부 정보를 저장하고 관련 이벤트가 있습니다. StorageSystem 의 사양에는 관리자가 스토리지 시스템의 상태에 대한 자세한 정보를 찾는 데 사용할 수 있는 실제 스토리지 시스템 CRD의 이름, 네임스페이스 및 kind가 포함되어 있습니다.
3.1.9. 라이프 사이클
OpenShift Data Foundation 번들이 설치되어 있는 한 The odf-operator 가 있어야 합니다. 이는 OpenShift Data Foundation CSV의 OLM 조정의 일부로 관리됩니다. 하나 이상의 포드 인스턴스가 Ready 상태여야 합니다.
CRD와 같은 Operator 피연산자가 Operator의 라이프사이클에 영향을 주지 않아야 합니다. StorageSystems 의 생성 및 삭제는 운영자의 제어 범위를 벗어난 작업이며 관리자가 시작하거나 적절한 API(애플리케이션 프로그래밍 인터페이스) 호출을 사용하여 자동화해야 합니다.
3.2. OpenShift Container Storage Operator
ocs-operator 는 다른 운영자에 영향을 미치고 다른 운영자가 제공하는 기능에 대한 구성 게이트웨이 역할을 하는 OpenShift Data Foundation의 "메타" 운영자로 설명할 수 있습니다. 다른 운영자는 직접 관리하지 않습니다.
ocs-operator 에는 다음과 같은 기본 기능이 있습니다.
- 다른 운영자가 조정하도록 트리거하는 CR(사용자 정의 리소스)을 생성합니다.
- Ceph 및 Multicloud Object Gateway 구성을 추상화하여 Red Hat에서 검증 및 지원하는 알려진 모범 사례로 제한합니다.
- 지원 정책에 따라 컨테이너화된 Ceph 및 NooBaa를 배포하는 데 필요한 리소스를 생성하고 조정합니다.
3.2.1. 구성 요소
ocs-operator 에는 종속 구성 요소가 없습니다. 그러나 Operator는 CSV( ClusterServiceVersion )에 정의된 다른 운영자의 모든 CRD(사용자 정의 리소스 정의)의 존재 여부에 대한 종속성이 있습니다.
3.2.2. 설계 다이어그램
이 다이어그램에서는 OpenShift Container Storage를 OpenShift Container Platform과 통합하는 방법을 보여줍니다.
그림 3.2. OpenShift Container Storage Operator
3.2.3. 책임
두 개의 ocs-operator CRD는 다음과 같습니다.
-
OCSInitialization -
StorageCluster
OCSInitialization 은 Operator 수준에서 적용되는 작업을 캡슐화하는 데 사용되는 Singleton CRD입니다. Operator는 하나의 인스턴스가 항상 존재하는지 확인합니다. CR은 다음을 트리거합니다.
OpenShift Container Storage에 필요한 초기화 작업을 수행합니다. 필요한 경우
OCSInitializationCRD를 삭제하여 이러한 작업을 다시 트리거할 수 있습니다.- OpenShift Container Storage에 필요한 SCC(보안 컨텍스트 제약 조건)가 있는지 확인합니다.
- 고급 문제 해결 및 복구 작업을 수행하는 데 사용되는 Ceph toolbox Pod의 배포를 관리합니다.
StorageCluster CRD는 OpenShift Container Storage의 전체 기능을 제공하는 시스템을 나타냅니다. Operator를 트리거하여 Rook-Ceph 및 NooBaa CRD의 생성 및 조정을 보장합니다. ocs-operator 는 Storage 및 Cluster 사양 의 구성을 기반으로 CephClusterNooBaa CRD를 알고리즘 방식으로 생성합니다. Operator는 CephBlockPools,Routes 등과 같은 추가 CR도 생성합니다. OpenShift Container Storage의 다양한 기능을 활성화하려면 이러한 리소스가 필요합니다. 현재 OpenShift Container Platform 클러스터당 하나의 스토리지 클러스터 CR만 지원됩니다.
3.2.4. Resources
ocs-operator 는 정의하는 CRD의 사양에 응답하여 다음 CR을 생성합니다. 이러한 일부 리소스의 구성을 재정의하여 생성된 사양을 변경하거나 완전히 생성하지 않도록 할 수 있습니다.
- 일반 리소스
- 이벤트
- 조정에 응답하는 데 필요한 경우 다양한 이벤트를 생성합니다.
- 영구 볼륨(PV)
- PV는 Operator가 직접 생성하지 않습니다. 그러나 Operator는 Ceph CSI 드라이버에서 생성한 모든 PV를 추적하고 PV에 지원되는 기능에 대한 적절한 주석이 있는지 확인합니다.
- 빠른 시작
- OpenShift Container Platform Console의 다양한 빠른 시작 CR을 배포합니다.
- Rook-Ceph 리소스
CephBlockPool-
기본 Ceph 블록 풀을 정의합니다.
Ceph 개체 저장소의 CephFilesysPrometheusRulesoute. StorageClass-
기본 스토리지 클래스를 정의합니다. 예를 들어
CephBlockPool및CephFilesystem의 경우). VolumeSnapshotClass- 해당 스토리지 클래스의 기본 볼륨 스냅샷 클래스를 정의합니다.
- Multicloud Object Gateway 리소스
NooBaa- 기본 Multicloud Object Gateway 시스템을 정의합니다.
- 리소스 모니터링
- 메트릭 내보내기 서비스
- 메트릭 내보내기 서비스 모니터
- PrometheusRules
3.2.5. 제한
ocs-operator 는 OpenShift Data Foundation의 다른 포드를 배포하거나 조정하지 않습니다. ocs-operator CSV는 Operator Deployments 및 OLM(Operator Lifecycle Manager)과 같은 최상위 구성 요소를 정의하여 지정된 구성 요소를 조정합니다.
3.2.6. 고가용성
고가용성은 대부분의 다른 운영자와 유사한 ocs-operator Pod의 기본 요구 사항이 아닙니다. 일반적으로 프로세스 배포의 필요나 이점을 얻는 작업이 없습니다. 현재 Pod를 사용할 수 없거나 삭제될 때마다 OpenShift Container Platform은 대체 Pod를 신속하게 실행합니다.
3.2.7. 관련 구성 파일
ocs-operator 구성은 CSV에서 완전히 지정되며 CSV의 사용자 정의 빌드 없이 수정할 수 없습니다.
3.2.8. 관련 로그 파일
OpenShift Container Storage에 대한 이해 및 문제 해결을 위해 다음을 참조하십시오.
- Operator Pod 로그
- 스토리지 클러스터 상태 및 이벤트
- OCSInitialization 상태
Operator Pod 로그
각 Operator는 조정 및 발생한 오류에 대한 정보를 포함하는 표준 Pod 로그를 제공합니다. 이러한 로그에는 필터링 및 무시할 수 있는 성공적인 조정에 대한 정보가 있는 경우가 많습니다.
스토리지 클러스터 상태 및 이벤트
StorageCluster CR은 CR의 상태에 조정 세부 정보를 저장하고 관련 이벤트가 있습니다. 상태에는 예상 컨테이너 이미지의 섹션이 포함됩니다. 다른 운영자의 포드에 존재할 것으로 예상되는 컨테이너 이미지와 현재 탐지하는 이미지를 표시합니다. 그러면 OpenShift Container Storage 업그레이드가 완료되었는지 확인하는 데 도움이 됩니다.
OCSInitialization 상태
이 상태는 초기화 작업이 성공적으로 완료되었는지 여부를 표시합니다.
3.2.9. 라이프 사이클
ocs-operator 는 OpenShift Container Storage 번들이 설치되어 있는 한 존재해야 합니다. 이는 OpenShift Container Storage CSV의 OLM 조정의 일부로 관리됩니다. 하나 이상의 포드 인스턴스가 Ready 상태여야 합니다.
CRD와 같은 Operator 피연산자가 Operator의 라이프사이클에 영향을 주지 않아야 합니다. OCSInitialization CR이 항상 있어야 합니다. Operator가 없는 경우 Operator가 하나를 생성합니다. 스토리지 클러스터 생성 및 삭제는 운영자의 제어 범위를 벗어난 작업이며 관리자가 시작하거나 적절한 API 호출을 사용하여 자동화해야 합니다.
3.3. Rook-Ceph Operator
Rook-Ceph 운영자는 OpenShift Data Foundation에서 Ceph의 Rook 운영자입니다. Rook를 사용하면 Ceph 스토리지 시스템을 OpenShift Container Platform에서 실행할 수 있습니다.
Rook-Ceph 운영자는 스토리지 클러스터를 자동으로 부트스트랩하고 스토리지 데몬을 모니터링하여 스토리지 클러스터가 정상인지 확인하는 간단한 컨테이너입니다.
3.3.1. 구성 요소
Rook-Ceph 운영자는 여러 구성 요소를 OpenShift Data Foundation 배포의 일부로 관리합니다.
- Ceph-CSI 드라이버
-
Operator는 두 드라이버 각각에 대한 프로비저너, RADOS 블록 장치(RBD) 및 Ceph 파일 시스템(CephFS) 및 두 드라이버 각각에 대한 볼륨 플러그인
데몬세트를 포함하여 CSI 드라이버를 생성하고 업데이트합니다. - Ceph 데몬
- Mons
- 모니터(모니터)는 Ceph의 핵심 메타데이터 저장소를 제공합니다.
- OSDs
- 오브젝트 스토리지 데몬(OSD)은 기본 장치에 데이터를 저장합니다.
- Mgr
- manager(mgr)는 지표를 수집하고 Ceph에 대한 기타 내부 기능을 제공합니다.
- RGW
- RGW(RADOS 게이트웨이)는 오브젝트 저장소에 S3 엔드포인트를 제공합니다.
- MDS
- 메타데이터 서버(MDS)는 CephFS 공유 볼륨을 제공합니다.
3.3.2. 설계 다이어그램
다음 이미지는 Ceph Rook이 OpenShift Container Platform과 통합하는 방법을 보여줍니다.
그림 3.3. Rook-Ceph Operator
OpenShift Container Platform 클러스터에서 Ceph가 실행 중인 경우 OpenShift Container Platform 애플리케이션은 Rook-Ceph에서 관리하는 블록 장치 및 파일 시스템을 마운트하거나 개체 스토리지에 S3/Swift API를 사용할 수 있습니다.
3.3.3. 책임
Rook-Ceph 운영자는 스토리지 클러스터를 부트스트랩하고 모니터링하는 컨테이너입니다. 다음과 같은 기능을 수행합니다.
- 스토리지 구성 요소의 구성 자동화
- RADOS 스토리지 클러스터를 제공하기 위해 Ceph 모니터 pod 및 Ceph OSD 데몬을 시작, 모니터링 및 관리합니다.
Pod 및 기타 아티팩트를 초기화하여 관리할 서비스를 실행합니다.
- 풀의 CRD
- 오브젝트 저장소(S3/Swift)
- 파일 시스템
- Ceph mons 및 OSD를 모니터링하여 스토리지가 계속 사용 가능하고 정상 상태로 유지되도록 합니다.
- 클러스터 크기에 따라 mon 구성을 조정하면서 Ceph mons 배치 배포 및 관리
- API 서비스에서 요청한 상태 변경 사항을 감시하고 변경 사항을 적용합니다.
- 스토리지 사용에 필요한 Ceph-CSI 드라이버 초기화
- 스토리지를 Pod에 마운트하도록 Ceph-CSI 드라이버 자동 구성
Rook-Ceph Operator 아키텍처
Rook-Ceph 운영자 이미지에는 클러스터를 관리하는 데 필요한 모든 도구가 포함되어 있습니다. 데이터 경로는 변경되지 않습니다. 그러나 운영자는 모든 Ceph 구성을 노출하지는 않습니다. 배치 그룹 및 프레임 맵과 같은 대부분의 Ceph 기능은 사용자에게 숨겨져 있으며 물리적 리소스, 풀, 볼륨, 파일 시스템 및 버킷 측면에서 더 나은 사용자 환경을 제공합니다.
3.3.4. Resources
Rook-Ceph Operator는 openshift-storage 네임스페이스에 생성하는 모든 리소스에 소유자 참조를 추가합니다. 클러스터가 설치 제거되면 소유자 참조를 통해 리소스가 모두 정리되었는지 확인합니다. 여기에는 configmaps,보안,서비스,배포,데몬 세트 등과 같은 OpenShift Container Platform 리소스가 포함됩니다.
Rook-Ceph 운영자는 CephCluster, Ceph ObjectStore, CephFilesystem 및 CephBlockPool을 포함하는 OpenShift Data Foundation에서 확인한 설정을 구성하기 위해 CR을 감시합니다.
3.3.5. 라이프 사이클
Rook-Ceph Operator는 Ceph 클러스터에서 다음 Pod의 라이프사이클을 관리합니다.
- Rook Operator
- 클러스터의 조정을 소유하는 단일 Pod입니다.
- RBD CSI 드라이버
- 단일 배포로 관리되는 두 개의 프로비저너 포드.
-
노드당 하나의 플러그인 Pod로, 데몬 세트에 의해
관리됩니다.
- CephFS CSI 드라이버
- 단일 배포로 관리되는 두 개의 프로비저너 포드.
-
노드당 하나의 플러그인 Pod로, 데몬 세트에 의해
관리됩니다.
- 모니터 (모니)
각각 자체 배포가 포함된 세 개의 mon 포드.
- 클러스터 확장
- 1개는 중재자 영역에 5개의 mon pod를 포함하고 다른 두 개의 데이터 영역에 각각 2개가 포함되어 있습니다.
- 관리자 (mgr)
클러스터에 하나의 mgr Pod가 있습니다.
- 클러스터 확장
- 두 개의 mgr 포드(OpenShift Data Foundation 4.8로 시작)가 있으며 각각 두 개의 할당되지 않은 영역이 있습니다.
- 오브젝트 스토리지 데몬(OSD)
- 클러스터에서 초기에 3개 이상의 OSD가 생성됩니다. 클러스터를 확장할 때 더 많은 OSD가 추가됩니다.
- 메타데이터 서버(MDS)
- CephFS 메타데이터 서버에는 단일 포드가 있습니다.
- RADOS 게이트웨이(RGW)
- Ceph RGW 데몬에는 단일 포드가 있습니다.
3.4. MCG 연산자
MCG(Multicloud Object Gateway) 운영자는 OpenShift Data Foundation 운영자 및 Rook-Ceph 운영자와 함께 OpenShift Data Foundation의 운영자입니다. MCG Operator는 독립형 운영자로 업스트림을 사용할 수 있습니다.
MCG Operator는 다음과 같은 주요 기능을 수행합니다.
- OpenShift Data Foundation 내에서 MCG(Multicloud Object Gateway) 구성 요소를 제어하고 조정합니다.
- 오브젝트 버킷 클레임, 버킷 클래스 및 백업 저장소와 같은 새 사용자 리소스를 관리합니다.
- 기본 바로 사용 가능한 리소스를 생성합니다.
몇 가지 구성 및 정보는 OpenShift Data Foundation 운영자를 통해 MCG 운영자에게 전달됩니다.
3.4.1. 구성 요소
MCG Operator에는 하위 구성 요소가 없습니다. 그러나 제어되는 다양한 리소스에 대한 조정 반복문으로 구성됩니다.
MCG Operator에는 CLI(명령줄 인터페이스)가 있으며 OpenShift Data Foundation의 일부로 사용할 수 있습니다. 다양한 리소스를 생성, 삭제 및 쿼리할 수 있습니다. 이 CLI는 YAML 파일을 직접 적용하는 것과 달리 구성을 적용하기 전에 입력 삭제 및 상태 검증 계층을 추가합니다.
3.4.2. 책임 및 리소스
MCG Operator는 CRD(사용자 정의 리소스 정의) 및 OpenShift Container Platform 엔터티를 조정하고 담당합니다.
- 백업 저장소
- 네임 스페이스 저장소
- 버킷 클래스
- 개체 버킷 클레임(OBC)
- NooBaa의 Pod 상태 저장은 CRD를 설정합니다.
- Prometheus 규칙 및 서비스 모니터링
- HPA(Horizontal Pod Autoscaler)
백업 저장소
고객이 MCG 구성 요소에 연결된 리소스입니다. 이 리소스는 MCG에 프로비저닝된 버킷의 데이터를 저장할 수 있는 기능을 제공합니다.
기본 백업 저장소는 OpenShift Container Platform이 실행되는 플랫폼에 따라 배포의 일부로 생성됩니다. 예를 들어 OpenShift Container Platform 또는 OpenShift Data Foundation이 AWS(Amazon Web Services)에 배포되면 AWS::S3 버킷인 기본 백업 저장소가 생성됩니다. 마찬가지로 Microsoft Azure의 경우 기본 백업 저장소는 Blob 컨테이너입니다.
기본 백업 저장소는 OpenShift Container Platform과 함께 제공되는 클라우드 인증 정보 Operator에 CRD를 사용하여 생성됩니다. MCG에 추가할 수 있는 백업 저장소의 양은 제한이 없습니다. 버킷 클래스 CRD에서 백업 저장소를 사용하여 버킷의 다양한 정책을 정의합니다. 특정 OpenShift Data Foundation 버전의 설명서를 참조하여 백업 저장소로 지원되는 서비스 또는 리소스 유형을 식별합니다.
네임 스페이스 저장소
네임스페이스 버킷에 사용되는 리소스입니다. 배포 중에는 기본값이 생성되지 않습니다.
버킷 클래스
새로 프로비저닝된 버킷의 기본 또는 초기 정책입니다. 다음 정책은 버킷 클래스로 설정됩니다.
- 배치 정책
버킷에 연결하고 버킷의 데이터를 작성하는 데 사용할 백업 저장소를 나타냅니다. 이 정책은 데이터 버킷 및 캐시 정책에 사용되며 로컬 캐시 배치를 나타냅니다. 배치 정책에는 다음 두 가지 모드가 있습니다.
- 분산. 정의된 백업 저장소에서 데이터를 제거합니다
- 미러. 각 백업 저장소에 전체 복제본 생성
- 네임 스페이스 정책
- 집계에 사용되는 리소스와 쓰기 대상에 사용되는 리소스를 정의하는 네임스페이스 버킷에 대한 정책입니다.
- 캐시 정책
- 이는 버킷에 대한 정책으로, 캐시 항목에 대한 허브(TTL) 및 TTL(Live To Live) 시간을 설정합니다.
기본 버킷 클래스는 배포 중에 생성되며 기본 백업 저장소를 사용하는 배치 정책으로 설정됩니다. 추가할 수 있는 버킷 클래스 수에는 제한이 없습니다.
지원되는 정책 유형을 식별하려면 특정 OpenShift Data Foundation 버전의 문서를 참조하십시오.
개체 버킷 클레임(OBC)
S3 버킷 프로비저닝을 활성화하는 CRD입니다. MCG를 사용하면 OBCs 선택적 버킷 클래스를 수신하여 버킷의 초기 구성을 확인합니다. 버킷 클래스를 제공하지 않으면 기본 버킷 클래스가 사용됩니다.
NooBaa의 Pod 상태 저장은 CRD를 설정합니다.
DB 포드, 코어 Pod 및 엔드포인트와 같은 NooBaa 배포의 다양한 Pod를 제어하는 내부 CRD입니다. 이 CRD는 내부이므로 변경하지 않아야 합니다. 이 Operator는 다음 엔터티를 조정합니다.
- DB pod SCC
- OpenShift Container Platform과 NooBaa 사용자 인터페이스 간에 SSO SSO SSO를 허용하는 역할 바인딩 및 서비스 계정
- S3 액세스 경로
- OpenShift Container Platform에서 수집 및 서명하고 S3 경로에 설정된 인증서
Prometheus 규칙 및 서비스 모니터링
이러한 CRD는 Prometheus 및 MCG에서 지원하는 경고 규칙에 대한 스크랩 지점을 설정합니다.
HPA(Horizontal Pod Autoscaler)
MCG 엔드 포인트와 통합됩니다. 엔드포인트 포드는 CPU 부족(S3 트래픽 금액)에 따라 확장 및 축소됩니다.
3.4.3. 고가용성
Operator는 OpenShift Container Platform에서 실패한 Pod를 다시 예약하는 유일한 고가용성을 제공합니다.
3.4.4. 관련 로그 파일
NooBaa Operator의 문제를 해결하려면 다음을 참조하십시오.
- must-gather를 통해서도 사용할 수 있는 Operator Pod 로그입니다.
- must-gather를 통해 사용할 수 있는 다른 CRD 또는 엔터티 및 해당 상태입니다.
3.4.5. 라이프 사이클
MCG Operator는 OpenShift Data Foundation 배포 후 그리고 제거될 때까지 이를 실행하고 조정합니다.
4장. OpenShift Data Foundation 설치 개요
OpenShift Data Foundation은 여러 운영자가 관리하는 여러 구성 요소로 구성됩니다.
4.1. 설치된 Operator
Operator Hub에서 OpenShift Data Foundation을 설치할 때 다음과 같은 4가지 배포가 생성됩니다.
-
odf-operator: theodf-operatorPod 정의 -
ocs-operator: 동일한 컨테이너에서ocs-operator및 해당metricsPod를 정의합니다.-exporter에 대한 프로세스를 실행하는 ocs-operator -
rook-ceph-operator:rook-ceph-operator포드를 정의합니다. -
mcg-operator:mcg-operator포드를 정의합니다.
이러한 운영자는 독립적으로 실행되며 다른 운영자가 조사하는 고객 리소스(CR)를 만들어 서로 상호 작용합니다. ocs-operator 는 주로 Ceph 스토리지 및 Multicloud Object Gateway를 구성하는 CR을 생성합니다. mcg-operator 는 해당 구성 요소에서 사용할 Ceph 볼륨을 생성하는 경우가 있습니다.
4.2. OpenShift Container Storage 초기화
OpenShift Data Foundation 번들은 OpenShift Container Platform Console의 외부 플러그인을 정의하여 콘솔에서 사용할 수 없는 새 화면과 기능을 추가합니다. 이 플러그인은 설치 시 OLM에서 생성한 Deployment에서 관리하는 the odf-console-plugin Pod에서 웹 서버로 실행됩니다.
ocs-operator 는 OCSInitialization CR이 생성되면 자동으로 생성합니다. 어떤 시점에도 하나의 OCSInitialization CR만 존재합니다. 단일 스토리지 클러스터 의 범위로 제한되지 않고 한 번만 수행하는 ocs-operator 동작을 제어합니다. OCSInitialization CR을 삭제하면 ocs-operator 에서 다시 생성하여 초기화 작업을 다시 시작할 수 있습니다.
OCSInitialization CR은 다음 동작을 제어합니다.
- SCC(
SecurityContextConstraints) -
OCSInitializationCR이 생성된 후ocs-operator는 구성 요소 Pod에서 사용할 다양한 SCC를 생성합니다. - Ceph 툴박스 배포
-
OCSInitialization을 사용하여 고급 Ceph 작업을 위해 Ceph 툴박스 Pod를 배포할 수 있습니다. - Rook-Ceph Operator 구성
-
이 구성은
rook-ceph-operator 동작에 대한 전체 구성을 제어하는rook-ceph-operator-configConfigMap을 생성합니다.
4.3. 스토리지 클러스터 생성
OpenShift Data Foundation 운영자 자체는 스토리지 기능을 제공하지 않으며 원하는 스토리지 구성을 정의해야 합니다.
Operator를 설치한 후 OpenShift Container Platform 콘솔 마법사 또는 CLI 및 ocs-operator 를 사용하여 새 스토리지 클러스터를 생성합니다. OpenShift Data Foundation은 설치당 단일 스토리지 클러스터 를 지원합니다. 첫 번째 생성 후에 생성된 스토리지 클러스터 CR은 ocs-operator 조정에서 무시합니다.
OpenShift Data Foundation에서는 다음과 같은 세 가지 스토리지 클러스터 구성을 허용합니다.
- 내부
-
내부 모드에서 모든 구성 요소는 OpenShift Container Platform 클러스터 내에서 컨테이너화되며 설치 마법사에서 관리자가 지정한
StorageClass에 대해 생성된 PV(영구 볼륨)를 동적으로 프로비저닝합니다. - 내부 연결
-
이 모드는 내부 모드와 유사하지만 관리자가 Ceph에서 백업 스토리지에 사용하는 클러스터 노드에 직접 연결된 로컬 스토리지 장치를 정의해야 합니다. 또한 관리자는
StorageClass를 제공하기 위해 로컬 스토리지 운영자가 조정하는 CR을 생성해야 합니다.ocs-operator는 이StorageClass를Ceph의 백업 스토리지로 사용합니다. - 외부
- 이 모드에서 Ceph 구성 요소는 OpenShift Container Platform 클러스터 내에서 실행되지 않고 애플리케이션이 PV를 생성할 수 있는 외부 OpenShift Container Storage 설치에 제공됩니다. 필요에 따라 다른 구성 요소는 클러스터 내에서 실행됩니다.
MCG 독립 실행형: 이 모드를 사용하면 CephCluster가 포함되지 않고 Multicloud Object Gateway 시스템을 쉽게 설치할 수 있습니다.
스토리지 클러스터 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 |
클러스터의 여러 노드에서 세 개의 Ceph |
|
Ceph | 이 데몬이 시작되어 클러스터에 대한 지표를 수집하여 Prometheus에 보고합니다. |
| Ceph OSD |
이러한 OSD는 |
| CSI 프로비저너 |
이러한 프로비저너는 RBD 및 |
|
CSI 볼륨 플러그인 및 |
RBD 및 |
CephCluster CR이 구성되면 Rook에서 나머지 Ceph CR을 조정하여 설정을 완료합니다.
|
|
|
|
|
|
|
|
|
|
|
|
Operator는 Ceph 상태를 모니터링하여 스토리지 플랫폼이 정상인지 확인합니다. mon 데몬이 너무 길어지면(10분), Rook은 해당 위치에서 새 mon 을 시작하여 전체 쿼럼을 완전히 복원할 수 있습니다.
ocs-operator 가 CephCluster CR을 업데이트하면 Rook은 요청된 변경 사항에 즉시 응답하여 클러스터 구성을 업데이트합니다.
4.3.1.2. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator 는 다음을 조정합니다.
기본 백업 저장소
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다른 옵션은 다음과 같습니다.
| AWS(Amazon Web Services) 배포 |
|
| Microsoft Azure 배포 |
|
| GCP(Google Cloud Platform) 배포 |
|
| On-prem deployment |
RGW가 있는 경우 |
| 이전에 언급한 배포가 적용되지 않습니다. |
|
기본 버킷 클래스
기본 백업 저장소에 대한 배치 정책이 생성됩니다.
포함된 버킷 클래스가
NooBaa Pod
다음 NooBaa Pod가 생성 및 시작됩니다.
| 데이터베이스 (DB) | 이는 메타데이터, 통계, 이벤트 등을 포함하는 Postgres DB입니다. 그러나 저장되는 실제 데이터를 보유하지는 않습니다. |
| 코어 | 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 포드입니다. |
| 엔드포인트 |
이러한 포드는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고, 다양한 서비스와 통신하여 데이터를 작성하고 읽습니다. 엔드포인트는 |
경로
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
Service
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스용 서비스가 생성됩니다.
4.3.2. 외부 모드 스토리지 클러스터
외부 스토리지 클러스터의 경우 ocs-operator 는 약간 다른 설정 프로세스를 따릅니다. ocs-operator 는 다른 사용자가 생성해야 하는 rook-ceph-external-cluster-details ConfigMap (관리자 또는 콘솔)이 있는지 찾습니다. ConfigMap 생성 방법에 대한 자세한 내용은 외부 모드를 위한 OpenShift Data Foundation 클러스터 생성을 참조하십시오. 그런 다음 ocs-operator 는 ConfigMap 에 지정된 대로 다음 리소스 중 일부 또는 전체를 생성합니다.
| 외부 Ceph 구성 |
ConfigMap은 외부 |
| 외부 Ceph 인증 정보 시크릿 | 외부 Ceph 인스턴스에 연결할 자격 증명이 포함된 Secret입니다. |
| 외부 Ceph StorageClasses | RBD, CephFS 및/또는 RGW에 대한 볼륨을 생성할 수 있는 하나 이상의 StorageClasss입니다. |
| CephFS CSI 드라이버 활성화 |
|
| Ceph RGW 구성 | RGW StorageClass가 지정된 경우 다양한 Ceph 개체 CR을 생성하여 Ceph RGW 오브젝트 스토리지 끝점에 대한 액세스를 활성화하고 제공합니다. |
ConfigMap 에 지정된 리소스를 생성하면 StorageCluster 생성 프로세스가 다음과 같이 진행됩니다.
|
|
|
|
|
애플리케이션에서 Ceph 볼륨의 스냅샷 |
|
|
|
QuickStarts: 콘솔에 빠른 시작 가이드를 표시하는 빠른 시작 CR을 생성합니다.
4.3.2.1. 클러스터 생성
Rook Operator는 CephCluster CR이 외부 모드에서 생성될 때 다음 작업을 수행합니다.
-
운영자는 원격 Ceph 클러스터에서 연결을 사용할 수 있는지 확인합니다. 연결하려면
mon엔드포인트와 시크릿을 로컬 클러스터로 가져와야 합니다. -
CSI 드라이버는 Ceph에 대한 원격 연결을 사용하여 구성됩니다. RBD 및
CephFS프로비저너 및 볼륨 플러그인은 내부 모드로 구성된 경우 CSI 드라이버와 유사하게 시작되며 Ceph에 대한 연결이 OpenShift 클러스터 외부에 있습니다. - 주소 변경 사항을 정기적으로 모니터링하고 그에 따라 Ceph-CSI 구성을 업데이트합니다.
4.3.2.2. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator 는 다음을 조정합니다.
기본 백업 저장소
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다른 옵션은 다음과 같습니다.
| AWS(Amazon Web Services) 배포 |
|
| Microsoft Azure 배포 |
|
| GCP(Google Cloud Platform) 배포 |
|
| On-prem deployment |
RGW가 있는 경우 |
| 이전에 언급한 배포가 적용되지 않습니다. |
|
기본 버킷 클래스
기본 백업 저장소에 대한 배치 정책이 생성됩니다.
포함된 버킷 클래스가
NooBaa Pod
다음 NooBaa Pod가 생성 및 시작됩니다.
| 데이터베이스 (DB) | 이는 메타데이터, 통계, 이벤트 등을 포함하는 Postgres DB입니다. 그러나 저장되는 실제 데이터를 보유하지는 않습니다. |
| 코어 | 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 포드입니다. |
| 엔드포인트 |
이러한 포드는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고, 다양한 서비스와 통신하여 데이터를 작성하고 읽습니다. 엔드포인트는 |
경로
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
Service
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스용 서비스가 생성됩니다.
4.3.3. MCG Standalone StorageCluster
이 모드에서는 CephCluster가 생성되지 않습니다. 대신 OpenShift Container Platform의 기존 StorageClass를 활용할 수 있도록 기본값을 사용하여 NooBaa 시스템 CR을 생성합니다.
4.3.3.1. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator 는 다음을 조정합니다.
기본 백업 저장소
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다른 옵션은 다음과 같습니다.
| AWS(Amazon Web Services) 배포 |
|
| Microsoft Azure 배포 |
|
| GCP(Google Cloud Platform) 배포 |
|
| On-prem deployment |
RGW가 있는 경우 |
| 이전에 언급한 배포가 적용되지 않습니다. |
|
기본 버킷 클래스
기본 백업 저장소에 대한 배치 정책이 생성됩니다.
포함된 버킷 클래스가
NooBaa Pod
다음 NooBaa Pod가 생성 및 시작됩니다.
| 데이터베이스 (DB) | 이는 메타데이터, 통계, 이벤트 등을 포함하는 Postgres DB입니다. 그러나 저장되는 실제 데이터를 보유하지는 않습니다. |
| 코어 | 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 포드입니다. |
| 엔드포인트 |
이러한 포드는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고, 다양한 서비스와 통신하여 데이터를 작성하고 읽습니다. 엔드포인트는 |
경로
S3을 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
Service
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스용 서비스가 생성됩니다.
4.3.3.2. StorageSystem Creation
StorageCluster 생성의 일부로 odf-operator 는 스토리지 클러스터를 OpenShift Data Foundation에 노출하는 해당 StorageSystem CR을 자동으로 생성합니다.
5장. OpenShift Data Foundation 업그레이드 개요
OLM(Operator Lifecycle Manager)에서 관리하는 운영자 번들인 OpenShift Data Foundation은 해당 운영자를 활용하여 CSV( ClusterServiceVersion ) CR을 통해 제품을 설치하고 업그레이드하는 높은 수준의 작업을 수행합니다.
5.1. 업그레이드 워크플로
OpenShift Data Foundation은 다음 두 가지 유형의 업그레이드를 인식합니다. z-stream 릴리스 업그레이드 및 마이너 버전 릴리스 업그레이드. 이러한 두 업그레이드 경로에 대한 사용자 인터페이스 워크플로는 완전히 동일하지는 않지만 결과 동작은 상당히 유사합니다. 차이점은 다음과 같습니다.
Z-stream 릴리스의 경우 OCS는 redhat-operators CatalogSource 에 새 번들을 게시합니다. OLM은 이를 탐지하고 새 CSV에 대한 InstallPlan 을 생성하여 기존 CSV를 교체합니다. 서브스크립션 승인 전략(Automatic(자동) 또는 Manual(수동) 여부)은 OLM이 조정을 진행할지 또는 관리자 승인을 기다리는지 여부를 결정합니다.
마이너 버전 릴리스의 경우 OpenShift Container Storage는 redhat-operators CatalogSource 에 새 번들을 게시합니다. 차이점은 이 번들이 새 채널의 일부가 되며 채널 업그레이드가 자동으로 수행되지 않는다는 것입니다. 관리자는 새 릴리스 채널을 명시적으로 선택해야 합니다. 이 작업이 완료되면 OLM에서 이를 탐지하고 새 CSV에 대한 InstallPlan 을 생성하여 기존 CSV를 교체합니다. 채널 스위치는 수동 작업이므로 OLM에서 자동으로 조정을 시작합니다.
이후 업그레이드 프로세스는 동일합니다.
5.2. ClusterServiceVersion 조정
OLM에서 승인된 InstallPlan 을 감지하면 CSV를 조정하는 프로세스가 시작됩니다. 광범위하게 새 사양을 기반으로 Operator 리소스를 업데이트하고 새 CSV가 올바르게 설치되었는지 확인한 다음 이전 CSV를 삭제하면 됩니다. 업그레이드 프로세스에서는 Operator 배포로 업데이트를 푸시합니다. 그러면 새 CSV에 지정된 이미지를 사용하여 Operator Pod를 다시 시작합니다.
지정된 CSV를 변경하고 그러한 변경 사항이 관련 리소스로 전파되도록 할 수는 있지만 새 CSV로 업그레이드할 때 변경되지 않은 사양에 따라 새 CSV가 생성되므로 모든 사용자 정의 변경 사항이 손실됩니다.
5.3. Operator 조정
이 시점에서 OpenShift Data Foundation 피연산자의 조정이 OpenShift Data Foundation 설치 개요 에 정의된 대로 진행됩니다. Operator는 사용자 관련 리소스(예: StorageCluster)에 지정된 대로 예상 구성에 모든 관련 리소스가 있는지 확인합니다.
