VM 인식 스토리지 가이드

대부분의 기업은 공유 스토리지 인프라에서 수십에서 수백 대의 VM을 운영합니다. 여기에는 가상 데스크톱부터 가상 서버에서 구동되는 프로덕션 데이터베이스까지 모든 것이 포함됩니다. 호스팅은 온프레미스 또는 서비스형 인프라(IaaS) 제공업체를 통해 이루어지며, 일반적으로 논리 유닛 번호(LUN, 블록 스토리지 단위) 또는 파일 기반 스토리지 볼륨을 사용합니다.

Mordor Intelligence의 연구에 따르면 가상 머신 시장은 2025년 135억 9,000만 달러로 평가되었으며, 2030년까지 269억 4,000만 달러로 성장할 것으로 예상됩니다. 이러한 성장으로 인해 동일한 공유 스토리지에 더 많은 VM이 배치됨에 따라 기존 방식으로는 어떤 VM이 가장 많은 리소스를 사용하는지 또는 속도를 저하시키는지를 파악하기가 더욱 어려워집니다. VM 인식 스토리지는 이러한 문제를 해결합니다.

VM 인식 스토리지는 각 VM의 활동을 개별적으로 추적하고 프로비저닝과 같은 데이터 서비스를 개별 VM 수준에서 적용합니다.  기존 스토리지가 하나의 단위로 취급하는 과거 공유 볼륨 또는 논리 단위 번호(LUN)를 확인하여 특정 시간에 가장 많은 IOPS(초당 입출력 작업)를 생성하는 VM과 같은 세부 정보까지 VM 성능을 추적합니다.

시스템은 VM이 동일한 풀을 두고 경쟁하도록 내버려두지 않고, 각 VM에 필요한 리소스를 제공합니다. 또한 각 VM이 사용할 수 있는 스토리지 성능을 제어하는 규칙인 VM별로 서비스 품질(QoS) 설정을 할당할 수 있습니다. 이렇게 하면 우선순위가 높은 애플리케이션이 동일한 스토리지를 두고 우선순위가 낮은 애플리케이션과 경쟁할 필요가 없습니다. 스토리지는 VM이 생성될 때 프로비저닝되고, 워크로드 변화에 따라 조정되며, VM을 사용할 수 있게 되거나 삭제되면 확보됩니다.

스냅샷도 VM별로 처리됩니다. 스냅샷은 특정 시점의 VM 가상 디스크 상태를 캡처하므로 문제가 발생할 경우 데이터를 복원할 수 있습니다. 기존 스토리지 어레이의 경우, 어레이 수준 스냅샷은 전체 공유 볼륨을 캡처합니다. VM 인식 스토리지를 사용하면 어레이가 개별 VM의 스냅샷을 생성할 수 있으므로 하나의 VM의 데이터를 복구하기 위해 전체 볼륨을 복원할 필요가 없습니다. (하이퍼바이저 수준에서는 VM별 스냅샷이 항상 가능했지만, VAS를 사용하면 스토리지 수준에서 이러한 세분성을 구현할 수 있습니다.)

VM 인식 스토리지는 아카이브 또는 비정형 데이터에 일반적으로 사용되는 오브젝트 스토리지가 아니라, VM 디스크를 호스팅하는 블록 및 파일 스토리지에 적용된다는 점에 주목할 필요가 있습니다. Block Storage가 다른 스토리지 유형과 어떻게 다른지 자세히 알아보려면 Block Storage, 파일 스토리지, 객체 스토리지 비교를 참조하세요.

기존 스토리지와 VM 인식 스토리지의 주요 차이점은 가시성에 있습니다. 기존 스토리지 방식은 파이버 채널 및 iSCSI와 같은 블록 프로토콜을 사용하는데, 이러한 프로토콜은 물리적 서버용으로 설계되었으며 개별 VM 활동을 확인할 수 있는 내장 기능이 없습니다. 일반적으로 스토리지 영역 네트워크(SAN)의 공유 볼륨 또는 논리 장치 번호(LUN)를 하나의 단위로 제공합니다. 이러한 사각지대는 과잉 프로비저닝으로 이어집니다. 관리자는 만일을 대비해 여유 용량을 확보하지만, 그 버퍼 대부분은 사용되지 않은 채 남습니다.

VM 인식 스토리지는 다른 접근 방식을 사용하여 각 VM에 필요한 것만 제공합니다. Tintri가 벤더 중 처음으로 이 방식을 시장에 도입한 이후 다른 스토리지 벤더들도 자체 버전을 개발했습니다. 

이는 문제 해결 과정에서 가장 명확하게 드러납니다. 기존 스토리지 환경에서는 VM 속도 저하 문제를 찾으려면 일반적으로 로그를 추출하고 공유 볼륨 전체를 확인해야 하는데, 이는 시스템이 이미 성능 저하 상태일 때 시간이 많이 소요되는 작업입니다. VM 인식 스토리지는 이 단계를 건너뜁니다. 정보는 이미 개별 VM에 연결되어 있으므로 원인을 쉽게 찾을 수 있습니다.

VM 인식 스토리지는 가상화의 광범위한 이점을 기반으로 여러 가지 주요 이점을 제공합니다.

- 더 우수한 성능
- 비용 절감
- 더 빠른 문제 해결
- 더 쉬운 확장성
- 더욱 정확한 복구

VM 인식 스토리지를 사용하면 VM은 더 이상 다른 VM이 점유하고 있는 리소스를 기다릴 필요가 없습니다. 이는 지연 시간을 줄여주므로, 특히 all flash array와 같은 더 빠른 하드웨어와 함께 사용할 경우 애플리케이션이 더욱 안정적으로 실행됩니다.

최악의 시나리오에 대비하기 위해 용량을 유휴 상태로 남겨 두지 않고 더욱 효율적으로 사용하므로 동일한 하드웨어에서 더 많은 VM을 실행할 수 있습니다.

IT 팀은 로그를 검색하지 않고도 어떤 VM이 문제를 일으키는지 정확히 파악할 수 있으므로 문제 해결 시간을 단축할 수 있습니다.

VM 인식 스토리지를 사용하면 새 VM이 추가될 때 스토리지가 자동으로 프로비저닝되므로 용량을 수동으로 재구성할 필요가 없습니다.

단일 VM의 데이터는 환경의 나머지 부분에 영향을 주지 않고 복원될 수 있으므로 하나의 인시던트로 인한 중단을 제한합니다. 따라서 VM 인식 스토리지는 장애 발생 전에 VM별 복제를 지원하고, 장애 발생 후에는 더 빠르고 정확한 복구를 수행할 수 있도록 해주기 때문에 재해 복구 전략에서 유용한 요소가 됩니다.

VM 인식 스토리지에는 다음과 같은 몇 가지 장단점이 있으므로 이를 고려해야 합니다. 

- 설정 복잡성
- 벤더 종속성
- 비용

VAS는 일상적인 관리를 간소화할 수 있지만 마이그레이션 자체는 더 복잡할 수 있습니다. 스위치를 켜고 끄는 수준이 아닙니다. 조직은 LUN 기반 설정에서 벗어나기 위한 계획을 세워야 하며, VM 수준의 가시성을 지원하는 스토리지를 구축해야 하는 경우도 흔합니다. 이러한 잠재적 비용을 고려해야 합니다.

일부 VM 인식 스토리지 시스템은 특정 하이퍼바이저(하나의 물리적 컴퓨터에서 여러 VM을 실행할 수 있도록 하는 소프트웨어 계층) 또는 특정 스토리지 벤더와 밀접하게 연결되어 있어 나중에 플랫폼을 전환할 때 스토리지 구성을 다시 설정해야 하는 경우가 있습니다.

VM 인식 스토리지 시스템은 하드웨어와 소프트웨어가 VM 수준에서 데이터 추적 및 관리를 지원해야 하기 때문에 기존 스토리지보다 초기 비용이 더 많이 들 수 있습니다.

VMware는 기업 IT 분야를 선도하는 가상화 플랫폼으로, 스토리지 벤더들은 이에 맞춰 제품을 개발해 왔습니다. (하지만 Broadcom이 VMware를 인수한 후 발생한 라이선스 변경으로 일부 고객은 경쟁사로 이동했습니다.) 해당 지원에는 다음이 포함됩니다.

- VVols
- vSAN
- VAAI

VVols는 VM 수준 스토리지 통합을 위한 VMware의 프레임워크입니다. VVol은 각 VM의 디스크를 기존 공유 데이터 저장소에 배치하지 않고 블록 프로토콜 또는 NFS(네트워크 파일 시스템)를 통해 스토리지 어레이에 개별 오브젝트로 저장합니다.

VVols를 사용하면 스냅샷, 클론 생성 및 QoS 설정을 전체 볼륨이 아닌 하나의 VM에 개별적으로 적용할 수 있습니다.

2023년 VMware를 인수한 Broadcom은 VVols를 중단하기로 했습니다. 새로운 vVols 및 VASA 제공자 인증은 2025년 6월에 출시된 VMware Cloud Foundation(VCF) 및 vSphere Foundation(VVF) 9.0부터 중단되었으며, Broadcom은 VCF/VVF 9.1에서 이 기능을 완전히 제거할 계획입니다.

VMware는 별도의 SAN 없이 서버에 연결된 드라이브를 공유 스토리지로 통합하는 자체 스토리지 옵션인 vSAN도 제공합니다. vSAN은 하이퍼바이저에 직접 내장되어 있기 때문에 VVols와 같은 별도의 통합 계층 없이도 성능 및 데이터 보호를 위한 VM 수준 정책을 적용할 수 있습니다.

호스트 서버에서 스토리지 어레이 자체로 프로비저닝과 같은 특정 스토리지 작업을 넘겨주는 VAAI(VMware vSphere 스토리지 API Array 통합)도 있습니다. 템플릿에서 VM을 복제할 때, 배열이 호스트를 거치지 않고 내부적으로 데이터를 복사하거나 덮어쓸 수 있습니다. VAAI는 프로비저닝 및 복제와 같은 작업을 가속화하지만 어레이가 개별 VM에 대한 가시성을 자체적으로 제공하지는 않습니다. 모든 벤더가 VAAI를 동일한 방식으로 지원하는 것은 아니므로 플랫폼을 선택하기 전에 확인하는 것이 좋습니다.

모든 워크로드가 가상 머신에서 실행되는 것은 아닙니다. 많은 조직에서는 컨테이너를 사용하는데, 컨테이너는 전체 운영 체제 없이 애플리케이션을 패키징하고 종종 VM 내에서 실행됩니다. 컨테이너는 임시 스토리지 또는 Kubernetes 또는 기타 오케스트레이터를 통해 관리되는 클라우드 네이티브 스토리지와 같은 영구 스토리지를 사용할 수 있습니다. 하지만 VM을 실행하는 조직 중에서 VMware가 유일한 옵션은 아닙니다. 대체 하이퍼바이저에는 Hyper-V, KVM 및 Nutanix AHV가 포함되며 각 플랫폼은 스토리지를 다르게 처리합니다.

• Hyper-V는 별도의 SAN 없이 서버 간 드라이브를 공유 스토리지로 풀링하는 S2D(스토리지 공간 다이렉트)와 같은 Windows Server 스토리지 기능과 함께 사용되는 경우가 많습니다.
  
  
• KVM은 일반적으로 기본 Linux 스토리지 스택을 사용하며, 클러스터 전체에서 공유 스토리지를 위해 Ceph와 같은 도구와 함께 사용되는 경우가 많습니다.
• Nutanix AHV는 스토리지와 컴퓨팅을 별도의 시스템으로 실행하는 대신, 단일 플랫폼에서 함께 제공합니다. AHV 하이퍼바이저는 KVM을 기반으로 하지만, Nutanix는 Hyper-V 및 ESXi도 지원합니다.

하이퍼바이저를 변경하면 VM 수준 스냅샷, QoS 설정 및 복구 정책이 위험에 노출될 수 있습니다. 이러한 설정은 종종 원래 하이퍼바이저의 도구와 연결되어 있으며 자동으로 이전되지 않는 경우가 있기 때문입니다.

마이그레이션하기 전에 각 VM에 어떤 보호 조치가 있는지 파악하고 새 환경에서 해당 조치를 복제할 수 있는지 또는 다시 구축해야 하는지 확인하십시오. 일부 벤더는 하나의 플랫폼에서 여러 하이퍼바이저를 지원하므로 이러한 작업이 더 쉬워집니다. 다른 시스템은 단일 하이퍼바이저를 중심으로 구축되어 있어, 전환 후 보호 설정을 다시 해야 할 수도 있습니다.

2026년 8월, Broadcom은 가상 디스크 개발 키트(VDDK)에 대한 공개 다운로드 권한을 제거했는데, 이 라이브러리는 서드파티 도구가 게스트 OS를 거치지 않고도 VM 디스크를 읽을 수 있게 해줍니다. Microsoft Azure Migrate, AWS Application Migration Service 및 Nutanix Move를 포함하여 에이전트 없는 마이그레이션에 이를 사용했던 도구는 이제 Broadcom의 기술 제휴 프로그램을 통해 액세스하거나 에이전트 기반 방식으로 전환해야 합니다.

이미 프라이빗 클라우드 , 퍼블릭 클라우드 및 온프레미스 환경을 아우르는 하이브리드 클라우드 환경을 관리하고 있는 조직은 이러한 전환이 더 수월할 수 있습니다. 이 경우 서로 다른 인프라 간에 워크로드를 이동하는 것은 이미 일상적인 운영의 일부입니다. 완전히 전환하기 전에 새 플랫폼에서 복구 기능을 테스트하는 것은 추가적인 노력을 기울일 만한 가치가 있습니다. 테스트 단계에서 발생하는 문제점을 발견하는 비용이 마이그레이션 도중에 발견하는 비용보다 훨씬 적기 때문입니다.