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

댓글을 달아 주세요

Skills/가상화(Hypervisors) 2009. 10. 17. 11:33
야간작업중이다.

데이타 마이그레이션 및 재구축인데...

RAC 구성과 GFS, IBM iseries 로 되어있는 WAS 시스템이 대략적인 구성이다.

뭐 별거 있나. 그냥 RAC 구성되있던 서버 쭉 밀고 RHEL 4.8 최신버젼으로 설치 한담에,

스토리지 할당 받고 ORACLE 설치하면 되는거지...

GFS 구성도 서버 RHEL5.4 로 쭉 밀고 스토리지 할당 받은담에, GFS 설정하면 되는거지..

그런데 이런... IBM iseries 가 문제가 생겼다.

스토리지를 해제시켜놓고 다시 구성하는 상황이였는데, 행이 걸려있다...

설마설마 했는데, iSeries 를 함부로 다룰 순 없었기에, 게다가 부팅의 방법도 모르기에...

쥐쥐였다......

i 엔지니어가 새벽 두시에 들어와서는 두개 디스크가 미싱 ( os 영역 ) 이 나서 재구성해야 할 수도 있겠단다.

전체 재구성...............쥐쥐다...

이때 역시나 바로 드는 생각은 가상화 였다.

VMware 로 구성하여 DR 을 이루었더라면, 아니 하다못해 FT, HA 라도 구성을 해놨더라면

지금과 같은 상황에서 재해복구는 문제가 되지 않았을 것이다.

iSeries 같은 것에서 가상화로 자원을 나눠 할당했다는 것은, 장애가 발생했을때 큰 문제가 된다.

일단 방금설명했던 대로, iSeries 등 특별한 장비를 다룰 수있는 엔지니어가 필요하다는 것.

그리고 재난 발생시 대체할만한 비슷한 성능의 대체장비의 준비와, 백업,복구 과정이 어렵다는 것.

이래서 VMware 등의 x86 가상화솔루션이 필요한 것이다.

iSeries 에 있는 7개 정도 되는 VM 을 vSphere 4 로 구현 한다고 했을 경우,

IBM x3850_m2 시리즈 두대를 준비 ( 2CPUs nehalem, RAM 16G ) 7개 VM 을

각 서버에 나누거나 이중화를 시켜 ( 양 서버에 각각 7개 동일 VM 이 구동 - Fault Torrence )

충분히 여유롭게 가동이 가능하고, 지금과 같은 스토리지 재구성으로 인한 디스크 missing 현상 같이

디바이스 매칭이 안되서 알아 올 수 없을때, 혹은 메인 OS 의 문제가 발생 했을때,

한쪽의 서버에서 대체 구동이 가능 할 뿐만 아니라, 나눠서 운영중이였다면 한쪽의 서버로 7개의 VM 을

집약시켜 이상없이 구동이 가능하다는 점이였다.

게다가 장비 두대가 모두 문제가 생겼다 하여도 x86 기반이므로 다른 서버들보다 훨씬 빨리

하드웨어 수급이 이루어 질 수 있고, 백업 및 복원도 단지 몇분만으로 동일한 환경이 생성되어

서비스 될 수 있다는 것이다. - 심지어 vSphere 4 서버 솔루션 문제라면 간단히 재설치해주면 된다 !!!!

어쨋든 지금 나와서 작업하고 있는 이곳은 아직도 중국에 가있는 iSeries 엔지니어가 오기를 기다리고 있고,

와서 재구축을 한다고 해도 이틀의 시간을 소요 해야 할 것이다.

확실히 재난복구 상황에 대한 가장 효율적인 해결책은 가상화 시스템이 아닐까 생각된다.

너무 졸려서 두서없이 써버렸는데, 일단 잠좀 간단하게 자고 작업 마친 뒤 정리해야 할듯 하다.


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2009. 9. 9. 00:14
최근 vSphere 4 Essential Plus 가 들어간 사이트에서

백업관련 이슈가 생겨서 VCB 를 알아보던중 Data-Recovery 가 쓸만해보여

Data-Recovery 로 백업솔루션을 대체하기로 하였다...

뭐 VCB 는 VI3 에서까지 계속 사용되어 오던 백업시스템인데,

사실 이게 매우매우 허접스러워서 여타 다른 솔루션을 병행해야했다.

커맨드라인 리모트 스냅샷 이라고 보면 대충 비슷했다고나 할까...

아무튼 그런데 이 4버젼으로 올라오면서 생긴 Data-Recovery ... 이거 좋다...

특히 vSphere 4 Essential 에는 없지만 Plus 에는 이놈과 HA 까지 된다..

VMotion 은 안되지만 Plus 이거 괜찮다...

어쨋든, 이거 설정하는데 무지 애먹었다....왜냐면..

이 Data-Recovery 의 구성을 보자하면,

Data-Recovery 용 서버가 VM 으로 구성되어 있어야 하며,

VC 에 Data-Recovery Plug-in 을 설치해야 한다...

그리고 백업된 파일이 저장될 Shared Directory 가 필요하다..

여기서 문제는 Data-Recovery VM 이였다...

이게 재밌는것이, 기존 VMware 어플리언스들과 다르게, 스탠다드 얼론 식으로

혹은 따로 데몬이나 서비스로 올라가는 것이라기보단,

리눅스 기반 서버에 데이타리커버리가 커스터마이징된 VM 이라는 것이다..

간단하게 말하자면, Data-Recovery ISO 이미지에 있는 ovf 템플릿을 이용하여

VM 으로 Deploy 시켜 사용해야 한다는 것....

게다가 이 것은 CentOS 5.2 에 바인드 되어있다....

즉 CentOS 를 다뤄야 하는 일도 생긴다는거지......

뭐 리눅스에 익숙하다면야 모르겠지만, 또 재밌는건 아까 얘기했던 CIFS..

즉 리눅스에서 mount 명령을 통해 CIFS 로 윈도우 공유디렉토리를 마운트한뒤,

중계서버로 리눅스를 이용하여 백업을 한다는것이다....

뭐 이게 나온지 얼마 안되었고, 실제로 잘 사용하는 사람들이 없다는 걸 보면,

앞으로는 컨버터등처럼 스탠다드얼론까진 아니더라도 최소한 서비스 데몬 식으로

나올것 같긴 한데... 어쨋든 리눅스에서 CIFS 붙히는 부분에 이상하게

정상적으로 되질 않아 하루를 꼬빡 고생했고,

담당자가 정보통신기술사였었고..옆에서 계속 지켜보고 계셔서...

매우 긴장속에 땀을 무쟈게 흘렸다는거지......

결국 하루에 해결 못해서 이튿날 뒤인 오늘 이 CentOS + DataRecovery VM 을

삭제하고 다시 디플로이 하는것으로 해결했다는거.....

첨엔 윈도우쪽에서 된다는 소리에 윈도우용 데몬 혹은 서비스프로그램을 찾느라

아주 캐삽질 해보았으나.... 역시 그것은 헛소문............ㅠㅠ

기술지원 나간 엔지니어가 고객과 함께

'음 이건 이렇게 해볼까요?', '음..이건 이렇게 해야할거같은데..음 그렇군요..'

라며 상담하며 기술지원하는 VMware.... 아주 재밌어~~~~~ ㅡ.,ㅡ:::

어쨋든 Data-Recovery 이건 기존 VCB 와는 달리 GUI 로 설정 되며 관리되고,

스케쥴링 및 보관주기까지 정해서 관리 할 수 있으므로 Essential Plus 이상을

무조건 강추하는 바이다...물론 속도는 약간 느린것 같긴한데,

디폴트 스케쥴링시간이 매일 업무시간 제외한 나머지 시간들이다.

괜찮지 않나?? 물론 VMWare 측에선 여전히 써드파티 솔루션의 병행을

권장하고 있다.. 왜?? 파일기반 백업은 아무래도 안되기때문이쥐~~

참고로 Essential Plus 는 2 socket CPU, 3 개의 ESX Host 까지 커버리지가 가능하다.

         -------------------------------------------------------------------

이 부분은 ( 연결 문제로 잦은 디플로이를 요구하는 문제 ) 미국 본사와 에스컬레이션이 진행됨..

답변으로는 아직 계속 개발 및 패치중이고, 이미 보고된 문제이므로, 패치 될때까진

미안하지만 계속 그상태로 사용하는게 좋겠다.. 라고 클로징이 되었었으며,

어제 새로 날라온 엔지니어의 메일로는, vDR 이미지가 새로 업데이트 되었으니,

그걸 받아다 디플로이 해보고 문제가 생기진 않는가 확인 해 달라고 하였다...

실 운영환경이다보니 고객이 백업에 민감해서 시도 할지는 모르겠고, 테스트 서버에서

테스트를 해봐야 하는데 환경이 썩 좋은 건 아니라 글쎄........

--------------------------------------------------------------------------

업데이트 된 vDR 로 몇개월째 사용중인데 고객측에서 아무 문제 없이 잘 사용하고 있다고 한다.

현재는 vSphre4 Update 1 까지 나와있다. ( 문제가있어서 내렸다 다시 올린거지만 )
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2009. 8. 5. 21:32
최근 vSphere 4 Essential Plus 가 들어간 포스*경영연*소 에

백업관련 이슈가 생겨서 VCB 를 알아보던중 Data-Recovery 가 쓸만해보여

Data-Recovery 로 백업솔루션을 대체하기로 하였다...

뭐 VCB 는 VI3 에서까지 계속 사용되어 오던 백업시스템인데,

사실 이게 매우매우 허접스러워서 여타 다른 솔루션을 병행해야했다.

커맨드라인 리모트 스냅샷 이라고 보면 대충 비슷했다고나 할까...

아무튼 그런데 이 4버젼으로 올라오면서 생긴 Data-Recovery ... 이거 좋다...

특히 vSphere 4 Essential 에는 없지만 Plus 에는 이놈과 HA 까지 된다..

VMotion 은 안되지만 Plus 이거 괜찮다...

어쨋든, 이거 설정하는데 무지 애먹었다....왜냐면..

이 Data-Recovery 의 구성을 보자하면,

Data-Recovery 용 서버가 VM 으로 구성되어 있어야 하며,

VC 에 Data-Recovery Plug-in 을 설치해야 한다...

그리고 백업된 파일이 저장될 Shared Directory 가 필요하다..

여기서 문제는 Data-Recovery VM 이였다...

이게 재밌는것이, 기존 VMware 어플리언스들과 다르게, 스탠다드 얼론 식으로

혹은 따로 데몬이나 서비스로 올라가는 것이라기보단,

리눅스 기반 서버에 데이타리커버리가 커스터마이징된 VM 이라는 것이다..

간단하게 말하자면, Data-Recovery ISO 이미지에 있는 ovf 템플릿을 이용하여

VM 으로 Deploy 시켜 사용해야 한다는 것....

게다가 이 것은 CentOS 5.2 에 바인드 되어있다....

즉 CentOS 를 다뤄야 하는 일도 생긴다는거지......

뭐 리눅스에 익숙하다면야 모르겠지만, 또 재밌는건 아까 얘기했든 CIFS..

즉 리눅스에서 mount 명령을 통해 CIFS 로 윈도우 공유디렉토리를 마운트한뒤,

중계서버로 리눅스를 이용하여 백업을 한다는것이다....

뭐 이게 나온지 얼마 안되었고, 실제로 잘 사용하는 사람들이 없다는 걸 보면,

앞으로는 컨버터등처럼 스탠다드얼론까진 아니더라도 최소한 서비스 데몬 식으로

나올것 같긴 한데... 어쨋든 리눅스에서 CIFS 붙히는 부분에 이상하게

정상적으로 되질 않아 하루를 꼬빡 고생했고,

담당자가 정보통신기술사였었고..옆에서 계속 지켜보고 계셔서...

매우 긴장속에 땀을 무쟈게 흘렸다는거지......

결국 하루에 해결 못해서 이튿날 뒤인 오늘 이 CentOS + DataRecovery VM 을

삭제하고 다시 디플로이 하는것으로 해결했다는거.....

첨엔 윈도우쪽에서 된다는 소리에 윈도우용 데몬 혹은 서비스프로그램을 찾느라

아주 캐삽질 해보았으나.... 역시 그것은 헛소문............ㅠㅠ

기술지원 나간 엔지니어가 고객과 함께

'음 이건 이렇게 해볼까요?', '음..이건 이렇게 해야할거같은데..음 그렇군요..'

라며 상담하며 기술지원하는 VMware.... 아주 재밌어~~~~~ ㅡ.,ㅡ:::

어쨋든 Data-Recovery 이건 기존 VCB 와는 달리 GUI 로 설정 되며 관리되고,

스케쥴링 및 보관주기까지 정해서 관리 할 수 있으므로 Essential Plus 이상을

무조건 강추하는 바이다...물론 속도는 약간 느린것 같긴한데,

디폴트 스케쥴링시간이 매일 업무시간 제외한 나머지 시간들이다.

괜찮지 않나?? 물론 VMWare 측에선 여전히 써드파티 솔루션의 병행을

권장하고 있다.. 왜?? 파일기반 백업은 아무래도 안되기때문이쥐~~

참고로 Essential Plus 는 2 socket CPU, 3 개의 ESX Host 까지 커버리지가 가능하다.

posted by mirr

댓글을 달아 주세요

Skills/System 2009. 6. 17. 12:48
요즘 계속 Pos** 경*연구소 로 VMWare 지원을 나가고있는데...

IBM 3650 M2 에 올라가거등....

이게 네할렘 프로세서를 쓰는등 가상화를 겨냥하고 나온 시스템이라 그런지,

ESX 4 (Vsphere ) 의 성능이 매우 잘나오는것 같다...

ESX 가 4버젼 Vsphere 라는 이름으로 올라가면서 성능 및 기능에 많은 변화를 이뤘는데,

그동안 반신반의 했던 부분들을 말끔히 정리시켜줘버리네...

윈도우 시스템 7대와 리눅스 시스템 한대 통합시키는거였는데,

메모리부분등 독립적 물리서버일때보다 훨씬 줄여서 VMware의 메모리 관리기능에

맡겨놨는데 고객은 오히려 더 좋은 성능을 보이는것 같다면서 좋아하더라고...

게다가 P2V 역시 많이 좋아지고 향상되서 리눅스 시스템마져 큰 문제 없이 잘 P2V를

진행하였다는...그러나 고객의 기존 리눅스가 SULinux라서 가상디스크 모듈이 없던지라,

결국 다른 레댓계열 리눅스로 재설치 하였지만..(뻔하지 커뮤니티엔터프라이즈OS)

HP에서도 저번달부터인가 이달부터인가 G6 로 라인업 하면서,

가상화에 매우 큰 관심을 갖고 라인업 했다고 하던데..특히 블레이드 시스템들에서말야..

암튼 P2V 시 데이타 동기화 과정때문에 업무가 중단된 저녁에 작업하느라고

거의 밤을 새다시피 했지만, 제대로된 경험이였달까.....

VCP 취득후 처음으로 제대로된 지원이였고, 물론 스토리**리 의 양과장님 도움이 컸다..

VMWare 디자인과정이 좀 복잡하며 머리아프고 매우 큰 부분을 차지하지만,

확실히 재미는 있군.......

참고로 오는 6월 25일 Vshpere ( VMware ESX 4 ) 제품발표 및 소개 세미나가 있다고하니

관심있으신 분들은 참고해 두시길.....

'Skills > System' 카테고리의 다른 글

CloudeComputing on RHEL5 (Xen)  (2) 2009.07.04
효율적 데이타베이스관리를 위한 MySQL 세미나..  (0) 2009.06.17
VMware Essential Plus 구축..  (0) 2009.06.17
커널 코어덤프 분석하기...  (0) 2009.05.05
advise path 메시지 로그  (0) 2009.04.22
CentOS 5.3 Released..  (0) 2009.04.01
posted by mirr

댓글을 달아 주세요

Life/The Past 2009. 4. 7. 18:39
내가 VCP 취득했다는 얘길 한적이 있던가...

취득하기위해서는 200만원 상당의 트레이닝과정과

20만원 상당의 시험을 모두 패스해야지만 VCP 자격이 주어진다...

한마디로 돈이 무쟈게 드는 자격증으로 개인이 취득하기엔 엄청난 무리가 있.......

암튼 회사에서 VMware 도 한다면서 VCP 2명 필요하다길레 얼결에 취득했다...

뭐 가상화에 대한 수요와 네할렘등 가상화를 위한 기술발전동향을 보면서

관심이 마구생기긴했지만....무튼...

내일 분당으로 VMware 컨설팅을 나간다....

컨설팅이라니 뭘 어떻게 해야하는거야 이거.....흥미진진한데.... 켁..



'Life > The Past' 카테고리의 다른 글

소니에릭슨 X1 Xperia 구입...  (4) 2009.04.26
밤샘작업 했더니...  (0) 2009.04.15
VMWare 첫 컨설팅인가...  (2) 2009.04.07
북한 인공위성 발사실험...  (0) 2009.04.05
간만에 쓴 글들이...  (1) 2009.03.27
정의로움을 지킨다는 것은..  (1) 2009.03.23
posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of http://truefeel.tistory.com/ BlogIcon 좋은진호

    오~ VMware 컨설팅. 컨설팅은 잘 했나요?
    (댓글다는 사람 이제 나 밖에 없네. ^^)

    2009.04.08 18:57
    •  Addr  Edit/Del Favicon of http://blog.mirr4u.com BlogIcon 미르

      ㅎㅎ 뭐 그냥 데스크탑가상화가 주 목표였던지라 그냥
      개념설명정도로만....댓글.. 흑 공개만 하고 발행을 안하죠 요즘 ㅎㅎ

      2009.04.09 00:42