Skills/가상화(Hypervisors) 2010. 4. 15. 17:51
음...어제 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

댓글을 달아 주세요

Skills/System 2010. 3. 5. 01:15
본 글은 스스로에게 어디까지 기술력을 보유해야 한다고 생각하는 건지 자문하는 글로써,
정리되지 않던 글들은 다시 정리하여 공개합니다. 문제가 되는 부분들은 언제든지 얘기해 주십시오.

어느정도 진행되는 동안 R 사의 GSS 에서는 고객의 의문사항들을 어느정도 답변 해 주고 있던 상태..

고객의 심도있던 Thread 와 메모리의 상관관계, VM split 모델에 대한 심도깊은 관계 (spilt 등 )

최대 스레드 값을 계산 할 수 있는 공식, Lowmempage 부족의 의미, Lowmem 부족상태에서

swap 이 사용되지 않는 경우, cache memory  와 swap 의 관계, 메모리 관리 ( linux-mm ) 알고리즘,

2.4 커널과 2.6 커널의 차이점 ( 나름 상세하게 - 메모리 관리에서부터 쭈~~~욱 )

paging 매카니즘 등등... 거의 세미나수준으로이지 않나 싶게..

GSS 에서는 나에게 전화로 혹시 세미나하는거냐고 매우 지원하는데 깊은 심도로 인해 어려움이 있었다고

난이도와 난감함을 우스개소리로 했을 정도.....ㅠㅠ

엔지니어레벨에서는 이해를 하겠으나 설명하기는 난감한 상황 발생...

어찌됐든 현재는 장애 재현이 강제로는 발생하지 않는 상황에 돌입하여버린것이다.

이 문제를 해결하기 위하여 우리는 고객에게 각종 리눅스 인터널적인 매카니즘 및 알고리즘들과,

OS 의 문제가 아님을 판명하려 노력해야 했다. ( 머리터지는줄 알았.... )

이런 이슈들로 인해 물론 나역시 많은걸 보고 배우며 생각하게 되긴 했는데,

이과정을 겪으면서 이상적으로 자문하게 되는 부분은

과연 SE 가 해결해 줄 수 있어야 하는 범위는 어디까지 인것일까? 라는 것...

고객은 Oops 커널이나, 커널 디버깅 모드를 설정하거나, 또는 빌드를 새로 하더라도,

커널 내부 메시지들을 로그 찍어 적극적인 해결을 요구하는 상황도 있을 수 있고...
( R 사에서는 커널이 수정되거나 개별 빌드하게 되면 지원이 중단된다 )

RHEL3 의 EOS 가 올 10월로 정해진 마당에, 계속 지원하는 엔지니어로써는 솔직히 환장할 일인 것이다.

인터널에 대해 궁금해 하면 할 수록 이해하고 설명하기가 더 힘들다는 점 역시 어디까지 공부해야하는지...휴~

과연 SE 로써, 커널의 상세 매카니즘들에 완벽하게 알 고 있어야 할 필요가 있을까? 라는 생각이

주를 이뤘던 나였기에 더더욱 자문하게 되는 부분....

Lowmem 영역에 DMA 가 포함되는 그 이유까지 알아야 할 필요가 있을까?

Lowmem pagetable 이 0 일 경우 Highmem pagetable 을 이용한다 정도까지면 되지,

어떻게 얼마나 매핑이 되는지 과연 심각하게 파고 들어야만 하는 것인가??

1G/3G 스플릿에 적용받는 커널은 일반커널과, SMP 이고, 64 비트의 경우 스플릿이 없으며,

Hugemem 커널의 경우 4/4G split 를 알 정도면 되는 것인가?

왜 그렇게 되는건지는 몰라도 되는가??

VM 끼리 연결이 어떻게 되는지는..??

Stack 사이즈와 Threads 의 관계만 알면 되지, 왜 Stack size 가 Threads 와 관계를 갖는 건지

알아야 하지 않는가 ????

내 생각엔 모두 'No' 였다. 알아두면 좋지만 꼭 알아야 할 필요는 없다고 생각했다.

SA ( system architect ) 가 아니라 engineer 이지 않는가? 엔지니어의 최대 목적은,

적절한 효율을 낼 수 있는 것이라고 생각한다.

장애에 대한 대비를 항시 하고, 예측하며, 발생시에는 원인분석에 걸리는 시간을 계산하여,

적절하고 효율적인 대처를 통해 장애 처리를 하여 서비스를 재개시키고, 장애가 재현되지 않도록

하는 것이 SE 라고 생각한다.

고로 장애 발생시에는 가상화이므로, 멀쩡한 VM 에서 클론을 후다닥 떠서 서비스를 재개한뒤 (가상화의 장점!)

원인분석을 위해, 장애가 있던 VM 을 가지고 실제 서비스와 비슷한 상태를 만들어 놓고,

발생되는 정상적인 core dump 를 분석요청 하는 것 정도까지가,

실제 엔지니어레벨에서 충분한 지원범위 였지 않았나 싶은데..또 그것도 정하기가 애매하다는....

가상화 환경이니만큼 시스템 장애시 복구 및 관리 혹은 deploy 가 수월하니,

구글이나 다른 서비스업체들에서 하듯이 동일 시스템을 바로 박아넣어 동작시키면 되는것이라곤 생각되는데..

엔지니어는 서비스가 열심히 돌아가게 해주는게 본분이라면

그럼 SA 까지 바라본다면 어떻게 해야하는거지????

결론은 끝이 없이 나오지 않겠지만........고민되는 부분이다 정말...

리눅스의 커널은 방대하고 심오하다. 커널의 개발자들도 각 매카니즘의 동작 원리를 파악하고,

남에게 설명해 주기에는 더 어렵고도 더 어려운 일인것 같다.

무엇보다 누가 그 깊은 부분들을 다 이해할 수 있을까??

나도 최근 커널공부를 위해 여러가지 준비중인 상태에서도 이해가 잘 안가는 부분들이 많은데....

시스템 엔지니어로써의 가장 필요한 마인드가 무엇인지 생각해 볼 필요가 있었다...

난 어디까지 가야 하는건가?? 어디까지 가려고 하는 건가??


posted by mirr

댓글을 달아 주세요

Skills/System 2010. 3. 5. 01:14
본 글은 스스로에게 어디까지 기술력을 보유해야 한다고 생각하는 건지 자문하는 글로써,
정리되지 않던 글들은 다시 정리하여 공개합니다. 문제가 되는 부분들은 언제든지 얘기해 주십시오.

말 그대로, 시스템 엔지니어로써 갖춰야 할 기술력은 어느정도일까??

2월 3일부터 모 사이트에서 발생한 장애로 인하여, 2월 한달 내내 사람이 살듯 살고있지 못했다. ㅠㅠ

가상화 위에 올라가 있던 RHEL3 (kernel 2.4 smp - 16G) 시스템이 아무런 이유 없이 Hang up 에 빠진것.

우리측의 초기 대처는 일단 전반적인 시스템 메시지 및 로그를 살펴 보는 것..

메시지는 갑자기 파워오프된 서버들에서 흔히 볼 수 있게, 특별한 메시지 없이 뚝 떨어져 있다가,

restart 되는 것들만 있었고, sar 데이타 역시 특별한 이상유무를 찾을 수 없을 정도로

자원 상황은 원할한 상황이였다.
( 특별한 로그가 없이 죽으면 정말 난감할 수 밖에 없다 )

가상화 측 분석 요청도 한 상태였는데, 가상화측에서는 아무런 메시지가 남겨져 있는게 없다는 말...

결국 발칵 뒤집혀 지기 시작했다. OS 측의 문제인 것 아니냐는 식으로 몰려가기 시작한다.

sar 데이타는 디폴트 10분이기 때문에 물론 정확하지 않다는게 맞는 말이긴 하지만,

이 상황에서 장애 원인을 찾기란 힘든 상황이었다.

고객이 설정들을 직접 살펴본 결과, threads-max 커널파라메터가 다른 일반 서버들보다 낮게 설정되어

62327인가 라는 값으로 올려논 상태라고 하였고, 그 후로 모니터링 중이라고 하였다.

이차 분석을 하려고 방문 한 날, 고객측에서 테스트 (장애재현) 를 하게 되었고,

몇가지 간단한 시나리오를 바탕으로 테스트에 들어갔다.

주요 테스트는 단순한 Thread 생성 테스트를 통한 부하 테스트..
( sysrq 로그나 응용프로그램 로그등에 찍힌 fork(): not allocate memory 뭐 이런 로그로 인하여 )

테스트 프로그램을 실행 시키자, 순식간에 서버가 뻗는다.

아하 이거구나! 라고 생각한 전부는 threads-max 의 적절한 값을 정하지 못해서 그런것으로 판단,

R 사 에 문의 하기로 한다. ( 그상황에서 VMware 와 Diskdump 의 지원문제로 netdump 설정 함 )

간단한 R 사 의 답변은 SMP 커널의 경우 메모리가 어느정도이든,

프로세스나 스레드 생성을 위해서는 1G/3G 스플릿 모델에 의해 1G 영역에서 관리할 수 있게 되고,

소스상의 최대 생성가능 수는 32000 개로 정해져 있다는 것.

고로 이 시스템에선 1G / 8 * (8192/4096) = 14336 이라는 것. ( default threads-max 값 )

가상화 이전엔 Hugemem 이였던 시스템이였으나, VMware 의 hugemem 미지원으로 인해

smp 를 사용 하였다는 정보 추가. ( smp = Max 16G Ram ).

뭐, 결국 원점이 되버린건데, 장애의 원인은 결국 못찾았다는것이다.

그래서 다시 테스트를 해 보았고, 테스트 시점에서 netdump 와 sysrq 를 통해 core dump 를 받아

R 사 에 다시 문의 하였다.

R 사 에서 돌아오는 답변은 간략하게, 정확히 행업상태의 덤프가 아니라, 스냅샷식의 덤프라 의미가 없다는것.

분석 내용에서는 메모리가 부족하여 Hang-up 으로 보였을 뿐 Hang-up  은 아니라는 것이였다.

아차.. 그럴 수도 있었겠군... 그러나 몇일 뒤 다시 Hangup!! 게다가 netdump 문제로 not dump...

대략 여러가지 살펴보았고, 또다시 뜬 메모리 부족 및 fork 에러를 기반으로 다시 시나리오를 작성.

문제는 메모리할당이나 스레드 등등 이지 않을까 싶어 R 사 엔지니어 방문요청! 테스트를 해보았다. (와우~)

- 계속 -

posted by mirr

댓글을 달아 주세요

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

댓글을 달아 주세요