SLA for VMware Cloud on AWS

여느 퍼블릭 클라우드처럼 VMware Cloud on AWS에도 가용성을 보장하는 SLA(Service Level Aggrement)가 있습니다.

SLA는 만약의 사태에라도 서비스 가용성을 어느정도 수준으로 보장한다는 일종의 보증수표로,

만약 해당 가용성을 지키지 못하는 이슈가 발생하였을 경우 그에 대한 보상이 지불되는 기준이 되기도 합니다.

 

기본적으로 가용성은 사용하고 있는 서비스의 빌링되는 기간을 기준으로 합니다.

예를 들어 4월 1일부터 30일까지 한달 쓴 비용을 월 1회 빌링으로 청구받는다고 하면, 4월 한달이 기준입니다.

이 경우 4월달에 서비스의 다운시간의 총 합계가 SLA가 보장하는 시간보다 더 길었을 경우 보상이 이루어 집니다. 

물론 대부분의 경우 다운타임이 존재하지 않으며, 만약의 사태를 대비한 최대 장애 시간으로 생각하면 좋을 것 같습니다.

 

정리해보면 가용성은 계산식으로 정리될 수 있습니다.

 

가용성 = { ( 43,200분 - 총 장애시간 ) / 43,200분 } * 100

여기서의 43,200분은 단순히 30일 기준으로 시간을 계산한 것으로, 만약 31일인 달이라면 44,640분으로 바뀝니다.

즉, 실제 가용시간을 전체 시간으로 나누고 100을 곱하여 %로 변환한 것으로 가용성을 나타내고 있습니다.

 

이러한 기준으로 보았을 때,

SLA 대상 항목들은 99.99% 일 경우 4.32분, 99.9%일 경우 43.2분의 최대 장애 허용 시간이 주어집니다.

 

구분	대상			SLA	장애허용시간/월
SDDC 인프라	하나의 AZ에 구성된 하나의 SDDC 클러스터			99.9%	43.2분 이하/월
SDDC 인프라	하나 이상의 AZ에 걸쳐져 있는 Stretched 클러스터			99.99%	4.32분 이하/월
관리영역	SDDC			99.9%	43.2분 이하/월
관리영역	VMware Site Recovery			99.9%	43.2분 이하/월

 

그럼 여기서의 서비스 가용성의 핵심 요소인 장애라는 시간에 대해 어떻게 판단할까요?

VMware의 모니터링 도구에서 다양한 수치들에 대해 서비스가 정상적이지 않았던 시간들을 확인하고,

다시 서비스가 정상으로 돌아오기까지의 총 발생된 시간을 기준으로 합니다.

 

대상	산정기준
SDDC 인프라	- 클러스터 내 가동중인 VM들이 연속된 4분동안 어떠한 접속도 이루어지지 못한 경우 - 어떤 VM도 연속된 4분동안 스토리지에 접근하지 못한 경우 - 어떤 VM도 연속된 4분동안 시작되지 못한 경우
SDDC 관리	- vCenter 서버에 연속된 4분동안 접근하지 못한경우 - NSX 매니저에 연속된 4분동안 접근하지 못한 경우
SRM	- 연속된 4분동안 VMware Cloud on AWS 위에 구동중인 SRM server가 접근되지 못한 경우 - 연속된 4분동안 VMware Cloud on AWS 위에 구동중인 vSphere Replication management가 접근되지 못한 경우

 

각 구분별로 산정기준을 보면,

연속적으로 4분동안은 서비스 접근이 이루어지지 못해야 SLA 장애 시간으로 인정 받을 수 있습니다.

만약 3분 50초동안 모니터링 상에서 접근이 안됐다면, 장애로 인정받지 못합니다.

 

추가적으로, 만약 2개 이상의 SLA 이벤트가 동시에 연속적으로 발생한다면,

더 오랜 시간 지속된 비정상 상태를 전체 장애 시간으로 인식합니다.

즉 사유가 무엇이던, 전체 서비스 장애시간을 기준으로 보상이 이루어지게 됩니다.

 

이 모든 SLA는 VMware 솔루션 구동에 대간 모니터링만 포함하고 있으며,

AWS 인프라 가용성에 대한 SLA는 VMware Cloud on AWS의 인프라 SLA에 포함되어 있지 않습니다.

만약 AWS 인프라의 가용성 문제로 인해 VMware Cloud on AWS의 인프라 SLA가 충족되지 못한경우,

AWS에 대한 SLA 청구권은 VMware에 있으며, VMware는 별도의 계약에 따라 AWS에 요청합니다.

 

결론적으로, AWS 인프라의 가용성으로 인한 문제 발생으로 인해, VMware Cloud on AWS에 영향을 미칠 경우,

AWS의 SLA 정책이 아니라, VMware Cloud on AWS의 SLA 정책에 따라 처리 됩니다.

물론 VMware Cloud on AWS에 연결된 AWS 서비스에 대해서는 사용자가 직접 AWS에 SLA 청구가 가능합니다.

 

만약 서비스에 문제가 생겨 SLA보다 낮은 가용성을 보여줄 경우 SLA Credit을 청구할 수 있습니다.

하지만, 각 상황별로 아래 규칙이 준수되었을 경우에만 SLA Credit을 청구할 수 있습니다.

따라서, 아래 규칙들은 권고사항으로 반드시 필수 사항은 아니지만, 보상을 위해서는 반드시 지켜야 하는 사항입니다.

 

• Stretched 클러스터가 아닌 일반 SDDC 클러스터 내 host가 2대에서 5대 사이라면, FTT=1로 구성되어야 합니다.
• Stretched 클러스터가 아닌 일반 SDDC 클러스터 내 host가 6대 이상이라면, FTT=2로 구성되어야 합니다.
• 하나 이상의 AZ에 배포된 Stretched 클러스터에서는 모든 VM의 스토리지 정책이 Disaster Tolerance(PFTT) = dual site mirroring으로 Secondart level을 SFTT=1로 구성해야 합니다.
• SDDC 클러스터별 스토리지 사용용량은 Slack space를 위해 25%의 여유가 있어야 합니다.

만약, SLA 크레딧을 받을 수 있는 서비스 장애가 있었을 경우,

60일 이내 Support에서 'Product Licensing' 항목을 이용하여 요청해야하며,

엔터프라이즈 환경에서는 MSP를 통해 해당 요청을 처리할 수 있습니다.

그러면, VMware는 요청된 사항에 대해 검토 한 후 SLA 위반이 확인될 경우 SLA Credit을 발행합니다.

 

대상	SLA Credit
SDDC 인프라	- 99.9% ~ 99.99% : 해당 월 사용비용의 10% (Stretched Cluster의 경우) - 99.0% ~ 99.9% : 해당 월 사용비용의 10% - 99.0% 미만 : 해당 월 사용비용의 30%
SDDC 관리	- 99.0% ~ 99.9% : 해당 월 사용비용의 5% - 99.0% 미만 : 해당 월 사용비용의 15%
SRM	- 99.0% ~ 99.9% : 해당 월 사용비용의 5% - 99.0% 미만 : 해당 월 사용비용의 15%

 

국내 대부분의 클라우드 데이터센터는 SLA를 위반하는 일이 거의 없으며, 앞으로도 없기만을 바랍니다.

하지만, 최근 유럽 최대의 클라우드 데이터센터가 화재로 소실되는 등 관련사고들이 있어, 

사용하는 클라우드의 서비스 SLA의 유지여부와 관련 Credit 발행 조건등에 대해 확인해 두고,

사용자 입장에서도 SLA조건을 지키기 위해 노력하는 것이 만약의 사태를 대비할 수 있는 방법이 될 것입니다.

 

※ VMware Cloud on AWS의 전체 SLA 기준은 아래 문서에서 확인할 수 있습니다.

www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/vmw-cloud-aws-service-level-agreement.pdf