VMworld 2017에서 성능 이슈를 해결하고 원인 분석을 하는 동영상을 정리해보았습니다.

VMworld 2017 SER1534BUR - VMware vSphere Performance Troubleshooting and Root Cause Analysis

https://www.youtube.com/watch?v=a_VyvjGeEcQ

ESXTOP

Esxtop은 ESXi host에서 실행되는 실시간 성능 모니터링 도구로 리눅스의 top 명령과 유사합니다. 옵션은 다음과 같습니다.

C: CPU     m: Memory    d: Disk(Adapter)    u: Disk (device)    v:Virtual Disk (소문자)    n: network

V: Virtual Machine view(대문자)    h: help    q: Quit

CPU

VMware에서 VM이나 ESXi 에서 실행되는 작업을 World 라고 부르는데 World가 Schedule 되는 상태는 다음과 같습니다.

World 상태 중 Ready, Costop이 중요 합니다. Ready 각 vCPU 별로 10 이상이 되어서는 안됩니다. 10 이상이라는 것은 VM의 vCPU가 실행되려 할 때 Hypervisor가 pCPU를 할당해주지 못하는 상태입니다. 그리고 Cstop은 3이상이 되어서는 안됩니다. cstop은 vSMP 일때 사용되는 것으로 Core가 2개인 VM이 있을 때 빠른 vCPU가 느린 vCPU를 기다린 시간 입니다. Cstop 값이 높다면 NUMA를 고려해서 physical CPU의 구조를 따르는 것이 좋습니다. 8 개 이상의 vCPU가 필요한 VM은 하나의 코어를 소캣을 각각 생성하는 방법을 고려할 수 있습니다.

CPU Key performance indicator는 다음과 같습니다.

ESXi host: Ready time, Utilization, Load average

VM: Ready time(%RDY), Co-stop(%CSTP), Swap wait(%SWPWT), MaxLimited(%MLMTD)

%USED 와 %RDY가 높다는 것은 CPU가 over-commitment 되었다는 의미 입니다.

Memory

esxtop 에서 m을 누르면 Memory의 상태를 확인할 수 있습니다. PMEM 은 설치된 물리 메모리를 나타내고 VMKMEM은 VMkernel에 관리하는 메모리를 나타냅니다. Minfree 는 VMkernel이 free 상태 유지해야 하는 메모리 양을 나타내고 rsvd는 Resource Pool에 Reserve 된 메모리의 양을 나타냅니다.

ESXi host는 Minfree 의 양을 계산해서 Memory의 state를 표시 합니다. Minfree의 크기는 물리 메모리의 크기에 따라서 자동으로 계산되는데 0~4GB 물리 메모리의 경우 245MB 정도가 할당되고 12~28GB의 경우 696MB 정도가 할당된다. Minfree 대비 어느 정도의 Free 메모리가 남아 있는지에 따라서 Memory State가 High, Clear, Soft 등으로 표시된다.

esxtop 에서 j 를 누르면 Ballooning 상태를 확인할 수 있습니다. MEMCTL/MB 값으로 Memory Balloon 상태를 알 수 있으며 MCTL이 Y로 되어 있으면 해당 VM에 Balloon Driver가 설치된 것 입니다. MCTLSZ 값이 0이 아닌 경우 Host의 메모리가 over-commit 되어 Bollandriver가 메모리를 회수하는 것입니다. ZIP은 Host에서 메모리가 압축된 상태를 보여줍니다. CACHESZ로 압축된 캐시의 크기를 보여주고 ZIP/s 와 UNZIP/s 를 통해서 압축을 하는데 사용된 IO를 보여 줍니다.

SWAP은 VM의 성능에 많은 영향을 주는데 SWCUR 값으로 현재 SWAP에 사용된 메모리의 양을 할 수 있고 SWR/s, SWW/s를 통해서 SWAP 동작을 확인할 수 있습니다. SWAP 관련 값들은 0 이상일 경우 SWAP이 발생하였고 SWAP으로 인해 VM의 성능저하가 발생했는지 확인할 수 있습니다.

Network

Network 은 여러가지 지점에서 성능을 확인해봐야 합니다. 우선 Virtual NIC를 살펴보면 Virtual NIC이 사용하는 uplink를 확인해야 하고, Virtual NIC의 대역폭을 확인해야 하고, Virtual NIC의 패킷 수와 평균 패킷 크기 마지막으로 Virtual NIC에서 drop 한 패킷을 확인해야 합니다. 그리고 물리 NIC에서도 대역폭, 패킷 수, 평균 패킷 크기 마지막으로 drop 한 패킷을 확인해야 합니다.

esxtop 에서 n 을 누르면 network의 성능 정보를 볼 수 있습니다. %DRPTX %DRPRX 는 packet이 drop 되었다는 것으로 0 값을 가져야 합니다.

(물리 NIC 마다 NetPol 이라고 불리는 Receive Thread가 할당되어 있습니다. NetPol의 사용량은 esxtop의 vmx의 %SYS  값으로 확인할 수 있습니다.)

Network packet은 Buffer가 부족하면 Drop 됩니다. 패킷을 보내거나 받기 위해서는 버퍼가 필요 합니다. Virtual NIC이나 Virtual switch port의 버퍼를 사용하는데 버퍼의 크기보다 패킷이 더 많은 경우 Drop 하게 됩니다.

Storage

스토리지 성능을 이해 하려면 몇가지 용어를 알아야 합니다. 

IOPS: 초당 Input/output 또는 Read/Write를 한 횟수

SCSI Command: Disk의 명령으로 Read/Write, SCSI reservation 등이 있습니다.

SCSI Reservation: 분산 파일시스템에서 메타 데이터를 보호하기 위해 LUN을 lock 하는 것입니다.

Latency: SCSI 명령이 최초 발생/처리/완료 되는데 걸린 시간으로 보통 ms 단위 입니다.

Throughput: Disk에 전달된 데이터의 총합으로 보통 MBps 단위 입니다.

esxtop 에서 v 를 누르면 VM의 vmdk 디스크의 성능, u를 누르면 LUN의 성능 마지막으로 d를 누르면 HBA/RAID card 시점에서 성능을 확인할 수 있습니다. 

CMDS/s 는 초당 Disk에 전달된 명령의 양을 확인할 수 있고 DAVG는 Driver driver에서 실제 디스크 장치까지의 응답 시간으로 15 ~ 20 ms 내의 시간을 가져야 합니다. KAVG는 VMKernel의 응답 시간으로 2 ~ 3ms의 시간을 가져야 합니다. (Guest 가 인식하는 응답 시간은 DAVG+KAVG 입니다).마지막으로 Disk의 ABRTS/s 값은 0이어야 합니다. DAVG가 높고 KAVG가 낮은 경우는 Array에 부하가 많이 걸린 것이고 KAVG가 높고 DAVG가 낮은 경우는 Host에 부하가 걸린 것입니다.

아래 내용을 참고해서 esxtop에 대해서 더 알아볼 수 있습니다.

Interpreting esxtop Statistics

https://communities.vmware.com/docs/DOC-9279

Using esxtop to identify storage performance issues for ESX / ESXi (multiple versions) (1008205)

https://kb.vmware.com/s/article/1008205

감사합니다.

VMworld 2017에서 발표된 vCenter Performance 관련 동영상을 정리해 보았습니다.

성능 이슈를 이해 하고 분석 하려면 기반 지식을 모두 알아야 하는데 이 동영상을 통해서 vCenter의 구조, 어떤 성능상 문제가 있을 수 있는지? 문제를 확인하는 방법 등을 확인할 수 있습니다.

동영상은 아래 링크에서 확인 가능 합니다.

VMworld 2017 - SER1504BE - VMware vCenter Performance Deep Dive

https://www.youtube.com/watch?v=cIAGxJ4tVbA

vCenter의 구성이 간단한하고 부하가 많이 걸리지 않은 경우 Windows 기반과 VCSA 모두 성능이 비슷 합니다. 하지만 복잡한 구성과 부하가 많이 걸리는 경우 vCenter Windows 버전보다 VCSA가 성능이 더 뛰어납니다. 

vCenter의 메인 서비스인 vpxd로 Client의 요청을 처리해서 DB에 저장하는 역할을 합니다. 사용자가 Web Browser를 사용해서 vCenter를 사용해서 VM 생성 등의 작업을 요청하면 요청을 vsphere-client가 받아서 SSO로 인증을 처리한 후 VPXD에 요청을 하는 것입니다. 요청을 받은 VPXD는 vSphere host에 요청을 하고 변경 사항을 DB에 저장하는 것입니다. vpxd는 C++로 작성 되었고 다른 서비스는 java나 Python 등으로 작성되었습니다.

VM을 켜는 동작을 좀 더 자세히 살펴 보면 다음과 같습니다. Client의 요청을 vCenter에서 받은 후 ESXi host에 Name을 Reserve 하고 VM 생성 요청을 한 후 상태를 확인 한 후 DB에 update 하고 Client에 결과를 돌려줍니다. 작업은 Storage와 DB 단에 지연이 있을 수 있으니 최적화를 해서 성능을 향상시킬 수 있습니다.

vCenter 노드는 Management node 를 담당하고 PSC 노드는 라이선싱, 디렉토리 서비스, SO를 담당합니다. vCenter와 PSC를 동일한 노드에 둘 수도 있고 대규모 환경에서는 분리할 수도 있습니다.

하나의 PSC에 여러개의 VC를 연결할 경우 하나이 Single Domain으로 관리할 수 있고 하나의 디렉토리 서비스를 사용하기 때문에 롤, 권한 라이선싱, 테그 등을 공유해서 관리할 수 있습니다. 이 구조에서는 PSC가 Single Point of Failure 이기 때문에 PSC를 2개 설치하고 Replication을 해서 HA 구성을 할 수 있습니다. (vSphere 6.7 에서는 Embeded PSC 구조에서 HA를 직접 구성할 수 있기 때문에 PSC를 외부로 설치하고 HA 구성을 할 필요가 없읍니다.)

https://blogs.vmware.com/vsphere/2018/11/external-platform-services-controller-a-thing-of-the-past.html

DSL 이라는 Tag를 검색한다고 할때 Web Browser 는 VC 를 통해서 PSC에 검색을 하고 VC 간에 다시 검색을 하게 됩니다. VC 간에 지연이 있다면 Tag 검색에 시간이 많이 걸리게 됩니다. VC나 PSC 사이에 통신 속도가 6.0 에서는 10ms 이하, 6.5 에서는 30ms 이하일 경우 하나의 site로 구성을 합니다.

VCs, PSC 사이의 통신이 6.0에서 10ms 이상 6.5에서 30ms 이상일 경우 multi-site를 구성 합니다. (6.0/6.5 모두 사이트간 통신 속도는 100ms 이하를 권장 합니다.)

vCenter는 동시에 640개의 작업을 처리할 수 있고 최대 2,000개의 세션을 처리할 수 있습니다. Esxi host (6.0+)은 호스트당 16개의 cost를 처리할 수 있습니다. Cost는 작업에 드는 부하(?)를 의미하는데 Clone/relocate/vMotion은 2, Storage vMotion은 8과 같이 정해져 있습니다. 아래 그림에서 Host A 에서 B로 Clone을 할 경우 두 호스트 모두에 2라는 부하(?)가 걸립니다. 하나의 호스트에서 Clone을 할 경우 해당 호스트에 4의 부하가 걸립니다.

Datastore의 동시 작업은 128까지 가능하고 vMotion의 부하는 1, Storage vMotion의 부하는 16 입니다. 1Gb NIC은 동시에 4, 10Gb NIC은 동시에 8까지 동시 작업이 가능하고 vMotion 은 1의 부하를 가집니다.

CPU와 Memory는 70%가 넘지 않아야 합니다. CPU가 70%가 넘어갈 경우 어떤 프로세스 (vpxd, vSphere-client, 등)의 CPU 사용률이 높아졌는지 확인해야 하며 vpxd의 사용률이 높으면 CPU를 추가해야 합니다. java 서비스가 높은 경우 GC 관련 동작인지 확인하고 메모리를 추가해야 합니다. Memory의 경우 swap 이 되지 않도록 충분한 메모리를 추가해 주어야 하며 VM으로 VC를 실행하고 있다면 VM size 만큼 메모리를 Reserve 해야 합니다.

VCSA를 사용할 경우 CPU and Memory를 통해서 CPU/Memory 사용률을 확인할 수 있으며 자세히 보려면 Windows의 경우 Task manager와 Process explorer 를 사용해서 확인하고 java 프로세스의 경우 User name이나 Command Line을 통해서 어떤 서비스가 실행되는지 확인할 수 있습니다. VCSA의 경우 vimtop 명령을 통해 확인 가능 합니다. (CPU 100% 이면 1 core를 사용하는 것이고 CPU 200% 이면 2 core를 사용하는 것입니다.)

API 요청 때문에 성능 문제가 발생할 경우 vpxd 로그나 vpxd-profiler log를 사용해서 어떤 API가 호출되는지 확인하고 session 수는 얼마나 되는지 등 정보를 확인해서 Troubleshooting 해야 합니다.

DB의 경우 DB 가 사용하는 파티션이 부족한 현상이 발생하는지 확인해야 하고 성능 문제가 있을 경우 profiling 을 해서 성능을 확인해야 합니다. VCSA의 경우 /opt/vmware/vpostgres/current/bin/pg_top -U postgres -d VCDB를 통해서 profiling 정보를 확인할 수 있습니다.

vimtop 명령을 사용해서 vSphere client의 Heap 에 문제가 있는지 확인할 수 있습니다.

감사합니다.