vMotion 이동과 HA 재시작 및 vCenter 접속 복구를 구분한 과정

공유 NFS datastore를 만든 뒤에는 VM을 다른 호스트로 옮기는 실습과 호스트 장애 실습을 진행했다. 둘 다 VM이 다른 ESXi에서 보이는 결과로 이어질 수 있지만, 실행 중인 VM을 이동하는 vMotion과 장애 뒤 VM을 다시 시작하는 HA는 구분해야 했다.

테스트 VM의 부팅 문제부터 해결했다

테스트 VM은 공유 datastore에 CPU 2개, 메모리 2GB, 20GB Thin disk로 생성했다. VM을 만들었지만 설치 ISO를 사용하는 과정에서 콘솔에 다음 문구가 나왔다.

EFI Virtual disk ... No Media.
EFI VMware Virtual SATA CDROM Drive ... No Media.

ISO 업로드에서 인증서 오류를 겪어 NFS 서버로 직접 파일을 올렸다. 이후 ISO 접근 문제를 해결하고 게스트를 설치했다. VM 생성과 설치 미디어 접근은 별도로 확인했다.

게스트를 준비한 뒤에는 실제 vMotion 이동이 되는 것을 확인했다. 이어 HA 설정에서 Host Monitoring과 장애 시 VM 재시작을 활성화하고, 호스트 한 대 장애를 고려한 Admission Control을 검토했다. datastore heartbeat에는 두 호스트가 마운트한 공유 NFS가 표시됐다.

vCenter의 VM 파일도 공유 저장소로 옮겼다

당시 vCenter는 호스트의 로컬 스토리지에 있었다. vCenter가 있는 호스트를 잃었을 때 다른 호스트가 VM 파일을 읽을 수 있어야 하므로, vCenter를 공유 NFS로 Storage vMotion했다.

vMotion의 호스트 간 실행 위치 이동과 Storage vMotion의 파일 저장 위치 변경을 따로 봤다. 그래야 어느 네트워크와 디스크를 확인할지도 구분할 수 있었다.

Storage vMotion이 느리게 느껴졌을 때는 NFS 서버의 네트워크와 디스크를 함께 봤다. 당시 sar에서는 직결 NIC의 평균 사용률이 15.71%로 표시됐고, iostat의 여러 구간에서 디스크 사용률은 약 94–96%, 쓰기 대기는 약 9–10ms였다. 링크가 1Gbps로 협상됐다는 결과만으로 스토리지 처리도 충분하다고 볼 수는 없었다.

NFS 서버의 쓰기 I/O 병목을 의심했지만, LOGICAL VOLUME과 ROTA=0만으로 물리 디스크 종류나 고장을 결론내리지는 않았다.

호스트를 꺼도 vCenter VM의 전원은 켜져 있었다

HA를 구성한 뒤 vCenter가 있던 ESXi의 전원을 껐다. 다른 ESXi에서 vCenter VM이 보였고, 다시 Power On을 누르자 현재 전원이 켜진 상태라 작업할 수 없다는 응답이 나왔다.

이것은 VM의 전원 상태를 보여주는 결과였다. vCenter 웹 화면에 로그인할 수 있다는 결과는 아니었다. 실제로 이후에는 다음 오류 화면을 봤다.

vSphere Client service has stopped working.

vMotion은 실행 중인 VM을 옮기는 기능이지만, HA의 장애 대응은 다른 호스트에서 VM을 다시 시작하는 흐름이다. 재부팅과 게스트 서비스 기동이 필요하므로 이 장애 시험을 무중단 이동 성공으로 기록하지 않았다.

VM 전원과 vCenter 서비스 상태를 따로 확인했다

vCenter 안에서 service-control --status --all로 상태를 조회했다. 일부 서비스는 Running이었지만 vsphere-ui와 여러 서비스는 StartPending이었다. 이어 UI 서비스 시작을 요청했을 때도 작업이 진행 중이라는 메시지가 나왔다.

처음에는 DNS나 인증서, PNID 같은 원인 후보가 나왔지만 하나의 원인으로 확정하지 않았다. 내부 DNS 서버가 없는 환경이었고, 그 사실만으로 이번 시작 지연을 설명할 수는 없었다. 실제 서비스 상태와 로그를 기준으로 확인을 이어갔다.

후속 로그에는 API health batch 실행 완료 문구가 있었고, 이후에는 정상 접속과 HA 상태를 확인했다. batch가 실행됐다는 문구 하나를 모든 개별 서비스의 정상 판정으로 읽지 않고 실제 UI 결과까지 봤다.

호스트 가용성과 서비스 가용성을 나누어 봤다

VM 이동, 공유 저장소 배치, 호스트 장애 뒤 재시작, vCenter UI 복구를 각각 확인했다. 단계를 나누니 “HA가 됐다”는 말도 더 구체적으로 쓸 수 있었다.

다만 두 호스트가 같은 NFS 서버에 의존한다는 구조는 그대로였다. 호스트 장애에 대응하는 구성과 스토리지 장애에 대응하는 구성은 다른 과제다.

현재 구성은 시점도 구분해야 한다. 10월 13일 API 기록의 DRS는 disabled였고, 10월 19일 화면에서는 부분 자동화로 표시됐다. 두 관찰 사이의 변경 시각과 작업자는 확인하지 못했다.