물리 서버도 Auto Scaling 이 됩니다! Elastic DRS

VMware Cloud on AWS는 AWS의 베어메탈 서버를 기반으로 구성되지만,

놀랍게도 베어메탈 서버를 기준으로 Auto Scaling을 지원합니다.

클라우드이기 때문에 가능한 VMware Cloud의 특화된 필수 기능이지요.

 

아시다시피 On-premise라면 물리서버가 자동으로 늘어나고 줄어든다는 개념은 절대 불가능한 일입니다.

서버는 물리자산이기 때문에 항상 고정이고, 고정된 자산을 기존에 미리 장착/구성 해놓지 않고서는,

하이퍼바이저 host의 순간적인 증가는 불가능합니다.

 

하지만, VMware Cloud on AWS에서는 사용량에 따라 자동으로 host를 늘릴수도 줄일수도 있습니다.

또는 API를 통해 시간에 맞추어 서버를 증설하고, 원하는 시간에 수동으로 서버를 줄일 수도 있습니다.

해외에서는 아침마다 서버를 추가하고, 저녁마가 서버를 삭제하는 기업도 있다고 합니다.

 

실제 확인해보면 수동으로 추가하던, 자동으로 추가하던 10~20분 정도면 추가가 완료됩니다.

서버 한대 설치하고, 케이블 연결하고,  네트워크 구성하고, 하이퍼바이저구성하고, 스토리지 구성하고......

이 모든 작업이 10분대에 가능하다는 것이지요!

 

그럼 Auto Scaling이 어떻게 가능한 것인지 살펴보겠습니다.

 

VMware Cloud on AWS의 모든 SDDC에는 Elastic DRS라는 정책이 기본으로 적용되어 있습니다.

Cloud Console에서 SDDC를 선택해 보면 왼쪽 아래에 Elastic DRS라는 정책이 걸려 있는 것을 확인할 수 있는데요.

해당 정책은 기본으로 구성되며, 사용자의 선택에 의해 disable 할수는 없습니다.

단, 2 host SDDC 구성의 경우 'Default Storage Scale-out' 정책만 사용할 수 있습니다.

 

Elastic DRS는 host의 사용량을 기반으로, 자동으로 추가하기도, 제거하는 정책입니다.

각 host의 CPU/MEM/DISK 사용량 데이터와 SDDC의 Elastic DRS 정책(임계치)이 5분마다 측정되며,

측정 결과에 따라 Scale-out과 Scale-in 이 수행됩니다.

 

위 박스에서 아래쪽에 있는 'EDIT EDRS SETTINGS'를 선택하면, 다양한 정책중에서 원하는 정책을 선택할 수 있습니다.

여기서 보면 Elastic DRS를 줄여서 EDRS라고 하는군요.

사실 DRS도 'Distributed Resource Scheduler'의 줄임말이니,

EDRS는 'Elastic Distributed Resouce Scheduler'라는 뜻입니다.

 

Elastic DRS의 정책은 총 4가지로 원하는 정책을 선택하여 즉시 적용이 가능합니다.

 

 

1. Default Storage Scale-Out(기본값)

 

모든 SDDC에 기본적으로 적용되는 정책으로,

전체 물리 스토리지 사용량을 기준으로 75%를 넘었을 때 자동으로 host를 추가합니다.

여기서의 75%는 물리사용량을 말하는 것으로, 중복제거와 압축 후의 용량을 기준으로 하며,

실제 사용하는 디스크는 물리사용량보다 훨씬 크다고 할 수 있습니다.

host 증가시 CPU 코어수와 메모리가 host 1대 만큼 추가되며, 스토리지 용량 및 성능(IOPS)가 선형적으로 증가합니다.

 

리소스	최저 임계값	최고 임계값
CPU	자동 축소 안함	자동 확대 안함
메모리	자동 축소 안함	자동 확대 안함
스토리지	자동 축소 안함	75%

예를 들어 아래 상황에서는,

물리 디스크 사용량은 49.41TB지만, 중복제거와 압축을 통해 28.88TB의 데이터를 절감하였습니다.

즉, 실제 데이터 사용량인 Effective 스토리지 용량은 총 78.29TB(49.41TB+28.88TB) 입니다.

물리 디스크를 기준으로 보았을때는 62.06TB(82.75TB * 75%)를 넘는 경우에 자동으로 host가 추가됩니다.

 

 

2. Optimize for Best Performance

 

사용량 증가에 따른 성능 감소를 줄이기 위해, 빠르게 Scale-out을 결정하고, 느리게 Scale-in이 진행됩니다.

기본적으로 CPU 90%, 메모리 80%, 스토리지 70% 중 하나라도 최고 임계값에 미치게 되면, host가 추가됩니다.

하지만, 제거시에는 CPU 50% 미만, 메모리 50% 미만, 스토리지 20% 미만의 3가지 조건이 모두 충족되야 제거됩니다.

즉, 증가될 때는 하나의 조건이라도 맞아 신속히, 축소될 때는 모든 조건을 맞춰서 신중하게 진행합니다.

 

리소스	최저 임계값	최고 임계값
CPU	50%	90%
메모리	50%	80%
스토리지	20%	70%

클러스터에서 확장 가능한 최소 host 수와 최대 host 수를 정해서 정해진 범위 내에서 탄력적인 운영이 가능합니다.

만약 Scale-in 조건에 들더라도 최소 host 수에 도달했다면, Scale-in은 수행되지 않습니다.

 

 

3. Optimize for Lowest Cost

 

host수를 최소로 유지하면서, 'Optimize for Best Performance' 보다 빠르게 호스트를 제거합니다.

기본적으로 CPU 90%, 메모리 80%, 스토리지 70% 중 하나라도 최고 임계값에 미치게 되면 host가 자동으로 추가되며,

해당 정책은 'Optimize for Best Performance'와 동일합니다.

하지만, host 제거시에는 CPU 60% 미만, 메모리 60% 미만, 스토리지 20% 미만의 3가지 조건이며,

CPU와 메모리의 임계값이 'Optimize for Best Performace'보다 10% 높아 조금 더 빨리 제거됩니다.

 

리소스	최저 임계값	최고 임계값
CPU	60%	90%
메모리	60%	80%
스토리지	20%	70%

이 정책 역시,

클러스터에서 확장 가능한 최소 host 수와 최대 host 수를 정해서 정해진 범위 내에서 탄력적인 운영이 가능하며,

Scale-in 조건에 들더라도 최소 host 수에 도달했다면, Scale-in은 수행되지 않습니다.

 

4. Optimize for Rapid Scale-Out

 

사용량의 급격한 변화에 대비하기 위해 미리 Scale-Out을 통해 사전에 대비하는 방식으로

임계치에 도달하는 리소스 종류에 따라 증가되는 host의 수가 다릅니다.

만약 CPU나 메모리의 최고 임계값에 도달한다면, 기본값으로 4대(수정 가능)가 증가되며,

스토리지가 최고 임계값에 도달한다면, 다른 정책과 마찬가지로 1대의 host가 증가됩니다.

 

처음에 1대 배포하는데 10~20분 정도의 시간이 소요된다고 말씀드렸는데요,

만약 4대가 증가한다 하더라도, 동시에 배포가 진행되기 때문에 동일하게 10~20분정도의 시간이 소요됩니다.

 

기본적으로 CPU 80%, 메모리 80%, 스토리지 70% 중 하나라도 최고 임계값에 미치게 되면 host가 자동으로 추가되며,

해당 정책은 'Optimize for Best Performance'보다 CPU부분이 10% 더 적어 빠르게 Scale-out에 돌입합니다.

하지만, 자동으로는 증가된 host를 제거하지 않으며, Cloud Console에서 수동으로 제거해야 합니다.

 

리소스	최저 임계값	최고 임계값
CPU	자동 축소 안함	80%
메모리	자동 축소 안함	80%
스토리지	자동 축소 안함	70%

클러스터에서 확장 가능한 최소 host 수와 최대 host 수 그리고 원하는 확장 host수를 정할 수 있습니다.

 

 

물론 이 모든 정책이 아무런 경고없이 이루어지지는 않습니다.

사전에 관리자로 등록된 Cloud Admin 계정들에게, host 증가에 대한 경고 메일이 발송되게 됩니다.

 

예를 들어 Default Storage Scale-out 정책의 경우,

75%가 임계치지만, 70%를 초과할때쯤 현재 상황에 대한 경고 및 대응을 요청하는 메일이 발송됩니다.

5% 정도의 여유상태에서 경고를 받으면, host 추가를 막기 위해 용량을 더 신경써서 관리하거나,

기존 미사용 용량을 삭제하거나 하는 식의 대응이 필요하겠지요.

 

또한, 잦은 Scale-out과 Scale-in의 반복을 막기 위해 아래 2가지 안전장치를 두고 있습니다.

• Scale-out 발생시 30분간 추가적인 Scale-out 금지
• Scale-out 발생 후 3시간 이내 Scale-in 금지

이처럼 VMware Cloud on AWS는 클라우드의 장점을 살려, 베어메탈 host도 Scale-out이 가능합니다.

클라우드기 때문에 사용한 기간과 자원만큼만 비용을 지불하면 되고요.

트래픽이 몰리거나, 특정기간에만 사용자가 몰리는 등 특성이 있는 서비스의 경우 아주 유용하게 사용할 수 있습니다.

즉, VMware Cloud on AWS에서 베어메탈 기반의 Scale-out은 당연히 가능합니다!