[번역] vSphere 7 DRS Scalable Share Deep Dive

출처 : https://frankdenneman.nl/2020/05/27/vsphere-7-drs-scalable-shares-deep-dive/

당신은 리소스 풀에 대한 당신의 관점을 완전히 뒤집을 수 없다. 예, 여전히 폴더(sigh)로 사용할 수 있지만 vSphere 7에서 새로 도입된 확장 가능한 공유 옵션을 사용하면 리소스 풀을 서비스 품질 클래스로 전환하거나 그 이하로 전환할 수 있다. 재밌겠다, 그렇지? 먼저 자원 풀의 전통적인 작업, 그들이 도입한 과제, 그리고 이러한 자원 분배의 새로운 전달 방식에 대해 살펴보자. 이해하려면 DRS가 예약되지 않은 리소스를 배포하는 방법의 기본 사항을 먼저 살펴봐야 한다.

계산 리소스 배포

클러스터는 리소스 풀의 루트다. 클러스터는 클러스터에 있는 모든 ESXi 호스트의 소모품 리소스 컬렉션을 구체화한다. 두 개의 호스트로 구성된 작은 클러스터의 예를 들어보자. 오버헤드 감소 후 각 호스트는 50GHz 및 50GB 메모리를 제공한다. 그 결과, 클러스터는 100 GHz와 100 GB의 메모리를 소비용으로 제공한다.

리소스 풀은 추가적인 추상화 수준을 제공하므로 관리자가 각 VM 또는 vSphere Pod를 개별적으로 마이크로 관리하지 않고 리소스 풀을 관리할 수 있다. 리소스 풀은 클러스터의 하위 개체다. 이 시나리오에는 HighShares를 사용하는 리소스 풀과 NormalShares라는 이름을 가진 리소스 풀(RP)이라는 두 개의 리소스 풀이 존재한다.

HighShares RP는 높은 CPU 공유 수준과 높은 메모리 공유 수준으로 구성되고, NormalShares RP는 정상적인 CPU 공유 수준 및 일반 메모리 공유 수준으로 구성된다. 그 결과 HighShares RP는 CPU 공유 8000과 메모리 공유 327680를, NormalShares RP는 CPU 공유 4000과 메모리 공유 163840를 받는다. 2:1의 두 RP 사이에 비율이 생성된다.

01-ShareRatio.png

이 예에서는 각각 vCPU 2개와 32GB가 포함된 VM 8개를 클러스터에 배치한다. HighShares RP에 6개, NormalShares RP에 VM 2개. 경합이 발생하면 클러스터 리소스의 2/3은 HighShares RP에, 클러스터 리소스의 1/3은 NormalShares RP에 주어진다. RP의 다음 단계는 부여된 리소스를 하위 개체로 나누는 것이다. 하위 개체들은 VM 및 vSphere Pod 같은 다른 수준의 리소스 풀 또는 워크로드 개체일 수 있다. 모든 VM이 100% 활성 상태인 경우 HighShare RP는 66GHz 및 66GB의 메모리를 사용할 수 있으며, NormalShares RP는 33GHz 및 33GB의 메모리를 사용할 수 있다.

그리고 이것은 자원의 분배는 Shares 값에 의해 "설명된" 원하는 비율을 따르기 때문에 완벽하다. 그러나 사용자의 실제 의도를 포착하지 못한다. 많은 고객이 다른 RP의 워크로드와 비교하여 워크로드의 상대적 우선 순위를 선언하기 위해 리소스 풀을 사용하므로 HighShare 리소스 풀의 모든 VM이 NormalShare RP의 VM보다 2배 더 중요하다. 정상적인 행동은 단지 수여된 자원들을 따라 지나가기 때문에 그런 식으로 작동하지 않는다.

이 예제에서 HighShares RP의 6개 VM 각각은 클러스터 리소스의 2/3에서 1/6을 얻는다. 즉 66Ghz & 66GB의 16% = ~11GHz & ~ 11GB인 반면 NormalShares RP의 두 VM은 클러스터 리소스의 1/2을 얻는다. 33 GHz의 50% & 33 GB = ~16 GHz 및 ~16 GB. 본질적으로 우선 순위가 낮은 그룹 VM은 개별 워크로드당 더 많은 리소스를 제공할 수 있다. 이런 현상을 우선순위 파이 역설(priority pie paradox)이라고 한다.

Scalable Shares

이 문제를 해결하고 리소스 풀 사이징을 많은 고객의 의도에 맞게 조정하려면 새로운 방법을 만들어야 한다. RP의 공유를 자동스케일링하여 RP 내부에 배치된 워크로드를 반영하는 기법. VM에 적합하며, 고순도(high-churn) 컨테이너형 워크로드에 필요하다. vSphere 포드 및 vSphere 네임스페이스에 대한 자세한 내용은 vSphere Supervisor 네임스페이스를 참조하기 바란다. 그리고 이 새로운 기능은 vSphere 7에 포함되어 있으며 Scalable Shares라고 불린다. (참으로 뒷이야기는, 초기 아이디어는 냅킨 뒤가 아니라 2012년 팔로 알토로 돌아가는 길에 비행기에서 발견한 기내 잡지에서 Duncan Epping과 내가 개발했다. 그것에 대해 특허상을 받는 것은 엄청난 영광으로 느껴졌다. 사람들이 새로운 기능에 대해 극찬하는 것을 보는 것은 훨씬 더 보람 있는 일이다.

Scalable Shares 활성화

Scalable shares 기능은 클러스터 수준 및 개별 리소스 풀 수준에서 사용할 수 있다.

03-Enable-Scalable-Shares-at-Cluster-Level.png

각 하위-RP는 확장 가능한 공유 기능을 자동으로 상속하므로 클러스터 수준에서 이를 활성화하는 것이 더 쉽다. 클러스터 수준에서 "실패하지 않은(unticked)" 상태로 두고, 각 개별 리소스 풀에서 확장 가능한 공유를 사용하도록 설정할 수도 있다. 특정 리소스 풀에 있는 각 RP의 공유 값은 자동으로 조정된다. 이 수준에서 설정하는 것은 서비스 제공업체들이 최상위 수준에서 클러스터를 분할하고 고객에게 정적 부분을 할당하면서 그 아래에 셀프 서비스 IAAS 계층을 제공하고자 하기 때문에 거의 의도된 것이다.

04-Enable-Scalable-Shares-at-Resource-Pool-Level.png

클러스터 수준에서 공유를 사용하도록 설정할 때 실제로 보이는 일은 발생하지 않는다. UI는 기능이 활성화되어 있음을 보여주지만, 표시된 공유 값이 자동으로 변경되지는 않는다. 이 값은 이제 공유 값 설정(높음/보통/낮음)에 따라 정적 값으로 전환된다.

05-HighShares-RP-Settings-with-Scalable-Shares-Enabled.png

우리는 그 시스템을 신뢰해야만 그 일을 할 수단과 방법을 가리지 않는다. 그리고 전형적으로, 그건 어쨌든 네가 원하는 거야. 우리는 당신이 역동적으로 변화하는 공유 가치를 계속 주시하기를 기대하지 않는다. 하지만 그것이 효과가 있다는 것을 증명하기 위해서, 우리가 커버 아래에서 무슨 일이 일어나는지 볼 수 있다면 좋을 것이다. 물론 할 수 있지만, 물론, 이것은 우리가 예상하는 것이 아니다. 정상적인 운영 중에. 공유 값을 가져오려면 vSphere Managed Object Browser를 사용한다. MOB에 대해 William(물론, 다른 누가)은 광범위하게 글을 썼다. 디폴트로 비활성화된 것임을 기억하자. 그러므로 이것을 활성화하는 방법에 대한 William의 지침을 따르기 바란다.

시나리오를 쉽게 따라갈 수 있도록 각 RP의 VM을 별도의 호스트에 그룹화했다. HighSharees RP에 배포된 6개의 VM은 호스트 ESXi01에서 실행되며, NormalSharees RP에 배포된 두 VM은 호스트 ESXi02에서 실행된다. 클러스터에 리소스 풀 트리를 만들면 RP 트리가 클러스터 내의 개별 호스트에 복사되기 때문에 이렇게 한 것이다. 그러나 특정 호스트에서 실행되는 VM과 연결된 RP만 복사된다. 따라서 ESXi01에서 리소스 풀 트리를 검토할 때 HighSharees RP만 표시되며 ESXi02의 리소스 풀 트리를 보면 NormalShare RP만 표시된다. 호스트의 RP 트리를 보려면 브라우저를 열고 MOB가 사용하도록 설정되어 있는지 확인한 다음 진행한다.

https://<ESXi-name-or-ipaddress>/mob/?moid=ha%2droot%2dpool&doPath=childConfiguration

William이 날 위해 이 경로를 추적해줘서 고마워. 확장 가능한 공유를 사용하도록 설정하기 전에 ESXi01을 검토할 때 다음 사항을 확인한다.

  • ManagedObjectReference:ResourcePool: pool0 (HighShares)
  • CpuAllocation: Share value 8000
  • MemoryAllocation: Share value: 327680

06-ESXi01-Local-Tree-HighShares-1536x784.png

ESXi02의 이미지를 잘라냈지만 여기에서 NormalShare RP 기본값은 다음과 같음을 알 수 있다.

  • ManagedObjectReference:ResourcePool: pool1 (NormalShares)
  • CpuAllocation: Share value 4000
  • MemoryAllocation: Share value: 163840

07-ESXi02-Local-Tree-NormalShares.png

리소스 풀 기본 공유 값

이 숫자들을 어떻게 선택하는지 궁금하다면, RP는 내부적으로는 4vCPU 16GB 가상 머신으로 크기가 지정된다. 정상 설정(기본값)을 사용하면 각 vCPU에 대해 CPU 공유 1000개와 각 MB에 대해 메모리 공유 10개(16384×10)를 얻을 수 있다. High Share setting 상은 vCPU당 2000 공유, MB당 20 공유. 낮은 공유 설정을 사용하면 CPU당 500 공유, MB당 메모리 5 공유를 얻게 된다.

08-HighShares-Scalable_Shares-enabled.png

활성화되면 확장 가능한 공유가 마법을 걸었다는 것을 알 수 있다. HighShares의 공유 값은 현재 CPU의 경우 24000이고 메모리 공유는 392160이다. 이 계산은 어떻게 이루어지는가?

  • 각 VM은 정상 공유 값으로 설정된다.
  • 각 VM은 vCPU 2개(2 x 1000 공유 = 2000 CPU 공유)
  • 각 VM은 32GB의 메모리가 있으며 = 327680 공유가 있다.
  • RP 내부에 6개의 VM이 있으며 모두 ESXi01에서 실행된다:
  • RP에서 활성화된 CPU 공유의 합계: 2000 + 2000 + 2000 + 2000 + 2000 + 2000 = 12000
  • RP에서 활성화된 메모리 공유의 합계: 327680 + 327680 + 327680 + 327680 + 327680 + 327680 = 1966080
  • 그 결과는 리소스 풀의 공유 수준에 의해 정의된 비율로 곱해진다.

세 값 사이의 비율(High:Normal:Low)는 4:2:1이다. 즉, HighShares RP는 12000 x 2 = 24000 CPU 공유, 1966080 x 2 = 3932160 메모리 공유를 부여받는다.

09-VM-entitlement-Scalable-Shares-.png

확인을 위해 MOB는 NormalShares RP의 조정된 값을 보여주는데, 이 값은 2 x 2000 CPU 공유 = 4000 CPU 공유, 2 x 163840 = 655360 메모리 공유다.

10-NormalShares-Scalable-Shares-enabled.png

각 VM의 최악의 경우 시나리오 할당(클러스터의 모든 VM이 100% 활성 상태인 경우)을 살펴보면 HighShares RP에서 VM 할당이 증가하고, NormalShares RP에서 VM 할당이 감소됨을 알 수 있다. VM7과 VM8은 이제 16GB가 아닌 최대 7GB를 제공하며, VM 1~6 할당량은 각각 3GHz와 3GB씩 증가한다. 쉽게 눈에 띄지만 최악의 경우 시나리오 할당은 RP 점유율 수준 비율을 모델로 만든 것이다.

11-Ratio-established-Scalable-Shares.png

RP 레벨에서 공유 레벨을 조정하면 어떻게 하시겠습니까? NormalSharees RP는 낮은 메모리 공유 수준으로 다운그레이드된다. CPU 공유는 그대로 유지된다. RP는 81920의 공유를 받아 현재 HighShares RP(327680 대 81920) 대비 4:1의 비율을 설정한다. 흥미로운 점은 MOB가 655360개의 메모리 공유를 이전과 같은 가치로 보여준다는 것이다. 왜일까? 왜냐하면 그것은 단지 RP에 있는 공유를 합친 것이기 때문이다.

12-Sum-of-Shares-Low-Memory-Shares-RP.png

테스트로 VM7의 메모리 공유를 327680에서 163840으로 줄였다. MOB는 655360에서 491520(327680+163840)으로 공유가 하락했다고 표시해, 해당 공유가 하위-객체들의 총 공유임을 입증한다.

13-Adjusted-VM-share-value.png

이것은 행동의 근본적인 변화라는 점에 유의하십시오. 확장 불가능한 공유 RP의 경우 공유 값은 형제 수준에서 상대적일 뿐이다. 즉, 리소스 풀 내의 VM이 해당 리소스 풀 내의 동일한 수준의 다른 VM과 리소스를 경쟁하는 경우 이제 터무니없이 높은 수(사용자 지정 또는 몬스터-VM)를 사용하는 VM이 클러스터의 전체 리소스 배포에 영향을 미침 리소스 풀 공유 값은 하위 개체의 합이다. 리소스 풀에 몬스터-VM을 삽입하면 리소스 풀의 공유 값이 자동으로 증가하므로 전체 워크로드 그룹이 이를 통해 이점을 누리게 된다.

HighSharees RP에서 발생하는 증가 비율을 확인하기 위해 VM7의 공유 값을 기본값인 327680으로 수정했다. high와 low 사이의 비율은 4:1이므로, HighShares에서 조정된 메모리 비율은 1966080 x 4 = 7864320이어야 한다.

14-Adjusted-Shares-HighShare-RP.png

NormalShares를 이 테스트의 시작과 유사한 정상 공유 값으로 되돌리지만 환경에 또 다른 High Share 값 RP를 추가하면 어떻게 될까? 이 테스트를 위해 vCPU 2개와 32GB의 메모리를 모두 갖춘 VM9과 VM10을 추가했다. 테스트 목적으로 HighShare RP VM과 유사한 ESXi01과 호환된다. ESXi01의 MOB는 새로운 RP HighShares-II: CPU 공유 8000, 메모리 공유 1310720에 대해 2:1의 비율로 다음 값을 나타낸다.

15-HighShares-II-Shares-Value.png

각 VM의 최악의 경우 시나리오 할당을 살펴보면 HighShares 및 NormalShares RP의 모든 VM에 대해 VM 할당이 감소하는 것을 알 수 있다. VM 1~6은 16%(11GHz 및 11GB)를 얻고 VM 7과 8은 클러스터 리소스의 50%(각각 5.5GHz 및 5.5GB)를 얻는다. 새로운 VM 9와 10은 각각 최대 11 GHz와 11 GB까지 할당할 수 있으며, 이는 RP 공유 수준 비율에 따라 Highshare RP의 VM과 동일하다.

16-Cluster-Resource-Distribution.png

HighShares-II RP를 제거하고 VM9 및 VM10을 새로운 LowShares RP로 이동하면 어떻게 될까? 이에 따라 배당된 RP가 각각 다른 3개로 4:2:1의 비율을 제공하는 상황이 조성된다. ESXi01의 MOB 뷰를 보면 LowSharees RP 공유가치가 수정되지 않고 HighSharees RP 공유가 4배 증가했다는 것을 알 수 있다.

17-HighShares-LowShares-MOB-view.png

ESXi01의 MOB 보기는 NormalSharees RP 공유의 공유 값이 4:2:1의 비율에 정확히 따라 현재 두 배로 증가했음을 보여준다.

18-NormalShares-MOB-view.png

이 RP 설계는 다음과 같은 최악의 경우 시나리오 할당 분포를 초래한다.

19-High-Normal-Low-RPs-1.png

VMs as Siblings

마지막으로 강조하고자 하는 시나리오는 RP 레벨에서 동일한 레벨로 구축된 VM이다. 흔한 일이다. 확장 가능한 공유가 없으면 Monster-VM이 리소스 풀에 그림자를 드리울 수 있으므로 이는 재앙이 될 수 있다. vCPU 16개 및 128GB를 사용하는 A(정상 공유 값) VM은 CPU 16000 공유와 메모리 1310720 공유를 받게 된다. 사전확인이 가능한 공유에서는 4000 공유와 163840 공유의 메모리 공유를 가진 normal 공유 값 RP를 왜소화할 것이다. 이제 확장 가능한 공유들이 하위 개체들의 쉐어 값을 부풀리면서, 경쟁의 장을 열어준다. 완전히 해결되지는 않지만 피해를 줄여준다. 항상 그렇듯이 레벨당 하나의 객체에 커밋하는 것이 권장된다. 리소스 풀을 사용한 후에는 해당 수준의 리소스 풀만 프로비저닝 g한다. VM과 RP를 동일한 수준에서 혼합하지 않는다. 예를 들어 VM "High-VM11"을 리소스 풀과 동일한 레벨에 배포했으며 DRS는 이 시나리오에 NormalShares RP가 있는 ESXi02에 배치했다. 공유 값 수준은 High로 설정되므로 vCPU 두 개에 대해 4000 공유를, 메모리 구성에 대해서는 655360 공유를 수신하여 내부 VM 두 개의 요구를 충족해야 하는 RP 구성에 일치한다.

17-VM-and-RP-as-Sibling.png

이 기록을 통해 Scalable Shares가 얼마나 뛰어난지 이해하여 공유 수준을 QoS 레벨로 전환하기를 바란다. 완벽한가? 아직이다, VM을 제자리에 프로비저닝하는 것에 대한 방탄복은 아니기 때문이다. 이에 대한 VEBA(4)를 탐색하고, 불일치를 방지하여 루트 배포된 VM을 자동으로 General RP로 이동하는 기능을 생성하는 것이 좋다.

마치면서

사용한 시나리오에서 전체 RP의 VM을 단일 호스트에 배치하는 것을 제한했다는 점에 유의한다. 일상적인 환경에서는 이러한 상황이 존재하지 않을 것이며, RP는 단일 호스트로 묶이지 않을 것이다. 내가 사용한 설정은 Scalable Shares의 내부 작업을 시연하기 위한 것이며 일반적인 vSphere 동작에 대한 보증 또는 설명으로 간주되지 않아야 한다. 플랫폼은 좀 더 이해하기 쉽도록 정돈되지 않은 시야를 제공하도록 크게 조정되었다.

최악의 경우 시나리오 수치는 일어날 가능성이 매우 낮은 상황을 보여주는 것이다. 각 VM이 동시에 100% 활성 상태인 상황이다. 그것은 메커니즘, 전형적으로 자원 수요 썰물(ebb)과 서로 다른 워크로드 사이의 흐름을 설명하면서 자원 분배를 강조하는데 도움이 된다. 이러한 시나리오에서 사용되는 예는 자원 풀과 공유만을 사용할 때 예상되는 자원 할당을 나타내지 않는다.