Deploying and managing OpenShift Data Foundation using Red Hat OpenStack Platform
Red Hat OpenStack Platform에서 OpenShift Data Foundation 배포 및 관리 방법
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 어떻게 하면 더 잘할 수 있는지 알려주십시오. 피드백을 제공하려면 다음을 수행합니다.
특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.
- 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
- 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
- 표시된 지침을 따릅니다.
보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.
- Bugzilla 웹 사이트로 이동하십시오.
- 구성 요소 섹션에서 문서 를 선택합니다.
- 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
- 버그 제출을 클릭합니다.
접두부
Red Hat OpenShift Data Foundation 4.9는 Red Hat OpenStack Platform 클러스터를 사용하여 기존 Red Hat OpenShift Container Platform(RHOCP)에 대한 배포를 지원합니다.
내부 및 외부 OpenShift Data Foundation 클러스터는 Red Hat OpenStack Platform에서 지원됩니다. 배포 요구 사항에 대한 자세한 내용은 배포 플래닝 을 참조하십시오.
OpenShift Data Foundation을 배포하려면 OpenShift Data Foundation 배포 준비 장의 요구 사항부터 시작한 다음 요구 사항에 따라 적절한 배포 프로세스를 따릅니다.
1장. OpenShift Data Foundation 배포 준비
동적 스토리지 장치를 사용하여 OpenShift Container Platform에 OpenShift Data Foundation을 배포하면 내부 클러스터 리소스를 생성할 수 있는 옵션이 제공됩니다. 이렇게 하면 기본 서비스가 내부 프로비저닝되므로 애플리케이션에서 추가 스토리지 클래스를 사용할 수 있습니다.
Red Hat OpenShift Data Foundation 배포를 시작하기 전에 다음 단계를 따르십시오.
선택 사항: 외부 키 관리 시스템(KMS)을 사용하여 클러스터 전체 암호화를 활성화하려면 다음을 수행합니다.
- 토큰이 있고 Vault에서 키 값 백엔드 경로가 활성화되어 있는지 확인합니다. Vault에서 키 값 백엔드 경로 및 정책 활성화를 참조하십시오.
- Vault 서버에서 서명된 인증서를 사용하고 있는지 확인합니다.
최소 노드 시작 요구 사항 [기술 프리뷰]
표준 배포 리소스 요구 사항이 충족되지 않으면 OpenShift Data Foundation 클러스터는 최소 구성으로 배포됩니다. 계획 가이드의 리소스 요구 사항 섹션을 참조하십시오.
regional-DR 요구 사항 [Developer Preview]
Red Hat OpenShift Data Foundation에서 지원하는 재해 복구 기능에는 재해 복구 솔루션을 성공적으로 구현하기 위해 다음과 같은 사전 요구 사항이 모두 필요합니다.
- 유효한 Red Hat OpenShift Data Foundation 고급 인타이틀먼트
유효한 Red Hat Advanced Cluster Management for Kubernetes 서브스크립션
OpenShift Data Foundation에 대한 서브스크립션이 작동하는 방법을 알아보려면 OpenShift Data Foundation 서브스크립션에 대한 지식 베이스 문서 를 참조하십시오.
자세한 요구 사항은 Region -DR 요구 사항 및 RHACM 요구 사항을 참조하십시오.
1.1. Vault에서 키 값 백엔드 경로와 정책 활성화
사전 요구 사항
- Vault에 대한 관리자 액세스.
-
나중에 변경할 수 없기 때문에 이름 지정 규칙을 따르는 백엔드
경로로고유한 경로 이름을 신중하게 선택합니다.
절차
Vault에서 KV(Key/Value) 백엔드 경로를 활성화합니다.
Vault KV 시크릿 엔진 API의 경우 버전 1:
$ vault secrets enable -path=odf kv
Vault KV 시크릿 엔진 API의 경우 버전 2:
$ vault secrets enable -path=odf kv-v2
다음 명령을 사용하여 시크릿에서 쓰기 또는 삭제 작업을 수행하도록 사용자를 제한하는 정책을 생성합니다.
echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -위 정책과 일치하는 토큰을 생성합니다.
$ vault token create -policy=odf -format json
2장. 내부 모드로 Red Hat OpenStack Platform에 OpenShift Data Foundation 배포
Red Hat OpenStack Platform 설치 관리자 프로비저닝 인프라(IPI)에서 제공하는 동적 스토리지 장치를 사용하여 내부 모드의 OpenShift Container Platform에 OpenShift Data Foundation을 배포하면 내부 클러스터 리소스를 생성할 수 있습니다. 이로 인해 기본 서비스가 내부 프로비저닝되므로 애플리케이션에서 추가 스토리지 클래스를 사용할 수 있습니다.
동적 스토리지 장치를 사용하여 배포하기 위한 다음 단계를 진행하기 전에 OpenShift Data Foundation 배포 준비에 대한 요구 사항을 해결했는지 확인하십시오.
2.1. Red Hat OpenShift Data Foundation Operator 설치
Red Hat OpenShift Container Platform Operator Hub를 사용하여 Red Hat OpenShift Data Foundation Operator를 설치할 수 있습니다.
사전 요구 사항
-
cluster-admin및 Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. - Red Hat OpenShift Container Platform 클러스터에 3개 이상의 작업자 노드가 있어야 합니다.
- 추가 리소스 요구 사항은 배포 계획 가이드를 참조하십시오.
OpenShift Data Foundation의 클러스터 수준 기본 노드 선택기를 재정의해야 하는 경우 명령줄 인터페이스에서 다음 명령을 사용하여
openshift-storage네임스페이스에 대한 빈 노드 선택기를 지정할 수 있습니다(이 경우 openshift-storage 네임스페이스 생성).$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
노드를
infra로 테인트하여 Red Hat OpenShift Data Foundation 리소스만 해당 노드에 예약되도록 합니다. 이는 서브스크립션 비용을 절감할 수 있도록 지원합니다. 자세한 내용은 스토리지 리소스 관리 및 할당 가이드의 Red Hat OpenShift Data Foundation 전용 작업자 노드 사용 방법을 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub 를 클릭합니다.
-
OpenShift Data Foundation을 키워드로 필터링 상자에 스크롤하여 OpenShift Data Foundation Operator를 찾습니다. - 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- Channel을 stable-4.9 로 업데이트합니다.
- 클러스터의 특정 네임스페이스 로 설치 모드.
-
설치된 Namespace를 Operator 권장 네임스페이스 openshift-storage. 네임스페이스
openshift-storage가 없으면 Operator 설치 중에 생성됩니다. 승인 전략을 자동 또는 수동으로 선택합니다.
자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.
- Console 플러그인에 대해 Enable 옵션이 선택되어 있는지 확인합니다.
- 설치를 클릭합니다.
모든 기본 설정을 사용하는 것이 좋습니다. 이를 변경하면 예기치 않은 동작이 발생할 수 있습니다. 결과를 알고 있는 경우에만 변경합니다.
검증 단계
- OpenShift Data Foundation Operator에 성공적으로 설치를 나타내는 녹색 눈금이 표시되는지 확인합니다.
Operator가 성공적으로 설치되면 메시지가 포함된 팝업
이 사용자 인터페이스에 웹 콘솔 업데이트가표시됩니다. 콘솔 변경 사항을 반영하려면 이 팝업 창에서 웹 콘솔 새로 고침 을 클릭합니다.- 웹 콘솔에서 Operator로 이동하여 OpenShift Data Foundation 을 사용할 수 있는지 확인합니다.
OpenShift Data Foundation Operator를 설치한 후 콘솔 플러그인 옵션이 자동으로 활성화되지 않은 경우 이를 활성화해야 합니다.
콘솔 플러그인을 활성화하는 방법에 대한 자세한 내용은 Red Hat OpenShift Data Foundation 콘솔 플러그인 활성화를 참조하십시오.
2.2. OpenShift Data Foundation 클러스터 생성
OpenShift Data Foundation Operator를 설치한 후 OpenShift Data Foundation 클러스터를 생성합니다.
사전 요구 사항
- OpenShift Data Foundation Operator는 Operator Hub에서 설치해야 합니다. 자세한 내용은 Operator Hub를 사용하여 OpenShift Data Foundation Operator 설치를 참조하십시오.
절차
OpenShift 웹 콘솔에서 Operator → 설치된 Operator를 클릭하여 설치된 모든 Operator 를 확인합니다.
선택한 프로젝트 가
openshift-storage인지 확인합니다.- OpenShift Data Foundation Operator를 클릭한 다음 Create StorageSystem 을 클릭합니다.
백업 스토리지 페이지에서 다음을 선택합니다.
- 기존 StorageClass 옵션 사용을 선택합니다.
스토리지 클래스 를 선택합니다.
기본적으로
표준으로설정됩니다.-
고급 을 확장하고 Deployment type 옵션의
Full Deployment를 선택합니다. - 다음을 클릭합니다.
용량 및 노드 페이지에서 필요한 정보를 제공합니다.
드롭다운 목록에서 Requested Capacity (요청 용량) 값을 선택합니다. 기본적으로
2TiB로 설정됩니다.참고초기 스토리지 용량을 선택하면 선택한 사용 가능한 용량( raw 스토리지의 3배)만 클러스터 확장이 수행됩니다.
노드 선택 섹션에서 사용 가능한 노드가 3개 이상 선택합니다.
여러 가용성 영역이 있는 클라우드 플랫폼의 경우 노드가 다른 위치/ 가용 영역에 분산되어 있는지 확인합니다.
선택한 노드가 집계된 30 개의 CPU 및 72GiB RAM의 OpenShift Data Foundation 클러스터 요구 사항과 일치하지 않으면 최소 클러스터가 배포됩니다. 최소 노드 요구 사항은 계획 가이드의 리소스 요구 사항 섹션을 참조하십시오.
- 다음을 클릭합니다.
선택 사항: 보안 및 네트워크 페이지에서 요구 사항에 따라 다음을 구성합니다.
- 암호화를 활성화하려면 블록 및 파일 스토리지에 데이터 암호화 사용을 선택합니다.
암호화 수준 중 하나 또는 둘 다를 선택합니다.
클러스터 전체 암호화
전체 클러스터(블록 및 파일)를 암호화합니다.
StorageClass 암호화
암호화 활성화된 스토리지 클래스를 사용하여 암호화된 영구 볼륨(블록만 해당)을 생성합니다.
외부 키 관리 서비스에 연결 확인란을 선택합니다. 이는 클러스터 전체 암호화의 경우 선택 사항입니다.
-
Key Management Service Provider 는 기본적으로
Vault로 설정됩니다. - Vault 서비스 이름, Vault 서버 호스트 주소 ('https://<hostname 또는 ip>), 포트 번호 및 토큰 을 입력합니다.
고급 설정을 확장하여
Vault구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.- OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
- 선택 사항: TLS 서버 이름 및 Vault Enterprise Namespace 를 입력합니다.
- 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서 및 클라이언트 개인 키를 제공합니다.
- 저장을 클릭합니다.
-
Key Management Service Provider 는 기본적으로
- 다음을 클릭합니다.
검토 및 생성 페이지에서 구성 세부 정보를 검토합니다.
구성 설정을 수정하려면 Back 을 클릭합니다.
- Create StorageSystem 을 클릭합니다.
검증 단계
설치된 스토리지 클러스터의 최종 상태를 확인하려면 다음을 수행합니다.
- OpenShift 웹 콘솔에서 설치된 Operator → OpenShift Data Foundation → 스토리지 시스템 → ocs-storagecluster-storagesystem → Resources 로 이동합니다.
-
StorageClusterStatus(상태)가Ready이고 옆에 녹색 눈금이 표시되어 있는지 확인합니다.
- OpenShift Data Foundation이 성공적으로 설치 되었는지 확인하려면 OpenShift Data Foundation 설치 확인을 참조하십시오.
추가 리소스
오버 프로비저닝 제어 경고를 활성화하려면 모니터링 가이드의 경고를 참조하십시오.
2.3. OpenShift Data Foundation 배포 확인
이 섹션을 사용하여 OpenShift Data Foundation이 올바르게 배포되었는지 확인합니다.
2.3.1. Pod 상태 확인
절차
- OpenShift 웹 콘솔에서 워크로드 → 포드 를 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
각 구성 요소에 대해 예상되는 Pod 수 및 노드 수에 따라 달라지는 방법에 대한 자세한 내용은 표 2.1. “OpenShift Data Foundation 클러스터에 해당하는 Pod” 을 참조하십시오.
Running 및 Completed 탭을 클릭하여 다음 Pod가
Running및Completed상태인지 확인합니다.표 2.1. OpenShift Data Foundation 클러스터에 해당하는 Pod
구성 요소 해당 Pod OpenShift Data Foundation Operator
-
OCS-operator-*작업자 노드의 Pod 1 -
OCS-metrics-exporter-*(작업자 노드에서 Pod) -
ODF-operator-controller-manager-*(1개의 작업자 노드에서 Pod) -
ODF-console-*(작업자 노드의 Pod)
rook-ceph Operator
rook-ceph-operator-*(모든 작업자 노드의 Pod)
Multicloud Object Gateway
-
NooBaa-operator-*(작업자 노드에서 Pod) -
NooBaa-core-*(스토리지 노드의 Pod) -
NooBaa-db-pg-*(1 스토리지 노드의 pod) -
NooBaa-endpoint-*(1 스토리지 노드에서 Pod)
MON
rook-ceph-mon-*(스토리지 노드에 분산된 Pod 3개)
MGR
rook-ceph-mgr-*(1 스토리지 노드의 Pod)
MDS
rook-ceph-mds-ocs-storagecluster-cephfilesystem-*(2개의 Pod가 스토리지 노드에 배포됨)
CSI
CephFS-
CSI-cephfsplugin-*(각 작업자 노드의 Pod) -
CSI-cephfsplugin-provisioner-*(2개 작업자 노드에 분산된 Pod)
-
rbd-
CSI-rbdplugin-*(각 작업자 노드의 Pod) -
CSI-rbdplugin-provisioner-*(2 작업자 노드에 분산된 Pod)
-
rook-ceph-crashcollector
rook-ceph-crashcollector-*(1개의 스토리지 노드의 pod)
OSD
-
rook-ceph-osd-*(각 장치의 Pod) -
rook-ceph-osd-prepare-ocs-deviceset-*(각 장치의 Pod)
-
2.3.2. OpenShift Data Foundation 클러스터가 정상인지 확인
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- 블록 및 파일 탭의 상태 카드에서 스토리지 클러스터에 녹색 눈금 이 있는지 확인합니다.
- 세부 정보 카드에서 클러스터 정보가 표시되는지 확인합니다.
블록 및 파일 대시보드를 사용하는 OpenShift Data Foundation 클러스터의 상태에 대한 자세한 내용은 Monitoring OpenShift Data Foundation 을 참조하십시오.
2.3.3. Multicloud Object Gateway가 정상인지 확인
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- Object 탭의 상태 카드에서 Object Service 와 Data Resiliency 모두 녹색 눈금이 있는지 확인합니다.
- 세부 정보 카드에 MCG 정보가 표시되는지 확인합니다.
오브젝트 서비스 대시보드를 사용하는 OpenShift Data Foundation 클러스터의 상태에 대한 자세한 내용은 Monitoring OpenShift Data Foundation 을 참조하십시오.
2.3.4. OpenShift Data Foundation 특정 스토리지 클래스가 있는지 확인
절차
- OpenShift 웹 콘솔의 왼쪽 창에서 스토리지 → 스토리지 클래스 를 클릭합니다.
OpenShift Data Foundation 클러스터 생성으로 다음 스토리지 클래스가 생성되었는지 확인합니다.
-
ocs-storagecluster-ceph-rbd -
ocs-storagecluster-cephfs -
openshift-storage.noobaa.io
-
2.4. OpenShift Data Foundation 설치 제거
2.4.1. 내부 모드에서 OpenShift Data Foundation 설치 제거
내부 모드에서 OpenShift Data Foundation을 설치 제거하려면 OpenShift Data Foundation 설치 제거에 대한 지식 기반 문서를 참조하십시오.
3장. 외부 모드에서 Red Hat OpenStack Platform에 OpenShift Data Foundation 배포
Red Hat OpenShift Data Foundation은 외부에서 호스팅된 Red Hat Ceph Storage(RHCS) 클러스터를 Red Hat OpenStack Platform의 스토리지 공급자로 사용할 수 있습니다. 자세한 내용은 배포 계획을 참조하십시오.
RHCS 4 클러스터 설치 방법에 대한 자세한 내용은 설치 가이드 를 참조하십시오.
다음 단계에 따라 OpenShift Data Foundation을 외부 모드로 배포합니다.
3.1. Red Hat OpenShift Data Foundation Operator 설치
Red Hat OpenShift Container Platform Operator Hub를 사용하여 Red Hat OpenShift Data Foundation Operator를 설치할 수 있습니다.
사전 요구 사항
-
cluster-admin및 Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. - Red Hat OpenShift Container Platform 클러스터에 3개 이상의 작업자 노드가 있어야 합니다.
- 추가 리소스 요구 사항은 배포 계획 가이드를 참조하십시오.
OpenShift Data Foundation의 클러스터 수준 기본 노드 선택기를 재정의해야 하는 경우 명령줄 인터페이스에서 다음 명령을 사용하여
openshift-storage네임스페이스에 대한 빈 노드 선택기를 지정할 수 있습니다(이 경우 openshift-storage 네임스페이스 생성).$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
노드를
infra로 테인트하여 Red Hat OpenShift Data Foundation 리소스만 해당 노드에 예약되도록 합니다. 이는 서브스크립션 비용을 절감할 수 있도록 지원합니다. 자세한 내용은 스토리지 리소스 관리 및 할당 가이드의 Red Hat OpenShift Data Foundation 전용 작업자 노드 사용 방법을 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub 를 클릭합니다.
-
OpenShift Data Foundation을 키워드로 필터링 상자에 스크롤하여 OpenShift Data Foundation Operator를 찾습니다. - 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- Channel을 stable-4.9 로 업데이트합니다.
- 클러스터의 특정 네임스페이스 로 설치 모드.
-
설치된 Namespace를 Operator 권장 네임스페이스 openshift-storage. 네임스페이스
openshift-storage가 없으면 Operator 설치 중에 생성됩니다. 승인 전략을 자동 또는 수동으로 선택합니다.
자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.
- Console 플러그인에 대해 Enable 옵션이 선택되어 있는지 확인합니다.
- 설치를 클릭합니다.
모든 기본 설정을 사용하는 것이 좋습니다. 이를 변경하면 예기치 않은 동작이 발생할 수 있습니다. 결과를 알고 있는 경우에만 변경합니다.
검증 단계
- OpenShift Data Foundation Operator에 성공적으로 설치를 나타내는 녹색 눈금이 표시되는지 확인합니다.
Operator가 성공적으로 설치되면 메시지가 포함된 팝업
이 사용자 인터페이스에 웹 콘솔 업데이트가표시됩니다. 콘솔 변경 사항을 반영하려면 이 팝업 창에서 웹 콘솔 새로 고침 을 클릭합니다.- 웹 콘솔에서 Operator로 이동하여 OpenShift Data Foundation 을 사용할 수 있는지 확인합니다.
OpenShift Data Foundation Operator를 설치한 후 콘솔 플러그인 옵션이 자동으로 활성화되지 않은 경우 이를 활성화해야 합니다.
콘솔 플러그인을 활성화하는 방법에 대한 자세한 내용은 Red Hat OpenShift Data Foundation 콘솔 플러그인 활성화를 참조하십시오.
3.2. 외부 모드를 위한 OpenShift 데이터 기반 클러스터 생성
Red Hat OpenStack 플랫폼에 배포된 OpenShift Container Platform에 OpenShift Data Foundation Operator를 설치한 후 새 OpenShift Data Foundation 클러스터를 생성해야 합니다.
사전 요구 사항
- OpenShift Data Foundation 4.8을 배포하기 전에 OpenShift Container Platform 버전이 4.8 이상인지 확인합니다.
- OpenShift Data Foundation Operator가 설치되어 있어야 합니다. 자세한 내용은 Operator Hub를 사용하여 OpenShift Data Foundation Operator 설치를 참조하십시오.
외부 클러스터에 Red Hat Ceph Storage 버전 4.2z1 이상이 필요합니다. 자세한 내용은 Red Hat Ceph Storage 릴리스 및 해당 Ceph 패키지 버전에 대한 지식 베이스 문서를 참조하십시오.
4.1.1 미만 버전에서 Red Hat Ceph Storage 클러스터를 최신 릴리스로 업데이트하고 새로 배포된 클러스터가 아닌 경우, 외부 모드에서 CephFS PVC 생성을 활성화하려면 Red Hat Ceph Storage 클러스터에서 CephFS 풀의 애플리케이션 유형을 수동으로 설정해야 합니다.
자세한 내용은 외부 모드에서 CephFS PVC 생성 문제 해결을 참조하십시오.
- Red Hat Ceph Storage에는 Ceph 대시보드가 설치되어 구성되어 있어야 합니다. 자세한 내용은 Ceph 대시보드 설치 및 액세스를 참조하십시오.
- Red Hat은 외부 Red Hat Ceph Storage 클러스터에 PG Autoscaler를 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 Red Hat Ceph Storage 문서 의 배치 그룹 자동 스케일러 섹션을 참조하십시오.
- 외부 Ceph 클러스터에는 사용하도록 사전 구성된 기존 RBD 풀이 있어야 합니다. 존재하지 않는 경우 OpenShift Data Foundation 배포를 수행하기 전에 Red Hat Ceph Storage 관리자에게 문의하십시오. Red Hat은 각 OpenShift Data Foundation 클러스터에 별도의 풀을 사용하는 것이 좋습니다.
절차
Operator → 설치된 Operator를 클릭하여 설치된 모든 Operator를 확인합니다.
선택한 프로젝트 가
openshift-storage인지 확인합니다.- OpenShift Data Foundation → 스토리지 클러스터의 인스턴스 생성 링크를 클릭합니다.
mode를 외부로 선택합니다. 기본적으로 Internal는 배포 모드로 선택됩니다.
그림 3.1. 스토리지 클러스터 생성 양식의 외부 클러스터 섹션에 연결

- 외부 클러스터에 연결 섹션에서 다운로드 스크립트 링크를 클릭하여 Ceph 클러스터 세부 정보를 추출하기 위해 python 스크립트를 다운로드합니다.
RHCS(Red Hat Ceph Storage) 클러스터 세부 정보를 추출하려면 RHCS 관리자에게
관리자 키가있는 Red Hat Ceph Storage 노드에서 다운로드한 python 스크립트를 실행하십시오.RHCS 노드에서 다음 명령을 실행하여 사용 가능한 인수 목록을 확인합니다.
# python3 ceph-external-cluster-details-exporter.py --help
중요Red Hat Ceph Storage 4.x 클러스터가 Red Hat Enterprise Linux 7.x(RHEL 7.x) 클러스터에 배포된 경우
대신 python을 사용합니다.python3참고MON 컨테이너(컨테이너화된 배포) 또는 MON 노드(rpm 배포) 내부에서 스크립트를 실행할 수도 있습니다.
RHCS 클러스터에서 외부 클러스터 세부 정보를 검색하려면 다음 명령을 실행합니다.
# python3 ceph-external-cluster-details-exporter.py \ --rbd-data-pool-name <rbd block pool name> [optional arguments]
예를 들면 다음과 같습니다.
# python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name ceph-rbd --monitoring-endpoint xxx.xxx.xxx.xxx --monitoring-endpoint-port xxxx --rgw-endpoint xxx.xxx.xxx.xxx:xxxx --run-as-user client.ocs
상기 예에서, In the above example,
-
--RBD-data-pool-name은 OpenShift Data Foundation에서 블록 스토리지를 제공하는 데 사용되는 필수 매개 변수입니다. -
--RGW-endpoint는 선택 사항입니다. OpenShift Data Foundation용 Ceph Rados Gateway를 통해 오브젝트 스토리지를 프로비저닝할 경우 이 매개변수를 제공합니다. 다음과 같은 형식으로 끝점을 제공합니다.<ip_address>:<port> -
--monitoring-endpoint는 선택 사항입니다. OpenShift Container Platform 클러스터에서 연결할 수 있는 활성ceph-mgr의 IP 주소입니다. 제공되지 않으면 값이 자동으로 채워집니다. -
--monitoring-endpoint-port는 선택 사항입니다.--monitoring-endpoint에서 지정한ceph-mgrPrometheus 내보내기와 연결된 포트입니다. 제공되지 않으면 값이 자동으로 채워집니다. -- run-as-user는 스크립트에서 생성한 Ceph 사용자의 이름을 제공하는 데 사용되는 선택적 매개 변수입니다. 이 매개변수를 지정하지 않으면 기본 사용자 이름client.healthchecker가 생성됩니다. 새 사용자에 대한 권한은 다음과 같이 설정됩니다.- caps: [mgr] allow command config
- caps: [mon] allow r, allow command quorum_status, allow command version
caps: [osd] allow rwx pool=
RGW_POOL_PREFIX_PREFIX, allow rw pool= .rgw.root , allow rw pool=.rgw.rootallow x pool=RGW_POOL_PREFIX.rgw.control.log.log.RGW_POOL_PREFIX.rgw.buckets.indexpython 스크립트를 사용하여 생성된 JSON 출력 예:
[{"name": "rook-ceph-mon-endpoints", "kind": "ConfigMap", "data": {"data": "xxx.xxx.xxx.xxx:xxxx", "maxMonId": "0", "mapping": "{}"}}, {"name": "rook-ceph-mon", "kind": "Secret", "data": {"admin-secret": "admin-secret", "fsid": "<fs-id>", "mon-secret": "mon-secret"}}, {"name": "rook-ceph-operator-creds", "kind": "Secret", "data": {"userID": "client.healthchecker", "userKey": "<user-key>"}}, {"name": "rook-csi-rbd-node", "kind": "Secret", "data": {"userID": "csi-rbd-node", "userKey": "<user-key>"}}, {"name": "ceph-rbd", "kind": "StorageClass", "data": {"pool": "ceph-rbd"}}, {"name": "monitoring-endpoint", "kind": "CephCluster", "data": {"MonitoringEndpoint": "xxx.xxx.xxx.xxx", "MonitoringPort": "xxxx"}}, {"name": "rook-csi-rbd-provisioner", "kind": "Secret", "data": {"userID": "csi-rbd-provisioner", "userKey": "<user-key>"}}, {"name": "rook-csi-cephfs-provisioner", "kind": "Secret", "data": {"adminID": "csi-cephfs-provisioner", "adminKey": "<admin-key>"}}, {"name": "rook-csi-cephfs-node", "kind": "Secret", "data": {"adminID": "csi-cephfs-node", "adminKey": "<admin-key>"}}, {"name": "cephfs", "kind": "StorageClass", "data": {"fsName": "cephfs", "pool": "cephfs_data"}}, {"name": "ceph-rgw", "kind": "StorageClass", "data": {"endpoint": "xxx.xxx.xxx.xxx:xxxx", "poolPrefix": "default"}}]
-
.json확장자를 사용하여 JSON 출력을 파일에 저장합니다.참고OpenShift Data Foundation이 원활하게 작동하려면 JSON 파일을 사용하여 업로드할 매개 변수(RGW 끝점, CephFS 세부 정보, RBD 풀 등)가 스토리지 클러스터 생성 후 RHCS 외부 클러스터에서 변경되지 않은 상태로 남아 있는지 확인합니다.
외부 클러스터 메타데이터 → 찾아보기 를 클릭하여 JSON 파일을 선택하고 업로드합니다.
JSON 파일의 내용은 텍스트 상자에 채워져 표시됩니다.
그림 3.2. JSON 파일 콘텐츠

생성을 클릭합니다.
Create 버튼은
.json파일을 업로드한 후에만 활성화됩니다.
검증 단계
설치된 스토리지 클러스터의 최종 상태가
Phase로 표시되는지 확인합니다. Ready녹색 체크 표시가 있습니다.- Operator → 설치된 Operator → 스토리지 클러스터 링크를 클릭하여 스토리지 클러스터 설치 상태를 확인합니다.
- 또는 Operator 세부 정보 탭에 있는 경우 Storage Cluster 탭을 클릭하여 상태를 볼 수 있습니다.
- OpenShift Data Foundation, pod 및 StorageClass가 성공적으로 설치되었는지 확인하려면 외부 모드 OpenShift Data Foundation 설치 확인을 참조하십시오.
3.3. 외부 모드를 위한 OpenShift Data Foundation 설치 확인
이 섹션을 사용하여 OpenShift Data Foundation이 올바르게 배포되었는지 확인합니다.
3.3.1. Pod 상태 확인
- OpenShift 웹 콘솔의 왼쪽 창에서 워크로드 → 포드 를 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
각 구성 요소에 대해 예상되는 Pod 수와 노드 수에 따라 달라지는 방법에 대한 자세한 내용은 다음을 참조하십시오. 표 3.1. “OpenShift Data Foundation 구성 요소에 해당하는 Pod”
다음 Pod가 실행 중인지 확인합니다.
표 3.1. OpenShift Data Foundation 구성 요소에 해당하는 Pod
구성 요소 해당 Pod OpenShift Data Foundation Operator
-
OCS-operator-*작업자 노드의 Pod 1 -
OCS-metrics-exporter-*(작업자 노드에서 Pod) -
ODF-operator-controller-manager-*(1개의 작업자 노드에서 Pod) -
ODF-console-*(작업자 노드의 Pod)
rook-ceph Operator
rook-ceph-operator-*(모든 작업자 노드의 Pod)
Multicloud Object Gateway
-
NooBaa-operator-*(작업자 노드에서 Pod) -
NooBaa-core-*(작업자 노드에서 Pod) -
NooBaa-db-pg-*(1개의 작업자 노드의 pod) -
NooBaa-endpoint-*(모든 작업자 노드에서 Pod)
CSI
CephFS-
CSI-cephfsplugin-*(각 작업자 노드의 Pod) -
CSI-cephfsplugin-provisioner-*(2개 작업자 노드에 분산된 Pod)
-
참고MDS가 외부 클러스터에 배포되지 않으면 csi-cephfsplugin Pod가 생성되지 않습니다.
rbd-
CSI-rbdplugin-*(각 작업자 노드의 Pod) -
CSI-rbdplugin-provisioner-*(2 작업자 노드에 분산된 Pod)
-
-
3.3.2. OpenShift Data Foundation 클러스터가 정상인지 확인
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- 블록 및 파일 탭의 상태 카드에서 Storage Cluster 및 Data Resiliency 모두 녹색 눈금이 있는지 확인합니다.
세부 정보 카드에서 클러스터 정보가 다음과 같이 표시되는지 확인합니다.
+ 서비스 이름:: OpenShift Data Foundation 클러스터 이름:: ocs-external-storagecluster Provider:: OpenStack Mode:: 외부 버전:: ocs-operator-4.9.0
블록 및 파일 대시보드를 사용하는 OpenShift Data Foundation 클러스터의 상태에 대한 자세한 내용은 Monitoring OpenShift Data Foundation 을 참조하십시오.
3.3.3. Multicloud Object Gateway가 정상인지 확인
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- Object 탭의 상태 카드에서 Object Service 와 Data Resiliency 모두 녹색 눈금이 있는지 확인합니다.
- 세부 정보 카드에서 MCG(Multicloud Object Gateway) 정보가 표시되는지 확인합니다.
RADOS 오브젝트 게이트웨이는 OpenShift Data Foundation을 외부 모드에 배포하는 동안 RADOS 오브젝트 게이트웨이 세부 정보가 포함된 경우에만 나열됩니다.
오브젝트 대시보드를 사용하는 OpenShift Data Foundation 클러스터의 상태에 대한 자세한 내용은 Monitoring OpenShift Data Foundation 을 참조하십시오.
3.3.4. 스토리지 클래스가 생성되고 나열되는지 확인
- OpenShift 웹 콘솔의 왼쪽 창에서 스토리지 → 스토리지 클래스 를 클릭합니다.
OpenShift Data Foundation 클러스터 생성으로 다음 스토리지 클래스가 생성되었는지 확인합니다.
-
ocs-external-storagecluster-ceph-rbd -
ocs-external-storagecluster-ceph-rgw -
ocs-external-storagecluster-cephfs -
openshift-storage.noobaa.io
-
-
MDS가 외부 클러스터에 배포되지 않으면
ocs-external-storagecluster-cephfs스토리지 클래스가 생성되지 않습니다. -
RGW가 외부 클러스터에 배포되지 않으면
ocs-external-storagecluster-ceph-rgw스토리지 클래스가 생성되지 않습니다.
MDS 및 RGW에 대한 자세한 내용은 Red Hat Ceph Storage 문서를 참조하십시오.
3.3.5. Ceph 클러스터가 연결되어 있는지 확인
다음 명령을 실행하여 OpenShift Data Foundation 클러스터가 외부 Red Hat Ceph Storage 클러스터에 연결되어 있는지 확인합니다.
$ oc get cephcluster -n openshift-storage
NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH ocs-external-storagecluster-cephcluster 31m15s Connected Cluster connected successfully HEALTH_OK
3.3.6. 스토리지 클러스터가 준비되었는지 확인
다음 명령을 실행하여 스토리지 클러스터가 준비되고 External 옵션이 true로 설정되었는지 확인합니다.
$ oc get storagecluster -n openshift-storage
NAME AGE PHASE EXTERNAL CREATED AT VERSION ocs-external-storagecluster 31m15s Ready true 2021-02-29T20:43:04Z 4.8.0
3.4. OpenShift Data Foundation 설치 제거
3.4.1. 외부 스토리지 시스템에서 OpenShift Data Foundation 설치 제거
이 섹션의 단계를 사용하여 OpenShift Data Foundation을 설치 제거합니다. OpenShift Data Foundation을 설치 제거해도 외부 클러스터에서 RBD 풀이 제거되지 않거나 외부 Red Hat Ceph Storage 클러스터를 설치 제거합니다.
주석 제거
스토리지 클러스터의 주석은 제거 프로세스의 동작을 변경하는 데 사용됩니다. 제거 동작을 정의하기 위해 스토리지 클러스터에 다음 두 개의 주석이 도입되었습니다.
-
uninstall.ocs.openshift.io/cleanup-policy: delete -
uninstall.ocs.openshift.io/mode: normal
uninstall.ocs.openshift.io/cleanup-policy 는 외부 모드에 적용되지 않습니다.
아래 표는 이러한 주석과 함께 사용할 수 있는 다양한 값에 대한 정보를 제공합니다.
표 3.2. uninstall.ocs.openshift.io 제거 주석 설명
| 주석 | 값 | 기본값 | 동작 |
|---|---|---|---|
| cleanup-policy | delete | 있음 |
rook은 물리적 드라이브와 |
| cleanup-policy | 유지 | 없음 |
rook은 물리적 드라이브와 |
| mode | 정상 | 있음 | Rook 및 NooBaa는 PVC와 OBC가 관리자/사용자가 제거될 때까지 제거 프로세스를 일시 중지합니다. |
| mode | 강제 | 없음 | rook 및 NooBaa는 Rook 및 NooBaa를 사용하여 프로비저닝된 PVC/OBC가 각각 존재하는 경우에도 제거 작업을 진행합니다. |
다음 명령을 사용하여 주석의 값을 편집하여 제거 모드를 변경할 수 있습니다.
$ oc annotate storagecluster ocs-external-storagecluster -n openshift-storage uninstall.ocs.openshift.io/mode="forced" --overwrite storagecluster.ocs.openshift.io/ocs-external-storagecluster annotated
사전 요구 사항
- OpenShift Data Foundation 클러스터가 정상 상태인지 확인합니다. 리소스 또는 노드가 부족하여 일부 Pod가 종료되지 않으면 설치 제거 프로세스가 실패할 수 있습니다. 클러스터가 비정상 상태인 경우 OpenShift Data Foundation을 제거하기 전에 Red Hat 고객 지원에 문의하십시오.
- 애플리케이션이 OpenShift Data Foundation에서 제공하는 스토리지 클래스를 사용하여 애플리케이션이 PVC(영구 볼륨 클레임) 또는 오브젝트 버킷 클레임(OBC)을 사용하지 않는지 확인합니다.
절차
OpenShift Data Foundation을 사용하는 볼륨 스냅샷을 삭제합니다.
모든 네임스페이스의 볼륨 스냅샷 나열
$ oc get volumesnapshot --all-namespaces
이전 명령의 출력에서 OpenShift Data Foundation을 사용하는 볼륨 스냅샷을 식별하고 삭제합니다.
$ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>
OpenShift Data Foundation을 사용하는 PVC 및 OBC를 삭제합니다.
기본 제거 모드(graceful)에서 제거 프로그램은 OpenShift Data Foundation을 사용하는 모든 PVC 및 OBC가 삭제될 때까지 기다립니다.
PVC를 미리 삭제하지 않고 Storage Cluster를 삭제하려면 제거 모드 주석을 "forced"로 설정하고 이 단계를 건너뛸 수 있습니다. 이렇게 하면 시스템의 PVC 및 OBC가 생성됩니다.
OpenShift Data Foundation을 사용하여 OpenShift Container Platform 모니터링 스택 PVC를 삭제합니다.
OpenShift Data Foundation을 사용하여 OpenShift Container Platform 레지스트리 PVC를 삭제합니다.
OpenShift Data Foundation에서 OpenShift Container Platform 레지스트리 제거
OpenShift Data Foundation을 사용하여 OpenShift Container Platform 로깅 PVC를 삭제합니다.
OpenShift Data Foundation을 사용하여 프로비저닝된 다른 PVC 및 OBC를 삭제합니다.
아래는 OpenShift Data Foundation을 사용하여 프로비저닝된 PVC 및 OBC를 식별하는 샘플 스크립트입니다. 이 스크립트는 OpenShift Data Foundation에서 내부적으로 사용하는 PVC 및 OBC를 무시합니다.
#!/bin/bash RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com" CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com" NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc" RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket" NOOBAA_DB_PVC="noobaa-db" NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc" # Find all the OCS StorageClasses OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}') # List PVCs in each of the StorageClasses for SC in $OCS_STORAGECLASSES do echo "======================================================================" echo "$SC StorageClass PVCs and OBCs" echo "======================================================================" oc get pvc --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC" oc get obc --all-namespaces --no-headers 2>/dev/null | grep $SC echo doneOBC를 삭제합니다.
$ oc delete obc <obc name> -n <project name>
PVC를 삭제합니다.
$ oc delete pvc <pvc name> -n <project-name>
클러스터에서 생성된 사용자 정의 백업 저장소, 버킷 클래스 등을 제거했는지 확인합니다.
Storage Cluster 오브젝트를 삭제하고 관련 리소스가 제거될 때까지 기다립니다.
$ oc delete -n openshift-storage storagesystem --all --wait=true
네임스페이스를 삭제하고 삭제가 완료될 때까지 기다립니다.
openshift-storage가 활성 프로젝트인 경우 다른 프로젝트로 전환해야 합니다.예를 들면 다음과 같습니다.
$ oc project default $ oc delete project openshift-storage --wait=true --timeout=5m
다음 명령에서
NotFound오류를 반환하는 경우 프로젝트가 삭제됩니다.$ oc get project openshift-storage
참고OpenShift Data Foundation 설치 제거 중 네임스페이스가 완전히 삭제되지 않고 상태가
종료인 경우 Uninstall 중 남은 리소스를 삭제하고 나머지 리소스를 삭제하여 네임스페이스가 종료되지 않는 오브젝트를 식별합니다.OpenShift Data Foundation을 사용하여 프로비저닝된 모든 PV가 삭제되었는지 확인합니다.
Released상태에 PV가 남아 있으면 삭제합니다.$ oc get pv $ oc delete pv <pv name>
CustomResourceDefinitions를 제거합니다.$ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io storagesystems.odf.openshift.io --wait=true --timeout=5m
OpenShift Data Foundation이 완전히 제거되도록 하려면 다음을 수행합니다.
- OpenShift Container Platform 웹 콘솔에서 스토리지를 클릭합니다.
- OpenShift Data Foundation 이 더 이상 Storage에 표시되지 않는지 확인합니다.
3.4.2. OpenShift Data Foundation에서 모니터링 스택 제거
이 섹션을 사용하여 OpenShift Data Foundation에서 모니터링 스택을 정리합니다.
모니터링 스택 구성의 일부로 생성된 PVC는 openshift-monitoring 네임스페이스에 있습니다.
사전 요구 사항
OpenShift Container Platform 모니터링 스택을 사용하도록 PVC가 구성됩니다.
자세한 내용은 모니터링 스택 구성을 참조하십시오.
절차
openshift-monitoring네임스페이스에서 현재 실행 중인 Pod 및 PVC를 나열합니다.$ oc get pod,pvc -n openshift-monitoring NAME READY STATUS RESTARTS AGE pod/alertmanager-main-0 3/3 Running 0 8d pod/alertmanager-main-1 3/3 Running 0 8d pod/alertmanager-main-2 3/3 Running 0 8d pod/cluster-monitoring- operator-84457656d-pkrxm 1/1 Running 0 8d pod/grafana-79ccf6689f-2ll28 2/2 Running 0 8d pod/kube-state-metrics- 7d86fb966-rvd9w 3/3 Running 0 8d pod/node-exporter-25894 2/2 Running 0 8d pod/node-exporter-4dsd7 2/2 Running 0 8d pod/node-exporter-6p4zc 2/2 Running 0 8d pod/node-exporter-jbjvg 2/2 Running 0 8d pod/node-exporter-jj4t5 2/2 Running 0 6d18h pod/node-exporter-k856s 2/2 Running 0 6d18h pod/node-exporter-rf8gn 2/2 Running 0 8d pod/node-exporter-rmb5m 2/2 Running 0 6d18h pod/node-exporter-zj7kx 2/2 Running 0 8d pod/openshift-state-metrics- 59dbd4f654-4clng 3/3 Running 0 8d pod/prometheus-adapter- 5df5865596-k8dzn 1/1 Running 0 7d23h pod/prometheus-adapter- 5df5865596-n2gj9 1/1 Running 0 7d23h pod/prometheus-k8s-0 6/6 Running 1 8d pod/prometheus-k8s-1 6/6 Running 1 8d pod/prometheus-operator- 55cfb858c9-c4zd9 1/1 Running 0 6d21h pod/telemeter-client- 78fc8fc97d-2rgfp 3/3 Running 0 8d NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0 Bound pvc-0d519c4f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1 Bound pvc-0d5a9825-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2 Bound pvc-0d6413dc-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0 Bound pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1 Bound pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-external-storagecluster-ceph-rbd 8d
모니터링 구성 맵을 편집합니다.
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
다음 예제에 표시된 대로 OpenShift Data Foundation 스토리지 클래스를 참조하는
config섹션을 제거하고 저장합니다.편집 전
. . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-external-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-external-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .편집 후
. . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .
이 예에서는
alertmanagerMain및prometheusK8s모니터링 구성 요소가 OpenShift Data Foundation PVC를 사용하고 있습니다.PVC를 사용하는 Pod를 나열합니다.
이 예에서 PVC를 사용하는
alertmanagerMain및prometheusK8sPod는Terminating상태입니다. 이러한 Pod가 더 이상 OpenShift Data Foundation PVC를 사용하지 않으면 PVC를 삭제할 수 있습니다.$ oc get pod,pvc -n openshift-monitoring NAME READY STATUS RESTARTS AGE pod/alertmanager-main-0 3/3 Terminating 0 10h pod/alertmanager-main-1 3/3 Terminating 0 10h pod/alertmanager-main-2 3/3 Terminating 0 10h pod/cluster-monitoring-operator-84cd9df668-zhjfn 1/1 Running 0 18h pod/grafana-5db6fd97f8-pmtbf 2/2 Running 0 10h pod/kube-state-metrics-895899678-z2r9q 3/3 Running 0 10h pod/node-exporter-4njxv 2/2 Running 0 18h pod/node-exporter-b8ckz 2/2 Running 0 11h pod/node-exporter-c2vp5 2/2 Running 0 18h pod/node-exporter-cq65n 2/2 Running 0 18h pod/node-exporter-f5sm7 2/2 Running 0 11h pod/node-exporter-f852c 2/2 Running 0 18h pod/node-exporter-l9zn7 2/2 Running 0 11h pod/node-exporter-ngbs8 2/2 Running 0 18h pod/node-exporter-rv4v9 2/2 Running 0 18h pod/openshift-state-metrics-77d5f699d8-69q5x 3/3 Running 0 10h pod/prometheus-adapter-765465b56-4tbxx 1/1 Running 0 10h pod/prometheus-adapter-765465b56-s2qg2 1/1 Running 0 10h pod/prometheus-k8s-0 6/6 Terminating 1 9m47s pod/prometheus-k8s-1 6/6 Terminating 1 9m47s pod/prometheus-operator-cbfd89f9-ldnwc 1/1 Running 0 43m pod/telemeter-client-7b5ddb4489-2xfpz 3/3 Running 0 10h NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-0 Bound pvc-2eb79797-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-1 Bound pvc-2ebeee54-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-2 Bound pvc-2ec6a9cf-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-0 Bound pvc-3162a80c-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-1 Bound pvc-316e99e2-1fed-11ea-93e1-0a88476a6a64 40Gi RWO ocs-external-storagecluster-ceph-rbd 19h
관련 PVC를 삭제합니다. 스토리지 클래스를 사용하는 모든 PVC를 삭제해야 합니다.
$ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m
3.4.3. OpenShift Data Foundation에서 OpenShift Container Platform 레지스트리 제거
이 섹션을 사용하여 OpenShift Data Foundation에서 OpenShift Container Platform 레지스트리를 정리합니다. 대체 스토리지를 구성하려면 이미지 레지스트리를 참조하십시오.
OpenShift Container Platform 레지스트리 구성의 일부로 생성된 PVC는 openshift-image-registry 네임스페이스에 있습니다.
사전 요구 사항
- OpenShift Data Foundation PVC를 사용하도록 이미지 레지스트리가 구성되어 있어야 합니다.
절차
configs.imageregistry.operator.openshift.io오브젝트를 편집하고 storage 섹션에서 콘텐츠를 제거합니다.$ oc edit configs.imageregistry.operator.openshift.io
편집 전
. . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .편집 후
. . . storage: emptyDir: {} . . .이 예에서 PVC는 이제 삭제할 수 있는
registry-cephfs-rwx-pvc라고 합니다.PVC를 삭제합니다.
$ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m
3.4.4. OpenShift Data Foundation에서 클러스터 로깅 Operator 제거
이 섹션을 사용하여 OpenShift Data Foundation에서 클러스터 로깅 Operator를 정리합니다.
클러스터 로깅 Operator 구성의 일부로 생성된 PVC(영구 볼륨 클레임)는 openshift-logging 네임스페이스에 있습니다.
사전 요구 사항
- OpenShift Data Foundation PVC를 사용하도록 클러스터 로깅 인스턴스가 구성되어 있어야 합니다.
절차
네임스페이스에서
ClusterLogging인스턴스를 제거합니다.$ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m
openshift-logging네임스페이스의 PVC는 이제 삭제할 수 있습니다.PVC를 삭제합니다.
$ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m<pvc-name>- PVC의 이름입니다.
4장. 독립형 Multicloud Object Gateway를 내부 모드로 배포
OpenShift Data Foundation을 사용하여 Multicloud Object Gateway 구성 요소만 배포하면 배포 유연성을 제공하고 리소스 소비를 줄이는 데 도움이 됩니다. 이 섹션에서는 다음 단계를 포함하는 내부 모드에서 독립 실행형 Multicloud Object Gateway 구성 요소만 배포합니다.
- Red Hat OpenShift Data Foundation Operator 설치
- 독립 실행형 Multicloud Object Gateway 생성
독립 실행형 Multicloud Object Gateway 구성 요소 배포는 외부 모드 배포에서 지원되지 않습니다.
4.1. Red Hat OpenShift Data Foundation Operator 설치
Red Hat OpenShift Container Platform Operator Hub를 사용하여 Red Hat OpenShift Data Foundation Operator를 설치할 수 있습니다.
사전 요구 사항
-
cluster-admin및 Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. - Red Hat OpenShift Container Platform 클러스터에 3개 이상의 작업자 노드가 있어야 합니다.
- 추가 리소스 요구 사항은 배포 계획 가이드를 참조하십시오.
OpenShift Data Foundation의 클러스터 수준 기본 노드 선택기를 재정의해야 하는 경우 명령줄 인터페이스에서 다음 명령을 사용하여
openshift-storage네임스페이스에 대한 빈 노드 선택기를 지정할 수 있습니다(이 경우 openshift-storage 네임스페이스 생성).$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
노드를
infra로 테인트하여 Red Hat OpenShift Data Foundation 리소스만 해당 노드에 예약되도록 합니다. 이는 서브스크립션 비용을 절감할 수 있도록 지원합니다. 자세한 내용은 스토리지 리소스 관리 및 할당 가이드의 Red Hat OpenShift Data Foundation 전용 작업자 노드 사용 방법을 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub 를 클릭합니다.
-
OpenShift Data Foundation을 키워드로 필터링 상자에 스크롤하여 OpenShift Data Foundation Operator를 찾습니다. - 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- Channel을 stable-4.9 로 업데이트합니다.
- 클러스터의 특정 네임스페이스 로 설치 모드.
-
설치된 Namespace를 Operator 권장 네임스페이스 openshift-storage. 네임스페이스
openshift-storage가 없으면 Operator 설치 중에 생성됩니다. 승인 전략을 자동 또는 수동으로 선택합니다.
자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.
- Console 플러그인에 대해 Enable 옵션이 선택되어 있는지 확인합니다.
- 설치를 클릭합니다.
모든 기본 설정을 사용하는 것이 좋습니다. 이를 변경하면 예기치 않은 동작이 발생할 수 있습니다. 결과를 알고 있는 경우에만 변경합니다.
검증 단계
- OpenShift Data Foundation Operator에 성공적으로 설치를 나타내는 녹색 눈금이 표시되는지 확인합니다.
Operator가 성공적으로 설치되면 메시지가 포함된 팝업
이 사용자 인터페이스에 웹 콘솔 업데이트가표시됩니다. 콘솔 변경 사항을 반영하려면 이 팝업 창에서 웹 콘솔 새로 고침 을 클릭합니다.- 웹 콘솔에서 Operator로 이동하여 OpenShift Data Foundation 을 사용할 수 있는지 확인합니다.
OpenShift Data Foundation Operator를 설치한 후 콘솔 플러그인 옵션이 자동으로 활성화되지 않은 경우 이를 활성화해야 합니다.
콘솔 플러그인을 활성화하는 방법에 대한 자세한 내용은 Red Hat OpenShift Data Foundation 콘솔 플러그인 활성화를 참조하십시오.
4.2. 독립 실행형 Multicloud Object Gateway 생성
이 섹션을 사용하여 OpenShift Data Foundation에서 Multicloud Object Gateway 구성 요소만 생성합니다.
사전 요구 사항
- OpenShift Data Foundation Operator가 설치되어 있는지 확인합니다.
- (로컬 스토리지 장치만 사용하여 배포하는 경우) Local Storage Operator가 설치되어 있는지 확인합니다.
- 스토리지 클래스가 있고 기본값으로 설정되어 있는지 확인합니다.
절차
OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 모든 Operator 를 확인합니다.
선택한 프로젝트가
openshift-storage인지 확인합니다.- OpenShift Data Foundation Operator를 클릭한 다음 Create StorageSystem 을 클릭합니다.
- 백업 스토리지 페이지에서 고급 을 확장합니다.
- Deployment type 용으로 Multicloud Object Gateway for Deployment를 선택합니다.
- 다음을 클릭합니다.
선택 사항: 보안 페이지에서 외부 키 관리 서비스에 연결을 선택합니다.
-
Key Management Service Provider 는 기본적으로
Vault로 설정됩니다. - Vault Service Name, host Address of Vault server ('https://<hostname or ip>'), 포트 번호, 토큰 을 입력합니다.
고급 설정을 확장하여
Vault구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.- OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
- 선택 사항: TLS 서버 이름 및 Vault Enterprise Namespace 를 입력합니다.
- 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서 및 클라이언트 개인 키를 제공합니다.
- 저장을 클릭합니다.
- 다음을 클릭합니다.
-
Key Management Service Provider 는 기본적으로
검토 및 생성 페이지에서 구성 세부 정보를 검토합니다.
구성 설정을 수정하려면 Back 을 클릭합니다.
- Create StorageSystem 을 클릭합니다.
검증 단계
- OpenShift Data Foundation 클러스터가 정상인지 확인
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- Object 탭의 상태 카드에서 Object Service 와 Data Resiliency 모두 녹색 눈금이 있는지 확인합니다.
- 세부 정보 카드에 MCG 정보가 표시되는지 확인합니다.
- Pod 상태 확인
- OpenShift 웹 콘솔에서 워크로드 → 포드 를 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택하고 다음 포드가Running상태인지 확인합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
구성 요소 해당 Pod OpenShift Data Foundation Operator
-
OCS-operator-*작업자 노드의 Pod 1 -
OCS-metrics-exporter-*(작업자 노드에서 Pod) -
ODF-operator-controller-manager-*(1개의 작업자 노드에서 Pod) -
ODF-console-*(작업자 노드의 Pod)
rook-ceph Operator
rook-ceph-operator-*(모든 작업자 노드의 Pod)
Multicloud Object Gateway
-
NooBaa-operator-*(작업자 노드에서 Pod) -
NooBaa-core-*(작업자 노드에서 Pod) -
NooBaa-db-pg-*(1개의 작업자 노드의 pod) -
NooBaa-endpoint-*(모든 작업자 노드에서 Pod)
-
5장. 스토리지 클래스 및 스토리지 풀
OpenShift Data Foundation Operator는 사용 중인 플랫폼에 따라 기본 스토리지 클래스를 설치합니다. 이 기본 스토리지 클래스는 Operator가 소유하고 제어하며 삭제하거나 수정할 수 없습니다. 그러나 스토리지 클래스에 다른 동작을 갖도록 하려면 사용자 정의 스토리지 클래스를 생성할 수 있습니다.
다음 기능을 제공하는 스토리지 클래스에 매핑되는 스토리지 풀을 여러 개 생성할 수 있습니다.
- 자체 고가용성 애플리케이션이 두 개의 복제본으로 영구 볼륨을 사용할 수 있으므로 애플리케이션 성능이 향상될 수 있습니다.
- 압축이 활성화된 스토리지 클래스를 사용하여 영구 볼륨 클레임의 공간을 저장합니다.
외부 모드 OpenShift Data Foundation 클러스터에서는 여러 스토리지 클래스와 다중 풀이 지원되지 않습니다.
단일 장치 세트가 최소 클러스터인 경우 두 개의 새 스토리지 클래스만 생성할 수 있습니다. 모든 스토리지 클러스터 확장에서는 두 개의 새로운 스토리지 클래스를 사용할 수 있습니다.
5.1. 스토리지 클래스 및 풀 생성
기존 풀을 사용하여 스토리지 클래스를 생성하거나 스토리지 클래스를 생성하는 동안 새 풀을 생성할 수 있습니다.
사전 요구 사항
-
OpenShift Container Platform 웹 콘솔에 로그인하고 OpenShift Data Foundation 클러스터가
Ready상태인지 확인합니다.
절차
- 스토리지 → StorageClasses 를 클릭합니다.
- Create Storage Class 를 클릭합니다.
- 스토리지 클래스 이름 및 설명을 입력합니다.
회수 정책은 기본 옵션으로
Delete로 설정됩니다. 이 설정을 사용합니다.스토리지 클래스에서 회수 정책을
Retain으로 변경하면 PVC(영구 볼륨 클레임)를 삭제한 후에도 PV(영구 볼륨)가Released상태로 유지됩니다.볼륨 바인딩 모드는 기본 옵션으로
WaitForConsumer로 설정됩니다.Immediate옵션을 선택하면 PVC를 생성하는 동안 PV가 동시에 생성됩니다.- 영구 볼륨을 프로비저닝하는 데 사용되는 플러그인인 RBD Provisioner 를 선택합니다.
목록에서 기존 스토리지 풀을 선택하거나 새 풀을 생성합니다.
- 새 풀 생성
- Create New Pool 을 클릭합니다.
- Pool name 을 입력합니다.
- 2-way-Replication 또는 3-way-Replication 을 데이터 보호 정책으로 선택합니다.
데이터를 압축해야 하는 경우 압축 사용을 선택합니다.
압축을 활성화하면 애플리케이션 성능에 영향을 미칠 수 있으며 데이터를 이미 압축하거나 암호화할 때 효과가 없을 수 있습니다. 압축을 활성화하기 전에 기록된 데이터는 압축되지 않습니다.
- 생성 을 클릭하여 새 스토리지 풀을 생성합니다.
- 풀을 만든 후 완료 를 클릭합니다.
- 선택 사항: 암호화 활성화 확인란을 선택합니다.
- 생성을 클릭하여 스토리지 클래스를 생성합니다.
5.2. 영구 볼륨 암호화를 위한 스토리지 클래스 생성
PV(영구 볼륨) 암호화는 테넌트(애플리케이션) 간의 격리 및 기밀성을 보장합니다. PV 암호화를 사용하려면 PV 암호화의 스토리지 클래스를 생성해야 합니다.
OpenShift Data Foundation은 HashiCorp Vault에 암호화 암호 저장을 지원합니다. 다음 절차에 따라 영구 볼륨 암호화를 위해 외부 키 관리 시스템(KMS)을 사용하여 활성화된 암호화 스토리지 클래스를 생성합니다. 영구 볼륨 암호화는 RBD PV에서만 사용할 수 있습니다. 두 가지 방법으로 KMS에 대한 액세스를 구성할 수 있습니다.
-
vaulttokens사용 : 사용자가 토큰을 사용하여 인증할 수 있음 -
vaulttenantsa(기술 프리뷰) 사용: 사용자가 serviceaccounts를 사용하여 Vault로 인증할 수 있습니다.
vaulttenantsa 를 사용하여 KMS에 액세스하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
스토리지 클래스 생성 절차에 따라 사용 사례의 관련 사전 요구 사항 섹션을 참조하십시오.
5.2.1. vaulttokens사용 사전 요구 사항
-
OpenShift Data Foundation 클러스터는
Ready상태입니다. 외부 키 관리 시스템 (KMS)
- 토큰이 있고 Vault에서 키 값 백엔드 경로가 활성화되어 있는지 확인합니다. 자세한 내용은 Vault에서 키 값 및 정책 활성화를 참조하십시오.
- Vault 서버에서 서명된 인증서를 사용하고 있는지 확인합니다.
다음과 같이 테넌트의 네임스페이스에 보안을 생성합니다.
- OpenShift Container Platform 웹 콘솔에서 워크로드 → 시크릿 으로 이동합니다.
- 생성 → 키/값 시크릿을 클릭합니다.
-
Secret Name 을
ceph-csi-kms-token으로 입력합니다. -
Key 를
토큰으로입력합니다. - Value 를 입력합니다. Vault의 토큰입니다. 찾아보기 를 클릭하여 토큰이 포함된 파일을 선택하고 업로드하거나 텍스트 상자에 직접 토큰을 입력할 수 있습니다.
- 생성을 클릭합니다.
토큰은 ceph-csi-kms-token 을 사용하는 모든 암호화된 PVC가 삭제된 경우에만 삭제할 수 있습니다.
다음으로 5.2.3절. “PV 암호화용 스토리지 클래스 생성 절차” 의 단계를 따르십시오.
5.2.2. vaulttenantsa를 사용하기 위한 사전 요구 사항
-
OpenShift Data Foundation 클러스터는
Ready상태입니다. 외부 키 관리 시스템 (KMS)
- 정책이 존재하고 Vault에서 키 값 백엔드 경로가 활성화되어 있는지 확인합니다. 자세한 내용은 Vault에서 키 값 및 정책 활성화를 참조하십시오.
- Vault 서버에서 서명된 인증서를 사용하고 있는지 확인합니다.
다음과 같이 테넌트 네임스페이스에 다음 serviceaccount를 생성합니다.
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ServiceAccount metadata: name: ceph-csi-vault-sa EOFOpenShift Data Foundation에서 인증하고 Vault를 사용하기 전에 Kubernetes 인증 방법을 구성해야 합니다. 아래 지침은 OpenShift Data Foundation이 Vault로 인증할 수 있도록 하는 데 필요한
serviceAccount,ClusterRole,ClusterRoleBinding을 생성 및 구성합니다.Openshift 클러스터에 다음 YAML을 적용합니다.
apiVersion: v1 kind: ServiceAccount metadata: name: rbd-csi-vault-token-review --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-csi-vault-token-review rules: - apiGroups: ["authentication.k8s.io"] resources: ["tokenreviews"] verbs: ["create", "get", "list"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-csi-vault-token-review subjects: - kind: ServiceAccount name: rbd-csi-vault-token-review namespace: openshift-storage roleRef: kind: ClusterRole name: rbd-csi-vault-token-review apiGroup: rbac.authorization.k8s.io위에서 만든 serviceaccount(SA)와 관련된 시크릿 이름을 확인합니다.
$ oc -n openshift-storage get sa rbd-csi-vault-token-review -o jsonpath="{.secrets[*]['name']}"시크릿에서 토큰 및 CA 인증서를 가져옵니다.
$ oc get secret <secret associated with SA> -o jsonpath="{.data['token']}" | base64 --decode; echo $ oc get secret <secret associated with SA> -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echoOCP 클러스터 끝점을 검색합니다.
$ oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}"다음과 같이 Vault에서 kubernetes 인증 방법을 설정하려면 위 단계에서 수집된 정보를 사용합니다.
$ vault auth enable kubernetes $ vault write auth/kubernetes/config token_reviewer_jwt=<SA token> kubernetes_host=<OCP cluster endpoint> kubernetes_ca_cert=<SA CA certificate>
테넌트 네임스페이스에 대한 Vault에서 역할을 생성합니다.
$ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>
CSI-kubernetes는 OpenShift Data Foundation에서 Vault를 찾는 기본 역할 이름입니다. Openshift Data Foundation 클러스터의 테넌트 네임스페이스의 기본 서비스 계정 이름은ceph-csi-vault-sa입니다. 이러한 기본값은 테넌트 네임스페이스에 ConfigMap을 생성하여 덮어쓸 수 있습니다.기본 이름을 재정의하는 방법에 대한 자세한 내용은 테넌트 ConfigMap을 사용하여 Vault 연결 세부 정보를 참조하십시오.
PV encrytpion에 대해
vaulttenantsa방법을 사용하는 스토리지 클래스를 생성하려면 기존 ConfigMap을 편집하거나 Vault와의 연결을 설정하는 데 필요한 모든 정보를 보유하는csi-kms-connection-details라는 ConfigMap을 생성해야 합니다.아래 제공된 샘플 yaml을 사용하여
csi-kms-connection-detailConfigMap을 업데이트하거나 생성할 수 있습니다.apiVersion: v1 data: vault-tenant-sa: |- { "encryptionKMSType": "vaulttenantsa", "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>", "vaultTLSServerName": "<vault TLS server name>", "vaultAuthPath": "/v1/auth/kubernetes/login", "vaultAuthNamespace": "<vault auth namespace name>" "vaultNamespace": "<vault namespace name>", "vaultBackendPath": "<vault backend path name>", "vaultCAFromSecret": "<secret containing CA cert>", "vaultClientCertFromSecret": "<secret containing client cert>", "vaultClientCertKeyFromSecret": "<secret containing client private key>", "tenantSAName": "<service account name in the tenant namespace>" } metadata: name: csi-kms-connection-details-
EncryptionKMSType: 자격 증명 모음 인증에 서비스 계정을 사용하도록vaulttenantsa로 설정해야 합니다. -
vaultAddress: 포트 번호를 사용하여 자격 증명 모음 서버의 호스트 이름 또는 IP 주소입니다. -
vaultTLSServerName: (선택 사항) 자격 증명 모음 TLS 서버 이름 -
vaultAuthPath: (선택 사항) Vault에서 kubernetes auth 메서드가 활성화된 경로입니다. 기본 경로는kubernetes입니다.kubernetes이외의 다른 경로에서 auth 메서드를 활성화하면 이 변수를"/v1/auth/<path>/login"으로 설정해야 합니다. -
vaultAuthNamespace: (선택 사항) kubernetes auth 메서드가 활성화된 Vault 네임스페이스입니다. -
vaultNamespace: (선택 사항) 키를 저장하는 데 사용되는 백엔드 경로가 존재하는 Vault 네임스페이스 -
vaultBackendPath: 암호화 키가 저장되는 Vault의 백엔드 경로입니다. -
vaultCAFromSecret: Vault의 CA 인증서를 포함하는 OpenShift Data Foundation 클러스터의 시크릿 -
vaultClientCertFromSecret: Vault의 클라이언트 인증서를 포함하는 OpenShift Data Foundation 클러스터의 시크릿 -
vaultClientCertKeyFromSecret: Vault의 클라이언트 개인 키를 포함하는 OpenShift Data Foundation 클러스터의 시크릿 -
tenantSAName: (선택 사항) 테넌트 네임스페이스의 서비스 계정 이름입니다. 기본값은ceph-csi-vault-sa입니다. 다른 이름을 사용해야 하는 경우 이 변수를 적절하게 설정해야 합니다.
-
다음으로 5.2.3절. “PV 암호화용 스토리지 클래스 생성 절차” 의 단계를 따르십시오.
5.2.3. PV 암호화용 스토리지 클래스 생성 절차
vaulttokens 또는 vaulttenantsa 에 필요한 사전 요구 사항을 수행한 후 아래 단계를 수행하여 암호화가 활성화된 스토리지 클래스를 생성합니다.
- 스토리지 → StorageClasses 로 이동합니다.
- Create Storage Class 를 클릭합니다.
- 스토리지 클래스 이름 및 설명을 입력합니다.
- Reclaim Policy (폐기 정책)에 대해 Delete 또는 Retain 을 선택합니다. 기본적으로 삭제 가 선택됩니다.
- 볼륨 바인딩 모드 로 Immediate 또는 WaitForFirstConsumer 를 선택합니다. WaitForConsumer 가 기본 옵션으로 설정됩니다.
-
영구 볼륨을 프로비저닝하는 데 사용되는 플러그인인 RBD Provisioner
openshift-storage.rbd.csi.ceph.com을 선택합니다. - 목록에서 볼륨 데이터가 저장된 스토리지 풀을 선택하거나 새 풀을 생성합니다.
암호화 활성화 확인란을 선택합니다. KMS 연결 세부 정보를 설정하는 데 사용할 수 있는 두 가지 옵션이 있습니다.
-
기존 KMS 연결을 선택합니다. 드롭다운 목록에서 기존 KMS 연결을 선택합니다. 목록은
csi-kms-connection-detailsConfigMap에서 사용 가능한 연결 세부 정보에서 채워집니다. 새 KMS 연결을 생성합니다. 이는
vaulttoken에만적용됩니다.- Key Management Service Provider 는 기본적으로 Vault로 설정됩니다.
-
고유한 Vault 서비스 이름, Vault 서버의 호스트 주소 (https
://<hostname 또는 ip>) 및 포트 번호를 입력합니다. 고급 설정을 확장하여 Vault 구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.
- OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
- 선택 사항: TLS 서버 이름 및 Vault Enterprise Namespace 를 입력합니다.
- 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서, 클라이언트 인증서 및 클라이언트 개인 키를 제공합니다.
- 저장을 클릭합니다.
- 저장을 클릭합니다.
-
기존 KMS 연결을 선택합니다. 드롭다운 목록에서 기존 KMS 연결을 선택합니다. 목록은
- 생성을 클릭합니다.
HashiCorp Vault 설정에서 백엔드 경로에서 사용하는 KV(Key/Value) 보안 엔진 API 버전의 자동 탐지를 허용하지 않는 경우 ConfigMap을 편집하여
VAULT_BACKEND또는vaultBackend매개변수를 추가합니다.참고VAULT_BACKEND또는vaultBackend는 백엔드 경로와 연결된 KV 시크릿 엔진 API 버전을 지정하기 위해 configmap에 추가된 선택적 매개변수입니다. 값이 백엔드 경로에 설정된 KV 시크릿 엔진 API 버전과 일치하는지 확인합니다. 그러지 않으면 PVC(영구 볼륨 클레임) 생성 중에 실패할 수 있습니다.새로 생성된 스토리지 클래스에서 사용하는 암호화KMSID를 식별합니다.
- OpenShift 웹 콘솔에서 스토리지 → 스토리지 클래스로 이동합니다.
- 스토리지 클래스 이름 → YAML 탭을 클릭합니다.
스토리지 클래스에서 사용하는 encryptionKMSID 를 캡처합니다.
예제:
encryptionKMSID: 1-vault
- OpenShift 웹 콘솔에서 워크로드 → ConfigMaps 로 이동합니다.
- KMS 연결 세부 정보를 보려면 csi-kms-connection-details 를 클릭합니다.
ConfigMap을 편집합니다.
- Action 메뉴 (journal) → Edit ConfigMap 을 클릭합니다.
이전에 식별된 암호화KMSID에 대해 구성된 백엔드에 따라
VAULT_BACKEND또는vaultBackend매개변수를 추가합니다.KV 시크릿 엔진 API에 kv, 버전 1 및
kv-v2를 KV 시크릿 엔진 API 버전 2에 할당할 수 있습니다.예제:
kind: ConfigMap apiVersion: v1 metadata: name: csi-kms-connection-details [...] data: 1-vault: |- { "KMS_PROVIDER": "vaulttokens", "KMS_SERVICE_NAME": "1-vault", [...] "VAULT_BACKEND": "kv-v2" } 2-vault: |- { "encryptionKMSType": "vaulttenantsa", [...] "vaultBackend": "kv-v2" }- 저장을 클릭합니다.
다음 단계
스토리지 클래스는 암호화된 영구 볼륨을 생성하는 데 사용할 수 있습니다. 자세한 내용은 영구 볼륨 클레임 관리를 참조하십시오.
중요Red Hat은 기술 파트너와 협력하여 이 문서를 고객에게 서비스로 제공합니다. 그러나 Red Hat은 HashiCorp 제품을 지원하지 않습니다. 이 제품에 대한 기술 지원의 경우 HashiCorp 에 문의하십시오.
5.2.3.1. 테넌트 ConfigMap을 사용하여 Vault 연결 세부 정보 덮어쓰기
openshift-storage 네임스페이스의 csi-kms-connection-details ConfigMap에 설정된 값과 다른 구성 옵션을 사용하여 Openshift 네임스페이스에 ConfigMap을 생성하여 Vault 연결 세부 정보를 재구성할 수 있습니다. ConfigMap은 테넌트 네임스페이스에 있어야 합니다. 테넌트 네임스페이스의 ConfigMap 값은 해당 네임스페이스에서 생성된 암호화된 영구 볼륨에 대한 csi-kms-connection-details ConfigMap에 설정된 값을 재정의합니다.
절차
- 테넌트 네임스페이스에 있는지 확인합니다.
- 워크로드 → ConfigMap을 클릭합니다.
- Create ConfigMap 을 클릭합니다.
다음은 샘플 yaml입니다. 지정된 테넌트 네임스페이스에 대한 초과된 값은 다음과 같이
data섹션에서 지정할 수 있습니다.--- apiVersion: v1 kind: ConfigMap metadata: name: ceph-csi-kms-config data: vaultAddress: "<vault_address:port>" vaultBackendPath: "<backend_path>" vaultTLSServerName: "<vault_tls_server_name>" vaultNamespace: "<vault_namespace>"
- yaml을 편집한 후 Create 를 클릭합니다.
6장. OpenShift Container Platform 서비스의 스토리지 구성
OpenShift Data Foundation을 사용하여 이미지 레지스트리, 모니터링 및 로깅과 같은 OpenShift Container Platform 서비스에 스토리지를 제공할 수 있습니다.
이러한 서비스의 스토리지를 구성하는 프로세스는 OpenShift Data Foundation 배포에 사용되는 인프라에 따라 다릅니다.
이러한 서비스에 대한 충분한 저장 용량을 보유하고 있는지 항상 확인하십시오. 이러한 중요한 서비스의 스토리지가 부족하면 클러스터가 작동하지 않고 복구하기가 매우 어려워집니다.
Red Hat은 이러한 서비스에 대해 더 짧은 큐레이션 및 보존 간격을 설정할 것을 권장합니다. 자세한 내용은 OpenShift Container Platform 설명서에서 영구 스토리지 구성의 Prometheus 지표 데이터 하위 섹션에 대한 Curator 일정 구성 및 보존 시간 수정을 참조하십시오.
이러한 서비스를 위한 스토리지 공간을 실행하는 경우 Red Hat 고객 지원에 문의하십시오.
6.1. OpenShift Data Foundation을 사용하도록 이미지 레지스트리 구성
OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 컨테이너 이미지 레지스트리에 빌드를 제공합니다. 일반적으로 레지스트리는 클러스터에 빌드된 이미지의 게시 대상과 클러스터에서 실행되는 워크로드의 이미지 소스로 사용됩니다.
이 프로세스에서는 기존 이미지 레지스트리의 데이터를 새 이미지 레지스트리로 마이그레이션하지 않습니다. 기존 레지스트리에 컨테이너 이미지가 이미 있는 경우 이 프로세스를 완료하기 전에 레지스트리를 백업한 후 이 프로세스가 완료되면 이미지를 다시 등록합니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
-
OpenShift Data Foundation Operator는
openshift-storage네임스페이스에 설치 및 실행됩니다. OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 Operator 를 확인합니다. -
이미지 레지스트리 Operator가
openshift-image-registry네임스페이스에 설치되어 실행됩니다. OpenShift 웹 콘솔에서 관리 → 클러스터 설정 → 클러스터 Operator를 클릭하여 클러스터 운영자를 확인합니다. -
프로비저너
openshift-storage.cephfs.csi.ceph.com이 있는 스토리지 클래스를 사용할 수 있습니다. OpenShift 웹 콘솔에서 스토리지 → StorageClasses를 클릭하여 사용 가능한 스토리지 클래스를 확인합니다.
절차
사용할 이미지 레지스트리에 대한 영구 볼륨 클레임을 생성합니다.
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
-
프로젝트를
openshift-image-registry로 설정합니다. 영구 볼륨 클레임 생성 을 클릭합니다.
-
위에서 검색한 사용 가능한 스토리지 클래스 목록에서 프로비저너
openshift-storage.cephfs.csi.ceph.com을 사용하여 스토리지 클래스 를 지정합니다. -
영구 볼륨 클레임 이름 (예:
ocs4registry)을 지정합니다. -
공유 액세스
(RWX)의 액세스 모드를 지정합니다. - Size 를 100GB 이상으로 지정합니다.
생성을 클릭합니다.
새 영구 볼륨 클레임의 상태가
Bound로 표시될 때까지 기다립니다.
-
위에서 검색한 사용 가능한 스토리지 클래스 목록에서 프로비저너
새 영구 볼륨 클레임을 사용하도록 클러스터의 이미지 레지스트리를 구성합니다.
- Administration → Custom Resource Definitions 를 클릭합니다.
-
imageregistry.operator.openshift.io그룹과 연결된Config사용자 정의 리소스 정의를 클릭합니다. - Instances 탭을 클릭합니다.
- 클러스터 인스턴스 옆에 있어야 Action Menu(작업 메뉴) → Edit Config (구성 편집) 를 클릭합니다.
새 영구 볼륨 클레임을 이미지 레지스트리의 영구 스토리지로 추가합니다.
spec:에서 다음을 추가합니다. 필요한 경우 기존스토리지:섹션을 교체합니다.storage: pvc: claim: <new-pvc-name>예를 들면 다음과 같습니다.
storage: pvc: claim: ocs4registry- 저장을 클릭합니다.
새 구성이 사용 중인지 확인합니다.
- 워크로드 → 포드 를 클릭합니다.
-
프로젝트를
openshift-image-registry로 설정합니다. -
새
image-registry-*Pod가Running이고 이전image-registry-*Pod가 종료되었는지 확인합니다. -
새
image-registry-*Pod를 클릭하여 Pod 세부 정보를 확인합니다. -
볼륨 까지 아래로 스크롤하고
registry-storage볼륨에 새 영구 볼륨 클레임(예:ocs4registry)과 일치하는 Type 이 있는지 확인합니다.
6.2. OpenShift Data Foundation을 사용하도록 모니터링 구성
OpenShift Data Foundation은 Prometheus 및 Alert Manager로 구성된 모니터링 스택을 제공합니다.
이 섹션의 지침에 따라 OpenShift Data Foundation을 모니터링 스택의 스토리지로 구성합니다.
스토리지 공간이 부족하면 모니터링이 작동하지 않습니다. 항상 모니터링을 위한 충분한 저장 용량을 보유하고 있는지 확인하십시오.
이 서비스에 대해 짧은 보존 간격을 구성하는 것이 좋습니다. 자세한 내용은 OpenShift Container Platform 설명서의 모니터링 가이드의 Prometheus 지표 데이터 수정 에서 참조하십시오.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
-
OpenShift Data Foundation Operator는
openshift-storage네임스페이스에 설치 및 실행됩니다. OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 Operator 를 확인합니다. -
openshift-monitoring네임스페이스에 Operator 모니터링이 설치되어 실행 중입니다. OpenShift 웹 콘솔에서 관리 → 클러스터 설정 → 클러스터 Operator 를 클릭하여 클러스터 운영자를 확인합니다. -
프로비저너
openshift-storage.rbd.csi.ceph.com이 있는 스토리지 클래스를 사용할 수 있습니다. OpenShift 웹 콘솔에서 스토리지 → StorageClasses를 클릭하여 사용 가능한 스토리지 클래스를 확인합니다.
절차
- OpenShift 웹 콘솔에서 워크로드 → 구성 맵 으로 이동합니다.
-
프로젝트 드롭다운을
openshift-monitoring로 설정합니다. - 구성 맵 생성을 클릭합니다.
다음 예제를 사용하여 새
cluster-monitoring-config구성 맵을 정의합니다.각도 괄호(
<,>)의 내용을 고유한 값(예:retention)으로 바꿉니다. 24h또는storage: 40Gi.storageClassName을 프로비저너
openshift-storage.rbd.csi.ceph.com을 사용하는스토리지클래스로 교체합니다. 아래 예에서 storageclass 의 이름은ocs-storagecluster-ceph-rbd입니다.cluster-monitoring-config구성 맵의 예apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: <time to retain monitoring files, e.g. 24h> volumeClaimTemplate: metadata: name: ocs-prometheus-claim spec: storageClassName: ocs-storagecluster-ceph-rbd resources: requests: storage: <size of claim, e.g. 40Gi> alertmanagerMain: volumeClaimTemplate: metadata: name: ocs-alertmanager-claim spec: storageClassName: ocs-storagecluster-ceph-rbd resources: requests: storage: <size of claim, e.g. 40Gi>- 생성 을 클릭하여 구성 맵을 저장하고 만듭니다.
검증 단계
영구 볼륨 클레임이 Pod에 바인딩되었는지 확인합니다.
- 스토리지 → 영구 볼륨 클레임 으로 이동합니다.
-
프로젝트 드롭다운을
openshift-monitoring로 설정합니다. 3개의
alertmanager-main-*Pod 및 두 개의prometheus-k8s-*Pod에 연결된Bound상태로 5 영구 볼륨 클레임이 표시되는지 확인합니다.그림 6.1. 생성 및 바인딩된 스토리지 모니터링

새
alertmanager-main-*포드가Running(실행 중) 상태로 표시되는지 확인합니다.- 워크로드 → Pod 로 이동합니다.
-
새
alertmanager-main-*Pod를 클릭하여 Pod 세부 정보를 확인합니다. 볼륨까지 아래로 스크롤하여 볼륨에 새로운 영구 볼륨 클레임 ( 예:
ocs-alertmanager-claim-alertmanager-main-0)과 일치하는 Type,ocs-alertrtmanager-claim-alertmanager-main-0이 있는지 확인합니다.그림 6.2.
alertmanager-main-*Pod에 연결된 영구 볼륨 클레임
새
prometheus-k8s-*Pod가Running상태로 표시되는지 확인합니다.-
새
prometheus-k8s-*Pod를 클릭하여 Pod 세부 정보를 확인합니다. 볼륨까지 아래로 스크롤하여 볼륨에 새로운 영구 볼륨 클레임 ( 예:
ocs-prometheus-claim-prometheus-prometheus-prometheus-prometheus-prometheus-prometheus-k8s-0)과 일치하는 Type, ocs-prometheus-prometheus-claim-claims가 있는지 확인합니다.그림 6.3.
prometheus-k8s-*Pod에 연결된 영구 볼륨 클레임
-
새
6.3. OpenShift Data Foundation의 클러스터 로깅
클러스터 로깅을 배포하여 다양한 OpenShift Container Platform 서비스에 대한 로그를 집계할 수 있습니다. 클러스터 로깅 배포 방법에 대한 자세한 내용은 클러스터 로깅 배포를 참조하십시오.
초기 OpenShift Container Platform 배포 시 OpenShift Data Foundation은 기본적으로 구성되지 않으며 OpenShift Container Platform 클러스터는 노드에서 사용할 수 있는 기본 스토리지에만 의존합니다. OpenShift Data Foundation에서 지원하는 OpenShift 로깅(ElasticSearch)의 기본 구성을 편집하여 OpenShift Data Foundation 지원 로깅(Elasticsearch)을 사용할 수 있습니다.
이러한 서비스에 대한 충분한 저장 용량을 보유하고 있는지 항상 확인하십시오. 이러한 중요한 서비스에 대한 스토리지 공간을 실행하는 경우 로깅 애플리케이션이 작동하지 않고 복구하기가 매우 어려워집니다.
Red Hat은 이러한 서비스에 대해 더 짧은 큐레이션 및 보존 간격을 설정할 것을 권장합니다. 자세한 내용은 OpenShift Container Platform 설명서의 클러스터 로깅 큐레이터 를 참조하십시오.
이러한 서비스를 위한 스토리지 공간을 실행하는 경우 Red Hat 고객 지원에 문의하십시오.
6.3.1. 영구 스토리지 구성
스토리지 클래스 이름 및 크기 매개변수를 사용하여 Elasticsearch 클러스터의 영구 스토리지 클래스 및 크기를 구성할 수 있습니다. Cluster Logging Operator는 이러한 매개변수를 기반으로 Elasticsearch 클러스터의 각 데이터 노드에 대한 영구 볼륨 클레임을 생성합니다. 예를 들면 다음과 같습니다.
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage:
storageClassName: "ocs-storagecluster-ceph-rbd”
size: "200G"
이 예에서는 클러스터의 각 데이터 노드가 200GiB ocs-storagecluster-ceph-rbd 스토리지를 요청하는 영구 볼륨 클레임에 바인딩되도록 지정합니다. 각 기본 분할은 단일 복제본에서 지원합니다. shard 사본은 모든 노드에 복제되며 항상 사용 가능하며 단일 중복 정책으로 인해 두 개 이상의 노드가 있는 경우 복사본을 복구할 수 있습니다. Elasticsearch 복제 정책에 대한 자세한 내용은 클러스터 로깅 배포 및 구성 의 Elasticsearch 복제 정책을 참조하십시오.
스토리지 블록을 종료하면 기본 스토리지에서 지원하는 배포가 생성됩니다. 예를 들면 다음과 같습니다.
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage: {}자세한 내용은 클러스터 로깅 구성을 참조하십시오.
6.3.2. OpenShift data Foundation을 사용하도록 클러스터 로깅 구성
이 섹션의 지침에 따라 OpenShift Data Foundation을 OpenShift 클러스터 로깅의 스토리지로 구성합니다.
OpenShift Data Foundation에서 처음으로 로깅을 구성할 때 모든 로그를 가져올 수 있습니다. 그러나 제거 및 로깅을 다시 설치하면 이전 로그가 제거되고 새 로그만 처리됩니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
-
OpenShift Data Foundation Operator는
openshift-storage네임스페이스에 설치 및 실행됩니다. -
Cluster logging Operator가
openshift-logging네임스페이스에 설치되어 실행됩니다.
절차
- OpenShift 웹 콘솔의 왼쪽 창에서 Administration → Custom Resource Definitions 를 클릭합니다.
- 사용자 정의 리소스 정의 페이지에서 ClusterLogging 을 클릭합니다.
- 사용자 정의 리소스 정의 개요 페이지의 작업 메뉴에서 인스턴스 보기를 선택하거나 인스턴스 탭을 클릭합니다.
클러스터 로깅 페이지에서 클러스터 로깅 생성을 클릭합니다.
데이터를 로드하기 위해 페이지를 새로 고쳐야 할 수도 있습니다.
YAML에서 storageClassName을 provisioner
openshift-storage.rbd.csi.ceph.com을 사용하는storageclass로 바꿉니다. 아래 예에서 storageclass 의 이름은ocs-storagecluster-ceph-rbd입니다.apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: ocs-storagecluster-ceph-rbd size: 200G # Change as per your requirement redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: replicas: 1 curation: type: "curator" curator: schedule: "30 3 * * *" collection: logs: type: "fluentd" fluentd: {}OpenShift Data Foundation 노드에 테인트된 경우 로깅을 위해 데몬 세트 Pod 예약을 활성화하려면 허용 오차를 추가해야 합니다.
spec: [...] collection: logs: fluentd: tolerations: - effect: NoSchedule key: node.ocs.openshift.io/storage value: 'true' type: fluentd- 저장을 클릭합니다.
검증 단계
영구 볼륨 클레임이
elasticsearchPod에 바인딩되었는지 확인합니다.- 스토리지 → 영구 볼륨 클레임 으로 이동합니다.
-
프로젝트 드롭다운을
openshift-logging으로 설정합니다. Persistent Volume Claims가
elasticsearch-* pod에 연결된Bound상태로 표시되는지 확인합니다.그림 6.4. 클러스터 로깅 생성 및 바인딩

새 클러스터 로깅이 사용 중인지 확인합니다.
- 워크로드 → Pod 를 클릭합니다.
-
프로젝트를
openshift-logging으로 설정합니다. -
새
elasticsearch-* Pod가Running상태로 표시되는지 확인합니다. -
새
elasticsearch-* Pod를 클릭하여 Pod 세부 정보를 확인합니다. -
볼륨까지 아래로 스크롤하여 elasticsearch 볼륨에 새 영구 볼륨 클레임 ( 예:
elasticsearch-elasticsearch-cdm-9r624biv-3)과 일치하는 Type 이 있는지 확인합니다. - 영구 볼륨 클레임 이름을 클릭하고 PersistentVolumeClaim Overview 페이지에서 스토리지 클래스 이름을 확인합니다.
Elasticsearch Pod에 연결된 PV의 PV 전체 시나리오를 방지하려면 더 짧은 큐레이터 시간을 사용해야 합니다.
보존 설정에 따라 Elasticsearch 데이터를 삭제하도록 Curator를 구성할 수 있습니다. 다음 기본 인덱스 데이터 보존을 기본값으로 5일로 설정하는 것이 좋습니다.
config.yaml: |
openshift-storage:
delete:
days: 5자세한 내용은 Elasticsearch 데이터 Curation을 참조하십시오.
영구 볼륨 클레임에서 지원하는 클러스터 로깅을 설치 제거하려면 각 배포 가이드의 제거 장에 있는 OpenShift Data Foundation에서 클러스터 로깅 Operator를 제거하는 절차를 사용하십시오.
7장. OpenShift Data Foundation을 사용하여 OpenShift Container Platform 애플리케이션 백업
OpenShift Container Platform을 설치하는 동안 OpenShift Data Foundation을 직접 설치할 수 없습니다. 그러나 Operator Hub를 사용하여 기존 OpenShift Container Platform에 OpenShift Data Foundation을 설치한 다음 OpenShift Data Foundation에서 지원하도록 OpenShift Container Platform 애플리케이션을 구성할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform이 설치되어 있으며 OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
-
OpenShift Data Foundation이
openshift-storage네임스페이스에 설치되어 실행됩니다.
절차
OpenShift 웹 콘솔에서 다음 중 하나를 수행합니다.
워크로드 → 배포를 클릭합니다.
배포 페이지에서 다음 중 하나를 수행할 수 있습니다.
- 기존 배포를 선택하고 Action 메뉴(hiera) 메뉴에서 Add Storage (스토리지 추가) 옵션을 클릭합니다.
새 배포를 생성한 다음 스토리지를 추가합니다.
- Create Deployment (배포 생성)를 클릭하여 새 배포를 생성합니다.
-
사용자 요구 사항에 따라
YAML을 편집하여 배포를 생성합니다. - 생성을 클릭합니다.
- 페이지 오른쪽 상단에 있는 작업 드롭다운 메뉴에서 스토리지 추가 를 선택합니다.
워크로드 → 배포 구성을 클릭합니다.
배포 구성 페이지에서 다음 중 하나를 수행할 수 있습니다.
- 기존 배포를 선택하고 Action 메뉴(hiera) 메뉴에서 Add Storage (스토리지 추가) 옵션을 클릭합니다.
새 배포를 생성한 다음 스토리지를 추가합니다.
- Create Deployment Config (배포 구성 생성)를 클릭하여 새 배포를 생성합니다.
-
사용자 요구 사항에 따라
YAML을 편집하여 배포를 생성합니다. - 생성을 클릭합니다.
- 페이지 오른쪽 상단에 있는 작업 드롭다운 메뉴에서 스토리지 추가 를 선택합니다.
스토리지 추가 페이지에서 다음 옵션 중 하나를 선택할 수 있습니다.
- 기존 클레임 사용 옵션을 클릭하고 드롭다운 목록에서 적절한 PVC를 선택합니다.
새 클레임 생성 옵션을 클릭합니다.
-
스토리지 클래스 드롭다운 목록에서 적절한
CephFS또는RBD스토리지 클래스 를 선택합니다. - 영구 볼륨 클레임의 이름을 입력합니다.
ReadWriteOnce (RWO) 또는 ReadWriteMany (RWX) 액세스 모드를 선택합니다.
참고ReadOnlyMany (ROX)는 지원되지 않으므로 비활성화됩니다.
원하는 스토리지 용량의 크기를 선택합니다.
참고블록 PV를 확장할 수 있지만 영구 볼륨 클레임 생성 후에는 스토리지 용량을 줄일 수 없습니다.
-
스토리지 클래스 드롭다운 목록에서 적절한
- 컨테이너 내부의 마운트 경로 볼륨에 대한 마운트 경로 및 하위 경로(필요한 경우)를 지정합니다.
- 저장을 클릭합니다.
검증 단계
구성에 따라 다음 중 하나를 수행합니다.
- 워크로드 → 배포를 클릭합니다.
- 워크로드 → 배포 구성을 클릭합니다.
- 필요에 따라 프로젝트를 설정합니다.
- 스토리지를 추가한 배포를 클릭하여 배포 세부 정보를 표시합니다.
- 볼륨 까지 아래로 스크롤하여 배포에 할당된 영구 볼륨 클레임과 일치하는 Type 이 있는지 확인합니다.
- 영구 볼륨 클레임 이름을 클릭하고 영구 볼륨 클레임 개요 페이지에서 스토리지 클래스 이름을 확인합니다.
8장. Red Hat OpenShift Data Foundation 전용 작업자 노드를 사용하는 방법
Red Hat OpenShift Container Platform 서브스크립션에는 OpenShift Data Foundation 서브스크립션이 필요합니다. 그러나 인프라 노드를 사용하여 OpenShift Data Foundation 리소스를 예약하는 경우 OpenShift Container Platform 서브스크립션 비용을 절감할 수 있습니다.
Machine API 지원 없이 환경 간에 일관성을 유지하는 것이 중요합니다. 이로 인해 모든 경우에 worker 또는 infra로 라벨이 지정된 특수 카테고리가 있거나 두 역할을 모두 갖는 것이 좋습니다. 자세한 내용은 8.3절. “인프라 노드 수동 생성” 섹션을 참조하십시오.
8.1. 인프라 노드 분석
OpenShift Data Foundation과 함께 사용할 인프라 노드에는 몇 가지 속성이 있습니다. 노드가 RuntimeClass 인타이틀먼트를 사용하지 않도록 하려면 infra node-role 레이블이 필요합니다. infra node-role 라벨은 OpenShift Data Foundation을 실행하는 노드에 OpenShift Data Foundation 자격만 필요하다는 것을 확인합니다.
-
node-role.kubernetes.io/infra로 레이블이 지정됩니다.
인프라 노드가 OpenShift Data Foundation 리소스만 예약하려면 NoSchedule 효과를 사용하여 OpenShift Data Foundation 테인트를 추가해야 합니다.
-
node.ocs.openshift.io/storage="true"로 테인트됨
이 레이블은 Gradle 노드를 infra 노드로 식별하므로 journalctl 서브스크립션 비용이 적용되지 않습니다. 테인트를 사용하면 비 OpenShift Data Foundation 리소스가 테인트된 노드에 예약되지 않습니다.
노드에 스토리지 테인트를 추가하려면 openshift-dns daemonset 와 같은 다른 daemonset Pod에 대한 허용 오차 처리가 필요할 수 있습니다. 허용 오차를 관리하는 방법에 대한 자세한 내용은 기술 자료 문서를 참조하십시오. https://access.redhat.com/solutions/6592171.
OpenShift Data Foundation 서비스를 실행하는 데 사용할 인프라 노드에 필요한 테인트 및 라벨의 예:
spec:
taints:
- effect: NoSchedule
key: node.ocs.openshift.io/storage
value: "true"
metadata:
creationTimestamp: null
labels:
node-role.kubernetes.io/worker: ""
node-role.kubernetes.io/infra: ""
cluster.ocs.openshift.io/openshift-storage: ""8.2. 인프라 노드 생성을 위한 머신 세트
환경에서 Machine API가 지원되는 경우 인프라 노드를 프로비저닝할 머신 세트 템플릿에 레이블을 추가해야 합니다. 머신 API에서 생성한 노드에 라벨을 수동으로 추가하는 데 대한 안티바이러스가 방지하십시오. 이렇게 하는 것은 배포로 생성된 Pod에 라벨을 추가하는 것과 유사합니다. 두 경우 모두 Pod/노드에 실패하면 교체 Pod/노드에 적절한 레이블이 없습니다.
EC2 환경에서는 각각 별도의 가용 영역(예: us-east-2a, us-east-2b, us-east-2c)에 인프라 노드를 프로비저닝하도록 구성된 세 개의 머신 세트가 필요합니다. 현재 OpenShift Data Foundation은 세 개 이상의 가용성 영역에서의 배포를 지원하지 않습니다.
다음 머신 세트 템플릿 예에서는 인프라 노드에 필요한 적절한 테인트 및 라벨을 사용하여 노드를 생성합니다. 이는 OpenShift Data Foundation 서비스를 실행하는 데 사용됩니다.
template:
metadata:
creationTimestamp: null
labels:
machine.openshift.io/cluster-api-cluster: kb-s25vf
machine.openshift.io/cluster-api-machine-role: worker
machine.openshift.io/cluster-api-machine-type: worker
machine.openshift.io/cluster-api-machineset: kb-s25vf-infra-us-west-2a
spec:
taints:
- effect: NoSchedule
key: node.ocs.openshift.io/storage
value: "true"
metadata:
creationTimestamp: null
labels:
node-role.kubernetes.io/infra: ""
cluster.ocs.openshift.io/openshift-storage: ""인프라 노드에 테인트를 추가하는 경우 다른 워크로드의 테인트에 허용 오차를 추가해야 합니다(예: fluentd pod). 자세한 내용은 OpenShift 4의 Red Hat 지식베이스 솔루션 인프라 노드를 참조하십시오.
8.3. 인프라 노드 수동 생성
환경에서 Machine API가 지원되지 않는 경우에만 라벨을 노드에 직접 적용해야 합니다. 수동 생성을 수행하려면 OpenShift Data Foundation 서비스를 예약하는 데 3개 이상의 worker 노드를 사용할 수 있어야 하며 이러한 노드에 충분한 CPU 및 메모리 리소스가 있어야 합니다. RuntimeClass 서브스크립션 비용을 방지하려면 다음이 필요합니다.
oc label node <node> node-role.kubernetes.io/infra="" oc label node <node> cluster.ocs.openshift.io/openshift-storage=""
인프라 노드가 OpenShift Data Foundation 리소스만 예약하고 기타 비 OpenShift Data Foundation 워크로드를 회신하도록 NoSchedule OpenShift Data Foundation 테인트를 추가해야 합니다.
oc adm taint node <node> node.ocs.openshift.io/storage="true":NoSchedule
node-role node-role.kubernetes.io/worker=""를 제거하지 마십시오.
node-role.kubernetes.io/worker="" 를 제거하면 OpenShift 스케줄러와 MachineConfig 리소스를 모두 변경하지 않는 한 문제가 발생할 수 있습니다.
이미 제거된 경우 각 인프라 노드에 다시 추가해야 합니다. node-role node-role.kubernetes.io/infra="" 및 OpenShift Data Foundation 테인트를 추가하면 인타이틀먼트 제외 요구 사항을 준수할 수 있습니다.
9장. 스토리지 노드 확장
OpenShift Data Foundation의 스토리지 용량을 확장하려면 다음 중 하나를 수행할 수 있습니다.
- 스토리지 노드 확장 - 기존 OpenShift Data Foundation 작업자 노드에 스토리지 용량 추가
- 스토리지 노드 확장 - 스토리지 용량이 포함된 새 작업자 노드 추가
9.1. 스토리지 노드 확장 요구사항
스토리지 노드를 확장하기 전에 다음 섹션을 참조하여 특정 Red Hat OpenShift Data Foundation 인스턴스에 대한 노드 요구 사항을 이해해야 합니다.
- 플랫폼 요구 사항
스토리지 장치 요구 사항
항상 충분한 스토리지 용량을 보유하고 있는지 확인하십시오.
스토리지가 완전히 채워지면 용량을 추가하거나 스토리지에서 콘텐츠를 삭제하여 공간을 확보할 수 없습니다. 완전히 완전한 저장은 복구하기가 매우 어렵습니다.
클러스터 스토리지 용량이 75%(near-full) 및 전체 용량의 85%(전체)에 도달하면 용량 경고가 발행됩니다. 항상 용량 경고를 신속하게 처리하고 저장 공간이 부족하지 않도록 스토리지를 정기적으로 검토합니다.
스토리지 공간을 완전히 실행하는 경우 Red Hat 고객 지원에 문의하십시오.
9.2. Red Hat OpenStack Platform 인프라의 OpenShift Data Foundation 노드에 용량을 추가하여 스토리지 확장
구성된 Red Hat OpenShift Data Foundation 작업자 노드에 스토리지 용량 및 성능을 추가할 수 있습니다.
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
- OpenShift 웹 콘솔의 관리 권한.
- 배포 중에 프로비저닝된 스토리지 클래스 이외의 스토리지 클래스를 사용하여 확장하려면 먼저 추가 스토리지 클래스를 정의합니다. 자세한 내용은 스토리지 클래스 생성 을 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → 설치된 Operator를 클릭합니다.
- OpenShift Data Foundation Operator를 클릭합니다.
Storage Systems 탭을 클릭합니다.
- 스토리지 시스템 이름 맨 오른쪽에 있는 Action Menu(작업 메뉴) 를 클릭하여 옵션 메뉴를 확장합니다.
- 옵션 메뉴에서 용량 추가 를 선택합니다.
- 스토리지 클래스 를 선택합니다.
배포 중에 생성된 기본 스토리지 클래스를 사용하는 경우 스토리지 클래스를 표준으로 설정해야 합니다. 다른 스토리지 클래스를 생성한 경우 적합한 스토리지 클래스를 선택합니다.
+ Raw Capacity 필드는 스토리지 클래스 생성 중에 설정된 크기를 표시합니다. OpenShift Data Foundation에서는 복제본 수를 3개로 사용하기 때문에 소비되는 총 스토리지의 양은 3배입니다.
추가를 클릭합니다.
-
상태를 확인하려면 스토리지 → OpenShift Data Foundation 으로 이동하여 Status 카드의
스토리지시스템에 녹색 눈금이 있는지 확인합니다.
-
상태를 확인하려면 스토리지 → OpenShift Data Foundation 으로 이동하여 Status 카드의
검증 단계
Raw Capacity 카드를 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
블록 및 파일 탭에서 Raw Capacity 카드를 확인합니다.
선택 항목에 따라 용량이 증가합니다.
참고원시 용량은 복제를 고려하지 않고 전체 용량을 표시합니다.
새 OSD 및 해당 새 PVC(영구 볼륨 클레임)가 생성되었는지 확인합니다.
새로 생성된 OSD의 상태를 보려면 다음을 수행합니다.
- OpenShift 웹 콘솔에서 워크로드 → 포드 를 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
PVC 상태를 보려면 다음을 수행합니다.
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
선택 사항: 클러스터에서 클러스터 전체 암호화가 활성화된 경우 새 OSD 장치가 암호화되었는지 확인합니다.
새 OSD 포드가 실행 중인 노드를 식별합니다.
$ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name><OSD-pod-name>OSD 포드의 이름입니다.
예를 들면 다음과 같습니다.
oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
이전 단계에서 확인한 각 노드에서 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node-name><node-name>노드의 이름입니다.
$ chroot /host
ocs-deviceset이름 옆에 있는crypt키워드를 확인합니다.$ lsblk
Red Hat 지원 팀의 지원 만 통해 클러스터 감소가 지원됩니다.
9.3. 새 노드를 추가하여 스토리지 용량 확장
스토리지 용량을 확장하려면 다음을 수행해야 합니다.
- 기존 작업자 노드가 최대 지원되는 OSD에서 이미 실행 중인 경우 스토리지 용량을 늘리려면 새 노드를 추가합니다. 이는 초기 구성 중에 선택한 용량의 3개의 OSD가 증가합니다.
- 새 노드가 성공적으로 추가되었는지 확인합니다.
- 노드를 추가한 후 스토리지 용량 확장
사전 요구 사항
- OpenShift Container Platform 클러스터에 로그인해야 합니다.
절차
- 컴퓨팅 → 머신 설정 으로 이동합니다.
노드를 추가하려는 머신 세트에서 머신 수 편집 을 선택합니다.
- 노드 양을 추가하고 저장을 클릭합니다.
- 컴퓨팅 → 노드 를 클릭하고 새 노드가 Ready 상태인지 확인합니다.
OpenShift Data Foundation 레이블을 새 노드에 적용합니다.
- 새 노드의 경우 Action menu(작업 메뉴) → Edit Labels (레이블 편집) 를 클릭합니다.
- cluster.ocs.openshift.io/openshift-storage 를 추가하고 저장을 클릭합니다.
서로 다른 영역에 각각 3개의 노드를 추가하는 것이 좋습니다. 노드를 3개 추가하고 모든 노드에 대해 이 절차를 수행해야 합니다.
검증 단계
- 새 노드가 추가되었는지 확인하려면 새 노드 추가 확인을 참조하십시오.
9.3.1. 새 노드 추가 확인
다음 명령을 실행하고 출력에 새 노드가 있는지 확인합니다.
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
워크로드 → Pod 를 클릭하고 새 노드의 다음 Pod가 Running 상태인지 확인합니다.
-
csi-cephfsplugin-* -
csi-rbdplugin-*
-
9.3.2. 스토리지 용량 확장
OpenShift Data Foundation에 새 노드를 추가한 후 용량을 추가하여 스토리지 확장에 설명된 대로 스토리지 용량을 확장해야 합니다.
10장. Multicloud Object Gateway
10.1. Multicloud Object Gateway 정보
MCG(Multicloud Object Gateway)는 OpenShift를 위한 경량 오브젝트 스토리지 서비스로, 사용자가 작게 시작한 다음 필요에 따라 온프레미스, 여러 클러스터 및 클라우드 네이티브 스토리지로 확장할 수 있습니다.
10.2. 애플리케이션을 사용하여 Multicloud Object Gateway에 액세스
AWS S3를 대상으로 하는 모든 애플리케이션 또는 AWS S3 SDK(Software Development Kit)를 사용하는 코드로 오브젝트 서비스에 액세스할 수 있습니다. 애플리케이션은 MCG(Multicloud Object Gateway) 끝점, 액세스 키 및 시크릿 액세스 키를 지정해야 합니다. 터미널 또는 MCG CLI를 사용하여 이 정보를 검색할 수 있습니다.
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
보다 쉽게 관리할 수 있도록 MCG 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다.
- IBM Power의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- IBM Z 인프라의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 Download RedHat OpenShift Data Foundation 페이지 ()에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
다음 두 가지 방법으로 관련 끝점, 액세스 키 및 시크릿 액세스 키에 액세스할 수 있습니다.
예 10.1. 예제
- 가상 호스트 스타일을 사용하여 MCG 버킷에 액세스
- 클라이언트 애플리케이션이 https://<bucket-name>.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com에 액세스하려고 하면
<bucket-name>MCG 버킷의 이름입니다.
예: https://mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
S3 서비스를 가리키도록
mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com에 DNS 항목이 필요합니다.
가상 호스트 스타일을 사용하여 클라이언트 애플리케이션을 MCG 버킷을 가리키도록 DNS 항목이 있는지 확인합니다.
10.2.1. 터미널에서 Multicloud Object Gateway에 액세스
절차
describe 명령을 실행하여 액세스 키(AWS_ACCESS_KEY_ID 값) 및 시크릿 액세스 키(AWS_SECRET_ACCESS_KEY 값)를 포함하여 MCG(Multicloud Object Gateway) 엔드포인트에 대한 정보를 봅니다.
# oc describe noobaa -n openshift-storage
출력은 다음과 유사합니다.
Name: noobaa
Namespace: openshift-storage
Labels: <none>
Annotations: <none>
API Version: noobaa.io/v1alpha1
Kind: NooBaa
Metadata:
Creation Timestamp: 2019-07-29T16:22:06Z
Generation: 1
Resource Version: 6718822
Self Link: /apis/noobaa.io/v1alpha1/namespaces/openshift-storage/noobaas/noobaa
UID: 019cfb4a-b21d-11e9-9a02-06c8de012f9e
Spec:
Status:
Accounts:
Admin:
Secret Ref:
Name: noobaa-admin
Namespace: openshift-storage
Actual Image: noobaa/noobaa-core:4.0
Observed Generation: 1
Phase: Ready
Readme:
Welcome to NooBaa!
-----------------
Welcome to NooBaa!
-----------------
NooBaa Core Version:
NooBaa Operator Version:
Lets get started:
1. Connect to Management console:
Read your mgmt console login information (email & password) from secret: "noobaa-admin".
kubectl get secret noobaa-admin -n openshift-storage -o json | jq '.data|map_values(@base64d)'
Open the management console service - take External IP/DNS or Node Port or use port forwarding:
kubectl port-forward -n openshift-storage service/noobaa-mgmt 11443:443 &
open https://localhost:11443
2. Test S3 client:
kubectl port-forward -n openshift-storage service/s3 10443:443 &
1
NOOBAA_ACCESS_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
2
NOOBAA_SECRET_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
alias s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY aws --endpoint https://localhost:10443 --no-verify-ssl s3'
s3 ls
Services:
Service Mgmt:
External DNS:
https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443
Internal DNS:
https://noobaa-mgmt.openshift-storage.svc:443
Internal IP:
https://172.30.235.12:443
Node Ports:
https://10.0.142.103:31385
Pod Ports:
https://10.131.0.19:8443
serviceS3:
External DNS: 3
https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443
Internal DNS:
https://s3.openshift-storage.svc:443
Internal IP:
https://172.30.86.41:443
Node Ports:
https://10.0.142.103:31011
Pod Ports:
https://10.131.0.19:644310.2.2. MCG 명령줄 인터페이스에서 Multicloud Object Gateway에 액세스
사전 요구 사항
MCG 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다.
- IBM Power의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- IBM Z 인프라의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
절차
status 명령을 실행하여 endpoint, access key, secret access 키에 액세스합니다.
noobaa status -n openshift-storage
출력은 다음과 유사합니다.
INFO[0000] Namespace: openshift-storage INFO[0000] INFO[0000] CRD Status: INFO[0003] ✅ Exists: CustomResourceDefinition "noobaas.noobaa.io" INFO[0003] ✅ Exists: CustomResourceDefinition "backingstores.noobaa.io" INFO[0003] ✅ Exists: CustomResourceDefinition "bucketclasses.noobaa.io" INFO[0004] ✅ Exists: CustomResourceDefinition "objectbucketclaims.objectbucket.io" INFO[0004] ✅ Exists: CustomResourceDefinition "objectbuckets.objectbucket.io" INFO[0004] INFO[0004] Operator Status: INFO[0004] ✅ Exists: Namespace "openshift-storage" INFO[0004] ✅ Exists: ServiceAccount "noobaa" INFO[0005] ✅ Exists: Role "ocs-operator.v0.0.271-6g45f" INFO[0005] ✅ Exists: RoleBinding "ocs-operator.v0.0.271-6g45f-noobaa-f9vpj" INFO[0006] ✅ Exists: ClusterRole "ocs-operator.v0.0.271-fjhgh" INFO[0006] ✅ Exists: ClusterRoleBinding "ocs-operator.v0.0.271-fjhgh-noobaa-pdxn5" INFO[0006] ✅ Exists: Deployment "noobaa-operator" INFO[0006] INFO[0006] System Status: INFO[0007] ✅ Exists: NooBaa "noobaa" INFO[0007] ✅ Exists: StatefulSet "noobaa-core" INFO[0007] ✅ Exists: Service "noobaa-mgmt" INFO[0008] ✅ Exists: Service "s3" INFO[0008] ✅ Exists: Secret "noobaa-server" INFO[0008] ✅ Exists: Secret "noobaa-operator" INFO[0008] ✅ Exists: Secret "noobaa-admin" INFO[0009] ✅ Exists: StorageClass "openshift-storage.noobaa.io" INFO[0009] ✅ Exists: BucketClass "noobaa-default-bucket-class" INFO[0009] ✅ (Optional) Exists: BackingStore "noobaa-default-backing-store" INFO[0010] ✅ (Optional) Exists: CredentialsRequest "noobaa-cloud-creds" INFO[0010] ✅ (Optional) Exists: PrometheusRule "noobaa-prometheus-rules" INFO[0010] ✅ (Optional) Exists: ServiceMonitor "noobaa-service-monitor" INFO[0011] ✅ (Optional) Exists: Route "noobaa-mgmt" INFO[0011] ✅ (Optional) Exists: Route "s3" INFO[0011] ✅ Exists: PersistentVolumeClaim "db-noobaa-core-0" INFO[0011] ✅ System Phase is "Ready" INFO[0011] ✅ Exists: "noobaa-admin" #------------------# #- Mgmt Addresses -# #------------------# ExternalDNS : [https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443] ExternalIP : [] NodePorts : [https://10.0.142.103:31385] InternalDNS : [https://noobaa-mgmt.openshift-storage.svc:443] InternalIP : [https://172.30.235.12:443] PodPorts : [https://10.131.0.19:8443] #--------------------# #- Mgmt Credentials -# #--------------------# email : admin@noobaa.io password : HKLbH1rSuVU0I/souIkSiA== #----------------# #- S3 Addresses -# #----------------# 1 ExternalDNS : [https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443] ExternalIP : [] NodePorts : [https://10.0.142.103:31011] InternalDNS : [https://s3.openshift-storage.svc:443] InternalIP : [https://172.30.86.41:443] PodPorts : [https://10.131.0.19:6443] #------------------# #- S3 Credentials -# #------------------# 2 AWS_ACCESS_KEY_ID : jVmAsu9FsvRHYmfjTiHV 3 AWS_SECRET_ACCESS_KEY : E//420VNedJfATvVSmDz6FMtsSAzuBv6z180PT5c #------------------# #- Backing Stores -# #------------------# NAME TYPE TARGET-BUCKET PHASE AGE noobaa-default-backing-store aws-s3 noobaa-backing-store-15dc896d-7fe0-4bed-9349-5942211b93c9 Ready 141h35m32s #------------------# #- Bucket Classes -# #------------------# NAME PLACEMENT PHASE AGE noobaa-default-bucket-class {Tiers:[{Placement: BackingStores:[noobaa-default-backing-store]}]} Ready 141h35m33s #-----------------# #- Bucket Claims -# #-----------------# No OBC's found.
이제 애플리케이션에 연결하기 위해 관련 끝점, 키, 시크릿 액세스 키가 있습니다.
예 10.2. 예제
AWS S3 CLI가 애플리케이션이면 다음 명령에서 OpenShift Data Foundation의 버킷을 나열합니다.
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID> AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY> aws --endpoint <ENDPOINT> --no-verify-ssl s3 ls
10.3. Multicloud Object Gateway 콘솔에 사용자 액세스 허용
MCG(Multicloud Object Gateway) 콘솔에 대한 액세스를 사용자에게 허용하려면 사용자가 다음 조건을 충족해야 합니다.
- user는 cluster-admins 그룹에 있습니다.
- 사용자는 system:cluster-admins 가상 그룹에 있습니다.
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
절차
MCG 콘솔에 대한 액세스를 활성화합니다.
클러스터에서 다음 단계를 한 번 수행합니다.
cluster-admins그룹을 만듭니다.# oc adm groups new cluster-admins
그룹을
cluster-admin역할에 바인딩합니다.# oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
cluster-admins그룹에서 사용자를 추가하거나 제거하여 MCG 콘솔에 대한 액세스를 제어합니다.cluster-admins그룹에 사용자 세트를 추가하려면 다음을 수행합니다.# oc adm groups add-users cluster-admins <user-name> <user-name> <user-name>...
여기서
<user-name>은 추가할 사용자의 이름입니다.참고cluster-admins그룹에 사용자 집합을 추가하는 경우 OpenShift Data Foundation 대시보드에 대한 액세스를 허용하기 위해 새로 추가된 사용자를 cluster-admin 역할에 바인딩할 필요가 없습니다.cluster-admins그룹에서 사용자 집합을 제거하려면 다음을 수행합니다.# oc adm groups remove-users cluster-admins <user-name> <user-name> <user-name>...
여기서
<user-name>은 제거할 사용자의 이름입니다.
검증 단계
- OpenShift 웹 콘솔에서 Multicloud Object Gateway Console에 대한 액세스 권한이 있는 사용자로 로그인합니다.
- 스토리지 → OpenShift Data Foundation 으로 이동합니다.
- Storage Systems 탭에서 스토리지 시스템을 선택한 다음 개요 → 오브젝트 탭을 클릭합니다.
- Multicloud Object Gateway 링크를 선택합니다.
- Allow selected permissions 를 클릭합니다.
10.4. 하이브리드 또는 멀티클라우드용 스토리지 리소스 추가
10.4.1. 새 백업 저장소 생성
OpenShift Data Foundation에서 새 백업 저장소를 생성하려면 다음 절차를 사용하십시오.
사전 요구 사항
- OpenShift Data Foundation에 대한 관리자 액세스 권한
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 백업 저장소 탭을 클릭합니다.
- 백업 저장소 생성 을 클릭합니다.
새 백업 저장소 생성 페이지에서 다음을 수행합니다.
- 백업 저장소 이름을 입력합니다.
- 공급자를 선택합니다.
- Region 을 선택합니다.
- 끝점을 입력합니다. 이는 선택 사항입니다.
드롭다운 목록에서 보안을 선택하거나 고유 보안을 생성합니다. 필요한 경우 필요한 시크릿 을 채울 수 있는 자격 증명 보기로 전환 할 수 있습니다.
OCP 시크릿 생성에 대한 자세한 내용은 Openshift Container Platform 설명서 의 보안 생성 섹션을 참조하십시오.
각 보조 저장소는 다른 시크릿이 필요합니다. 특정 백업 저장소에 대한 시크릿을 생성하는 방법에 대한 자세한 내용은 10.4.2절. “MCG 명령줄 인터페이스를 사용하여 하이브리드 또는 멀티클라우드용 스토리지 리소스 추가” 을 참조하고 YAML을 사용하여 스토리지 리소스를 추가하는 절차를 따르십시오.
참고이 메뉴는 Google Cloud 및 로컬 PVC를 제외한 모든 공급자와 관련이 있습니다.
- 대상 버킷 을 입력합니다. 대상 버킷은 원격 클라우드 서비스에서 호스팅되는 컨테이너 스토리지입니다. MCG에 시스템에 이 버킷을 사용할 수 있음을 알리는 연결을 만들 수 있습니다.
- 백업 저장소 생성 을 클릭합니다.
검증 단계
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 백업 저장소 탭을 클릭하여 모든 백업 저장소를 확인합니다.
10.4.2. MCG 명령줄 인터페이스를 사용하여 하이브리드 또는 멀티클라우드용 스토리지 리소스 추가
MCG(Multicloud Object Gateway)는 클라우드 공급자 및 클러스터에 걸쳐 있는 데이터 프로세스를 간소화합니다.
MCG에서 사용할 수 있는 백업 스토리지를 추가해야 합니다.
배포 유형에 따라 다음 절차 중 하나를 선택하여 백업 스토리지를 생성할 수 있습니다.
- AWS 지원 백업 저장소 생성은 참조하십시오. 10.4.2.1절. “AWS 지원 백업 저장소 생성”
- IBM COS 지원 백업 저장소 생성은 참조하십시오. 10.4.2.2절. “IBM COS 지원 백업 저장소 생성”
- Azure 지원 백업 저장소 생성은 참조하십시오. 10.4.2.3절. “Azure 지원 백업 저장소 생성”
- GCP 지원 백업 저장소 생성은 참조하십시오. 10.4.2.4절. “GCP 지원 백업 저장소 생성”
- 로컬 영구 볼륨 지원 보조 보조 저장소 생성은 참조하십시오. 10.4.2.5절. “로컬 영구 볼륨 지원 보조 보조 저장소 생성”
VMware 배포의 경우 자세한 내용은 10.4.3절. “s3 호환 Multicloud Object Gateway 백업 저장소 생성” 로 건너뛰십시오.
10.4.2.1. AWS 지원 백업 저장소 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa backingstore create aws-s3 <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
-
<backingstore_name>을 backingstore의 이름으로 바꿉니다. -
<AWS ACCESS KEY>및<AWS SECRET ACCESS KEY>를 이를 위해 생성한 AWS 액세스 키 ID 및 시크릿 액세스 키로 바꿉니다. <bucket-name>을 기존 AWS 버킷 이름으로 교체합니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.출력은 다음과 유사합니다.
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "aws-resource" INFO[0002] ✅ Created: Secret "backing-store-secret-aws-resource"
YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.
인증 정보를 사용하여 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <backingstore-secret-name> namespace: openshift-storage type: Opaque data: AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64> AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
-
Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고
<AWS ACCESS KEY ID ENCODED IN BASE64>및<AWS SECRET ACCESS KEY ENCODED IN BASE64>BASE64>의 결과를 사용해야 합니다. -
<backingstore-secret-name>을 고유한 이름으로 교체합니다.
-
Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고
특정 백업 저장소에 대해 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: bs namespace: openshift-storage spec: awsS3: secret: name: <backingstore-secret-name> namespace: openshift-storage targetBucket: <bucket-name> type: aws-s3-
<bucket-name>을 기존 AWS 버킷 이름으로 교체합니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다. -
<backingstore-secret-name>을 이전 단계에서 생성한 보안 이름으로 교체합니다.
-
10.4.2.2. IBM COS 지원 백업 저장소 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. 예를 들면 다음과 같습니다.
- IBM Power의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- IBM Z 인프라의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa backingstore create ibm-cos <backingstore_name> --access-key=<IBM ACCESS KEY> --secret-key=<IBM SECRET ACCESS KEY> --endpoint=<IBM COS ENDPOINT> --target-bucket <bucket-name> -n openshift-storage
-
<backingstore_name>을 backingstore의 이름으로 바꿉니다. <IBM ACCESS KEY>,<IBM SECRET ACCESS KEY>,<IBM COS ENDPOINT>를 IBM 액세스 키 ID, 시크릿 액세스 키 및 기존 IBM 버킷의 위치에 해당하는 적절한 지역 끝점으로 바꿉니다.IBM 클라우드에서 위의 키를 생성하려면 대상 버킷에 대한 서비스 자격 증명을 생성하는 동안 vGPU 자격 증명을 포함해야 합니다.
<bucket-name>을 기존 IBM 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.출력은 다음과 유사합니다.
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "ibm-resource" INFO[0002] ✅ Created: Secret "backing-store-secret-ibm-resource"
-
YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.
인증 정보를 사용하여 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <backingstore-secret-name> namespace: openshift-storage type: Opaque data: IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64> IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
-
Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 시크릿 액세스 키를 입력하고 인코딩해야 합니다.
<IBM COS ACCESS KEY ID ENCODED IN BASE64>및<IBM COS ACCESS KEY ENCODED IN BASE64>ACCESS KEY -
<backingstore-secret-name>을 고유한 이름으로 교체합니다.
-
Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 시크릿 액세스 키를 입력하고 인코딩해야 합니다.
특정 백업 저장소에 대해 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: bs namespace: openshift-storage spec: ibmCos: endpoint: <endpoint> secret: name: <backingstore-secret-name> namespace: openshift-storage targetBucket: <bucket-name> type: ibm-cos-
<bucket-name>을 기존 IBM COS 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다. -
<endpoint>를 기존 IBM 버킷 이름의 위치에 해당하는 리전 끝점으로 바꿉니다. 이 인수는 Multicloud Object Gateway에 백업 저장소에 사용할 끝점을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 끝점을 지시합니다. -
<backingstore-secret-name>을 이전 단계에서 생성한 보안 이름으로 교체합니다.
-
10.4.2.3. Azure 지원 백업 저장소 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name>
-
<backingstore_name>을 backingstore의 이름으로 바꿉니다. -
<AZURE ACCOUNT KEY>및<AZURE ACCOUNT NAME>을 이 목적을 위해 생성한 AZURE 계정 키 및 계정 이름으로 바꿉니다. <blob 컨테이너 이름>을 기존 Azure Blob 컨테이너 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.출력은 다음과 유사합니다.
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "azure-resource" INFO[0002] ✅ Created: Secret "backing-store-secret-azure-resource"
-
YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.
인증 정보를 사용하여 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <backingstore-secret-name> type: Opaque data: AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64> AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>
-
Base64를 사용하여 자체 Azure 계정 이름과 계정 키를 입력하고 인코딩해야 하며
<AZURE ACCOUNT NAME ENCODED IN BASE64>및<AZURE ACCOUNT KEY ENCODED IN BASE64>대신 해당 결과를 사용해야 합니다. -
<backingstore-secret-name>을 고유한 이름으로 교체합니다.
-
Base64를 사용하여 자체 Azure 계정 이름과 계정 키를 입력하고 인코딩해야 하며
특정 백업 저장소에 대해 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: bs namespace: openshift-storage spec: azureBlob: secret: name: <backingstore-secret-name> namespace: openshift-storage targetBlobContainer: <blob-container-name> type: azure-blob-
<blob-container-name>을 기존 Azure Blob 컨테이너 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다. -
<backingstore-secret-name>을 이전 단계에서 생성한 보안 이름으로 교체합니다.
-
10.4.2.4. GCP 지원 백업 저장소 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa backingstore create google-cloud-storage <backingstore_name> --private-key-json-file=<PATH TO GCP PRIVATE KEY JSON FILE> --target-bucket <GCP bucket name>
-
<backingstore_name>을 backingstore의 이름으로 바꿉니다. -
<PATH GCP PRIVATE KEY JSON FILE>을 이를 위해 생성된 GCP 개인 키 경로로 바꿉니다. <GCP 버킷 이름>을 기존 GCP 오브젝트 스토리지 버킷 이름으로 교체합니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.출력은 다음과 유사합니다.
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "google-gcp" INFO[0002] ✅ Created: Secret "backing-store-google-cloud-storage-gcp"
-
YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.
인증 정보를 사용하여 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <backingstore-secret-name> type: Opaque data: GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>
-
Base64를 사용하여 자체 GCP 서비스 계정 개인 키를 공급 및 인코딩하고
<GCP PRIVATE KEY ENCODED IN BASE64>대신 결과를 사용해야 합니다. -
<backingstore-secret-name>을 고유한 이름으로 교체합니다.
-
Base64를 사용하여 자체 GCP 서비스 계정 개인 키를 공급 및 인코딩하고
특정 백업 저장소에 대해 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: bs namespace: openshift-storage spec: googleCloudStorage: secret: name: <backingstore-secret-name> namespace: openshift-storage targetBucket: <target bucket> type: google-cloud-storage-
<target bucket>을 기존 Google 스토리지 버킷으로 교체합니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다. -
<backingstore-secret-name>을 이전 단계에서 생성한 보안 이름으로 교체합니다.
-
10.4.2.5. 로컬 영구 볼륨 지원 보조 보조 저장소 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa backingstore create pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES> --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS>
-
<backingstore_name>을 backingstore의 이름으로 바꿉니다. -
<NUMBER OF VOLUMES>를 생성하려는 볼륨 수로 바꿉니다. 볼륨 수를 늘리면 스토리지가 확장됩니다. -
<VOLUME SIZE>를 각 볼륨의 필수 크기(GB)로 바꿉니다. <LOCAL STORAGE CLASS>를 로컬 스토리지 클래스로 바꾸고ocs-storagecluster-ceph-rbd를 사용하는 것이 좋습니다.출력은 다음과 유사합니다.
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"
-
YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.
특정 백업 저장소에 대해 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: <backingstore_name> namespace: openshift-storage spec: pvPool: numVolumes: <NUMBER OF VOLUMES> resources: requests: storage: <VOLUME SIZE> storageClass: <LOCAL STORAGE CLASS> type: pv-pool-
<backingstore_name>을 backingstore의 이름으로 바꿉니다. -
<NUMBER OF VOLUMES>를 생성하려는 볼륨 수로 바꿉니다. 볼륨 수를 늘리면 스토리지가 확장됩니다. -
<VOLUME SIZE>를 각 볼륨의 필수 크기(GB)로 바꿉니다. G 문자는 그대로 있어야 합니다. -
<LOCAL STORAGE CLASS>를 로컬 스토리지 클래스로 바꾸고ocs-storagecluster-ceph-rbd를 사용하는 것이 좋습니다.
-
10.4.3. s3 호환 Multicloud Object Gateway 백업 저장소 생성
MCG(Multicloud Object Gateway)는 모든 S3 호환 오브젝트 스토리지를 백업 저장소(예: Red Hat Ceph Storage의 RADOS Object Gateway)로 사용할 수 있습니다. 다음 절차에서는 Red Hat Ceph Storage의 RGW를 위한 S3 호환 MCG 백업 저장소를 생성하는 방법을 보여줍니다. RGW가 배포되면 OpenShift Data Foundation Operator는 MCG에 대한 S3 호환 백업 저장소를 자동으로 생성합니다.
절차
MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>
<RGW ACCESS KEY>및<RGW SECRET KEY>를 가져오려면 RGW 사용자 시크릿 이름을 사용하여 다음 명령을 실행합니다.oc get secret <RGW USER SECRET NAME> -o yaml -n openshift-storage
- Base64에서 액세스 키 ID와 액세스 키를 디코딩하고 유지합니다.
-
<RGW USER ACCESS KEY>및<RGW USER ACCESS KEY>를 이전 단계에서 디코딩한 적절한 데이터로 바꿉니다. -
<bucket-name>을 기존 RGW 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다. <RGW 끝점>을 가져오려면 RADOS 오브젝트 게이트웨이 S3 끝점 액세스를 참조하십시오.출력은 다음과 유사합니다.
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "rgw-resource" INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"
YAML을 사용하여 백업 저장소를 생성할 수도 있습니다.
CephObjectStore사용자를 생성합니다. 또한 RGW 인증 정보가 포함된 시크릿을 생성합니다.apiVersion: ceph.rook.io/v1 kind: CephObjectStoreUser metadata: name: <RGW-Username> namespace: openshift-storage spec: store: ocs-storagecluster-cephobjectstore displayName: "<Display-name>"
-
<RGW-Username>및<Display-name>을 고유한 사용자 이름 및 표시 이름으로 바꿉니다.
-
S3-호환 백업 저장소에 대해 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: <backingstore-name> namespace: openshift-storage spec: s3Compatible: endpoint: <RGW endpoint> secret: name: <backingstore-secret-name> namespace: openshift-storage signatureVersion: v4 targetBucket: <RGW-bucket-name> type: s3-compatible-
<backingstore-secret-name>을 이전 단계에서CephObjectStore로 생성한 보안 이름으로 교체합니다. -
<bucket-name>을 기존 RGW 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다. -
<RGW 끝점>을 가져오려면 RADOS 오브젝트 게이트웨이 S3 끝점 액세스를 참조하십시오.
-
10.4.4. 사용자 인터페이스를 사용하여 하이브리드 및 멀티클라우드용 스토리지 리소스 추가
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- Storage Systems 탭에서 스토리지 시스템을 선택한 다음 개요 → 오브젝트 탭을 클릭합니다.
- Multicloud Object Gateway 링크를 선택합니다.
아래에서 강조 표시된 왼쪽의 리소스 탭을 선택합니다. 채워지는 목록에서 클라우드 리소스 추가 를 선택합니다.

새 연결 추가를 선택합니다.

관련 네이티브 클라우드 공급자 또는 S3 호환 옵션을 선택하고 세부 정보를 입력합니다.

새로 생성된 연결을 선택하고 기존 버킷에 매핑합니다.

- 필요에 따라 백업 저장소를 만들려면 이 단계를 반복합니다.
NooBaa UI에서 생성된 리소스는 OpenShift UI 또는 MCG CLI에서 사용할 수 없습니다.
10.4.5. 새 버킷 클래스 생성
버킷 클래스는 OBC(오브젝트 버킷 클래스)에 대한 계층화 정책 및 데이터 배치를 정의하는 버킷 클래스를 나타내는 CRD입니다.
OpenShift Data Foundation에서 버킷 클래스를 생성하려면 이 절차를 사용하십시오.
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 버킷 클래스 탭을 클릭합니다.
- Create Bucket Class 를 클릭합니다.
Create new Bucket Class 페이지에서 다음을 수행합니다.
버킷 클래스 유형을 선택하고 버킷 클래스 이름을 입력합니다.
BucketClass 유형을 선택합니다. 다음 옵션 중 하나를 선택합니다.
- 표준: MCG(Multicloud Object Gateway)에서 데이터를 소비하고, 축소, 압축 및 암호화됩니다.
네임스페이스: 데이터는 중복 제거, 압축 또는 암호화를 수행하지 않고 네임 스페이스 저장소에 저장됩니다.
기본적으로 Standard는 선택되어 있습니다.By default, Standard is selected.
- 버킷 클래스 이름을 입력합니다.
- 다음을 클릭합니다.
배치 정책에서 계층 1 - 정책 유형을 선택하고 다음을 클릭합니다. 요구 사항에 따라 옵션 중 하나를 선택할 수 있습니다.
- 스프레드 를 사용하면 선택한 리소스에 걸쳐 데이터를 분산할 수 있습니다.
- mirror 를 사용하면 선택한 리소스에서 데이터를 완전히 복제할 수 있습니다.
- Add Tier 를 클릭하여 다른 정책 계층을 추가합니다.
Tier 1 - Policy Type 을 Spread 로 선택한 경우 사용 가능한 목록에서 백업 저장소 리소스를 하나 이상 선택하고 다음을 클릭합니다. 또는 새 백업 저장소를 만들 수도 있습니다.
참고이전 단계에서 미러링으로 정책 유형을 선택할 때 최소한 2개의 백업 저장소를 선택해야 합니다.
- 버킷 클래스 설정을 검토하고 확인합니다.
- Create Bucket Class 를 클릭합니다.
검증 단계
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 버킷 클래스 탭을 클릭하고 새 버킷 클래스를 검색합니다.
10.4.6. 버킷 클래스 편집
Openshift 웹 콘솔에서 편집 버튼을 클릭하여 YAML 파일을 통해 버킷 클래스 구성 요소를 편집하려면 다음 절차를 사용하십시오.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스.
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 버킷 클래스 탭을 클릭합니다.
- 편집하려는 Bucket 클래스 옆에 있는 Action Menu (및 작업 메뉴) 를 클릭합니다.
- Edit Bucket Class 를 클릭합니다.
- YAML 파일로 리디렉션되어 이 파일에서 필요한 변경을 수행하고 저장을 클릭합니다.
10.4.7. 버킷 클래스의 백업 저장소 편집
다음 절차에 따라 기존 MCG(Multicloud Object Gateway) 버킷 클래스를 편집하여 버킷 클래스에 사용되는 기본 백업 저장소를 변경합니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스.
- 버킷 클래스입니다.
- 백업 저장소.
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 버킷 클래스 탭을 클릭합니다.
편집하려는 Bucket 클래스 옆에 있는 Action Menu (및 작업 메뉴) 를 클릭합니다.

- Edit Bucket Class Resources 를 클릭합니다.
Edit Bucket Class Resources 페이지에서 버킷 클래스에 백업 저장소를 추가하거나 버킷 클래스에서 백업 저장소를 제거하여 버킷 클래스 리소스를 편집합니다. 하나 또는 두 개의 계층과 다른 배치 정책으로 생성된 버킷 클래스 리소스를 편집할 수도 있습니다.
- 버킷 클래스에 백업 저장소를 추가하려면 백업 저장소의 이름을 선택합니다.
버킷 클래스에서 백업 저장소를 제거하려면 백업 저장소의 이름을 지웁니다.

- 저장을 클릭합니다.
10.5. 네임스페이스 버킷 관리
네임스페이스 버킷을 사용하면 다른 공급자의 데이터 리포지토리를 함께 연결할 수 있으므로 단일 통합 보기를 통해 모든 데이터와 상호 작용할 수 있습니다. 각 공급자와 연결된 오브젝트 버킷을 네임스페이스 버킷에 추가하고 네임스페이스 버킷을 통해 데이터에 액세스하여 모든 오브젝트 버킷을 한 번에 확인합니다. 이를 통해 다른 여러 스토리지 공급자에서 읽는 동안 기본 스토리지 공급자에게 작성할 수 있으므로 새 스토리지 공급자로 마이그레이션하는 비용을 크게 줄일 수 있습니다.
S3 API를 사용하여 네임스페이스 버킷의 오브젝트와 상호 작용할 수 있습니다. 자세한 내용은 네임스페이스 버킷의 오브젝트 S3 API 끝점 을 참조하십시오.
네임스페이스 버킷은 쓰기 대상을 사용할 수 있고 작동하는 경우에만 사용할 수 있습니다.
10.5.1. 네임 스페이스 버킷의 오브젝트에 대한 Amazon S3 API 끝점
Amazon Simple Storage Service(S3) API를 사용하여 네임스페이스 버킷의 오브젝트와 상호 작용할 수 있습니다.
Red Hat OpenShift Data Foundation 4.6 이후에는 다음과 같은 네임 스페이스 버킷 작업을 지원합니다.
이러한 작업 및 사용 방법에 대한 최신 정보는 Amazon S3 API 참조 문서를 참조하십시오.
10.5.2. Multicloud Object Gateway CLI 및 YAML을 사용하여 네임스페이스 버킷 추가
네임스페이스 버킷에 대한 자세한 내용은 네임스페이스 버킷 관리를 참조하십시오.
배포 유형 및 YAML 또는 Multicloud Object Gateway CLI를 사용할지 여부에 따라 다음 절차 중 하나를 선택하여 네임스페이스 버킷을 추가합니다.
10.5.2.1. YAML을 사용하여 AWS S3 네임스페이스 버킷 추가
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform
- MCG(Multicloud Object Gateway)에 대한 액세스 권한은 2장 2장, 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
절차
인증 정보를 사용하여 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <namespacestore-secret-name> type: Opaque data: AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64> AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
-
Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고
<AWS ACCESS KEY ID ENCODED IN BASE64>및<AWS SECRET ACCESS KEY ENCODED IN BASE64>BASE64>의 결과를 사용해야 합니다. -
<namespacestore-secret-name>을 고유한 이름으로 교체합니다.
-
Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고
OpenShift CRD(Custom Resource Definitions)를 사용하여 NamespaceStore 리소스를 생성합니다. NamespaceStore는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. NamespaceStore 리소스를 생성하려면 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: NamespaceStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: <resource-name> namespace: openshift-storage spec: awsS3: secret: name: <namespacestore-secret-name> namespace: <namespace-secret> targetBucket: <target-bucket> type: aws-s3-
<resource-name>을 리소스에 지정할 이름으로 교체합니다. -
<namespacestore-secret-name>을 1단계에서 생성된 보안으로 교체합니다. -
<namespace-secret>을 보안을 찾을 수 있는 네임스페이스로 바꿉니다. -
<target-bucket>을 NamespaceStore에 대해 생성한 대상 버킷으로 바꿉니다.
-
네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는
단일또는다중유형의 유형이 필요합니다.유형
단일의 네임스페이스 정책에는 다음 구성이 필요합니다.apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <my-bucket-class> namespace: openshift-storage spec: namespacePolicy: type: single: resource: <resource>-
<my-bucket-class>를 고유한 네임스페이스 버킷 클래스 이름으로 교체합니다. -
<resource>를 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 네임스페이스 저장소의 이름으로 바꿉니다.
-
유형
multi의 네임스페이스 정책에는 다음 구성이 필요합니다.apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <my-bucket-class> namespace: openshift-storage spec: namespacePolicy: type: Multi multi: writeResource: <write-resource> readResources: - <read-resources> - <read-resources>-
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<write-resource>를 네임스페이스 버킷의 쓰기 대상을 정의하는 단일 네임스페이스 저장소의 이름으로 교체합니다. -
<read-resources>를 네임스페이스 버킷의 읽기 대상을 정의하는 namespace-stores 이름 목록으로 바꿉니다.
-
2단계에서 정의된 버킷 클래스를 사용하는 OBC(Object Bucket Class) 리소스를 사용하여 버킷을 생성하려면 다음 YAML을 적용합니다.
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <resource-name> namespace: openshift-storage spec: generateBucketName: <my-bucket> storageClassName: openshift-storage.noobaa.io additionalConfig: bucketclass: <my-bucket-class>-
<resource-name>을 리소스에 지정할 이름으로 교체합니다. -
<my-bucket>을 버킷에 부여하려는 이름으로 교체합니다. -
<my-bucket-class>를 이전 단계에서 만든 버킷 클래스로 바꿉니다.
-
Operator가 OBC를 프로비저닝하면 MCG에 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 Secret 및 ConfigMap을 생성합니다.
10.5.2.2. YAML을 사용하여 IBM COS 네임스페이스 버킷 추가
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
- MCG(Multicloud Object Gateway)에 대한 액세스 권한은 2장 2장, 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
절차
인증 정보를 사용하여 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <namespacestore-secret-name> type: Opaque data: IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64> IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
-
Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 시크릿 액세스 키를 입력하고 인코딩해야 합니다.
<IBM COS ACCESS KEY ID ENCODED IN BASE64>및<IBM COS ACCESS KEY ENCODED IN BASE64>ACCESS KEY -
<namespacestore-secret-name>을 고유한 이름으로 교체합니다.
-
Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 시크릿 액세스 키를 입력하고 인코딩해야 합니다.
OpenShift CRD(Custom Resource Definitions)를 사용하여 NamespaceStore 리소스를 생성합니다. NamespaceStore는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. NamespaceStore 리소스를 생성하려면 다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: NamespaceStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: bs namespace: openshift-storage spec: s3Compatible: endpoint: <IBM COS ENDPOINT> secret: name: <namespacestore-secret-name> namespace: <namespace-secret> signatureVersion: v2 targetBucket: <target-bucket> type: ibm-cos-
<IBM COS ENDPOINT>를 적절한 IBM COS 엔드포인트로 바꿉니다. -
<namespacestore-secret-name>을 1단계에서 생성된 보안으로 교체합니다. -
<namespace-secret>을 보안을 찾을 수 있는 네임스페이스로 바꿉니다. -
<target-bucket>을 NamespaceStore에 대해 생성한 대상 버킷으로 바꿉니다.
-
네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는
단일또는다중유형의 유형이 필요합니다.유형
단일의 네임스페이스 정책에는 다음 구성이 필요합니다.apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <my-bucket-class> namespace: openshift-storage spec: namespacePolicy: type: single: resource: <resource>-
<my-bucket-class>를 고유한 네임스페이스 버킷 클래스 이름으로 교체합니다. -
<resource>를 네임스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 네임스페이스 저장소의 이름으로 바꿉니다.
-
유형
multi의 네임스페이스 정책에는 다음 구성이 필요합니다.apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <my-bucket-class> namespace: openshift-storage spec: namespacePolicy: type: Multi multi: writeResource: <write-resource> readResources: - <read-resources> - <read-resources>-
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<write-resource>를 네임스페이스 버킷의 쓰기 대상을 정의하는 단일 네임스페이스 저장소의 이름으로 교체합니다. -
<read-resources>를 네임스페이스 버킷의 읽기 대상을 정의하는 네임스페이스 저장소 이름 목록으로 바꿉니다.
-
2단계에서 정의된 버킷 클래스를 사용하는 OBC(Object Bucket Class) 리소스를 사용하여 버킷을 생성하려면 다음 YAML을 적용합니다.
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <resource-name> namespace: openshift-storage spec: generateBucketName: <my-bucket> storageClassName: openshift-storage.noobaa.io additionalConfig: bucketclass: <my-bucket-class>-
<resource-name>을 리소스에 지정할 이름으로 교체합니다. -
<my-bucket>을 버킷에 부여하려는 이름으로 교체합니다. -
<my-bucket-class>를 이전 단계에서 만든 버킷 클래스로 바꿉니다.
-
Operator가 OBC를 프로비저닝하면 MCG에 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 Secret 및 ConfigMap을 생성합니다.
10.5.2.3. Multicloud Object Gateway CLI를 사용하여 AWS S3 네임스페이스 버킷 추가
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
- MCG(Multicloud Object Gateway)에 대한 액세스 권한은 2장 2장, 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
- MCG 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
NamespaceStore 리소스를 생성합니다. NamespaceStore는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
-
<namespacestore>를 NamespaceStore의 이름으로 바꿉니다. -
<AWS ACCESS KEY>및<AWS SECRET ACCESS KEY>를 이를 위해 생성한 AWS 액세스 키 ID 및 시크릿 액세스 키로 바꿉니다. -
<bucket-name>을 기존 AWS 버킷 이름으로 교체합니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.
-
네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는
단일또는다중유형의 유형이 필요합니다.다음 명령을 실행하여
단일유형의 네임 스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
-
<resource-name>을 리소스를 지정할 이름으로 교체합니다. -
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<resource>를 네임스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 namespace-store로 바꿉니다.
-
다음 명령을 실행하여
multi유형의 네임 스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
-
<resource-name>을 리소스를 지정할 이름으로 교체합니다. -
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<write-resource>를 네임스페이스 버킷의 쓰기 대상을 정의하는 단일 namespace-store로 바꿉니다. -
<read-resources>를 네임스페이스 버킷의 읽기 대상을 정의하는 쉼표로 구분된 네임스페이스 저장소 목록으로 바꿉니다.
-
다음 명령을 실행하여 2단계에서 정의된 버킷 클래스를 사용하는 OBC(오브젝트 버킷 클래스) 리소스를 사용하여 버킷을 생성합니다.
noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
-
<bucket-name>을 선택한 버킷 이름으로 바꿉니다. -
<custom-bucket-class>를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.
-
Operator가 OBC를 프로비저닝하면 MCG에 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 Secret 및 ConfigMap을 생성합니다.
10.5.2.4. Multicloud Object Gateway CLI를 사용하여 IBM COS 네임스페이스 버킷 추가
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
- MCG(Multicloud Object Gateway)에 대한 액세스 권한은 2장 2장, 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.
MCG 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다.
- IBM Power의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- IBM Z 인프라의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
NamespaceStore 리소스를 생성합니다. NamespaceStore는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
-
<namespacestore>를 NamespaceStore의 이름으로 바꿉니다. -
<IBM ACCESS KEY>,<IBM SECRET ACCESS KEY>,<IBM COS ENDPOINT>를 IBM 액세스 키 ID, 시크릿 액세스 키 및 기존 IBM 버킷의 위치에 해당하는 적절한 지역 끝점으로 바꿉니다. -
<bucket-name>을 기존 IBM 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.
-
네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는
단일또는다중유형의 유형이 필요합니다.다음 명령을 실행하여
단일유형의 네임 스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
-
<resource-name>을 리소스를 지정할 이름으로 교체합니다. -
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<resource>를 네임스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 namespace-store로 바꿉니다.
-
다음 명령을 실행하여
multi유형의 네임 스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
-
<resource-name>을 리소스를 지정할 이름으로 교체합니다. -
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<write-resource>를 네임스페이스 버킷의 쓰기 대상을 정의하는 단일 namespace-store로 바꿉니다. -
<read-resources>를 네임스페이스 버킷의 읽기 대상을 정의하는 쉼표로 구분된 네임스페이스 저장소 목록으로 바꿉니다.
-
다음 명령을 실행하여 2단계에서 정의된 버킷 클래스를 사용하는 OBC(오브젝트 버킷 클래스) 리소스를 사용하여 버킷을 생성합니다.
noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
-
<bucket-name>을 선택한 버킷 이름으로 바꿉니다. -
<custom-bucket-class>를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.
-
Operator가 OBC를 프로비저닝하면 MCG에 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 Secret 및 ConfigMap을 생성합니다.
10.5.3. OpenShift Container Platform 사용자 인터페이스를 사용하여 네임스페이스 버킷 추가
OpenShift Data Foundation 4.8 릴리스를 통해 OpenShift Container Platform 사용자 인터페이스를 사용하여 네임스페이스 버킷을 추가할 수 있습니다. 네임스페이스 버킷에 대한 자세한 내용은 네임스페이스 버킷 관리를 참조하십시오.
사전 요구 사항
- OpenShift Data Foundation Operator를 사용하여 OpenShift Container Platform이 설치되어 있어야 합니다.
- MCG(Multicloud Object Gateway)에 대한 액세스.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- 스토리지 → OpenShift Data Foundation을 클릭합니다.
네임 스페이스 저장소 탭을 클릭하여
네임 스페이스 버킷에 사용할 네임 스페이스 저장소리소스를 생성합니다.- 네임스페이스 저장소 생성 을 클릭합니다.
- 네임스페이스 저장소 이름을 입력합니다.
- 공급자를 선택합니다.
- region을 선택합니다.
- 기존 시크릿을 선택하거나 Switch to credentials 를 클릭하여 보안 키 및 시크릿 액세스 키를 입력하여 시크릿을 생성합니다.
- 대상 버킷을 선택합니다.
- 생성을 클릭합니다.
- namespacestore가 Ready 상태인지 확인합니다.
- 원하는 양의 리소스가 있을 때까지 이러한 단계를 반복합니다.
버킷 클래스 탭 → 새 버킷 클래스 생성을 클릭합니다.
- Namespace (네임스페이스) 라디오 버튼을 선택합니다.
- 버킷 클래스 이름을 입력합니다.
- 설명을 추가합니다(선택 사항).
- 다음을 클릭합니다.
- 네임스페이스 버킷에 대한 네임스페이스 정책 유형을 선택한 다음 Next 를 클릭합니다.
대상 리소스를 선택합니다.
- 네임스페이스 정책 유형이 Single 이면 읽기 리소스를 선택해야 합니다.
- 네임스페이스 정책 유형이 Multi 인 경우 읽기 리소스와 쓰기 리소스를 선택해야 합니다.
- 네임스페이스 정책 유형이 Cache 인 경우 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 Hub 네임 스페이스 저장소를 선택해야 합니다.
- 다음을 클릭합니다.
- 새 버킷 클래스를 검토한 다음 Create Bucketclass(Bucketclass 만들기 )를 클릭합니다.
- BucketClass 페이지에서 새로 생성된 리소스가 생성 단계에 있는지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 상태 카드에서 Storage System 을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
- 오브젝트 탭에서 Multicloud Object Gateway → Buckets → Namespace Buckets 탭을 클릭합니다.
Create Namespace Bucket 을 클릭합니다.
- 이름 선택 탭에서 네임 스페이스 버킷의 이름을 지정하고 다음을 클릭합니다.
Set Placement 탭에서 다음을 수행합니다.
- Read Policy 에서 네임스페이스 버킷이 데이터를 읽도록 5단계에서 생성된 각 네임스페이스 리소스의 확인란을 선택합니다.
- 사용 중인 네임스페이스 정책 유형이 Multi 이면 Under Write Policy 인 경우 네임스페이스 버킷이 데이터를 써야 하는 네임스페이스 리소스를 지정합니다.
- 다음을 클릭합니다.
- 생성을 클릭합니다.
검증
- 네임 스페이스 버킷이 상태 열에 녹색 확인 표시, 예상 읽기 리소스 수 및 예상되는 쓰기 리소스 이름으로 나열되는지 확인합니다.
10.6. 하이브리드 및 멀티클라우드 버킷에 대한 데이터 미러링
MCG(Multicloud Object Gateway)는 클라우드 공급자 및 클러스터에 걸쳐 있는 데이터 프로세스를 간소화합니다.
사전 요구 사항
- 먼저 MCG에서 사용할 수 있는 백업 스토리지를 추가해야 합니다. 10.4절. “하이브리드 또는 멀티클라우드용 스토리지 리소스 추가” 를 참조하십시오.
그런 다음 데이터 관리 정책을 반영하는 버킷 클래스를 만듭니다.
절차
다음 세 가지 방법으로 미러링 데이터를 설정할 수 있습니다.
10.6.1. MCG 명령줄 인터페이스를 사용하여 데이터를 미러링하기 위한 버킷 클래스 생성
MCG(Multicloud Object Gateway) 명령줄 인터페이스에서 다음 명령을 실행하여 미러링 정책으로 버킷 클래스를 생성합니다.
$ noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
새로 생성된 버킷 클래스를 새 버킷 클레임으로 설정하여 두 위치 간에 미러링될 새 버킷을 생성합니다.
$ noobaa obc create mirrored-bucket --bucketclass=mirror-to-aws
10.6.2. YAML을 사용하여 데이터를 미러링하기 위한 버킷 클래스 생성
다음 YAML을 적용합니다. 이 YAML은 로컬 Ceph 스토리지와 AWS 간에 데이터를 미러링하는 하이브리드 예입니다.
apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <bucket-class-name> namespace: openshift-storage spec: placementPolicy: tiers: - backingStores: - <backing-store-1> - <backing-store-2> placement: Mirror표준 OBC(오브젝트 버킷 클레임)에 다음 행을 추가합니다.
additionalConfig: bucketclass: mirror-to-aws
OBC에 대한 자세한 내용은 10.8절. “오브젝트 버킷 클레임” 를 참조하십시오.
10.6.3. 사용자 인터페이스를 사용하여 데이터를 미러링하도록 버킷 구성
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 상태 카드에서 Storage System 을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
- Object 탭에서 Multicloud Object Gateway 링크를 클릭합니다.
NooBaa 페이지에서 왼쪽의 버킷 아이콘을 클릭합니다. 버킷 목록을 볼 수 있습니다.

- 업데이트하려는 버킷을 클릭합니다.
계층 1 리소스 편집 을 클릭합니다.

미러 를 선택하고 이 버킷에 사용할 관련 리소스를 확인합니다. 다음 예제에서 AWS에 있는
noobaa-default-backing-store와 AWS에 있는AWS-backingstore간의 데이터가 미러링됩니다.
- 저장을 클릭합니다.
NooBaa UI에서 생성된 리소스는 OpenShift UI 또는 MCG(Multicloud Object Gateway) CLI에서 사용할 수 없습니다.
10.7. Multicloud Object Gateway의 버킷 정책
OpenShift Data Foundation은 AWS S3 버킷 정책을 지원합니다. 버킷 정책을 사용하면 사용자에게 버킷 및 오브젝트에 대한 액세스 권한을 부여할 수 있습니다.
10.7.1. 버킷 정책 정보
버킷 정책은 AWS S3 버킷 및 오브젝트에 권한을 부여할 수 있는 액세스 정책 옵션입니다. 버킷 정책은 JSON 기반 액세스 정책 언어를 사용합니다. 액세스 정책 언어에 대한 자세한 내용은 AWS Access Policy Language Overview 를 참조하십시오.
10.7.2. 버킷 정책 사용
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
- MCG(Multicloud Object Gateway)에 대한 액세스 보기 10.2절. “애플리케이션을 사용하여 Multicloud Object Gateway에 액세스”
절차
MCG에서 버킷 정책을 사용하려면 다음을 수행합니다.
JSON 형식으로 버킷 정책을 생성합니다. 다음 예제를 참조하십시오.
{ "Version": "NewVersion", "Statement": [ { "Sid": "Example", "Effect": "Allow", "Principal": [ "john.doe@example.com" ], "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::john_bucket" ] } ] }버킷 정책에는 액세스 권한과 관련하여 사용 가능한 많은 요소가 있습니다.
이러한 요소 및 액세스 권한을 제어하는 데 사용할 수 있는 방법에 대한 예제에 대한 자세한 내용은 AWS Access Policy Language 개요 를 참조하십시오.
버킷 정책 예제에 대한 자세한 내용은 AWS Bucket Policy Examples 를 참조하십시오.
S3 사용자 생성에 대한 지침은 10.7.3절. “Multicloud Object Gateway에서 AWS S3 사용자 생성” 에서 확인할 수 있습니다.
AWS S3 클라이언트를 사용하여
put-bucket-policy명령을 사용하여 버킷 정책을 S3 버킷에 적용합니다.# aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy
-
ENDPOINT를 S3 끝점으로 교체합니다. -
MyBucket을 버킷으로 교체하여 정책을 설정합니다. -
BucketPolicy를 버킷 정책 JSON 파일로 교체합니다. 기본 자체 서명된 인증서를 사용하는 경우
--no-verify-ssl을 추가합니다.예를 들면 다음과 같습니다.
# aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy
put-bucket-policy명령에 대한 자세한 내용은 AWS CLI 명령 참조에서 put-bucket-policy 를 참조하십시오.참고principal 요소는 버킷과 같이 리소스에 대한 액세스 허용 또는 거부된 사용자를 지정합니다. 현재 NooBaa 계정만 보안 주체로 사용할 수 있습니다. 객체 버킷 클레임의 경우 NooBaa는
obc-account.<generated bucket name>@noobaa.io.io 계정을 자동으로 생성합니다.참고버킷 정책 조건은 지원되지 않습니다.
-
10.7.3. Multicloud Object Gateway에서 AWS S3 사용자 생성
사전 요구 사항
- 실행 중인 OpenShift Data Foundation Platform.
- MCG(Multicloud Object Gateway)에 대한 액세스 보기 10.2절. “애플리케이션을 사용하여 Multicloud Object Gateway에 액세스”
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 상태 카드에서 Storage System 을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
- Object 탭에서 Multicloud Object Gateway 링크를 클릭합니다.
계정 탭에서 계정 생성 을 클릭합니다.

S3 Access only 을 선택하고 계정 이름 (예: john.doe@example.com)을 제공합니다. mailto:john.doe@example.com 다음을 클릭합니다.

S3 기본 배치 (예: noobaa-default-backing-store )를 선택합니다. 버킷 권한 을 선택합니다. 특정 버킷 또는 모든 버킷을 선택할 수 있습니다. 생성을 클릭합니다.

10.8. 오브젝트 버킷 클레임
오브젝트 버킷 클레임은 워크로드에 S3 호환 버킷 백엔드를 요청하는 데 사용할 수 있습니다.
다음과 같은 세 가지 방법으로 오브젝트 버킷 클레임을 생성할 수 있습니다.
오브젝트 버킷 클레임은 새 액세스 키 및 시크릿 액세스 키를 포함하여 버킷에 대한 권한이 있는 NooBaa에서 새 버킷과 애플리케이션 계정을 생성합니다. 애플리케이션 계정은 단일 버킷에만 액세스할 수 있으며 기본적으로 새 버킷을 생성할 수 없습니다.
10.8.1. 동적 오브젝트 버킷 클레임
영구 볼륨과 유사하게 애플리케이션의 YAML에 OBC(오브젝트 버킷 클레임)의 세부 정보를 추가하고 오브젝트 서비스 끝점, 액세스 키, 구성 맵 및 시크릿 액세스 키를 가져올 수 있습니다. 이 정보를 동적으로 애플리케이션의 환경 변수로 읽을 수 있습니다.
절차
애플리케이션 YAML에 다음 행을 추가합니다.
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <obc-name> spec: generateBucketName: <obc-bucket-name> storageClassName: openshift-storage.noobaa.io
이 라인은 OBC 자체입니다.
-
<obc-name>을 고유한 OBC 이름으로 바꿉니다. -
<obc-bucket-name>을 OBC의 고유한 버킷 이름으로 바꿉니다.
-
YAML 파일에 더 많은 줄을 추가하여 OBC 사용을 자동화할 수 있습니다. 아래 예는 버킷 클레임 결과 매핑으로, 데이터가 있는 구성 맵과 인증 정보가 있는 시크릿입니다. 이 특정 작업은 버킷과 계정을 생성하는 NooBaa의 오브젝트 버킷을 클레임합니다.
apiVersion: batch/v1 kind: Job metadata: name: testjob spec: template: spec: restartPolicy: OnFailure containers: - image: <your application image> name: test env: - name: BUCKET_NAME valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_NAME - name: BUCKET_HOST valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_HOST - name: BUCKET_PORT valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_PORT - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: <obc-name> key: AWS_ACCESS_KEY_ID - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: <obc-name> key: AWS_SECRET_ACCESS_KEY-
<obc-name>의 모든 인스턴스를 OBC 이름으로 바꿉니다. -
<your application image>를 애플리케이션 이미지로 바꿉니다.
-
업데이트된 YAML 파일을 적용합니다.
# oc apply -f <yaml.file>
<yaml.file>을 YAML 파일의 이름으로 바꿉니다.새 구성 맵을 보려면 다음을 실행합니다.
# oc get cm <obc-name> -o yaml
obc-name을 OBC의 이름으로 바꿉니다.출력에서 다음 환경 변수를 기대할 수 있습니다.
-
BUCKET_HOST- 애플리케이션에서 사용할 끝점입니다. BUCKET_PORT- 애플리케이션에 사용 가능한 포트입니다.-
포트는
BUCKET_HOST와 관련이 있습니다. 예를 들어BUCKET_HOST가 https://my.example.com 이고BUCKET_PORT가 443이면 오브젝트 서비스의 끝점이 https://my.example.com:443 여야 합니다.
-
포트는
-
BUCKET_NAME- 요청되거나 생성된 버킷 이름입니다. -
AWS_ACCESS_KEY_ID- 인증 정보의 일부인 액세스 키입니다. -
AWS_SECRET_ACCESS_KEY- 인증 정보의 일부인 보안 액세스 키입니다.
-
AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY 를 검색합니다. 이름은 AWS S3 API와 호환되도록 사용됩니다. 특히 MCG(Multicloud Object Gateway) 버킷에서 S3 작업을 수행하는 동안 키를 지정해야 합니다. 키는 Base64로 인코딩됩니다. 키를 사용하기 전에 디코딩합니다.
# oc get secret <obc_name> -o yaml<obc_name>- 오브젝트 버킷 클레임의 이름을 지정합니다.
10.8.2. 명령줄 인터페이스를 사용하여 오브젝트 버킷 클레임 생성
명령줄 인터페이스를 사용하여 OBC(오브젝트 버킷 클레임)를 생성할 때 구성 맵과 함께 애플리케이션에 오브젝트 스토리지 서비스를 사용하는 데 필요한 모든 정보가 포함된 시크릿이 제공됩니다.
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다.
- IBM Power의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- IBM Z 인프라의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
절차
명령줄 인터페이스를 사용하여 새 버킷 및 자격 증명의 세부 정보를 생성합니다. 다음 명령을 실행합니다.
# noobaa obc create <obc-name> -n openshift-storage
<obc-name>을 고유한 OBC 이름으로 교체합니다(예:myappobc).또한
--app-namespace옵션을 사용하여 OBC 구성 맵과 보안이 생성될 네임스페이스(예:myapp-namespace)를 지정할 수 있습니다.출력 예:
INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"
MCG 명령줄-인터페이스는 필요한 구성을 생성하고 OpenShift에 새로운 OBC에 대한 정보를 제공합니다.
다음 명령을 실행하여 OBC를 확인합니다.
# oc get obc -n openshift-storage
출력 예:
NAME STORAGE-CLASS PHASE AGE test21obc openshift-storage.noobaa.io Bound 38s
다음 명령을 실행하여 새 OBC의 YAML 파일을 확인합니다.
# oc get obc test21obc -o yaml -n openshift-storage
출력 예:
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer generation: 2 labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage resourceVersion: "40756" selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af spec: ObjectBucketName: obc-openshift-storage-test21obc bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4 generateBucketName: test21obc storageClassName: openshift-storage.noobaa.io status: phase: Boundopenshift-storage네임스페이스 내에서 이 OBC를 사용할 구성 맵과 시크릿을 찾을 수 있습니다. CM과 시크릿의 이름은 OBC와 동일합니다. 다음 명령을 실행하여 시크릿을 확인합니다.# oc get -n openshift-storage secret test21obc -o yaml
출력 예:
Example output: apiVersion: v1 data: AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY= AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ== kind: Secret metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage ownerReferences: - apiVersion: objectbucket.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ObjectBucketClaim name: test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af resourceVersion: "40751" selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc uid: 65117c1c-f662-11e9-9094-0a5305de57bb type: Opaque시크릿은 S3 액세스 자격 증명을 제공합니다.
다음 명령을 실행하여 구성 맵을 확인합니다.
# oc get -n openshift-storage cm test21obc -o yaml
출력 예:
apiVersion: v1 data: BUCKET_HOST: 10.0.171.35 BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4 BUCKET_PORT: "31242" BUCKET_REGION: "" BUCKET_SUBREGION: "" kind: ConfigMap metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage ownerReferences: - apiVersion: objectbucket.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ObjectBucketClaim name: test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af resourceVersion: "40752" selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc uid: 651c6501-f662-11e9-9094-0a5305de57bb구성 맵에는 애플리케이션의 S3 끝점 정보가 포함되어 있습니다.
10.8.3. OpenShift 웹 콘솔을 사용하여 오브젝트 버킷 클레임 생성
OpenShift 웹 콘솔을 사용하여 OBC(오브젝트 버킷 클레임)를 생성할 수 있습니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리 액세스.
- 애플리케이션에서 OBC와 통신하려면 구성 맵과 시크릿을 사용해야 합니다. 이에 대한 자세한 내용은 10.8.1절. “동적 오브젝트 버킷 클레임” 을 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷 클레임 → 오브젝트 버킷 클레임 생성 을 클릭합니다.
오브젝트 버킷 클레임의 이름을 입력하고 드롭다운 메뉴에서 배포, 내부 또는 외부를 기반으로 적절한 스토리지 클래스를 선택합니다.
- 내부 모드

배포 후 생성된 다음 스토리지 클래스를 사용할 수 있습니다.
-
OCS-storagecluster-ceph-rgw는 Ceph Object Gateway(RGW)를 사용합니다. -
openshift-storage.nooba.io는 MCG(Multicloud Object Gateway)를 사용합니다.
-
- 외부 모드

배포 후 생성된 다음 스토리지 클래스를 사용할 수 있습니다.
-
OCS-external-storagecluster-ceph-rgw는 RGW를 사용합니다. openshift-storage.nooba.io는 MCG를 사용합니다.참고RGW OBC 스토리지 클래스는 OpenShift Data Foundation 버전 4.5의 새로운 설치에서만 사용할 수 있습니다. 이전 OpenShift Data Foundation 릴리스에서 업그레이드된 클러스터에는 적용되지 않습니다.
-
생성을 클릭합니다.
OBC를 생성하면 세부 정보 페이지로 리디렉션됩니다.

추가 리소스
10.8.4. 배포에 오브젝트 버킷 클레임 연결
생성되면 OBC(오브젝트 버킷 클레임)를 특정 배포에 연결할 수 있습니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리 액세스.
절차
- 왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷 클레임 을 클릭합니다.
생성한 OBC 옆에 있는 Action 메뉴 (octets) 를 클릭합니다.
드롭다운 메뉴에서 Attach to Deployment 를 선택합니다.

Deployment Name(배포 이름) 목록에서 원하는 배포를 선택한 다음 Attach (연결)를 클릭합니다.

추가 리소스
10.8.5. OpenShift 웹 콘솔을 사용하여 오브젝트 버킷 보기
OpenShift 웹 콘솔을 사용하여 OBC(오브젝트 버킷 클레임)에 대해 생성된 오브젝트 버킷의 세부 정보를 볼 수 있습니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리 액세스.
절차
- OpenShift 웹 콘솔에 로그인합니다.
왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷을 클릭합니다.

또는 특정 OBC의 세부 정보 페이지로 이동하여 리소스 링크를 클릭하여 해당 OBC의 오브젝트 버킷을 볼 수도 있습니다.
- 세부 정보를 표시하려는 오브젝트 버킷을 선택합니다. 오브젝트 버킷 세부 정보 페이지로 이동합니다.
추가 리소스
10.8.6. 오브젝트 버킷 클레임 삭제
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리 액세스.
절차
- 왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷 클레임 을 클릭합니다.
삭제하려는 OBC (오브젝트 버킷 클레임) 옆에 있는 Action 메뉴(octets)를 클릭합니다.

- Delete Object Bucket Claim 을 선택합니다.
- 삭제를 클릭합니다.
추가 리소스
10.9. 오브젝트 버킷에 대한 캐싱 정책
캐시 버킷은 허브 대상과 캐시 대상이 있는 네임스페이스 버킷입니다. hub 대상은 S3 호환 큰 오브젝트 스토리지 버킷입니다. 캐시 버킷은 로컬 Multicloud Object Gateway 버킷입니다. AWS 버킷 또는 IBM COS 버킷을 캐시하는 캐시 버킷을 생성할 수 있습니다.
캐시 버킷은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
10.9.1. AWS 캐시 버킷 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다. IBM Z 인프라의 경우 다음 명령을 사용합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
NamespaceStore 리소스를 생성합니다. NamespaceStore는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
-
<namespacestore>를 namespacestore의 이름으로 바꿉니다. -
<AWS ACCESS KEY>및<AWS SECRET ACCESS KEY>를 이를 위해 생성한 AWS 액세스 키 ID 및 시크릿 액세스 키로 바꿉니다. <bucket-name>을 기존 AWS 버킷 이름으로 교체합니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.YAML을 적용하여 스토리지 리소스를 추가할 수도 있습니다. 먼저 인증 정보를 사용하여 보안을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <namespacestore-secret-name> type: Opaque data: AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64> AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고
<AWS ACCESS KEY ID ENCODED IN BASE64>및<AWS SECRET ACCESS KEY ENCODED IN BASE64>BASE64>의 결과를 사용해야 합니다.<namespacestore-secret-name>을 고유한 이름으로 교체합니다.다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: NamespaceStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: <namespacestore> namespace: openshift-storage spec: awsS3: secret: name: <namespacestore-secret-name> namespace: <namespace-secret> targetBucket: <target-bucket> type: aws-s3-
<namespacestore>를 고유한 이름으로 교체합니다. -
<namespacestore-secret-name>을 이전 단계에서 생성한 보안으로 교체합니다. -
<namespace-secret>을 이전 단계에서 보안을 생성하는 데 사용되는 네임스페이스로 교체합니다. -
<target-bucket>을 namespacestore에 대해 생성한 AWS S3 버킷으로 바꿉니다.
-
다음 명령을 실행하여 버킷 클래스를 생성합니다.
noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>
-
<my-cache-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<backing-store>를 관련 백업 저장소로 바꿉니다. 이 필드에서 쉼표로 구분된 백업 저장소를 하나 이상 나열할 수 있습니다. -
<namespacestore>를 이전 단계에서 생성한 namespacestore로 바꿉니다.
-
다음 명령을 실행하여 2단계에서 정의된 버킷 클래스를 사용하는 OBC(오브젝트 버킷 클레임) 리소스를 사용하여 버킷을 생성합니다.
noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
-
<my-bucket-claim>을 고유 이름으로 교체합니다. -
<custom-bucket-class>를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.
-
10.9.2. IBM COS 캐시 버킷 생성
사전 요구 사항
MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms # yum install mcg
참고서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위해 적절한 아키텍처를 지정합니다.
- IBM Power의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
- IBM Z 인프라의 경우 다음 명령을 사용하십시오.
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수 있습니다.
참고아키텍처에 따라 올바른 제품 변형을 선택합니다.
절차
NamespaceStore 리소스를 생성합니다. NamespaceStore는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.
noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name>
-
<namespacestore>를 NamespaceStore의 이름으로 바꿉니다. -
<IBM ACCESS KEY>,<IBM SECRET ACCESS KEY>,<IBM COS ENDPOINT>를 IBM 액세스 키 ID, 시크릿 액세스 키 및 기존 IBM 버킷의 위치에 해당하는 적절한 지역 끝점으로 바꿉니다. <bucket-name>을 기존 IBM 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대한 대상 버킷으로 사용할 버킷을 알려주고 그 이후 데이터 스토리지 및 관리에 사용할 버킷을 알려줍니다.YAML을 적용하여 스토리지 리소스를 추가할 수도 있습니다. 먼저 인증 정보를 사용하여 보안을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <namespacestore-secret-name> type: Opaque data: IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64> IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 시크릿 액세스 키를 입력하고 인코딩해야 합니다.
<IBM COS ACCESS KEY ID ENCODED IN BASE64>및<IBM COS ACCESS KEY ENCODED IN BASE64>ACCESS KEY<namespacestore-secret-name>을 고유한 이름으로 교체합니다.다음 YAML을 적용합니다.
apiVersion: noobaa.io/v1alpha1 kind: NamespaceStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: <namespacestore> namespace: openshift-storage spec: s3Compatible: endpoint: <IBM COS ENDPOINT> secret: name: <backingstore-secret-name> namespace: <namespace-secret> signatureVersion: v2 targetBucket: <target-bucket> type: ibm-cos-
<namespacestore>를 고유한 이름으로 교체합니다. -
<IBM COS ENDPOINT>를 적절한 IBM COS 엔드포인트로 바꿉니다. -
<backingstore-secret-name>을 이전 단계에서 생성한 보안으로 교체합니다. -
<namespace-secret>을 이전 단계에서 보안을 생성하는 데 사용되는 네임스페이스로 교체합니다. -
<target-bucket>을 namespacestore에 대해 생성한 AWS S3 버킷으로 바꿉니다.
-
다음 명령을 실행하여 버킷 클래스를 생성합니다.
noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>
-
<my-bucket-class>를 고유한 버킷 클래스 이름으로 교체합니다. -
<backing-store>를 관련 백업 저장소로 바꿉니다. 이 필드에서 쉼표로 구분된 백업 저장소를 하나 이상 나열할 수 있습니다. -
<namespacestore>를 이전 단계에서 생성한 namespacestore로 바꿉니다.
-
다음 명령을 실행하여 2단계에서 정의된 버킷 클래스를 사용하는 Object Bucket Claim 리소스를 사용하여 버킷을 생성합니다.
noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
-
<my-bucket-claim>을 고유 이름으로 교체합니다. -
<custom-bucket-class>를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.
-
10.10. 끝점을 추가하여 멀티 클라우드 오브젝트 게이트웨이 성능 확장
Multicloud Object Gateway 성능은 환경에 따라 다를 수 있습니다. 경우에 따라 특정 애플리케이션에는 S3 끝점 스케일링을 통해 쉽게 해결할 수 있는 더 빠른 성능이 필요합니다.
Multicloud Object Gateway 리소스 풀은 기본적으로 활성화된 두 가지 유형의 서비스를 제공하는 NooBaa 데몬 컨테이너 그룹입니다.
- 스토리지 서비스
- S3 끝점 서비스
10.10.1. 스토리지 노드를 사용하여 Multicloud Object Gateway 확장
사전 요구 사항
- MCG(Multicloud Object Gateway)에 액세스할 수 있는 OpenShift Container Platform에서 실행 중인 OpenShift Data Foundation 클러스터입니다.
MCG의 스토리지 노드는 하나 이상의 PV(영구 볼륨)에 연결된 NooBaa 데몬 컨테이너이며 로컬 오브젝트 서비스 데이터 스토리지에 사용됩니다. NooBaa 데몬은 Kubernetes 노드에 배포할 수 있습니다. 이 작업은 StatefulSet Pod로 구성된 Kubernetes 풀을 생성하여 수행할 수 있습니다.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- MCG 사용자 인터페이스에서 개요 → 스토리지 리소스 추가 를 클릭합니다.
- 창에서 Kubernetes 풀 배포를 클릭합니다.
- Create Pool 단계에서 향후 설치된 노드에 대한 대상 풀을 생성합니다.
- Configure 단계에서 요청된 Pod 수 및 각 PV의 크기를 구성합니다. 새 포드마다 하나의 PV를 생성해야 합니다.
- 검토 단계에서는 새 풀의 세부 정보를 찾아 로컬 또는 외부 배포라는 배포 방법을 선택할 수 있습니다. 로컬 배포를 선택하면 Kubernetes 노드가 클러스터 내에 배포됩니다. 외부 배포를 선택하면 외부에서 실행할 YAML 파일이 제공됩니다.
- 모든 노드는 첫 번째 단계에서 선택한 풀에 할당되며 리소스 → 스토리지 리소스 → 리소스 이름에서 확인할 수 있습니다.
10.11. MultiCloud Object Gateway 끝점 자동 스케일링
MCG(MultiCloud Object Gateway) 엔드포인트 수는 MCG S3 서비스의 부하가 증가하거나 감소할 때 자동으로 확장됩니다. OpenShift Data Foundation 클러스터는 하나의 활성 MCG 끝점과 함께 배포됩니다. 각 MCG 끝점 Pod는 기본적으로 요청과 일치하는 제한이 있는 1개의 CPU 및 2Gi 메모리 요청으로 구성됩니다. 끝점의 CPU 로드가 일관된 기간 동안 80% 이상의 사용 임계값을 초과하면 첫 번째 끝점에서 부하를 줄입니다. 두 끝점의 평균 CPU 부하가 일관된 기간 동안 80% 임계값 아래로 떨어지면 끝점 중 하나가 삭제됩니다. 이 기능을 사용하면 MCG의 성능 및 서비스 가능성이 향상됩니다.
11장. 영구 볼륨 클레임 관리
OpenShift Data Foundation에서 지원하는 PVC에서는 PVC 확장이 지원되지 않습니다.
11.1. OpenShift Data Foundation을 사용하도록 애플리케이션 Pod 구성
이 섹션의 지침에 따라 OpenShift Data Foundation을 애플리케이션 포드의 스토리지로 구성합니다.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
-
OpenShift Data Foundation Operator는
openshift-storage네임스페이스에 설치 및 실행됩니다. OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 Operator 를 확인합니다. - OpenShift Data Foundation에서 제공하는 기본 스토리지 클래스를 사용할 수 있습니다. OpenShift 웹 콘솔에서 스토리지 → StorageClasses 를 클릭하여 기본 스토리지 클래스를 확인합니다.
절차
애플리케이션에서 사용할 영구 볼륨 클레임(PVC)을 생성합니다.
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
- 애플리케이션 포드에 대한 프로젝트를 설정합니다.
영구 볼륨 클레임 생성 을 클릭합니다.
- OpenShift Data Foundation에서 제공하는 스토리지 클래스 를 지정합니다.
-
PVC 이름 (예:
myclaim)을 지정합니다. 필요한 액세스 모드를 선택합니다.
참고액세스 모드,
RWX(공유 액세스)는 IBM FlashSystem에서 지원되지 않습니다.-
Rados Block Device (RBD)의 경우 액세스 모드가 ReadWriteOnce (
RWO)인 경우 필요한 볼륨 모드를 선택합니다. 기본 볼륨 모드는Filesystem입니다. - 애플리케이션 요구 사항에 따라 Size 를 지정합니다.
-
생성 을 클릭하고 PVC가
Bound상태가 될 때까지 기다립니다.
새 PVC를 사용하도록 새 애플리케이션 Pod 또는 기존 애플리케이션 Pod를 구성합니다.
새 애플리케이션 Pod의 경우 다음 단계를 수행합니다.
- 워크로드 →포드 를 클릭합니다.
- 새 애플리케이션 포드를 생성합니다.
spec:섹션에서 volume: 섹션을 추가하여 새 PVC를 애플리케이션 Pod의 볼륨으로추가합니다.volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>예를 들면 다음과 같습니다.
volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
기존 애플리케이션 Pod의 경우 다음 단계를 수행합니다.
- 워크로드 →배포 구성을 클릭합니다.
- 애플리케이션 Pod와 관련된 필수 배포 구성을 검색합니다.
- 작업 메뉴(octets) → 배포 구성 편집 을 클릭합니다.
spec:섹션에서 volume: 섹션을 추가하여 새 PVC를 애플리케이션 Pod의 볼륨으로추가하고 저장을 클릭합니다.volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>예를 들면 다음과 같습니다.
volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
새 구성이 사용 중인지 확인합니다.
- 워크로드 → 포드 를 클릭합니다.
- 애플리케이션 포드에 대한 프로젝트를 설정합니다.
-
애플리케이션 포드가
Running(실행 중) 상태로 표시되는지 확인합니다. - 애플리케이션 포드 이름을 클릭하여 Pod 세부 정보를 확인합니다.
-
Volumes (볼륨) 섹션까지 아래로 스크롤하여 볼륨에 새 영구 볼륨 클레임과 일치하는 Type (예:
myclaim)이 있는지 확인합니다.
11.2. 영구 볼륨 클레임 요청 상태 보기
PVC 요청의 상태를 보려면 다음 절차를 사용하십시오.
사전 요구 사항
- OpenShift Data Foundation에 대한 관리자 액세스 권한
절차
- OpenShift 웹 콘솔에 로그인합니다.
- 스토리지 → 영구 볼륨 클레임을 클릭합니다.
- 필터 텍스트 상자를 사용하여 필요한 PVC 이름을 검색합니다. 또한 이름 또는 레이블로 PVC 목록을 필터링하여 목록을 좁힐 수 있습니다.
- 필요한 PVC에 해당하는 Status 열을 확인합니다.
- 필요한 이름을 클릭하여 PVC 세부 정보를 확인합니다.
11.3. 영구 볼륨 클레임 요청 이벤트 검토
PVC(영구 볼륨 클레임) 요청 이벤트를 검토하고 해결하려면 다음 절차를 사용하십시오.
사전 요구 사항
- OpenShift 웹 콘솔에 대한 관리자 액세스.
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 스토리지 시스템 탭에서 스토리지 시스템을 선택한 다음 개요 → 블록 및 파일을 클릭합니다.
- 인벤토리 카드를 찾아 오류가 있는 PVC 수를 확인합니다.
- 스토리지 → 영구 볼륨 클레임을 클릭합니다.
- 필터 텍스트 상자를 사용하여 필요한 PVC를 검색합니다.
- PVC 이름을 클릭하고 Events로 이동합니다.
- 필요에 따라 또는 지시에 따라 이벤트를 처리합니다.
11.4. 동적 프로비저닝
11.4.1. 동적 프로비저닝 소개
StorageClass 리소스 객체는 요청 가능한 스토리지를 설명하고 분류할 뿐 만 아니라 필요에 따라 동적으로 프로비저닝된 스토리지에 대한 매개 변수를 전달하는 수단을 제공합니다. StorageClass 객체는 다른 수준의 스토리지 및 스토리지에 대한 액세스를 제어하기 위한 관리 메커니즘으로 사용될 수 있습니다. 클러스터 관리자(cluster-admin) 또는 스토리지 관리자(storage-admin)는 사용자가 기본 스토리지 볼륨 소스에 대한 자세한 지식이 없어도 요청할 수 있는 StorageClass 오브젝트를 정의하고 생성합니다.
OpenShift Container Platform 영구 볼륨 프레임 워크를 사용하면이 기능을 사용할 수 있으며 관리자는 영구 스토리지로 클러스터를 프로비저닝할 수 있습니다. 또한 이 프레임 워크를 통해 사용자는 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.
OpenShift Container Platform에서 많은 스토리지 유형을 영구 볼륨으로 사용할 수 있습니다. 관리자가 이를 모두 정적으로 프로비저닝할 수 있지만 일부 스토리지 유형은 기본 제공자 및 플러그인 API를 사용하여 동적으로 만들 수 있습니다.
11.4.2. OpenShift Data Foundation의 동적 프로비저닝
Red Hat OpenShift Data Foundation은 컨테이너 환경에 최적화된 소프트웨어 정의 스토리지입니다. OpenShift Container Platform에서 Operator로 실행되어 컨테이너에 고도로 통합되고 단순화된 영구 스토리지 관리 기능을 제공합니다.
OpenShift Data Foundation은 다음을 포함하여 다양한 스토리지 유형을 지원합니다.
- 데이터베이스용 블록 스토리지
- 지속적인 통합, 메시징 및 데이터 집계를 위한 공유 파일 스토리지
- 아카이브, 백업 및 미디어 스토리지를 위한 오브젝트 스토리지
버전 4에서는 Red Hat Ceph Storage를 사용하여 영구 볼륨 및 클레임을 지원하는 파일, 블록 및 오브젝트 스토리지를 제공하며, Rook.io는 영구 볼륨 및 클레임의 프로비저닝을 관리하고 오케스트레이션합니다. NooBaa는 객체 스토리지를 제공하며, Multicloud Gateway는 여러 클라우드 환경(기술 프리뷰로 사용 가능)에 걸쳐 객체 페더레이션을 허용합니다.
OpenShift Data Foundation 4에서 RADOS Block Device(RBD) 및 Ceph File System(CephFS)의 Red Hat Ceph Storage Interface(CSI) 드라이버는 동적 프로비저닝 요청을 처리합니다. PVC 요청이 동적으로 입력되면 CSI 드라이버에 다음과 같은 옵션이 있습니다.
-
볼륨 모드
Block이 있는 Ceph RBD를 기반으로 하는 ReadWriteOnce(RWO) 및 ReadWriteMany(RWX) 액세스를 사용하여 PVC를 만듭니다. -
볼륨 모드
파일시스템을 사용하여 Ceph RBD를 기반으로 하는 ReadWriteOnce(RWO) 액세스를 사용하여 PVC를 만듭니다. -
볼륨 모드
파일시스템의 CephFS를 기반으로 하는 ReadWriteOnce(RWO) 및 ReadWriteMany(RWX) 액세스를 사용하여 PVC를 생성합니다.
사용할 드라이버(RBD 또는 CephFS)의 판단은 storageclass.yaml 파일의 항목을 기반으로 합니다.
11.4.3. 사용 가능한 동적 프로비저닝 플러그인
OpenShift Container Platform은 다음과 같은 프로비저너 플러그인을 제공합니다. 이에는 클러스터의 구성된 제공자 API를 사용하여 새 스토리지 리소스의 동적 프로비저닝을 위한 일반 구현이 포함되어 있습니다.
| 스토리지 유형 | 프로비저너 플러그인 이름 | 참고 |
|---|---|---|
| OpenStack Cinder |
| |
| AWS Elastic Block Store (EBS) |
|
다른 영역에서 여러 클러스터를 사용할 때 동적 프로비저닝의 경우 각 노드에 |
| AWS Elastic File System (EFS) | 동적 프로비저닝은 프로비저너 플러그인이 아닌 EFS 프로비저너 Pod를 통해 수행됩니다. | |
| Azure Disk |
| |
| Azure File |
|
|
| GCE Persistent Disk (gcePD) |
| 멀티 존 설정에서는 현재 클러스터에 노드가 없는 영역에서 PV가 생성되지 않도록 GCE 프로젝트 당 하나의 OpenShift Container Platform 클러스터를 실행하는 것이 좋습니다. |
|
| ||
| Red Hat Virtualization |
|
선택한 프로비저너 플러그인에는 관련 문서에 따라 클라우드, 호스트 또는 타사 공급자를 구성해야 합니다.
12장. 볼륨 스냅샷
볼륨 스냅샷은 특정 시점에서 클러스터의 스토리지 볼륨 상태입니다. 이러한 스냅샷을 사용하면 매번 전체 복사본을 만들지 않고도 스토리지를 보다 효율적으로 사용할 수 있으며 애플리케이션 개발을 위한 빌딩 블록으로 사용할 수 있습니다.
동일한 PVC(영구 볼륨 클레임)의 스냅샷을 여러 개 생성할 수 있습니다. CephFS의 경우 PVC당 최대 100개의 스냅샷을 생성할 수 있습니다. RADOS Block Device(RBD)의 경우 PVC당 512개의 스냅샷을 생성할 수 있습니다.
스냅샷 생성을 예약할 수 없습니다.
12.1. 볼륨 스냅샷 생성
PVC(영구 볼륨 클레임) 페이지 또는 볼륨 스냅샷 페이지에서 볼륨 스냅샷을 생성할 수 있습니다.
사전 요구 사항
-
일관된 스냅샷의 경우 PVC가
Bound상태이어야 하며 사용하지 않아야 합니다. 스냅샷을 생성하기 전에 모든 IO를 중지해야 합니다.
OpenShift Data Foundation은 포드에서 PVC를 사용하는 경우에만 PVC의 볼륨 스냅샷에 대해 충돌 일관성을 제공합니다. 애플리케이션 일관성의 경우 실행 중인 Pod를 먼저 종료하여 일관된 스냅샷을 확인하거나 애플리케이션에서 제공하는 quiesce 메커니즘을 사용하여 확인합니다.
절차
- 영구 볼륨 클레임 페이지에서
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
볼륨 스냅샷을 생성하려면 다음 중 하나를 수행하십시오.
- 원하는 PVC에 있는 Action 메뉴(hiera ) → Create Snapshot (스냅샷 생성) 을 클릭합니다.
- 스냅샷을 생성할 PVC를 클릭하고 작업 → 스냅샷 생성 을 클릭합니다.
- 볼륨 스냅샷의 이름을 입력합니다.
- 드롭다운 목록에서 스냅샷 클래스 를 선택합니다.
- 생성을 클릭합니다. 생성된 볼륨 스냅샷의 세부 정보 페이지로 리디렉션됩니다.
- 볼륨 스냅샷 페이지에서
- OpenShift 웹 콘솔에서 스토리지 → 볼륨 스냅샷 을 클릭합니다.
- Volume Snapshots (볼륨 스냅샷) 페이지에서 Create Volume Snapshot 을 클릭합니다.
- 드롭다운 목록에서 필요한 프로젝트를 선택합니다.
- 드롭다운 목록에서 영구 볼륨 클레임 을 선택합니다.
- 스냅샷의 이름을 입력합니다.
- 드롭다운 목록에서 스냅샷 클래스 를 선택합니다.
- 생성을 클릭합니다. 생성된 볼륨 스냅샷의 세부 정보 페이지로 리디렉션됩니다.
검증 단계
- PVC의 세부 정보 페이지로 이동하여 볼륨 스냅샷 탭을 클릭하여 볼륨 스냅샷 목록을 확인합니다. 새 볼륨 스냅샷이 나열되었는지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → 볼륨 스냅샷 을 클릭합니다. 새 볼륨 스냅샷이 나열되었는지 확인합니다.
-
볼륨 스냅샷이
Ready상태가 될 때까지 기다립니다.
12.2. 볼륨 스냅샷 복원
볼륨 스냅샷을 복원하면 새 PVC(영구 볼륨 클레임)가 생성됩니다. 복원된 PVC는 볼륨 스냅샷 및 상위 PVC와 독립적입니다.
영구 볼륨 클레임 페이지 또는 볼륨 스냅샷 페이지에서 볼륨 스냅샷을 복원할 수 있습니다.
절차
- 영구 볼륨 클레임 페이지에서
상위 PVC가 있는 경우에만 영구 볼륨 클레임 페이지에서 볼륨 스냅샷을 복원할 수 있습니다.
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
- 볼륨 스냅샷의 PVC 이름을 클릭하여 볼륨 스냅샷을 새 PVC로 복원합니다.
- Volume Snapshots (볼륨 스냅샷) 탭에서 복원할 볼륨 스냅샷 옆에 있는 Action(작업) 메뉴를 클릭합니다.
- 새 PVC로 복원을 클릭합니다.
- 새 PVC의 이름을 입력합니다.
스토리지 클래스 이름을 선택합니다.
참고Rados Block Device(RBD)의 경우 상위 PVC와 동일한 스토리지 클래스를 선택해야 합니다. 암호화가 활성화되지 않고 그 반대의 경우도 마찬가지인 스토리지 클래스를 사용하여 암호화된 PVC의 스냅샷을 복원할 수 있습니다.
선택한 액세스 모드를 선택합니다.
중요ReadOnlyMany(ROX) 액세스 모드는 개발자 프리뷰 기능이며 개발자 프리뷰 지원 제한 사항이 적용됩니다. 개발자 프리뷰 릴리스는 프로덕션 환경에서 실행하기 위한 것이 아니며 Red Hat Customer Portal 케이스 관리 시스템을 통해 지원되지 않습니다. ReadOnlyMany 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 목록에 연락하여 Red Hat Development Team의 구성원은 가용성 및 작업 일정에 따라 최대한 빨리 도움을 드릴 것입니다. ROX 액세스 모드를 사용하려면 복제본 생성 또는 새 읽기 전용 액세스 모드로 스냅샷 복원을 참조하십시오.
- 선택 사항: RBD에서 볼륨 모드를 선택합니다.
- 복원을 클릭합니다. 새 PVC 세부 정보 페이지로 리디렉션됩니다.
- 볼륨 스냅샷 페이지에서
- OpenShift 웹 콘솔에서 스토리지 → 볼륨 스냅샷 을 클릭합니다.
- Volume Snapshots (볼륨 스냅샷) 탭에서 복원할 볼륨 스냅샷 옆에 있는 Action(작업) 메뉴를 클릭합니다.
- 새 PVC로 복원을 클릭합니다.
- 새 PVC의 이름을 입력합니다.
스토리지 클래스 이름을 선택합니다.
참고Rados Block Device(RBD)의 경우 상위 PVC와 동일한 스토리지 클래스를 선택해야 합니다. 암호화가 활성화되지 않고 그 반대의 경우도 마찬가지인 스토리지 클래스를 사용하여 암호화된 PVC의 스냅샷을 복원할 수 있습니다.
선택한 액세스 모드를 선택합니다.
중요ReadOnlyMany(ROX) 액세스 모드는 개발자 프리뷰 기능이며 개발자 프리뷰 지원 제한 사항이 적용됩니다. 개발자 프리뷰 릴리스는 프로덕션 환경에서 실행하기 위한 것이 아니며 Red Hat Customer Portal 케이스 관리 시스템을 통해 지원되지 않습니다. ReadOnlyMany 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 목록에 연락하여 Red Hat Development Team의 구성원은 가용성 및 작업 일정에 따라 최대한 빨리 도움을 드릴 것입니다. ROX 액세스 모드를 사용하려면 복제본 생성 또는 새 읽기 전용 액세스 모드로 스냅샷 복원을 참조하십시오.
- 선택 사항: RBD에서 볼륨 모드를 선택합니다.
- 복원을 클릭합니다. 새 PVC 세부 정보 페이지로 리디렉션됩니다.
검증 단계
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭하고 영구 볼륨 클레임 페이지에 새 PVC가 나열되는지 확인합니다.
-
새 PVC가
Bound상태에 도달할 때까지 기다립니다.
12.3. 볼륨 스냅샷 삭제
사전 요구 사항
- 볼륨 스냅샷을 삭제하려면 해당 특정 볼륨 스냅샷에 사용되는 볼륨 스냅샷 클래스가 있어야 합니다.
절차
- 영구 볼륨 클레임 페이지
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
- 삭제해야 하는 볼륨 스냅샷이 있는 PVC 이름을 클릭합니다.
- Volume Snapshots (볼륨 스냅샷) 탭에서 원하는 볼륨 스냅샷 옆에 있는 Action menu (작업 메뉴) → Delete Volume Snapshot (볼륨 스냅샷 삭제) 을 클릭합니다.
- 볼륨 스냅샷 페이지
- OpenShift 웹 콘솔에서 스토리지 → 볼륨 스냅샷 을 클릭합니다.
- Volume Snapshots 페이지에서 원하는 볼륨 스냅샷 옆에 있는 Action menu (작업 메뉴) → Delete Volume Snapshot (볼륨 스냅샷 삭제) 을 클릭합니다.
검증 단계
- PVC 세부 정보 페이지의 볼륨 스냅샷 탭에 삭제된 볼륨 스냅샷 이 없는지 확인합니다.
- 스토리지 → 볼륨 스냅샷 을 클릭하고 삭제된 볼륨 스냅샷이 나열되어 있지 않은지 확인합니다.
13장. 볼륨 복제
복제본은 표준 볼륨으로 사용되는 기존 스토리지 볼륨이 복제됩니다. 볼륨의 복제본을 생성하여 데이터의 특정 시점 복사를 만듭니다. PVC(영구 볼륨 클레임)는 다른 크기로 복제할 수 없습니다. CephFS 및 RADOS Block Device(RBD) 모두에 대해 PVC당 최대 512개의 복제본을 생성할 수 있습니다.
13.1. 복제 생성
사전 요구 사항
-
소스 PVC는
Bound상태에 있어야 하며 사용할 수 없습니다.
Pod가 이를 사용하는 경우 PVC의 복제본을 생성하지 마십시오. 그러면 PVC가 quiesced(일시 중지됨)되지 않기 때문에 데이터 손상이 발생할 수 있습니다.
절차
- OpenShift 웹 콘솔에서 스토리지 → 영구 볼륨 클레임 을 클릭합니다.
복제본을 생성하려면 다음 중 하나를 수행하십시오.
- 원하는 PVC에 있어야 Action 메뉴 (작업 메뉴) → Clone PVC 복제를 클릭합니다.
- 복제하려는 PVC를 클릭하고 작업 → 복제 PVC 를 클릭합니다.
- 복제의 이름을 입력합니다.
선택한 액세스 모드를 선택합니다.
중요ReadOnlyMany(ROX) 액세스 모드는 개발자 프리뷰 기능이며 개발자 프리뷰 지원 제한 사항이 적용됩니다. 개발자 프리뷰 릴리스는 프로덕션 환경에서 실행하기 위한 것이 아니며 Red Hat Customer Portal 케이스 관리 시스템을 통해 지원되지 않습니다. ReadOnlyMany 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 목록에 연락하여 Red Hat Development Team의 구성원은 가용성 및 작업 일정에 따라 최대한 빨리 도움을 드릴 것입니다. ROX 액세스 모드를 사용하려면 복제본 생성 또는 새 읽기 전용 액세스 모드로 스냅샷 복원을 참조하십시오.
- Clone 을 클릭합니다. 새 PVC 세부 정보 페이지로 리디렉션됩니다.
복제된 PVC 상태가
Bound가 될 때까지 기다립니다.이제 Pod에서 복제된 PVC를 사용할 수 있습니다. 이 복제된 PVC는 dataSource PVC와 독립적입니다.
14장. 스토리지 노드 교체
다음 절차 중 하나를 선택하여 스토리지 노드를 교체할 수 있습니다.
14.1. Red Hat OpenStack Platform 설치 관리자 프로비저닝 인프라에서 운영 노드 교체
Red Hat OpenStack Platform 설치 관리자 프로비저닝 인프라(IPI)에서 운영 노드를 교체하려면 다음 절차를 사용하십시오.
절차
- OpenShift 웹 콘솔에 로그인하고 컴퓨팅 → 노드 를 클릭합니다.
- 교체해야 하는 노드를 식별합니다. 시스템 이름을 기록해 둡니다.
다음 명령을 사용하여 노드를 예약 불가로 표시합니다.
$ oc adm cordon <node_name>
다음 명령을 사용하여 노드를 드레이닝합니다.
$ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets
중요이 활동은 최소 5-10분 이상 걸릴 수 있습니다. 이 기간 동안 생성된 Ceph 오류는 임시이며 새 노드에 레이블이 지정되어 있고 기능할 때 자동으로 해결됩니다.
- 컴퓨팅 → 머신 을 클릭합니다. 필요한 머신을 검색합니다.
- 필요한 시스템 외에도 Action 메뉴 (octets) → 머신 삭제를 클릭합니다.
- Delete 를 클릭하여 머신 삭제를 확인합니다. 새 머신이 자동으로 생성됩니다.
새 머신이 시작되고 Running 상태로 전환될 때까지 기다립니다.
중요이 활동은 최소 5-10분 이상 걸릴 수 있습니다.
- 컴퓨팅 → 노드 를 클릭하고 새 노드가 Ready 상태인지 확인합니다.
다음 중 하나를 사용하여 새 노드에 OpenShift Data Foundation 레이블을 적용합니다.
- 사용자 인터페이스에서
- 새 노드의 경우 Action Menu (octets) → Edit Labels를 클릭합니다.
-
cluster.ocs.openshift.io/openshift-storage를 추가하고 저장을 클릭합니다.
- 명령줄 인터페이스에서
다음 명령을 실행하여 OpenShift Data Foundation 레이블을 새 노드에 적용합니다.
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
검증 단계
다음 명령을 실행하고 출력에 새 노드가 있는지 확인합니다.
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
워크로드 → Pod 를 클릭하고 새 노드의 다음 Pod가 Running 상태인지 확인합니다.
-
csi-cephfsplugin-* -
csi-rbdplugin-*
-
- 기타 필요한 모든 OpenShift Data Foundation Pod가 Running 상태인지 확인합니다.
새 OSD 포드가 교체 노드에서 실행되고 있는지 확인합니다.
$ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd선택 사항: 클러스터에서 클러스터 전체 암호화가 활성화된 경우 새 OSD 장치가 암호화되었는지 확인합니다.
이전 단계에서 확인한 각 새 노드에 대해 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name> $ chroot /host
"lsblk"를 실행하고
ocs-deviceset이름 옆에 "crypt" 키워드를 확인합니다.$ lsblk
- 확인 단계가 실패하면 Red Hat 지원팀에 문의하십시오.
14.2. Red Hat OpenStack Platform 설치 관리자 프로비저닝 인프라에서 오류가 발생한 노드 교체
다음 절차에 따라 OpenShift Data Foundation의 Red Hat OpenStack Platform 설치 관리자 프로비저닝 인프라(IPI)에서 작동하지 않는 오류가 발생한 노드를 교체합니다.
절차
- OpenShift 웹 콘솔에 로그인하고 컴퓨팅 → 노드 를 클릭합니다.
- 오류가 있는 노드를 식별하고 시스템 이름을 클릭합니다.
- 작업 → 주석 편집 을 클릭하고 추가 추가 를 클릭합니다.
-
machine.openshift.io/exclude-node-draining을 추가하고 저장을 클릭합니다. - 작업 → 머신 삭제를 클릭하고 삭제를 클릭합니다.
새 머신이 자동으로 생성되고 새 머신이 시작될 때까지 기다립니다.
중요이 활동은 최소 5-10분 이상 걸릴 수 있습니다. 이 기간 동안 생성된 Ceph 오류는 임시이며 새 노드에 레이블이 지정되어 있고 기능할 때 자동으로 해결됩니다.
- 컴퓨팅 → 노드 를 클릭하고 새 노드가 Ready 상태인지 확인합니다.
다음 중 하나를 사용하여 새 노드에 OpenShift Data Foundation 레이블을 적용합니다.
- 사용자 인터페이스에서
- 새 노드의 경우 Action Menu (octets) → Edit Labels를 클릭합니다.
-
cluster.ocs.openshift.io/openshift-storage를 추가하고 저장을 클릭합니다.
- 명령줄 인터페이스에서
다음 명령을 실행하여 OpenShift Data Foundation 레이블을 새 노드에 적용합니다.
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
- [선택 사항]: 실패한 Red Hat OpenStack Platform 인스턴스가 자동으로 제거되지 않으면 Red Hat OpenStack Platform 콘솔에서 인스턴스를 종료합니다.
검증 단계
다음 명령을 실행하고 출력에 새 노드가 있는지 확인합니다.
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
워크로드 → Pod 를 클릭하고 새 노드의 다음 Pod가 Running 상태인지 확인합니다.
-
csi-cephfsplugin-* -
csi-rbdplugin-*
-
- 기타 필요한 모든 OpenShift Data Foundation Pod가 Running 상태인지 확인합니다.
새 OSD 포드가 교체 노드에서 실행되고 있는지 확인합니다.
$ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd선택 사항: 클러스터에서 클러스터 전체 암호화가 활성화된 경우 새 OSD 장치가 암호화되었는지 확인합니다.
이전 단계에서 확인한 각 새 노드에 대해 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name> $ chroot /host
"lsblk"를 실행하고
ocs-deviceset이름 옆에 "crypt" 키워드를 확인합니다.$ lsblk
- 확인 단계가 실패하면 Red Hat 지원팀에 문의하십시오.
15장. 스토리지 장치 교체
15.1. Red Hat OpenStack Platform 설치 관리자 프로비저닝 인프라에서 운영 또는 실패한 스토리지 장치 교체
다음 절차에 따라 Red Hat OpenStack Platform에 배포된 OpenShift Data Foundation의 스토리지 장치를 교체할 수 있습니다. 이 절차에서는 새 볼륨에서 새 PVC(영구 볼륨 클레임)를 생성하고 이전 오브젝트 스토리지 장치(OSD)를 제거하는 데 도움이 됩니다.
절차
교체해야 하는 OSD와 OSD가 예약된 OpenShift Container Platform 노드를 식별합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
출력 예:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>
이 예에서는
rook-ceph-osd-0-6d77d6c7c6-m8xj6을 교체해야 하며,compute-2는 OSD가 예약된 OpenShift Container Platform 노드입니다.참고교체할 OSD가 정상이면 Pod 상태가
Running이 됩니다.OSD를 교체할 OSD 배포를 축소합니다.
$ osd_id_to_remove=0 $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0여기서
osd_id_to_remove는rook-ceph-osd접두사 바로 직후 포드 이름에 있는 정수입니다. 이 예에서 배포 이름은rook-ceph-osd-0입니다.출력 예:
deployment.extensions/rook-ceph-osd-0 scaled
rook-ceph-osd포드가 종료되었는지 확인합니다.$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}출력 예:
No resources found.
참고rook-ceph-osdPod가종료상태인 경우force옵션을 사용하여 Pod를 삭제합니다.$ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0
출력 예:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted
경우에 따라 실패한 OSD와 연결된 영구 볼륨이 실패하고 실패한 영구 볼륨 세부 정보를 가져오고 다음 명령을 사용하여 해당 볼륨을 삭제합니다.
$ oc get pv $ oc delete pv <failed-pv-name>
새 OSD를 추가할 수 있도록 클러스터에서 이전 OSD를 제거합니다.
이전
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}출력 예:
job.batch "ocs-osd-removal-0" deleted
openshift-storage프로젝트로 변경합니다.$ oc project openshift-storage
클러스터에서 이전 OSD를 제거합니다.
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} |oc create -n openshift-storage -f -명령에 쉼표로 구분된 OSD ID를 추가하여 두 개 이상의 OSD를 제거할 수 있습니다. 예를 들면 다음과 같습니다. FAILED_OSD_IDS=0,1,2)
주의이 단계에서는 OSD가 클러스터에서 완전히 제거됩니다.
osd_id_to_remove의 올바른 값이 제공되는지 확인합니다.
ocs-osd-removal-jobPod의 상태를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.상태가
Completed로 OSD 제거 작업이 성공했는지 확인합니다.# oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
OSD 제거가 완료되었는지 확인합니다.
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
출력 예:
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
중요ocs-osd-removal-job이 실패하고 Pod가 expectedCompleted상태가 아닌 경우 Pod 로그에서 추가 디버깅을 확인합니다.예를 들면 다음과 같습니다.
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1
설치 시 암호화가 활성화된 경우 해당 OpenShift Data Foundation 노드에서 제거된 OSD 장치에서
dm매핑을 제거합니다.-crypt관리 장치-mapperocs-osd-removal-jobPod 로그에서 교체된 OSD의 PVC 이름을 가져옵니다.$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’
예를 들면 다음과 같습니다.
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
단계 #1에서 식별된 각 노드에 대해 다음을 수행합니다.
스토리지 노드의 호스트에
디버그Pod 및chroot를 생성합니다.$ oc debug node/<node name> $ chroot /host
이전 단계에서 확인한 PVC 이름을 기반으로 관련 장치 이름을 찾습니다.
sh-4.4# dmsetup ls| grep <pvc name> ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
매핑된 장치를 제거합니다.
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt
참고충분하지 않은 권한으로 인해 위 명령이 중단되는 경우 다음 명령을 실행합니다.
-
CTRL+Z를 눌러 위의 명령을 종료합니다. 정지된 프로세스의 PID를 찾습니다.
$ ps -ef | grep crypt
kill명령을 사용하여 프로세스를 종료합니다.$ kill -9 <PID>
장치 이름이 제거되었는지 확인합니다.
$ dmsetup ls
-
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}출력 예:
job.batch "ocs-osd-removal-0" deleted
검증 단계
새 OSD가 실행되고 있는지 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
출력 예:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20h
Bound상태에 있는 새 PVC가 생성되었는지 확인합니다.$ oc get -n openshift-storage pvc
출력 예:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-b44ebb5e-3c67-4000-998e-304752deb5a7 50Gi RWO ocs-storagecluster-ceph-rbd 6d ocs-deviceset-0-data-0-gwb5l Bound pvc-bea680cd-7278-463d-a4f6-3eb5d3d0defe 512Gi RWO standard 94s ocs-deviceset-1-data-0-w9pjm Bound pvc-01aded83-6ef1-42d1-a32e-6ca0964b96d4 512Gi RWO standard 6d ocs-deviceset-2-data-0-7bxcq Bound pvc-5d07cd6c-23cb-468c-89c1-72d07040e308 512Gi RWO standard 6d
선택 사항: 클러스터에서 클러스터 전체 암호화가 활성화된 경우 새 OSD 장치가 암호화되었는지 확인합니다.
새 OSD 포드가 실행 중인 노드를 식별합니다.
$ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>
예를 들면 다음과 같습니다.
oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
이전 단계에서 확인한 각 노드에서 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name> $ chroot /host
"lsblk"를 실행하고
ocs-deviceset이름 옆에 "crypt" 키워드를 확인합니다.$ lsblk
OpenShift 웹 콘솔에 로그인하고 스토리지 대시보드를 확인합니다.
그림 15.1. 장치 교체 후 OpenShift Container Platform 스토리지 대시보드의 OSD 상태

16장. OpenShift Data Foundation으로 업그레이드
16.1. OpenShift Data Foundation 업데이트 프로세스 개요
오픈 소스 Ceph 기술을 기반으로 하는 OpenShift Container Storage는 도입 이후 컨테이너화된 하이브리드 클라우드 환경에서의 범위 및 기본 역할을 확장했습니다. 다른 데이터 관련 하드웨어 및 소프트웨어 외에도 기존 스토리지를 보완하여 하이브리드 클라우드 환경에서 빠르게 연결 가능하고 액세스 가능하며 확장할 수 있습니다. 이러한 기본 및 인프라 분리를 보다 잘 반영하기 위해 OpenShift Container Storage는 이제 OpenShift Data Foundation 입니다.
OpenShift Container Platform OperatorHub에서 OpenShift Data Foundation Operator를 설치하는 경우에만 OpenShift Container Storage 버전 4.8에서 OpenShift Data Foundation 버전 4.9의 업그레이드 프로세스를 수행할 수 있습니다.
향후 릴리스에서는 4.9 및 4.x와 같은 마이너 릴리스 사이에서 또는 자동 업데이트를 활성화하지 않는 경우 (운영자 설치 중이 아닌 경우) 자동 업데이트를 활성화하여 4.9.0 및 4.9.1과 같은 배치 업데이트 간에 Red Hat OpenShift Data Foundation을 업그레이드할 수 있습니다.
또한 내부 및 외부 모드 배포 모두에 대해 다음 순서로 Red Hat OpenShift Data Foundation의 다양한 부분을 업그레이드해야 합니다.
- OpenShift Container Platform 의 클러스터 업데이트 문서에 따라 OpenShift Container Platform을 업데이트합니다.
Red Hat OpenShift Data Foundation 업데이트.
- 업데이트를 위해 연결이 끊긴 환경을 준비하려면 제한된 네트워크에서 Operator Lifecycle Manager를 사용하여 Red Hat OpenShift Data Foundation 및 Local Storage Operator를 업데이트할 수 있습니다.
- OpenShift Container Platform 웹 콘솔의 OperatorHub에서 Red Hat OpenShift Container Storage Operator 버전 4.8을 버전 4.9로 업데이트 합니다. Red Hat OpenShift Container Storage 4.8에서 Red Hat OpenShift Data Foundation 4.9로 업데이트를 참조하십시오.
- Red Hat OpenShift Data Foundation을 4.9.x에서 4.9.y로 업데이트합니다. Red Hat OpenShift Data Foundation 4.9.x에서 4.9.y 업데이트를 참조하십시오.
- 외부 모드 배포를 업데이트 하려면 OpenShift Data Foundation 외부 시크릿 업데이트 섹션에서 단계를 수행해야 합니다.
로컬 스토리지를 사용하는 경우:
Local Storage Operator를 업데이트 합니다.
확실하지 않은 경우 Local Storage Operator 배포 확인 을 참조하십시오.
로컬 스토리지에서 지원하는 클러스터의 업데이트 후 구성 변경을 수행합니다.
업데이트 고려 사항
시작하기 전에 다음 중요한 고려 사항을 검토하십시오.
Red Hat은 동일한 Red Hat OpenShift Container Platform 버전을 Red Hat OpenShift Data Foundation과 함께 사용하는 것이 좋습니다.
OpenShift Container Platform 및 Red Hat OpenShift Data Foundation의 지원되는 조합에 대한 자세한 내용은 Interoperability Matrix 를 참조하십시오.
- Local Storage Operator는 Local Storage Operator 버전이 Red Hat OpenShift Container Platform 버전과 일치하는 경우에만 완전히 지원됩니다.
- 유연한 확장 기능은 Red Hat OpenShift Data Foundation 버전 4.7 이상의 새로운 배포에서만 사용할 수 있습니다. 이전 버전에서 버전 4.7 이상으로 업그레이드된 스토리지 클러스터는 유연한 스케일링을 지원하지 않습니다. 자세한 내용은 4.7 릴리스 노트 의 새로운 기능 섹션에서 OpenShift Container Storage 클러스터의 유연한 스케일링 을 참조하십시오.
16.2. Red Hat OpenShift Container Storage 4.8에서 Red Hat OpenShift Data Foundation 4.9로 업데이트
이 장에서는 모든 Red Hat OpenShift Data Foundation 배포(내부, 내부 연결 및 외부)의 z-stream 릴리스를 업그레이드하는 데 도움이 됩니다. 업그레이드 프로세스는 모든 배포에 동일하게 유지됩니다. 유일한 차이점은 업그레이드 된 것과 그렇지 않은 것입니다.
- 내부 및 내부 연결 배포의 경우 OpenShift Container Storage를 업그레이드하면 백엔드 Ceph Storage 클러스터를 비롯한 모든 OpenShift Container Storage 서비스가 업그레이드됩니다.
외부 모드 배포의 경우 OpenShift Container Storage는 OpenShift Container Storage 서비스를 업그레이드하고 백엔드 Ceph 스토리지 클러스터가 그대로 유지되므로 별도로 업그레이드해야 합니다.
새로운 기능 지원, 보안 수정 및 기타 버그 수정을 얻으려면 OpenShift Container Storage와 함께 RHCS를 업그레이드하는 것이 좋습니다. RHCS 업그레이드에 대한 강력한 종속성이 없기 때문에 먼저 OpenShift Data Foundation Operator를 업그레이드한 후 RHCS 업그레이드 또는 그 반대의 경우도 업그레이드할 수 있습니다. Red Hat Ceph Storage 릴리스에 대한 자세한 내용은 솔루션을 참조하십시오.
4.8 이전 버전에서 직접 4.9로 업그레이드할 수 없습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터가 버전 4.9.X의 안정적인 최신 릴리스로 업데이트되었는지 확인합니다. 클러스터 업데이트를 참조하십시오.
OpenShift Container Storage 클러스터가 정상이며 데이터의 복원력이 있는지 확인합니다.
- 스토리지 → 개요 로 이동하여 상태 카드의 녹색 눈금에 대해 블록 및 파일 및 오브젝트 탭을 모두 확인합니다. 녹색 눈금은 스토리지 클러스터,오브젝트 서비스 및 데이터 복원력 이 모두 정상임을 나타냅니다.
Operator 포드를 포함한 모든 OpenShift Container Storage Pod가
openshift-storage네임스페이스에서 Running 상태인지 확인합니다.OpenShift 웹 콘솔에서 Pod 상태를 보려면 워크로드 → Pod 를 클릭합니다. 프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
- 클러스터에서 실행되는 OSD 수에 따라 업데이트 시간이 다르기 때문에 OpenShift Data Foundation 업데이트 프로세스를 완료하는 데 충분한 시간이 있는지 확인합니다.
절차
- OpenShift 웹 콘솔에서 OperatorHub 로 이동합니다.
-
키워드로 필터링 박스를 사용하여
OpenShift Data Foundation을 검색하고 OpenShift Data Foundation 타일을 클릭합니다. - 설치를 클릭합니다.
Operator 설치 페이지에서 설치를 클릭합니다. Operator 설치가 완료될 때까지 기다립니다.
참고모든 기본 설정을 사용하는 것이 좋습니다. 이를 변경하면 예기치 않은 동작이 발생할 수 있습니다. 결과를 알고 있는 경우에만 변경합니다.
검증 단계
Create StorageSystem 에 대한 옵션과 함께 페이지에 Succeeded 메시지가 표시되는지 확인합니다.
참고업그레이드된 클러스터의 경우 스토리지 시스템이 자동으로 생성되므로 다시 생성하지 않습니다.
- 알림 팝업에서 웹 콘솔 새로 고침 링크를 클릭하여 OpenShift 콘솔의 OpenShift Data Foundation 변경 사항을 반영합니다.
OpenShift 웹 콘솔에서 포드 상태를 확인합니다.
- 워크로드 → 포드 를 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
openshift-storage네임스페이스의 모든 포드가 다시 시작되고Running상태가 될 때까지 기다립니다.
OpenShift Data Foundation 클러스터가 정상이고 데이터가 탄력적인지 확인합니다.
- 스토리지 → OpenShift Data foundation → Storage Systems 탭으로 이동한 다음 스토리지 시스템 이름을 클릭합니다.
- 상태 카드에서 Block 및 File 및 Object 탭을 모두 확인합니다. 녹색 눈금은 스토리지 클러스터, 오브젝트 서비스 및 데이터 복원력이 모두 정상임을 나타냅니다.
OpenShift Data Foundation Operator를 설치한 후 콘솔 플러그인 옵션이 자동으로 활성화되지 않은 경우 이를 활성화해야 합니다.
콘솔 플러그인을 활성화하는 방법에 대한 자세한 내용은 Red Hat OpenShift Data Foundation 콘솔 플러그인 활성화를 참조하십시오.
- 외부 모드 배포를 업데이트한 후 외부 시크릿도 업데이트해야 합니다. 자세한 내용은 OpenShift Data Foundation 외부 시크릿 업데이트를 참조하십시오.
추가 리소스
OpenShift Data Foundation을 업데이트하는 동안 문제가 발생하는 경우 문제 해결 가이드 의 일반적으로 필요한 로그를 참조하십시오.
16.3. Red Hat OpenShift Data Foundation 4.9.x에서 4.9.y로 업데이트
이 장에서는 모든 Red Hat OpenShift Data Foundation 배포(내부, 내부 연결 및 외부)의 z-stream 릴리스를 업그레이드하는 데 도움이 됩니다. 업그레이드 프로세스는 모든 배포에 동일하게 유지됩니다. 유일한 차이점은 업그레이드 된 것과 그렇지 않은 것입니다.
- 내부 및 내부 연결 배포의 경우 OpenShift Container Storage를 업그레이드하면 백엔드 Ceph Storage 클러스터를 비롯한 모든 OpenShift Container Storage 서비스가 업그레이드됩니다.
외부 모드 배포의 경우 OpenShift Container Storage는 OpenShift Container Storage 서비스를 업그레이드하고 백엔드 Ceph 스토리지 클러스터가 그대로 유지되므로 별도로 업그레이드해야 합니다.
따라서 새로운 기능 지원, 보안 수정 및 기타 버그 수정을 얻으려면 OpenShift Container Storage와 함께 RHCS를 업그레이드하는 것이 좋습니다. RHCS 업그레이드에 대한 강력한 종속성이 없기 때문에 먼저 OpenShift Data Foundation Operator를 업그레이드한 후 RHCS 업그레이드 또는 그 반대의 경우도 업그레이드할 수 있습니다. Red Hat Ceph Storage 릴리스에 대한 자세한 내용은 솔루션을 참조하십시오.
새 z-stream 릴리스가 사용 가능하게 되면 업데이트 전략이 자동으로 설정된 경우 업그레이드 프로세스가 자동으로 트리거됩니다. 업데이트 전략이 Manual 로 설정된 경우 다음 절차를 사용하십시오.
사전 요구 사항
- OpenShift Container Platform 클러스터가 버전 4.9.X의 안정적인 최신 릴리스로 업데이트되었는지 확인합니다. 클러스터 업데이트를 참조하십시오.
OpenShift Data Foundation 클러스터가 정상이며 데이터의 복원력이 있는지 확인합니다.
- 스토리지 → OpenShift Data Foundation → Storage Systems 탭으로 이동한 다음 스토리지 시스템 이름을 클릭합니다.
- 개요 - 블록 및 파일 및 오브젝트 탭의 상태 카드에서 녹색 눈금을 확인합니다. 녹색 눈금은 스토리지 클러스터, 오브젝트 서비스 및 데이터 복원력이 정상임을 나타냅니다.
Operator 포드를 포함한 모든 OpenShift Data Foundation Pod가
openshift-storage네임스페이스에서 Running 상태인지 확인합니다.OpenShift 웹 콘솔에서 Pod 상태를 보려면 워크로드 → Pod 를 클릭합니다. 프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
- 클러스터에서 실행되는 OSD 수에 따라 업데이트 시간이 다르기 때문에 OpenShift Data Foundation 업데이트 프로세스를 완료하는 데 충분한 시간이 있는지 확인합니다.
절차
- OpenShift 웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
openshift-storage프로젝트를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
- OpenShift Data Foundation Operator 이름을 클릭합니다.
- 서브스크립션 탭을 클릭합니다.
-
업그레이드 상태에
승인이필요한 경우 승인 링크가 필요합니다. - InstallPlan 세부 정보 페이지에서 설치 계획 프리뷰 를 클릭합니다.
- 설치 계획을 검토하고 승인을 클릭합니다.
-
Status가
Unknown에서Created로 변경될 때까지 기다립니다.
검증 단계
OpenShift Data Foundation 이름 아래의 버전 및 Operator 상태가 최신 버전인지 확인합니다.
-
Operators → 설치된 Operators 로 이동하여
openshift-storage프로젝트를 선택합니다. - 업그레이드가 완료되면 OpenShift Data Foundation의 새 버전 번호로 업데이트되고 녹색 틱을 사용하여 성공으로 변경됩니다.
-
Operators → 설치된 Operators 로 이동하여
OpenShift Data Foundation 클러스터가 정상이고 데이터가 탄력적인지 확인합니다.
- 스토리지 → OpenShift Data Foundation → Storage Systems 탭으로 이동한 다음 스토리지 시스템 이름을 클릭합니다.
- 개요 - 블록 및 파일 및 오브젝트 탭의 상태 카드에서 녹색 눈금을 확인합니다. 녹색 눈금은 스토리지 클러스터, 오브젝트 서비스 및 데이터 복원력이 정상임을 나타냅니다.
OpenShift Data Foundation Operator를 설치한 후 콘솔 플러그인 옵션이 자동으로 활성화되지 않은 경우 이를 활성화해야 합니다.
콘솔 플러그인을 활성화하는 방법에 대한 자세한 내용은 Red Hat OpenShift Data Foundation 콘솔 플러그인 활성화를 참조하십시오.
- 확인 단계가 실패하면 Red Hat 지원팀에 문의하십시오.
16.4. 업데이트 승인 전략 변경
동일한 채널에서 새 업데이트를 사용할 수 있을 때 스토리지 시스템이 자동으로 업데이트되도록 하려면 업데이트 승인 전략을 자동으로 유지하는 것이 좋습니다. 업데이트 승인 전략을 Manual 로 변경하면 각 업그레이드에 대한 수동 승인이 필요합니다.
절차
- Operator → 설치된 Operator로 이동합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
- OpenShift Data Foundation Operator 이름을 클릭합니다.
- 서브스크립션 탭으로 이동합니다.
- 업데이트 승인을 변경하려면 연필 아이콘을 클릭합니다.
- 업데이트 승인 전략을 선택하고 저장을 클릭합니다.
검증 단계
- 업데이트 승인에 아래에서 새로 선택한 승인 전략이 표시되는지 확인합니다.