'RHEV-M'에 해당되는 글 2건

  1. 2010.01.12 :: RHEV 이야기 두번째 (1)
  2. 2009.12.14 :: RHEV (RedHat Enterprise Virtualization )
Skills/가상화(Hypervisors) 2010. 1. 12. 23:51
요즘 십이간지의 가장 으뜸이라고 으시대고당기는 존재가 있는 곳에 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

Skills/가상화(Hypervisors) 2009. 12. 14. 10:44
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

댓글을 달아 주세요