[번역] What is the Maximum vSAN VMDK Size?

출처 : https://blogs.vmware.com/virtualblocks/2020/01/16/what-is-maximum-vsan-vmdk-size/

vSAN에서 VMDK의 크기의 선택

최근에 vSAN의 VMDK 크기 모범 사례에 대해 질문을 받았다. 지원되는 최대 VMDK 크기는 62TB이다. vSAN 또는 vSphere 클러스터의 최대 규모에 대한 논의와 마찬가지로(이 게시물을 확인하십시오!), 이는 많은 흥미로운 요소와 함께 매우 미묘한 운영 논의다.

백엔드 데이터 배치

한 가지 문제는 더 많은 개체가 클러스터의 뒷부분에서 더 많은 스트라이핑을 유발한다는 것이다. vSAN 설계 및 싸이징 가이드의 설명에 따르면, 대형 VMDK(vSAN 개체)는 최대 255GB의 구성 요소 크기에 기초하여 많은 소규모 구성 요소로 "chunked" 처리될 것이다.

NumberOfFailuresToTolerate=1을 사용하는 단일 62TB VMDK는 클러스터에 500여 개의 구성 요소가 필요하다(이러한 구성 요소 중 많은 구성 요소가 동일한 물리적 디바이스에 상주할 수 있음). 62 x 1TB 볼륨 또는 1 x 62TB 사이에는 상당한 구성 요소 차이가 없다.

Cormac은 전에도 이 점을 설명했고, vSAN은 백엔드를 가로질러 큰 VMDK를 분할하는 작업을 꽤 잘 한다.

백업 작업

데이터를 백업하는 방법(게스트 에이전트, VADP 기반 변경 블록 추적, VAIO 기반 데이터 스트리밍)에 따라 더 적은 수의 VMDK에 영향을 미칠 수 있다. VADP는 일반적으로 VM당 단일 데이터 이동 경로에만 데이터를 전송하지만, 데이터를 여러 VM으로 분할할 수 있는 경우 데이터 백업의 병렬화를 더 크게 허용할 수 있다. CBT를 사용하여 영구적으로 전체 시스템을 실행하는 경우 62TB 백업은 초기 백업에 문제를 일으키지 않을 수 있지만, 큰 변경 사항이 도입될 경우 CBT 맵을 재설정하고 전체 백업이 필요한 경우 또는 vSphere Replication의 경우 더 문제가 될 수 있다. 대형 파일 서버의 경우 DFS를 활용하고 공유를 여러 VM으로 분할하면 추가적인 운영 민첩성을 제공할 수 있다.

볼륨을 분할하면 볼륨 레벨에서 작동하는 백업 소프트웨어가 더 쉽게 "예외" 볼륨으로 전환될 수 있으며, 독립 볼륨을 사용하면 백업할 필요가 없는 볼륨의 스냅샷을 만들 수 있다.

복구 작업에도 영향을 미칠 수 있다. 대부분의 데이터 복원은 본질적으로 작지만(잘못 삭제된 파일) 파티션이나 기타 더 큰 "블래스트 반경" 장애 도메인을 삭제하는 운영자 오류로 인해 복원 시간이 더 길어질 수 있다. 이러한 당면 과제는 VM의 전체 복제본을 유지하고 이 복제본을 활성화하거나 "즉각 복구" 스타일의 백업 솔루션(종종 NFS 또는 VAIO를 사용하여 데이터를 백업 공유)을 사용하여 크게 완화될 수 있다.

게스트 VM 성능

단일 vSCSI HBA를 사용하는 단일 VMDK가 단일 직렬 IO 대기열을 나타내는 것은 사실이다. 특정 지연 시간에 얼마나 많은 IOPS와 처리량을 달성할 수 있는지에 대한 실질적인 한계가 있으며, 드문 경우 더 많은 vSCSI HBA(멀티플렉싱할 수 없는 볼륨)가 필요할 수 있다. 긴 NVMe end-to-end 다중 대기열 IO 경로가 이를 완화한다. 이것이 일부 대형 데이터베이스 공급업체가 RA 등의 일부로 이 구성을 권장하는 이유라는 점에 유의하기 바란다

씬 프로비저닝 및 용량 관리

씬 프로비저닝은 VMDK가 증가해야 하므로 게스트 파티션과 파일 시스템을 지속적으로 확장해야 하는 번거로움을 피할 수 있는 강력한 기술이다. 불행하게도, 많은 현대 파일 시스템은 "thin unfriendly" VMDK가 효과적으로 'thick'하고 부풀릴 때까지 모든 쓰기를 파티션의 빈 공간으로 점차 리디렉션할 것이다. 이는 클러스터에서 vSAN Space Reclamation(영구적인 VDI 클러스터에 일반적으로 사용됨)를 사용함으로써 완화할 수 있다. 자세한 내용은 다음 비디오에서 #StorageMinute: vSAN Space Reclamation 및 안내서를 참조하십시오.

파일 시스템 문제

일부 레거시 파일 시스템은 최대 62TB까지 실행하는 것이 권장되지 않을 수 있다. 많은 Windows 관리자는 chkdsk 성능에 대한 우려 때문에 NTFS를 이 크기로 실행하지 않으며, EXT3 이상의 파일 시스템은 이 크기로 확장되지 않을 수 있다. 최신 파일 시스템(ReFS 및 XFS)은 이러한 문제를 가지고 있지 않지만, 알고 있어야 할 문제다.

기타 운영 고려 사항

로그를 자체 파티션 및 VMDK로 분리하고 분할하는 데 공통 설계가 사용된다. 이는 IO 이유(쓰기량이 많은 볼륨에 대해 RAID 1 설정)에 유용할 수 있지만, 볼륨을 가득 채우는 로그가 볼륨에 써야 하는 애플리케이션이 손상되는 것을 방지하는 데도 유용할 수 있다. 특히 자동 그루밍 기능이 없는 로그 시스템이나 var/log에 로그를 배치하는 방법을 발견하지 못한 애플리케이션 개발자의 경우.

최종 생각

vSAN은 관리자를 위해 대량의 볼륨을 관리하는 데 많은 신경을 쓰지만, 관리자는 가상 시스템과 VMDK 크기를 설계할 때 고려해야 할 다른 운영 고려 사항을 여전히 가지고 있다.