많은 조직이 2012 년에 블록 스토리지 어레이의 현실을 처리하기 위해 "항상 Eager Zero Thick 사용"정책을 채택했습니다. vSAN으로 전환 할 때 씬 프로비저닝은 스토리지 비용을 절감 할 수있는 빠르고 안전한 방법으로 재검토되어야합니다.
1.관리 및 모니터링 오버 헤드– VMFS 블록 스토리지와 함께 씬 프로비저닝을 사용하는 경우 각 데이터 스토어에서 공간 부족 상태를 모니터링해야합니다.VMFS의 초기 버전은 용량 제한 (2TB)이 더 작았습니다.이로 인해 공간 부족 상태를 방지하기위한 추가 모니터링 오버 헤드가 발생했습니다.어레이에서 사용되는 더 큰 풀에서만 사용되는 씬 프로비저닝은이 오버 헤드를 줄였습니다.vSAN은 사용 가능한 모든 용량을 풀링하므로 씬 프로비저닝을 모니터링 할 단일 풀로 설정하는 어레이의 동작을 미러링합니다.vSAN 7U1은 vSAN 관리자가 용량이 적은 경우에 도움이되도록 데이터 스토어에서 용량을 숨길 수있는 "운영 예약"을 추가로 구현했습니다.
2.VMFS Performance overhead– 씬 프로비저닝 성능 오버 헤드는 수년 전에 우려되었던 것이었지만 시대는 변했습니다.역사적으로 VMFS에서 이것은 SCSI 예약으로 수행되었으며 성능 관련 문제를 일으킬 수 있습니다.ATS가이 문제를 완화했지만 vSAN은 클러스터 된 파일 시스템없이 블록 소유권을 처리하므로 설계 상이 문제가 없다는 점에 주목할 가치가 있습니다.vSAN은 기본적으로 "희소"라는 점에서 NFS와 더 유사하게 작동하며 VMDK를 "두꺼움"으로 설정하는 것은 쓰기 IO 경로의 순 최적화가 아니라 용량 예약입니다.
3.Array performance overhead – 일부 구형 스토리지 어레이는 씬 프로비저닝을 사용하기위한 성능 오버 헤드를 전달했습니다.디스크에 메타 데이터 맵을 저장하면 읽기 IO가 100 % 증폭되고 어레이의 절반에서 성능이 효과적으로 감소됩니다.vSAN (예 : 최신 어레이)은 메타 데이터 맵을 플래시에 저장하고이를 DRAM에 캐시하여이 문제를 방지합니다.
4.Shared VMDK Support requirements– 과거에 공유 된 VMDK (예 : Oracle에 필요한 것)에는 Eager Zero Thick 볼륨이 필요했습니다.이것은 더 이상 vSAN의 요구 사항이 아닙니다.
5.Vendor/application support– 일부 공급 업체가 불필요하게 오래된 모범 사례를 따르는 경우입니다.대부분의 주요 애플리케이션 공급 업체가 씬 및 일부 이전 홀드 아웃 (예 : Microsoft Exchange)을 지원한다는 점은 주목할 가치가 있습니다.씬 프로비저닝을 지원하도록 변경되었습니다.
6. 씬 프로비저닝은 신뢰성이 떨어졌습니다. 오랫동안 씬 프로비저닝을 사용해 온 사람이라면 씬 프로비저닝이 항상 앞뒤가 맞지 않는다는 것을 알 수 있었습니다. 나와 통화한 고객 중 한 명이 페타바이트의 차이를 발견했습니다. 윈도우즈에서는 드라이브가 50GB를 사용하는 것으로 보고되지만 씬 VMDK는 200GB를 사용하고 있는 것으로 표시되며 어레이는 VMFS에 500GB를 사용하고 있는 것으로 표시됩니다. 이는 NTFS/XFS/EXT4 등이 새로운 쓰기를 사용 가능한 공간으로 적극적으로 리디렉션하는 비친화적인 씬 파일 시스템의 결과입니다. 시간이 지남에 따라 씬 프로비저닝 절감 효과가 서서히 회복될 것입니다. TRIM/UNMAP을 통해 이 문제를 해결할 수 있었지만, 이러한 명령은 스토리지 컨트롤러를 압도하여 문제를 일으킨 전력이 있습니다. 또한 블록 회수 작업은 두 가상 시스템 계층에서 모두 관리하되 추가적인 VMFS 계층에서 관리해야 했습니다. vSAN은 단일 계층(가상 시스템에서 VMDK로)에서 회수함으로써 이러한 복잡성을 방지합니다. vSAN은 스케일아웃 컨트롤러 시스템을 사용하여 많은 성능 문제를 완화합니다. 컨트롤러 성능을 스케일아웃하여 메타데이터 작업을 처리하고 UNMAP 명령의 디스테이징을 지능적으로 제한할 수 있습니다. UNMAP 지원을 활성화하면 씬 프로비저닝을 20-30% 더 절약할 수 있습니다.
VMware vSAN은 씬 스토리지를 제공 할뿐만 아니라 씬을 유지할 준비가되어 있습니다.이렇게 20-50 %의 용량 절감 효과를 더하면 안전하고 일관된 방식으로 총 스토리지 비용이 절감됩니다.
디스크 폴트나 호스트장애로 60분이상 유지보수모드 실행 시 데이터 불균형 발생 할 수 있음
vSAN 6.7 이상 부터는 Automatic Rebalance 필수 사용
Automatic Rebalance 서비스 실행 시 즉시 데이터 마이그레이션이 실행 되며 워크로드에 형향 줄 수 있음
vSAN 6.7 이상 버전 부터는 Automatic Rebalance 서비스 실행 시 자동으로 클러스터의 데이터 불균형을 조정해 줍니다.
Automatic Rebalance(자동 재조정) : vSAN 6.7 U3 부터 디스크 재조정은 더 이상 수동 방법이 아니며 vSAN 클러스터 설정 내에서 서비스로 활성화해야 합니다(아래 설명).이 기능이 사용하도록 설정되어 있지 않으면 vSAN 디스크가 80% 용량 임계값을 초과할 때만 vSAN이 vSAN 디스크에 대한 재조정을 시작합니다.참고: 디스크 재조정은 vSAN 클러스터의 I/O 성능에 영향을 줄 수 있습니다.이러한 성능 영향을 방지하기 위해 임계값을 변경하거나 최대 성능이 필요할 때 자동 재조정을 끌 수 있습니다.
이 클러스터 수준 기능을 활성화 또는 비활성화하기 위한 토글은 그림 같이 vCenter의 구성 > vSAN > 서비스 > 고급 옵션 > "자동 재조정" 에서 찾을 수 있습니다.본 서비스를 실행 하면 개체 다시 동기화 메뉴를 보면 데이터 마이그레이션이 되는 것을 확인 할 수 있습니다.Data Rablancing이 시작되며 IOPS 및 Latency에 영항을 받는 것을 확인 할 수 있습니다.
그렇다면 Automatic Rebalance(자동 재조정)을 활성화해야 합니까?
예, vSAN 클러스터에서 자동 재조정 기능을 활성화하는 것이 좋습니다. 기능이 6.7 U3에 추가되었을 때 VMware는 고객 환경에 이 기능을 천천히 도입하기를 원했으며 vSAN 7에서도 이 방식을 유지했습니다. 최신 버전의 스케줄러 및 재동기화에 대한 최적화로 이 기능은 기본적으로 다음에서 활성화됩니다.
클러스터에서 자동 재조정을 일시적으로 비활성화하려는 드문 경우가 있을 수 있습니다.짧은 시간에 기존 클러스터에 많은 수의 추가 호스트를 추가하는 것이 그러한 가능성 중 하나일 수 있으며 기본 테스트에 사용되는 중첩된 랩 환경일 수도 있습니다.대부분의 경우 자동 재조정을 활성화해야 합니다.
CLOM(클러스터 수준 개체 관리자)은 개체 구성이 해당 스토리지 정책과 일치하는지 확인하는 역할을 합니다. CLOM은 해당 정책을 충족하는 데 사용할 수 있는 디스크 그룹이 충분한지 아닌지를 확인합니다. 또한 클러스터에서 구성 요소 및 감시 기능을 배치할 위치를 결정합니다.
CMMDS (Cluster Monitoring, Membership, and Directory Service )
CMMDS(클러스터 모니터링, 멤버 자격 및 디렉토리 서비스)는 네트워크로 연결된 노드 멤버 클러스터의 복구 및 유지 보수를 담당합니다. 호스트 노드, 디바이스 및 네트워크와 같은 항목의 인벤토리를 관리합니다. 또한vSAN개체에 대한 정책 및 RAID 구성과 같은 메타데이터 정보도 저장합니다.
DOM (Distributed Object Manager)
DOM(분산 개체 관리자)은 구성 요소를 생성하고 클러스터에 분산하는 역할을 합니다. DOM 개체가 생성되면 노드(호스트) 중 하나가 해당 개체에 대한 DOM 소유자로 지정됩니다. 이 호스트는 클러스터 전체에서 해당 하위 구성 요소를 찾은 후vSAN네트워크를 통해 해당 구성 요소로 I/O를 리디렉션함으로써 해당 DOM 개체에 대한 모든 IOPS를 처리합니다. DOM 개체에는 vdisk, snapshot, vmnamespace, vmswap, vmem 등이 포함됩니다.
LSOM (Log-Structured Object Manager)
LSOM(로그 구조 개체 관리자)은vSAN파일 시스템의 데이터를vSAN구성 요소 또는 LSOM 개체(데이터 구성 요소 또는 감시 구성 요소)로서 로컬로 저장하는 역할을 합니다.
Thin : 공간이 보장되지 않으며 디스크가 기록 될 때 사용됩니다. thick (Lazy Thick) : 공간이 블록에 의해 예약되어 나중에 초기화되므로 VMFS는 블록이 처음 작성 될 때 제로잉 이됩니다. EZT 또는 Eager Zero Thick : 전체 디스크가 제로잉이 되이므로 VMFS는 메타 데이터를 쓸 필요가 없습니다. VMFS는 메타 데이터 업데이트를 조정할 수 없으므로 공유 디스크 사용 사례에 필요합니다.
VMFS와 vSAN은 어떻게 다릅니까? 이러한 가상 디스크 유형은 vSAN에서 의미가 없습니다. vSAN 관점에서 모든 개체는 씬 입니다. 이것은 NFS가 항상 예비와 예약이 가능한 작업 (NFS VAAI 처럼)과 유사하지만 실제로 제로잉 하거나 VMFS에서와 같이 공간을 채우지 않는다는 사실을 바꾸지는 않습니다. VMFS에서 이것은 ATS와 WRITE_SAME을 사용하여 크게 완화 될 수 있습니다 (작업의 추가적인 개선으로). 얼마나 많은 데이터베이스와 응용 프로그램이 파일 시스템을 미리 작성하고 미리 할당 하는지를 감안할 때 저는이 이점에 대해 항상 모호했습니다. ext4 파일 시스템을 만드는 것이 더 느린 경우와 같은 몇 가지 코너 케이스가있을 수 있지만 정말로 신경 쓴다면 일반적으로 이 문제를 해결할 수 있다 (mkfs.ext4 -E nodiscard).
VAAI는 최신 All-Flash 어레이, VMFS6 개선 등의 이점이 있을 수 있지만 씬 VMDK에 대한 오버헤드는 크게 낮췄다.UNMAP/TRIM 스토리지 회수에는 씬 VMDK가 필요하므로 대부분의 사용 사례에서 씬(Thin)은 타당한 이유가 없는 기본값이 되도록 권장한다.
vSAN에서 씬을 선택하는 이유 EZT 디스크가 있다고해서 VMFS와 동일한 방식으로 vSAN 성능이 반드시 향상되는 것은 아닙니다. VMFS에서 먼저 제로잉을하면 메타 데이터 할당과 관련된 "번인"병목 현상을 피할 수있는 이점이 있습니다.
디스크 유형이 "thick"또는 "eager zero thick"으로 설정된 vSAN이 씬 vSAN 정책이 있음에도 불구하고 씩 동작하는 이유는 무엇입니까? 레거시 지원의 이유로 씩 VMDK 디스크 유형 집합은 SPBM 정책을 재정의한다. VM에서 "Thick Provisioning"을 사용해야 하는 경우 vSAN 옵션 "Object Space Reservation"이 100(Thick Provisioning)으로 설정된 상태로 VM에 스토리지 정책을 적용하십시오.
먼저 vSAN은 자체적으로 공간 예약을 제어합니다. Object Space Reservation 정책 즉 OSR = 100 % (Thick) 또는 OSR = 0 % (Thin). 이는 용량을 예약하고 클러스터의 공간 부족을 허용하는 할당을 방지하려는 경우에 사용됩니다.
In general, I recommend the default of “Thin” as it offers the most capacity flexibility and thick provisioning tends to be reserved for cases where it is impossible or incredibly difficult to ever add capacity to a cluster and you have very little active monitoring of a cluster.
FT 및 공유 디스크 사용 사례 (RAC, SQL, WFC 등)는 어떻습니까?
이 요구 사항은 vSAN에 대해 제거되었습니다. vSAN의 경우 이러한 기능을 활용하기 위해 개체 공간 예약을 너무 두껍게 구성 할 필요도 없습니다. VMFS는 공유 된 VMDK 메타 데이터 업데이트를 단일 소유자가 소유하는 방식으로 인해 여전히 몇 가지 이점이있을 수 있습니다 (vSAN 메타 데이터 업데이트는 분산되므로 문제가되지 않음).
Thin VMDK를 기본값으로 사용하면 무엇을 얻을 수 있습니까?
당신은 많은 공간을 절약합니다. 업계의 다른 사람들과 대화하면 용량이 20-30 % 절약됩니다. TRIM / UNMAP 자동 회수와 결합하면 더 많은 공간을 다시 크롤링 할 수 있습니다! 이를 통해 스토리지 비용을 크게 절감 할 수 있습니다. 추가로 중복 제거 및 압축은 OSR = 0 %이고 기본 씬 VMDK 유형을 선택한 경우에만 의도 한대로 작동합니다.
또한 자동 회수하도록 구성된 경우 공간 부족 상태가 발생할 가능성이 낮아 가용성이 높아질 수 있습니다. vSAN의 Eager Zero Thick 또는 Thick VMDK는 vSAN에 대한 과잉 약정을 방지하는 방식으로 용량을 예약하지 않고 단순히 더 많은 용량을 사용합니다.
초기 VXRAIL Manager에서 자동 배포하는 VXRAIL vCenter Server 방식
수동으로 VMware vCenter Server Appliance를 배포해서 Join 시키는 Customer-supplied vCenter 방식 이 있습니다.
- VXRAIL vCenter Server = VXRAIL Internal vCenter
VxRail의 초기 릴리스에서는 vCenter Server 장치를 VxRail 장치에 배포했습니다. 이 vCenter Server 장치의 라이센스가 VxRail에 포함되어 있습니다. 이 vCenter Server 배포를 "내부" 또는 "Internal vCenter"라고 합니다. 일관성을 위해 이 가이드에서 사용되는 용어는 VxRail vCenter Server입니다. VxRail은 VxRail vCenter Server의 배포 및 수명 주기 관리를 조정합니다. 이 VxRail vCenter Server는 배포된 VxRail 클러스터만 관리할 수 있습니다.
VxRail 장치는 선택적으로 VxRail 클러스터 외부에서 호스팅되는 호환 가능한 vCenter Server 환경에 가입할 수 있습니다. 이 기능을 사용하면 중앙 vCenter Server 인스턴스가 여러 VxRail 클러스터를 관리할 수 있습니다. 각 VxRail 환경은 vSAN 데이터스토어로 구성된 호스트의 클러스터로 vCenter Server 내에 나타납니다. 이 환경을 "external" 또는 "existing" vCenter Server라고 합니다.
일관성을 위해 이 가이드에서 사용되는 용어는 customer-supplied vCenter Server입니다.
이 vCenter Server 인스턴스는 VxRail 장치를 배포하기 전에 존재해야 하며 별도의 고객이 제공한 라이센스가 필요합니다. 고객이 제공한 vCenter Server의 배포, 구성 및 수명 주기 관리를 담당합니다.
VxRail 클러스터의 가상 인프라는 VxRail vCenter Server 또는 Customer-supplied vCenter와 같은 단일 vCenter Server 인스턴스에 의해 관리됩니다.
VxRail 장치를 배포할 때 vCenter 배포 유형이 선택되어 변경하기가 어렵습니다.
Customer-supplied vCenter 에서 VxRail vCenter Server로 변경하려면 출고 시 재설정해야 하며 모든 데이터를 VxRail 장치에서 지우고 다시 설치해야 합니다.
반면 VxRail vCenter Server를 Customer-supplied vCenter로 마이그레이션할 수는 있지만 제품 자격 확인 요청이 필요합니다.
참고 : Customer-supplied vCenter는 더 많은 구성 옵션을 제공하며 권장됩니다.
유형별 배포 방법
1. VxRail vCenter Server 7.0
VxRail 배포의 일부로 Embeded PSC가 있는 vCenter Server 인스턴스가 구성됩니다.
vCenter Server 및 PSC는 단일 Linux 기반 가상 시스템에서 호스팅됩니다.
Embeded PSC가 포함된 vCenter Server는 관리 중인 VxRail 클러스터에 배포되며 배포 후 클러스터 밖으로 이동할 수 없습니다.
VxRail vCenter의 라이센스는 VxRail vCenter Server용이며 Customer-supplied vCenter에 사용할 수 있도록 전송할 수 없습니다.
따라서 사용이 제한되거나 제한된 vCenter Server 라이센스로 간주 될 수 있습니다.
2. VxRail vCenter Server 6.0 – 6.7
VxRail 배포의 일부로 External PSC가 있는 vCenter Server 인스턴스가 구성됩니다.
vCenter Server와 PSC는 별도의 Linux 기반 가상 머신입니다.
VxRail vCenter Server와 PSC는 모두 관리 중인 VxRail 클러스터에 배포되며 배포 후 클러스터 밖으로 이동할 수 없습니다.
Use case VxRail vCenter Server는 다음과 같은 경우에 적합합니다. • Single VxRail clusters • Standalone environments
참고: Stretched clusters는 권장되지 않습니다. 왜냐하면 site-affinity rule(PFTT=0)이 사용되는 경우 ISL(Inter-Switch Link) 오류가 발생하고 vCenter와 동일한 사이트에 있지 않은 모든 가상 시스템의 전원이 꺼지기 때문입니다.
Limitations (6.x 및 7.0) • VxRail vCenter Server는 자체 VxRail 클러스터만 관리합니다. • 다른 VxRail 클러스터 또는 다른 ESXi 호스트를 관리할 수 없습니다. ▪ 고객이 제공한 vCenter Server로 사용할 수 없습니다. • 향상된 링크 모드는 VxRail 7.0.100 이상에서 지원됩니다. • Single Sign-On 도메인은 vsphere.local이므로 사용자 지정할 수 없습니다. • VxRail vCenter Server는 4.5.200 이전 버전의 VxRail 암호화를 지원하지 않습니다.
3. CustomerSupplied vCenter Server
다음 그림에서는 여러 VxRail 클러스터가 Customer-supplied vCenter 환경의 일부인 예를 보여 줍니다.
각 클러스터는 vCenter 내에서 별도의 클러스터로 나타납니다.
중앙 집중식 관리뿐만 아니라 동일한 vCenter 환경에 속하므로 vSAN 환경 간에 VM을 쉽게 마이그레이션하여 워크로드 균형을 최적화하고 VxRail 장치 업그레이드 및 확장을 간소화할 수 있습니다.
참고: CustomerSupplied vCenter Server 배포는 vCenter Server 장치에서 실행되는 물리적 서버 또는 가상 서버일 수 있습니다.
Use case Customer-supplied vCenter 솔루션은 다음과 같은 경우에 필요합니다. • VxRail이 기존 VMware 플랫폼에 추가되고 있으며 단일 관리 인스턴스가 필요합니다. • 여러 VxRail 클러스터가 배포되며 단일 관리 인터페이스가 필요합니다. • 2-노드 클러스터에는 vCenter Server를 배포할 수 없습니다.
VxRail 4.5.200 이전 버전에서는 다음과 같은 경우 Customer-supplied vCenter 솔루션이 필요합니다. • 확장된 클러스터는 솔루션의 일부입니다. • vSAN 암호화가 필요합니다. vSAN 클러스터에서 DARE(Data at Rest Encryption)를 사용하도록 설정하는 경우 KMS(Key Management Server)가 vSAN 클러스터 외부에 있어야 합니다.
Limitations • VxRail Manager는 고객이 제공한 vCenter Server를 업그레이드하지 않습니다. VxRail 장치 소프트웨어를 업그레이드하기 전에 릴리스 정보를 참조하여 필요한 최소 vCenter Server 릴리스 번호를 확인합니다. VxRail 업그레이드 전에 Customer-supplied vCenter를 업그레이드해야 할 수 있습니다.
• Customer-supplied vCenter 가 4.7 이전 버전을 실행하는 VxRail 클러스터에서 호스트되는 경우 RPQ가 필요합니다.
▪ VxRail 클러스터 종료 기능을 사용하려면 모든 VM의 전원을 수동으로 꺼야 합니다. ▪ vSAN 오류가 발생할 경우 vCenter를 원격 사이트에 백업하는 것이 좋습니다.
Notes • Customer-supplied vCenter는 라이센스에 대한 책임이 있습니다. • Customer-supplied vCenter를 사용할 경우 Log Insight가 활성화되지 않습니다. • vCenter HA 네트워크에 대해 하나의 공용 IP 주소만 지원됩니다.
