공부공부 공부공부내용
Ovirt 개요 (블로그 펌) 본문
출처 : ovirtkorea.wordpress.com/2014/07/29/66/
#0 ovirt meet up 자료
http://www.slideshare.net/rogan/20140208-ovirtkorea-01
-Nested KVM 환경에서 oVirt 설치 방법
http://www.slideshare.net/rogan/20140208-ovirtkorea-04ovirtonnestedkvm
oVirt 기초 시리즈 #1 아키텍처
oVirt는 oVirt-Engine(JBoss 미들웨어 기반의 Java 웹서비스)이라는 Administrator/User Portal 웹기반 서비스와 oVirt-Node(Customized Fedora+KVM+libvirt+VDSM로 구성)라는 하이퍼바이저 전용 이미지로 구성되어 있습니다.
oVirt-Engine은 PostgreSQL DB에 필요한 정보를 저장하고 대부분의 통신은 XML-PRC 기반으로 이루어집니다. oVirt-Node의 경우에는 Read-Only로 부팅하여 Stateless 하이퍼바이저 역할만 수행하므로 필요시 손쉽게 추가하거나 삭제하실 수 있습니다.
oVirt 기초 시리즈 #2 SPICE
oVirt/RHEV 환경에서 VM console에 접속하려면 VNC 또는 SPICE client 프로그램을 사용해야 합니다. VNC의 경우 워낙 잘 알려진 원격 Console 접속 방식이지만 SPICE의 경우는 조금 생소할 수 있습니다. VNC의 경우 (Advanced 기능을 가진 솔루션도 있으나) 일반적으로 단순히 화면 및 키보드/마우스 전송이 국한되기 때문에 VDI(Virtual Desktop Infrastructure) 구성을 위해서는 다소 부족할 수 있습니다. 때문에 KVM, oVirt/RHEV를 개발했던 Qumranet(현재는 Red Hat에 인수)이 KVM등과 같이 개발한 VDI용 프로토콜 및 프로그램입니다. 따라서 KVM+Qemu 조합에 보다 최적화되어 있습니다.
현재는 오픈소스화 되어 있으며 SPICE를 사용할 경우, Server <-> Client 간에 USB 및 사운드까지 전달가능하며, 다중 모니터 기능까지 지원하고 있어, 기업에서 가상화/클라우드 기반의 VDI 환경을 구축하고자 할 때 오픈소스로서 선택할 수 있는 가장 적합한 대안입니다.
당연히 oVirt/RHEV 환경의 기본 Console 방식이며, OpenStack에서도 많이 사용되고 있습니다. oVirt/RHEV에서는 윈도우즈 및 리눅스용 virt-viewer client를 사용할 수 있으며, Firefox 브라우저용 플러그인 spice-xpi를 사용하면 oVirt Admin Portal에서 바로 접속할 수 있습니다. 추가적으로 Android용 클라이언트도 개발되어 있어 Android 태블릿에서 VDI 구성도 가능합니다.
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
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 기초 시리즈 #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 서버 가상화에서 OpenStack 클라우드로
http://www.slideshare.net/rogan/20140218-openstack-dayroganovirtandopenstackv4kr
oVirt 기초 시리즈 #6 oVirt/RHEV Guest Agent
oVirt Beginner Series #6 oVirt/RHEV Guest Agent
Guest Agent라는 툴은 oVirt/RHEV 환경에서 VM내에 설치되어 VM의 사용과 관리 경험을 개선시킵니다.
좀 더 구체적으로 ovirt-guest-agent, rhevm-guest-agent 패키지들이 VM내에 설치되면, oVirt-Engine에서 VM을 Shutdown/Reboot 시킬 수 있으며, RHEL 6 VM이라면 tuned 서비스를 자동으로 실행하여 VM환경에 최적화되도록 자동 튜닝됩니다. SPICE에서 Multiple 모니터를 지원할 수 있게 되고, SPICE client에서 마우스 in/out이 자유로워지고 Client 내부/외부와 클립보드 사용도 가능해 집니다.
그럼 설치 방법을 간단히 살펴볼까요?
1) oVirt 3.3 환경하에서 Agent 설치하는 방법
– 자세한 설치 방법 : http://www.ovirt.org/How_to_install_the_guest_agent_in_Fedora
– RHEL 6.5, CentOS 6.5 용 패키지 다운로드
# wget http://resources.ovirt.org/releases/3.3/rpm/EL/6.5/noarch/ovirt-guest-agent-1.0.8-1.el6.noarch.rpm
– Fedora 19 용 패키지 다운로드
# wget http://resources.ovirt.org/releases/3.3/rpm/Fedora/19/noarch/ovirt-guest-agent-common-1.0.8-2.fc19.noarch.rpm
– 다운로드 받은 패키지를 VM에 복사 후 설치
# scp ovirt-guest-agent*.rpm root@VM_IP:~/
– RHEL 6.5, CentOS 6.5 VM내에서 설치
# yum localinstall /root/ovirt-guest-agent-1.0.8-1.el6.noarch.rpm
# chkconfig ovirt-guest-agent on
# service ovirt-guest-agent start
– Fedora 19 VM에서 설치
# yum localinstall /root/ovirt-guest-agent-common-1.0.8-2.fc19.noarch.rpm
# systemctl enable ovirt-guest-agent.service
# systemctl start ovirt-guest-agent.service
2) RHEV 3.3 환경하에서 Agent 설치하는 방법
– 자세한 설치 방법 : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Power_User_Portal_Guide/chap-Monitoring_Virtual_Resources.html
– RHEL5/6용 패키지 설치 (RHEV의 경우 Red Hat Network에 적절한 채널에 등록되어 있어야 함)
# yum install rhevm-guest-agent -y
– Windows VM용 패키지 설치
rhev-guest-tools ISO 이미지를 다운로드 받아 VM의 CD에 연결
RHEV-toolsSetup 프로그램을 실행하여 설치 후 재부팅
oVirt 기초 시리즈 #7 oVirt의 논리적인 아키텍처
- 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 기초 시리즈 #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 기초 시리즈 #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/RHEV 사용 및 운영에서 가장 골치아픈 부분이 스토리지 관련 부분입니다. 스토리지쪽은 다수의 하이퍼바이저가 공유하고 동시에 사용하기 때문에 장애나 문제 발생 시 그 영향도가 단일 시스템을 넘어서기 때문입니다. 더욱이 한번 구축을 해 놓은 이후부터는 쉽게 변경하기 어려운 측면도 있습니다.
따라서 가능하면 아키텍처를 그리는 단계에서부터 신중하게 종류(NFS, iSCSI, FCP, GlusterFS)를 선택하고, 용량을 산정하고, 구축해야 향후 발생할지 모를 재앙(?)으로부터 가상 데이터센터를 보호할 수 있습니다.
* 새로운 희망
다행스러운 점은 oVirt/RHEV 3.4부터는 여러 종류의 스토리지를 함께 사용할 수 있어서 유연성이 증가했다는 부분이고, 더불어 관리 비용도 감소될 수 있겠네요. 게다가 3.2부터 GlusterFS가 추가되면서 파일기반의 VM Image 변환이 되어 iSCSI/FCP를 사용했을 때 Block device를 묶기 위해 사용된 LVM의 한계도 피할 수 있게 되었습니다. (물론 LVM의 장점도 무척 많지만 말입니다)
* 스토리지 유형 선택 팁
당연히 성능이 중요하고, 규모가 상대적으로 적으며(Manager당 수십대의 하이퍼바이저 수준), 부하가 예측되며 아키텍처 변화가 적은 환경에서는 iSCSI/FCP가 선호될 것입니다. 만약 규모가 크고(Manager당 백대 이상의 하이퍼바이저 수준), 부하가 예상되지 않는 경우라면 GlusterFS를 기본으로 하고 경우에 따라 다른 스토리지 유형도 섞어서 쓰는 전략이 필요할 것 입니다.
* iSCSI/FCP 구축 팁
마지막으로 iSCSI/FCP에 기반한다면, 다른 인프라와 공유하지 않는 oVirt/RHEV 전용의 스토리지를 사용하는게 혹시 있을지 모를 스토리지 단의 Human fault의 피해를 줄일 수 있으며(스토리지 엔니지어의 실수로 막대한 결과를 초래한 사례가 있었습니다.), oVirt/RHEV의 스토리지 도메인당 여러 LUN을 묶기보다는 큰 LUN으로 구성하는게 좋습니다. 더불어 업무 등급별 스토리지 도메인를 나누어서, 하나의 스토리지 도메인에 Fault가 발생하더라도 피해 규모를 줄이는게 도움이 됩니다.
실전 활용팁, 사이징
객관적인 근거없이 믿도 끝도 없이 개인의 감(?)으로 산정된 oVirt/RHEV 사이징을 공개합니다.
oVirt/RHEV 환경에서 소수의 하이퍼바이저와 가상머신을 가진 경우라면, 요즘 성능 좋은 단독 서버에 ovirt-engine(RHEV Manager)를 설치해 쓰는게 컴퓨팅 자원 낭비라고 생각될 수도 있습니다. 여기서 소수라고 함은 수대~수십대의 하이퍼바이저와 1백개 미만의 가상머신정도로 해두죠.
그러나, 계속해서 하이퍼바이저와 가상머신이 추가되는 환경이라면 ovirt-engine의 부하가 점차 증가함을 알 수 있습니다. 그도 그럴 것이 ovirt-engine은 주기적으로 모든 하이퍼바이저와 가상머신의 상태정보를 받아 기록하고 또 추적하기 때문입니다.
특히 Backend DB인 PostgreSQL 서버의 부하가 특히 병목이 될 수 있는데요, 추가적인 튜닝으로 일부 개선을 시킬 수 있으나, 이때부터 낭비라고 생각했던 하드웨어 스펙에 따라 전체적인 성능이 좌우됩니다.
수일에서 수주에 걸친 업무 및 부하 분석이 동반되는 Sizing과는 전혀 관계없이, 감에 의존한 사이징 정보는 다음과 같습니다. (자세한 내용은 전문가와의 상담을 권장합니다.) 참고로 oVirt/RHEV 3.3부터는 처리 성능이 대폭 개선되었습니다만 다음 정보는 3.2 기준입니다.
* 단일 ovirt-engine(RHEV Manager)당 최대 Sizing
- 150 호스트 + 1200대 가상머신 (small VM) –> cloud-like workload
- 150 호스트 + 600대 가상머신 (medium VM)
- 150 호스트 + 400대 가상머신 (large VM) –> Traditional workload
따라서 10,000대 작은 규모의 가상머신을 운영하는 규모라면 9개정도의 ovirt-engine(RHEV Manager) 환경을 구축해볼 수 있습니다. 이들을 API와 적절한 네트워크 설계를 통해 연동 하는 것도 가능하지요. 다만 oVirt의 경우 OpenStack과 달리 애초에 Scale out에 초점을 맞춘 아키텍처는 아닙니다. 따라서 Cloud-like workload나 Scale out이 중요한 환경에 최적의 플랫폼은 아니라는 점은 반드시 고려되어야 하겠습니다.
* 조건에 따른 적절한 선택
- 기존 물리 서버의 가상화 또는 중소규모의 클라우드라면 oVirt
- 클라우드 서비스 또는 대규모 클라이드 환경을 목표로 한다면 OpenStack
- 하드웨어 종속적 기능이 요구되거나 성능이 중시되는 환경이라면 가상화보다는 Docker와 같은 Contaner
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의 운영체제에서도 지원해야하고 사전 조치가 필요하는 등 아직은 다소 미흡한만큼 좀 더 지켜볼 일입니다.
실전 활용팁, 업무별 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를 선택하는 것이 좋습니다.
실전 활용팁, 라이브 마이그레이션 준비
Best Practice, live-migration prerequisites
oVirt/RHEV의 강점 중 하나가 online 상에서 가상머신을 서로 다른 ovirt-node(하이퍼바이저, 호스트)로 라이브 마이그레이션이 가능하다는 점 입니다. 서비스의 지속성 관점에서 매우 중요한 기능인데요, 실시간으로 서비스 중단 없이 호스트간에 이동이 가능한만큼 몇가지 조건을 만족시켜줘야 합니다.
* 용어 안내
- Source 호스트 : 라이브 마이그레이션 대상 가상머신이 실행중인 호스트
- Destination 호스트 : 실행중인 가상머신이 옮겨갈 대상 호스트
* 라이브 마이그레이션을 위한 조건
- Source, Destination 호스트가 모두 동일한 oVirt Cluster 소속, 동일한 CPU 호환성을 가져야 함 (Intel/AMD 벤더 및 CPU microarchitecture – Nehalem, SandyBridge 등)
- Source, Destination 호스트가 모두 Up 상태
- Source, Destination 호스트의 oVirt/RHEV Management Network 또는 Migration Network(3.3 이후)를 통해 접근 가능
- 대상 가상머신이 사용하는 oVirt/RHEV 스토리지 도메인에 Source, Destination 호스트가 모두 접근 가능
- Destination 호스트에 대상 가상머신 실행에 필요한 충분한 여유 메모리
- Source, Destination 호스트간 DNS 또는 /etc/hosts에 host명 resolve 필요
- 대상 가상머신에 ISO 이미지가 mount되어 있거나 attach 되면 안됨
- 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 커널 옵션 추가
주변기술 시리즈 #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에서 확인하게 됩니다
'클라우드 구성 및 관리 > 가상화 인프라 관리 [ovirt]' 카테고리의 다른 글
| Ovirt실습 1 이어서 ( iso storage 추가) (0) | 2020.06.24 |
|---|---|
| 가상화 개념정리*(퍼옴) (0) | 2020.06.24 |
| 가상화 개요 (강사님) (0) | 2020.06.22 |
| Ovirt 구성 실습1 (0) | 2020.06.22 |
| 가상화 개요 및 관련 용어들 (0) | 2020.06.22 |
