vSAN 메뉴얼이 한글화되지 않아서, witness에 대한 한글 표기가 명확하지 않습니다. 영어사전에는 "목격자, 증인, 증명" 등의 뜻으로 나오고, 파파고 번역에서는 "감시"로 나옵니다. 저는 "증명"이 기능적인 측면에서 가장 가까운 의미라 봅니다.
vSAN 위트니스(witness) 호스트란 무엇입니까? 그게 왜 필요하지? 어떻게 작동하죠? 위트니스 호스트가 없는 vSAN 스트레치드 클러스터 장애 시나리오의 경우 어떻게 됩니까? 다음 단락에서 자주 묻는 질문에 대한 답변을 드리겠습니다. 또한 Witness 호스트 구성, Witness 라이프사이클, 구현 옵션은 무엇이며, AWS 또는 VCF(VMware Cloud Foundation)에서 VMC를 구축할 때 구체적으로 어떤 사항이 있는지 살펴보겠습니다. 세부사항으로 들어가겠습니다.
vSAN Witness 호스트가 무엇입니까?
vSAN 위트니스 호스트는 기본적으로 VM 데이터를 저장하지 않고 VM 메타데이터만 저장하는 ESXi 호스트입니다. 즉, 확장된 클러스터 또는 2-노드 클러스터 구성의 각 VM 개체에 대한 위트니스 구성 요소를 저장합니다. 각 vSAN 위트니스 호스트는 위트니스 장치로 배포할 수 있습니다. 위트니스 장치는 OVA 템플릿을 사용하여 배포할 수 있으며 추가 vSphere 라이센스가 필요하지 않습니다. 이 위트니스 장치 VM은 ESXi 호스트로 처리되며 vSphere 사용자 인터페이스에 파란색으로 표시됩니다.
증인 진행자가 왜 필요하며 어떻게 작동합니까?
전체 사이트에 장애가 발생할 위험이 있을 때마다 이러한 유형의 일시적 워크로드 중단을 완화하려면 vSAN 스트레치 클러스터를 구성하는 것이 좋습니다. vSAN 스트레치 클러스터는 장애 도메인 개념을 기반으로 사이트 가용성 문제를 해결합니다. 장애 도메인 개념은 각 호스트를 독립적인 장애 도메인으로 처리하는 특정 vSAN 방식을 나타내며, 이중화를 위해 지정된 VM 개체의 각 구성 요소를 별도의 호스트에 배치합니다.
확장 클러스터는 사이트별 수준에서 확장하고 장애 시나리오에 대비하여 위트니스 호스트를 동점처리(tiebreak)로 도입하여 동일한 모델을 구현합니다. 각 VM 개체에는 이 유형의 클러스터에 대한 기본 정책인 “Site disaster tolerance =1″로 구성된 정책을 충족하려면 각 사이트에 하나 이상의 완전한 복제본이 있어야 합니다. 그런 다음 허용할 장애 수에 따라 각 개체마다 사이트 내의 서로 다른 호스트/장치에 추가 복제본 또는 패리티 구성 요소가 배치될 수 있습니다. 사용자는 로컬 보호를 위해 다음과 같은 옵션을 사용할 수 있습니다. 1-3개의 장애/RAID-1,5,6 및 2노드 클러스터의 경우 1개의 장애/RAID-1. 아래 그림 2의 가용성 수준을 참조하십시오.
이중 사이트 미러링의 Site Disaster Tolerance로 구성된 정책이 개체에 할당되면 vSAN은 VM이 상주하는 사이트에서 로컬로 읽으면서 한 개체의 모든 쓰기를 기본 사이트와 비기본 사이트 모두에 동기적으로 커밋합니다.
그럼 다시 본론으로 돌아가 보겠습니다. 왜 위트니스 호스트가 필요한 걸까요? 앞서 언급했듯이, 위트니스 호스트가 어느 사이트가 권위 있는 사이트인지 결정하는 분할 브레인(split-brain) 시나리오에서 동점처리 역할을 할 것이다.
사이트 장애와 감시 호스트 없는 경우 어떻게 됩니까?
분할 브레인 시나리오는 사이트 중 하나에서 실제 결함이 발생할 수 있으며, 어떤 결함이 남아 있는지 사이트에서 독립적으로 결정할 수 없을 때 발생할 수 있다. 이 이벤트로 인해 두 사이트 모두에서 애플리케이션이 활성화되어 중단될 수 있습니다. vSAN은 위트니스 호스트가 추가 투표를 제공하여 나머지 사이트와 쿼럼을 구성하고 VM을 vMotion하고 다시 시작해야 하는 정상 사이트를 선택할 수 있도록 함으로써 이 가능성을 제거합니다.
호스트 또는 어플라이언스 권장 사항 확인
이제 위트니스 호스트의 역할이 얼마나 중요한지 알았으므로 이제 감시 호스트의 구성 및 배포와 관련하여 가장 중요한 권장 사항을 살펴보겠습니다. 예를 들어 각 감시 장치 또는 감시 호스트는 확장된 클러스터 또는 2-노드 클러스터 외부에 배포해야 하지만 동일한 vCenter에 속해야 합니다. 일반적으로 vSAN 위트니스 호스트를 다른 데이터 센터에 배치하는 것이 좋습니다.
또 다른 골든 규칙에서는 vSAN Witness 호스트가 vSphere Cluster에 속하지 않지만 디스크를 vSAN 클러스터에 제공하고 있기 때문에 위트니스 호스트가 vSAN 데이터 노드와 동일한 버전 및 빌드되어야 한다고 말합니다.
물리적 위트니스 호스트에는 VM의 데이터가 저장되지 않습니다. 이러한 하드웨어 리소스가 VM 데이터에 필요한 경우 전용 물리적 ESXi 호스트를 사용하는 대신 vSAN 위트니스 장치를 배포할 수 있습니다.
배포 프로세스는 템플릿에서 VM을 배포하는 것과 동일합니다. 감시 장치는 ESXi를 실행하고 OVA 템플릿으로 배포되는 사전 구성된 가상 시스템일 뿐입니다. 배포 프로세스를 시작하기 전에 스트레치드/2노드 클러스터에서 실행해야 하는 VM 수를 고려해야 합니다. 위트니스 크기는 한 클러스터에서 실행할 수 있는 최대 VM 수를 반영하기 때문입니다. vSAN 7 업데이트 2에서 VMware는 2-노드 클러스터 구성에 대한 새로운 공유 위트니스 옵션을 도입했습니다. 단일 vSAN 위트니스 호스트 또는 어플라이언스를 최대 64개의 2-노드 클러스터와 공유할 수 있습니다. 이 기능을 통해 새로운 “초대형” 옵션이 생성되었습니다. 공유 위트니스의 블로그 게시물에서 빠른 크기 조정 가이드 표를 살펴보십시오.
vSAN Witness Host는 vSphere Client에서 쉽게 교체할 수 있는 상태 비저장 장치입니다. 대부분의 상태 비저장 애플리케이션과 마찬가지로 데이터 보호 및 복구 계획을 구현할 필요가 없습니다. 자세한 내용은 2 노드 클러스터 가이드의 이 섹션을 참조하십시오.
VCF 스트레치드 클러스터 감시
VCF 스트레치드 클러스터는 예외를 만들지 않으며 위트니스 호스트도 필요합니다. 위트니스는 어느 한 AZ(Availability Zone)와도 인프라 종속성을 공유해서는 안 되며, 어느 한 가용성 영역에 대한 위트니스의 배포는 지원되지 않습니다.
호스트가 위치할 두 가용성 영역 사이에 확장되어야 하는 네트워크 목록이 있습니다. 다음은 확장할 위트니스 네트워크 목록입니다.
- 위트니스 호스트 ID
- 위트니스 호스트의 FQDN
- 위트니스 호스트의 vSAN 서브넷 CIDR
VMC on AWS에서 vSAN 스트레치드 클러스터 위트니스
스트레치드 클러스터의 개념은 AWS에서 VMC를 구성할 때 그대로 유지되며 vSphere 클러스터를 단일 영역 내의 두 가용성 영역에 걸쳐 확장하여 단일 AZ 손실을 방지합니다. 위트니스 호스트는 세 번째 가용성 영역에 배포되며 분할 브레인 시나리오의 경우 쿼럼을 다시 제공합니다.
위트니스 장애 발생 시 모든 VM이 제자리걸음을 하며, 이는 사내에서 실행되는 vSAN 확장 클러스터에도 적용됩니다. VMC on AWS에서 실행되는 Strenched 클러스터에서 특별한 점은 자동 지원 시스템이 예외 없이 위트니스 호스트 장애가 발생할 경우 새 감시 어플라이언스를 클러스터에 배포한다는 것입니다. vSAN은 새로운 정상 위트니스 기능이 스트레치드 클러스터 구성의 일부가 되는 즉시 누락된 사이트 간 위트니스 구성 요소를 재구성합니다.
요약
위트니스 호스트 또는 어플라이언스는 vSAN 확장 클러스터와 vSAN 2-노드 클러스터의 필수적인 부분입니다. 사이트 장애 시 필요한 모든 메타데이터를 저장하고 타이를 차단하는 역할을 합니다. 사내, Edge 또는 클라우드에서 vSAN 확장 클러스터 구성의 일부로 손쉽게 구현하여 데이터의 고가용성을 유지할 수 있습니다.
출처 : https://core.vmware.com/blog/understanding-vsan-witness-host
