오늘은 Guest OS의 Disk timeout 설정에 대해서 정리해보고자 합니다.

Windows VM에서 Disk timeout 값이 작게 설정되어 있는 경우에 SAN datastore 를 사용하면 성능에 문제가 있다는 문서가 있습니다. 

Inconsistent Windows virtual machine performance when disks are located on SAN datastores (1014)

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

Windows VM이 위치한 SAN datastore 에서 오류가 발생해서 Retry, Link down timeout, Failover 등이 발생하는 경우 조치에 걸리는 시간보다 Disk의 Timeout이 길어야 ESXi 레이어에서 Storage에 대한 복구가 될 때 까지 Disk 가 오류가 발생하지 않게 됩니다. 문서에서는 일반적인 60초로 설정을 하도록 하였으나 정확한 값은 각 스토리지 업체의 값을 따라야 하고 Windows VM에서 실행되고 있는 Application의 특성을 따라야 합니다.

좀더 자세히 살벼보면 Windows WDK의 SCSI Miniport Driver 문서에는 Timeout을 설정하지 않을 경우 10초로 설정된다고 되고 Windows 8 (Windows Server 2012) 부터는 Miniport driver에 설정된 timeout 값이 적용됩니다.

https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/registry-entries-for-scsi-miniport-drivers

하지만 아래 Microsoft 에서 나온 블로그 들을 보면 Timeout을 무조건 60 초로 설정하지는 말라고 되어 있습니다. Windows 에서는 Timeout이 발생하면 Storport 드라이버가 8번까지 재시도를 하게 되어 있어 만약 timeout이 60초로 설정되된 경우 최대 8분까지 (60초 x 8회) 재시도를 하는 것이 됩니다. SQL Server 나 Exchange Server와 같이 IO가 중요한 시스템들은 무조건 60초를 설정하기 보다는 Application 특성, 물리/가상머신 여부, Multipath, 스토리지 특성 등을 다 고려해서 적절한 값을 설정하는 것이 중요합니다.

Disk Timeout
https://blogs.technet.microsoft.com/hugofe/2011/09/07/disk-timeout/

Windows Disk Timeouts and Exchange Server 2010
https://blogs.technet.microsoft.com/exchange/2011/11/17/windows-disk-timeouts-and-exchange-server-2010/

Linux Guest OS의 Disk timeout도 설정되어야 합니다. 아래 문서를 보면 Linux Guest OS에서 SAN에서 IO retry, Path failover 등에 시간이 오래 걸려서 file system이 read-only로 설정되거나 Panic이 발생하는 경우가 있어 패치를 적용하고 Disk의 Timeout 값을 180으로 설정해야 합니다. (ESX 4 이후 부터는 VMware tools 를 설치한 경우 Timeout 값이 180으로 설정됩니다.)

Linux based file systems become read-only (51306)
https://kb.vmware.com/s/article/51306

Storage path failover might cause kernel panic in Linux kernels if using a virtual LSILogic adapter (Parallel or SAS) (1010759)
https://kb.vmware.com/s/article/1010759

Increasing the disk timeout values for a Linux 2.6 virtual machine (1009465)
https://kb.vmware.com/s/article/1009465

Filesystem on VMware Red Hat Enterprise Linux 4, 5, 6, & 7 guests went read-only
https://access.redhat.com/solutions/35329

Storage 업체의 권고를 확인해 보면 NetApp에서는 vSphere 환경에서 Linux 와 Windows 모두 60초를 설정할 것을 권장하고 있습니다.

What are the guest OS tunings needed for a VMware vSphere deployment?
https://kb.netapp.com/app/answers/answer_view/a_id/1001979/~/what-are-the-guest-os-tunings-needed-for-a-vmware-vsphere-deployment%3F-

결론은 Application/Storage 특성, ESXi 에서의 구성등을 모두 고려해서 Disk timeout을 설정해야 합니다.

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 에 문제가 있는지 확인할 수 있습니다.

감사합니다.

최근에 VMware 제품인 ESXi를 공부해야할 필요가 생겨서 공부를 하면서 정리를 해 보았습니다. 이제 공부를 처음 시작하는 것이기 때문에 어떤 내용들을 정리할 수 있을지 정하지는 않았지만 최대한 많이 자료를 접하면 정리가 될 것 같습니다.

VMware world TA8245-ESXi Internals - Better Understanding for Better Management and Troubleshooting

https://www.youtube.com/watch?v=Qq3H3yIh5UQ&list=WL&index=6&t=0s

자료가 VMworld 2010 자료라 현재는 내용이 달라졌을 수 있습니다. 큰 그림은 바뀌지 않았으리라 생각하고 정리해 봅니다.

Olivier Cremel 이라는 VMware의 Principal Engineer가 발표를 하는데 Linkedin을 보니 Google로 갔다가 다시 VMware로 컴백을 했습니다.

Files & Filesystems

어떤 부트 디바이스일 경우에도 단일 부팅 이미지로 되어 있고 모든 내용이 메모리로 로드가 된다고 합니다. 그래서 부트 디바이스에 문제가 발생 하더라도 운영에 문제가 없다고 합니다. Windows의 경우에는 일부 시스템 이미지가 로드 되지 않은 상태이고 페이지 아웃 까지 가능해서 부팅 디바이스가 문제가 생가면 1분 안에 시스템이 크래시 됩니다. 아무래도 가상화 부분만 담당하기 때문에 좀더 안정적으로 만들 수 있었던것 같습니다. 

ESXi의 베이스 이미지는 압축되어 있고 메모리에 압축이 해제되어 로드가 됩니다. VIB (VMware Installation Bundles) 파일은 압축이 해제되지 않고 Tardisks 라는 방식으로 Mount 됩니다. (https://blogs.vmware.com/vsphere/2011/09/whats-in-a-vib.html)

/etc 디렉토리에 있는 파일들은 persisted state files 로 (esx.conf, inetd.conf) tardisk에 위치라며 sticky로 설정된다. /var/spool/cron/root/cronjobs 와 같은 파일등은 running state가 유지되지 않는다. persisted state file 들은 root filesystem에 마운트되고 메모리에서 유지 관리 됩니다.

Persistence 파일들을 변경 하려면 rebuild를 하고 부트 디바이스에 저장을 해야 합니다.

Diskless, Stateless가 가능 합니다. Diskless는 부팅 한 후 부트 디바이스를 사용하지 않는 것이고 Stateless는 state 정보가 ESXi 로 부터 얻어지지 않습니다.

Archive 에서 Tardsk로 파일이 올라갑니다. VisorFS에 대한 상세한 기술 문서는 VMware lab에 있는데 다음번에 정리를 해보고자 합니다. (https://labs.vmware.com/vmtj/visorfs-a-special-purpose-file-system-for-efficient-handling-of-system-images)

vdf, vdu 명령으로 tardisk 의 사용률을 볼 수 있습니다.

state file은 /etc/vmware/esx.conf 파일에 있고 기본 환경에서 실행한 명령은 /tmp.cmd.log, /var/run/cmd.pid 에 있고 로그 파일은 /var/log/vmkernel.log에 있습니다.

Ramdisk 는 32MB 정도의 크기를 가지는데 90~95% 정도의 사용률을 보입니다. 버그나 비정상적인 상황(TSM에서 큰 파일을 다운받기)를 하지 않는 경우 디스크가 full 되는 일은 없는데 Ramdisk가 full 되면 시스템이 불안정한 상태가 됩니다. 이 경우 문제점을 찾은 후 조치를 취하거나 /var/log 파일을 삭제 하거나 Ramdisk 크기를 조절해서 조치해야 합니다. (https://kb.vmware.com/s/article/2001550)

컴포넌트를 live system에 설치 하는 것은 Ramdisk를 마운트 하고 tardisk 이미지를 Ramdisk에 다운로드하고 tardisk를 마운트 하는 작업으로 적절한 크기의 메모리가 있어야 하며 overcommitted 된 시스템에서는 해서는 안된다고 합니다.

Esxi의 디스크와 Filesystem 구조는 다음과 같습니다.

Agents & Execution environment

코어 실행 모듈은 vmkernel 이고 코어 익스텐션은 kernel 모듈, 드라이버가 있습니다. Idle, helper, Driver 는 시스템 권한으로 실행됩니다. 유저 레벨 프로세스도 있는데 여기서 유저 레벨은 End user를 의미하는 것이 아니라 실행 권한이 시스템 레벨이 아니라는 것입니다.

Userworld에는 어떤 일이 있을 수 있을까요?

Out of memory가 발생하면 random 으로 userworld 프로세스를 종료 합니다.

메모리 부족 현상이 발생하면 ENOMEM이나 NULL이 되고 Exception 핸들러가 없이 크래시되거나 행이 됩니다.

다른 Userworld에는 영향이 없으며 리소소를 많이 사용한 모듈이 종료 됩니다.

CPU 부족 현상이 발생하면 Userworld가 느려 집니다.

Remote CLI나 PowerShell CLI의 첫 엔트리 포인트는 hostd 입니다. hostd가 응답하지 않을 경우 DCUI를 사용하여 네트워크, 에이전트 등을 확인합니다. 이마저도 동작하지 않은다면 VMware support에 연락을 하고 TSM을 Enable 한 후 문제 해결을 합니다.

Ramdisk를 파일을 저장하는 용도로 사용하지 않아야 합니다. root filesystem에서 변경한 내용은 재부팅이 되면 삭제 됩니다.

Userworld 의 리소스 풀에는 제약이 있어서 너무 많은 명령을 실행하면 에러가 발생할 수 있고 CPU를 많이 사용하는 명령은 CPU 제한 때문에 행 상태로 보일 수 있습니다.

Userworld 는 일반적인 용도를 위한 것이 아닙니다. ps 결과는 vmkernel 월드의 결과를 보여주고 vsortfs 는 vdf와 vdu를 사용해서 사용률을 확인해야 합니다. Debug VID를 설치해서 추가적인 Troubleshooting command를 실행할 수 있습니다.