Category Archives: oVirt/RHEV 시작하기

oVirt/RHEV 사용을 위한 기본적인 지식를 공유하는 곳입니다.

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

Advertisements

oVirt 기초 시리즈 #9 qcow2 and allocation policies

oVirt Beginner Series #9 qcow2 and allocation policies

* 가상머신 디스크 이미지 포맷

oVirt를 비롯한 KVM 가상화에서는 가상머신의 디스크 이미지를 위한 파일 포맷으로 qcow2와 raw 방식을 사용하고 있습니다.
qcow2 파일 포맷의 장점은 1) 디스크 공간을 실제 사용할때 할당할 수 있으며, 2) Copy on Write를 지원하기 때문에 Read-only base 이미지를 사용하다가 변경이 발생할 때 분리된 qcow2 파일에 변경된 부분만 저장할 수 있다는 점입니다.
즉, Thin-provision 기능과 Snapshot 기능을 파일 포맷차원에서 제공할 수 있는 것이죠. oVirt나 virt-manager등 QEMU+KVM 가상화 도구들은 이러한 파일 포맷 특징을 적극 활용하여 Thin-provision과 Snapshot 기능들을 제공하고 있습니다. 참고로 qcow2를 사용한다고 해서 꼭 Thin-provision 방식만 사용해야 하는 것은 아니고 Pre-allocation에서도 사용할 수 있습니다.
http://en.wikipedia.org/wiki/Qcow

qcow2, raw 이미지는 qemu-img 명령어를 이용하여 직접 생성하거나 조작 가능합니다.

# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
# qemu-img info filename

* oVirt에서의 활용

그렇다면 oVirt에서 qcow2와 raw 포맷을 어떻게 사용하는지 살펴보겠습니다. oVirt에서는 가상머신 디스크 이미지를 Allocation policy에 따라 2가지로 구분해서 표현하는데, 할당된 전체 이미지 크기는 Virtual Size로서 표현하고, 실제 사용중인 크기는 Actual Size라고 표현하고 있습니다. 예를 들면 다음과 같습니다.

Alloc Policy, Virtual Size (qcow2), Actual Size (LV)
————————————————–
Thin-provision , 10 GiB , 1 GiB
————————————————–
Pre-allocation , 10 GiB , 10 GiB
————————————————–

* 성능측면의 고려사항

초기에는 Allocation policy와 무관하게 qcow2 방식이 raw 방식보다 느린측면이 있었지만, 지금은 qcow2와 raw 방식이 동일한 조건에서는 매우 비슷한 성능을 내기 때문에 포맷에 대한 고민보다는 Allocation policy를 고민하는게 맞습니다.
http://fedoraproject.org/wiki/Features/KVM_qcow2_Performance

Thin-provision의 경우 얼만큼 사용할지 모를 때 미리 적당한 공간을 할당해놓고 사용한만큼 크기를 키울 수 있어 스토리지 자원을 효율적으로 사용할 수 있는 장점이 있습니다. 더불어 디스크 생성시간이 무척 짧아서 Cloud workloads에 대응하기 위한 신속한 Scale-out 이 요구되는 환경에서는 이상적인 할당 방식이라고 볼 수 있습니다. 그러나 운영중에 allocation을 수행하기 때문에 그 시간만큼의 overhead가 발생할 수 있어 I/O 중심의 workload에서는 Pre-allocation 방식을 사용해야 합니다. 개인적으로는 oVirt라면 Pre-allocation을 OpenStack이라면 Thin-provision이 적합하다고 생각합니다.

qcow 이미지 포맷에 대한 보다 자세한 정보는 OpenStack 프로젝트에서도 이름을 날리고 있는 Mark McLoughlim의 다음 문서를 참조하시기 바랍니다.
https://people.gnome.org/~markmc/qcow-image-format.html

oVirt 기초 시리즈 #8 Full Virtualization, Para Virtualization and VirtIO

oVirt Basic Series #8 : Full Virtualization, Para Virtualization and VirtIO

영문이 보다 의미를 명확하게 전달하는 측면이 있으나 한글로는 전가상화(Full Virtualization), 반가상화(Para Virtualization)라고도 불리우는 가상화 방법입니다. Full-Virt에서는 Guest 운영체제가 자신이 가상화 플랫폼 위에서 실행중인지 아니면 Bare metal 하드웨어에서 실행되는지 구분하지 못하는, 말 그대로 완전한 가상화 상태를 의미하며, Para-Virt의 경우에는 Guest 운영체제가 자신이 가상화 플랫폼 위에서 실행되고 있다는 것을 인지하고 있는 상태가 됩니다. 따라서 Para-Virt 플랫폼에서는 Guest 운영체제가 인지할 수 있도록 하는 수정 이 필요하다는 어려움이 있으나 Guest 운영체제와 하이퍼바이저와의 협력을 통해 성능을 월등히 개선시킬 수 있는 장점이 있습니다. 사실 가상화가 대중화되고 대부분의 운영체제가 지원하는 근래에 들어서는 Guest 운영체제의 수정이 큰 문제가 되지는 않습니다.

oVirt의 경우 KVM의 가상화 기술과 QEMU 하드웨어 에뮬레이션을 사용한 Full-Virt 플랫폼으로 다양한 Guest 운영체제를 수정없이 사용할 수 있습니다. 그러나 높은 성능이 요구되는 Block 장치, Network 장치등은 성능개선을 위해 KVM의 VirtIO라 불리는 Framework를 지원하고 있으며, VirtIO용 Para-virtualized driver를 지원하는 Guest 운영체제의 경우 장치 드라이버 수준에서 반가상화 기술을 사용하게 됩니다.

Red Hat Enterprise Linux, CentOS는 4.8 버전부터, 5.3 버전부터, 6.0 버전은 모두, Fedora의 경우 12 버전이후 모든 버전에서 virtio 드라이버를 지원하고 있기 때문에 oVirt에서 실행할 경우 바로 Para-Virt의 개선된 성능을 이용할 수 있습니다. 추가적으로 Red Hat Enterprise Virtualization(oVirt의 기업용 버전)의 경우 마이크로소프트로부터 호환 인증을 받은 Windows용 virtio 드라이버도 지원하고 있습니다. 물론 oVirt에서도 윈도우용 virtio 드라이버 사용 가능합니다.

VirtIO에 대한 보다 깊은 내용은 별도의 Deep Dive 시리즈와 세미나 기회에 자세히 설명해드릴 예정입니다.

http://www.ibm.com/developerworks/library/l-virtio/

oVirt 기초 시리즈 #7 oVirt의 논리적인 아키텍처

oVirt Basic Series #7 : oVirt’s logical architecture

  • Datacenter : oVirt의 가상 최상위 요소, 하나 이상의 Cluster로 구성, 하나의 Storage Pool과 논리적 네트워크의 관리 단위
  • Cluster : 동일한 하드웨어(CPU)와 네트워크를 가진 하나 이상의 Host로 구성, 가상머신의 라이브 마이그레이션 단위
  • Storage Pool : Datacenter내의 모든 Cluster와 Hypervisor가 공유하는 스토리지 리소스 풀, 최소 하나의 Data Storage Domain으로 구성.하나의 Datacenter에는 한가지 유형(FCP, iSCSI, GlusterFS, PosixFS, NFS, Local)만 사용 (단, ISO/Export Storage Domain은 제외)
  • Storage Domain : 가상머신의 디스크 이미지가 저장되는 Data Storage Domain과 ISO 이미지가 포함된 ISO Domain (NFS only), 가상머신의 백업/이동을 위한 Export Domain (NFS only, optional)으로 구분
  • SPM (Storage Pool Manager) : Storage Pool의 관리 업무를 수행하는 Host, Datacenter당 한대. 자동으로 선택되나 우선순위 지정 가능
  • Host : 가상머신이 실행되는 KVM Hypervisor

* oVirt 설치 후 구축 순서

1) DataCenter 설정

  • 최초 설치시 기본 ‘Default’ Datacenter 생성되어 있으며, 이를 수정하거나 신규로 추가
  • Network 설정에서 ovirt management network는 기본 설정되어 있으며, 필요에 따라 Service, Display, Migratoin, Storage Network 등 추가 가능
  •  Storage 설정에서는 사용할 Storage Pool 유형 설정

2) Cluster 설정

  • 최초 설치시 기본 ‘Default’ Cluster가 생성되어 있으며, 이를 수정하거나 신규로 추가
  • Cluster에서는 CPU Type을 설정할 수 있으며, Nehalem, SandyBridge 등 Host가 공통으로 지원하는 CPU 유형 선택

3) Host 등록

  • oVirt-node-vdsm ISO를 사용해 등록할 경우 Host에서 oVirt-Engine IP를 입력해주면 자동으로 등록 됨
  • Fedora/RHEL 기반의 Host인 경우 oVirt-Engine의 Host Tab에서 ‘Add’로 Host의 IP를 넣어 직접 추가
  • 등록 완료 후 Host가 소속될 Cluster 설정
  • Datacenter에서 정의했던 논리적 Network를 Host의 NIC(Bonding, VLAN등 설정)에 할당

4) Storage 등록

  • 등록된 Host를 통해 스토리지에 연결하여 Data Storage Domain 추가
  • Data Storage Domain 추가 후 ISO Storage Domain 추가

5) 가상 머신 설치

이제 즐깁니다. 가상화 세계에 오신 것을 환영합니다.

oVirt 기초 시리즈 #5 하드웨어적 조건

oVirt 기초 시리즈 #5 하드웨어적 조건

 

2월 8일에 발표할 내용중에 포함되어 있으나 여기 먼저 살짝 풀어놓습니다.

oVirt가 KVM 기반의 가상화 플랫폼이라는 것은 이제 모르는분은 없을텐데요, oVirt 구축을 위한 하드웨어적인 조건 역시 KVM을 사용하기 위한 조건이라고 생각하시면 되겠습니다. 기초시리즈니까 쉬어가는 차원에서 정리해 봅니다.

최근엔 KVM이 x86_64 아키텍처뿐만 아니라 PPC, ARM도 지원하고 있지만, 기본적으로 x86_64 환경이라면 Intel VT-x 또는 AMD AMD-V를 지원하는 CPU를 사용해야 합니다. 최신 CPU라면 대부분 지원하고 서버용이라면 100% 지원한다고 보면 되지만, 간혹 노트북이나 데스크톱 저가 모델의 경우 지원되지 않는 경우도 있으니 확인이 필요합니다.

# grep –color=tty -E ‘svm|vmx’ /proc/cpuinfo

여기에 추가적으로 oVirt의 경우 보안성 강화를 위해 No Execute 기능(NX)을 지원하는 CPU여야 합니다. 이 역시 비교적 최신 CPU라면 지원된다고 보시면 되겠습니다.

# grep –color=tty nx /proc/cpuinfo

자, 그럼 다음으로 oVirt-Engine을 실행할 시스템과 oVirt-Node를 실행할 시스템들을 준비하면 됩니다. oVirt-Node는 1대 이상이면 구성 가능하나 oVirt 기능의 백미라 할 수 있는 Live-migration이나 scheduling등을 테스트해보시려면 최소 2대 이상을 준비하시는 것을 권장합니다. 참고로 oVirt는 하나의 Datacenter당 최대 200개의 oVirt-Node를 지원합니다.

oVirt을 위한 스토리지는 FCP/iSCSI/NFS/GlusterFS를 사용하실 수 있는데, 조건에 맞게 구축하시면 되겠습니다. NFS의 경우 운영 편리성은 높은 편이나 성능이나 안정성은 떨어질 수 있으니 Enterprise에서 사용하신다면 FCP/iSCSI를 권장합니다. GlusterFS의 경우는 최근에 포함된만큼 시간을 두고 보되, 대규모 구축시에 비용효율적인 선택이 될 것 입니다.

그 밖에 Network은 서비스 수요에 맞게 준비하시면 되고, oVirt Management Network는 1 GbE를 권해 드립니다. Migration Network는 가능하면 독립시켜 별도로 유지하고 최소 1 GbE, 가능하면 Bonding mode 4를 통해 2 GbE 이상으로 구축하는 것이 좋습니다.

oVirt 기초 시리즈 #4 libvirt, VDSM

oVirt 기초 시리즈 #4 libvirt, VDSM

oVirt가 KVM+Qemu 가상화에 기반한다는 것은 이미 아시리라 생각됩니다. KVM+Qemu가 가상화 구현에 필요한 기본 요소라면 oVirt-Engine과 oVirt-Node간에 통신을 처리하고 명령을 받아 VM들을 제어하는 역할을 수행하는 Agent가 필요할텐데요, VDSM(Virtual Desktop and Server Manager)가 바로 그 Agent로 oVirt-Node에서 서비스로서 실행됩니다.

사실 KVM 가상화를 관리하는 도구에는 oVirt의 VDSM 뿐만 아니라 GUI기반의 virt-manager, CLI기반의 virsh, 그리고 웹 기반의 KIMCHI, OpenStack 등이 있습니다. 아직까지 모든 도구들이 직접 KVM+Qemu를 통제하지는 않고 사실상 libvirt라는 라이브러리를 통해 제어를 하고 있습니다.

libvirt의 경우에는 VM들을 관리하는 표준적인 API를 제공하여 KVM, Xen, VMware ESX, VirtualBox 등 하위 하이퍼바이저로부터 독립된 상위 응용프로그램을 구현할 수 있도록 도와주는 라이브러리이자 서비스입니다. libvirt 내부적으로는 하이퍼바이저별 driver를 통해 실제로 통제 작업을 수행하게 되며, 이 때문에 libvirt를 사용하는 도구들은 이론적으로 하이퍼바이저의 종류에 구분없이 동작할 수 있습니다.

그러나 libvirt 자체도 계속해서 기능이 추가되고 발전하고 있으며, VDSM등과 같이 각 프로젝트의 Agent도 비슷한 방향으로 발전하면서 상호 프로젝트간에 중복 작업이 일어나거나 호환성을 유지에 어려움이 많아지고 있습니다. libvirt가 현실적으로 하이퍼바이저를 통제하기 위한 가장 손쉬운 방법이긴 하나, 그 장점에 따른 한계도 있고 VDSM과 같이 단일 하이퍼바이저 방식만을 지원하는 경우에는 하나의 Layer가 추가되는 형태라서 커뮤니티내에서는 변화가 필요하다는 목소리가 나오고 있는데요, 어떤식으로든 변화가 예상됩니다.

가상화, 클라우드 컴퓨팅에서 오픈소스 프로젝트를 빼놓고는 설명하기 힘들겠죠? 참고로 libvirt 프로젝트의 경우 Red Hat Emerging Technologies의 하나로서 지원받고 있습니다.

http://libvirt.org/
http://www.ovirt.org/Category:Vdsm

oVirt 기초 시리즈 #3 RHEV란?

oVirt 기초 시리즈 #3 RHEV란?

앞서 기초 시리즈 #1 에서 oVirt가 관리 플랫폼인 oVirt-Engine과 KVM 기반 하이퍼바이저 oVirt-node로 구성되어 있다고 소개해드린바 있는데요, RHEV는 oVirt를 보다 안정화 시키고 버전간 호환성, Red Hat Enterprise Linux의 인증등을 상속받도록 노력하는 등 기업용으로 개발한 버전으로 보시면 됩니다.

oVirt가 앞만보고 마구 달려가는 Fedora와 같은 존재라면 RHEV는 기업용으로 인정받는 RHEL과 같은 존재입니다. 사실 RHEV에 대해 자세히 소개하려는 것은 아니고, 기초 시리즈라서 백문이 불여일견! oVirt-Engine을 비주얼하게 보여주는 간략하면서 쓸만한 동영상을 찾다 못 찾아서 RHEV-M으로 대신하려다 보니 설명하게 되었네요.

다음의 동영상을 보시면 짧게 RHEV-M, oVirt-Engine의 모습을 예상하실 수 있습니다.

http://www.youtube.com/watch?v=PKXcJWI62qY