VMware vSphere

[번역] Troubleshooting vMotion

출처 : https://blogs.vmware.com/vsphere/2019/09/troubleshooting-vmotion.html

이전 블로그 게시물에서는 vMotion 프로세스(The vMotion Process Under the Hood)와 높은 대역폭 네트워크를 활용하여 실시간 마이그레이션 시간을 단축하는 방법을 살펴보았다. 이 글은 실시간 마이그레이션이 성공하지 못할 경우 vMotion 문제를 해결할 때 수행할 작업에 대한 자세한 정보를 얻기 위해 작성되었다. 마이그레이션이 실패한 대표적인 이유는 무엇인가? 조사해야 할 로그는? 문제를 해결하고 vMotion 작업이 실패하는 것을 방지하는 방법을 살펴봅겠다.

공통 장애

실시간 이동이 실패하는 일반적인 실패와 패턴은 다음과 같다.

모든 vMotion 요구 사항을 충족했는지 확인한다. 여기에는 네트워크 연결 또는 MTU 불일치의 vMotion 문제의 주요 이유가 포함된다. 이 문제를 정확히 파악할 수 없는 경우 vSphere 로그를 검토해서 어떤 일이 발생했는지 확인하는 것이 유용할 수 있다.

vSphere 로그

vSphere 로그를 자세히 들여다보면 실시간 마이그레이션이 실패하는 원인이 무엇인지 확인하는 데 유용하다. vMotion 프로세스는 vCenter Server 및 ESXi 구성 요소를 모두 사용한다. 다섯 가지 다른 로그 파일에 로그하는 다섯 가지 프로세스가 있다.

processes-logs.png


vCenter Daemon(VPXD), vCenter Agent(VPXA) 및 Host Daemon(hostd)은 vMotion 프로세스의 제어 영역이다. '데이터 평면'은 VMX 프로세스 및 VMkernel에 있다. 첫 번째 단계는 이러한 로그에서 Operation ID(opID)를 찾는 것이다. 이 opID는 Migration ID에 매핑된다. 이 두 개의 식별자를 사용해서, 해당 로그 파일을 확인해서 vMotion 프로세스 따라갈 수 있다.

Operation ID

vCenter Server 인스턴스의 VPXD 로그에서 vMotion 프로세스의 "작업 ID"를 찾으십시오. VCSA(vCenter Server Appliance) 인스턴스의 콘솔에 연결하고 바시 쉘로 이동하십시오. 다음 명령을 실행할 수 있음:

grep "relocate" /var/log/vmware/vpxd/vpxd-*.log | grep BEGIN

이 명령의 출력은 Operation ID를 포함하는 로그 항목을 노출한다.

/var/log/vmware/vpxd/vpxd-214.log:2019-09-24T15:38:10.042Z info vpxd[29243] [Originator@6876 sub=vpxLro opID=jzlgfw8g-11824-auto-94h-h5:70003561-20] [VpxLRO] — BEGIN task-8031 — vm-269 — vim.VirtualMachine.relocate — 52b17681-35d1-998b-da39-de07b7925dda(520681db-25b7-c5d6-44d7-6a056620e043)

Migration ID

이제 Operation ID(opID)를 검색했다. 이것을 사용해서 ESXi 호스트의 hostd 로그 파일에서 opID를 이용해서 Migration ID를 찾는다.  관련된 소스 및 대상 ESXi 호스트를 알고 있을 때 유용하다. 이 예는 이전 명령을 사용해서 찾은 Operation ID를 사용하는 컴퓨팅 및 스토리지 vMotion(XvMotion) 이다.

grep jzlgfw8g-11824-auto-94h-h5:70003561-20 /var/log/hostd.log | grep -i migrate

Source ESXi host output:

2019-09-24T15:38:47.070Z info hostd[2100388] [Originator@6876 sub=Vcsvc.VMotionSrc.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1 2019-09-24T15:38:47.072Z info hostd[2100388] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/b86202d8-fb958817-0000-000000000000/NH-DC-02/NH-DC-02.vmx opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VigorMigrateNotifyCb:: hostlog state changed from success to none

Destination ESXi host output:

2019-09-24T15:38:47.136Z info hostd[2099828] [Originator@6876 sub=Vcsvc.VMotionDst.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-2c-3c35 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1

VMkernel 항목

이제 Migration ID를 확보했으므로, 이것을 사용해서 vmkernel 로그 파일에서 특정 실시간 마이그레이션에 대한 vMotion 프로세스의 정보를 추출할 수 있다. 소스 및 대상 ESXi 호스트에서 다음 명령을 사용한다.

grep VMotion /var/log/vmkernel*

출력은 vMotion 프로세스에서 데이터 전송에 사용되는 평균 대역폭과 같은 몇 가지 흥미로운 데이터 포인트를 보여준다.

Source ESXi host output:

2019-09-24T15:38:47.402Z cpu13:46101760)VMotionUtil: 5199: 3117907752192811422 S: Stream connection 1 added.
2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 2062: Allocating pool 0.
2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.
2019-09-24T15:38:47.445Z cpu8:46092538)VMotion: 8134: 3117907752192811422 S: Requiring explicit resume handshake.
2019-09-24T15:38:47.445Z cpu13:46101760)XVMotion: 3384: 3117907752192811422 S: Starting XVMotion stream.
2019-09-24T15:39:34.622Z cpu14:46101762)VMotion: 5426: 3117907752192811422 S: Disk copy complete, no bandwidth estimate.
2019-09-24T15:39:34.905Z cpu24:46092539)VMotion: 5281: 3117907752192811422 S: Stopping pre-copy: only 37 pages left to send, which can be sent within the switchover time goal of 0.500 seconds (network bandwidth ~185.134 MB/s, 1536000% t2d)
2019-09-24T15:39:34.965Z cpu13:46101760)VMotionSend: 5095: 3117907752192811422 S: Sent all modified pages to destination (network bandwidth ~281.100 MB/s)
2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

Destination ESXi host output:

2019-09-24T15:38:47.397Z cpu15:2099283)VMotionUtil: 5199: 3117907752192811422 D: Stream connection 1 added.
2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 2062: Allocating pool 0.
2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.
2019-09-24T15:38:47.440Z cpu3:3543984)VMotion: 8134: 3117907752192811422 D: Requiring explicit resume handshake.
2019-09-24T15:39:34.907Z cpu3:3543984)VMotionRecv: 761: 3117907752192811422 D: Estimated network bandwidth 205.138 MB/s during pre-copy
2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2961: 3117907752192811422 D: DONE paging in
2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2969: 3117907752192811422 D: Estimated network bandwidth 200.096 MB/s during page-in
2019-09-24T15:39:35.059Z cpu6:3543972)VMotion: 6675: 3117907752192811422 D: Received all changed pages.
2019-09-24T15:39:35.067Z cpu1:3543972)VMotion: 6454: 3117907752192811422 D: Resume handshake successful
2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

가상 시스템 로그 파일 항목

가상 시스템 로그 파일은 vmx 파일과 vmdk 파일도 포함하고 있는 가상 시스템의 홈 폴더에 있다. ESXi 호스트에서 root로 액세스 사용하면 적절한 폴더로 이동할 수 있다. 테스트 VM이 vSAN에 있으므로 symlink /vmfs/volumes/vsanDatastore를 사용해서 가상 시스템 홈 디렉토리를 찾는다. 다음 명령을 사용하면 소스 및 대상 IP 주소와 같은 실시간 마이그레이션에 대한 자세한 정보를 볼 수 있다.

grep "3117907752192811422" vmware.log

Output:

2019-09-24T15:38:47.280Z| vmx| I125: Received migrate ‘from’ request for mid id 3117907752192811422, src ip <192.168.200.93>.
2019-09-24T15:38:47.280Z| vmx| I125: MigrateSetInfo: state=8 srcIp=<192.168.200.93> dstIp=<192.168.200.91> mid=3117907752192811422 uuid=4c4c4544-004a-4c10-8044-c7c04f4d4e32 priority=high
2019-09-24T15:38:47.282Z| vmx| I125: MigID: 3117907752192811422
2019-09-24T15:39:34.971Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422
2019-09-24T15:39:35.023Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422

이 글은 모범적인 vMotion 작업이 성공적이었음에도, 어떤 로그 항목이 사용되는지 보여주기 위한 것이다. 표시된 로그 항목에는 프로세스를 수행하는 데 도움이 되는 많은 상세 정보가 포함되어 있다. 만약 무언가가 실패한다면, 이 로그들은 가능한 원인을 찾기 위한 좋은 자원이 될 것이다.

추가 자료

구강사의 간단 요약

 

 

[번역] Enhanced vMotion Compatibility (EVC) Explained

출처 : https://blogs.vmware.com/vsphere/2019/06/enhanced-vmotion-compatibility-evc-explained.html

vSphere Enhanced vMotion Compatibility (EVC)를 통해 서로 다른 CPU 세대를 실행하는 클러스터의 ESXi 호스트 간에 워크로드를 실시간 마이그레이션할 수 있다. 일반적으로 EVC를 사용하도록 설정하는 것이 좋다. 새로운 CPU 모델이 포함될 수 있는 새 호스트로 클러스터를 확장하는 데 도움이 될 것이기 때문이다. 브라운필드(brownfield) 시나리오에서 EVC를 활성화하는 것은 어려울 수 있다. 그래서 우리는 처음부터 그것을 가능하게 해야 한다고 강조한다. 이 블로그 게시물은 EVC 및 VM당 EVC 기능에 대한 세부 정보를 제공한다.

EVC는 어떻게 작동하는가?

EVC가 동일한 vMotion 호환성을 허용하는 방법은 ESXi 호스트에서 실행 중인 가상 시스템에 CPUID(명령어) 기준선을 적용하는 것이다. 즉, EVC는 선택한 호환성 수준과 지원되는 호환성 수준에 따라 CPU 명령 집합을 VM에 허용하고 노출한다. 새로운 CPU 패키지를 포함하는 새로운 호스트를 클러스터에 추가하는 경우 EVC는 잠재적으로 VM에 새 CPU 명령어를 숨긴다. 이렇게 함으로써 EVC는 클러스터의 모든 VM이 동일한 CPU 명령으로 실행되어 가상 시스템이 ESXi 호스트 간에 실시간 마이그레이션(vMotion)될 수 있도록 보장한다.

EVC는 CPUID를 사용하여 게스트 OS에서 마스킹할 명령어를 결정한다. 기본적으로 CPUID는 CPU용 API로 볼 수 있다. 이를 통해 EVC는 CPU가 수행할 수 있는 명령 집합과 구성된 EVC 기준선에 따라 마스킹해야 하는 명령어를 배울 수 있다. 클러스터에서 EVC를 사용하도록 설정한 경우 클러스터의 모든 ESXi 호스트가 해당 설정을 준수해야 한다.

VMware KB 문서에서는 현재 모든 EVC 기준선과 이 기준선이 VM에 노출되는 CPU 명령어에 대해 자세히 설명되어 있다.

Per-VM EVC

EVC는 클러스터 내에서 VM 이동성을 지원하는 클러스터 수준 설정이다. 가상 시스템을 사내 또는 하이브리드 클라우드 환경 중 하나에서 다른 클러스터로 이동하면 대상 환경에 따라 EVC 구성이 손실된다. 그 다음으로, 실시간 워크로드가 있는 환경에서 클러스터 EVC 기준선을 변경하는 것은 어렵다.

Per-VM EVC를 구현함으로써 EVC 모드는 클러스터에서 부팅되는 특정 프로세서 생성 대신 VM의 속성이 된다. 이는 EVC 지원 및 기준선을 통해 보다 유연하게 사용할 수 있도록 도와준다. 우리는 vSphere 6.7에서 Per-VM EVC 기능을 소개하였다. Per-VM EVC를 사용하려면 VM 하드웨어 버전 14 이상이 필요하다. 가상 시스템의 전원이 꺼진 경우 Per-VM EVC 기준선을 변경할 수 있다.