VMware vSAN

[번역] Revisiting vSAN’s Free Capacity Recommendations

출처 : https://blogs.vmware.com/virtualblocks/2020/01/13/revisiting-vsan-free-capacity-recommendations

관리자가 관리하는 리소스 유형 중 스토리지가 가장 어려울 수 있다. 수요는 종종 예측 수준을 넘어 증가하며, 오래된 아키텍처로 문제를 해결하는 것은 일반적으로 큰 자본 비용과 복잡성을 추가하는 것을 의미했다. 공간 효율성과 스토리지 회수 기술은 용량 임계값이 충족되면 잠재적으로 지연될 수 있지만, 결국 스토리지 용량에 대한 우려가 대두된다.

vSAN은 호스트에 공유 스토리지를 제공하고 관리하는 3계층 아키텍처에 대해 다른 접근 방식을 취한다. 단일 데이터스토어에서 전체 클러스터로 스토리지 용량을 제공하기 위해 클러스터에 있는 vSAN 호스트의 디스크리트 디바이스 용량을 집계한다. vSAN은 호스트 간에 적절한 수준의 데이터 복원력을 보장하고 통신 또는 하드웨어 오류 조건 시 자동으로 복구하는 역할을 한다. 스토리지의 설계와 관리를 단순화하는 반면, vSAN의 아키텍처는 사용 가능한 공간을 유지하기 위해 특별한 고려사항을 가지고 있는데, 이는 때때로 혼란을 야기한다. 이 게시물은 vSAN의 사용 가능한 공간 권장 사항에 대한 이유를 명확히 하기 위해 노력한다.

vSAN의 여유 용량

vSAN의 여유 공간은 두 가지 매우 중요한 기능을 제공한다.

VMware는 vSAN Design and Sizing Guide, VMware Docs, vSAN Operations Guide, vSAN Sizing Tool, 수많은 블로그 게시물을 포함하여 용량 싸이징 가이드에 대해 동일한 권장 사항을 제시하는 많은 리소스를 제공한다. 이 지침은 정책 변경, 재조정, 복구 등과 같은 느린 공간 활동의 경우 클러스터의 vSAN 스토리지 용량의 약 25-30%가 사용 가능한 상태로 유지되도록 권장한다. 왜 이런 경우인지 살펴봅시다.

HCI를 통한 용량 관리 - 다른 사고 방식

vSAN의 용량 관리에 있어 "사용 가능한 공간"은 클러스터 전체에서 단일 값으로 간주되는 경우가 많다. 백분율 또는 기가바이트/테라바이트 단위. vSAN은 클러스터당 단일 데이터스토어를 제공하므로, vSAN은 UI에서 이 용량 활용도를 잘 렌더링하여 그림 1과 같이 사용 가능한 용량을 명확하게 분류한다.

Figure01-1024x598.png

그림 1. 용량 소비는 UI에서 단일 값으로 렌더링되지만 장치 전체의 합계임

vSAN은 사용 가능한 공간을 훨씬 더 개별적인 수준에서 해석한다. 호스트, 명시적 장애 도메인, 디스크 그룹 및 개별 디스크까지. 사용 가능한 빈 공간이 있는 *어디*가 문제가 되기 때문에 이 작업을 수행해야 한다. vSAN은 "반선호도" 접근 방식을 사용하여 중복 데이터를 배치한다. 그림 2와 같이 초기 배치 결정, 고장 조건, 유지보수 모드 진입 작업, 스토리지 정책 변경 또는 데이터 재조정 시 vSAN은 복원력을 제공하는 다른 데이터 복사본과 겹치지 않는 데이터를 배치할 위치를 찾는다. 스토리지 용량은 이러한 개별 Disk로 구성되므로 일부 디바이스는 개체 구성 요소를 전체적으로 보유할 수 있는 용량이 없을 수 있으며, 이는 데이터를 어디에 배치할 것인지에 대한 vSAN의 결정에 영향을 미친다.

Figure02-1024x571.png

그림 2. 일부 데이터에 사용 가능한 공간을 사용할 수 없는 간단한 예

위의 간단한 예에서 볼 수 있듯이 각 호스트에는 사용 가능한 용량 백분율이 있는 스토리지 디바이스가 있지만 특정 호스트만이 복원력 설정을 준수하기 위해 해당 데이터를 저장할 수 있다.

대규모 클러스터에 대한 사용 가능한 용량 가이드라인(소규모 클러스터 대비)

표준 vSAN 클러스터는 3개에서 64개의 호스트를 지원한다. 전체 용량의 약 25-30%가 프리라는 지침은 모든 크기의 클러스터에 적용된다. 이것은 일시적인 활동을 수행하는 데 필요한 공간의 추정이며, 일반적인 시나리오에서는 단일 호스트 재구축으로 기본적인 N+1 기능을 제공할 수 있는 충분한 공간이기도 하다.

매우 작은 클러스터 또는 명시적 장애 도메인을 사용하는 클러스터에서는 각 호스트(또는 장애 도메인)가 더 큰 용량 비율을 기여한다. 이 경우, 일시적인 활동과 호스트 장애를 위한 충분한 공간이 있는지 확인하기 위해 약간 더 여유 있는 용량으로 실행하는 것이 현명할 수 있다. N+2 이상에 대한 요구 충족은 호스트 장애 시나리오에 필요한 여유 용량 양에도 영향을 미칠 수 있다. 클러스터 크기 결정에 대한 자세한 내용은 StorageHub의 vSAN Cluster Design - Large Clusters versus Small Clusters 대형 클러스터 대 소규모 클러스터 문서의 이 섹션을 참조하십시오.

vSAN에 대한 지침과 기존 스토리지 비교

사용 가능한 공간의 필요성을 설명할 때 기존 스토리지 어레이에 보다 익숙한 새로운 vSAN 사용자는 다음과 같은 응답에 대응한다. "어레이에 이와 같은 요구 사항이 없는데 왜 이렇게 권장되는 수준의 여유 공간을 유지해야 하는가?" 분산 스토리지 아키텍처는 다르다는 점을 기억하자. vSAN은 하나 이상의 물리적 엔클로저(호스트)의 장애를 흡수하고 여전히 데이터 가용성을 제공할 수 있습니다. 3계층 아키텍처에서 어레이 인클로저를 잃는 것은 훨씬 더 극적인 사건이다. 어레이가 다른 엔클로저와 동시에 미러링되지 않는 한, 해당 데이터의 총 가용성을 의미한다.

HCI는 스토리지를 제공하기 위해 컴퓨팅 호스트를 사용하기 때문에 운영 규율은 클러스터가 적어도 하나의 호스트의 손실을 흡수하기에 충분한 컴퓨팅, 메모리 및 스토리지 용량 리소스를 가지고 있는지 확인해야 한다. 때때로 운영 3계층 환경에서 무시되는 N+1 이상의 접근 방식은 항상 클러스터 설계 및 운영에 권장되는 방식이었다.

흥미롭게도, 대부분의 스토리지 어레이는 스토리지 용량 조건이 자체 내부 임계값에 도달했을 때 어려움을 겪는다. 관리자는 그 원인을 파악할 수 없을 수 있다. 가비지 수집 루틴과 데이터 중복 제거와 같은 데이터 후 처리 활동이 영향을 받아 성능 또는 효율성이 저하될 수 있다.

vSAN 관리자에 대한 용량 관리 작업

좋은 소식은 vSAN이 데이터 배치를 관리한다는 것이다. 스토리지 정책을 통해 특정 복원력 설정이 할당된 데이터가 다른 데이터 복사본과 어떤 식으로든 중복되어서는 안 된다는 것을 알고 있다. vSAN은 스토리지 정책의 "desired state" 데이터 구성을 지속적으로 모니터링하고 있으며 항상 준수 상태를 보장하기 위해 조정될 것이다.

관리자의 간단하지만 중요한 작업 중 하나는 VMware 지침당 사용 가능한 공간이 충분한지 확인하는 것이다. vSAN 6.7 U3을 포함한 모든 버전의 vSAN에 대해 권장 추정치는 25-30%이며 단순히 클러스터 전체의 사용 가능한 공간을 의미한다. vSAN의 경보 및 자동화된 기능은 클러스터가 아닌 디스크 또는 디스크 그룹의 조건에 크게 기초한다는 점에 유의하십시오.

스토리지 용량 소비량 모니터링이 그 어느 때보다 용이하다. vSAN은 vCenter에서 클러스터의 과거 용량 활용도를 제공하여 쉽게 추세 조정 및 분석할 수 있도록 지원 자세한 내용은 vSAN Operations Guide에서 Observing Storage Capacity Consumption Over Time을 참조한다.

vSAN 클러스터가 권장 사용 가능한 공간보다 작은 공간에서도 작동할 수 있는가? 그렇다, 그런 일이 일어나는 것을 막는 것은 아무것도 없다. VMware는 vSAN 클러스터에서 사용 가능한 용량이 25-30% 미만인 운영 방식을 승인하고 있는가? 아니다. 제공된 지침은 이러한 일시적인 데이터 관리 작업을 수행하고 호스트 장애를 흡수하기 위한 vSAN의 기존 행동과 요구를 반영한다.

용량 제한에 근접한 vSAN 클러스터 수용

중요한 용량 상태 시나리오를 방지하기 위해 적절한 운영 관행이 시행되어야 한다. 용량 제한에 가깝게 또는 용량 제한에 따라 실행되는 것은 데이터 및 서비스의 가용성을 촉진하는 관행이 아니며, 어떤 아키텍처에서도 권장되지 않는다. 다행히도 vSAN의 아키텍처는 스토리지 어레이보다 작은 증분으로 용량을 빠르게 추가하는 데 효과적이다. 두 가지 옵션이 있다.

vSAN 6.7 U3은 용량 경색 상태를 처리하기 위해 여러 가지 새로운 기능을 추가했는데, 예를 들어 데이터스토어에서 VMDK를 수동으로 다운로드 및 삭제하고 VM 전원을 끄기 위한 지원 등이 그것이다. 이러한 작업들은 이전에는 vmkfstools의 사용이 필요했지만 이제는 UI에서 수행될 수 있다. vSAN 6.7 U3 또한 용량이 긴장된 조건에서 대규모 정책 변경 그룹을 관리하기 위한 새로운 논리를 추가했다. 이는 비이상적인 조건에서 관리를 단순화하지만, 현재 진행 중인 목표는 충분한 양의 여유 용량을 유지하는 권장사항을 준수하는 것이어야 한다.

요약

vSAN은 설계, 작동 및 최적화가 더 쉬운 스토리지를 제공한다. 스토리지에 대한 이러한 분산 접근방식은 여유 공간 관리에 대한 지침이 기존의 3계층 아키텍처와 다르다는 것을 의미한다. IT의 핵심 헌장은 데이터와 서비스의 가용성을 보장하는 것임을 기억하자. 설계 및 운영 방식이 이러한 목표를 지원하는 것은 당연하다. VMware의 무료 용량 권장 사항을 따르면 원하는 결과를 얻을 수 있다.

 

[번역] Monitoring vSAN Performance

출처 : https://blogs.vmware.com/virtualblocks/2020/01/21/monitoring-vsan-performance/

어떤 환경에서든 성능 문제의 근본 원인을 파악하는 것은 어려울 수 있지만, 수백 개의 가상 워크로드가 아니더라도 수십 개의 환경이 실행되고 있는 상황에서 정확한 원인을 정확히 파악하고, 완화 옵션을 이해하는 것은 숙련된 관리자라도 어려울 수 있다. vSAN 클러스터는 로컬로 연결된 디스크로 구성되므로 vCenter에는 애플리케이션에서 개별 스토리지 디스크까지 성능을 모니터링할 수 있는 진정한 통찰력 있는 툴이 내장되어 있다.

이 게시물의 목적은 vSAN 성능 모니터링의 핵심 영역을 강조하기 위한 것이다. vSAN 성능 문제 해결에 대한 자세한 내용은 Pete Koehler의 Troubleshooting vSAN Performance 백서를 참조하십시오.

vSAN 성능 모니터링

역사적으로 관리자는 하이퍼바이저의 다양한 계층에 있는 게스트 VM 내부와 스토리지 어레이에서 전통적인 3계층 스토리지를 사용하는 경우에 성능 데이터를 측정할 수 있는 다양한 옵션을 제공했다. 불행히도, 이러한 다양한 선택사항들은 종종 불완전하거나 부정확한 결과를 제공한다. 예를 들어, 스토리지 어레이는 VM에서 사용하는 전체 스토리지 경로에 대한 엔드 투 엔드 통찰력을 가지고 있지 않다. 운영체제가 자원의 독점적 소유권을 전제로 하고 자원 공유를 설명할 수 없기 때문에 VM에서 데이터를 측정하는 것은 때때로 똑같이 어려울 수 있다. 스택에서 가장 지능적인 위치인 하이퍼바이저에서 데이터를 추출할 때 vCenter는 이상적인 모니터링 영역이다. vSAN 지원 환경을 통해 vCenter는 엔드 투 엔드 스토리지를 보고 제어할 수 있다.

이제 성능을 모니터링할 수 있는 최적의 장소를 정했으니 vSAN 성능을 모니터링할 수 있는 방법을 자세히 살펴봅시다.

게스트 VM 수준

VM에 연결된 애플리케이션 및 OS 동작을 게스트 수준에서 볼 수 있다. IOPS, 처리량 및 지연 시간과 같은 메트릭을 이 수준에서 볼 수 있으며 중요 VM이 ESXi vSCSI 계층에서 보고 있는 효과적인 동작에 대한 이해를 확립하여 소스를 더 빠르게 격리할 수 있다. vSAN 관리자는 Monitor > Performance > Advanced 외에도 Monitor > vSAN > Performance를 클릭한 다음 VM에 대한 독립적인 가상 디스크 분석을 위한 VM 또는 Virtual Disks 탭을 선택할 수 있다.

vsanp-guest4.png

클러스터 레벨

vSAN은 클러스터 기반 스토리지 솔루션으로, VM 데이터가 반드시 VM이 상주하는 동일한 호스트에 상주하는 것은 아니라는 것을 의미한다. 보다 일반적으로 VM의 일부는 스토리지 정책에 의해 지시되는 "허용되는 장애"(FTT)의 양에 따라 여러 호스트에 분산된다. 예를 들어 FTT=1 및 RAID-1 미러를 사용하는 VM의 디스크(구성 요소)는 세 번째 호스트에 있는 감시 구성 요소와 함께 두 호스트에 상주한다. vSAN 데이터 배치 및 가용성에 대한 자세한 내용은 여기를 참조하십시오. 클러스터 수준에서 측정하면 클러스터 전체의 활동 수준을 이해하는 데 도움이 될 수 있다.