RHEL7 will bring better performance for virtualization

주변기술 시리즈 #3,  RHEL7 가상화 성능 개선점

가상화, 가상화… 온통 가상화가 화두죠. 클라우드가 가능한 것도 자원과 공간의 가상화가 있었기에 가능한 것이고요.
얼마전 Red Hat Enterprise Linux(RHEL) 7.0이 릴리즈되었습니다. 클라우드와 가상화가 자리잡아가고 있는 시점에 등장했기에 더욱 기대가 되는 버전입니다. 그만큼 가상화 측면에서 개선된 점도 많은데요 오늘은 관련 기술들 몇가지 살펴보겠습니다.

Multiple Queue NICs
이전에 RHEL 6.6에 포함될 예정이고 7.0에도 포함될 것이라고 말씀드렸던 그 기능. virtio_net 반가상화 네트워크 드라이버가 드디어 Multiple Queue를 지원합니다. 네트워크 부하가 클 때 인터럽트를 하나 이상의 vCPU에 분산하여 성능을 개선시킬 수 있는 기능으로 RHEL을 비롯한 리눅스 가상머신에서만 지원됩니다.

Multiple Queue virtio_scsi
네트워크쪽에서 개선되었다면 스토리지쪽도 필요하겠죠? SCSI 장치를 위한 virtio_scsi 드라이버도 역시 Multiple Queue를 지원하게 되었습니다.

Bridge Zero Copy Transmit
가상머신과 KVM 호스트 사이에 네트워크 연결은 보통 논리적인 네트워트 스위치 역할을 수행하는 Linux Bridge 사용하게 되는데요, 가상머신 <-> Bridge로 트래픽이 이동하면서 Memory Copy가 일어나게 됩니다. 대량의 데이터가 송수신되는 환경이라면 이 Memory Copy에 따른 Overhead가 성능에 지대한 영향을 미치는데요, Zero Copy Transmit라는 말은 말그대로 가상머신에 Mapping되어 있는 데이터를 Bridge로 Memory Copy하지 않고 바로 Mapping하여 사용할 수 있도록 하는 기능입니다. Zero Copy는 10G NIC 장치에서 널리 사용하는 기술인데, 이제 Bridge에서도 경험할 수 있게 되었습니다. 상당한 성능 개선이 기대되는 부분입니다. (기본은 비활성화되어있네요.)

⁠Para-Virtualized Ticketlocks
가상머신의 vCPU는 사실 KVM 호스트 입장에서는 하나의 Thread로 동작합니다. 때문에 물리적인 CPU core가 8개라도 가상머신에는 그 이상의 vCPU를 할당할 수도 있고 여러 가상머신이 물리적인 core보다 몇배 많은 vCPU를 사용할 수도 있는 것 입니다. 그러나 그만큼 vCPU간에 상호 scheduling하고 대기하는 시간도 길어질 수 있는데요, 경우에 따라 먼저 대기하던 vCPU보다 나중에 도착한 vCPU thread가 물리 CPU를 사용하는 등 불공평등한 상황이 벌어질 수 있습니다. 때문에 이들 locking 매커니즘을 개선한 반가상화 드라이버인 pvticketlocks를 도입하여 이러한 불평등이 다소간 해소되었습니다. 역시 성능 개선이 예상됩니다.

⁠Intel VT-d Large Pages
IOMMU 기능을 활용하면 NIC등 물리적인 장치를 Emulation 없이 가상머신이 직접 Local 장치인 것처럼 점유하여 사용할 수 있습니다. 이를 PCI pass-through라고도 하는데요, 그동안 IOMMU를 사용하더라도 데이터를 리눅스 커널의 page 단위(4 KiB)로 밖에 처리하지 못하는 제약이 있었습니다. 역시 대량의 데이터를 처리하는 하드웨어, 예를 들면 10G NIC,에서는 이러한 제약으로 인해 PCI pass-through에 따른 하드웨어 성능을 100% 경험하지 못하는 어려움이 있었습니다. 7.0부터는 2MiB, 1GiB 단위의 Large Page 크기를 지원하게 되어 TLB hit률이 높아져 상당한 성능 개선이 이뤄질 수 있습니다. 기능의 특성상 일부 하드웨어제 제한적인 지원이 되는데요,  RHEL 6.6에도 포함될 예정입니다.

⁠KVM Clock Get Time Performance
시스템 콜이나 라이브러리 콜을 추적해보면 생각보다 많은 프로그램들이 시스템 시간을 읽는데 CPU 시간을 소진하는 것을 알 수 있습니다. 라이브러리에 의한 간접적인 영향도 있어서 실제로 응용 프로그램에서 호출하지 않더라도 발생할 수 있습니다. 특히 금융권이나 공공시장의 응용프로그램에서 중요한데요, RHEL7에서는 KVM 가상 머신에서의 성능이 개선되어 효과를 보실 수 있습니다.

⁠Live Migration Thread
이 부분은 바로 이전에 ‘실전 시리즈, 라이브 마이그레이션시 가상머신 CPU 사용량 변화’에서 라이브 마이그레이션시에 CPU steal time에 따른 overhead가 있다고 지적해드렸던 부분입니다. RHEL 7.0부터는 라이브 마이그레이션이 별도의 Thread에서 처리되도록 분리되어 vCPU에서의 성능 저하가 사라질 것으로 예상됩니다. 실험에서 확인했던 바와 같이 일시적으로 15%정도 하락되었던 만큼 느낌으로 와닿는 성능 개선의 폭이 크지 않을 수도 있지만, CPU 사용률이 높은 가상머신에서는 민감한 부분이 아닐 수 없습니다.

그외에도 여기에 다 거론하기 힘들만큼 다수의 기능이 개선되었습니다. 하루가 다르게 변화하고 있는 가상화, 클라우드 환경이니만큼 성능상 이점을 얻고자 하신다면 RHEL 7.0을 고민할 때입니다.

참고자료
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.0_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.0_Release_Notes-Virtualization.html

Advertisements

How to use Direct LUN in oVirt/RHEV?

실전 활용팁, Direct LUN 사용방법

oVirt/RHEV에서 실행되는 가상머신의 Disk(이하 vDisk)는 스토리지 도메인에서 할당해서 사용하게 됩니다. 이들 스토리지 도메인은 FCP/iSCSI의 경우 LVM을 사용하고, NFS/Gluster의 경우에는 단일 Mount Point를 스토리지 도메인으로서 사용하고 있습니다. Direct LUN 기능의 경우는 말 그대로 vDisk 할당시 스토리지 도메인을 사용하는 것이 아니라 FCP/iSCSI의 LUN 하나를 그대로 vDisk로 사용할 수 있도록 해주는 기능입니다.

이를 위해서는 스토리지 PCI Pass-throiugh를 위해 VirtIO-SCSI 기능을 사용해야 합니다. 당연히 성능적인 측면에서의 이점이 있으며, vDisk를 LUN 단위로 관리할 수 있는 장점이 있습니다(만 Direct LUN의 경우 꼭 필요한 경우가 아니라면 가상화라는 측면에서 적합해보이지 않습니다)

적용 방법은 다음과 같습니다.

  1.  oVirt/RHEV Admin Portal 접속 -> Virtual Machine 탭 선택
  2.  New 버튼 클릭하여 New VM 윈도우 실행
  3.  Advanced Option 선택 -> Resource Allocation menu 선택 -> [v] VirtIO-SCSI 활성화
  4.  Virtual Disk 설정 -> External (Direct Lun) 선택 -> Interface [VirtIO SCSI] 선택

이렇게 되면 VirtIO-SCSI 드라이버를 통해 LUN이 가상머신에 바로 보이게 되고, Local Disk처럼 사용할 수 있게 됩니다.

How to calculate Monitoring indicators in oVirt Admin Portal?

oVirt Deep Dive 시리즈, oVirt Admin Portal에서 보여지는 모니터링 수치 계산방법?

하이퍼바이저 CPU 사용량 수치

각 하이퍼바이저에는 oVirt-engine과의 통신과 제어를 담당하는 vdsm 서비스 데몬이 실행되고 있습니다. 소스를 분석한 결과 하이퍼바이저의 CPU 사용량은 vdsm 데몬이 /proc/loadavg 파일의 두번째 필드를 활용하는 것을 알수 있었습니다.

        try:
            self.cpuLoad = file(‘/proc/loadavg’).read().split()[1]
        except:
            self.cpuLoad = ‘0.0’

/proc/loadavg 파일의 경우 리눅스 시스템의 부하정보를 실시간으로 제공하는 파일이기 때문에 하이퍼바이저의 CPU 사용량으로 이용하는데 무리가 없습니다.

하이퍼바이저 Memory 사용량 수치

Memory 사용량 역시 vdsm이 산출하여 oVirt-engine에 전달하고 있습니다. 계산방법은 흔히 리눅스 시스템의 Memory 정보를 확인할 때 사용하는 free 명령어의 정보와 거의 동일한 수치를 이용해 계산합니다.

….
        meminfo = readMemInfo()
        freeOrCached = (meminfo[‘MemFree’] +
                        meminfo[‘Cached’] + meminfo[‘Buffers’])
        self.memUsed = 100 – int(100.0 * (freeOrCached) / meminfo[‘MemTotal’])
        self.anonHugePages = meminfo.get(‘AnonHugePages’, 0) / 1024
….

위의 코드에서 확인할 수 있듯이 Memory Total 크기에서 Free + Cached + Buffers 영역을 제외한 부분을 Used로 사용하고 있습니다.

하이퍼바이저 Network 사용량 수치

이 부분은 깊이 분석하지는 않았으나 전달되는 수치는 ifconfig에서 관련 네트워크 인터페이스의 rx/tx 패킷수를 이용해 계산되는 것으로 생각됩니다.

# vdsClient -s 0 getVdsStats | egrep ‘rx|tx’

가상머신 CPU 사용량 수치

가상머신의 부하 수치중 Guest Agent 가 설치되지 않았을 경우에는 오직 CPU 사용량만이 출력됩니다. 이는 vCPU의 경우 하이퍼바이저에서 추정가능한 요소이기 때문입니다.

libvirt 라이브러리는 가상머신의 실질적 프로세스인 qemu로부터 전달되는 다음과 같은 CPU 사용량을 vCPU의 수로 나누어 계산합니다.

cpuUser = 3.18
cpuSys = 0.86
cpuIdle = 95.96

수치가 위와 같을 때 vCPU가 1개라면 약 cpuUser+cpuSys 수치인 4% 정도로 표현되며 만약 2개라면 2%가 됩니다.

가상머신 Memory/Network 사용량 수치

가상머신내의 Memory/Network의 사용량의 경우 내부에 설치된 Guest Agent(기초 시리즈 참조)를 통해 전달받은 정보를 그대로 활용하게 됩니다. Guest Agent의 경우 하이퍼바이저와 마찬가지로 가상머신이 리눅스인 경우 리눅스 시스템의 일반적인 부하 수치를 읽어 전달하게 됩니다.

Like

실전 활용팁, 라이브 마이그레이션시 가상머신 CPU 사용량 변화

Best Practice, vCPU utilization change while live-migration

얼마전에 라이브 마이그레이션에 대해 살펴보았는데요, 라이브 마이그레이션시에 가상머신 내의 CPU 사용률이 10~15% 정도 증가하는 현상이 발견되었습니다. 아무런 작업도 수행되지 않는데 이상했지요.

라이브 마이그레이션을 수행하면서 가상머신내에서는 vmstat 명령어를 통해 지속적으로 측정하도록 한 결과, ‘st’ 필드가 10~15%정도 거의 정확히 사용률이 증가한만큼 올라간 것을 확인하였습니다. 즉 vCPU의 CPU cycle을 라이브마이그레이션을 위해 Host 차원에서 소진하면서(Steal time: st) 그만큼 증가한 것으로 측정된 것으로 생각됩니다.

그래서 Steal time에 대해 좀 알아봤는데요, 예상한대로였습니다.

“Steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor.” — http://blog.scoutapp.com/articles/2013/07/25/understanding-cpu-steal-time-when-should-you-be-worried

혹시 운영중에 이런 현상을 목격하시더라도 놀라지 마세요.

실전 활용팁, 라이브 마이그레이션 준비

Best Practice, live-migration prerequisites

oVirt/RHEV의 강점 중 하나가 online 상에서 가상머신을 서로 다른 ovirt-node(하이퍼바이저, 호스트)로 라이브 마이그레이션이 가능하다는 점 입니다. 서비스의 지속성 관점에서 매우 중요한 기능인데요, 실시간으로 서비스 중단 없이 호스트간에 이동이 가능한만큼 몇가지 조건을 만족시켜줘야 합니다.

* 용어 안내

  • Source 호스트 : 라이브 마이그레이션 대상 가상머신이 실행중인 호스트
  • Destination 호스트 : 실행중인 가상머신이 옮겨갈 대상 호스트

* 라이브 마이그레이션을 위한 조건

  1. Source, Destination 호스트가 모두 동일한 oVirt Cluster 소속, 동일한 CPU 호환성을 가져야 함 (Intel/AMD 벤더 및 CPU microarchitecture – Nehalem, SandyBridge 등)
  2. Source, Destination 호스트가 모두 Up 상태
  3. Source, Destination 호스트의 oVirt/RHEV Management Network 또는 Migration Network(3.3 이후)를 통해 접근 가능
  4. 대상 가상머신이 사용하는 oVirt/RHEV 스토리지 도메인에 Source, Destination 호스트가 모두 접근 가능
  5. Destination 호스트에 대상 가상머신 실행에 필요한 충분한 여유 메모리
  6. Source, Destination 호스트간 DNS 또는 /etc/hosts에 host명 resolve 필요
  7. 대상 가상머신에 ISO 이미지가 mount되어 있거나 attach 되면 안됨
  8. oVirt/RHEV 3.1-> oVirt/RHEV 3.0 라이브 마이그레이션은 지원하지 않음

* 대표적 라이브 마이그레이션 실패 사례

  • ISO 파일을 마운트 한 상태에서 시도 ==> umount, detach 후 재시도
  • 오래된 vdsm, libvirt 버전 사용 ==> 가능한 3.2 이후 최신 버전 사용 (3.4 권장)
  • 라이브 마이그레이션에 사용되는 네트워크 대여폭 부족에 따른 취소 ==> 대여폭 확보, 또는 3.3 이후 버전에서는 별도의 live-migration network 분리
  • 가상머신의 높은 부하로 인해 주어진 시간내 마이그레이션을 성공할 수 없는 경우 취소 ==> 부하가 줄었을 때 재시도, 또는 vdsm 설정에서” migration_downtime” 값을 늘린 후 재시도
  • RHEL 5.7 이전 버전에서 시스템 패닉 발생 ==> nmi_watchdog=0 커널 옵션 추가

 

참고 자료 : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4/html/Administration_Guide/Live_migration_prerequisites.html

실전 활용팁, 업무별 oVirt Guest 권장 디스크 유형

Best Practice, recommended virtual disk type in oVirt by workload

oVirt에서는 다음과 같이 2가지 가상머신 디스크 유형을 지원하고 있습니다. Thin Provision의 경우 디스크 공간을 절약할 수 있는 반면 단점도 있기 때문에 적합한 workload에 대한 신중한 선택이 필요합니다.

1) Preallocated 방식

  • DB, FTP, WAS 등 I/O가 비교적 많은 가상머신
  • 최초 생성후 장기간 운영되는 전통적 서버용 가상머신
  • 정기적인 백업등이 수행되는 중요 업무 환경
  • 공간 효율성보다 시스템 성능이 중시되는 서비스 환경

2) Thin Provision 방식

  • 데스크톱 등 생성 후 I/O가 비교적 적은 가상머신
  • 필요에 따라 생성되어 단기간 사용되고 사라지는 VDI용 가상머신
  • 클라우드 환경이 고려된 scale-out형 서비스
  • 공간의 효율성이 시스템 성능보다 중시되는 서비스 환경

oVirt/RHEV를 작은 규모의 클라우드 플랫폼으로 사용하는 경우가 아니고, 서버 가상화 관점에서만 본다면 Preallocated를 선택하는 것이 좋습니다.

oVirt/RHEV 3.4의 새로운 기능 #5. Hot plug CPU (Preview)

oVirt/RHEV 3.4 New Feature #5. Hot plug CPU (Preview)

oVirt는 데이터센터 가상화 플랫폼인것을 잘 아실 것 입니다. 때문에 VM의 Scale-out도 중요한 요소이기는 하지만 Cloud 플랫폼과 달리 workload 변화에 따른 Scale-up에 대한 요구도 충족할 수 있어야 합니다. 따라서 OpenStack에서의 Flavor같은 고정된 VM Type에 기반하기 보다는 그때 그때 필요한만큼의 자원을 할당하여 사용하는것이 일반적입니다. 이러한 가상 컴퓨팅 자원, 예를 들면 CPU, Memory, Disk, Network device등은 VM을 생성하기 이전, 또는 VM을 Down시킨 후에 가감하여 사용하고 있습니다. 다만 가상화 플랫폼에서 실행되는 많은 응용의 경우 Cloud 대비 상대적으로 lifecycle이 길고 S/W 차원의 Load Balancing이 안되어 있는 경우가 많아 Downtime이 가장 큰 고려사항이 되곤 합니다.

oVirt 3.4에서는 비록 Preview 기능이긴 하지만 vCPU를 VM 실행중에 Downtime없이 추가 지정해줄 수 있는 기능입니다. 사실 vCPU를 추가뿐만 아니라 제거하는 기능도 제공하고 있지만 제거(UnPlug)의 경우 VM의 운영체제에서도 지원해야하고 사전 조치가 필요하는 등 아직은 다소 미흡한만큼 좀 더 지켜볼 일입니다.

http://www.ovirt.org/Hot_plug_cpu