올해 VMworld breakout session 들을 좀 보고 있는데, 공유하면 좋은 내용들이 있어 별도로 추출해서 작성합니다. (#HBI1964BU)

 

보통 Snapshot 의 경우 아래 두가지 경우가 문제가 되는 경우가 많습니다. 바로 Consolidation 과 연관된 부분입니다. 

  1. 스냅샷 통합이 너무 오래걸리거나
  2. 스냅샷 통합이 정상적으로 끝나지 않거나

 

스냅샷 통합이 너무 오래걸리는 경우 

Consolidation 의 경우 스냅샷 크기에 따라서 오래 걸릴수도 있는데요, 문제는 Consolidation 이 끝나지 않는 경우, 설정, reboot, power-cycle 등의 작업이 불가능하다는 것입니다. 또 중간에 임의로 중단할수도 없기 떄문에 Consolidation 이 오래걸리는 경우 두려운 경우가 많죠. 

 

일단 오래걸리는 경우는 오래걸리는 것이지 문제가 있는것은 아니기 때문에, 크나마 다행이죠. 그렇지만 대략 언제 끝날지 알고 싶은것이 또 사람의 마음이기도 합니다.

 

여기서는 ESXi command 를 통해 계산하는 방법을 소개합니다. 물론 예상치이기 때문에 정확하지 않을 수 있습니다.

 

순서는 다음과 같습니다.

  1. Snapshot 파일의 크기 확인 – /vmfs/volumes/datastore/<VM Name>/ 으로 이동해서 ‘-sesparse’ 나 ‘-delta’ 로 끝나는 파일의 사이즈 확인

  2.  본 예제에서는 약 97GB 정도로 확인됩니다. esxcli 
  3. 그리고 해당 VM 이 위치한 datastore 를 확인합니다. (esxcli storage vmfs extent list)

  4. 그 다음 esxtop 를 실행합니다. 그뒤 ‘u’ 를 눌러 데이터스토어와 LUN 스크린으로 진입합니다.

  5. 여기서 필요한 값이 MBWRTN/s 입니다. 한 10초정도 지켜보고 평균이 어느정도 되는지 확인해보세요. 본 예제에서는 대략 185MB/sec 정도 됩니다. 스크린샷에서는 191.81 MB/sec 로 표시되고 있습니다. 현재 데이터스토어의 Throughput 이라고 보시면 됩니다.

자 그럼 필요한 데이터는 다 수집했습니다. 그럼 계산에 들어가면..

[스냅샷 크기 in MB] / [Throughput in MB] 으로 계산하시면 됩니다.

  • 스냅샷 크기 96.8GB * 1024 = 99,123MB
  • 99,123 / 185 = ~536 seconds (대략 9분) 

 

위와 같이 예상하시면 됩니다만, Throughput 수치가 계속 변할 수 있기 때문에 아주 정확하다고 볼수는 없습니다. 스냅샷이 여러개라면 모든 스냅샷의 크기를 다 합해서 계산합니다.

 

스냅샷 통합이 실패하는 경우 

 

스냅샷 통합이 실패하는 경우의 대부분은 거의다 File Locks 이슈로 인해 발생합니다. 그리고 그 경우에는 UI 상으로 “Virtual Machine Consolidation Needed Status” 또는 “Virtual Machine disks consolidation is needed” 라는 알람이 발생합니다.

 

이 경우 어떤 호스트 또는 어떤 프로세스가 File lock 을 잡고 있는지 확인해야 합니다.

  1. hostd.log 파일에서 VM 이름으로 검색하여 failed to open 메세지 확인, lock 으로 인해 실패했음을 확인할 수 있음

  2.  VM 이 Powered on 상태에서 Consolidation 이 실패한 경에는 vmware.log 를 통해서도 확인할 수 있음. (/vmfs/volumes/datastore/<VM name>/vmware.log)

File lock 으로 인해 발생하는 문제는 스냅샷 Consolidation 외에도 아래와 같은 것들이 있습니다.

  • VM Power on 실패
  • VM Registration 실패
  • VM Migration 실패

 

보통 이럴때 UI 상으로도 에러 메세지가 발생하지만, 충분한 정보를 제공하지 않는 경우들이 많습니다. 예를 들면..

  • failed to lock the file
  • File system specific implementation of OpenFile[file] failed
  • Device or resource busy

 

이 때에는 누가 Lock 을 잡고 있는지 확인해야합니다.

 

확인하는 방법#1 – vmfsfilelockinfo

ESXi 6.x 부터 추가된 커맨드로 가장 쉬운 방법 입니다. 다만 vSphere HA 기반으로 동작하기 때문에, vSphere HA 가 turn on 되어있지 않으면 제대로 된 정보가 안나옵니다. 그 외 내용은 KB 2110152 를 참조 하십시요.

위 예제에서는 10.21.181.22 호스트가 락을 잡고 있다고 나오네요.

 

확인하는 방법#2 – vmkfstools

만약 HA 가 동작하지 않는 경우라면 전통적인 방식으로 vmkfstools 를 사용하면 됩니다. 다만 좀 더 공수가 들어갑니다. 어떤 호스트의 mac address 인지 찾아야 하거든요. 자세한 내용은 KB 10051 를 참조하시기 바랍니다.

owner 라고 되어있는 부분의 맨 마지막 부분이 사실 MAC address 입니다. 해당 어드레스가 어떤 호스트인지를 확인해보시면 되겠습니다.

 

자 호스트까지 찾았습니다. 그 이후의 과정은 어떨까요?

  1. 해당 호스트로 접속
  2. lsof 커맨드를 사용해서 확인 lsof | grep ‘vsan-vc-flat.vmdk’ 본 예제에서는 less 커맨드로 임의로 lock 을 잡았습니다. 

  3. 위의 예제에서는 less 지만, 일반적으로는 vmx (VM) 거나 호스트에서 동작하는 프로세스 일겁니다. (hostd 등의)
    • VMX 일 경우 – 해당 스냅샷 파일이 attached 되어있는지 확인, 보통 백업에서 사용하는 Proxy VM 인 경우가 많습니다. 확인이 되면 해당 VM Power off 를 진행하면 락이 풀립니다.
    • Hostd 등일 경우(or vpxa) – 해당 프로세스 restart (KB 1003490) 를 하면 락이 풀립니다.
    • 위의 두가지가 아닐경우 – 해당 호스트의 VM 들을 전부 마이그레이션 하고, Maintenance 모드 진입 및 호스트 리붓이 필요합니다.

보통 위의 스텝대로 진행하면 대부분 lock 이 풀립니다. 그 이후에 다시 진행해보면 될것입니다.

 

다른 종류들도 정리해서 공유해보겠습니다. 

 

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다