주변기술 시리즈 #4, KVM live-migration internal

주변기술 시리즈 #4, KVM live-migration (가상머신의 라이브마이그레이션)

가상화 기술의 장점중 하나가 바로 라이브마이그레이션입니다. 라이브마이그레이션이 필요한 이유는 여러가지가 있으나 결과적으로 가상머신의 downtime을 줄이고 서비스의 High Availability를 달성하기 위함이라고 볼 수 있습니다. 심지어 service의 life-cycle이 상대적으로 짧고, HA를 application layer에 의존하도록 하는 IaaS cloud computing 플랫폼에서도 대세는 라이브마이그레이션을 지원하는 방향으로 가고 있습니다. OpenStack의 지원이 그 단적인 예라고 할 수 있지요.

라이브마이그레이션을 위한 조건 및 실패사례는 이전 포스팅을 참고하시고요,
https://ovirtkorea.wordpress.com/2014/06/23/%EC%8B%A4%EC%A0%84-%ED%99%9C%EC%9A%A9%ED%8C%81-%EB%9D%BC%EC%9D%B4%EB%B8%8C-%EB%A7%88%EC%9D%B4%EA%B7%B8%EB%A0%88%EC%9D%B4%EC%85%98-%EC%A4%80%EB%B9%84/

최근에 KVM 라이브마이그레이션 시에 내부적으로 어떤 일들이 읽어나는지, 왜 메모리 변화가 큰(높은 부가) 가상머신의 라이브마이그레이션이 실패하는지에 대한 분석해야할 일이 있었는데요, 관련하여 유용한 자료가 있어 공유합니다.
http://developerblog.redhat.com/2015/03/24/live-migrating-qemu-kvm-virtual-machines/

대략적인 동작은 다음과 같습니다.

  • Stage 1: 가상머신의 모든 메모리를 dirty(복사 대상)으로 설정합니다.
  • Stage 2: 반복적인 iteration을 거쳐 이들 dirty page들을 복사합니다. (1회 iteration을 전송하는 사이에 추가 변경된 page들은 dirty로 재전환), 만약 live migration에 주어진 현재 전송되는 속도(지속적으로 계산)를 고려하여 남은 dirty page가 downtime(기본값 300 ms)내 전송이 가능한 수준이 되면 Stage 3로 전환
  • Stage 3: Source로부터 가상머신을 일시 멈추고, 나머지 dirty page를 destination에 복사합니다. 그리고 destination에서 가상머신을 재시작합니다.

위 과정중에 가장 중요한 부분은 Stage 2 단계로서 이에 영향을 미칠 수 있는 요소는 2가지 입니다.

  • downtime : 허용 가능한 최대 downtime(마이그레이션 마지막 단계에서 일시적, 기본값 300 ms)
  • speed : 초당 전송에 사용할 최대 bandwidth 값(기본 32 MiB/s)

그러나 stage 2에서 전송되는 속도보다 dirty로 변하는 속도가 클 경우에는 결국 라이브 마이그레이션은 실패하게 됩니다. dirty로 변하는 page는 KVM이 추적하게 되며 QEMU에서 KVM API를 통해 각 iteration에서 확인하게 됩니다.

실전 활용팁, KVM 가상화에서 CPU의 HyperThread 기능을 사용할 것인가?

실전 활용팁, KVM 가상화에서 CPU의 HyperThread 기능을 사용할 것인가?
Best Practice, HyperThread feature CPU provides is helpful for KVM virtualization?

가상화 플랫폼에서는 CPU를 포함한 모든 하드웨어 자원이 그야말로 가상화 되기 때문에 컴퓨팅 자원에 대한 수량을 산정하는게 쉽지는 않습니다. 과연 vCPU를 하나의 독립적인 CPU 자원으로 산정해야 하느냐하는 부분과 vCPU 2개가 물리 CPU 1개보다 나은 결과를 가져오는가 하는 등의 이슈도 남아있지요. 그렇더라도 아직까지는 vCPU 수로 컴퓨팅 파워는 산정하는 분위기 인거 같습니다.

vCPU 산정에서 빼놓을 수 없는것이 바로 물리 CPU Socket의 수, 물리 CPU의 Core 수, 그리고 HyperThread(이하 HT) 기능의 활용 여부등일겁니다. 기본적으로 여러 가상머신이 동시에 실행되는 환경이기 때문에 특별히 CPU isolation 과 pinning을 하지 않는한 어차피 vCPU : CPU가 1:1 대응은 어렵습니다. 다만 한가지 지켜져야 할 부분은 “성능상의 이점이 없기 때문에” 개별 가상머신의 vCPU 수는 호스트의 물리적인 CPU 수와 같거나 작아야 한다는 것입니다.

예를 들어, 물리적인 CPU가 32개라면 단일 가상머신에 할당할 최대 vCPU수는 32개 또는 이하여야 한다는 말입니다. (논리적으로는 그 이상도 가능하지만 장점이 없죠)

여기서 고민은 그럼 물리적인 CPU에 HT 기능을 사용해야하는가일텐데요, 답변은 No 그리고 Yes 입니다.

No)  HT의 경우 태생적 특징으로 인해 실제로 물리 Core만큼의 성능을 제공해주지 않습니다. HT의 경우 Workload에 따라 상당한 편차를 가져오지만 대체로 15~30% 성능 개선이 있다고 알려져 있습니다. 즉 총 16 Core 시스템의 경우 HT 활성화시 최대 21(16 * 130%)개의 CPU 성능을 보인다고 생각하면 되겠습니다. 여기서 사용자와 관리자(또는 Automation system)에게 오해를 줄 수 있습니다. HT 활성화시 이들은 CPU가 32개라고 생각하고 Allocation 해줄 가능성이 높은데 이게 Overall Performance에 역효과를 가져올 수 있다는 것 입니다. 추가적으로 Interrupt가 많은 환경에서 HT가 큰 도움을 주지 않는다고 합니다. 따라서 대량의 KVM 가상화를 구현하는 환경에서는 Production 기준 HT 비활성화를 권장합니다.

Yes) 그렇다고 항상 No는 아닙니다. 만약 가상머신내 Workload가 CPU intensive하거나 SMP 환경에 맞춰 개발된 경우라면 HT 활성화가 더 좋은 결과를 가져올 수 있습니다. HPC workload나 Big-Data 등 대량의 데이터 처리 솔루션등이 실행되는 경우라면 HT가 도움을 줄 수 있습니다.

따라서 자신의 Workload를 파악하고 그에 맞춰 HT 활성화를 고민하시면 되겠습니다. 물론 위 내용은 여러 정보를 바탕으로 한 제 개인 의견이므로 참고용으로만 삼으시기 바랍니다.

실전 활용팁, 이렇게 구축 하시면 안 돼요!

실전 활용팁, 이렇게 구축 하시면 안 돼요!
Best Practice, Bad architectures we have to avoid in Production.

정말 오랜만에 돌아왔습니다.

요즘 oVirt/RHEV 구축 사례를 심심치 않게 듣게 되는데요, 이전 포스팅에서 몇가지 권장 아키텍처를 말씀드리긴 했지만 몇가지 우려스러운 아키텍처가 있어 이번 활용팁을 쓰게 되었습니다. 물론 비즈니스 니즈나 제약조건등에 따라 불가피하게 선택한 경우겠지만 가능하면 피해야 할 구현을 말씀드리고자 합니다.

1) oVirt/RHEV 3.1 이전 버전 사용
oVirt 가장 최신 버전은 3.5, RHEV도 가장 최신 버전은 3.4가 나와 있습니다. 최신 버전이 나왔다는 의미는 당연히 기능적인 개선도 있지만 많은 버그와 알려진 문제점들이 해소되었다는 이야기지요. 기 구축된 환경도 업그레이드를 고려하는데 신규 구축에 굳이 옛날 버전을 사용할 필요는 없을 것 입니다. 특히 3.1 이전 버전이라면 강력하게 3.4 이후 버전을 선택하시길 권해드립니다. RHEV도 3.5 베타가 나온만큼 현재 도입 계획중이시라면 3.5를 고려하세요.

2) Local storage domain 사용
oVirt/RHEV는 Local Storage Domain(하이퍼바이저의 local disk 사용)도 지원하고 있습니다. 다만 Local Storage Domain의 경우 Datacenter 1 : Clsuter 1 : Hypervisor 1로만 구축 가능하기 때문에 oVirt/RHEV를 도입하는 취지와 맞지도 않거니와 많은 좋은 기능들을 사용할 수 없다는 단점이 있습니다. Local Storage Domain의 사용은 PoC나 테스트를 위한 기능이라는거 잊지 마세요.

3) 1 storage domain size == 1 virtual machine size
1개 스토리지 도메인당 1개의 가상머신를 설치하고 용량도 거의 비슷하게 구축하게 되면 Snapshot, Template등의 기능을 사용하지 못할뿐만 아니라 결과적으로 가상머신내 복구 불가한 장애 발생 시에 시간이 오래걸리는 재설치 또는 사전에 Export 해 두었던 가상머신의 Import외에는 선택 방법이 없습니다. 오늘을 살지만 내일도 살아야 하니 아키텍처는 좀 더 유연하게 설계하는 것이 좋겠죠?
 
4) 100 Mbit oVirt/RHEV management network 사용
소규모라면 100 Mbit도 받아들일만 하지만 최소 1 Gbit network bandwidth는 할당해주셔야 됩니다. 요즘 100 Mbit 쓰는데가 어디있나 싶지만 management network라고 해서 쉽게 생각하시고 남는 NIC를 사용하는 경우도 있고, 1 Gbit이라도 migration network 분리 없이 management network를 공용으로 사용하는 경우까지 포함됩니다. oVirt/RHEV는 management network를 통해서 주기적으로 하이퍼바이저의 상태 정보, 가상머신 정보등을 갱신하기 때문에 하이퍼바이저나 가상머신 수가 증가될 경우 생각보다 많은 대여폭이 필요할 수 있습니다.
추가적으로 oVirt/RHEV 플랫폼은 OpenStack과 같이 비교적 lifecycle이 짧은 workload뿐만 아니라 lifecycle이 긴 전통적인 workload도 서비스해야 하기 때문에 Live-migration 수요가 지속적으로 발생합니다. 따라서 아키텍처 설계시에 Migration network의 분리도 반드시 고려되어야 합니다.

5) 1 Gbit storage network 사용
가상머신의 부하의 상당수는 당연히 Storage에서 옵니다. 일반적으로 기업이나 기관에서 도입하실 때에는 전용 광라인에 충분한 대여폭을 가진 FCP/iSCSI등을 사용하시지만 간혹 비용적인 부담으로 인해 낮은 대여폭을 가진 NFS, iSCSI, Glusterfs등을 사용하는 경우가 있습니다. Bonding으로 성능 개선을 계획하시겠지만 생각보다 쉽게 원하는 성능을 얻기 어렵습니다. Storage network는 10 Gbit 이상으로 가시는 것을 권해드리며 최소 8 Gbit는 확보해주세요.

6) 2 TB vRAM, 8 TB vDisk 사용
실제 이런 경우까지는 없겠지만 이론적으로 oVirt/RHEV에서 하나의 가상머신에 2 TB 메모리와 8 TB 디스크를 할당해줄 수 있습니다. 하지만 이렇게 큰 하드웨어 리소스가 필요한 서비스라면 물리적인 서버를 적극 추천하겠습니다. 메모리건 디스크건 단일 가상머신에 수백 GB~수TB 단위는 좀 아닌거 같습니다. 불가피하게 사용해야만 하는 경우에는 물론 사용하실 수 있습니다.

7) 가상머신내 Bonding 사용
가상머신에 2개의 vNIC를 할당하고 이를 다시 Bonding으로 묶는 것은 불필요한 작업입니다. 성능 개선이나 SPoF를 대비하고자 한다면 하이퍼바이저 수준에서 Bonding 처리하는게 맞습니다. 가상머신내에서는 목적별로 하나의 vNIC를 사용하는게 좋습니다.

혹시 이러한 아키텍처가 여러분께서 생각하고 계셨던 것은 아니시지요? 만약 다른 특이한 아키텍처를 목격하셨다면 공유 부탁드립니다.

oVirt/RHEV 3.5 새로운 기능 총정리!

What’s New inoVirt/RHEV 3.5?

얼마전에 독일 Düsseldorf에서 oVirt Workshop과 KVM Forum 2014이 함께 열렸습니다. oVirt가 KVM 가상화 기술의 가능성을 실현하는 기본 플랫폼이여서인지 함께 논의하는 것이 자연스러워 보입니다.

oVirt Workshop 오프닝으로 oVirt 3.5의 주요 변화를 소개했는데요, 정리하면 다음과 같습니다.
http://www.ovirt.org/images/f/f1/Whats_new_in_3.5.pdf
1) UI – PatternFly
– 과거와는 달리 요즘의 오픈소스 프로젝트들은 command line을 벗어나 UI가 필요한 경우가 많아졌습니다. 그런데 문제는 각 오픈소스 프로젝트마다 UI가 통일성이 없고, 사용할만한 오픈소스형 UI 리소스도 없어서 디자인 감각이 떨어지는 오픈소스 개발자들이 어려움을 겪었습니다.
– PatternFly는 이러한 어려움을 해소하고자 시작된 프로젝트입니다. Red Hat의 많은 UI 담당자가 커뮤니티에 기여하는 취지에서 시작해 오픈소스처럼 누구나 참여할 수 있는 UI 프로젝트입니다. (https://www.patternfly.org)
oVirt 3.5도 이 PatternFly 디자인으로 갈아탔습니다. 엄청나게 많은 변화가 있는 것은 아니지만 디자인이 전체적으로 미려해졌고, 느낌은 뭐랄까… 좀 더 고급집니다. (전적으로 개인적인 취향입니다)

2) Deployment
– oVirt는 OpenStack과 달리 모듈형 구조는 아닙니다. 그러다 보니 Central Management 환경인 oVirt-engine(RHEV-M)의 운영에 따른 설치, 관리의 용의성이 높은 반면, Scale out에 상대적으로 어려움이 있었습니다. oVirt 3.5부터는 그동안 oVirt-engine과 하나의 시스템에 모두 설치되어 있어야 했던 websocket-proxy, DWH, Reports등이 외부의 시스템에 설치되어 동작할 수 있게 되었습니다. 특히 DWH, Reports의 경우 무거워 oVirt-Engine 시스템의 부하 분산에 큰 개선이 이뤄질 것을 기대됩니다.
oVirt-Engine이 Appliance 형태로 배포되어, 별도의 시스템에 설치하는 과정없이 가상화 한경에서 바로 import시켜 oVirt-Engine을 사용할 수 있게 되었습니다.

3) Infrastructure
– 사용자 인증처리 관련 코드가 완전히 새롭게 개선되었습니다. 물론 외부적인 차원에서 그 차이를 느끼기는 어렵겠지만, 개인적으로 향후 OpenStack Keystone등과 같은 인증시스템과의 통합이 좀 더 수월한 방향으로 개선된 것으로 생각됩니다.
– Fencing 부분의 사용성도 개선되었는데요, Cluster 설정에서 Fencing 정책을 수립할 수 있는 탭이 추가되었고, kdump도 설정하여 하이퍼바이저 장애시 vmcore를 수집하여 장애 원인 식별에 도움을 줄 수 있도록 개선되었습니다.

4) Networking
– oVirt의 공식 이미지 배포 서비스인 glance.ovirt.org를 통해 Nautron Virtual Appliance(CentOS + OpenStack IceHouse 기반)를 배포하게 되었습니다. Neutron Appliance에 대해서는 차후에 자세히 다루겠습니다. (http://www.ovirt.org/Features/NeutronVirtualAppliance)

5) SLA
OptaPlanner 도입으로 Cluster 단위에서 rules을 기반으로 VM들이 주어진 Host와 리소스들을 모두 고려해 최적화된 조건으로 실행될 수 있도록 개선되었습니다. 최적화를 계산하여 결과를 보여주고, 그에 따라 VM들이 마이그레이션(re-balancing)될 수 있도록 하는 기능을 제공합니다.

6) Storage
– 이전에 설명드렸던 SPM 제거를 위한 작업이 계속해서 진행되고 있습니다. 3.6에서 꼭 이루어졌으면 좋겠습니다.
– 그동안 Import Domain/Export Domain을 통해서만 VM 이미지를 DataCenter간 이동할 수 있었는데요, 큰 VM이나 대량의 VM을 Export/Import 할 경우에는 매우 오랜작업 시간(그에 따른 Downtime)이 소요되는 문제점이 있었습니다. 3.5에는 Data Domain을 바로 Import시킬 수 있도록 개선되어 관리 효율성이 매우 개선되었습니다. 사용자가 가장 가려워했던 부분인데 oVirt 커뮤니티에서 잘 찾아주었네요.
– 그동안 VM에 대해 여러 Snapshot찍었을 때, 중간에 불필요한 Snapshot을 삭제하려면 VM을 Down시킨 후에 작업을 해야 했는데요, 3.5부터는 Live merge를 지원하여 VM이 실행중인 상태에서 Snapshot 삭제시 그 앞뒤 상태를 Merge해주는 기능이 추가되었습니다.

6) Virtualization
– oVirt등 가상화 플랫폼에서는 OpenStack과 같은 클라우드 플랫폼과 달리 별도의 Instance Type(OpenStack에서는 Flavor)을 지원하지 않았었는데요, 3.5부터는 사전에 정의된 VM의 HW Profile을 지원하게 되었습니다. oVirt를 클라우드 환경의 기반 플랫폼으로 사용하거나 대량의 표준화된 VM들을 관리하는 환경에서는 Instance Type을 사전에 정의하여 손쉽게 표준화된 VM을 생성할 수 있게 되었습니다. 개인적으로 상당히 마음에 드는 기능입니다.
– 드디어 Live migration시에 Progress 상태를 볼수 있게 되었습니다. 이제나 저제나 언제쯤 끝날지 몰랐던 Live migration의 상태를 시작적으로 볼 수 있어 운영 편의성이 개선되었습니다.

가까운 미래에는요?

– oVirt 사용자의 소원인 SPM이 사라집니다.
– CEPH 스토리지 지원이 예상됩니다.
– Host 시스템 장치들에 대한 Passthrough와 SR-IOV가 지원됩니다. NFV 서비스의 플랫폼으로 oVirt를 고려하시는 분들께는 희소식이 아닐수 없습니다.
– 그동안 별도로 동작하던 GUI들도 모두 REST API를 사용하도록 변경됩니다. 이렇게 되면 GUI와 CLI간의 일관성이 개선되고, API가 좀 더 풍부해질 것으로 예상할 수 있습니다.
– 그 밖에도 많습니다. 여러분들께서 직접 의견을 주셔서 더 나은 oVirt 플랫폼으로 거듭나는데 기여하실 수도 있습니다.

oVirt 3.6에서 SPM 역할이 사라질 예정입니다.

그동안 oVirt/RHEV의 Storage Pool 컨셉(Master Storage Domain)과 Storage Pool Manager(SPM) 때문에 괴로우셨나요?

oVirt/RHEV에서는 수 많은 하이퍼바이저와 공유 스토리지를 운영하기 위해서는 스토리지 정보를 중앙에서 통제할 방법이 필요했고, 이를 SPM의 역할을 맡은 하나의 하이퍼바이저가 해왔는데요, 단일 노드가 역할을 수행함에 따라 부하 문제, SPM 노드의 장애에 따른 예상치 못한 문제들이 있었습니다. 그에 더해 oVirt/RHEV의 Scaling에 병목으로 작용하기도 했지요.

물론 3.2 이후로는 불편함이 많이 줄어들었지만, 대신 Scale out 관점에서의 극복해야할 대상이 된 것도 사실입니다. 그러던 것이… 적어도 oVirt 3.6 버전에서는 사라질 것으로 예상됩니다. (RHEV의 경우는 3.6 버전이 될지 확실하지 않습니다)

아래 링크를 건 관련 문서에서 조차 다음과 같이 이들의 제거에 따른 긍정적인 효과에 대해 언급하고 있습니다.
“As a consequence the Master Domain and its special content will disappear as well (pool metadata, asynchronous tasks persistency and ovf backups) simplifing the implementation and getting rid of several known problems.”

스토리지 작업에 필요한 locking은 Sanlock 서비스를 통해 획득하여 데이터의 corruption을 방지하고, 그동안 Storage domain중 Master로 지정된 Storage의 일정공간에 저장하던 Storage Pool metadata를 oVirt-engine/RHEV Manager의 DB에 저장하도록 변경될 예정입니다. 이러한 준비 작업은 3.5 버전부터 시작되어 3.6에서 완성될 것으로 생각되고요.

이렇게 계속 좋아져도 되나 싶네요.

http://www.ovirt.org/Features/Decommission_Master_Domain_and_SPM

oVirt/RHEV 3.4의 새로운 기능 #6. OpenStack Neutron Integration

oVirt/RHEV 3.4 New Feature #6. OpenStack Neutron Integration

올해 초 모임에서 oVirt의 경우 OpenStack과의 통합이 계속해서 진행되고 있다고 말씀드렸었는데요, 드디어 RHEV 3.4에서 OpenStack의 Neutron과의 통합이 공식 지원됩니다.

Neutron, Glance 서비스가 External Provider로써 RHEV 3.4(oVirt 3.4)에 통합될 수 있으며, Neutron의 경우 OpenStack Keystone, Neutron 서비스만 존재한다면 RHEV와 손쉽게 통합될 수 있습니다. Neutron에서 생성된 Network 구성을 RHEV에도 적용할 수 있습니다.

이러한 통합이 왜 중요한가 하면, OpenStack을 도입하였거나 Neutron를 통해 SDN을 구현하려는 조직이라도, 대체로 전통적인 가상화 환경도 운영해야 하는 경우가 많은데, 이 때 이들을 통합 관리할 수 있기 때문입니다.

External Provider로서 붙는 것까지는 테스트해 보았는데, 아직 실제 네트워크 구성에 적용해보지는 않았는데요, 추후에 기회가 되면 실전 활용팁을 통해 자세한 방법을 안내해드리겠습니다.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4/html/Administration_Guide/Adding_an_OpenStack_Network_Service_Neutron_for_Network_Provisioning.html

oVirt 기초 시리즈 #10, 지원 네트워크 설정

oVirt Beginner Series #10, Network Configuration

1. 기본 레이아웃
– 단일 NIC(eth0), 단일 Bridge(rhevm)를 통한 가상머신 vNIC 할당


2. Bonding 레이아웃
– eth0, eth1 등 하나 이상의 NIC를 Bonding device(bond0)로 묶고, 이를 다시 Bridge(rhevm, br0 등)로 나누어 vNIC 할당


3. VLAN을 사용한 기본 레이아웃
– 단일 NIC(eth0)에서 하나 이상의 VLAN 인터페이스을 생성(eth0.1, eth0.2,… eth0.n)한 후 각 VLAN 인터페이스에 Bridge를 생성하여 vNIC 할당


4. VLAN+Bonding을 사용한 레이아웃
– 하나 이상의 NIC를 bonding으로 묶은 후, VLAN 인터페이스로 나눈 후(bond0.1, bond0.2….) 각 VLAN 인터페이스에 Bridge를 생성하여 vNIC 할당


더 복잡해 보이는 네트워크 구성도 있으나, 사실 대부분 인터페이스 수가 늘어날 뿐 기본적으로 위의 구성에 기초한다고 볼 수 있습니다.
PCI Pass-through를 사용하지 않은 한 가상머신에 vNIC를 할당하기 위해서는 논리적인 L2 Switch 역할을 하는 Bridge 생성은 필수입니다.

Image Source : Red Hat Enterprise Virtualization 3.4 Technical Guide

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

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

Design a site like this with WordPress.com
Get started