OpenShift Data Foundation 이해
가상 프라이빗 클라우드 클래식 인프라 Satellite
OpenShift Data Foundation은 컨테이너화된 앱의 영구 저장소를 관리하는 데 사용할 수 있는 고가용성 스토리지 솔루션입니다.
- OpenShift Data Foundation은 무엇입니까?
- OpenShift Data Foundation은 여러 오픈 소스 운영자와 Ceph, NooBaa 및 Rook. 이러한 오퍼레이터는 Red Hat® OpenShift® on IBM Cloud® 클러스터에서 컨테이너 워크로드에 대해 파일, 블록, 오브젝트 스토리지를 프로비저닝하고 관리하도록 허용합니다. 각 스토리지 유형에 대해 별도의 드라이버 및 오퍼레이터를 구성해야 할 수 있는 기타 스토리지 솔루션과 달리 ODF는 스토리지 요구사항에 대한 조정 및 스케일링이 가능한 통합 솔루션입니다. OCP 클러스터에서 ODF를 배치할 수도 있습니다.
- OpenShift Data Foundation은 어떻게 작동합니까?
- ODF는 해당 디바이스를 사용하여 가상화된 스토리지 계층을 작성하는데, 여기서 고가용성을 위해 앱 데이터가 복제됩니다. ODF는 기본 스토리지를 나타내므로 ODF를 사용하여 동일한 기본 원시 블록 스토리지에서 파일, 블록 또는 오브젝트 스토리지 청구를 작성할 수 있습니다.
- ODF는 3의 배수의 스토리지 볼륨을 사용하며 해당 볼륨에서 앱 데이터를 복제합니다. ODF에 대해 사용하는 기본 스토리지 볼륨은 클러스터 유형에 따라 다릅니다.
- 가상 머신을 사용하는 VPC 클러스터의 경우, 스토리지 볼륨은 Block Storage for VPC 스토리지 볼륨입니다.
- 베어 메탈 워커를 사용하는 클래식 또는 VPC 클러스터의 경우, 스토리지 볼륨은 베어 메탈 워커 노드에 있는 로컬 디스크입니다.
- Satellite 클러스터의 경우, 스토리지 볼륨은 워커 노드의 로컬 디스크이거나 호환되는 블록 스토리지 드라이버를 사용하여 디스크를 동적으로 프로비저닝할 수 있습니다.
- OpenShift 의 Data Foundation을 개인 전용 VPC 클러스터에 설치할 수 있습니까?
- 네, CoreOS 작업자의 경우 클러스터 버전
4.16.23_1546_openshift부터, RHEL 작업자의 경우4.16.21_1544_openshift부터 개인 전용 VPC 클러스터에 ODF를 설치할 수 있습니다. - Satellite 클러스터에 OpenShift Data Foundation 추가 기능을 설치할 수 있습니까?
- 아니오. 클러스터 추가 기능은 클래식 및 VPC 클러스터에만 사용할 수 있습니다.
- Satellite에 OpenShift Data Foundation을 설치하는 방법은 무엇입니까?
- Satellite 스토리지 템플리트 중 하나를 사용하여 Satellite 에 ODF를 설치할 수 있습니다. 자세한 정보는 Satellite 스토리지 문서 를 참조하십시오.
odf-local: 작업자 노드에 사용 가능한 로컬 스토리지가 있는 경우 이 템플리트를 선택하십시오.lsblk를 실행할 때 스토리지 볼륨이 표시되는 경우, 원시 및 포맷되지 않은 경우 ODF를 배치할 때 이 디스크를 사용할 수 있습니다.odf-remote: 클러스터에 CSI 드라이버가 설치되어 있는 경우 이 템플리트를 선택하십시오. 예를 들어,azuredisk-csi-driver드라이버입니다. ODF를 배치할 때 CSI 드라이버를 사용하여 스토리지 볼륨을 동적으로 프로비저닝할 수 있습니다.
기능 및 이점에 대한 전체 개요는 OpenShift 데이터 기반을 참조하세요.
아키텍처 개요
다음 다이어그램 및 표를 검토하여 OpenShift Data Foundation에 대해 자세히 알아보십시오.
| 숫자 | ODF 구성요소 | 설명 |
|---|---|---|
| 1 | OpenShift Data Foundation 스토리지 클래스 | ODF를 배치하는 경우 ODF 오퍼레이터가 클러스터에서 파일, 블록, 오브젝트 스토리지 클래스를 작성합니다. 앱의 스토리지를 청구하기 위해 및 PVC에서 해당 스토리지 클래스를 참조하십시오. |
| 2 | OSD 블록 스토리지 | 해당 디바이스는 클러스터에서 애플리케이션 스토리지를 제공합니다. 각 OSD는 사용자가 ODF를 배치할 때 동적으로 프로비저닝되거나 작업자 노드에서 로컬 디스크일 수 있는 원시 블록 스토리지 디바이스입니다. VPC 클러스터에서 OSD 블록 스토리지 디바이스는 Block Storage for VPC 드라이버를 사용하여 동적으로 프로비저닝됩니다. Satellite 클러스터에서 작업자 노드의 로컬 볼륨을 사용할 수 있거나 동적
프로비저닝을 지원하는 블록 스토리지 드라이버를 사용하여 블록 스토리지 디바이스를 동적으로 프로비저닝할 수 있습니다. 클래식 클러스터에서 OSD 블록 디바이스는 작업자 노드의 로컬 디스크입니다. ODF를 배치하는 경우 각 디바이스는 OSD 팟(pod)으로 마운트됩니다. 애플리케이션에서 사용 가능한 총 스토리지는 osdSize에 numOfOsd를 곱한 값과 같습니다. |
| 3 | 오브젝트 스토리지 디먼(OSD) 팟(pod) | OSD 팟(pod)은 스토리지 디바이스에서 데이터 배치 및 복제를 관리합니다. |
| 4 | 모니터(Mon) 팟(pod) | 모니터 팟(pod)은 OpenShift Data Foundation 스토리지 클러스터의 맵을 유지하고 스토리지 클러스터 상태를 모니터합니다. |
| 5 | 모니터(Mon) 블록 스토리지 디바이스 | 모니터 스토리지 디바이스는 모니터 팟(pod)의 기본 스토리지 디바이스입니다. 각 모니터 디바이스는 사용자가 ODF를 배치할 때 동적으로 프로비저닝되거나 작업자 노드에서 로컬 디스크일 수 있는 원시 블록 스토리지 디바이스입니다. 각 디바이스는 팟(pod)을 모니터하는 스토리지를 제공합니다. |
다중 클라우드 오브젝트 게이트웨이 개요
멀티클라우드 개체 게이트웨이는 오픈 소스 도구로 구성되어 있으며 NooBaa 로 구성되며 OpenShift Data Foundation의 구성 요소입니다. 다중 클라우드 오브젝트 게이트웨이를 사용하면 클라우드 제공자에서 오브젝트 및 버킷을 관리할 수 있습니다.
| 숫자 | 다중 클라우드 오브젝트 게이트웨이 구성요소 | 설명 |
|---|---|---|
| 1 | 백업 저장소 | 백업 저장소는 s3 호환 가능 오브젝트 스토리지 버킷입니다. 다중 클라우드 오브젝트 게이트웨이에서 백업 저장소는 제공자에 상관없이 클라우드 환경에 있을 수 있습니다. 다중 클라우드 오브젝트 게이트웨이에 여러 백업 저장소를 연결할 수 있습니다. ODF를 배치하는 경우 기본 백업 저장소는 ODF 스토리지 클러스터에 대해 지정하는 원시 블록 스토리지 디바이스를 사용합니다. 그러나 선택적으로 IBM Cloud Object Storage을(를) 기본 백업 저장소로 설정할 수 있습니다. |
| 2 | 버킷 클래스 | 버킷 클래스는 하나 이상의 백업 저장소(버킷) 및 배치 정책으로 구성됩니다. 위치 및 클라우드에서 오브젝트를 관리하도록 백업 저장소 및 배치 정책을 구성할 수 있습니다. |
| 3 | 스토리지 클래스 | 다중 클라우드 오브젝트 게이트웨이의 스토리지 클래스는 스토리지 리소스 매개변수를 정의하는 기타 Kubernetes 스토리지 클래스와 유사합니다. 그러나 다중 클라우드 오브젝트 게이트웨이에서 스토리지 클래스를 작성하는 경우 사용하려는 버킷 클래스를 지정합니다. 버킷 클래스에서 스토리지 클래스를 작성하여 네임스페이스에서 사용 가능한 다중 클라우드 오브젝트 게이트웨이 리소스를 작성할 수 있습니다. |
| 4 | 오브젝트 버킷 청구(OBC) | 오브젝트 버킷 청구(OBC)는 개발자 또는 스토리지 관리자가 OBC를 작성하여 스토리지 리소스를 청구할 수 있는 Kubernetes 지속적 볼륨 청구(PVC)와 유사합니다. OBC를 작성하는 경우 사용하려는 스토리지 클래스를 지정하고 선택적으로 동적으로 작성된 오브젝트 버킷의 이름을 제공합니다. |
| 5 | 시크릿 | 오브젝트 버킷 청구를 작성할 때 Kubernetes 시크릿도 클러스터에 작성됩니다. |
| 6 | ConfigMap | 오브젝트 버킷 청구를 작성할 때 ConfigMap 도 클러스터에 작성됩니다. |
| 7 | 오브젝트 버킷 | 오브젝트 버킷 청구를 작성하는 경우 오브젝트 버킷이 동적으로 프로비저닝됩니다. 오브젝트 버킷은 하나 이상의 백업 저장소를 단일 리소스에 추출합니다. |
| 8 | s3 앱 | 개체 저장소를 사용하는 앱입니다. |
| 9 | 시크릿 참조 | 시크릿 참조는 클러스터에서 Kubernetes 시크릿에 대한 참조입니다. 오브젝트 버킷 청구를 작성하는 경우 NooBaa는 해당 시크릿 및 구성 맵을 작성합니다. 그런 다음 앱에 신임 정보를 직접 포함시키지 않고 앱에서 시크릿 및 구성 맵을 참조할 수 있습니다. |
| 10 | ConfigMap 참조 | 구성 맵 참조는 클러스터의 Kubernetes 구성 맵에 대한 참조입니다. 오브젝트 버킷 청구를 작성할 때 NooBaa는 해당 시크릿 및 구성 맵을 동적으로 작성합니다. 애플리케이션에 해당 신임 정보를 포함시키지 않고 앱에서 시크릿 및 구성 맵을 참조할 수 있습니다. |
| 11 | 네임스페이스 리소스 | 네임스페이스 리소스는 s3 호환 가능 버킷입니다. 네임스페이스 리소스(버킷)를 다중 클라우드 오브젝트 게이트웨이에 추가한 후 하나 이상의 네임스페이스 리소스에서 읽고 쓰는 데 사용할 수 있는 네임스페이스 버킷을 작성하여 해당 버킷을 참조할 수 있습니다. |
| 12 | 네임스페이스 버킷 | 네임스페이스 버킷은 NooBaa 네임스페이스에서 하나 이상의 네임스페이스 리소스를 추출합니다. 네임스페이스 버킷을 작성하는 경우 다중 클라우드 오브젝트 게이트웨이에서 구성한 네임스페이스 리소스에 읽기 또는 쓰기 정책을 지정할 수 있습니다. 예를 들어, 다른 클라우드 제공자의 두 버킷에서 읽어 오고 다른, 별도의 클라우드 환경에 있는 세 번째 버킷에 쓸 수 있습니다. |
| 13 | 네임스페이스 버킷 액세스 키 | 액세스 키는 네임스페이스 버킷에 액세스하는 데 사용됩니다. 네임스페이스 버킷은 다른 클라우드 제공자 또는 온프레미스 버킷의 다중 네임스페이스 리소스를 포함할 수 있습니다. 네임스페이스 버킷 액세스 키 및 시크릿 키는 네임스페이스 버킷에 대한 액세스를 구성하기 위해 s3 앱에서 사용되며 이는 사용자가 구성하는 네임스페이스 리소스에 대한 읽기 및 쓰기 정책을 정의합니다. |
| 14 | 네임스페이스 버킷 시크릿 키 | 시크릿 키는 네임스페이스 버킷을 액세스하는 데 사용됩니다. 네임스페이스 버킷은 다른 클라우드 제공자 또는 온프레미스 버킷의 다중 네임스페이스 리소스를 포함할 수 있습니다. 네임스페이스 버킷 액세스 키 및 시크릿 키는 네임스페이스 버킷에 대한 액세스를 구성하기 위해 s3 앱에서 사용되며 이는 사용자가 구성하는 네임스페이스 리소스에 대한 읽기 및 쓰기 정책을 정의합니다. |
| 15 | 배치 정책 | 버킷 클래스를 작성하는 경우 배치 정책을 지정해야 합니다. 배치 정책은 데이터가 백업 저장소에 작성되는 방법을 정의합니다. 미러 배치 정책은 버킷 클래스의 백업 저장소에서 오브젝트를 미러링하고 스프레드 배치 정책은 버킷 클래스의 백업 저장소에서 오브젝트를 분배합니다. |
청구 유형별 기능 지원
| 기능 지원 | 필수 | 고급 |
|---|---|---|
| 블록 스토리지 | 예 | 예 |
| 파일 스토리지 | 예 | 예 |
| 오브젝트 스토리지 | 예 | 예 |
| Node 및 디스크 복원성 | 예 | 예 |
| 운영자 기반 자동화 | 예 | 예 |
| 압축 | 예 | 예 |
| 로컬 스냅샷 및 복제 | 예 | 예 |
| 기본 클러스터 전체 암호화 | 예 | 예 |
| KMS를 사용한 고급 암호화 | 아니오 | 예 |
| 복제를 사용한 지역 재해 복구 | 아니오 | 예 |
| 확장 클러스터-메트로 고가용성 및 재해 복구 | 아니오 | 예 |
| 다중 클러스터-메트로 고가용성 및 재해 복구 | 아니오 | 예 |
우수 사례
ODF를 설치하고 관리할 때 우수 사례에 대해서는 다음 절을 검토하십시오.
계획
- 워커 노드 배포 계획
- 고가용성을 보장하려면 ODF 클러스터를 장애 도메인에 분산시키십시오. 이 분배는 노드 장애의 영향을 최소화하고 클러스터의 전체적인 안정성을 유지하는 데 도움이 됩니다.
- 최소 작업자 노드 스펙 충족
- ODF를 사용하는 작업자 노드에는 16개의 vCPUs 및 64GB RAM 이상이 있어야 합니다. IBM Classic 클러스터의 경우 권장되는 특징은
mb4c.32x384.3.8tb.ssd이상입니다. - 고가용성을 위해 대기 호스트 유지
- 고가용성을 보장하고 호스트 장애 시 다운타임을 최소화하려면 항상 대기 호스트를 두는 것이 좋습니다.
- 노드당 스토리지 디바이스 수 권장사항 충족
- 노드당 9개미만의 스토리지 디바이스를 사용하도록 계획하십시오. 이는 잠재적인 병목 현상을 방지하고 데이터 액세스 및 검색의 효율성을 향상시키는 데 도움이 됩니다.
- 권장되는 스토리지 디바이스 크기 및 개수 사용
- 로컬 스토리지를 배치할 때 4 TiB 이하의 디스크 크기를 사용하십시오. 모든 스토리지 노드에서 클러스터 내의 모든 디스크가 스토리지의 최적 사용을 위해 동일한 크기 및 유형인지 확인하는 것이 중요합니다. 최소 512Gi OSD를 사용합니다.
- 기본 복제 요소 및 스토리지 노드 구성을 사용하여 확장
- OpenShift Data Foundation (ODF) 에서 복제 요소는 기본적으로 3으로 설정됩니다. 용량을 추가할 때 스토리지 노드를 3의 배수로 추가하도록 계획하십시오.
- 필요에 맞는 올바른 설정 선택: 원격 스토리지 대 로컬 스토리지
- 스토리지 요구사항이 적거나 가상 서버 인스턴스를 사용하는 경우 원격 스토리지는 편리하고 비용 효율적인 옵션이 될 수 있습니다. 그러나 대규모 스토리지가 필요한 경우, 베어 메탈 클러스터 또는 네트워크 지연 시간이 짧은 고성능 스토리지를 사용하는 로컬 스토리지가 더 적합할 수 있습니다.
- 자동 검색 기능을 사용하여 배포를 간소화하세요
- 클래식 또는 로컬 스토리지가 있는 환경에서는 자동 검색 기능을 활용하여 클러스터에서 사용 가능한 스토리지 디스크를 자동으로 식별하고 ODF를 구성할 수 있습니다. 이 옵션을 사용하면 수동으로 디스크를 선택할 필요가 없습니다. ODF 프로비저닝에 대한 특정 디스크 요구사항이 없는 경우 자동 발견 기능을 활용하면 배치 프로세스가 능률화되고 구성 오류의 가능성이 줄어듭니다.
- 원격 스토리지의 ODF 설치에 메트로 스토리지 클래스 사용
- 원격 스토리지를 사용하는 ODF 설치를 수행할 때 이 스토리지를 사용하는 첫 번째 팟 (Pod) 이 스케줄될 준비가 될 때까지 Block Storage 작성을 지연시키는
WaitForFirstConsumer의VolumeBindingMode가 있는 스토리지 클래스를 사용해야 합니다. - 배치 크기 조정
- 스토리지 요구사항에 대한 자세한 분석을 위해 크기 조정 도구 를 사용하여 필요한 스토리지 용량을 판별하십시오. 공식 Red Hat 사이징 도구 를 사용할 수도 있습니다.
- 주기적 백업 설정
- 데이터 보호를 보장하고 재해 발생 시 데이터 복구를 용이하게 하려면 ODF 클러스터를 주기적으로 백업하는 것이 필수적입니다. 정기적인 백업이 없으면 치명적인 이벤트에서 데이터를 복구하는 것이 훨씬 더 어려워지고 영구적인 데이터 손실로 이어질 수 있습니다.
배치
- 전용 스토리지 노드 사용 계획
- 워크로드가 많은 시나리오에서는 ODF에 전용 스토리지 노드를 사용하십시오. 스토리지 노드의 조작을 분리하여 스토리지 인프라의 성능과 확장성을 향상시킬 수 있습니다.
- Red Hat 콘솔의 일반 모니터링 설정
- Red Hat 콘솔은 ODF 환경의 상태와 성능에 대한 귀중한 인사이트를 제공합니다. 콘솔을 정기적으로 모니터하여 잠재적인 문제에 대한 정보를 얻는 것이 좋습니다. 콘솔은 ODF에서 문제점이 발견될 때마다 경보를 트리거하여 사용자가 사전 조치를 취할 수 있도록 합니다.
- 용량 경고를 신속하게 처리
- 용량 경고가 발행되면 이를 신속하게 처리하는 것이 중요합니다. 이러한 경고에 대한 조치를 무시하거나 지연하면 스토리지 용량 제한조건 및 워크로드에 대한 잠재적인 중단을 초래할 수 있습니다. 용량 경고를 스토리지 요구사항을 평가하고 적절한 조치를 수행하여 잠재적인 문제를 완화할 수 있는 기회로 처리하십시오.
용량 확장
- 용량 확장을 위한 옵션 이해
- ODF에서 용량 확장에 사용할 수 있는 두 가지 옵션이 있습니다. 첫 번째 옵션에는 클러스터 내의 기존 노드에서 더 많은 OSD (Object Storage Daemons) 를 추가하여 용량을 늘리는 것이 포함됩니다. 이를 통해 사용 가능한 자원을 활용하여 스토리지 용량을 확장할 수 있습니다. 두 번째 옵션은 클러스터에 새 노드를 추가하여 용량을 확장하는 것입니다. OSD의 수가 증가하면 새로 추가된 노드에서 OSD가 자동으로 프로비저닝됩니다.
업데이트
- 노드를 바꾸는 상태 검사 수행
- ODF가 정상 상태가 아닌 경우 스토리지 노드를 바꾸지 마십시오. 노드 대체를 진행하기 전에 항상 ODF의 상태를 확인하십시오. 비정상 노드를 교체하기 전에 문제를 해결하십시오.
- 환경을 최신 상태로 유지
- 클러스터 버전을 사용 가능한 기본 버전 또는 최신 버전으로 업데이트하십시오. 클러스터 버전을 최신 상태로 유지하면 최신 기능을 활용하고 사용자 환경의 다른 컴포넌트와의 호환성을 유지할 수 있습니다.
- 클러스터 업그레이드 후 ODF 갱신 수행
- 항상 클러스터 마스터 및 작업자 노드를 먼저 업그레이드한 후 ODF 업그레이드를 위해 이동하십시오. 클러스터 업그레이드를 완료한 후에는 ODF도 업데이트해야 합니다. ODF가 현재 클러스터 버전 (n) 및 다음 클러스터 버전 (n+1) 을 모두 지원하더라도 ODF 버전을 클러스터 버전과 동일하게 유지하십시오. 이 정렬은 최적의 호환성을 보장합니다.
- 순차적으로 스토리지 노드 업그레이드
- 스토리지 노드를 업그레이드할 때 하나씩 업그레이드를 수행하는 것이 좋습니다. 이 순차적 접근 방식을 사용하면 각 노드를 업그레이드한 후 ODF의 상태를 확인하고 스토리지 인프라가 프로세스 전체에서 양호한 상태를 유지하는지 확인할 수 있습니다. 노드를 개별적으로 업그레이드하면 ODF에 대한 각 업그레이드의 영향을 자세히 모니터하고 발생할 수 있는 문제를 신속하게 식별하여 해결할 수 있습니다.
복구
- 양호하지 않은 호스트 대체
- 로컬 재해가 발생한 경우, 건강하지 않은 클러스터 호스트를 건강한 클러스터 호스트로 교체하는 것이 좋습니다.
- 문서에 따라 OSD를 복구하십시오.
- OSD (Object Storage 디먼) 가 OpenShift Data Foundation (ODF) 에서 작동 중지되면 복구를 위해 권장되는 단계를 따르는 것이 중요합니다. IBM Cloud Platform에서 제공되는 문서는 이러한 상황에서 OSD를 복구하는 방법에 대한 자세한 지시사항을 제공합니다.
설치 제거 및 제거
- 팟 (Pod) 및 지속적 볼륨 (PV) 삭제
- ODF 스토리지 클래스를 사용하는 리소스를 삭제할 때는 권장 절차를 따르는 것이 중요합니다. 다른 자원의 삭제를 진행하기 전에 OF 스토리지 클래스를 사용하여 작성된 연관된 팟 (Pod) 및 PV를 항상 삭제하십시오.
- 올바른 정리 순서를 따르십시오.
- 클러스터에서 ODF를 해제하거나 제거할 때 자원을 정리할 때 문서를 따라야 합니다. ODF 관리를 담당하는
ocscluster자원을 삭제하여 시작하십시오.ocscluster자원이 제거되면 IBM 콘솔에서 ODF 추가 기능을 제거하십시오. 이 순서를 따르면 클러스터에서 ODF를 매끄럽고 적절하게 제거하여 잠재적인 문제나 충돌을 방지할 수 있습니다.
문제점 해결
- 용량 경보 및 임계값 검토
- ODF는 클러스터 스토리지 용량이 특정 임계값에 도달할 때 용량 경보를 생성합니다. 이러한 임계값은 총 용량의 75% (거의 가득 참) 및 85% (가득 참) 로 설정됩니다. 이러한 경보는 스토리지 용량이 한계에 근접하여 주의가 필요함을 표시합니다.
- 공통 문제 검토
- OpenShift Data Foundation (ODF) 에 문제가 발생하면 공통 문제점 해결에 대한 지침을 제공하는 사용 가능한 Runbook을 참조하는 것이 유용합니다. Runbook에는 ODF에 대한 알려진 문제 및 해당 솔루션의 포괄적인 목록이 포함되어 있습니다.
OpenShift Data Foundation 배치
인프라 제공자의 배치 옵션을 검토하십시오.
- VPC(Virtual Private Cloud) 클러스터
- 동적 프로비저닝( Block Storage for VPC )을 사용하거나 베어메탈 워커에서 로컬 디스크를 사용하여 ODF를 배포할 수 있습니다. 자세한 정보는 VPC 클러스터에서 OpenShift Data Foundation 배치를 참조하십시오.
- Satellite 클러스터
- Satellite 클러스터에 ODF를 배포하려는 경우 Satellite 스토리지 템플릿을 사용할 수 있습니다. 자세한 정보는 다음 링크를 참조하십시오.
- 원격, 동적으로 프로비저닝된 디스크에 대해 OpenShift Data Foundation 템플리트 배치.
- 로컬 디스크에 대해 OpenShift Data Foundation 템플리트 배치.
- 클래식 클러스터
- 베어메탈 작업자 노드에서 로컬 디스크를 사용하여 ODF를 배치할 수 있습니다. 자세한 정보는 클래식 클러스터에서 OpenShift Data Foundation 배치를 참조하십시오.