(1) vSAN 파일 서비스의 구성
(2) 파일 공유의 작성과 이용
(3) 장애 발생 시의 움직임
이번에는 장애 발생 시의 동작에 대해서 소개를 하겠습니다.
■ ESXi 호스트의 장애
우선은 ESXi 호스트 장애 시의 동작에 대해서 살펴보겠습니다. vSAN File Services 구성에 대한 소개에서 설명은 했습니다만 FSVM은 EAM(vSphere ESX Agent Manager)에 의해 설치되어 관리되기 때문에 vSphere HA나 DRS 등의 영향을 받지 않습니다. 따라서 ESXi 호스트가 정지해도 FSVM는 페일오버하지 않습니다.
파일 서비스를 구성한 ESXi 호스트에는 1대의 ESXi 호스트가 이른바 헤드 노드가 됩니다. 당연할지 모르갰습니다만 ESXi 호스트의 장애가 헤드 노드에서 일어났는지 아닌지에 따라서 영향이 달라집니다. 여기서는 헤드 노드가 아닌 호스트 장애에 대해서 소개를 하겠습니다. 헤드 노드에 대해서는 FSVM 장애에서 보도록 하겠습니다.
호스트 esxi70-191를 정지해보겠습니다. 호스트 esxi70-191에서는 FSVM(5)가 움직이고 있습니다.
호스트 esxi70-191를 Power Off 해버렸습니다.
호스트 esxi70-191가 "Not Responding"이 되어 움직이고 있던 FSVM(5)도 "Disconnected" 상태가 되었습니다.
하지만 파일 공유에는 문제없이 접속할 수 있습니다. 기본 IP 어드레스로의 ping도 문제없이 소통되고 있습니다. 참고로 헤드 노드가 정지했을 경우는 파일 공유에의 접속이 타임 아웃되어 재접속해야 할 필요가 있습니다. 헤드 노드가 정지하면 나머지 ESXi 호스트에서 새롭게 헤드 노드가 선출됩니다.
호스트 esxi70-191의 전원을 넣었습니다. 호스트 esxi70-191가 시작되면 자동적으로 FSVM(5)도 자동적으로 시작됩니다.
호스트 esxi70-191도 FSVM(5)도 시작된 상태입니다. 이번에는 헬스 상태를 확인해 보겠습니다.
「vSAN」 → 「Skyline 건전성(vSAN 7.0부터 헬스는 프로액티브 지원 서비스 제품인 Skyline과 통합되었습니다)」 에서 「파일 서비스」를 확인해보면 "인프라스트럭쳐의 건전성"에서 호스트 esxi70-191의 파일 서비스에 이상이 있었던 것을 알 수 있습니다. 메시지를 확인해보면 "파일 서비스가 유효화 되지 않았다"는 것을 알 수 있습니다. 이 경우 「파일 서비스의 수정」을 실행하면 정상의 상태로 회복할 수 있습니다. ※「파일 서비스의 수정」을 반드시 실행할 필요는 없습니다. 그냥 내버려두어도 자동적으로 수정이 됩니다. ;)
파일 서비스 관련 헬스 상태가 전부 정상이 되었습니다.
■ FSVM의 장애
이번에는 FSVM의 장애에 대해서 입니다. FSVM도 가상 머신이므로 장애나 조작 미스로 인해 정지가 예상되죠. 솔직히 EAM에 의해서 관리되고 있기 때문에 정지 같은 조작을 하려고 하면 EAM에서 관리하고 있다는 메시지가 표시되므로 조작 미스의 염려는 없죠. 만일 조작 미스로 FSVM를 정지했다 치더라도 EAM에 의해 곧바로 기동 되므로 ESXi 호스트 장애에 비하면 영향은 미비할지 모르겠습니다. 이용자에게 영향이 있는 것은 정지한 FSVM이 헤드 노드 위에서 가동 중인 경우입니다. 헤드 노드 위에서 가동 중인 FSVM이 헤드 FSVM이 되기 때문이죠. 여기서는 헤드 FSVM을 정지해 보겠습니다.
우선 어느 ESXi 호스트가 헤드 노드인지 확인해 보겠습니다. 헤드 노드는 「vSAN」 → 「파일 서비스의 공유」에서 확인할 수 있습니다. 여기서는 호스트 esxi70-194이군요.
호스트 esxi70-194에서는 FSVM(6)이 가동중입니다.
FSVM(6)을 정지(Power Off)했습니다. 정지와 동시에 파일 전송량이 0가 되어버렸습니다. FSVM(6)은 EAM에 의해 정지후 약 10초 뒤에 자동적으로 기동 되었습니다만 타임 아웃된 전송은 재개되지 않기 때문에 재시행을 해야 됩니다.
참고로 헤드 노드는 호스트 esxi70-192로 변경되어있습니다. 헤드 FSVM가 정지하므로써 실행 중이던 조작이 타임 아웃되어버리긴 합니다만 EAM가 FSVM을 곧바로 기동시키기 때문에 파일 서비스의 제공이 정지되는 일은 없습니다.
이번에는 FSVM을 삭제해 봤습니다. 😉
호스트 esxi70-194에서 가동중인 FSVM(8)을 정지후 「디스크로부터 삭제」를 실행했습니다.
FSVM(8)이 삭제되어 FSVM은 3대가 되었습니다.
FSVM은 EAM에 의해 관리된다고 설명했죠. 「관리」 → 「vCenter Server의 확장 기능」에서 「vSphere ESX Agent Manager」를 확인해 보겠습니다. vsan-file-services의 상태는 "경고"로 호스트 esxi70-194의 FSVM이 없어진 것을 알 수 있습니다. 이 상태에서 이용 가능한 액션인 「문제의 해결」을 실행하면 호스트 esxi70-194 상에 FSVM이 새롭게 작성됩니다.(수동으로 실행하지 않아도 30초 정도 지나면 자동적으로 FSVM이 작성된답니다.)
새로운 FSVM은 헤드 노드 esxi70-194의 FSVM(3)의 클론으로 작성됩니다.
새로운 FSVM은 클론 작성이 시작된지 약 10초 만에 완료됩니다.
「vSphere ESX Agent Manager」의 vsan-file-services 상태도 "정상"으로 복구되었습니다.
어떤가요? 설정이나 이용이 간단하죠? 스토리지 정책에 의해서 데이터도 보호되니 검증을 거친 뒤에 실환경에서 이용해도 문제없을 것 같습니다. 물론 AD 인증이나 SMB이 미대응이라 이용 용도는 어느 정도 한정되긴 합니다만 첫 번째 릴리스 버전으로써는 기대 이상이라고 생각합니다. ;)
'virtualization > VMware' 카테고리의 다른 글
[VMware] vRealize Automation 8.1의 도입 (1) (0) | 2020.08.17 |
---|---|
[VMware] 알고있으면 편리한 사이트 (0) | 2020.07.30 |
[VMware] vRSLCM에 vRNI를 임포트하기 (0) | 2020.05.07 |
[VMware] vRealize Suite Lifecycle Manager의 업그레이드 (0) | 2020.05.01 |
[VMware] vSAN File Services에 대해서 (2) (0) | 2020.04.21 |
[VMware] vSAN File Services에 대해서 (1) (0) | 2020.04.18 |
[VMware] vRealize Automation 설치가 실패함 (0) | 2020.04.16 |
[VMware] vRealize Automation 8.0 설치 (0) | 2020.04.11 |