오랜만에 또 테크니컬 노트를 올린다.


일단, 이 글의 아이디어는 N 모 게임회사를 다니는 System Engineer 박모 씨의


질문으로 인해 떠올라 작성된 글이다.


배경 :

Ubuntu 10.04 를 개발팀에서 요구하였으나, IBM X3XXX M4 장비의 LSI 드라이버를

인식하지 못해 Bare-metal 한 설치가 불가능 한 상황.


하지만 나의 배경은 Oracle Linux 를 이용한다...


준비물 : OL6, 맥주(킬케니) 12캔, 파파이스 포테이토칩, 하인즈캐찹!


앞서 설명했던 오라클에서 제공하는 템플릿을 사용하면, 매우매우 편하게


yum repository 에서 명시된 릴리즈 버젼을 다운받아 설치를 진행 해 준다.


OL6 에서 OL5 의 이미지를 돌리고, 그것을 chroot 환경으로 제공하겠다는 것!

( 참고로 사용된 OL6 host 는 OVM 에 가상화로 돌아가는 가상머신이다 ㅋㅋ )



오랜만에 포스팅 끝..


담엔 간단히 Kpartx 를 함께 이용해 이미 존재하는 vDIsk 의 내용을 확인하는 방법과,

LVM 복구를 하는 걸 간단히 작성 해 보도록 하겠음. 물론 지켜진적 한번도 없으나 ㅋ



2012/09/03 - [Skills/가상화(Hypervisors)] - 가상화 시스템에서 자원컨트롤에 대한 신요소! Linux Container - 1부


2012/09/09 - [Skills/가상화(Hypervisors)] - 가상화 시스템에서 자원컨트롤에 대한 신요소! Linux Container - 2부




posted by mirr

댓글을 달아 주세요

이번엔 오랜만에 그냥 순수 프로덕에 대한 이야기를 올려본다.


클라우드에 대한 얘기를 하다보면, VDI 에 대한 얘기도 나올텐데...


오라클에도 이 VDI 가 있다는 점..


사실 Oracle VDI 는 Oracle VM 과 완전 별개의 프로덕트로써, 오로지 VDI 에 대한

기능제공을 위해서만 존재하는 프로덕트라고 볼 수 있다!


좀 더 살펴보도록 하자.



사실 한국에선 Oracle VDI 가 망했다고 한다.. 하지만 VirtualBOX 를 많이 쓰며,


Desktop 가상화 솔루션들에 대한 서버 관리를 Linux 로 할 수 있다는 점,


또한 DB 를 MySQL 로 구성했다는 점등은(Inno DB 까지 사용 가능하다),


특히 MySQL, Linux Host 를 이용하므로 리눅스나 오픈소스등에 익숙한 사람들이라면,


입맛에 맞게 커스터마이징도 충분히 가능하다는 장점이 있지 않을까 싶다...


다음번엔 Desktop Pool 로 생성한 몇가지 VM 으로, Oracle iPAD client 에 대한


접속 등등을 보여주도록 하겠다.


이부분에서 눈치챈사람들도 있겠지만, 내가 노트북이 없고 iPAD 나 iPhone 으로만 일을 하기 때문에,


관심을 갖기 시작한 것이라는걸 부인 할 수 없다.. ㅡ.,ㅡ::


(사실 5시에 땡땡이 ..라기보단 이른 퇴근을 하고싶기때문에 글쓰다가 중단하는 중..)

















posted by mirr

댓글을 달아 주세요

이전글 :

2012/09/03 - [Skills/가상화(VMware,Xen)] - 가상화 시스템에서 자원컨트롤에 대한 신요소! Linux Container - 1부


지난번에 이어 2부이다. 미리 예고했듯이, 이 LXC 를 이용한 가상 머신을 구동하는 방법과,


네트워크 설정, 그리고 자원 컨트롤 방법에 대해서 간략하게나마 다뤄보도록 하겠다.



자.. 이렇게 두번에 걸쳐 간단하게 Linux Container 에 대해서 알아보았다.


VirtualBOXRHEV 의 이미지들또한 이걸 이용해 손쉽게 운영할 수 있으며,


이것을 이용하여 메인 Hypervisor 의 장애로 인해 긴급하게나마 VM 을 임시로라도


운영하기 위해서 사용할 수도 있을것이다.


DR 에 대한 간단한 긴급 복구 Policy 로도 사용이 가능한 부분이 있다는것을 명심해두자..


BtrFS 의 스냅샷 기능과 Rsync 등의 동기화 툴들을 이용하면 불과 5분여만에


동일한 가상머신이 쉽게 복제되어 구동되기 때문에, 활용도는 매우 높을것으로 보여진다.


다음에는 HugeTLB.. 즉 HugePage 의 사용법등에 대해서 한번 정리해 볼 계획이다.

오라클에서 많이 쓰이는 영역이기~ 때문에~ ㅋㅋ



posted by mirr

댓글을 달아 주세요

가상화 시스템에서 자원컨트롤에대한 신요소로 Linux Container 라는 녀석이 있다.


엄밀히 얘기하면 Full Virtualization 을 위한 메카니즘은 아니지만, 서버 가상화에대한


뚜렷한 효용성을 못느끼는 분들이나, 서버팜의 확실성에 대한 강한 신뢰를 내려놓지


못하는 불신으로 똘똘 뭉친 고리타풍(ㅋㅋ) 하신 분들은 한번쯤 보아둬도 좋을듯하다.



뚜구둥~ 쉽게 만들어 지었다..


템플릿은 입맛에 맞게 수정하면 되고, 간단하게 가상머신이 하나 생성되는 셈이니,


왜 이녀석을 사용하는게 좋은지 다들 알것이다.


구지 에뮬레이팅되는 가상머신을 설치하여 GUI 등을 이용해 구동할 필요 없이,


간단한 자원 할당을 통해서도 이렇게 가상머신의 역할을 수행 할 수 있다는 점,


그리고 실제로 가상화에 대한 개념 그리고 발전모습을 더 디테일하게 밟아 볼 수


있다는 점이 내가 LXC 를 보고 열광하며 글을 쓰게 된 이유임을 알린다..

( 사실은 CGroup 이나 BtrFS 등은 RedHat 에 찾아보니 이미 새로운 문서들이 있더라는 ㅠㅠ )


 - 예고편 2부

 2부에서는 실제 운용하고 모니터링하는 부분에 대해서 서술하겠다.


 Bridge 네트워크를 이용해서 외부와도 통신이 가능한 Container 를 만들고,

 VLAN 을 이용해 Segement 의 구분을 지은 통신을 하는 모습,


 컨테이너의 CPU 나 Network 등 리소스를 직접적으로 Controlling 하는 부분,

 그리고 몇가지 기타 유용한 LXC 커맨드들을 살펴보도록 하겠다..


빠이빠이~


posted by mirr

댓글을 달아 주세요

트위터로 IBM RedBooks 와 Developerworks 의 글들을 구독하고있는데,

이런 유용하고도 멋진 내용들이 번역되서 올라오기도 한다.
(물론 영문버젼이 더 많지만..)

이번엔 특히나 리눅스 관련 특히 KVM 의 자원 조절에 대한 기교들이 언급되서

하나 올려본다.

어차피 링크고, PDF 버젼도 가면 받을 수 있다 :)

http://www.ibm.com/developerworks/kr/library/l-overcommit-kvm-resources/index.html


posted by mirr

댓글을 달아 주세요

...Virt-Manager 에서 OSType 과 Distro 종류를 꼭 선택해야하는지, 왜 두었는지
 

다들 별로 안궁금해하는가보다... python-virtinst 의 모듈에서 적용받는(?) 기능으로, 
 

OS 설치를 위한 이미지 및 커널들을 찾기위한 목적!!!
 

어차피 distro 기본이 none 으로 append 되긴 하는데
 

여기 파이선코드 보면 실제 지원하는 distrobute 들을 알 수 있다.


흥미롭지 않나? 어떤 배포본에서 게스트에대한 어떤 장치 지원이 되는지

이것들만 정리해도 충분히 파악 가능하다.

괜히 이것저것 바꿔 가면서 재부팅 할 필요는 우선적으로 제거된 것이다.

깨알팁은 추후에도 계속될지.............일단 To be Continue..
 
posted by mirr

댓글을 달아 주세요

뭐..비교가 될리가 있겠어? ㅎㅎ

그냥 단순하게 메모리 사용량이랑 Tuned 의 위력,

그리고 kvm_stat 이라는 debugfs 를 이용한 kvm 모니터링툴,

powertop 과, perf 를 이용한 커널 기반 모니터링을 통한 사용법을 깨작대보려고 해봤다. 

일전에 RHEL6 설명하면서 매우 재밌는 녀석들이라고 소개하고 제대로 사용하는걸

연구하기로 해놓구선 안하고 있었는데 그 초입이랄까..일단,

X201 = 4G, DualCore i5 520M, L3 cache ( 64bit, VT enable )
vs
X60s = 1.5G, Hyperthreaded 2 Core (32bit, not VT feature )  정도만 설명하자 쿨럭

대략 사양만봐도 사실 어이가 없긴한데, 그냥 노트북 새로 사면서 심심해서 해봤다고 생각하자.

일단 동일하게 WinXP 32bit 이미지 기존에 사용하고 있던 것을 그대로

X201 에 마이그레이션 하여 동일한 상황으로 맞춰놓고 작업하였다. (스크롤 쩐다)



어쨋든 노트북 새로 사서 좋고, 가상머신에 윈도우 잘 돌아서 좋고.... 64비트라서 좋고....
(흑...내 레츠노트는 아쉽지만 빠이빠이~)

posted by mirr

댓글을 달아 주세요

음...어제 P모 연구소에 들어간 vSpher 4 의 update 1a 를 적용 시켜달라는 요청으로 들어가서 작업했다..

vmware 테스트를 많이 접해 볼 상황이 못되어 ( 맨날 P 모 사에 짱박혀있으므로 ㅎㅎ )

테스트좀 하고 들어가려고 했는데 그냥 바로 들어가게 되버렸다.. ㅠㅠ

혹시 몰라 CD 도 굽고, zip 파일로 되어있는 녀석도 들고 갔는데...

일단 zip 파일을 이용한 업데이트를 해보려고 USB 를 꼽고 적당한 디렉에 파일을 풀었다..

원래 Host Update Manager 라는 GUI 를 이용하여 vCenter 에서 호스트를 업데이트 하는걸

VMware 에서는 매뉴얼 화 하고 있지만, 난 리눅스 엔지니어 아닌가....

GUI 귀찮다..게다가 고객자리에서 해야하기때문에 부담시럽공 ( 테스트를 충분히 한게 아니라 ㅠㅠ )

그래서 콘솔에서 하기로 결정했다...

ESX 에서 지원하는 명령어 중에는 esxupdate 라는 명령어가 있다.

패치파일을 ( zip 파일 ) 적당한 디렉토리에 풀어 놓으면 다수의 드라이버(모듈) 등과

metadata.zip 이라는 파일이 생겨나는데, 이 메타데이타를 인자로 넣어주면 주루룩 진행이 된당!!

esxupdate metadata.zip -m update

우선 다운받은 패치가 정상적인지 확인을 위해서는 -m 뒤에 check 를 넣어주거나, info 를 넣어주면

정보가 나와 확인이 가능하다.

아주 재밌는건... VMware 의 서비스콘솔이 리눅스 그것도 레드햇이기때문에 모듈이나 대부분의 드라이버를

rpm 으로 업데이트 한다는것!!!!

결국 esxupdate 는 rpm 패키지를 업데이트 해주고 설정을 업데이트 해주는 일련의 스크립트와 같은 녀석..
(까보진 않았다 귀찮아서)

어쨋든 쭈루루룩 RPM 업데이트를 하고 나면 bootloader 셋팅을 해주는 쉘스크립트 등이 돌면서

리부팅하라고 뜬다!!!

여기서 중요한건 업데이트 하기전에 모든 VM 들을 VMotion 으로 다른 서버로 옮겨 놓든지,

Power off 를 시켜놓은 뒤, Maintanance 모드로 변경해 놔야 한다는 것이다.

만약 이게 안되있다면 업데이트 도중 (RPM 업데이트 특히 glibc) 메인터넌스모드로 해야 된다면서 중단된다

재밌지? 씨디 넣고 해도 결국 아나콘다가 뜨면서 진행해주기때문에 리눅스 업데이트와 동일하다고 보여진다.

뭐 윈도우 사용이 편한 사람이라면 HUM (Host Update Manager) 를 사용하는 것이 낫다고 하겠지만,

내가 생각하기엔 훨씬 빠르고, 간단하고, 직관적으로 업데이트 도중 생겨 나는 문제에 접근이 가능하다고 본다.

리부팅 하면 update 1a 이라고 기록이 되느냐?? 안된다. update 1a 는 사실 4.0.0 버젼의 마이너 업데이트로써,

릴리즈등의 변화는 없다... 다만 빌드번호가 바뀌는 것 같았다.

update 1a 에서는 Windows 7 지원이 원할하게 될 수 있다고 하긴 했는데, 나야 뭐 운영을 직접 하는건 아니니

모르겠고.....아무튼 결론은 리눅스를 잘 하는 엔지니어라면 VMware 역시 손쉽게 접근이 가능하고,

개념정리가 중요한 것이지, 실제 기술지원은 패러다임만 파악하면 충분히 가능하다는 결론...

RHEV 도 다시 파고들어 봐야하는데... ㅠㅠ

PS : esxupdate 이다... 잘못치면 sexupdate 라고 될 수 있으니 주의하도록 하자 ㅡ,.ㅡ:::

posted by mirr

댓글을 달아 주세요

요즘 십이간지의 가장 으뜸이라고 으시대고당기는 존재가 있는 곳에 RHEV 가 나갔다는데,

결론부터 얘기하자면 KSM ( 메모리 오버커밋 ) 빼면 아직 특별한 강점은 없는 것이

가장 까칠하고 냉정한 결론인것 같다.

사실 VMware 와 비교하자면 기능적으로 구라만 가득차있다. ( 사실 VMware 도 구라삘 부분 꽤나 있... )

몇가지만 간단하게 짚어본다.

VMware 의 기능들부터 나열해보자면

* Virtual SMP
* VMware File System
* vStorage Thinprovisioning
* VMotion
* Storage VMotion
* vDRS
* vDPM
* vHA
* Fault Torrance
* vData Recovery
* Update Manager
* Host Profile
* vNetwork Distributed Switch

이렇게 있고, 위의 기능들중 FileSystem 과 Storage VMotion, Update Manager, Host Profile,

Distributed Switch, Fault Torrance, Data Recovery 기능이 RHEV 에서는 지원되고 있지 않다.

자, 그럼 일단 지원되는 기능들부터 비교해 본다.

vSMP 는 가상머신에 다중코어 CPU 를 할당하는 것이므로 큰 차이없이 잘 서로 지원한다.

Thin provisioning 은 가상화라면 당연하게 스토리지의 공간을 가상머신이 최소한으로 할당받아

절약하여 사용하고자 하는 기능이므로 기본으로 들고간다.

씬 프로비저닝의 기본은 가상머신의 디스크 이미지를 동적으로 만드는 것에서부터 시작된다.

이것은 COW ( Copy On Write ) 라는 기술로 가능해 졌다.

VMotion 이건 사실 예전 Xen Base 때부터 지원되던것으로 운영중인 ( Live ) 가상서버를 다른 물리서버로

운영중에 넘기는 것을 얘기하는 것으로 아주아주 잘된다. RHEV 에선 Live Migration 이라고 한다.

DRS 이것은 분산 자원 스케쥴러를 뜻하는 것으로 가상서버를 여러개로 묶어 크게 자원을 할당해 준뒤,

그 큰 자원의 욕조 ( Resouce Pool ) 의 정해져 있는 일정 룰에 의해 더 자원을 필요로 하는 가상머신에

자원을 할당해 주는 것은 기본, 전체 가상화서버가 자원 부족에 허덕일 경우 같은 클러스터 내부의

여유있는 다른 가상화서버로 가상머신을 넘겨 각 가상머신 (VM) 들이 자원 문제 없이 서비스를 할 수 있게

하는 기능이다. RHEV 에서는 뭐라고 하더라....System Scheduler 라고 했던것 같다..

라이브 마이그레이션이 기본적으로 가능한 상태여야지만 다른 Host 머신으로 옮겨줄 수 있다.

DPM 역시 분산 파워 메니지먼트로, 여러대의 가상Host 가 운영 중일 경우,

몇몇 VM 들이 특히 사용이 잘 안되는 시간대 ( 민원업무 및 사내업무 등 새벽시간때 혹은 아침출근때 등 )

에 한쪽의 Host 서버로 VM 들을 적절히 모아 최소 자원으로 구동하면서, 나머지 Host 서버의 전원을

중단시켜 전력량의 소비를 막는 시스템이다. RHEL 은 Power Saver 라고 할껄.

HA ( High Availity ) 이것은 기존 RHCS 에서 보여주는 HA 랑은 개념이 다르다.

사실상 이 HA 는 단순히 Host 서버 및 VM 이 죽었을 경우 왜 죽었는지는 몰르겠으나 일단 살려야 하므로

간단하게 셧다운된 Host 의 VM 들을 다른 Host 로 옮겨 Start 시켜주는 기능으로

단순히 VM 의 온/오프 기능만 담당하는 것이다. ( 이게 첨에 좀 헛갈리곤 한다 )

이렇게 지원되는 기능은 일단 전부 잘 되는 것 같다.

하지만 이제 짚어봐야 할 것은 없는 기능 및 실제 서버 콘솔리데이션 ( 통합 ) 과정 및 운영에서

사용되야할 필요 기능들이다.

1. File System 이 일반적인 Ext3 및 4 를 지원하게 되는 것은 약간의 문제를 발생시킨다.

VMware 에서 VMFS 가 특별하게 기능 ( feature ) 로 포함되는 이유는 그 특성이 대용량 이미지파일을

다루기 위해 개발된 것이라는 점에 있는데,

 VMFS 는 뭐 거창한건 아니고 단순히 파일시스템의 블럭 사이즈를 용도에 맞게 설정하여

파일시스템이 지원 가능한 최대 단일 파일 개수 및 사이즈를 확장시켜 준 것이다.

이것은 VM 들의 백업 및 디스크 생성, 복사, 이동 성능에 영향을 줄 수 있다.

RHEV 의 경우 디스크 이미지를 다른 서버 및 스토리지로 복사하기 위한 시간이 꽤나 많이 걸린다.

클론 등을 통한 이미지 생성시에도 시간이 걸린다.

아직 스토리지 라이브마이그레이션을 지원하지 않으나 생각해 둬야 하는 것이겠다.

2. 자, 스토리지 VMotion 은 무엇이냐? 말 그대로 스토리지 즉 VM 의 디스크이미지를 운영중에

살짜쿵 옮기는 것이다.

스토리지가 노후되었다. 아니면 이상하다. VM 을 다 옮겨야 한다. 다 끄자. 장난하냐?

몇일 걸린다... 장난하냐???

장비 빼고 납품 빼라는 소리... 충분히 가능하다.

그걸 극복하기 위한 방법이 스토리지 VMotion 이다. RHEV 에서는 지원 하지 않는다 아직.

스토리지는 이중화 하지 않는다는 것은 IT 관리자에게 치명적인 부분이 될 수도 있다는 것을 알아둬야 한다.

스토리지 용량이 많아질 수록 집접도에 성능이 뛰어난 스토리지를 사야하고 그럼 또 비싸지는 법이다.

중형 스토리지 이중화 하는게 훨씬 안전하고 I/O 성능을 골고루 분산시킬 수 있다.

업데이트 매니져 이것은 여러대의 VMware Host 서버를 관리하기 위한 도구이다.

3. Fault Torrance 이것은 진정한 고가용성을 위한 기능으로, Main VM 의 상태를 실시간으로

동일한 상태로 동기화 시킨 채로 StandBy 하고 있어, Active VM 이 장애시 StandBy 에서 서비스가

바로 재개되는 기능이다.

이것은 Vmotion, Storage Vmotion 기반으로 단순한 HA 의 온오프 관리 기능을 보완하는 장애복구 기능이다.

RHEV 에서는 아직 장애복구에 대해서 이정도로 고성능을 지원하지 않는다. ( ClustWare 이용 필요 )

4. Data Recovery 는 RHEV 에서 비스무리하게 지원되고 있긴 하다. 즉 스냅샷과 스케쥴링을 이용하는것인데,

약간 부족한 점이라고 치자면 de-duplication ( 중복제거 ) 기능과, 아무래도 Add-on 으로 작동되는

vDR 에 비해 관리적 측면에서 불편함이 있고, 실제로 스냅샷 복원 및 일정 선택이 원하는 대로 안된다.

즉 4일날과 11일날 스냅샷이 찍혀 백업되었다면, 4일날로 돌아간 뒤에는 11일것으로 돌아갈 수 없다고

알고있다 ㅡ,.ㅡ::

5. Update Manager 역시 지원되고 있지 않다.

RHEV 의 업데이트 버젼이 나오면 분명하게 재설치 해주어야지만 된다.

최소한 새로운 이미지를 넣고 리붓팅을 시켜 업그레이드 작업이 필요하다.

결국 그래서 Maintanance Mode 를 지원하고 있긴 하지만, 반드시 업데이트가 필요한 경우도 있을 것이다.

이 VMware 의 매니져는 Guest OS ( VM ) 들의 OS 패치까지 가능하다.

6. Host Profile 은 여러대의 가상서버를 손쉽게 Deployment 하기 위해 필요하다.

7. Distributed Switch 이것이 있으므로써 VMware 는 진정한 Infrastructure 의 모습에 완벽해 졌다.

데이타 센터에 들어가는 백본 및 상위레벨 Layer 의 네트워크 ( L4, L7 ) +처럼,

각 용도에따라 하나씩 생성되는 가상 스위치의 난무를 정리하는 식의, 여러대의 가상Host 서버의

네트워크를 관리 및 분산 할 수 있게 된 것이다.

RHEV 에서는 아직까지 단순한 네트워크 가상 스위치 레벨밖에 지원되지 않는다.

8. 기타 위에 나열한 제공하는 기능들 외에 RHEV 에서는 아직까지 오작동 하는 것들이 많다.

스토리지 의 성능문제에서부터 MSCS ( MicroSoft Cluster Suite ) 에 대한 지원까지

된다고하고선 안되고 있는게 문제랄까...

사실 위에 나열한 기능들중 일부와 문제점들은 2010 년 하반기에서나 ( Q3 ~ Q4 ) 개선된 버젼이

출시될 거라고 하는데, 벌써부터 팔아제끼면 Redhat 사이트에서 계산해주는 TCO & ROI 의 결과가

의심되는 일이 아닐까 싶다.. 엔지니어는 출장나갈때마다 땅파먹고, 사과만 하고 당겨야 한다는 건가?

KSM ( Kernel Memory Sharing ) 의 경우 역시 납득할만한 눈에띄는 모니터링 결과 리포트가

존재 하지 않아 커널가이들 사이에서도 논란이 일고있는 상황이다.

모니터링에 대한 부재 - 부재라기보단 빈약? - 그리고 RHEV 를 위한 서드파티 개발회사들이

존재하지 않는 단점도 ( 오픈소스를 가져다 쓰지만 써드파티등에서 RHEV 를 위해 개발하려고 노력하지 않는 )

무시하지 못할 것이란 얘기랄까??? 아싸리 데스크탑가상화에 대한 최상의 성능을 노려보는건 어떨까 ???

그나저나 멘토링데이 발표자료도 안만들고 뭐하니???

오픈오피스로 프리젠테이션하기 빡씨.......흑..

좀더 디테일한 문제점들 분석 및 VMWare 에 대한 비교는 다음 시리즈에 작성하도록 하겠다.

얘기하자면 밤을 샐만큼 복잡하고 길다. VCP4 업그레이드 패스한 뒤에나 다음 포스트는 올라갈 듯....

'Skills > 가상화(Hypervisors)' 카테고리의 다른 글

ThinkPAD X201 vs X60s KVM 비교  (0) 2011.03.20
vSphere 4 update1a  (0) 2010.04.15
RHEV 이야기 두번째  (1) 2010.01.12
RHEV (RedHat Enterprise Virtualization )  (0) 2009.12.14
재해복구 관점에서의 가상화  (0) 2009.10.17
Xen P2V 관련..  (0) 2009.09.09
posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of http://mirr4u.textcube.com BlogIcon mirr

    vmware 와 RHEV 역시 현재 많이 변화되었고, 이글을 쓸때 조금 겉핥기식이였던 부분이 있어서 정리해야하는데 ㅠㅠ

    2010.05.20 14:02

RHEV 즉 VMware 나 Citrix Xen 과 같은 KVM 기반 레드햇 하이퍼바이저 서버가

드디어 출시되었다. 물론 출시된지는 좀 됐지만....

일단 얼마전 싱가포르에서 열린 2009 Tech Summit 에서 발표를 대대적으로 했고,

RedHat 측에서 주력 상품 및 미래주도적 상품으로 밀겠다는 상품인데,

위에서 말했듯이 KVM 기반으로한, 최소한의 OS 를 RHEV-H (Hypervisor) 라고 하고,

이것들을 관리하기위한 RHEV-M (Management) 이 한 묶음으로써 RHEV 가 된다.

RHEV-H 야 일반적인 하이퍼바이저와 비슷한 모습이고, 설치 및 셋팅역시

기존 리눅스기반 아나콘다 설치가 아니라 간단한 TUI 로 메뉴를 선택하여 컨피그하면

자동으로 설치해 주는 모습을 갖고 있다.

VMware 에서밖에 구현되고 있지 않던 Memory Overcommit 의 구현이 가능해졌고,

HA, Dynamic Maintanance, 자원공유(Resouce Pool), LiveMigration, Snapshot, DPM 기능등

기존 가상화가 쌓아온 기술들을 모두 충족시키고 있다.

다만 VMware 에 비해 약간 아쉬운 점은, VMware 에 있는 Resource Pool 개념을 클러스터단위로

줄 수 있게 되어있고, 클러스터에서 사용되는 Resource Pool 은 Host서버 (물리적) 의 전체

리소스를 퍼센테이지로 분배하는 형식으로 되어 있었다는점.

( vSphere 의 경우 MHz 및 MB 또는 GB 단위로 세세하게 설정 가능 )

어쨋든 Direct I/O 등의 기술들이 적용된 커널의 패치역시 성능면에 있어서 대단하다고 볼 수 있었고,

모든 관리기능을 웹으로 구현하여, history 및 작업의 검색 등도 웹브라우저에서 편하게 할 수 있는점이

매우 매력적이였다.

단지 아이러니하고 어이없던 점은 이것들 역시 매니지먼트프로그램이 있어야 기능 사용이 가능한데,

Windows 2003 R2 Sp2 영문 + MSSQL (Express가능) + Powershell + IIS + AD + DNS

구성이 이루어 져 있어야만 한다는 것이다.

추후에 AD 는 LDAP 으로도 대체 가능하도록 할것이라고 하는데,

쿰라넷을 인수하고 채 포팅이 되지 않은 상태에서 너무 성급하게 시장에 제품을 내놓은건 아닌가

싶기도 했으나, RedHat 의 상황과 가상화 시장의 급진적 발전속도와 방향을 본다면

역시 어쩔 수 없는 선택이였거니 싶기도 한다.

어쨋든 가장 주목할 점은 역시 Memory Overcommit 기능으로써, 동일한 라이브러리 및 커널코드가

메모리에 적제될 경우, 코드를 비교하여 동일하다 판단 됬을 경우 실제 물리적 메모리의 주소를

하나로 통합하여 리드온리모드로 다른 VM ( Guest OS ) 에서 사용할 수 있게 하여,

그만큼의 나머지 물리적 메모리를 해제하여 좀 더 높은 통합비율과 성능을 보장해 주는 기능이다.

이게 왜 중요하냐면 특히나 서버 통합 ( consolidation ) 에서 투자비용등 TCO & ROI 의 문제인데,

Xen 의 경우 물리멤 4G 서버 하나에 Guest OS 들을 각각 1G 메모리씩 줘야 할 경우,

하이퍼바이저에 필히 할당되야할 메모리 때문에 ( 권장 1G 정도 ) 3 개의 VM 밖에 올릴 수 없게 된다.

이것은 일단 Guest 를 시작시킬때도 메모리 부족을 대비하여 동시에 실행 시키지 못하는 결과를

불러올 수도 있으며, 통합비율 자체도 3:1 의 비율로 현저하게 줄어들어 버리는 것이다.

결과적으로 서버 통합대수가 12대 일 경우 VMware 에서는 12 : 1 의 통합도 경우에 따라서 무리하지 않다고

하는 반면, Xen 의 경우에는 Host 서버(물리적)가 4대가량 필요해 질 수 도 있는 상황이 되버리는것이다.

이것은 MS 의 Hyper-V 또한 마찬가지이다.

하지만 KVM 은 리눅스 기반에서 커널과 함께 KSM ( Kernel Share Memory - 이름바뀔예정 ) 기능을 이용하여

메모리의 중복사용을 제거하였기 때문에 메모리 오버커밋이 가능한것이고, 이로써 VMware 에

가장 가깝게 쫒아 갈 기반이 생기게 된것이다.

( Memory overcommit 의 경우 동일한 OS 일 경우 효과가 최대화 되긴 하겠다. - 혹시몰라 설명함 )

물론 VMware 가 가상화 서버 시장의 정점에서 항상 새로운 개념과 새로운 기술들을 적용하고 선보이는

선두주자이긴 하지만, 역시 놀고만 있을 수는 없다는 것...

일단 RHEV 에대한 간단한 소개 만 하는 글로 시작되었기 때문에, 여기까지로 줄이겠고,

아직 가상화 서버들에 대한 할말은 많이 남아있고, 설명해야 하는 부분들도 많이 남아있다.

어쨋든 RedHat 쟁이로써 그리고 VMware 쟁이로써의 RHEV 에 대한 관심도와 기대치는 매우 높으며,

주목 할 수 밖에 없는 상품인 것이다...

끝으로 사족인데, RedHat 이든 VMware 에서든 Xen 은 경쟁대상으로도 안보더라. Overcommit 때문에 ㅎㅎ


posted by mirr

댓글을 달아 주세요