Red Hat OpenShift Data Foundation 아키텍처
OpenShift Data Foundation 아키텍처 및 구성 요소 및 서비스에서 수행하는 역할을 설명합니다.
초록
머리말
이 문서에서는 OpenShift Data Foundation 아키텍처에 대한 개요를 제공합니다.
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 개선할 내용에 대해 알려주십시오. 피드백을 보내주시려면 다음을 확인하십시오.
특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.
- 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
- 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
- 표시된 지침을 따릅니다.
보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.
- Bugzilla 웹 사이트로 이동하십시오.
- 구성 요소 섹션에서 문서 를 선택합니다.
- 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
- 버그 제출을 클릭합니다.
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를 사용한 메시징이 있습니다.
- 다중 클라우드 개체 스토리지: 여러 클라우드 오브젝트 저장소에서 데이터를 추상화하고 데이터를 검색할 수 있는 경량 S3 API 엔드포인트를 제공합니다.
- 온프레미스 개체 스토리지의 경우 데이터 집약적인 애플리케이션을 대상으로 하는 10페타바이트 및 10억 개의 개체로 확장되는 강력한 S3 API 엔드포인트를 제공합니다. 예를 들어 Spark, Presto, Red Hat AMQ Streams(Kafka) 및 TensorFlow 및 Pytorch와 같은 머신 학습 프레임워크와 같은 애플리케이션을 사용하여 행, columnar, 반 구조 데이터의 저장 및 액세스가 포함됩니다.
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에서 내부적으로 실행할 수 있습니다.
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 Operator는 최소한의 관리자 개입으로 클러스터가 해당 상태에 있거나 해당 상태에 도달하는지 확인합니다.
3.1. OpenShift Data Foundation Operator
odf-operator 는 OpenShift Data Foundation의 "meta" 연산자로 설명할 수 있습니다. 즉, 다른 운영자에 영향을 주기 위한 운영자입니다.
odf-operator 에는 다음과 같은 주요 기능이 있습니다.
OpenShift Data Foundation을 구성하는 다른 운영자의 구성 및 버전 관리를 시행합니다. 이는 Operator 종속성과 서브스크립션 관리라는 두 가지 주요 메커니즘을 사용하여 이 작업을 수행합니다.
-
odf-operator번들은 다른 OLM Operator에 대한 종속성을 지정하여 항상 특정 버전에 설치되어 있는지 확인합니다. - 운영자 자체는 다른 모든 운영자의 서브스크립션을 관리하여 OLM에서 원하는 버전의 Operator를 설치할 수 있는지 확인합니다.
-
- OpenShift 콘솔에 대한 OpenShift Data Foundation 외부 플러그인을 제공합니다.
- 스토리지 솔루션을 OpenShift Console과 통합할 수 있는 API를 제공합니다.
3.1.1. components
odf-operator 는 ocs-operator 패키지에 종속되어 있습니다. 또한 mcg-operator 의 서브스크립션을 관리합니다. 또한 odf-operator 번들은 OpenShift 콘솔의 OpenShift Data Foundation 외부 플러그인에 대한 두 번째 배포를 정의합니다. 이는 OpenShift Container Platform Console에 직접 OpenShift Data Foundation 대시보드를 등록하고 통합하는 데 필요한 파일을 제공하는 nginx- 기반 Pod를 정의합니다.
3.1.2. 설계 다이어그램
이 다이어그램에서는 odf-operator 가 OpenShift Container Platform과 통합되는 방법을 보여줍니다.
그림 3.1. OpenShift Data Foundation Operator
3.1.3. Responsibilites
odf-operator는 다음 CRD를 정의합니다.
-
StorageSystem
StorageSystem CRD는 OpenShift Container Platform의 데이터 스토리지 및 서비스를 제공하는 기본 스토리지 시스템을 나타냅니다. Operator를 트리거하여 스토리지 시스템의 지정된 Kind 에 대한 서브스크립션 이 있는지 확인합니다.
3.1.4. 리소스
ocs-operator 는 지정된 StorageSystem의 사양에 대한 응답으로 다음 CR을 생성합니다.
Operator Lifecycle Manager 리소스
지정된 StorageSystem의 Kind를 정의하고 조정하는 Operator에 대한 생성합니다.
서브스크립션 을
3.1.5. 제한 사항
odf-operator 는 데이터 스토리지 또는 서비스 자체를 제공하지 않습니다. 다른 스토리지 시스템의 통합 및 관리 계층으로 존재합니다.
3.1.6. 고가용성
고가용성은 다른 대부분의 Operator와 유사한 odf-operator Pod의 기본 요구 사항이 아닙니다. 일반적으로 프로세스 배포 시 이점을 요구하거나 활용하는 작업이 없습니다. OpenShift Container Platform은 현재 Pod를 사용할 수 없거나 삭제될 때마다 교체 Pod를 빠르게 가동합니다.
3.1.7. 관련 구성 파일
odf-operator 는 Operator의 동작을 수정하는 데 사용할 수 있는 변수의 ConfigMap 과 함께 제공됩니다.
3.1.8. 관련 로그 파일
OpenShift Data Foundation에 대해 이해하고 문제를 해결하려면 다음을 확인할 수 있습니다.
- Operator Pod 로그
-
스토리지 시스템상태 - 기본 스토리지 시스템 CRD 상태
Operator Pod 로그
각 Operator는 발생하는 조정 및 오류에 대한 정보를 포함하는 표준 Pod 로그를 제공합니다. 이러한 로그에는 종종 필터링 및 무시될 수 있는 성공적인 조정에 대한 정보가 있습니다.
StorageSystem 상태 및 이벤트
StorageSystem CR은 CR 상태에 조정 세부 정보를 저장하고 관련 이벤트가 있습니다. StorageSystem 사양에는 관리자가 스토리지 시스템의 상태에 대한 추가 정보를 찾는 데 사용할 수 있는 실제 스토리지 시스템 CRD의 이름, 네임스페이스, Kind가 포함되어 있습니다.
3.1.9. 라이프 사이클
OpenShift Data Foundation 번들이 설치된 한 odf-operator 가 있어야 합니다. 이는 OpenShift Data Foundation CSV의 OLM 조정의 일부로 관리됩니다. Pod의 하나 이상의 인스턴스가 Ready 상태여야 합니다.
CRD와 같은 Operator 피연산자는 Operator의 라이프사이클에 영향을 미치지 않습니다. StorageSystems 생성 및 삭제는 운영자의 제어 범위를 벗어난 작업이며 적절한 API(애플리케이션 프로그래밍 인터페이스) 호출을 통해 관리자가 시작하거나 자동화해야 합니다.
3.2. OpenShift Container Storage Operator
ocs-operator 는 OpenShift Data Foundation의 "meta" 연산자로 설명할 수 있습니다. 즉, 다른 운영자에 영향을 미치고 다른 Operator가 제공하는 기능에 대한 구성 게이트웨이 역할을 합니다. 다른 운영자는 직접 관리하지 않습니다.
ocs-operator 에는 다음과 같은 주요 기능이 있습니다.
- 다른 Operator를 트리거하여 조정할 사용자 정의 리소스(CR)를 생성합니다.
- Ceph 및 Multicloud Object Gateway 구성을 추상화하고 이를 Red Hat에서 검증 및 지원하는 알려진 모범 사례로 제한합니다.
- 지원 정책에 따라 컨테이너화된 Ceph 및 NooBaa를 배포하는 데 필요한 리소스를 생성하고 조정합니다.
3.2.1. components
ocs-operator 에는 종속 구성 요소가 없습니다. 그러나 Operator는 CSV( ClusterServiceVersion )에 정의된 다른 Operator의 모든 CRD(사용자 정의 리소스 정의)의 존재 여부에 따라 달라집니다.
3.2.2. 설계 다이어그램
이 다이어그램에서는 OpenShift Container Storage를 OpenShift Container Platform과 통합하는 방법을 설명합니다.
그림 3.2. OpenShift Container Storage Operator
3.2.3. 자주하는 질문
두 개의 ocs-operator CRD는 다음과 같습니다.
-
OCSInitialization -
스토리지 클러스터
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 알고리즘은 StorageCluster 사양의 구성을 기반으로 CephCluster 및 NooBaa CRD를 추가로 생성합니다. Operator는 CephBlockPools,Routes 등과 같은 추가 CR도 생성합니다. 이러한 리소스는 OpenShift Container Storage의 다양한 기능을 활성화하는 데 필요합니다. 현재 OpenShift Container Platform 클러스터당 하나의 스토리지 클러스터 CR만 지원됩니다.
3.2.4. 리소스
ocs-operator 는 정의하는 CRD의 사양에 대한 응답으로 다음 CR을 생성합니다. 이러한 리소스 중 일부 구성을 재정의하여 생성된 사양을 변경하거나 모두 생성하지 않도록 할 수 있습니다.
- 일반 리소스
- 이벤트
- 조정에 대한 응답으로 필요한 경우 다양한 이벤트를 생성합니다.
- 영구 볼륨(PV)
- PV는 Operator에서 직접 생성되지 않습니다. 그러나 Operator는 Ceph CSI 드라이버에서 생성한 모든 PV를 추적하고 PV에 지원되는 기능에 대한 적절한 주석이 있는지 확인합니다.
- 빠른 시작
- OpenShift Container Platform 콘솔에 다양한 빠른 시작 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의 다른 Pod를 배포하거나 조정하지 않습니다. ocs-operator CSV는 Operator Deployments와 같은 최상위 구성 요소를 정의하고 OLM(Operator Lifecycle Manager)은 지정된 구성 요소를 조정합니다.
3.2.6. 고가용성
고가용성은 다른 대부분의 Operator와 유사한 ocs-operator Pod의 기본 요구 사항이 아닙니다. 일반적으로 프로세스 배포 시 이점을 요구하거나 활용하는 작업이 없습니다. OpenShift Container Platform은 현재 Pod를 사용할 수 없거나 삭제될 때마다 교체 Pod를 빠르게 가동합니다.
3.2.7. 관련 구성 파일
ocs-operator 구성은 완전히 CSV로 지정되며 CSV의 사용자 정의 빌드 없이 수정할 수 없습니다.
3.2.8. 관련 로그 파일
OpenShift Container Storage를 이해하고 문제를 해결하려면 다음을 확인할 수 있습니다.
- Operator Pod 로그
- StorageCluster 상태 및 이벤트
- OCSInitialization 상태
Operator Pod 로그
각 Operator는 발생하는 조정 및 오류에 대한 정보를 포함하는 표준 Pod 로그를 제공합니다. 이러한 로그에는 종종 필터링 및 무시될 수 있는 성공적인 조정에 대한 정보가 있습니다.
StorageCluster 상태 및 이벤트
StorageCluster CR은 CR 상태에 조정 세부 정보를 저장하고 관련 이벤트가 있습니다. 상태에는 예상되는 컨테이너 이미지의 섹션이 포함되어 있습니다. 다른 Operator의 Pod 및 현재 감지하는 이미지에 존재할 것으로 예상되는 컨테이너 이미지가 표시됩니다. 이렇게 하면 OpenShift Container Storage 업그레이드가 완료되었는지 확인하는 데 도움이 됩니다.
OCSInitialization 상태
이 상태는 초기화 작업이 성공적으로 완료되었는지를 표시합니다.
3.2.9. 라이프 사이클
OpenShift Container Storage 번들이 설치된 경우 ocs-operator 가 있어야 합니다. 이는 OpenShift Container Storage CSV의 OLM 조정의 일부로 관리됩니다. Pod의 하나 이상의 인스턴스가 Ready 상태여야 합니다.
CRD와 같은 Operator 피연산자는 Operator의 라이프사이클에 영향을 미치지 않습니다. OCSInitialization CR은 항상 있어야 합니다. Operator가 없는 경우 이를 생성합니다. 스토리지 클러스터 생성 및 삭제는 Operator의 제어 범위를 벗어난 작업이며 관리자가 시작하거나 적절한 API 호출을 통해 자동화해야 합니다.
3.3. rook-Ceph Operator
rook-Ceph Operator는 OpenShift Data Foundation의 Ceph용 Rook 연산자입니다. rook을 사용하면 OpenShift Container Platform에서 Ceph 스토리지 시스템을 실행할 수 있습니다.
Rook-Ceph Operator는 스토리지 클러스터를 자동으로 부트스트랩하고 스토리지 데몬을 모니터링하여 스토리지 클러스터가 정상인지 확인하는 간단한 컨테이너입니다.
3.3.1. components
Rook-Ceph Operator는 OpenShift Data Foundation 배포의 일부로 여러 구성 요소를 관리합니다.
- Ceph-CSI 드라이버
-
Operator는 두 드라이버 각각에 대한 프로비저너, RADOS 블록 장치(RBD) 및 Ceph 파일 시스템(CephFS) 및 두 드라이버 각각에 대해 볼륨 플러그인
데몬세트를 포함하여 CSI 드라이버를 생성하고 업데이트합니다. - Ceph 데몬
- Mons
- 모니터(mons)는 Ceph의 핵심 메타데이터 저장소를 제공합니다.
- OSDs
- OSD(오브젝트 스토리지 데몬)는 기본 장치에 데이터를 저장합니다.
- mgr
- manager(mgr)는 지표를 수집하고 Ceph에 기타 내부 기능을 제공합니다.
- RGW
- RADOS 게이트웨이(RGW)는 오브젝트 저장소에 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 Operator는 스토리지 클러스터를 부트스트랩하고 모니터링하는 컨테이너입니다. 다음과 같은 기능을 수행합니다.
- 스토리지 구성 요소의 구성을 자동화합니다.
- 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 Operator 이미지에는 클러스터를 관리하는 데 필요한 모든 도구가 포함되어 있습니다. 데이터 경로는 변경되지 않습니다. 그러나 Operator가 모든 Ceph 구성을 노출하지는 않습니다. 배치 그룹 및 crush 맵과 같은 많은 Ceph 기능은 사용자에게 숨겨져 있으며 물리적 리소스, 풀, 볼륨, 파일 시스템 및 버킷 측면에서 더 나은 사용자 환경을 제공합니다.
3.3.4. 리소스
rook-Ceph Operator는 openshift-storage 네임스페이스에서 생성하는 모든 리소스에 소유자 참조를 추가합니다. 클러스터가 제거되면 소유자 참조에서 리소스가 모두 정리되도록 합니다. 여기에는 configmaps, 보안,서비스,배포,데몬 세트 등과 같은 OpenShift Container Platform 리소스가 포함됩니다.
Rook-Ceph Operator는 CephCluster,CephObjectStore,CephFilesystem, CephBlockPool 가 포함된 OpenShift Data Foundation에 의해 결정된 설정을 구성하기 위해 CR을 조사합니다.
3.3.5. 라이프 사이클
rook-Ceph Operator는 Ceph 클러스터에서 다음 Pod의 라이프사이클을 관리합니다.
- rook operator
- 클러스터의 조정이 포함된 단일 Pod입니다.
- RBD CSI 드라이버
- 단일 배포에서 관리하는 두 개의 프로비저너 Pod
-
데몬세트에서 관리하는 노드당 하나의 플러그인 Pod입니다.
- CephFS CSI 드라이버
- 단일 배포에서 관리하는 두 개의 프로비저너 Pod
-
데몬세트에서 관리하는 노드당 하나의 플러그인 Pod입니다.
- 모니터(mons)
3개의 mon pod, 각각 자체 배포가 있습니다.
- 확장 클러스터
- 5개의 mon pod를 포함하고, 하나는 arbiter 영역에, 다른 두 개의 데이터 영역에 각각 2개가 포함됩니다.
- 관리자 (mgr)
클러스터에 대한 단일 mgr Pod가 있습니다.
- 확장 클러스터
- 두 개의 mgr Pod(OpenShift Data Foundation 4.8로 시작) 두 개(arbiter 이외의 영역)가 있습니다.
- 개체 스토리지 데몬(OSD)
- 처음에 클러스터에서 3개 이상의 OSD가 생성됩니다. 클러스터가 확장되면 더 많은 OSD가 추가됩니다.
- 메타데이터 서버(MDS)
- CephFS 메타데이터 서버에는 단일 Pod가 있습니다.
- RADOS 게이트웨이(RGW)
- Ceph RGW 데몬에는 단일 Pod가 있습니다.
3.4. MCG Operator
MCG(Multicloud Object Gateway) Operator는 OpenShift Data Foundation Operator 및 Rook-Ceph Operator와 함께 OpenShift Data Foundation의 운영자입니다. MCG Operator는 독립 실행형 Operator로 업스트림에서 사용할 수 있습니다.
MCG 연산자는 다음과 같은 주요 기능을 수행합니다.
- OpenShift Data Foundation 내에서 MCG(Multicloud Object Gateway) 구성 요소를 제어하고 조정합니다.
- 오브젝트 버킷 클레임, 버킷 클래스 및 백업 저장소와 같은 새 사용자 리소스를 관리합니다.
- 기본 out-of-the-box 리소스를 생성합니다.
몇 가지 구성 및 정보는 OpenShift Data Foundation Operator를 통해 MCG Operator에 전달됩니다.
3.4.1. components
MCG 연산자에는 하위 구성 요소가 없습니다. 그러나 이를 통해 제어되는 다양한 리소스에 대한 조정 루프로 구성됩니다.
MCG Operator에는 CLI(명령줄 인터페이스)가 있으며 OpenShift Data Foundation의 일부로 사용할 수 있습니다. 다양한 리소스를 생성, 삭제 및 쿼리할 수 있습니다. 이 CLI는 YAML 파일을 직접 적용하는 것과 달리 구성을 적용하기 전에 입력 스anitation 및 status validation 계층을 추가합니다.
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 버전의 설명서를 참조하십시오.
네임스페이스 저장소
네임스페이스 버킷에 사용되는 리소스입니다. 배포 중에 기본값이 생성되지 않습니다.
버킷 클래스
새로 프로비저닝된 버킷의 기본 또는 초기 정책입니다. 버킷 클래스에 다음 정책이 설정됩니다.
- 배치 정책
버킷에 연결할 백업 저장소를 지정하고 버킷의 데이터를 작성하는 데 사용됩니다. 이 정책은 데이터 버킷 및 캐시 정책에 사용되어 로컬 캐시 배치를 나타냅니다. 배치 정책의 두 가지 모드가 있습니다.
- 스프레드. 정의된 백업 저장소에서 데이터를 제거
- mirror. 각 백업 저장소에 전체 복제본 생성
- 네임스페이스 정책
- 집계에 사용되는 리소스 및 쓰기 대상에 사용되는 리소스를 정의하는 네임스페이스 버킷에 대한 정책입니다.
- 캐시 정책
- 버킷에 대한 정책이며 허브( truth의 소스)와 캐시 항목의 라이브 시간(TTL)을 설정합니다.
기본 버킷 클래스는 배포 중에 생성되며 기본 백업 저장소를 사용하는 배치 정책으로 설정됩니다. 추가할 수 있는 버킷 클래스 수에는 제한이 없습니다.
지원되는 정책 유형을 확인하려면 특정 OpenShift Data Foundation 버전의 설명서를 참조하십시오.
개체 버킷 클레임(OBC)
S3 버킷 프로비저닝을 활성화하는 CRD입니다. MCG를 사용하면 OBCs는 버킷의 초기 구성을 기록하기 위한 선택적 버킷 클래스를 수신합니다. 버킷 클래스를 제공하지 않으면 기본 버킷 클래스가 사용됩니다.
NooBaa, Pod 상태 저장 세트 CRD
DB Pod, 코어 Pod, 끝점과 같은 NooBaa 배포의 다양한 Pod를 제어하는 내부 CRD입니다. 이 CRD는 내부이므로 변경할 수 없습니다. 이 Operator는 다음 엔터티를 조정합니다.
- DB Pod SCC
- OpenShift Container Platform과 NooBaa 사용자 인터페이스 간의 SSO SSO SSO SSO SSO SSO(Single Sign-On)를 허용하는 역할 바인딩 및 서비스 계정
- S3 액세스 경로
- OpenShift Container Platform에서 가져와 서명하고 서명하고 S3 경로에 설정된 인증서
Prometheus 규칙 및 서비스 모니터링
이러한 CRD는 MCG에서 지원하는 Prometheus 및 경고 규칙에 대한 스크랩 포인트를 설정합니다.
HPA(Horizontal Pod Autoscaler)
MCG 끝점과 통합됩니다. CPU 압력(S3 트래픽의 마운트)에 따라 끝점 Pod를 확장 및 축소합니다.
3.4.3. 고가용성
운영자로서 제공되는 유일한 고가용성은 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은 여러 Operator가 관리하는 여러 구성 요소로 구성됩니다.
4.1. 설치된 Operator
Operator Hub에서 OpenShift Data Foundation을 설치하면 다음과 같은 4개의 개별 배포가 생성됩니다.
-
ODF-operator :
odf-operator -
OCS-operator : 동일한 컨테이너에서
ocs-operator및 해당metricsPod를 정의합니다.-exporter에 대한 프로세스를 실행하는ocs-operator -
rook-ceph-operator:rook-ceph-operatorPod를 정의합니다. -
mcg-operator:mcg-operatorPod를 정의합니다.
이러한 Operator는 독립적으로 실행되며 다른 운영자가 조사한 고객 리소스(CR)를 생성하여 서로 상호 작용합니다. ocs-operator 는 주로 CR을 생성하여 Ceph 스토리지 및 Multicloud Object Gateway를 구성합니다. mcg-operator 에서 구성 요소에서 사용할 Ceph 볼륨을 생성하는 경우가 있습니다.
4.2. OpenShift Container Storage 초기화
OpenShift Data Foundation 번들은 OpenShift Container Platform 콘솔에 외부 플러그인을 정의하여 콘솔에서 사용할 수 없는 새로운 화면과 기능을 추가합니다. 이 플러그인은 설치시 OLM이 생성한 Deployment에 의해 관리되는 odf-console-plugin Pod에서 웹 서버로 실행됩니다.
ocs-operator 는 OCSInitialization CR을 자동으로 생성합니다. 어떤 시점에서든 하나의 OCSInitialization CR만 존재합니다. 단일 StorageCluster 범위로 제한되지 않는 ocs-operator 동작을 제어하지만 한 번만 수행합니다. OCSInitialization CR을 삭제하면 ocs-operator 에서 다시 생성하고 초기화 작업을 다시 트리거할 수 있습니다.
OCSInitialization CR은 다음 동작을 제어합니다.
- SCC(
SecurityContextConstraints) -
OCSInitializationCR이 생성된 후ocs-operator는 구성 요소 Pod에서 사용할 다양한 SCC를 생성합니다. - Ceph Toolbox Deployment
-
OCSInitialization을 사용하여 고급 Ceph 작업을 위해 Ceph Toolbox 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은 설치당 StorageCluster 단일 스토리지 클러스터를 지원합니다. 첫 번째 후 생성된 StorageCluster CR은 ocs-operator 조정에서 무시합니다.
OpenShift Data Foundation에서는 다음과 같은 세 가지 스토리지 클러스터 구성을 허용합니다.
- 내부
-
내부 모드에서는 모든 구성 요소가 OpenShift Container Platform 클러스터 내에서 컨테이너화된 컨테이너를 실행하고 설치 마법사의 관리자가 지정한
StorageClass에 대해 생성된 동적으로 프로비저닝된 PV(영구 볼륨)를 사용합니다. - 내부 연결
-
이 모드는 내부 모드와 유사하지만 관리자가 Ceph가 백업 스토리지에 사용하는 클러스터 노드에 직접 연결된 로컬 스토리지 장치를 정의해야 합니다. 또한 관리자는
StorageClass를 제공하기 위해 로컬 스토리지 Operator가 조정하는 CR을 생성해야 합니다.ocs-operator는 이StorageClass를 Ceph의 백업 스토리지로 사용합니다. - 외부
- 이 모드에서는 애플리케이션이 PV를 생성할 수 있는 외부 OpenShift Container Storage 설치에 대한 연결이 대신 OpenShift Container Platform 클러스터 내에서 Ceph 구성 요소가 실행되지 않습니다. 다른 구성 요소는 필요에 따라 클러스터 내에서 실행됩니다.
MCG 독립 실행형: 이 모드에서는 Ceph 클러스터 제공 없이 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 데몬이 너무 긴 기간(10분) 동안 다운된 경우 Rook은 전체 쿼럼을 완전히 복원할 수 있도록 그 자리에 새로운 몬 을 시작합니다.
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 배포 |
RGW가 존재하는 경우 |
| 앞서 언급한 배포 중 어느 것도 적용되지 않습니다. |
|
기본 버킷 클래스
기본 백업 저장소에 대한 배치 정책이 있는 BucketClass 가 생성됩니다.
NooBaa Pod
다음 NooBaa Pod가 생성되고 시작됩니다.
| 데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 이는 저장되는 실제 데이터를 보유하지 않습니다. |
| 코어 | 이 Pod는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리합니다. |
| 끝점 |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고 데이터를 작성하고 읽는 등의 다양한 서비스와 통신합니다. 끝점은 |
경로
NooBaa S3 인터페이스의 경로는 S3를 사용하는 애플리케이션에 대해 생성됩니다.
Service
NooBaa S3 인터페이스에 대한 서비스는 S3를 사용하는 애플리케이션에 대해 생성됩니다.
4.3.2. 외부 모드 스토리지 클러스터
외부 스토리지 클러스터의 경우 ocs-operator 는 약간 다른 설정 프로세스를 따릅니다. ocs-operator 는 관리자 또는 콘솔 중 하나에서 생성해야 하는 rook-ceph-external-cluster-details ConfigMap 이 있는지 찾습니다. ConfigMap 을 생성하는 방법에 대한 자세한 내용은 외부 모드를 위한 OpenShift Data Foundation 클러스터 생성을 참조하십시오. 그런 다음 ocs-operator 는 ConfigMap 에 지정된 대로 다음 리소스 중 일부 또는 모두를 생성합니다.
| 외부 Ceph 구성 |
외부 |
| 외부 Ceph 자격 증명 보안 | 외부 Ceph 인스턴스에 연결할 자격 증명이 포함된 시크릿입니다. |
| 외부 Ceph StorageClasses | RBD, CephFS 및/또는 RGW에 대한 볼륨 생성을 활성화하는 하나 이상의 StorageClasses. |
| CephFS CSI 드라이버 활성화 |
|
| Ceph RGW 구성 | RGW StorageClass가 지정된 경우 다양한 Ceph Object CR을 생성하여 Ceph RGW 오브젝트 스토리지 끝점에 대한 액세스를 활성화하고 제공합니다. |
ConfigMap 에 지정된 리소스를 생성한 후 스토리지 클러스터 생성 프로세스는 다음과 같이 진행됩니다.
|
|
|
|
|
애플리케이션이 Ceph 볼륨의 |
|
|
|
빠른 시작: 콘솔에 빠른 시작 가이드를 표시하는 빠른 시작 CR을 생성합니다.
4.3.2.1. 클러스터 생성
CephCluster CR이 외부 모드로 생성될 때 Rook Operator는 다음 작업을 수행합니다.
-
Operator는 원격 Ceph 클러스터에 연결을 사용할 수 있는지 확인합니다. 연결에
monendpoint 및 secret을 로컬 클러스터로 가져와야 합니다. -
CSI 드라이버는 Ceph에 원격 연결을 통해 구성됩니다. 내부 모드에서 구성된 경우 RBD 및
CephFS프로비저너s 및 볼륨 플러그인은 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 배포 |
RGW가 존재하는 경우 |
| 앞서 언급한 배포 중 어느 것도 적용되지 않습니다. |
|
기본 버킷 클래스
기본 백업 저장소에 대한 배치 정책이 있는 BucketClass 가 생성됩니다.
NooBaa Pod
다음 NooBaa Pod가 생성되고 시작됩니다.
| 데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 이는 저장되는 실제 데이터를 보유하지 않습니다. |
| 코어 | 이 Pod는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리합니다. |
| 끝점 |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고 데이터를 작성하고 읽는 등의 다양한 서비스와 통신합니다. 끝점은 |
경로
NooBaa S3 인터페이스의 경로는 S3를 사용하는 애플리케이션에 대해 생성됩니다.
Service
NooBaa S3 인터페이스에 대한 서비스는 S3를 사용하는 애플리케이션에 대해 생성됩니다.
4.3.3. MCG 독립 실행형 스토리지 클러스터
이 모드에서는 Ceph 클러스터가 생성되지 않습니다. 대신 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 배포 |
RGW가 존재하는 경우 |
| 앞서 언급한 배포 중 어느 것도 적용되지 않습니다. |
|
기본 버킷 클래스
기본 백업 저장소에 대한 배치 정책이 있는 BucketClass 가 생성됩니다.
NooBaa Pod
다음 NooBaa Pod가 생성되고 시작됩니다.
| 데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 이는 저장되는 실제 데이터를 보유하지 않습니다. |
| 코어 | 이 Pod는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리합니다. |
| 끝점 |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하고 데이터를 작성하고 읽는 등의 다양한 서비스와 통신합니다. 끝점은 |
경로
NooBaa S3 인터페이스의 경로는 S3를 사용하는 애플리케이션에 대해 생성됩니다.
Service
NooBaa S3 인터페이스에 대한 서비스는 S3를 사용하는 애플리케이션에 대해 생성됩니다.
4.3.3.2. 스토리지 시스템 생성
스토리지 클러스터 생성의 일부로 odf-operator 는 OpenShift Data Foundation에 스토리지 클러스터를 노출하는 해당 StorageSystem CR을 자동으로 생성합니다.
5장. OpenShift Data Foundation 업그레이드 개요
OLM(Operator Lifecycle Manager)에서 관리하는 Operator 번들로 OpenShift Data Foundation은 Operator를 활용하여 CSV( ClusterServiceVersion ) CR을 통해 제품을 설치 및 업그레이드하는 고급 작업을 수행합니다.
5.1. 업그레이드 워크플로
OpenShift Data Foundation은 Z-stream 릴리스 업그레이드 및 마이너 버전 릴리스 업그레이드의 두 가지 유형의 업그레이드를 인식합니다. 이러한 두 업그레이드 경로에 대한 사용자 인터페이스 워크플로는 거의 같지 않지만 결과 동작은 매우 유사합니다. 차이점은 다음과 같습니다.
Z-stream 릴리스의 경우 OCS는 redhat-operators CatalogSource 에 새 번들을 게시합니다. OLM은 이를 감지하고 새 CSV에 대한 InstallPlan 을 생성하여 기존 CSV를 교체합니다. 자동 또는 수동이든 서브스크립션 승인 전략은 OLM이 조정을 진행할지 아니면 관리자 승인을 기다리는지 여부를 결정합니다.
마이너 버전 릴리스의 경우 OpenShift Container Storage는 redhat-operators CatalogSource 에 새 번들도 게시합니다. 차이점은 이 번들이 새 채널의 일부가 되고 채널 업그레이드가 자동이 아니라는 점입니다. 관리자는 새 릴리스 채널을 명시적으로 선택해야 합니다. 이 작업이 완료되면 OLM에서 이를 감지하고 새 CSV에 대한 InstallPlan 을 생성하여 기존 CSV를 교체합니다. 채널 스위치는 수동 작업이므로 OLM은 조정을 자동으로 시작합니다.
이 시점에서 업그레이드 프로세스는 동일합니다.
5.2. ClusterServiceVersion Reconciliation
OLM에서 승인된 InstallPlan 을 감지하면 CSV 조정 프로세스를 시작합니다. 대체로 새 사양을 기반으로 Operator 리소스를 업데이트하고 새 CSV 설치를 올바르게 확인한 다음 이전 CSV를 삭제하여 이 작업을 수행합니다. 업그레이드 프로세스에서 Operator Deployments에 업데이트를 내보내면 새 CSV에 지정된 이미지를 사용하여 Operator Pod를 다시 시작할 수 있습니다.
지정된 CSV를 변경하고 이러한 변경 사항이 관련 리소스로 전파되도록 할 수는 있지만 새 CSV는 변경되지 않은 사양에 따라 새 CSV가 생성되므로 새 CSV가 손실됩니다.
5.3. Operator 조정
이 시점에서 OpenShift Data Foundation 피연산자의 조정은 OpenShift Data Foundation 설치 개요 에 정의된 대로 진행됩니다. Operator는 사용자 지향 리소스(예: 스토리지 클러스터)에 지정된 대로 예상되는 구성에 모든 관련 리소스가 있는지 확인합니다.
