8.5 Cluster Size Consideration

클러스터 설계 및 싸이징의 유연성은 vSAN의 주요 이점 중 하나입니다. 클러스터 크기에 비해 vSAN의 성능 기능에 대한 질문으로 이어집니다. 클러스터가 더 많은 호스트와 더 적은 호스트로 구성된 경우 애플리케이션이 더 빨리 실행됩니까? 간단한 대답은 “아니오"이며 vSAN Cluster Design - Large Clusters Versus Small Clusters에서 다루었습니다.

성능과 클러스터 크기에 대한 문제는 4-호스트 클러스터와 64개 호스트의 총 기능을 비교하는 것이 아니라 수십 또는 수백 개의 호스트를 보유한 데이터 센터에서 비롯되며 성능에 대한 최적의 클러스터 크기에 대한 의문에서 비롯됩니다.

vSphere 클러스터는 공유 리소스의 경계를 정의합니다. 기존 vSphere 클러스터의 경우 CPU와 메모리는 두 가지 유형의 리소스로 관리됩니다. 여기서는 명확한 설명을 위해 네트워크 인식 DRS를 생략합니다. 호스트를 추가하면 클러스터에서 실행 중인 VM에 사용 가능한 CPU 및 메모리 리소스가 추가되는 것이 사실이지만, 이는 호스트가 추가됨에 따라 16vCPU SQL 서버 하나에 더 많은 기능이 추가된다는 것을 의미하지는 않습니다. 사용 가능한 물리적 리소스의 경계가 넓어졌을 뿐입니다. vSAN 기반 클러스터는 클러스터 리소스로 스토리지를 도입합니다. 클러스터의 호스트 수가 증가하면 스토리지 리소스의 가용성도 증가합니다.

vSAN의 데이터 배치

성능(및 가용성)의 요소를 파악하기 위해 vSAN에서 데이터를 배치하는 방법에 대해 알아보겠습니다.

기존의 공유 스토리지에서는 파일 시스템에 저장된 데이터가 어레이 또는 어레이의 여러(또는 모든) 스토리지 장치에 분산되는 경우가 많습니다. 이 기술을 “와이드 스트리핑"이라고도 하는데, 이는 장치 집합을 통해 성능을 향상시키는 방법이었고, 어레이 제조업체가 특정 형태의 RAID를 사용하여 전 세계적으로 모든 데이터를 동일한 크기로 보호할 수 있도록 했습니다. 와이드 스트리핑은 회전하는 디스크의 경우에도 절실히 필요했지만 All-Flash 어레이 및 기타 아키텍처에서는 여전히 일반적이었습니다.

vSAN은 다릅니다. 데이터 배치 및 이중화를 위한 접근 방식을 사용하는 것은 객체 기반 스토리지 시스템과 가장 유사합니다. 데이터 배치의 결정권자이며, 어떤 호스트가 데이터에 액세스할 수 있는지를 결정합니다. VMDK와 같은 개체는 모든 객체 데이터가 하나의 호스트에 있을 수 있습니다. 복원력을 달성하려면 이 개체를 vSAN 클러스터의 다른 위치(호스트)에 미러링하거나 RAID-5/6 소거 코딩을 사용하는 경우 여러 호스트(vSAN ESA를 사용하는 RAID 5의 경우 3개 또는 5개의 호스트, vSAN OSA를 사용하는 RAID-5의 경우 4개의 호스트, RAID-6의 경우 6개의 호스트)에 걸쳐 패리티 데이터로 데이터를 인코딩합니다. SPBM(Storage Policy-Based Management) 덕분에 이를 개체 단위로 규정할 수 있습니다.

vSAN 8 ESA에 새로 추가된 RAID 5는 이제 클러스터가 5개의 호스트로 확장될 때 스트라이프 폭을 2+1에서 4+1(또는 뒤로)로 자동 조정합니다.

따라서 클러스터가 4개의 호스트이건 64개의 호스트이건 간에 VM을 지정된 복원력 수준으로 저장하는 데 사용할 호스트의 수는 동일합니다. 일부 작업은 데이터를 조금 더 분산시킬 수도 있지만 일반적으로 vSAN은 가능한 한 적은 수의 호스트로 스토리지 정책에서 지정한 개체의 가용성을 달성하려고 노력합니다.

vSAN에서 사용하는 접근 방식의 이점은 장애 상황에서 뛰어난 복원력과 단순화된 확장성입니다. FTT(허용할 수 있는 장애) 수준이 개체에 할당되면 가용성(및 성능)은 특정 개체가 상주하는 호스트만 참조합니다. 클러스터에서 다른 오류가 발생할 수 있으며 해당 특정 개체에 영향을 미치지 않습니다. 다른 접근 방식에서 종종 발견되는 와이드 스트라이핑은 가용성을 위해 데이터가 의존하는 기여 리소스를 더 많이 도입하므로 환경의 취약성을 증가시킬 수 있습니다. 와이드 스트라이핑을 사용하면 확장이 더 어려워질 수 있습니다.

성능 문제에 관련된 클러스터 크기는 언제입니까?

물리적 리소스가 초과 구독되면 기존 vSphere 클러스터의 크기가 VM 성능에 영향을 미칠 수 있습니다. 초과 구독은 호스트의 지정된 하드웨어 기능에 대해 너무 많은 부담을 주는 워크로드가 있을 때 가장 일반적으로 발생합니다. VM에서 생성된 물리적 리소스(CPU 및 메모리)에 눈에 띄는 수준의 경합이 있으면 성능이 저하됩니다. DRS는 CPU 및 메모리 리소스 사용의 균형을 맞추고 경합을 해소하기 위해 클러스터의 호스트 전체에 워크로드를 보다 균등하게 재분배하는 것을 목표로 합니다.

vSAN 클러스터에서 스토리지는 클러스터의 리소스이기도 합니다. 이는 기존 3계층 아키텍처와는 다른 개념입니다. VM의 I/O 요구가 스토리지 장치의 지정된 하드웨어 기능에 비해 너무 부담스러운 경우 약간의 경합이 있을 수 있습니다. 이러한 상황에서 클러스터에 호스트를 추가하면 손실된 성능을 회수하여 스토리지 성능을 향상시킬 수 있지만, 애초에 경합으로 인해 성능이 저하된 경우에만 가능합니다. 클러스터의 호스트 전반에 걸쳐 이 데이터를 배치하고 밸런싱하는 것은 전적으로 vSAN의 책임이며 성능이 아닌 용량을 기반으로 합니다. DRS는 이러한 의사 결정에 참여하지 않습니다.

vSAN 클러스터의 성능은 주로 스토리지 스택에 있는 디바이스(캐시/버퍼, 용량 계층, 스토리지 HBA 등)의 물리적 기능과 호스트 간 통신을 제공하는 디바이스(NIC 및 스위치기어)에 따라 결정됩니다. .

개별 애플리케이션이나 호스트 기능에 대한 테스트는 소규모 클러스터나 대규모 클러스터를 통해 수행할 수 있습니다. 애플리케이션이나 호스트에 표시되는 결과에는 차이가 없습니다. HCIBench와 같은 도구를 사용하여 종합 테스트를 수행하는 경우 더 많은 호스트가 추가됨에 따라 클러스터의 전체 성능(IOPS 또는 처리량으로 정의됨)이 증가합니다. 이는 클러스터에 더 많은 호스트가 추가됨에 따라 작업자 VM이 증가하기 때문입니다. 스트레스 테스트 결과는 클러스터에 있는 모든 호스트의 합계를 다시 보고합니다. 각 호스트의 개별 성능 기능은 동일하게 유지됩니다.

네트워크 스위치는 어떻습니까?

일반적인 가정은 네트워크 전환 요구 사항과 클러스터 크기 사이에 어느 정도 상관 관계가 있어야 한다는 것입니다. 스위치기어에 연결된 호스트 수가 동일할 경우 클러스터 크기와 스위치기어 수요 사이에는 상관관계가 거의 없습니다. NIC 또는 NIC가 연결되는 스위치기어의 크기 요구 사항은 호스트 용량, 호스트가 구성하는 장비의 유형/성능, 애플리케이션 요구 사항, 사용되는 스토리지 정책 및 데이터 서비스, 성능에 대한 기대치와 가장 밀접하게 관련되어 있습니다.

스위치기어가 호스트가 주도하는 성능을 제공할 수 없는 경우 호스트 성능이 영향을 받을 수 있습니다. 이는 기본 스위치기어에 모든 스위치 포트에서 광고된 속도를 유지할 수 있는 백플레인, 처리 능력 또는 버퍼가 없을 수 있다는 신호입니다. 그러나 이 동작은 사용된 클러스터 크기 조정 전략에 관계없이 발생합니다. 추가 호스트를 추가하면 네트워킹 버퍼 제한이나 스위칭 ASIC의 내부 대기열 제한에 도달할 수 있습니다. 클러스터의 성능 요구 사항이 크게 증가할 것으로 예상되는 경우 초기 배포 시 적절하고 강력한 스위치를 배포하는 것을 고려하십시오.

또한 많은 일반적인 랙 상단형 스위치는 액세스 포트가 48개로 제한되어 있으므로 대규모 클러스터에서는 이러한 링크가 병목 현상을 일으키는 것을 방지하기 위해 스위치 간에 추가 처리량이 필요할 수 있습니다. 여러 스위치에 걸쳐 적절한 대역폭이 할당되었는지 확인하는 대규모 클러스터를 고려하고 리프/스파인 CLOS 설계 사용을 적극 고려하십시오. 4 x 25Gbps 커넥터에 대한 브레이크아웃 연결을 지원하는 100Gbps 스위치는 대규모 클러스터에서 점점 인기가 높아지고 있습니다. 이를 통해 가장 큰 클러스터라도 단일 리프 스위치 쌍에서 트래픽을 유지할 수 있습니다.

RDMA 스위치 지원

vSAN 7 업데이트 2에는 RDMA Converged over Ethernet 버전 2(RCoEv2) 지원이 도입되었습니다. 스위치 공급업체에 문의하여 RCoEv2 요구 사항을 충족할 수 있는지 확인하세요.

대규모 클러스터의 운영 고려 사항

또 다른 고려 사항은 클러스터를 패치하는 데 걸리는 시간입니다. 많은 고객이 클러스터를 중단 없이 업데이트하는 vSAN의 기능을 활용하지만 일부 고객은 여전히 고정된 패치 기간을 요구하는 방식으로 운영하기로 선택할 수 있습니다. 이 레거시 상태의 경우 여러 기술과 개선 사항을 사용하여 클러스터 패치 시간을 제한할 수 있습니다.

vSAN 업그레이드 - 최신 vSAN은 프로덕션 워크로드에 영향을 주지 않도록 더욱 주의를 기울여 더 빠르고 스마트하게 데이터 재동기화를 출시합니다.
ESXi 호스트 패치를 위해 “QuickBoot” 사용을 고려하십시오. vSphere Quick Boot는 물리적 호스트를 재부팅하지 않고 VMware ESXi™ 하이퍼바이저를 다시 시작하여 시간이 많이 소요되는 하드웨어 초기화를 건너뛰는 주요 서버 공급업체와 협력한 혁신입니다. 중단을 허용할 수 있는 워크로드의 경우 7 업데이트 2에서 Quickboot를 사용한 vLCM 패치에 도입된 “Suspend to Memory” 옵션을 고려하십시오. 이 옵션은 호스트 패치 속도를 크게 향상시키지만 가상 시스템을 작동시키지 못하게 됩니다. Quickboot 기능은 KB52477을 참조하세요. vLCM 및 vSAN에 대한 자세한 내용은 이 비디오를 참조하세요.

클러스터 크기 고려 사항이 중요한 부분은 운영 및 관리입니다. vSAN 클러스터 설계 - 대규모 클러스터와 소규모 클러스터 문서에서는 더 적은 수의 호스트로 더 적은 수의 vSAN 클러스터를 사용하는 환경과 더 적은 수의 호스트로 더 많은 수의 vSAN 클러스터를 사용하는 환경 간의 고려 사항 및 장단점에 대한 완전한 분석이 제공됩니다. .

성능이 중요할 때 고려해야 할 사항은 무엇입니까?

성능이 최우선이라면 호스트를 구성하는 개별 구성 요소와 구성은 물론 호스트를 연결하는 네트워킹 장비에 더 중점을 두어야 합니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

대량의 쓰기 버스트를 흡수하는 고성능 버퍼링 계층 장치.
장기간 지속되는 쓰기 수준을 수용할 수 있는 고성능 용량 계층 장치입니다.
여전히 컨트롤러가 필요한 스토리지 장치(SATA 또는 SAS와 같은 비NVMe 기반 장치)를 사용하는 경우 적절한 HBA입니다.
각 호스트에서 여러 디스크 그룹을 사용하여 병렬화를 개선하고 호스트당 전체 버퍼 용량을 늘립니다.
성능 목표를 달성하는 데 적합한 호스트 네트워킹(호스트 NIC).
연결된 호스트의 요구 사항을 지원하고 원하는 성능 목표를 충족하는 적절한 네트워크 스위치기어입니다.
성능에 맞춰진 VM 구성(예: 여러 VMDK 및 가상 SCSI 컨트롤러 등)

결론

vSAN의 데이터 배치 접근 방식은 클러스터의 모든 호스트에 데이터를 광범위하게 분산시키지 않는다는 것을 의미합니다. 문제의 VM 컨텐츠를 보유하고 있지 않은 vSAN 클러스터의 호스트는 VM 성능에 긍정적이거나 부정적인 영향을 미치지 않습니다. 동일한 하드웨어를 사용하여 리소스 경합이 거의 없거나 전혀 없는 경우, 적은 수의 호스트로 구성된 클러스터는 더 많은 수의 호스트로 구성된 클러스터에 비해 VM에 거의 동일한 수준의 성능을 제공합니다. VM에 최적의 성능을 얻으려면 호스트에서 사용되는 하드웨어와 스위칭에 중점을 두어야 합니다.