Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/07/10/storage-considerations-openshift-virtualization
Red Hat OpenShift Virtualization을 성공적으로 구축하려면 운영 환경에 대한 신중한 계획과 평가가 필요합니다. 모든 계획 활동에 포함해야 할 요소 중 하나는 가상 머신(VM)에서 사용하는 스토리지입니다.
이 글에서는 사용 가능한 몇 가지 고수준 아키텍처 접근 방식을 분석하고 각 옵션의 장단점을 살펴봅니다. 시작하기 전에 VM 사용 사례의 스토리지 요구 사항을 검토하는 것이 좋습니다.
스토리지 요구 사항
다음 정보는 VM, 특히 KubeVirt 프로젝트(OpenShift Virtualization의 업스트림)가 Kubernetes 에 가져오는 저장소 요구 사항을 요약한 것입니다 .
- 라이브 마이그레이션 : 라이브 마이그레이션의 경우 저장 공간은 ReadWriteMany (RWX) 볼륨 입니다 . RWX는 공유 볼륨에서는 쉽지만, 블록 장치에서는 항상 사용할 수 있는 것은 아닙니다.
- VM 프로비저닝: 볼륨 스냅샷 및 볼륨 복제 는 선택적인 컨테이너 스토리지 인터페이스(CSI) 기능이며 모든 CSI 리버에서 구현되는 것은 아닙니다. 채워진 VM 디스크를 프로비저닝하는 KubeVirt의 컨테이너화된 데이터 임포터 (CDI) 모듈은 이러한 기능을 활용합니다.
- VM 디스크 확장: 볼륨 확장은 대부분의 CSI 호환 스토리지 드라이버가 구현하는 선택적 CSI 기능입니다.
- VM 백업: 볼륨 스냅샷 과 볼륨 일관성 그룹( CSI의 VolumeGroupSnapshot )은 여러 디스크가 있는 VM 또는 VM 그룹의 장애 발생 시에도 일관된 백업을 수행합니다. 증분 백업을 캡처할 수 있도록 하는 변경 블록 추적 (CBT) 기능이 백업의 규모에 맞게 작동해야 합니다. CBT는 CSI의 일부이지만 널리 채택되지는 않았습니다.
- VM 재해 복구(DR): 볼륨 복제는 CSI의 일부가 아닙니다. 따라서 현재 볼륨 복제를 요청하는 표준 방법은 없습니다. 복제된 볼륨의 볼륨 일관성 그룹에도 마찬가지입니다.
- 확장성: 스토리지는 수천 개의 볼륨으로 확장하고 수백 개의 볼륨을 동시에 연결/분리할 수 있어야 합니다. 대규모 베어 메탈 클러스터는 수천 개의 VM을 실행할 수 있습니다. 계획된 또는 계획되지 않은 유지 관리 작업 중에는 수백 개의 VM이 노드 또는 클러스터 간에 이동해야 할 수 있습니다.
물론 이러한 요구 사항의 대부분은 Container Storage Interface (CSI)를 요구합니다 . 따라서 스토리지 솔루션을 선택할 때 관련 CSI 드라이버가 지원하는 기능을 평가하는 것이 중요합니다. 스토리지 라이브 마이그레이션 , VM 간 공유 디스크 , 핫 플러그형 디스크 , SCSI-3 영구 예약 , 디스크 암호화 등 CSI를 요구하지 않는 다른 VM 스토리지 사용 사례도 있습니다. 이러한 사용 사례는 본 문서의 범위를 벗어납니다. 하지만 스토리지 솔루션 선택에 영향을 미칠 수 있습니다.
스토리지 솔루션을 선택할 때 이러한 요구 사항을 염두에 두고, 스토리지가 궁극적으로 VM에 제공되는 방식과 관련된 아키텍처를 고려하는 것이 중요합니다.
스토리지에 대한 아키텍처적 접근 방식
VM에 저장소를 제공하는 데 사용할 수 있는 세 가지 주요 아키텍처 접근 방식은 다음과 같습니다.
- CSI 드라이버를 통해 직접 액세스하는 외부 저장소는 일반적으로 SAN( Storage Area Network ) 어레이에 호스팅되지만 NAS( Network Attached Storage ) 또는 외부 SDS( Software-Defined Storage ) 일 수도 있습니다 .
- SDS 솔루션을 통해 내부 저장소가 제공됩니다.
- 공유 디스크 파일 시스템 .
직접 CSI를 갖춘 외부 스토리지
이 아키텍처 방식에서 스토리지는 Red Hat OpenShift 클러스터 외부에 위치하며 원격으로 접근합니다. 스토리지 공급업체 CSI 드라이버는 볼륨의 프로비저닝 및 연결/분리 작업을 관리합니다.
외부 스토리지를 제공하는 방법에는 여러 가지가 있습니다. 대부분의 경우 SAN (블록 스토리지) 또는 NAS (파일 스토리지) 토폴로지 영역에 속합니다 . 가상 머신을 위해 조직은 일반적으로 SAN 스토리지 어레이와 전용 스토리지 네트워크(예: 파이버 채널 네트워크)에 투자합니다.
그림 1은 이 아키텍처를 보여줍니다.
이 접근 방식에서 가상 머신과 연관된 영구 볼륨(PV)에는 CSI 드라이버가 생성한 해당 논리 단위 번호( LUN )(SAN인 경우) 또는 공유(NAS인 경우)가 있습니다.
이는 VM이 본질적으로 스토리지 공급자에 직접 연결되어 대기 시간을 최소화하므로 매우 효율적인 아키텍처 접근 방식입니다.
이 접근 방식이 실행 가능한 솔루션이 되려면 스토리지 공급업체에서 제공하는 CSI 드라이버가 앞서 언급한 요구 사항을 충족해야 합니다. SAN 공급업체의 CSI 드라이버 성숙도는 전반적으로 향상되고 있습니다.
그러나 다음과 같은 문제로 인해 이러한 아키텍처 접근 방식을 채택하는 데 어려움이 있을 수 있습니다.
- 사용 중인 CSI 드라이버는 블록 볼륨에 대한 RWX 모드를 지원하지 않거나 일부 고급 기능(예: 복제, 스냅샷, 볼륨 확장)을 지원하지 않습니다.
- VM 디스크당 하나씩 여러 개의 작은 LUN을 만드는 패턴은 SAN 제품에 적합하지 않습니다.
- 일부 스토리지 팀은 OpenShift가 볼륨을 동적으로 프로비저닝하는 기능을 제공하는 것을 원하지 않습니다.
SAN 분야에는 CSI 드라이버를 제공하는 여러 스토리지 공급업체가 있습니다. 아래 목록(일부만 제공)을 통해 공급업체별 CSI 문서를 확인할 수 있습니다.
스토리지 공급업체나 Red Hat 서비스는 스토리지 솔루션이 OpenShift Virtualization과 함께 사용하기에 적합한지 확인하는 데 도움을 줄 수 있습니다.
소프트웨어 정의 스토리지를 갖춘 내부 스토리지
이 아키텍처 접근 방식에서는 스토리지가 OpenShift 클러스터 내부에 존재하며 SDS 제품을 사용하여 관리됩니다.
SDS를 사용하면 OpenShift 클러스터의 일부 또는 모든 노드가 스토리지 노드이기도 합니다. 스토리지 노드에는 SDS 소프트웨어가 관리하는 로컬 스토리지 장치가 있습니다. 모든 노드가 스토리지 노드이기도 한 경우를 하이퍼컨버지드 인프라라고 합니다. 일부 노드만 스토리지 노드인 경우를 부분 컨버지드 인프라라고 합니다. 부분 컨버지드 솔루션은 스토리지와 컴퓨팅을 독립적으로 확장할 수 있는 기능을 제공하므로 컨테이너 및 가상 머신 과 더 잘 호환되는 것으로 보입니다 .
그림 2는 이 접근 방식을 사용한 아키텍처를 보여줍니다.
SDS 제품의 CSI 드라이버가 앞서 언급한 요구 사항을 충족하는 한, 소프트웨어 정의 스토리지는 가상 머신 사용 사례와 잘 작동합니다.
IBM Fusion Storage , Portworx , Red Hat OpenShift Data Foundation을 비롯하여 Kubernetes에 대한 뛰어난 운영자와 OpenShift Virtualization에 대한 인증을 갖춘 여러 SDS 제품이 있습니다 .
SDS를 사용하여 내부 스토리지를 평가할 때, OpenShift 관리팀이 스토리지 관리도 담당한다는 점에 유의해야 합니다. 스토리지 제품은 기업 내에서 가장 복잡한 구성 요소 중 하나이며, 전반적인 관리는 그 자체로 하나의 전문 분야입니다. 결과적으로 OpenShift 관리팀의 인지적 부담이 너무 커져 전반적인 진화를 지연시키고 OpenShift 플랫폼의 전반적인 건전성을 저해할 수 있습니다. 풍부한 기능을 갖춘 SDS 운영자는 이러한 위험을 상쇄하는 데 도움을 줄 수 있습니다.
SAN을 통한 SDS
SAN에서 프로비저닝된 LUN을 사용하여 SDS를 구축하는 것이 가능합니다. 그림 3은 이 아키텍처를 보여줍니다.
이러한 접근 방식을 지원하기 위해 일반적으로 스토리지 어레이에 대용량 LUN이 생성되어 OpenShift 노드에서 사용할 수 있도록 제공됩니다. SDS 제품은 이러한 LUN의 관리를 담당하고 이를 장치로 사용하여 스토리지 추상화 계층을 생성합니다.
저희는 고객들과 이러한 접근 방식을 몇 번이나 경험했기에, 이에 대한 내용을 별도로 다루기로 했습니다. 구조적으로 볼 때, SAN을 통한 SDS 사용은 다음과 같은 이유로 이상적이지 않습니다.
- SDS는 추가적인 소프트웨어 계층이며 라이선싱 및 관리 비용이 발생합니다.
- SDS 계층은 SAN에 직접 액세스할 때 지연 시간을 추가합니다.
- SDS 계층은 자체 데이터 보호 논리를 통해 쓰기 및 공간 증폭(일반적으로 쓰기 횟수를 2~3배로 곱함)을 도입합니다.
즉, SAN을 통한 SDS는 다른 실행 가능한 옵션이 없을 때 대안으로 고려될 수 있습니다.
공유 디스크 파일 시스템
공유 디스크 파일 시스템은 SAN을 효율적으로 사용하기 위해 개발되었습니다. 이 시스템은 클러스터 노드 간에 공유되는 하나의 큰 LUN을 생성한 후, 해당 LUN에 파일 시스템을 생성하는 방식으로 작동합니다. 이렇게 하면 파일 시스템이 클러스터 노드 간에 공유됩니다. 이러한 설정을 통해 VM 오케스트레이터는 공유 디스크 파일 시스템에 VM 디스크를 나타내는 파일을 생성할 수 있습니다. OpenShift 배포에서는 CSI 드라이버가 이 작업을 담당합니다. 그림 4는 CSI 드라이버로 보강된 공유 디스크 파일 시스템의 아키텍처를 보여줍니다. 이를 통해 VM에 스토리지를 프로비저닝합니다.
CSI 드라이버는 VM이 공유 디스크 파일 시스템 내에서 올바른 디스크 파일을 가져오도록 보장합니다. 그 이후에는 VM과 백업 스토리지 사이에 소프트웨어 계층이 없으므로, 이 방식은 이론적으로 직접 CSI 드라이버 방식과 동일한 성능을 제공합니다.
공유 디스크 파일 시스템은 노드 간 잠금 메커니즘의 작동 방식으로 인해 사용 가능한 노드 수에 제한이 있는 경우가 있습니다. 따라서 이 접근 방식은 중간 규모(최대 약 40개 노드)의 OpenShift 클러스터에 적합합니다.
본 출판 시점을 기준으로 두 개의 공유 디스크 파일 시스템 제품, 즉 IBM Fusion Access for SAN 과 Arctera(Veritas) Infoscale Operator에 적합한 CSI 드라이버가 있습니다 .
접근 방식의 장단점
앞서 언급한 접근 방식에는 각각 긍정적인 면과 부정적인 면이 있습니다.
직접 CSI를 갖춘 외부 저장소
장점:
- 효율적이고 Kubernetes 기반입니다.
단점:
- 모든 공급업체가 성숙한 CSI 드라이버를 보유하고 있는 것은 아닙니다.
- 일부 SAN은 여러 개의 작은 LUN을 지원하도록 설계되지 않았습니다.
- 모든 조직이 OpenShift에 SAN 자격 증명을 제공하여 볼륨을 동적으로 프로비저닝하려고 하는 것은 아닙니다.
SDS를 사용한 내부 저장소:
장점:
- 효율적이고 Kubernetes 기반입니다.
단점:
- 인지적 부담이 플랫폼 팀을 압도할 수도 있습니다.
SAN을 통한 SDS:
장점:
- CSI 직접 액세스를 지원하지 않는 구형 모델을 포함하여 모든 SAN에서 작동합니다.
단점:
- 지연 시간이 더 길어짐.
- 더 높은 비용(SDS 소프트웨어 라이선스 및 TCO로 인해)
- 증폭을 쓰세요.
- 인지적 부담이 더 크다.
공유 디스크 파일 시스템:
장점:
- CSI 직접 액세스를 지원하지 않는 구형 모델을 포함하여 모든 SAN에서 작동합니다.
단점:
- 확장성에 제한이 있을 수 있습니다.
- 비용이 더 많이 듭니다(공유 디스크 파일 시스템 소프트웨어 라이선스로 인해).
이러한 장단점 고려 사항을 바탕으로, 그림 5의 다음 다이어그램은 스토리지 아키텍처 솔루션을 선택할 때 권장되는 의사 결정 흐름을 보여줍니다.
결론
이 글에서는 OpenShift Virtualization에서 실행되는 가상 머신에 스토리지를 제공하는 세 가지 주요 아키텍처 접근 방식을 살펴보았습니다. 각 접근 방식의 장단점을 나열하고, 적절한 스토리지 솔루션을 결정하기 위한 정보에 기반한 의사 결정을 위한 의사결정 흐름을 제시했습니다. 이 글에 포함된 정보를 활용하여 OpenShift Virtualization 도입을 시작하는 모든 조직이 이 중요한 아키텍처를 신속하게 선택할 수 있기를 바랍니다.
