복제된 풀(기본값)

기본 ODF 구성에서는 3방향 복제를 사용합니다. 모든 데이터는 서로 다른 노드에 3개의 복사본으로 저장되며, 최대 2개의 디스크 또는 노드가 동시에 고장 나더라도 데이터를 보호합니다.

• 장점: 간단한 아키텍처, 빠른 읽기 성능, 빠른 복구, 예측 가능한 지연 시간.
• 사용량 증가: 사용 가능한 데이터 1바이트당 3x 원시 저장 공간.

사본을 분실하면 어떻게 되나요 ( rep3 ):

min_size 매개변수는 Ceph가 I/O를 허용하기 전에 사용할 수 있어야 하는 최소 복사본 수를 제어합니다. ODF는 기본적으로 rep3 풀에 대해 min_size=2 를 설정하며, 이는 requireSafeReplicaSize: true 을 통해 적용됩니다. 즉, 2개 또는 3개의 복사본이 사용 가능한 경우 읽기 및 쓰기 작업이 정상적으로 진행됩니다. 사용 가능한 복사본이 1개뿐일 경우, Ceph는 추가적인 데이터 불일치를 방지하기 위해 I/O를 차단합니다.

이러한 동작은 가용성보다 데이터 무결성을 우선시하는 의도적인 안전 장치입니다.

두 번째 사본을 잃은 시점부터 재복제가 완료될 때까지의 기간이 가장 위험합니다. 이 기간 동안 세 번째 장애가 발생하면 영구적인 데이터 손실이 발생합니다. Ceph의 재복제 속도는 사용 가능한 클러스터 대역폭과 여유 공간에 따라 달라지기 때문에, 용량 계획이 중요한 것입니다. 과부하가 걸리거나 거의 가득 찬 클러스터는 재복제하는 데 더 오랜 시간이 걸리므로, 취약한 상태가 지속되는 기간이 길어집니다.

rep2 풀의 경우, 진행 속도가 더 빠릅니다. 사본 1개를 분실하면 사본 1개만 남습니다. min_size=2 (기본값)을 사용하면, 누락된 OSD가 복구되거나 새 사본이 복제될 때까지 해당 PG의 I/O가 즉시 차단됩니다. min_size=1 를 사용하면, 남아 있는 단일 사본에서 I/O 처리가 계속되지만, 두 번째 장애가 발생하면 데이터가 영구적으로 손실됩니다.

Red Hat OpenShift ( Kubernetes Service ) ODF 애드온은 ocs-storagecluster-cephblockpool 을 사용하여 rep3 풀만 자동으로 생성합니다. Rep2 풀은 애드온에 의해 생성되지 않습니다. replicated.size: 2 를 사용하여 사용자 지정 CephBlockPool 를 수동으로 생성하고, 이에 대응하는 StorageClass 도 함께 생성해야 합니다. 자세한 내용은 ‘가상화를 위한 사용자 지정 StorageClass 만들기’를 참조하십시오.

rep2 는 rep3 보다 내결함성이 낮으므로, 스토리지 비용 절감 효과가 해당 워크로드에 대한 증가된 위험을 상쇄할 만큼 충분한지 평가해야 합니다.

IBM 가용성과 데이터 내구성을 보장하기 위해 모든 프로덕션 가상화 워크로드에 3-way 복제를 권장합니다.

삭제 코드 풀

스토리지 용량 효율성이 우선시되는 환경을 위해 ODF는 삭제 코드(EC) 풀도 지원합니다. EC는 데이터를 k 데이터 청크와 m 패리티 청크로 분할하여, 복제 방식에 비해 원시 저장 공간 사용량을 줄이면서도 여전히 내결함성을 보장합니다.

지원 현황: ODF의 RBD 및 CephFS 에 대한 지우기 코딩(Erasure coding)은 개발자 미리 보기 기능으로, ODF에서 처음 도입되었습니다. 4.20. 개발자 미리보기 기능은 실제 운영 환경에서 지원되지 않습니다. 또한 이 사항들은 Red Hat 고객 포털의 사례 관리 대상에도 포함되지 않습니다. ODF 4.20 이전에는 RGW(오브젝트 스토리지) EC만이 개발자 프리뷰(ODF 4.16 ) 형태로 제공되었습니다. 기본 Ceph 스토리지 엔진은 Luminous 릴리즈(2017) 이후 RBD에 대한 EC 덮어쓰기를 지원하지만, ODF 운영자와 관리형 배포 모델은 아직 프로덕션 블록 스토리지 워크로드에 대한 EC 풀을 인증하지 않습니다. 모든 프로덕션 VM 스토리지에는 복제 풀( rep2 또는 rep3 )을 사용할 계획을 세우고, 개발자 프리뷰의 제한 사항이 허용 가능한 비프로덕션 환경에서만 EC 풀을 검토하십시오.

다음 표는 참고를 위해 사용 가능한 모든 풀 유형을 비교한 것입니다.

다음 목록은 지우기 코딩에 있어 고려해야 할 주요 사항들을 보여줍니다.

• EC 풀은 패리티 계산과 작업당 더 많은 청크를 기록해야 하기 때문에, 복제 풀보다 쓰기 지연 시간이 더 깁니다.
• EC 풀은 경쟁력 있는 순차 읽기 처리량을 제공하지만 랜덤 쓰기 IOPS가 감소할 수 있습니다.
• 오류 도메인의 수는 최소한 k+m개여야 합니다. 3노드 클러스터에서는 rep2, rep3, ec-2-1 만 가능합니다.
• 6노드 클러스터의 경우, 앞서 나열된 모든 풀 유형을 사용할 수 있습니다.

단일 리플리카 풀 (개발 및 테스트용으로만 사용되며, 내결함성이 없음)

ODF 애드온 버전 4.14, Red Hat OpenShift Kubernetes Service 는 addSingleReplicaPool 매개변수를 통해 단일 복제본( rep1 ) 풀을 지원합니다. 이 매개변수는 데이터 복제가 없으며, 각 데이터 블록이 한 번만 저장되는 Ceph 비복원형 블록 풀을 생성합니다.

ODF를 배포할 때 단일 리플리카 풀을 활성화하려면 다음 명령을 사용하십시오

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

이 명령은 추가적인 StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd: WaitForFirstConsumer 볼륨 바인딩이 있는 단일 복제본 블록 스토리지.

이 기능을 사용하면 여전히 표준 replica-3 풀(ocs-storagecluster-cephblockpool)이 생성됩니다. 비복구형 풀은 별도의 옵트인 옵션입니다.

단일 레플리카 풀에는 다음과 같은 사용 사례가 있습니다.

• 개발 및 테스트 환경 - 데이터 내구성이 중요하지 않고 스토리지 비용 절감이 우선시되는 경우.
• 내장형 복제 기능을 갖춘 애플리케이션 - 이러한 애플리케이션은 애플리케이션 계층에서 자체적으로 데이터 중복성을 관리합니다. 이러한 애플리케이션은 노드 간에 여러 개의 복사본을 유지하므로, 스토리지 수준의 복제는 중복됩니다.

단일 복제본 풀은 제로 장애 허용 오차를 제공합니다. 하나의 OSD 또는 노드에 장애가 발생하면 해당 OSD의 모든 데이터는 영구적으로 복구할 수 없는 데이터 손실이 발생합니다. IBM Cloud 문서에서는 이 옵션이 데이터 손실, 데이터 손상 및 잠재적인 시스템 불안정의 위험을 증가시킨다고 명시적으로 경고하고 있습니다. 자세한 내용은 Ceph 문서를 참조하세요.

제한사항:

• 블록 스토리지 전용: 파일 스토리지는 단일 복제본으로는 지원되지 않습니다.
• 추가 디스크 필요: ‘ replica-3 ’ 풀에서 사용하는 디스크 외에 노드당 최소 한 개의 추가 사용 가능한 NVMe 디스크가 필요합니다. 이 추가 디스크가 없으면 replica-1 OSD가 시작되지 않고 스토리지 클러스터가 진행 중인 상태로 유지됩니다.
• 장애 도메인당 하나의 풀: ODF는 장애 도메인당 하나의 비복원성 CephBlockPool 을 생성하며, 이 볼륨은 WaitForFirstConsumer 을 사용하여 바인딩하여 데이터 로캘리티를 확인합니다.
• 가상 머신 워크로드 루트 디스크에는 권장되지 않습니다: 루트 디스크를 호스팅하는 OSD에 장애가 발생하면 가상 머신 워크로드가 영구적으로 손실됩니다. 개발 또는 테스트 가상 머신 워크로드에서 일회용 데이터 디스크에만 비복원성 풀을 사용하세요.

프로덕션 가상화 워크로드의 경우, 항상 replica-3 (또는 최소한 replica-2 ) 풀을 사용하십시오.

VMware vSAN 마이그레이션 비교

VMware ( vSAN™ )에서 마이그레이션하는 팀의 경우, 이러한 Ceph 풀 유형은 익숙한 vSAN 스토리지 정책과 다음과 같이 대응됩니다:

다음과 주요 차이점 vSAN:

• 더 작은 호스트 최소값: Ceph는 클러스터 쿼럼과 데이터 배치를 분리합니다. rep3 풀은 각 호스트가 하나의 전체 사본을 저장하기 때문에 호스트 3대만 있으면 됩니다. vSAN RAID-1 FTT=2 는 호스트 5대가 필요합니다.
• rep2 표준 vSAN RAID-1: 과 일치합니다. 대부분의 vSAN 배포 환경에서는 FTT=1 을 사용하며, 여기에는 2개의 사본이 저장됩니다. Ceph의 rep2 가 이에 직접적으로 해당합니다.
• ec-3-1 vSAN 및 와 일치합니다. 두 경우 모두 3+1 레이아웃을 사용하며, 단일 고장 허용 능력에 있어 가장 공간 효율적인 옵션인 사용량을 달성합니다. RAID-5: 1.33x
• ec-4-2 vSAN 및 와 일치합니다. 두 제품 모두 4+2 레이아웃을 사용하며, 이중 고장 내성을 갖춘 사용량을 달성합니다. RAID-6: 1.5x
• ec-2-1 또한 ‘ ec-2-2 ’에는 ‘ vSAN ’에 해당하는 직접적인 개념이 없습니다. 데이터 청크 수가 더 적은 소규모 Ceph EC 구성으로, 바이트당 사용량은 더 많지만 필요한 호스트 수는 더 적습니다. 저장 효율성을 희생하는 대신 호스트 수를 줄일 수 있습니다.

계획 용량

ODF 클러스터를 계획할 때는 선택한 데이터 보호 정책에 따른 원시 스토리지 사용량을 고려해야 합니다. 사용 가능한 용량은 총 원시 NVMe 용량보다 적습니다.

사용 가능한 용량 공식은 Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor 입니다.

노드당 8개의 3.2 TB NVMe 드라이브가 있는 3노드 클러스터의 다음 계산 예시( 76.8 TB 원시 합계)를 참조하세요:

가상 머신 워크로드 용량 추정: 30GB 루트 디스크와 100GB 데이터 디스크가 있는 일반적인 가상 머신 워크로드는 130GB의 사용 가능한 스토리지를 사용합니다. rep3 을 사용하면 해당 가상 머신 워크로드에 390 GB의 원시 저장 공간이 필요합니다. 앞서 언급한 3노드 클러스터에서는 이 규모의 가상 머신 워크로드를 약 196개 정도 프로비저닝할 수 있습니다. 실제로는 성능을 유지하고 복구 작업을 지원하려면 Ceph 사용량을 75% 미만으로 유지하세요.

클러스터 사용량이 증가하면 Ceph 성능이 저하됩니다. ODF는 어떤 OSD의 사용률이 75%를 초과할 경우 ‘ CephOSDNearFull ’ Prometheus 경보를 발령합니다. 85%에 도달하면 Ceph는 네이티브 nearfull OSD 플래그(mon_osd_nearfull_ratio)를 설정하고, ODF는 CephOSDCriticallyFull 경보를 발령합니다. 90%에 도달하면 Ceph는 영향을 받은 OSD에 대한 백필 및 복구 작업을 중지합니다(mon_osd_backfillfull_ratio). 95%에 도달하면 Ceph는 해당 OSD를 full 로 표시하고(mon_osd_full_ratio), 모든 쓰기 작업을 차단하며, HEALTH_ERR 를 발생시킵니다. 정상 운영 시 사용률이 70% 미만으로 유지되도록 용량을 계획하여, 노드 유지보수 또는 장애 발생 시 데이터 복구 및 재조정 작업을 수행할 수 있는 여유 용량을 확보하십시오.

현재 클러스터 사용량을 확인하려면 다음 명령어를 실행하십시오:

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

워커 노드 수 및 토폴로지

IBM Cloud 의 ODF 애드온에서 사용하는 장애 도메인 토폴로지는 클러스터 구성에 따라 달라집니다:

• 다중 가용 영역 클러스터(가용 영역 3개): 장애 도메인은 zone 로 설정되어 있습니다. 워커 노드는 여러 존에 분산되어 있으며, 존 간의 균형을 유지하기 위해 ODF는 3의 배수로 확장되어야 합니다. 가용성, 성능 및 데이터 보안을 최적화하려면 ODF 스토리지 클러스터에 3개, 6개 또는 9개의 노드를 사용하십시오. 각 구역에는 동일한 수의 노드가 할당됩니다.
• 단일 가용 영역 클러스터 또는 가용 영역이 3개 미만인 클러스터: 유연한 확장이 자동으로 활성화되며, 장애 도메인은 ‘ host ’로 설정됩니다. 노드 3개로 시작하여 한 번에 하나씩 노드를 추가할 수 있습니다.

ODF 스토리지 클러스터에 참여하는 모든 노드는 베어메탈이어야 합니다. 동일한 ODF 클러스터 내에서 가상화된 노드와 베어메탈 노드를 혼합하는 것은 지원되지 않습니다.

다중 구역 클러스터의 경우: 3의 배수가 아닌 개수의 노드를 추가하면 구역 간 불균형이 발생합니다. 노드가 4개인 경우, 한 구역에는 노드가 2개 배정되고 나머지 구역에는 각각 1개씩 배정되므로, OSD 가중치 분배가 불균형해지고, 데이터 배치 효율이 떨어지며, 사용량이 고르지 않게 분산되고, 일부 OSD는 유휴 상태가 됩니다.

다중 영역 클러스터의 경우, 균형 잡힌 영역 토폴로지를 유지하기 위해 항상 3의 배수로 확장해야 합니다.

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

ODF 구독 요금제

귀하의 요구 사항에 가장 적합한 요금제를 선택하세요:

• 필수

  • 비용 절감
  • 내부 모드 배포 전용
  • 재해 복구, 스트레치 클러스터 또는 외부 모드 배포를 지원하지 않습니다
  • 테스트 및 개발 환경, 개념 검증(PoC) 또는 소규모 배포에 가장 적합합니다

• 고급

  • 재해 복구, 스트레치 클러스터, 외부 모드 배포, 고급 세분화된 암호화, 다중 클러스터 지원을 포함한 포괄적인 기능 세트
  • 가상 머신을 사용하는 프로덕션 가상화 워크로드에 권장됩니다

두 플랜 모두 블록 풀에 대한 BlueStore 압축, 씬 프로비저닝, 스냅샷 및 복제 기능을 포함합니다. 각 플랜 간의 차이점은 스토리지 효율성 기능보다는 재해 복구, 암호화 세분화 수준, 배포 유연성과 관련이 있습니다.

ODF는 MCG(멀티클라우드 오브젝트 게이트웨이)를 통한 오브젝트 스토리지에 대해서만 중복 제거를 지원합니다. 블록 스토리지는 중복 제거를 지원하지 않습니다. 이 지원은 Essentials 요금제와 Advanced 요금제 모두에 적용됩니다. RBD를 위한 업스트림 Ceph 중복 제거는 아직 실험 단계이며 ODF에서 사용하도록 인증되지 않았습니다.

자세한 내용은 ‘ODF 기초’와 ‘ODF 심화’를 참조하십시오.

스토리지 유형

• 로컬 저장소를 선택합니다.
• 로컬 스토리지는 베어메탈 워커 노드에서 사용 가능한 로컬 NVMe 인스턴스 스토리지를 사용합니다.
• NVMe 드라이브는 가상 머신 워크로드 디스크에 필요한 낮은 지연 시간과 높은 IOPS 성능을 제공합니다.

ODF 리소스 프로필

ODF는 Ceph 데몬을 위해 예약된 CPU와 메모리를 제어하는 세 가지 리소스 할당 프로필을 제공합니다.

• 린: 최소한의 리소스 할당. Lean 프로필은 리소스가 제한된 환경, 테스트, 개발 및 개념 증명에 적합합니다. Lean은 생산 환경의 가상화 워크로드에는 권장되지 않습니다.
• 균형 잡힌: Red Hat OpenShift Kubernetes Service 의 기본 프로필입니다. 균형 잡힌 프로필은 범용 워크로드를 위한 리소스 소비와 성능 간의 균형을 제공합니다.
• 성능: Ceph 데몬에 더 많은 CPU와 메모리를 할당하여 데몬 측 병목 현상의 위험을 줄입니다. 높은 IOPS를 요구하는 워크로드, 대량의 가상 서버, 그리고 고성능이 필요한 애플리케이션에 가장 적합합니다.

로컬 NVMe 드라이브를 사용하는 베어메탈 배포의 경우, ‘성능 ’ 리소스 프로필을 사용하십시오. 노드당 8개 이상의 NVMe 드라이브를 갖춘 베어메탈 노드는 호스트당 OSD 수가 많아지게 됩니다. 'Balanced' 프로필을 사용할 경우, 기본 NVMe 하드웨어가 포화 상태에 이르기도 전에 Ceph 데몬의 CPU 및 메모리 한도에 먼저 도달하는 경우가 많으며, 이로 인해 IOPS가 제한되고 지연 시간이 증가합니다. ‘성능’ 프로필은 베어메탈 환경에서 Red Hat OpenShift 가상화 워크로드를 운영할 때 권장되는 최소 프로필입니다.

ODF 설치 중 Red Hat OpenShift 웹 콘솔에 표시되는 리소스 요구 사항은 클러스터 OSD 수에 따라 동적으로 계산됩니다. 따라서 NVMe 드라이브가 더 많은 클러스터일수록 그에 비례하여 더 많은 리소스가 필요합니다. 값은 고정되어 있지 않습니다. 특정 클러스터 구성에 대해 콘솔에 표시되는 요구 사항을 항상 확인하세요.

프로필은 Red Hat OpenShift 웹 콘솔의 성능 구성 화면을 통해 StorageSystem 생성 시 선택됩니다. 리소스가 부족하게 할당된 Ceph 데몬은 숨겨진 병목 현상이 되어, 기본 스토리지 하드웨어가 제공할 수 있는 수준보다 IOPS가 감소하거나 지연 시간이 증가할 수 있습니다.

베어 메탈 서버 프로필을 선택한 프로필에 표시된 리소스 요구 사항에 맞출 수 있습니다: IBM Cloud VPC 베어 메탈 서버 프로파일.

베어메탈 서버에서는 약간의 리소스 초과 구독이 허용되는 경우가 많습니다. 단, 표시된 최소 요구 사항보다 훨씬 적은 용량을 할당해서는 안 됩니다. 그렇게 할 경우 ODF의 성능과 안정성이 저하됩니다.

노드당 OSD 디스크 수

• 각 베어 메탈 서버에서 사용 가능한 로컬 NVMe 드라이브의 수를 확인하십시오.
• 노드당 구성된 OSD의 수가 사용 가능한 NVMe 드라이브의 수를 초과하지 않도록 하십시오.
• 최적의 성능과 장애 격리를 위해 NVMe 드라이브당 OSD 1개를 사용하는 것이 권장됩니다.
• 일반적으로 OSD 디스크의 개수가 베어 메탈 노드당 NVMe 드라이브의 개수와 일치하도록 해야 합니다. UI에 표시되는 저장 용량 계산값은 로컬 저장소 구성의 실제 사용 가능 용량을 반영하지 않으므로 무시해도 됩니다.

StorageSystem 을 생성할 때 노드를 선택할 때는 클러스터 내의 모든 노드를 선택하지 않도록 하십시오. 모든 노드를 선택하면 nodeSelector 가 없는 LVS( LocalVolumeSet )가 생성됩니다. 향후 클러스터에 추가되는 모든 워커 노드는, 비록 스토리지 용도로 설계되지 않았더라도 ODF에 의해 자동으로 감지됩니다. 예기치 않게 감지된 노드는 LVS에서 수동으로 제거해야 합니다. 이를 방지하려면 전용 스토리지 워커 풀에 속한 노드만 선택하거나, StorageSystem를 생성하기 전에 해당 노드에 cluster.ocs.openshift.io/openshift-storage 레이블이 부여되어 있는지 확인하십시오.

클러스터의 기본값 StorageClass

ODF가 배포된 후에는 일반적으로 다음의 followingStorageClasses 파일이 생성됩니다:

• ocs-storagecluster-ceph-rbd: 블록 스토리지
• ocs-storagecluster-cephfs: 파일 저장소
• ocs-storagecluster-ceph-rgw: 개체 스토리지

워크로드가 별도의 구성 없이도 ODF 기반의 고성능 영구 블록 스토리지를 자동으로 사용할 수 있도록 하려면, ODF 애드온을 설치한 후 기본 스토리지 클래스로 ‘ Ceph RADOS 블록 장치(RBD) 사용 ’를 선택하거나, 클러스터의 기본 StorageClass 로 ‘ RBD ’ (ocs-storagecluster-ceph-rbd)을 수동으로 설정하십시오.

1. RBD를 기본값으로 표시합니다:

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. 필요한 경우, 이전에 설정된 기본값에서 ‘default’를 제거하십시오:

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

ODF 구성 체크리스트

• 클러스터에 하나 이상의 베어메탈 서버 풀이 포함되어 있습니다
• Red Hat OpenShift 4.17 이상 버전
• ODF 애드온 및 운영자가 설치되어 실행 중입니다
• 베어 메탈 서버에는 사용 가능한 로컬 NVMe 드라이브가 충분합니다
• 선택한 리소스 프로필이 노드 용량과 일치합니다
• ODF 스토리지 클러스터는 최소 3개의 노드를 사용하며, 다중 구역 클러스터의 경우 3의 배수(3, 6, 9, …)를 사용해야 합니다 구역 균형을 유지하기 위해
• 모든 ODF 참여 노드는 베어메탈입니다
• RBD StorageClass 가 생성되고 기본값으로 설정되는 것이 좋습니다
• ODF 클러스터 상태는 ‘Ready’입니다 (oc get storagecluster -n openshift-storage)
• Ceph 상태는 HEALTH_OK입니다 (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

필수 조건: Red Hat OpenShift 가상화 오퍼레이터를 설치하십시오

IBM Cloud 에서 Red Hat OpenShift 가상화 기능을 사용하기 전에, Red Hat OpenShift Kubernetes Service 클러스터에 Red Hat OpenShift 가상화 운영자가 설치되어 있는지 확인하십시오.

Red Hat OpenShift 가상화 운영자는 Kubernetes 네이티브 가상 머신 워크로드 관리를 지원합니다. 또한 필요한 컨트롤러, CRD, 스토리지 및 네트워킹 구성 요소와의 통합을 제공합니다.

자세한 내용은 IBM Cloud 에서 Red Hat OpenShift 가상화를 참조하세요.

가상 머신 워크로드에 ODF 스토리지 사용

Red Hat OpenShift Data Foundation(ODF)은 Red Hat OpenShift 에서 실행되는 가상화 워크로드를 위한 영구적인 소프트웨어 정의 스토리지를 제공합니다. 가상 머신의 스토리지 백엔드로 ODF를 사용할 경우, 성능과 안정성을 보장하고 모든 기능을 완벽하게 호환시키려면 올바른 ‘ StorageClass ’를 선택하는 것이 매우 중요합니다.

다음과 같은 상황에서는 적절한 StorageClass 를 지정해야 합니다:

• 가상 서버가 생성됩니다
• 가상 서버를 가져오거나 복제합니다
• 가상 서버가 Red Hat OpenShift Kubernetes Service 클러스터로 마이그레이션됩니다

기본 가상화 StorageClass

Red Hat OpenShift 가상화 오퍼레이터가 설치되고 ODF 클러스터가 사용 가능한 경우, 가상화 워크로드에 최적화된 StorageClass 가 자동으로 생성됩니다:

• ocs-storagecluster-ceph-rbd-virtualization

이 StorageClass 입니다:

• 랜덤 읽기, 쓰기 및 지속적인 처리량과 같은 디스크 I/O 패턴에 맞게 조정됨
• 시작, 중지, 라이브 마이그레이션 및 스냅샷과 같은 가상화 수명 주기 작업에 대해 검증되었습니다
• 프로덕션 환경에서 완벽하게 지원 및 권장 Red Hat OpenShift 가상화 환경

대부분의 사용 사례에서는 수정 없이 StorageClass 을 사용하세요.

라이브 마이그레이션 스토리지 요구 사항

라이브 마이그레이션은 실행 중인 가상 머신 워크로드를 다운타임 없이 한 워커 노드에서 다른 워커 노드로 이동합니다. 성공적인 라이브 마이그레이션을 위해서는 소스 노드와 대상 노드 모두에서 동시에 스토리지에 액세스할 수 있어야 합니다. 라이브 마이그레이션을 수행하려면 다음 설정이 필요합니다.

• ReadWriteMany 가상 머신 워크로드 PVC의 액세스 모드를 설정합니다. Ceph RBD는 ODF 가상화의 기본 구성인 블록 모드에서 RWX를 지원합니다 StorageClass.
• ocs-storagecluster-ceph-rbd-virtualization ( StorageClass )는 RBD 블록 모드를 통해 ReadWriteMany 를 지원하도록 사전 구성되어 있습니다. StorageClass 을 사용하는 가상 서버는 추가 구성 없이 라이브 마이그레이션할 수 있습니다.
• 일반 ocs-storagecluster-ceph-rbd StorageClass 은 기본적으로 ReadWriteOnce 액세스 모드를 사용합니다. RWO PVC를 사용하는 가상 서버는 라이브 마이그레이션을 수행할 수 없습니다. 소스에 연결된 상태에서 대상 노드에 PVC를 마운트할 수 없기 때문에 마이그레이션이 실패합니다.

라이브 마이그레이션이 필요한 가상 서버용 PVC( customStorageClasses )를 생성하는 경우, 해당 PVC가 accessModes: [ReadWriteMany] 및 volumeMode: Block 설정으로 생성되었는지 확인하십시오.

실시간 마이그레이션도 필요합니다:

• 적절한 마이그레이션 정책으로 Red Hat OpenShift 가상화 운영자 구성하기
• 대상 노드에서 충분한 CPU와 메모리를 사용할 수 있는지 확인하기

일반 RBD에 비해 가상화에 특화되어 있습니다 StorageClass

가상 머신은 일반 Ceph RBD StorageClass, 를 사용할 수 있지만, 가상화 전용 StorageClass 는 가상 머신 워크로드 디스크의 고유한 I/O 및 수명 주기 특성에 최적화되어 있습니다.

일반 RBD( StorageClasses )는 컨테이너 워크로드에 여전히 적합하지만, 프로덕션 가상화 환경에서는 가상화 전용 StorageClass 를 사용하는 것이 권장됩니다.

가상화를 위한 사용자 지정 StorageClass 만들기

일부 시나리오에서는 특정 성능, 복원력 또는 용량 요구 사항을 충족하기 위해 사용자 지정 StorageClass 이 필요할 수 있습니다.

사용자 지정 StorageClass 리퀘스트를 생성하려면, 먼저 사용자 지정 CephBlockPool 를 생성해야 합니다. 사용자 지정 풀을 만들 때는 풀에 targetSizeRatio 을 설정해야 합니다. 이 설정이 없으면 Ceph 배치 그룹 자동 확장 기능은 풀에 배치 그룹을 단 1개만 할당합니다. 이 할당으로 인해 모든 I/O가 단일 OSD에서 병목 현상이 발생하여, 기본 풀보다 성능이 저하됩니다.

가상화 워크로드에 대한 사용자 지정 StorageClass 을 만들 때 다음 매개 변수가 올바르게 구성되어 있는지 확인합니다.

• 프로비저너

  StorageClass 는 ODF에서 제공하는 Ceph RBD CSI 프로비저너를 사용해야 합니다:

  openshift-storage.rbd.csi.ceph.com
  

  이 프로비저너를 사용하면 ODF 클러스터가 백업하는 Ceph RBD 볼륨을 동적으로 프로비저닝할 수 있습니다.

• 스토리지 풀

  가상 머신 워크로드 디스크를 백업하는 CephBlockPool 을 지정합니다. 다음 옵션 중 하나를 선택할 수 있습니다.

  • 기본 블록 풀입니다. ODF에 의해 생성된 기본 3방향 복제된 Ceph 블록 풀입니다:

      ocs-storagecluster-cephblockpool
      ```
  
  - 사용자 지정 블록 풀. 사용자 정의 CephBlockPool. 성능 함정을 피하려면 풀에 다음 설정이 포함되어야 합니다:
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• 이미지 기능

  StorageClass 에는 워크로드 성능에 중요한 RBD 이미지 기능이 포함되어 있어야 합니다:

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  RBD 이미지 기능 및 용도

  기능	용도
  exclusive-lock	쓰기백 캐싱 및 단일 라이터 최적화를 활성화합니다. 이 기능이 없으면 쓰기 IOPS가 최대 7x 더 나빠질 수 있습니다.
  object-map	희소 이미지에 할당된 오브젝트의 비트맵 추적을 활성화합니다.
  fast-diff	스냅샷 차이점 및 DataVolume 복제 작업을 가속화하여 부팅 시간을 단축합니다.
  deep-flatten	클론을 평평하게 만든 후 완전히 독립적으로 만듭니다.
  layering	DataVolume 복제에 필요한 복사 시 쓰기 복제를 활성화합니다.

• 지도 옵션

  mapOptions: krbd:rxbounce
  

  이 옵션은 Windows 가상 서버에서 커널 RBD 드라이버를 사용할 때 발생하는 데이터 손상 문제를 해결합니다. 호환성을 보장하기 위해 커널이 수신된 데이터에 대해 바운스 버퍼를 사용하도록 강제합니다. 이 옵션은 모든 워크로드 StorageClasses 에서 설정되어야 합니다.

• 완전한 사용자 지정 StorageClass 예제

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  클러스터의 clusterID 주소를 찾으려면 다음 명령을 실행합니다:

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  삭제 코딩 풀(개발자 미리 보기 전용)의 경우, ‘데이터 보호 이해’를 참조하고, EC 풀을 가리키는 dataPool 을 추가하며, pool 은 기본 복제 풀을 가리키도록 유지하십시오:

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

압축

ODF는 Ceph 블록 풀에서 BlueStore 인라인 압축을 지원하므로 디스크에서 사용하는 원시 저장 공간을 줄일 수 있습니다. 압축은 OSD 계층에서 투명하게 적용되므로, 가상 머신 워크로드와 해당 게스트 OS는 데이터가 압축되고 있다는 사실을 인식하지 못합니다.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

암호화

ODF는 독립적으로 활성화할 수 있는 여러 계층의 저장 데이터 암호화를 지원합니다.

• IBM Cloud 인프라 암호화: 물리적 NVMe 드라이브에 대한 전체 디스크 암호화 - IBM Cloud 에서 관리합니다.
• ODF 클러스터 전체 암호화: 모든 Ceph OSD 디스크는 장치 수준에서 dm-crypt를 사용하여 암호화됩니다. 스토리지 클러스터 CR의 ‘ encryption.clusterWide: true ’을 통해 활성화되었습니다. 물리적 디스크 도난으로부터 보호합니다.
• ODF 볼륨별 암호화: 개별 RBD 볼륨은 LUKS2 를 사용하여 암호화되며, 각 볼륨마다 고유한 데이터 암호화 키가 할당됩니다. 테넌트 격리 및 세분화된 키 관리 기능을 제공합니다.

Red Hat OpenShift Kubernetes Service 에서 ODF는 클러스터 전체 및 볼륨별 암호화를 위한 외부 키 관리 서비스로 IBM Key Protect 와 통합됩니다. 볼륨별 암호화를 사용하도록 설정하면 ODF는 -encrypted StorageClass 변형(예: ocs-storagecluster-ceph-rbd-encrypted)을 자동으로 생성합니다.

NVMe 베어메탈 환경에서의 Ceph 성능 튜닝

Ceph의 기본 구성은 일반적인 워크로드에 최적화되어 있습니다. 다음 매개변수 값들은 mx2d.metal.96x768 베어메탈 프로필에서 유효성이 검증되었으며, 해당 프로필에서 VM 디스크 워크로드의 IOPS를 크게 향상시키고 지연 시간을 줄여줍니다. 다른 베어메탈 프로필을 사용하는 경우, 이 내용을 기본 참고 자료로 삼고 특정 프로필의 NVMe 드라이브 수와 사용 가능한 CPU에 따라 값을 조정하십시오.

Ceph 툴박스 포드에서 ceph config set 명령어를 사용하여 각 매개변수를 적용하십시오:

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

신청 후, 설정이 승인되었는지 확인하십시오:

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

ceph config set 를 변경하더라도 OSD 포드를 다시 시작할 필요는 없습니다. Ceph는 구성을 동적으로 적용합니다. 그러나 BlueStore 의 캐시 변경 사항(osd_memory_target)은 각 OSD 포드가 재활용된 후에야 완전히 적용됩니다. 유지보수 시간대에는 I/O를 중단하지 않고 OSD 포드를 한 번에 하나씩 재활용할 수 있습니다.

벤치마크 참고 자료: 200개의 VM과 무제한 IOPS를 갖춘 3노드 mx2d.metal.96x768 클러스터에서 수행한 내부 테스트 결과, 16개의 샤드, 8GB OSD 메모리, 256MB RocksDB 쓰기 버퍼를 조합했을 때 약 194,000 IOPS와 758 MB/s의 처리량을 달성한 것으로 나타났습니다. 샤드 수를 8개에서 16개로 늘리는 것은 모든 테스트 구성에서 일관되게 IOPS 측면에서 가장 큰 단일 개선 효과를 가져왔습니다.

스냅샷 기반 백업

ODF는 Ceph RBD 볼륨에 대해 Kubernetes VolumeSnapshots 을 지원합니다. 디스크의 스냅샷을 찍으려면 다음 명령을 사용하세요:

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots 는 쓰기 즉시 복사할 수 있고 거의 즉시 만들 수 있습니다. 이를 통해 가상 머신 워크로드를 이전 상태로 복원하거나 디스크를 복제할 수 있습니다. 또한 Red Hat OpenShift Virtualization은 구성 및 모든 디스크를 포함한 가상 머신 워크로드의 전체 상태를 단일 작업으로 캡처하는 내장형 VM 스냅샷 및 복원 API를 제공합니다.

애플리케이션 일관성 스냅샷을 위한 가상 머신 워크로드 대기 중지

실행 중인 가상 머신 워크로드의 스냅샷을 생성할 때는 디스크상의 데이터가 일관된 상태여야 합니다. 스냅샷은 대기 시간 없이 부분적으로 기록된 트랜잭션, 더티 버퍼, 비행 중 I/O를 포함하여 해당 시점의 디스크에 있는 모든 것을 캡처합니다. 이 프로세스는 크래시 일관성 스냅샷을 생성하며, 복원 시 애플리케이션 수준 복구가 필요할 수 있습니다.

애플리케이션 일관성 있는 스냅샷을 생성하려면, 스냅샷 생성 전에 게스트 파일 시스템을 동결하고, 스냅샷 생성 후에 다시 해제해야 합니다. Red Hat OpenShift Virtualization은 QEMU 게스트 에이전트를 사용하여 이 과정을 자동화합니다.

스냅샷 컨트롤러가 QEMU 게스트 에이전트를 감지합니다. 스냅샷을 생성하기 전에, 모든 파일 시스템 I/O를 중지시키는 guest-fsfreeze-freeze 명령을 실행합니다. 파일 시스템이 정지된 상태에서 VolumeSnapshot이 생성됩니다. 스냅샷이 완료되면 guest-fsfreeze-thaw 명령이 I/O를 재개합니다. 스냅샷 상태는 달성된 일관성 수준을 나타냅니다. 각 상태의 의미는 다음 표를 참조하십시오.

모든 운영 환경의 가상 머신에는 QEMU 게스트 에이전트를 설치하는 것이 권장됩니다. Linux 게스트에서는 다음 명령을 사용하십시오.

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Windows 게스트의 경우 QEMU 게스트 에이전트 서비스가 포함된 VirtIO 드라이버 패키지를 설치합니다.

애플리케이션용 사용자 정의 동결/해제 후크: 파일 시스템 동결 외에도 추가적인 정지 처리가 필요한 데이터베이스 및 기타 상태 유지형 애플리케이션의 경우, /etc/qemu-ga/fsfreeze-hook.d/ 위치에 게스트 가상 머신 워크로드 내에 사용자 정의 후크 스크립트를 배치하십시오. 이 스크립트들은 파일 시스템이 동결되기 전에는 freeze 인수를, 파일 시스템이 해제된 후에는 thaw 인수를 받아 게스트 에이전트에 의해 자동으로 실행됩니다. 훅 실행 로그는 /var/log/qga-fsfreeze-hook.log 에 기록됩니다.

예를 들어 다음 PostgreSQL 고정 후크는 /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh 에 배치할 수 있습니다:

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware 비교: 이 예시는 애플리케이션 일관성 스냅샷을 생성하기 위해 VMware Tools와 함께 사용되는 ‘ VMware ’의 프리프리즈(pre-freeze) 및 포스트-토우(post-thaw) 스크립트와 유사합니다. QEMU 게스트 에이전트는 스냅샷 정지 기능에 있어 VMware Tools와 동일한 역할을 수행합니다.

변경된 블록 추적 제한 사항

변경된 블록 추적(Changed Block Tracking) 기능은 마지막 백업 이후 변경된 블록만을 식별하여 증분 백업을 가능하게 합니다. VMware 의 VADP( vStorage, 데이터 보호용 API)는 이 메커니즘을 활용하여 효율적인 증분 백업을 제공합니다.

Red Hat OpenShift 가상화에서는 ODF 및 Ceph RBD에 대한 CBT를 사용할 수 없습니다. 현재 백업은 전체 스냅샷에 의존하고 있어, 이로 인해 백업 시간이 길어지고 스토리지 사용량이 증가할 수 있습니다.

CBT 개발은 여러 단계로 진행 중입니다:

Ceph RBD는 스냅샷 간 변경된 블록을 식별하는 기본 rbd diff 기능을 지원하지만, 이 기능은 아직 Kubernetes CSI 변경 블록 추적 API를 통해 제공되지 않습니다. 전체 스택이 준비될 때까지(CSI CBT API + Ceph CSI 드라이버 지원 + KubeVirt 통합) 블록 레벨의 증분 백업은 사용할 수 없습니다.

백업 솔루션

여러 백업 업체들이 현재의 스냅샷 기반 모델 내에서 작동하는 ‘ Red Hat OpenShift ’ 가상화용 솔루션을 제공하고 있습니다:

• Veeam® Kasten: Kubernetes- Red Hat OpenShift 가상화 지원 및 ODF용 증분 스냅샷 기능을 통한 기본 데이터 보호. 자세한 내용은 빔 카스텐 참조 아키텍처를 참조 하세요.
• Kubernetes: Red Hat OpenShift 가상화 워크로드에 대한 백업 및 복구, ODF 통합. 자세한 내용은 Trilio Red Hat OpenShift 가상화 지원을 참조하세요.
• 베리타스 NetBackup: 엔터프라이즈 백업과 Red Hat OpenShift 가상화 지원. 자세한 내용은 다음을 참조하십시오. NetBackup- 포괄적인 기업 데이터 보호.

VMware 마이그레이션에 대한 권장 사항

현재 VMware 환경이 CBT 기반 증분 백업에 의존하는 경우 다음 권장 사항을 고려하세요:

• 전체 스냅샷 백업을 계획하세요. 증분 백업 대신 전체 백업( VolumeSnapshots )을 기준으로 백업 시간대 및 스토리지 요구 사항을 평가하십시오.
• Kubernetes-네이티브 백업 도구 평가하기. Veeam Kasten 및 Trilio는 Kubernetes 및 Red Hat OpenShift 가상화 환경을 위해 설계되었으며, 현재의 스냅샷 모델 내에서 작동합니다.
• Ceph 스냅샷의 효율성을 활용하세요. Ceph RBD 스냅샷은 쓰기 시 복사(Copy-on-Write) 방식을 채택하고 있으며, 스냅샷 생성 후에는 변경된 블록에 대해서만 저장 공간을 사용하므로, 전체 복사본에 비해 지속적인 스냅샷 저장이 더 효율적입니다.

ODF 및 Ceph 상태 모니터링

가용성과 성능을 유지하려면 ODF 스토리지 클러스터를 정기적으로 모니터링하는 것이 필수적입니다. 다음 섹션에서는 주요 명령어와 해당 출력을 설명합니다.

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

ODF 업그레이드 Red Hat OpenShift Kubernetes Service

IBM Cloud Red Hat OpenShift 의 Data Foundation(ODF) 애드온은 동일한 마이너 릴리스 내에서 z-stream 업데이트를 자동으로 적용합니다. 이러한 업데이트는 IBM Cloud 를 통해 관리됩니다.

그러나 메이저 및 마이너 버전 업그레이드(예: 4.18 → 4.19 )는 자동으로 이루어지지 않습니다. 데이터의 안전성과 클러스터의 안정성을 보장하기 위해 수동 업그레이드 절차를 따르십시오.

Red Hat OpenShift Kubernetes Service 클러스터에서 ODF 업데이트는 두 가지 주요 단계로 구성되며, 두 단계 모두 성공적인 업그레이드를 위해 필요합니다.

1. ODF 워커 노드를 업그레이드하거나 교체합니다.

   • ODF는 스토리지 구성 요소를 호스팅하기 위해 전용 또는 레이블이 지정된 작업자 노드를 사용합니다.
   • 메이저 또는 마이너 업그레이드 중에는 이러한 작업자 노드를 대상 Red Hat OpenShift 및 ODF 버전에 맞게 업그레이드하거나 교체해야 합니다.
   • 이 프로세스를 통해 ODF 포드(예: Ceph OSD, MON 및 관리자)가 올바르게 예약되고 데이터 손실 없이 계속 작동하도록 할 수 있습니다.
   • 스토리지 가용성을 유지하려면 이 단계를 시작하기 전에 충분한 용량과 노드 상태가 양호한지 확인하십시오.

2. ODF 애드온을 업데이트합니다.

   • 워커 노드를 업그레이드하거나 교체한 후 ODF 애드온을 업데이트합니다.
   • 이 단계에서는 ODF 연산자, CSI 드라이버 및 관련 구성 요소를 대상 버전으로 업그레이드합니다.
   • 애드온 업데이트가 완료되면 클러스터가 자동으로 ODF 리소스를 조정하고 필요한 변경 사항을 적용합니다.

   업그레이드 후 유효성 검사를 실행하여 다음 사항을 확인하십시오:

   • ODF 및 Ceph 클러스터 상태
   • StorageClasses 가용성
   • 애플리케이션별 성공적인 PVC 읽기 및 쓰기 작업

자세한 내용은 VPC 클러스터에서 ODF 업데이트하기를 참조하세요.

ODF 스토리지 확장 Red Hat OpenShift Kubernetes Service

따라서 워크로드가 증가하고 스토리지 수요가 늘어남에 따라 스토리지 인프라를 확장하는 것이 필수적입니다. ODF 확장은 실행 중인 애플리케이션을 중단하지 않고도 스토리지 용량을 늘리고 성능을 개선하며 복원력을 유지할 수 있는 2일차 핵심 작업입니다.

IBM Cloud Red Hat OpenShift Kubernetes Service 환경에서 확장에는 일반적으로 스토리지 워커 풀을 확장하는 작업이 포함됩니다. 이 작업은 최소한의 다운타임으로 수행되므로 스토리지 클러스터를 원활하게 확장할 수 있습니다.

1. VPC 클러스터에 워커 노드를 추가하세요. 스토리지 클러스터가 3개의 가용 영역에 걸쳐 있는 다중 영역 클러스터의 경우, 영역 간 균형을 유지하기 위해 워커 노드를 3의 배수(예: 3, 6, 9)로 추가하십시오. 유연한 확장 기능이 활성화된 단일 영역 클러스터의 경우, 노드를 한 번에 하나씩 추가할 수 있습니다.

2. 노드가 추가된 후, 해당 노드를 ODF에 등록하십시오. 클러스터의 모든 워커 노드에서 ODF가 실행 중이라면, 새로운 노드가 스토리지 토폴로지에 자동으로 추가됩니다. ODF가 일부 워커 노드에서만 실행되는 경우, 다음 단계로 진행하십시오.

3. 클러스터의 모든 워커 노드에서 ODF가 실행되는 경우, 새 워커 노드가 ODF 스토리지 클러스터 토폴로지에 자동으로 추가됩니다. ODF가 일부 워커 노드에서만 실행되는 경우, OcsCluster 사용자 정의 리소스에서 매개변수를 지정하십시오. 사용자 지정 리소스 정의를 편집하여 새 작업자 노드의 이름을 ODF 배포에 추가합니다. OcsCluster 사용자 정의 리소스를 다음과 같이 수정하십시오:

   • ocscluster 찾기

     oc get ocscluster
     

   • ocscluster 사용자 정의 리소스 파일을 편집하고 새로운 워크노드를 추가합니다

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • OcsCluster 사용자 정의 리소스 파일을 저장하여 클러스터에 다시 적용하십시오.

4. OcsCluster 사용자 정의 리소스에서 'numOfOsd' 값을 늘리면, OCS가 새로 추가된 워커 노드에 ODF 구성 요소를 배포하고 스토리지 클러스터에 추가 OSD를 프로비저닝할 수 있게 됩니다.

   'numOfOsd' 에 대한 조정 값은 노드당 OSD 디스크 수와 추가된 노드 수 모두에 따라 달라집니다. 예를 들어, 각 노드에 OSD 전용 NVMe 디스크가 8개씩 장착되어 있는 경우, 노드를 3개 추가하면 ‘ 'numOfOsd' ’가 8개 증가하고, 6개를 추가하면 16개 증가합니다.

5. 다음 명령을 실행하여 결과를 확인하십시오:

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. 새로운 워커 노드가 추가되었는지, 그리고 (다중 존 클러스터의 경우) 각 존에 고르게 분산되어 있는지, 또는 (단일 존 유연한 확장 클러스터의 경우) 개별 호스트 버킷으로 표시되는지, 또한 각 노드에 할당된 OSD의 수가 일치하는지 확인하십시오.

자세한 내용은 ‘VPC 클러스터에 워커 노드를 추가하여 ODF 확장하기’를 참조하십시오.

유연한 스케일링

IBM Cloud 의 ODF 애드온은 클러스터 구성에 따라 서로 다른 장애 도메인 토폴로지를 사용합니다:

• 다중 가용 영역 클러스터(가용 영역 3개): 장애 도메인은 zone 로 설정되어 있습니다. OSD는 존 간 데이터 복제 및 고가용성을 유지하기 위해 3의 배수로 프로비저닝되며, 존당 한 세트씩 할당됩니다. 존 간의 균형을 유지하려면 스토리지 클러스터의 용량을 3의 배수로 확장해야 합니다.
• 단일 가용 영역 클러스터 또는 가용 영역이 3개 미만인 클러스터: 유연한 확장 기능이 자동으로 활성화됩니다. 장애 도메인은 host``로 설정되어 있으며, 이는 각 노드가 서로 다른 장애 도메인을 구성함을 의미합니다. 한 번에 하나의 노드를 추가할 수 있으며, 스토리지 용량을 세밀하게 확장할 수 있습니다.

ODF 4.21 부터는 유연한 확장 동작이 초기 배포 시 클러스터 토폴로지에 따라 자동으로 결정되며, 이후에는 변경할 수 없습니다.

단일 영역 또는 유연한 확장 방식의 배포 환경에서는, replica-3 풀이 단일 호스트의 장애가 발생하더라도 계속 작동합니다. 다중 구역 배포 환경에서, replica-3 풀은 전체 구역이 손실되더라도 계속 작동합니다. ODF를本番 환경에 배포하기 전에, 클러스터 토폴로지와 이에 따른 내결함성이 복원력 요구 사항을 충족하는지 평가하십시오.

추가 매개변수의 전체 목록과 콘솔 기반 설치 단계에 대해서는 ‘VPC 클러스터에 OpenShift Data Foundation 배포’를 참조하십시오.

노드 확장 시 성능: 유연한 확장 기능을 지원하는 ODF 클러스터에 노드를 추가하면 Ceph 데이터 재조정 작업이 실행됩니다. 아래에서 설명하는 내부 테스트에서 IOPS와 처리량은 안정적인 수준을 유지한 반면, 쓰기 지연 시간은 일시적으로 증가했습니다. 50,000 IOPS에서 100대의 가상 머신이 구동되는 3노드 클러스터를 대상으로 한 내부 테스트에서 다음과 같은 결과가 관찰되었습니다:

재조정 완료 후 쓰기 지연 시간이 기준치로 돌아옵니다. 워크로드가 쓰기 지연 시간 급증에 민감한 경우, VM 활동이 적은 시간대에 노드 추가를 계획하십시오.