[번역] 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 문서에서 "슬랙 공간(slack space)"을 언급하는 경우 일반적으로 이러한 작업에 사용되는 임시 공간을 지칭한다.
  • 장애 시 사용한다. 각 호스트가 스토리지 용량 리소스를 제공하므로 호스트 운영 중단은 결국 데이터를 클러스터의 다른 위치에 배치해야 함을 의미한다. 모든 유형의 클러스터 설계는 적어도 하나의 호스트 장애를 흡수할 수 있는 충분한 자원을 가지고 있어야 한다. 기존의 3계층 아키텍처에서는 컴퓨팅과 메모리에만 적용되었지만 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 클러스터의 기존 호스트에 용량 추가(스케일업). 호스트 전체의 기존 디스크 그룹에 더 많은 용량 디바이스를 추가하거나 호스트 전체에 새 디스크 그룹을 추가한다. 클러스터 내 각 호스트에 용량을 추가하여 균일성을 유지하는 것이 이상적이다.
  • vSAN 클러스터에 호스트 추가(스케일아웃). 호스트가 추가되면 vSAN은 나머지 데이터를 클러스터의 호스트에 재분배하여 처리한다.

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

요약

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