Everything fails on VMware Cloud on AWS

Everything fails all the time.

 

모든것은 언젠가는 수명을 다하기 마련입니다. 혹은 수명을 다하지 않았어도 고장날 수 있습니다.

클라우드를 유지하는 인프라도 마찬가지입니다.

즉, AWS의 물리적 인프라 기반인 VMware Cloud on AWS도 Fail이 발생할 수 있습니다.

 

이를 대비하여, VMware Cloud on AWS에서는 항상 인프라의 상태를 모니터링하며,

장애발생시 즉시 복구하기 위한 Auto-Remediation 기능을 제공하고 있습니다.

VMware Cloud on AWS는 VMware에 의해 직접 managed 서비스가 제공되고 있음으로,

Auto-Remediation과 관련된 모든 과정은 VMware의 자동화된 프로세스에 의해 제공되며,

사용자는 제공되는 SDDC의 고가용성과 빠른 서비스 복원력을 바탕으로 지속적으로 서비스를 이어갈 수 있습니다.

 

VMware Cloud on AWS는 AWS와 VMware의 공동 엔지니어링의 결과물로,

Auto-Remediation은 VMware와 AWS의 각각의 모니터링 시스템을 모두 활용하여 빠른 복구를 진행합니다.

 

1. VMware

개별 host의 상태를 점검하는 모니터링 서비스를 가동 중이며,

각 개별 구성요소들로부터 알람과 로그등을 항시 수집하고 있습니다.

문제가 감지될 경우 즉시 Alerts Engine을 통해 Autoscaler Service에 전달됩니다.

주로 Software 영역에 대한 모니터링을 담당합니다.

 

2. AWS

host 레벨의 문제가 감지될 경우 즉시 AWS Lambda를 통해 AWS host event가 Autoscaler Service에 전달됩니다.

주로 Hardware 영역에 대한 모니터링을 담당합니다.

 

 

만약 실제 문제가 발생하여 host가 접근이 불가능한 경우가 발생했다고 가정해봅시다.

이 경우 자동화된 복구 프로세스가 동작한다고는 하지만, 그래도 복구까지 잠시 시간이 걸릴 수 있습니다.

그래서 VMware Cloud on AWS에서는 모든 VM에 기본적으로 HA를 적용하고 있으며, 이는 절대 해제될 수 없습니다.

이를 통해, Host의 Fail 발생시 VM에 영향을 최소화 할 수 있습니다.

 

물론 FT가 아님 HA임으로, host Fail 발생시 VM이 자동으로 Fail 되지 않은 host로 이동하여 재부팅이 일어납니다.

하지만, vSAN 기반의 분산저장 시스템을 통해, 정책 기반의 가상머신들은 데이터가 유실되지는 않습니다.

 

가상머신의 이동과 별개로 모니터링 시스템은 지속적인 host의 상태를 확인하여,

일시적인 장애일 경우 host를 재부팅하며, 하드웨어 장애로 판단될 경우 신규 host로 교체합니다.

이 모든 상황에서도 SDDC는 계속 유지되고 있으며, vSphere 기반의 DRS 정책을 통해 VM의 배치를 최적화합니다.

 

즉 모든 host에 고르게 분산된 VM들은 다른 host Fail로 받을 수 있는 영향을 최소화 합니다.

 

 

그럼 실제 host에 대한 이슈가 발생하였을때,

Auto-scaler에 의해 Auto-Remediation이 이루어지는 과정을 자세히 살펴 보겠습니다.

 

 

1. 모니터링

 

VMware Cloud on AWS에서는 SDDC 내 모든 개별요소들에 대해 항상 모니터링합니다.

무엇인가 Fail이 감지되는 경우 이벤트는 즉시 Auto-Scaler Service로 전달되고 Auto-Remediation가 이루어집니다.

• 하드웨어와 소프트웨어의 Fail
• Fail 감지시 하드웨어를 자동으로 배포
• 가능하면 자동으로 Fail 복구
• 자동으로 복구가 불가능할 경우 SRE가 수동으로 개입

 

2. 일시적 이벤트 여부의 판단

 

가끔씩 일시적으로 감지되는 서비스 영향 없는 이벤트가 있을 수 있습니다. 

예를 들어, 서비스는 정상이지만 일시적인 관리 네트워크 접속 오류로 인해 host에 접근할 수 없다던가 하는 일들입니다.

Auto-remediation은 문제가 일시적인것인가, 아니면 해결이 필요한 것인가를 판단하기 위해 발생 후 5분간 기다립니다.

만일 5분 내 문제가 해결된다면, Auto-remediation은 별도의 액션없이 이벤트를 종료합니다.

 

 

3. 신규 host 추가

 

만일 에러가 5분 동안 해결되지 않았을 경우, 진짜 host가 필요한지 여부와 상관없이,

Auto-remediation은 SDDC에 즉시 새로운 host를 추가하기 시작합니다.

이는 실제 host 교체가 필요하다고 판단되었을때, 즉시 사용할 수 있도록 미리 준비해두는 단계입니다.

이때, 추가된 host는 Fail이 발생된 host가 교체될 때까지 별도의 비용이 지불되지 않습니다.

 

 

4. Fail의 종류 확인 및 복구 수행

 

Host는 다양한 이유로 Fail 될 수 있으며, Fail 원인에 따라 다양한 해결 방법이 존재합니다.

예를 들어, PSOD는 host의 재부팅이 필요하지만, vSAN 디스크의 Fail은 소프트 리부팅으로도 해결될 수 있습니다.

이러한 상황을 자동으로 복구하기 위한 로직은 복잡하고 계속적으로 발전하고 있습니다.

 

 

5. 복구 여부 확인

 

다음 단계는 Auto-remediation에 의한 해결책이 host를 복구했나 확인하는 것입니다. 

만일 Fail된 host가 물리적 재부팅이나, 소프트 리부팅으로 해결되었다고 확인된다면,

마무리 단계로서, SDDC의 이슈와 관련된 필요 정보를 수집한후, 추가적인 잔여 작업을 수행합니다.

이후 3단계에서 선재적으로 추가된 host를 다시 제거합니다.

 

 

6. host 교체

 

만약 Fail된 host가 복구되지 않았다면, Auto-Scaler는 Fail된 host를 제거하고, 신규 추가된 host로 대체합니다.

앞서 3단계에서 미리 구성해 두었던 host가 SDDC cluster로 추가되게 되며,

vSphere의 HA나 vSAN 역시 기존 정책들이 새로운 호스트를 포함한 정책으로 확장됩니다.

DRS 정책을 통해 VM의 고른 분산이 이루어지고, 다시 예전의 성능을 복구합니다.

 

 

지금까지 살펴본것처럼, VMware Cloud on AWS는 AWS와 VMware의 공동 모니터링을 통해,

장애 발생시, 즉각적이고 자동화된 프로세스에 따라 처리되고 있습니다.

또한, 혹시 모를 host Fail 상황에 대비하여, Fail에 대한 대응방안이 확인되기도 전에,

미리 예비 host부터 추가하여 만약의 사태에 대비합니다.

이 모든 절차는 Everthing Fails의 영향을 최소화하는 노력이며, 실제 서비스의 SLA를 보장해주는 중요한 요소입니다.