<스팩>
ESXI 버전 : 7.x
게스트OS : WINDOWS Server 2022
서버 : HPE DL380 GEN10
<구성>
서버 2대에 ESXI 설치 후 각각 게스트OS 3개 씩 설치 하였습니다.
# 1번 서버 : 게스트OS1, 게스트OS2, 게스트OS3
# 2번 서버 : 게스트OS4, 게스트OS5, 게스트OS6(AD서버)
<질문>
1.두가지 케이스에서 FailOver 하는데 걸리는 시간의 차이가 왜 나는 지 궁급합니다.
동일환경) 1번 서버의 게스트OS1번이 현재 클러스터 서비스의 소유권을 가지고 있음
Case-1번) 1번 서버의 게스트OS들을 종료하지 않고 강제로 Host(ESXI)의 전원을 종료하면
게스트OS1~3 모두 강제종료가 되므로 소유권이 게스트OS4~5 으로 넘어 오는데까지 걸리는
시간이 26초 정도가 걸린다.
Case-2번) 1번 서버의 게스트OS들을 정상종료(HOST에서 전원끄기 혹은 OS에서 시스템종료)하면
게스트OS1~3 모두 정상종료가 되므로 소유권이 게스트OS4~5 으로 넘어 오는데까지 걸리는
시간이 7초 정도가 걸린다.
게스트OS4,5 이 1번서버의 강제종료된 게스트OS들의 장애를 판단하는 시간의 차이가 있는
것으로 보입니다.
왜 이러한 시간의 차이가 있는 걸까요?ㅜㅜ
5개의 답변이 있습니다.
호스트가 기본 호스트에서 분리되거나 분할되고 기본 호스트가 하트비트 데이터스토어를 사용하여 해당 호스트와 통신할 수 없을 때 가상 시스템 "분할 브레인" 상태가 발생할 수 있습니다. 이 경우 기본 호스트는 호스트가 활성(alive) 상태인지를 확인할 수 없으므로 비활성(dead) 상태로 선언합니다. 그런 다음에 기본 호스트는 분리되거나 분할된 호스트에서 실행 중인 가상 시스템을 다시 시작하려고 시도합니다. 가상 시스템이 분리/분할된 호스트에서 계속 실행 중이고 해당 호스트가 분리되거나 분할될 때 가상 시스템의 데이터스토어에 액세스할 수 없게 되는 경우 이 시도는 성공합니다. 그러면 두 개의 가상 시스템 인스턴스가 있기 때문에 분할 브레인 상태가 발생합니다. 하지만 한 인스턴스만 가상 시스템의 가상 디스크를 읽거나 쓸 수 있습니다.
Genghis Khan | 2달 전
HA 클러스터 구조와 설정에 따라 다를수 있겠지만 현재 하나의 구조에서 같은 VM별 설정을
했다면 각 VM에 OS와 그에 대한 app 설치 또는 구성에 따라 문제가 될수도 있겠네요
정상 종료한 후에 서비스가 정상적으로 넘어 갈 경우에는 점검하지 않아도 되는 데이터의 무결성 ( Integrity )을 강제 종료시에는 좀 더 엄격하게 점검하기 때문에 시간이 많이 소요되는 것이 아닐까 싶네요.
서버 1의 게스트 OS를 종료하지 않고 호스트를 강제로 끄는 Case-1번의 경우 클러스터가 장애를 인식하고 확인하는 데 더 많은 시간이 필요할 수 있습니다.
이는 게스트 OS 인스턴스의 갑작스러운 종료로 인해 데이터 손상, 불완전한 종료 절차 또는 클러스터의 예기치 않은 상태와 같은 잠재적인 문제가 발생할 수 있기 때문입니다.
결과적으로 클러스터가 장애조치 작업의 안정성과 무결성을 보장하기 위해 추가 검사 및 절차를 수행하므로 장애 조치 프로세스가 더 오래 걸릴 수 있습니다.
1번 서버의 게스트 OS가 정상적으로 종료되는 Case-2번의 경우 변수 없이 정상적인 종료 알림을 받을 수 있어 더 빠른 조치가 가능합니다. 일반적인 종료 절차를 통해 클러서터는 종료되는 호스트에서 클러스터의 나머지 호스트로의 서비스 및 리소스 전환을 원활하게 처리할 수 있습니다.
또한, 게스트 OS 4와 5 간의 장애 조치 시간 차이는 각 게스트 OS의 역할, OS 간 종속성, 클러스터 서비스의 특정 구성 등의 요소에 의해 영햐을 받을 수 있습니다. 일부 서비스 또는 애플리케이션은 장애 조치 프로세스 중에 초기화 또는 동기화하는데 시간이 더 오래 걸릴 수 있으며 이로 인해 변동이 발생할 수 있습니다.
case1번과 case2번은 다른 상황인데요.
case1번의 경우는 esxi의 cluster 환경 구성으로
한쪽 esxi가 갑자기 down되면 cluster heartbeat 등 상황체크를 하게되기에 일정시간이 소요됩니다.
그리고 이런 시간은 설정에 따라 약간 더 시간을 줄일 수도 늘릴 수도 있구요.
case2의 경우는 게이트OS1~3을 정상적으로 down시킨 뒤에 esxi를 down시켰다면
게이트OS1~3은 power on하면 복잡한 체크 과정이 줄어드어 운영중인 esxi에서
바로 부팅이 되기에 시간 차이가 발생합니다.
클러스터 솔루션마다 장애 방지의 방식이 차이가 나고 넘기는 시간의 설정도 차이가 나기는 합니다.
하지만 일반적으로 전원을 강제로 Off 하는 경우보다, 인위적으로 서비스를 Down 하는 방식이
넘어가는 시간이 짧은게 보통이더라구요.
기본적인 이유는 OS를 Down 하면서 클러스터에 나 Down 되니 Standby 로 서비스를
넘겨라 하는 신호를 주고 Down 되는 방식으로 보통 구성이 되기 때문입니다.
그래서 인위적으로 Down 할 경우에 넘어가는 시간이 짧게 됩니다.
pjs8806 | 2달 전
그렇군요ㅜㅜ 그런 메커니즘이군요 혹시 죄송하지만 자세하게 OS가 종료되면 클러스터에 DOWN 되니 Standby 로 서비스를 넘겨라 하는 신호가 어떤 신호일까요? 자세하게 찾아보고 싶어서요..!
앵그리파파 | 2달 전
OS가 종료되면 클러스터에 DOWN 되니 Standby 로 서비스를 넘겨라 하는 신호가 어떤 신호일까요?
이 물음에 대한 의견 참고하세요.
일반적으로 가상화 환경에서 클러스터링 솔루션은 VM 또는 호스트 상태 변화를 감시하고 이에 따라 조치를 취하는데 사용하는 여러 신호와 메커니즘이 있습니다. 예를 들어 VMware vSphere 환경에서는 다양한 이벤트 및 신호를 기반으로 자동화된 조치가 이루어집니다.
VM이나 호스트는 주기적으로 신호를 생성하고 이를 클러스터에 보내는데, 일정시간 동안 신호를 수신하지 못하면 해당 VM이나 호스트는 문제가 있거나 다운된 것으로 판단됩니다.
Simon.Park | 2달 전
제가 서비스를 넘겨라 하는 식으로 말씀 드렸는데,
다르게 말하면 다른 분이 말씀하신대로 서비스 정상 종료에 따른 체크 사항이 줄어들었다고도
볼 수 있습니다.
저도 MSCS 클러스터 엔지니어가 아니라 정확히 어떤 신호인지까지는 말씀드리지 못하네요~~ ㅜㅜ