Red Hat SummitRed Hat OpenShift Data Foundation 아키텍처
OpenShift Data Foundation 아키텍처 및 구성 요소 및 서비스가 수행하는 역할에 대한 개요입니다.
초록
머리말
이 문서에서는 OpenShift Data Foundation 아키텍처에 대한 개요를 제공합니다.
보다 포괄적 수용을 위한 오픈 소스 용어 교체
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 서비스는 주로 다음 구성 요소를 나타내는 스토리지 클래스를 통해 애플리케이션에서 사용할 수 있습니다.
- 주로 데이터베이스 워크로드에 제공하는 블록 스토리지 장치입니다. 여기에는 Red Hat OpenShift Container Platform 로깅 및 모니터링, PostgreSQL이 포함됩니다.
블록 스토리지는 여러 컨테이너에서 데이터를 공유할 필요가 없는 경우에만 모든 워크로드에 사용해야 합니다.
- 공유 및 분산 파일 시스템으로, 주로 소프트웨어 개발, 메시징 및 데이터 집계 워크로드를 제공합니다. 예를 들어 Jenkins 빌드 소스 및 아티팩트, Wordpress 업로드 콘텐츠, Red Hat OpenShift Container Platform 레지스트리 및 JBoss AMQ를 사용한 메시징이 있습니다.
- Multicloud 오브젝트 스토리지: 여러 클라우드 오브젝트 저장소의 스토리지를 추상화하고 데이터를 검색할 수 있는 경량 S3 API 엔드포인트를 제공합니다.
- 온프레미스 오브젝트 스토리지에서는 주로 데이터 집약적 애플리케이션을 대상으로 수십 페타바이트 및 10억 개의 개체로 확장되는 강력한 S3 API 엔드포인트를 제공합니다. 예를 들어 row, columnar, presto, Red Hat AMQ Streams(Kafka)와 TensorFlow 및 Pytorch와 같은 시스템 학습 프레임워크가 포함된 데이터 저장 및 액세스 등이 있습니다.
CephFS 영구 볼륨에서 PostgresSQL 워크로드를 실행할 수 없으며 RADOS Block Device(RBD) 볼륨을 사용하는 것이 좋습니다. 자세한 내용은 ODF 데이터베이스 워크로드 CephFS PV/PVC를 사용하지 않는 지식베이스 솔루션을 참조하십시오.
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 번들로 구성되며, 작업 및 리소스 특성을 쉽게 자동화할 수 있도록 관리 작업 및 사용자 정의 리소스를 통합하는 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
odf-operator 는 OpenShift Data Foundation의 "meta" Operator, 즉 다른 운영자에게 영향을 미치는 운영자로 설명할 수 있습니다.
odf-operator 에는 다음과 같은 주요 기능이 있습니다.
OpenShift Data Foundation을 구성하는 다른 Operator의 구성 및 버전 관리를 적용합니다. Operator 종속 항목 및 서브스크립션 관리의 두 가지 기본 메커니즘을 사용하여 이 작업을 수행합니다.
-
odf-operator번들은 다른 OLM Operator의 종속성을 지정하여 특정 버전에 항상 설치되었는지 확인합니다. - Operator 자체에서는 다른 모든 Operator에 대해 서브스크립션을 관리하여 OLM에서 원하는 Operator 버전을 설치할 수 있는지 확인합니다.
-
- OpenShift Console에 대한 OpenShift Data Foundation 외부 플러그인을 제공합니다.
- 스토리지 솔루션을 OpenShift 콘솔과 통합하는 API를 제공합니다.
3.1.1. components
odf-operator 는 ocs-operator 패키지에 종속되어 있습니다. 또한 mcg-operator 의 서브스크립션을 관리합니다. 또한 odf-operator 번들은 OpenShift Console의 OpenShift Data Foundation 외부 플러그인에 대한 두 번째 배포를 정의합니다. 이는 OpenShift Container Platform 콘솔에 직접 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를 트리거하여 지정된 유형의 스토리지 시스템에 대한 서브스크립션 이 있는지 확인합니다.
3.1.4. Resources
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 로그
-
StorageSystem상태 - 기본 스토리지 시스템 CRD 상태
Operator Pod 로그
각 Operator는 조정 및 오류 발생에 대한 정보를 포함하는 표준 Pod 로그를 제공합니다. 이러한 로그에는 종종 필터링 및 무시할 수 있는 성공적인 조정에 대한 정보가 있습니다.
StorageSystem 상태 및 이벤트
StorageSystem CR은 조정 세부 사항을 CR 상태에 저장하고 관련 이벤트가 있습니다. StorageSystem 의 사양에는 실제 스토리지 시스템의 CRD의 name, namespace 및 Kind가 포함되어 있습니다. 이 CRD는 관리자가 스토리지 시스템의 상태에 대한 추가 정보를 찾는 데 사용할 수 있습니다.
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로 설명할 수 있습니다. 즉, 다른 Operator에 영향을 미치고 다른 운영자가 제공하는 기능에 대한 구성 게이트웨이 역할을 합니다. 다른 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 -
StorageCluster
OCSInitialization 은 Operator 수준에서 적용되는 작업을 캡슐화하는 데 사용되는 단일ton 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 클러스터당 하나의 StorageCluster CR만 지원됩니다.
3.2.4. Resources
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 상태에 저장하고 관련 이벤트가 있습니다. status에는 예상되는 컨테이너 이미지의 섹션이 포함되어 있습니다. 다른 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가 없는 경우 이를 생성합니다. StorageClusters 생성 및 삭제는 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 Driver
-
Operator는 두 드라이버 각각에 대한 프로비저너, RADOS 블록 장치(RBD) 및 Ceph 파일 시스템(CephFS)과 두 드라이버 각각에 대한 볼륨 플러그인
데몬세트를 포함하여 CSI 드라이버를 생성하고 업데이트합니다. - Ceph 데몬
- Mons
- 모니터(mons)는 Ceph에 코어 메타데이터 저장소를 제공합니다.
- OSDs
- OSD(오브젝트 스토리지 데몬)는 기본 장치에 데이터를 저장합니다.
- gr
- 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. Resources
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 Driver
- 단일 배포에서 관리하는 두 개의 프로비저너 Pod
-
데몬 세트에서 관리하는 노드당 하나의 플러그인 Pod
.
- CephFS CSI Driver
- 단일 배포에서 관리하는 두 개의 프로비저너 Pod
-
데몬 세트에서 관리하는 노드당 하나의 플러그인 Pod
.
- 모니터(mons)
3개의 mon 포드, 각각 자체 배포가 있습니다.
- 클러스터 확장
- 5 개의 mon 포드를 포함합니다. 하나는 중재자 영역에 하나씩, 다른 두 데이터 영역 각각에 두 개의 포드가 있습니다.
- Manager(mgr)
클러스터에 대한 단일 mgr Pod가 있습니다.
- 클러스터 확장
- 두 개의 mgr Pod (OpenShift Data Foundation 4.8로 시작)가 두 개 있으며, 두 개의 비 하이퍼 영역 각각에 하나씩 있습니다.
- 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 Operator는 다음과 같은 주요 기능을 수행합니다.
- OpenShift Data Foundation 내에서 MCG(Multicloud Object Gateway) 구성 요소를 제어하고 조정합니다.
- 오브젝트 버킷 클레임, 버킷 클래스, 백업 저장소와 같은 새 사용자 리소스를 관리합니다.
- 기본 리소스를 생성합니다.
몇 가지 구성 및 정보는 OpenShift Data Foundation Operator를 통해 MCG 운영자에게 전달됩니다.
3.4.1. components
MCG Operator에는 하위 구성 요소가 없습니다. 그러나 이 루프는 제어되는 다양한 리소스에 대한 조정 반복문으로 구성됩니다.
MCG Operator에는 CLI(명령줄 인터페이스)가 있으며 OpenShift Data Foundation의 일부로 사용할 수 있습니다. 다양한 리소스를 생성, 삭제 및 쿼리할 수 있습니다. 이 CLI는 구성이 YAML 파일을 직접 적용하는 것과 달리 입력 sanitation 및 status 검증 계층을 추가합니다.
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 버전에 대한 설명서를 참조하십시오.
네임스페이스 저장소
네임스페이스 버킷에 사용되는 리소스입니다. 배포 중에 기본값이 생성되지 않습니다.
BucketClass
새로 프로비저닝된 버킷의 기본 또는 초기 정책입니다. 다음 정책은 bucketclass에 설정됩니다.
- 배치 정책
버킷에 연결할 백업 저장소를 나타내며 버킷의 데이터를 작성하는 데 사용됩니다. 이 정책은 데이터 버킷과 캐시 정책에 사용되어 로컬 캐시 배치를 나타냅니다. 배치 정책의 두 가지 모드가 있습니다.
- 확산. 정의된 백업 저장소에서 데이터를 제거
- 미러. 각 백업 저장소에 전체 복제본 생성
- 네임스페이스 정책
- 집계에 사용되는 리소스와 쓰기 대상에 사용되는 리소스를 정의하는 네임스페이스 버킷에 대한 정책입니다.
- 캐시 정책
- 이는 버킷에 대한 정책이며 캐시 항목에 대한 허브(위 정보 소스)와 라이브 시간(TTL)을 설정합니다.
기본 버킷 클래스는 배포 중에 생성되며 기본 백업 저장소를 사용하는 배치 정책으로 설정됩니다. 추가할 수 있는 버킷 클래스 수에는 제한이 없습니다.
지원되는 정책 유형을 확인하려면 특정 OpenShift Data Foundation 버전 설명서를 참조하십시오.
오브젝트 버킷 클레임(OBC)
S3 버킷의 프로비저닝을 활성화하는 CRD입니다. MCG에서는 MCG를 사용하면 버킷의 초기 구성을 기록하기 위해 선택적 버킷 클래스를 수신합니다. 버킷 클래스를 제공하지 않으면 기본 버킷 클래스가 사용됩니다.
NooBaa, Pod 상태 저장 세트 CRD
DB Pod, 코어 Pod, 끝점과 같은 NooBaa 배포의 다른 Pod를 제어하는 내부 CRD입니다. 이 CRD는 내부이므로 변경하지 않아야 합니다. 이 Operator는 다음 엔티티를 조정합니다.
- DB Pod SCC
- OpenShift Container Platform 및 NooBaa 사용자 인터페이스 간에 SSO Single Sign-On을 허용하는 역할 바인딩 및 서비스 계정
- S3 액세스 경로
- OpenShift Container Platform에서 가져와서 서명한 인증서로 S3 경로에 설정됩니다.
Prometheus 규칙 및 서비스 모니터링
이러한 CRD는 MCG에서 지원하는 Prometheus 및 경고 규칙에 대한 스크랩 지점을 설정합니다.
HPA(Horizontal Pod Autoscaler)
이는 MCG 엔드포인트와 통합됩니다. 끝점 Pod는 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은 여러 Operator가 관리하는 여러 구성 요소로 구성됩니다.
4.1. 설치된 Operator
Operator Hub에서 OpenShift Data Foundation을 설치하면 다음과 같은 네 가지 배포가 생성됩니다.
-
ODF-operator:odf-operatorPod를 정의합니다. -
OCS-operator: 동일한 컨테이너에서
ocs-operator및 해당metricsPod를 정의합니다.-exporter에 대한 프로세스를 실행하는ocs-operator -
rook-ceph-operator:rook-ceph-operatorPod를 정의합니다. -
mcg-operator:mcg-operatorPod를 정의합니다.
이러한 Operator는 다른 운영자가 감시하는 고객 리소스(CR)를 생성하여 독립적으로 실행되며 상호 작용합니다. ocs-operator 는 주로 Ceph 스토리지 및 Multicloud Object Gateway를 구성하기 위해 CR을 생성합니다. 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은 다음 동작을 제어합니다.
SecurityContextConstraints(SCC)-
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는 자체 스토리지 기능을 제공하지 않으며 원하는 스토리지 구성을 정의해야 합니다.
Operator를 설치한 후 OpenShift Container Platform 콘솔 마법사 또는 CLI 및 ocs-operator 에서 이 StorageCluster 를 조정하여 새 StorageCluster 를 생성합니다. OpenShift Data Foundation은 설치당 단일 StorageCluster 를 지원합니다. 첫 번째 후 생성된 StorageCluster CR은 ocs-operator 조정에 의해 무시됩니다.
OpenShift Data Foundation에서는 다음과 같은 StorageCluster 구성을 허용합니다.
- 내부
-
내부 모드에서 모든 구성 요소는 OpenShift Container Platform 클러스터 내에서 컨테이너화되어 있으며 설치 마법사의 관리자가 지정한
StorageClass에 대해 동적으로 프로비저닝된 PV(영구 볼륨)를 사용합니다. - 내부 연결
-
이 모드는 내부 모드와 유사하지만 관리자는 Ceph가 백업 스토리지에 사용하는 클러스터 노드에 직접 연결된 로컬 스토리지 장치를 정의해야 합니다. 또한 관리자는
StorageClass를 제공하기 위해 로컬 스토리지 Operator가 조정하는 CR을 생성해야 합니다.ocs-operator는 이StorageClass를 Ceph의 백업 스토리지로 사용합니다. - 외부
- 이 모드에서 Ceph 구성 요소는 애플리케이션이 PV를 생성할 수 있는 외부 OpenShift Container Storage 설치에 연결하는 대신 OpenShift Container Platform 클러스터 내에서 실행되지 않습니다. 다른 구성 요소는 필요에 따라 클러스터 내에서 실행됩니다.
- MCG 독립 실행형
- 이 모드를 사용하면 CephCluster가 제공되지 않고 Multicloud Object Gateway 시스템을 쉽게 설치할 수 있습니다.
StorageCluster CR을 찾은 후 ocs-operator 는 이를 검증하고 후속 리소스를 생성하여 스토리지 구성 요소를 정의하기 시작합니다.
4.3.1. 내부 모드 스토리지 클러스터
내부 및 내부 연결 스토리지 클러스터 모두 다음과 같은 설정 프로세스를 갖습니다.
|
| 클러스터 애플리케이션이 Ceph 볼륨을 생성하는 데 사용하는 스토리지 클래스를 생성합니다. |
|
| 클러스터 애플리케이션이 Ceph 볼륨의 스냅샷을 생성하는 데 사용하는 볼륨 스냅샷 클래스를 만듭니다. |
| Ceph RGW 구성 | Ceph RGW 오브젝트 스토리지 끝점에 대한 액세스를 활성화하고 제공하기 위해 다양한 Ceph 오브젝트 CR을 생성합니다. |
| Ceph RBD 구성 |
RBD 스토리지를 활성화하려면 |
| CephFS 설정 |
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 는 다음을 조정합니다.
Default BackingStore
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다양한 옵션은 다음과 같습니다.
| AWS(Amazon Web Services) 배포 |
|
| Microsoft Azure 배포 |
|
| GCP(Google Cloud Platform) 배포 |
|
| On-prem deployment |
RGW가 존재하는 경우 |
| 이전에 언급한 배포 중 어느 것도 적용할 수 없습니다. |
|
기본 BucketClass
기본 BackingStore 에 대한 배치 정책이 있는 BucketClass 가 생성됩니다.
NooBaa Pod
다음 NooBaa Pod가 생성되고 시작됩니다.
| 데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 저장된 실제 데이터는 유지되지 않습니다. |
| 코어 | 이는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 Pod입니다. |
| endpoints |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하여 데이터를 작성하고 읽기 위해 다른 서비스와 통신합니다. 끝점은 |
경로
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
Service
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스용 서비스가 생성됩니다.
4.3.2. 외부 모드 스토리지 클러스터
외부 스토리지 클러스터의 경우 ocs-operator 는 약간 다른 설정 프로세스를 따릅니다. ocs-operator 는 rook-ceph-external-cluster-details ConfigMap 의 존재를 찾습니다. 이 ConfigMap은 관리자 또는 콘솔 중 다른 사용자가 생성해야 합니다. ConfigMap 을 생성하는 방법에 대한 자세한 내용은 외부 모드를 위한 OpenShift Data Foundation 클러스터 생성을 참조하십시오. 그런 다음 ocs-operator 는 ConfigMap 에 지정된 대로 다음 리소스 중 일부 또는 모두를 생성합니다.
| 외부 Ceph 구성 |
외부 |
| 외부 Ceph 인증 정보 보안 | 외부 Ceph 인스턴스에 연결할 자격 증명이 포함된 시크릿입니다. |
| 외부 Ceph StorageClasses | RBD, CephFS 및/또는 RGW에 대한 볼륨 생성을 활성화하는 하나 이상의 StorageClasses. |
| CephFS CSI 드라이버 활성화 |
|
| Ceph RGW 구성 | RGW StorageClass가 지정된 경우 Ceph RGW 오브젝트 스토리지 끝점에 대한 액세스를 활성화하고 제공하는 다양한 Ceph Object CR을 생성합니다. |
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 는 다음을 조정합니다.
Default BackingStore
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다양한 옵션은 다음과 같습니다.
| AWS(Amazon Web Services) 배포 |
|
| Microsoft Azure 배포 |
|
| GCP(Google Cloud Platform) 배포 |
|
| On-prem deployment |
RGW가 존재하는 경우 |
| 이전에 언급한 배포 중 어느 것도 적용할 수 없습니다. |
|
기본 BucketClass
기본 BackingStore 에 대한 배치 정책이 있는 BucketClass 가 생성됩니다.
NooBaa Pod
다음 NooBaa Pod가 생성되고 시작됩니다.
| 데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 저장된 실제 데이터는 유지되지 않습니다. |
| 코어 | 이는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 Pod입니다. |
| endpoints |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하여 데이터를 작성하고 읽기 위해 다른 서비스와 통신합니다. 끝점은 |
경로
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
Service
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스용 서비스가 생성됩니다.
4.3.3. MCG Standalone StorageCluster
이 모드에서는 CephCluster가 생성되지 않습니다. 대신 NooBaa 시스템 CR은 OpenShift Container Platform. 대시보드의 기존 StorageClasses를 활용하기 위해 기본값을 사용하여 생성됩니다.
4.3.3.1. NooBaa 시스템 생성
NooBaa 시스템이 생성되면 mcg-operator 는 다음을 조정합니다.
Default BackingStore
OpenShift Container Platform 및 OpenShift Data Foundation이 배포된 플랫폼에 따라 버킷이 배치 정책에 사용할 수 있도록 기본 백업 저장소 리소스가 생성됩니다. 다양한 옵션은 다음과 같습니다.
| AWS(Amazon Web Services) 배포 |
|
| Microsoft Azure 배포 |
|
| GCP(Google Cloud Platform) 배포 |
|
| On-prem deployment |
RGW가 존재하는 경우 |
| 이전에 언급한 배포 중 어느 것도 적용할 수 없습니다. |
|
기본 BucketClass
기본 BackingStore 에 대한 배치 정책이 있는 BucketClass 가 생성됩니다.
NooBaa Pod
다음 NooBaa Pod가 생성되고 시작됩니다.
| 데이터베이스(DB) | 이는 메타데이터, 통계, 이벤트 등을 보유한 Postgres DB입니다. 그러나 저장된 실제 데이터는 유지되지 않습니다. |
| 코어 | 이는 구성, 백그라운드 프로세스, 메타데이터 관리, 통계 등을 처리하는 Pod입니다. |
| endpoints |
이러한 Pod는 중복 제거 및 압축과 같은 실제 I/O 관련 작업을 수행하여 데이터를 작성하고 읽기 위해 다른 서비스와 통신합니다. 끝점은 |
경로
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스의 경로가 생성됩니다.
Service
S3를 사용하는 애플리케이션에 대해 NooBaa S3 인터페이스용 서비스가 생성됩니다.
4.3.3.2. StorageSystem 생성
StorageCluster 생성의 일부로 odf-operator 는 StorageCluster를 OpenShift Data Foundation에 노출하는 해당 StorageSystem CR을 자동으로 생성합니다.
5장. OpenShift Data Foundation 업그레이드 개요
OLM(Operator Lifecycle Manager)에서 관리하는 Operator 번들로 OpenShift Data Foundation은 운영자를 활용하여 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는 사용자 연결 리소스(예: StorageCluster)에 지정된 대로 모든 관련 리소스가 예상 구성에 있는지 확인합니다.
'%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}