vSphere HA (High Availability)

가용성 레벨 (Availability Level, AL)

IDC(International Data Corporation), 미국의 IT 시장조사 및 컨설팅 기관이 정의한 가용성 기준

• AL0 (99%) : 단독서버, 87시간 36분 (1년 기준 다운타임 합계)
  • 보통 물리서버의 교체 + OS 재설치 등의 작업시간의 합계
• AL1 (99.5%) : Data Integrity, 43시간 48분
• AL2 (99.95%) : User Intervention, 4시간 23분
  • 가용성 시장의 최소 기준, AL2와 AL3를 합쳐서 HA Cluster 단계라고 부름 (AL1 미만은 일반적인 서버)
• AL3 (99.99%) : Automatic Fail-Over, 53분
  • 일반적인 데이터센터의 경우 적용하는 가용성 레벨
  • Active-Standby 를 갖춘 이중화된 서버
    • 자동으로 Fail-Over 처리가 가능한 정도
  • VMware HA 기능이 해당하는 레벨
    • VMware HA는 전통적인 Active-Standby 처럼 서버 2대를 구매해서 이중화하는 것은 아님
• AL4 (99.999%, five nines) : Fault Tolerant, 5.26분 → 무정지 서버
  • 최상위 가용성 레벨
• 사실상 무정지 (찰나의 서비스 다운만 허용하는 정도)
• CPU 및 Memory가 완전 동기화되도록 동작
• VMware FT 기능이 AL4에 해당하는 '무정지서버'의 형태

VMware HA

• VMware의 이중화 솔루션
• ESXi Host와 VM의 장애 발생 시 VM을 다른 Host에서 자동으로 재가동함으로써 가용성을 보장

ESXi 에 장애가 발생 시 시나리오
1. vCenter 감지
2. 장애가 발생한 ESXi에 있는 VM들을 강제로 이동
(이 때 vMotion 같은 기능 사용 X, vMotion은 ESXi가 살아 있을때 동작하는 기능이기 때문)
3. 공유디스크 차원에서 VM에 대한 소유권을 기전
4. 소유권 이전 후 VM 전원 자동 재가동 (hot migration 아님 주의)
5. 추후 ESXi 장애 복구 후 다시 수동으로 VM을 이동

• 각 host 들이 공유디스크 방식으로 디스크를 공유하고 있기 때문에 가능 (=동일한 스토리지를 바라보고 있기 때문)
• 장애 발생 시 Fail-Over될 특정 ESXi 호스트도 옵션으로 지정 가능
• vSphere HA 구성 시 ESXi 상태에서 master, slave 여부를 파악 가능
• VM을 받아줄 Host 는 당연히 CPU나 메모리 등의 리소스가 충분해야함
  • VM 용량 등을 설계하여 각 host에서 구동시키는 일 + 장애발생 대비하여 전체 클러스터 용량 예측 필요

VMware HA 내부 아키텍처 (vSphere 5 이상 기준)

• VMware HA 아키텍처는 Master-Slave 구조

1. HA 기능 활성화 시 FDM 에이전트가 각 ESXi에 설치됨 → HA 클러스터 구성
2. 각 host들 사이에서 master와 slave host를 선정 (master는 한 대, 나머지는 전부 slave)
   • master에 장애 발생 시 slave 중 하나가 master가 되는 프로세스 진행
3. 각 host는 HA 구성에 문제가 없는지 지속적으로 상호 정합성 체크
   • 정합성 확인 사항
     • 네트워크
     • 공유 스토리지
     • 하트비트 데이터스토어
       • 관리 네트워크가 실패할 때 host 및 VM을 모니터링하는 목적
4. 한 대의 호스트에서 비정상적으로 오랜시간 응답 X → 죽은것으로 판단 → 배제