string(9) "한국어"

VMware VVol의 간소화 – 클라우드에 최적화된 플래시 어레이에서의 VSPHERE 가상 볼륨 구축

클라우드 시대의 플래시: “올해의 소프트웨어” 출시 블로그 시리즈

  1. 퓨어스토리지 설립 사상 최대 규모의 혁신적인 소프트웨어 출시
  2. 퓨리티(Purity) 액티브클러스터(ActiveCluster) – 모든 운영 환경에 적용 가능한 액티브-액티브 클러스터 솔루션
  3. 진정한 스케일 아웃 스토리지, 플래시블레이드(FlashBlade) – 5배 커진 용량, 5배 향상된 퍼포먼스 
  4. 초고속 오브젝트 스토리지, 플래시블레이드(FLASHBLADE) 
  5. 퓨리티(Purity) 클라우드스냅(CloudSnap) 기능을 활용한 네이티브 퍼블릭 클라우드 통합 방안
  6. VMware VVol의 간소화 – 클라우드에 최적화된 플래시 어레이에서의 VSPHERE 가상 볼륨 구축(이번 포스팅)
  7. 퓨리티 런(Purity Run) – 내부 개발자를 위한 가상머신 및 컨테이너 구동을 위한 플래시어레이(FlashArray)
  8. 업계 혁신적인 NVMe 기술 도입, 그 이후는? 다이렉트플래시(DirectFlash) 쉘프 소개 및 NVMe/F 프리뷰
  9. 플래시어레이(FlashArray용 Windows File Services: 플래시어레이(FlashArray)에 완전한 SMB & NFS 탑재
  10. 다양한 업무 통합을 가능하게 하는 정책 기반 QoS
  11. 퓨어1 메타(Pure1 META): 셀프-드라이빙 스토리지를 가능하게 하는 퓨어스토리지의 AI 플랫폼

 

 

꽤 오랫동안 이 글을 쓰려고 마음 먹고 있었습니다. 사턈 바가니(Satyam Vaghani) 가 VMworld에서 이 문제에 관해 하나의 컨셉으로서 발표한 것을 본 게 언제였는지 정확히 기억도 나지 않습니다. 지금은 프로토콜 엔드포인트(나중에 자세히 설명)라 알려졌지만, 아직 컨셉이었을 당시에는 IO Demultiplexer라 불렸습니다. 발음하기도 상당히 어려운 단어입니다. 그리고 마침내 이에 관한 글을 쓰게 되었습니다! 기쁜 마음으로 FlashArray에 구축된 VVol에 대해 설명 드리겠습니다.

가상 볼륨은 VMware와 스토리지 관리자가 직면하고 있는 많은 문제들을 해결합니다. 주요한 문제는 granularity와 관련됩니다. 어레이 기반 기능을 활용하려고 하는 경우, VMDK 수준도 아닌 VM 수준에서도 이를 적용할 수 있는 옵션이 없기 때문에 VMFS datastore에 설정합니다. 이러한 설정으로 인하여 VMFS에 있는 모든 VM에 전부 해당되거나 어떠한 것도 해당되지 않게 됩니다. 단일한 VM을 복제하는 경우, 볼륨을 복제하고 그 외 모든 다른 것들까지 복제해야 합니다. 또는 이를 복제된 데이터스토어로 이동해야 합니다.

그런데 볼륨이 복제되었는지는 어떻게 알 수 있을까요? STAYS 라는 볼륨이 복제되었는지 어떻게 확신할 수 있을까요?

VMFS의 경우 플러그인과 추가적인 소프트웨어를 사용해 이를 처리할 수 있습니다.

그러나 여전히 VMware Intelligence에는 없으며, 다시 말하지만, 특별하게 유용한 granularity도 아닙니다.

그래서 VVol이 필요한 이유입니다.

 

VVol 이란?

VVol은 기본적으로 어레이 수준의 가상 디스크 granularity을 제공합니다. VM과 그 가상 디스크를 VM 또는 가상 디스크 수준에서 생성, 프로비저닝, 관리 및 보고할 수 있도록 해주는 것입니다. 그러나 현실에서 VVol은 이보다 더 많은 것을 의미합니다. 이는

  • VM의 granularity을 의미합니다. 당연한 일입니다.
  • 스토리지 정책 기반의 관리
  • 어레이 수준에서 vCenter로의 직접적이고 표준화된 통합
  • VMware 인프라에 대한 보다 철저한 제어 및 보고

 

먼저 VVol이란 무엇인지 알아보겠습니다.

VVol은 표준 SCSI 볼륨입니다. 어떤 의미에서는 RDM과 마찬가지입니다. ESXi의 vSCSI 스택을 통과한다는 사실을 제외하면 말입니다. VVol은 어레이 기반 기능을 효율적으로 사용하는데 지장을 주지 않고, vSphere에서 Storage vMotion, SDRS, SIOC 및 다른 가상 스토리지 기능을 사용할 수 있는 역량을 제공합니다. VVol에는 몇 가지 다른 유형이 존재합니다. 주요한 세 가지 유형은

  1. Config VVol--모든 VM에 존재하며 VMX 파일, 로그, 그리고 몇 가지 파일 서술자가 포함되어 있습니다. 크기는 4GB입니다.
  2. Swap VVol--모든 VM에는 전원을 켜면 자동으로 생성되고 전원을 끄면 삭제되는 Swap VVol이 있습니다.
  3. Data VVol--모든 가상 디스크에는 생성되는 어레이마다 볼륨이 하나씩 있습니다. 각각 다른 설정 및 정책이 적용될 수 있습니다.

VVol이 어떤 모습인지 또 어떻게 보고되는지는 기반이 되는 어레이에 따라 어느 정도 차이가 있습니다. FlashArray에서는 VVol은 다른 볼륨과 다름이 없습니다.

그렇기 때문에 현재 사용하는 기능을 동일한 방식으로 사용하고 관리할 수 있습니다. VVol과 “일반” 볼륨(예: VMFS를 호스트하는 볼륨)의 가장 큰 차이점이라고 한다면 호스트가 어떻게 주소를 할당하는가 하는 것입니다. “일반” 볼륨은 정상적인 LUN ID로 표시됩니다. 예를 들어, “일반” 볼륨이 255로 표시되면, VVol은 sub-lUN이기 때문에 255:4로 표시되는 것입니다. 1차 볼륨을 통해 주소가 할당됩니다.

스냅샷

어레이에서 가상 디스크의 granularity을 확보했기 때문에, VMware 스냅샷은 필요가 없어집니다. VMware 스냅샷은 유사시 구동되지만 장기적 사용 목적이 아니기 때문에 존재 자체로 또는 통합 중 삭제 시 성능에 지장을 줄 수 있습니다. 그러나 이러한 granularity 및 연결은 VASA를 통해 확보할 수 있기 때문에, FlashArray의 스냅샷을 사용할 수 있습니다!

FlashArray 스냅샷의 혜택:

  • 볼륨의 크기에 상관 없이 즉각적으로 생성
  • 생성시 100% 중복제거로 용량 소비 제로
  • 성능에 저하 제로. copy-on-write나 redirect-on-write 방식이 아니기 때문에 생성 시는 물론 수명주기 전반에서 VM의 성능에 지장을 주지 않습니다.

이제 VVol을 사용하는 VM을 클릭하고 스냅샷을 생성하면 FlashArray 스냅샷이 생성됩니다.

 

VMware 툴이 설치됐다면 FlashArray 스냅샷을 생성하기 전에 게스트 파일 시스템을 거부하도록 만들어 가상 디스크 당 granularity은 ‘물론’ 파일 시스템 상의 일관적인 스냅샷이 제공하는 혜택을 확보할 수 있습니다.

스냅샷에는 두 가지 “유형”이 있습니다.

먼저 관리되는 스냅샷이 있습니다. 이 스냅샷은 VMware가 인지하고 있습니다. 다른 말로 하면, VMware를 통해 생성된 스냅샷입니다. (예: GUI, PowerCLI 등) 그리고 관리되지 않는 스냅샷이 있습니다. 이 스냅샷은 VMware가 인지하지 못합니다. 본질적으로 어레이에 직접 생성된 스냅샷입니다. 두 스냅샷 모두 복원을 위해 사용될 수 있습니다. VMware는 관리되는 스냅샷만 확인할 수 있지만, FlashArray는 관리되는 스냅샷 및 관리되지 않는 스냅샷 모두를 확인할 수 있습니다.

 

프로토콜 엔드포인트

그렇다면 1차 볼륨이란 무엇일까요? 프로토콜 엔드포인트(PE)라 불리는 1차 볼륨은 기본적으로 VVol을 위한 마운트(mount) 포인트입니다. ESXi 서버에 수동으로 프로비저닝해야 하는 유일한 볼륨입니다. multipathing이 본 볼륨에 설정되며, 큐 깊이 한계값 또한 설정됩니다. FlashArray의 경우, Purity 운영 환경이 VVol이 포함된 버전(5.0)으로 업그레이드되면 프로토콜 엔드포인트가 자동으로 생성됩니다. 본 볼륨은 “퓨어-프로토콜-엔드포인트(pure-protocol-endpoint)”라 불립니다.

이 PE는 VVol을 프로비저닝하려고 하는 호스트 또는 호스트 그룹에 연결할 수 있습니다. 새로운 VM 또는 새로운 가상 디스크가 생성되면, VVol들이 생성되고, 어레이는 이들을 호스트에 연결된 적절한 PE에 종속시킵니다.

FlashArray가 한 개 이상의 PE를 지원할까요? 물론입니다. FlashArray에 한 개 이상의 PE가 필요할까요? 전혀 아닙니다. 자동으로 생성되는 PE 한 개면 모든 호스트에 충분합니다. 향후 블로그에서 이 주제에 대해 보다 자세히 다뤄 보겠습니다.

 

스토리지 컨테이너

자, 이제 VMFS가 없는 상태에서, VM을 프로비저닝할 때 무엇을 선택할까요? 데이터스토어가 없는데 ‘어디에서’ 그 무엇인가를 선택할까요?

VMware의 훌륭한 VVol 설계 기능은 VM 프로비저닝 및 관리의 모습/느낌/경험을 많이 바꾸지 않습니다. 그렇기 때문에 VMware 관리자들은 VMFS 대신 VVol을 사용하기 위해 새로운 프로세스를 익힐 필요가 없습니다. VVol의 경우, 데이터스토어는 여전히 존재하지만, 이는 파일 시스템이나 물리적 오브젝트만이 아닙니다. 이제, 통칭 스토리지 컨테이너라 불리는 VVol 데이터 스토어를 선택하면 됩니다. 스토리지 컨테이너는 별다른 설정 적용을 필요로 하지 않습니다. VVol이 설정되는 방법은 VMware 스토리지 정책상 설정에 어떠한 기능들이 할당되었느냐에 기반합니다. 이 부분에 대해서는 나중에 자세히 설명해 드리겠습니다.

스토리지 컨테이너는 하나의 어레이만을 나타냅니다. 이는 VMware VVol 설계의 요구사항 중 하나입니다.

현재 FlashArray는 스토리지 컨테이너를 자동 생성하며, 기본 크기는 64TB입니다. 크기는 설정 가능합니다. 현재 FlashArray 당 하나의 스토리지 컨테이너만 지원한다는 점을 기억하십시오. 어레이 기반 기능들은 데이터스토어 수준이 아니라 VVol 수준에서 적용되기 때문에 이는 크게 문제가 되지 않습니다. 그렇기 때문에 다수의 데이터스토어(복제 granularity, 스냅샷 granularity, 리스토어, 보고 등)에 대한 과거의 우려사항은, 말 그대로 ‘과거’의 문제가 됩니다.

하지만, 퓨어스토리지는 향후 다수의 스토리지 컨테이너 지원을 도입할 예정입니다.

도입 시기를 늦추기로 한 주요 이유는 이 스토리지 컨테이너 오브젝트 유형에 매우 적합한 기능 하나를 VVol이 나온 뒤 출시하기 위해서입니다.

스토리지 컨테이너는 데이터스토어처럼 표시되며, 추가 스토리지 마법사를 통해 VMFS와 동일한 프로세스로 마운트 된다는 사실에 주목하십시오.

 

마지막으로, 스토리지 컨테이너는 VMFS처럼 탐색할 수 있습니다.

스토리지 컨테이너는 본질적으로 VVol 요소와 관계들의 추상적 개념으로, ‘파일 시스템인 척’을 합니다.

VASA Provider

물리적 연결과 데이터스토어에 대해 알아봤습니다. 그렇다면 vCenter와 FlashArray간의 통신은 어떨까요? 이 부분에서 VASA가 필요합니다. 지난 vSphere 5.0에 도입된 VASA(vStorage API for Storage Awareness)는 VMFS 볼륨이 어떻게 설정되는지(RAID 레벨, 계층화, 복제 등)를 표시할 수 있도록 어레이와 VMware 간의 기본적인 통신을 제공했습니다.

소수의 공급업체만 VASA 1.0을 지원했고, 극소수의 고객만 실제로 이를 사용했습니다. vSphere 6.0에서 VASA 2.0이 출시됐습니다. 여기에는 VVol의 초기 릴리즈(버전 1)가 포함됩니다. vSphere 6.5에서, VASA 3.0이 출시되고 VVols 2.0이 함께 제공됐습니다. VVols 1.0과 VVols 2.0의 가장 큰 차이점은 복제입니다. VMware는 VVols 2.0이 나오기 전까진 어레이 기반 복제를 지원하지 않았습니다. 어레이가 이를 지원했다면 어레이 기반 복제를 사용할 수 있었겠지만, 실질적으로 재해복구(DR)를 구현할 수 있는 효과적인 방법이 없었습니다. VASA 사양은 재해복구를 지원하지 않았기 때문입니다. 이 기능이 없었기 때문에 VVol 1.0 도입이 상당히 지연됐습니다.

VASA 3.0은 복제를 위한 사양과 복제된 가상 볼륨의 재해복구를 위한 SDK를 추가로 탑재하고 있습니다. VVol의 DR 자동화에 PowerCLI를 사용하는 것에 대한 아래 글을 참조하십시오.

https://blogs.vmware.com/virtualblocks/2017/03/01/automating-vvol-dr-power-cli-6-5/

FlashArray VASA Provider는 버전 3입니다. FlashArray VVol을 구현하려면, vSphere 6.5를 사용해야 합니다. vSphere 6.5는 상당한 혜택을 제공하기 때문에, 이를 가능한 빨리 도입하는게 좋다고 생각합니다.

 

FlashArray VASA 서비스는 다음과 같은 주요 기능을 제공합니다.

  1. FlashArray 컨트롤러의 내부에서 실행됩니다. 퓨어스토리지의 VASA Provider를 위해 VM을 구현하거나 HA를 설정할 필요가 없습니다. 각 컨트롤러는 그 프로바이더의 복제를 실행합니다.
  2. 퓨어스토리지의 프로바이더는 액티브-액티브 구성입니다. 각 VASA 인스턴스는 vCenter로부터 호출을 수락할 수 있습니다.
  3. FlashArray에는 VASA “데이터베이스”가 존재하지 않습니다. 컨트롤러가 연관돼 있는 한, VASA 서비스는 stateless입니다. 모든 바인딩 정보, VVol 식별자 등은 데이터와 동일한 위치, 바로 플래시에 저장됩니다. 그렇기 때문에 만에 하나 두 컨트롤러가 모두 고장나는 상황이 발생하더라도 두 대의 새로운 컨트롤러를 연결하고 전원을 켜기만 하면 됩니다. VASA 서비스가 시작되어 중단된 지점에서부터 다시 가동됩니다. 아무것도 다시 저장하거나 구축할 필요가 없습니다.

VASA Provider를 vCenter에 등록하는 경우, FlashArray는 vCenter에 FlashArray가 제공할 수 있는 모든 기능들에 대한 정보를 제공합니다. 어떤 기능인지는 공급업체마다 다릅니다.

스토리지 정책 기반 관리 및 스토리지 프로파일

퓨어스토리지는 다음의 기능을 제공합니다.

기능 가치 설명
FlashArray 예/아니오 VM/VMDK가 FlashArray에 구축되길(또는 구축되지 않길) 원합니다.
FlashArray 그룹 FlashArray 이름 VM/VMDK가 특정 FlashArray에 구축되길 원합니다.
QoS 예/아니오 VM/VMDK가 QoS가 활성화된 FlashArray에 구축되길 (또는 구축되지 않길) 원합니다.
로컬 스냅샷 가능 예/아니오 VM/VMDK가 한 개 이상의 스냅샷 정책이 활성화된 FlashArray에 구축되길 원합니다.
로컬 스냅샷 간격 분, 시, 일, 월 또는 연 단위의 빈도 VM/VMDK가 특정 간격의 스냅샷 정책으로 보호되길 원합니다.
로컬 스냅샷 보존 분, 시, 일, 월 또는 연 단위의 빈도 VM/VMDK를 위한 로컬 스냅샷이 특정 기간동안 보존되길 원합니다.
복제 가능 예/아니오 VM/VMDK가 하나 이상의 복제 정책이 활성화된 FlashArray에 구축되길 원합니다.
복제 간격 분, 시, 일, 월 또는 연 단위의 빈도 VM/VMDK가 특정 간격의 복제 정책으로 보호되길 원합니다.
복제 보존 분, 시, 일, 월 또는 연 단위의 빈도 VM/VMDK를 위한 특정 시점 기반 복제가 특정 기간동안 보존되길 원합니다.
대상 위치 FlashArray 이름 VM/VMDK가 특정 FlashArray에 복제되길 원합니다.
최소 복제 동시성 타겟 수

VM/VMDK가 특정 수 이상의 FlashArray에 복제되길 원합니다. 3곳의 타겟 위치와 2곳에 대한

동시성을 보유하고 있는 경우, VVol이 이를 준수하려면 3곳 중 2곳에 복제가 되어야 합니다.

 

그렇다면 이 기능들은 무엇을 의미할까요?

프로바이더를 등록한 후, VMware 기능(IOPS 한계 등)을 원한다면 이 기능들을 혼합 사용해 vCenter 내부에 스토리지 정책을 생성할 수 있습니다.

 

그러므로 위의 정책에는 다음과 같은 항목이 포함될 것입니다.

  1. FlashArray에 구축되어야 함
  2. 1시간마다 로컬 환경에서 스냅샷을 생성해야 함
  3. 스냅샷은 하루 동안 보존되야 함
  4. 1시간 간격으로 복제되야 함

정책을 생성한 후에는 이를 VM에 할당할 수 있습니다.

VM이 생성된 후 또는 새로운 VM을 프로비저닝할 때 할당 작업을 수행할 수 있습니다. 아래에서 VM을 템플릿으로 구현하고 위의 정책을 할당해보겠습니다. 정책 준수 여부를 표시함으로써 vCenter는 자동적으로 어떤 스토리지가 이 정책을 이행할 수 있는지 알려줍니다.

정책을 선택하면, vCenter는 그 정책을 준수하지 않는 모든 데이터스토어를 걸러냅니다. 그렇다면 준수한다는 것은 무엇을 의미할까요? FlashArray를 위한 스토리지 컨테이너에 각 FlashArray에 해당 정책과 일치되는 하나 이상의 보호 그룹이 포함되어 있으면 그 컨테이너는 정책을 준수하는 것으로 판단합니다.  FlashArray 보호 그룹은 본질적으로 로컬 스냅샷 및/또는 복제 정책이 적용된 일관성 그룹입니다.

이는 지정된 세부 사항과 매칭 될 것입니다. 1시간 스냅샷이라고 지정하면, 그 뿐입니다. 1시간 스냅샷 정책을 포함하는 모든 보호 그룹이 반환됩니다. 또한 일부는 복제가 될 수도 있고, 또 되지 않을 수도 있습니다. 1시간 스냅샷을 준수하지만 복제는 되지 않는 그룹이 반환되길 원하는 경우, 복제 기능을 ‘아니오’로 선택하면 됩니다.

여기서는 스냅샷/복제 기능이 포함된 정책을 선택할 것이기 때문에, 복제 그룹을 선택해야 합니다. FlashArray에서는 복제 그룹이 보호 그룹입니다. 그렇기 때문에, 포함되길 원하는 보호 그룹을 선택할 수 있습니다.

 

프로비저닝 마법사를 종료하면 FlashArray가 다음과 같은 기능을 수행합니다.

  1. VVol을 생성 하고(설정 및 데이터),
  2. 지정이 된 경우 이들을 적절한 보호 그룹에 추가한 후,
  3. VM을 구동하는 ESXi 호스트에 표시된 PE에 종속시킵니다.

정책 기반 프로비저닝의 아주 유용한 혜택은 초기 위치뿐만 아니라 VVol이 그대로 유지되도록 보장해 준다는 것입니다. VVol이 있는 보호 그룹에 가서 복제 스케줄을 1시간에서 30분으로 변경하면, VMware는 그 VM 또는 가상 디스크를 준수하지 않는 것으로 표시합니다.

이제 설정을 수정하거나, VASA에 의해 적절하게 설정되도록 정책을 VM에 다시 적용할 수 있습니다.

 

기타 혜택

여기까지가 FlashArray VVol의 아키텍처에 대한 설명이었습니다. 아직 다루지 않은 추가 기능들이 있어 몇 가지 소개해 드리겠습니다.

 

VM 보고

새로운 VM이 생성되면, FlashArray는 VVol을 위한 볼륨을 생성합니다. 그런데 이외에도 퓨어스토리지는 볼륨 그룹이라는 새로운 오브젝트를 도입했습니다. 볼륨 그룹은 가상 머신을 나타냅니다. 볼륨일 뿐이기 때문에, 그룹에 대한 보고를 통해 VM 전체에 대한 보고를 하거나 개별 VVol에 대한 보고를 할 수 있습니다.

여기에는 VM 또는 볼륨에 대한 실시간 보고와 이력 보고가 포함됩니다. 또한, FlashArray에서는 이제 각각의 가상 디스크가 얼마나 효과적으로 감소되는지 확인할 수 있습니다.

 

가상 디스크 삭제 취소

VMFS에 있는 VM에서 가상 디스크를 삭제한 경우, 설정 여부가 불확실한 백업에 의존해야합니다. FlashArray는 볼륨을 삭제하면 삭제된 볼륨은 삭제된 볼륨 폴더로 이동해 24시간 동안 유지되기 때문에 그 24시간 동안 복구가 가능합니다. VVol으로부터도 동일한 혜택을 얻을 수 있습니다. VVol도 볼륨이기 때문입니다. 그래서 VM에서 가상 디스크를 삭제하면 사전 설정된 백업이 없는 경우 하루 동안 삭제를 취소할 수 있습니다.

 

간단함

당연한 것 같지만, 간단함은 VVol에서 큰 차이를 만듭니다. VMware가 공급업체에게 부여하는 의사결정의 많은 재량권은 복잡성으로 연결될 수 있습니다. 퓨어스토리지는 VVol 구현을 최대한 간단하게 유지하기 위해 노력했습니다. Purity를 업그레이드한 후, VMware 환경으로 VVol 프로비저닝을 단 몇 분 안에 설정하고 시작할 수 있습니다.

 

연성

아주 중요한 문제입니다! VMFS의 경우 VMware VM에서 물리적 서버로 또는 다른 하이퍼바이저 등으로 데이터를 이동하려면 변환이나 호스트 기반의 복사본이 필요했습니다. 이 때문에 지금도 Raw Device Mapping(RDM)을 사용하는 이들이 있습니다. RDM에도 단점은 있습니다. FlashArray에 구축된 VVol의 경우, 이는 더 이상 문제가 되지 않습니다. FlashArray에 구축된 VVol은 기존의 일반적인 볼륨입니다. 중대한 차이점이라고 한다면 sub-lun 으로서 주소가 할당된다는 것뿐입니다.

그렇기 때문에, 현재 RDM을 보유하고 있다면, VVol일 수도 있어서 sub-lun으로 추가하기만 하면 모든 것이 끝납니다. 이제 VVol이 됩니다. 물리적 서버에 볼륨으로 표시되었을까요? sub-lun으로 표시됩니다. 짠! 이제 VVol이 됩니다. 변환이나 복제는 필요하지 않습니다. 볼륨을 공유하길 원하십니까? ESXi에 sub-lun(VVol)으로 연결하고 동시에 다른 비 ESXi 호스트에 일반적인 방식으로 연결합니다. 모든 것이 끝납니다. VVol이면서 동시에 “일반적인” 볼륨이 됩니다. 기존 볼륨이나 스냅샷을 VVol으로 가져오기 하는 과정은 아래 링크의 글에 설명되어 있습니다. (앞으로 FlashArray에 대한 보다 세부 내용을 알려 드리겠습니다.)

http://www.codyhosterman.com/2017/04/importing-a-vvol-snapshot-with-powercli/

VMFS에서 FlashArray에 구축된 VVol으로 이동하면 보다 큰 데이터 이동성을 확보할 수 있습니다. VVol의 추가적인 종속성에 대해 많은 사용자들이 우려해왔던 것과는 정반대입니다. 전용 파일 시스템(VMFS)이 없기 때문에 이러한 문제가 사라집니다.

FlashArray vSphere 웹 클라이언트 플러그인

VMFS와 마찬가지로, vSphere 웹 클라이언트 플러그인(Web Client Plugin)은 가치를 배가시킵니다. 퓨어스토리지는 새로운 VVol 기능들을 포함하도록 플러그인을 업데이트했습니다.

 

스토리지 컨테이너/프로토콜 엔드포인트 프로비저닝

스토리지 컨테이너를 마운트하기 전에 ESXi 호스트에 프로토콜 엔드포인트가 프로비저닝 되어 있어야 합니다. 이를 위해서는 GUI/CLI/REST를 사용해 PE를 호스트나 호스트 그룹에 추가하고 스토리지 컨테이너를 vSphere 내부에 마운트할 필요가 있습니다.

퓨어스토리지의 플러그인에서는 이 모든 프로세스가 자동화됩니다. 클러스터를 선택하면 PE가 호스트로 프로비저닝되고 스토리지 컨테이너가 마운트됩니다. 모든 것이 몇 번의 클릭으로 완료됩니다.

 

VVol 기반 VM을 위한 VVol 탭

VM의 가상 디스크에 대한 FlashArray의 기본 볼륨 정보를 표시합니다.

이 탭에서 또는 VM의 메뉴를 우클릭하면 몇 가지 워크플로우에 액세스할 수 있습니다.

 

VM 삭제 취소

퓨어스토리지는 앞서 말한 삭제된 가상 디스크의 복구 프로세스를 자동화했습니다. 선택된 VM에 속하는 삭제된 볼륨 폴더에서 VVol을 찾으면 됩니다. 원하는 VVol을 선택하면 자동으로 가져오기 되어 VM으로 다시 첨부가 됩니다.

 

기존 VVol 또는 VVol 스냅샷 가져오기

이 작업은 VM의 VVol 기반 가상 디스크(또는 그 디스크의 모든 스냅샷)로 동일한 어레이에 있는 다른 VM으로 복제본을 표시할 수 있도록 합니다. 이는 데이터베이스의 개발/테스트에 유용한 기능입니다.

 

VVol 또는 VVol 스냅샷으로 기존 VVol 덮어쓰기

이 작업은 VM의 VVol 기반 가상 디스크(또는 그 디스크의 모든 스냅샷)로 동일한 어레이에 있는 다른 VM으로 복제본을 표시할 수 있도록 합니다. 이전의 경우와 유사하지만 새로운 복제를 생성하는 대신 덮어쓰기를 합니다.

 

VASA 및 스토리지 정책 설정

FlashArray vSphere 웹 클라이언트 플러그인의 Home 화면에는 VVol과 FlashArray 설정을 지원하는 몇 가지 새로운 기능이 있습니다.

 

VASA Provider 등록

FlashArray를 클릭하고 register storage provider를 선택하면, VASA Provider와 vCenter가 해당 어레이에 동시에 등록됩니다.

 

스토리지 정책의 자동 생성

일부 스토리지 정책을 자동으로 생성하려면, FlashArray에 있는 보호 그룹을 가져오기합니다. 그러면 플러그인이 이 설정을 스토리지 정책으로 변환합니다. 예를 들어, 로컬 스냅샷 간격 및 보존, 복제 간격 및 보존 등이 포함됩니다.

오늘은 여기까지 하겠습니다!

베타 버전이 마무리 단계에 있기 때문에 피드백에 따라 몇 가지 수정이 이뤄질 것입니다.

3분기 출시를 기대해주십시오!