RHEV 이야기 두번째

요즘 십이간지의 가장 으뜸이라고 으시대고당기는 존재가 있는 곳에 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 업그레이드 패스한 뒤에나 다음 포스트는 올라갈 듯....