[가상화&자동화] HDD Image :: Pre-Installed Template vs. OS-Only Template (with Chef/Puppet) (about AMI)

Cloud 2013. 2. 24. 21:54

VM Template 이미지를 어떻게 만들고 운영해야 유리할까~???


최근, Chef로 서비스 구성(Configuration) 자동화 파트를 다시 하게 되었다. 여기저기 타 부처 수행 인력과 협업도 해야 하는 상황이라, 가상화 인프라부터 논의를 통해 결정을 지어야 할 일이 많다... 서비스 구성에는 Hadoop Cluster, MySQL & Replication, Cassandra, MongoDB, HAProxy LB, Apache/Tomcat, 등등 여러가지 서비스들이 버튼 한번의 클릭으로, 동적 구성 및 동작이 되어야 한단다. (쉽게 이야기들 한다...쿨럭...) 이러한 일련의 자동화 구성/배포 전략 수립단계에서 여러사람들끼리 혼선도 있고, 의견 충돌이 있는 것은 당연하다. 왜? 정답이 없는 거니까~ ㅡ.ㅡㅋ 사실 이 섹션의 고민은 Cloud라는 단어가 국내에서 화자 되기전, RIS라는 OS 원격 설치 서비스를 구축 할 때에도 심각하게 고민됐었다... "과연 어느 선까지 사전에 설치 해두는 것이, 유연성과 편의성 두마리 토끼를 다 잡을 수 있을까?"...라는.... 결국 그 당시에는 지금의 Chef나 Puppet만큼 완성도 있는 도구가 없다는 핑계를 대며 일정에 쫓겨 최대한 밀어넣기(?)로 쫑친 기억이....


아무튼 그 중, 가장 어정쩡하게 결론이 난 것이 어떤 방식의 Template를 사용하냐~였다. 이참에 그 사항에 대해 정리를 나름대로 해두고 싶어 일단 펜을...아니 키보드를 두드려 둔다. 물론 서두는 없다. 생각 나는대로.. 우선...


PaaS, SaaS... 당연히 밑바탕이 IaaS라 불리는 가상화 서버스가 "반드시" 필요 한 것은 아니다. 그러나 즉시성, 그리고, 자원의 효율적 활용(이 부분도 아직 갈길이 멀기만 하지만...), 유연한 인프라 관리 체계(이 말도 참 귀에 걸면 귀걸이인 마케팅용...)라는 진부한 이야기들 외에 본 글에서는 오로지 Physical 인프라와 비교해 상대적으로 설치/구축이 쉬운 점을 감안하여 "필수적"이라는 가정하에 이야기를 풀어 볼 생각이다... (물론 이 말에는, 가상화를 위한 Physical 인프라는 이미, 그리고 부족함 없이 구축되어 있다는 대전제가 깔려 있어야....쿨럭..ㅡ.ㅡ;;)


여기서 논점의 주제는 뭐냐.....


1) Pre-Installed Template 방식

; 가상머신 이미지(VDI :: Virtual-Machine Disk Image)에 원하는 서비스와 설정들을 사전에 설치 해두는 것이 유리하냐?


아니면,


2) OS-Only Template 방식

; 가상머신 이미지는 순수 OS만 설치된 이미지를 그대로 사용하고 나머지는 그때 그때, 필요한 서비스들을 동적으로 배포/설치/설정 해주는 것이 유리하냐?


뭐가 좀 더 좋은 선택이냐~ 하는 것....


음.. 경험상 개인마다, 또 환경마다 호불호가 갈렸던 것 같다. 

이후 말하고자 하는 것은... 일반적 또는 보편적으로 봤을때에는 "2) OS-Only Image" 방식을 사용하는 것이 유리하다...라는 것에 대해 이유를 정리 해볼려고 한다... 물론 전혀 현실성 없는 이야기로 보일 수도, 틀린 이야기일 수 도 있는 사견일뿐....



참 Template에 대한 용어 정리 부터 하자...


* 본 글에서 언급되는 "Template"이라 함은, Virtual Machine 생성에 공통적으로 복제/사용되는 Disk 이미지를 말한다. 통상적으로, RedHat/Ubuntu/CentOS/Windows 등과 같은 범용적으로 사용되는 OS레벨까지만 설치되어 있는 Disk Image 파일을 말한다. 


자 그럼, 1)번의 경우, Hadoop이든, Cassandra든 뭐가 됐던, 모든 S/W, 관련 패키지, 라이브러리, 데이타 모두 사전에 각각에 대해 Template이미지를 미리 만들어 두어야 한다. 잘 이해가 안된다고? 아래 [그림1]을 보라.



[그림1]


(그림 설명)

- 가운데 점선은 Template으로부터 사용자에게 배포되는 경계를 나타냄. 일반적으로 Chef/Puppet가 담당.


지원하는 OS는 3종류로 가정한다. SuSe/RedHat/Ubuntu...

그리고, 지원하는 서비스로는 Hadoop/MySQL/Cassandra/Tomcat/HAProxy/Apache/GlusterFS 이정도로 7가지가 서비스할 계획이라고 치자...

 

  • OS플랫폼 : 3가지
  • 서비스 종류: 7가지


따라서, 3*7=21 가지로서, 21개의 Template이미지를 사전에 확보/관리 되고 있어야 한다.

물론 생성 이후에 적용된 고유정보나, 설정은 Chef나 Puppet와 같은 Auto-Configuration 툴을 사용한다는 것을 전제로 한다.


Pre-Installed Template 방식의 장점은 아래와 같다.

(본 글과 연관이 있는 항목 위주)

  • 설치/설정 작업에 필요한 소요시간 제거/단축.
  • 요소 패키지의 버전 Upgrade등으로 인한 설치/설정 중 발생 가능한 오류 제거.
  • 설치/설정 과정을 거친, 즉 작동이 검증된 이미지임을 보장.

위와 같은 이점을 누릴 수 있다. 이중에서도 1)번 방식을 주장하는 사람들이 가장 강하게 내세우는 점은 첫 번째 서비스 배포에 소모되는 "시간단축"이었다.


자, Pre-Installed Template이미지가 가지는 단점이 있겠으나, 아래 내용은 2)번 방식인 "OS-Only Template"방식을 살펴보고 비교해보는 것으로 충분할 것이다.


2번) 방식을 도식화한 [그림2]을 보자.


[그림2]

그림 2는?

Virtual VMs 영역은 "Pre-Installed Template"방식과 다를게 없다. 그러나, 아래 쪽 Template영역은 아주 딸랑 3개로 심플하다.


OS-Only Template 방식의 장점을 정리하면,

  • 확보/관리 되어야할 Template이미지 대상 수가 현저히 적다.
  • Template 이미지에 대한 Version Upgreae, Patch 이슈가 현저히 적다.


오직, 3개만, 그것도 순수 OS레벨까지만 구축되어 있는 Template를 확보하면 된다. 그럼 각각의 서비스들에 대한 설치/설정과 관련된 일들은 어디로 가버린거냐? 당연히 파란점선 부분에 존재하는 Chef/Puppet가 담당하게 된다.


그럼, 단점은?
  • 모든 서비스가 VM생성 요청마다, 설치/설정 작업이 수반되어야 한다.
  • Chef/Puppet의 역할이 매우 중요해진다.
  • 설치/설정이 생성 요청때마다 발생하므로, 당연히 배포완료까지 소요되는 시간이 증가한다.

자, Pre-Installed Template 방식과, OS-Only Template방식을 간략히 살펴 보면 이와 같이 "일장일단"이 있다.


나름 가상화라는 파트를 접하면서 겪어오고 싸우기도 한 이 문제...

결국 논쟁의 핵심은(단, 국내 가상화 일선 현장에서이다.) 아래의 것들 이었다.

  • 배포 소요 시간
  • 관리의 복잡성
  • 배포 실패 가능성


이러한 이유로 인해, 99%는 1)번 Pre-Installed Template 방식을 도입/적용 하는 것으로 가닥이 잡힌다. 설령 그것의 단점을 인지하고 있더라도...(최근에야 Chef나 Puppet의 비중을 높이려는 시도가 많이 보이나 쉽지는 않은듯 하고...)


아무튼, 이것은 단기적으로 봤을때는 충분히 설득력이 있고, 또 실제로 효과도 만점이다.

서비스 로직과 Web-UI연동, 빌링, 요구사항에 부합하는 서비스가 정상적으로 사용가능한지가 단기적인 프로젝트상 Output으로서 중요하지, Provisioning과정에서 생기는 시행착오나, 오류로 시간을 허비할 수는 없는 환경도 한 몫을 하고 있는 것 같다.


그러나 장기적으로 봤을 때, 덮어 두었던 문제들이 일순간 터져버리는 지뢰밭을 키우는 꼴이 될 확률이 대단이 높다.


왜?~~


1) 배포 소요 시간. 이것 부터 살펴 보자...

실제로 Hadoop, Apache, Cassandra 등등이 미리 설치 했을 때에 비해, 그때 그때 Instant하게 설치가 된다면 분명히 시간은 더 걸리겠으나, 과연 얼마나 더 소모될까? 10분? 아니면 1시간?.... 별의 별 S/W를 다 동적 Provisoning해봤지만, 어지간 해서는 3분을 넘기는 Provisioning을 필요로 하는 서비스는 굉장히 드물다....

(여담이지만, 이미지 복사하는데 훨씬 시간이 많이 걸린다... 왜? "Backing-File" 방식을 사용하지 않고, 10GB짜리를 그대로 10GB 통으로 복사를 하니..... 차라리 이런 시간을 줄이는게 훨씬 비용효율적일 것이다.) 


2) 버전 관리의 복잡성

음... 이 문제는 기술적 의견차가 큰것도 있지만, 커뮤니케이션 부족이 한 몫을 한 것 같다.

이 부분을 지적한 사람들이 주로 주장하는 내용이, "apt-get이나, yum등의 버전이 수시로 바뀌고, 관련 conf 패턴도 바뀌어 문제가 많이 발생하더라. 설치 과정도 어렵고 하니 한번만 고생해서 만들어 두면 편하지 않느냐..." 이었다. 음... 틀린 말은 아니다. 그러나 미안한 말이지만, 이 부분은 전적으로 "관리 능력"의 부재로 인한 핑계일 뿐이다.

이유는, 이 이슈를 Pre-Installed Template방식에서는 더 Critical하게 접하게 될 이슈이기 때문인다. 무슨 말인지 이해가 잘 안된다고? 어느 서비스도 마찬가지겠지만, Cloud라는 이름이 붙은 서비스에서 특정 Version으로 Static하게 패키징된 Template으로 1~2년 서비스를 할 수는 있다고 치자. 패치/업그레이드가 다반사로 일어나는 Cloud관련 솔루션들인데, 그렇게 버텼다고 치자. 훗날 업그레이드는 어떻게 수행할 것인가? 안할 것인가? 한다면, 전체 다 할 것인가? 아니면 기존 이미지 27개(앞선 예를 기준)템플릿은 별개로 운영하고, 신버전의 동일 서비스의 Template이미지들을 또 추가하여 54개의 Template으로 운영할 것인가? 그러면 언제부터 사용한 서비스냐에 따라 기술지원 방식이나 메뉴얼, 대응팀 운영을 개별적으로 가져갈 것인가? 문제는 시간이 가면 갈수록 걷잡을 수 없는 악순환에 빠지고 만다.

결국 핵심 이야기는 이것이다. "현재 작은 문제로 인해 발생한 상황을 해결 하지 못하는데, 그 문제들이 누적되고 쌓인 미래의 상황은 해결이 가능할 것인가?" 하는 것이다.


아래 [그림3]을 보면서 이 항목에 대해서는 마무리 하자.

개발에서도 통용되는 오래된 그림이고 이야기이다. 버그나, 이슈에 대한 패치의 양과 주기에 대한 비교 그림이다.

왼쪽그림은 패치 주기가 길고, 한번에 패치하는 버그/이슈의 양이 많다.

반면에, 오른쪽은 패치 주기가 짧고, 버그/이슈의 양도 적다. 그만큼 한번의 패치 작업 때 변경되는 코드 양이 작고, 만에 하나 발생할 잠재위험(Risk)도 작다.

어느 것이 유리한가? 답은 굳이 말하지 않아도 자명할 것이다.


      

[그림3]


3) 배포 실패 가능성.

음.. 이부분은 2)번 "관리의 복잡성"의 내용과 중복되는 부분이 많다.

실제 Pre-Installed Template방식에 비해, OS-Only Template 방식이 가지는 핸디캡이기도 하다. 다시말해 Chef나 Puppet와 같은 Auto-Configuration 툴의 역할과 비중이 증대되어 미션크리티컬한 시스템 수준으로 올라가게 된다. 모든 것을 배포하고, 설정하고, 조율하고, 심지어 모니터링/관제 까지.. 그만큼 Auto-Configuration 시스템의 운영/관리가 철저히 되어야 하고, 만에 하나 장애나 오동작시, 전체 시스템에 어떠한 피해가 올지 모를 양날의 검과 같은 존재다. "잘 쓰면 이롭지만, 잘 못 쓰면 해가 되는..."

이러한 툴들이 수행되는 과정에서 발생 가능한 오류는 S/W버전의 상이함, 배포 로직상의 오류, 툴 자체적인 SPOF구조, 등이 대다수다. 심지어 일부 Network구간 단절로 Configuration 시스템은 멀쩡함에도 배포 실패가 발생할 수 있다. 그러나 이러한 Risk는 Pre-Installed Template방식도 동일하게 내포하고 있는 문제이다. 단지, OS-Only Template방식에 비해, 수행 과정이 적다 보니, 발생 가능성이 상대적으로 낮을 뿐이지... 따라서 이 이슈는 어떤 방식이든 "관리/운영 능력의 문제"일 뿐이다. 고민은 하되 호불호를 따질 필요는 없을 것이다.



정리~


좀더 적합한 것은 존재 하난 정답은 아직인 것 같다. 적어도 국내 일선 현장에서는...

다만, 지극히 개인적으로~ "OS-Only Template"이 보편적인 방식으로 자리 잡기를 희망할 뿐...


장기 이식 의학 분야로 이야기를 빗대어 보자면,


Pre-Installed Template 방식은 간이식, 콩팥이식, 심장이식, 안구이식 등과 같이 특정 장기(Pre-Installed)를 확보하여 이식(배포)하는 방법이라면,


OS-Only Template 방식은, 줄기세포(단순 OS플랫폼)만 있으면, 어떠한 장기나 신체부위도 재생해낼 수 있는 방식이라고 생각하면 쉬울 것 같다. 단, 중간에서 재생(배포)에 필요한 미세하고 정교한 작업을 수행하는 의사(Chef/Puppet류의 툴들)의 뛰어난 역량이 수반되어야 할 것 같다.


"선택은 자유다............."


(여담) 그런데 이이야기를 깡그리 무너뜨릴 수 있는 것은, "왜? 여러 OS플랫폼에 똑같은 서비스를 사용해요? 하나만 정해서 서비스 해요~!!" 라고 하면....ㅡ.ㅡ;;


이상,,, 할 일 없는 일요일 저녁... 머리속에서만 맴돌고 정리가 안되던, 그래서 더욱 주관적인 이야기.... 글로 끄적여도 여전히 만족할만큼 정리는 되지 않았으나, 대충 어렴풋했던 그림도 서너장 나왔고, 앞으로 계속 다음어 나가야 할 글임을 다시금 되뇌이며 오늘은 이만....




(별첨) Chef/Puppet ?????


이러한 Auto-Configuratio툴의... (철학까지는 아니라도) 컨셉에 대해 내 의견과 다른(누가 맞는 건지는 아직 모르니...) 이들이 많아 내 생각도 이참에 간략히 메모해 두고, 경험이 쌓이고 생각이 조금씩 늘어나면 이 것도 수정 보완 해야 할 것 같다.


Chef/Puppet류의 툴들이 말하는 Configuration.......

과거,, 또는 최근 얼마전까지의 Configuration은 아닐 것이다. 다시 말해, "설정"이라는 좁은 의미로 사용된 것이 아닌, "구성"이라는 넓은 의미로 봐야 하는 것이 적절 할 것이다.

"구성"... 특정 머신이나 특정 S/W를 구성하는 것만이 아닌, "Service"에 대한 모든 제반 사항을 "구성"한다고 봐야 한다. 그 목표하는 시스템이 비록 1대일지라도, 혹은 수천대 일지라도.. 둘다 동등한 "구성"이다.. 적어도 Cloud라는 아직까지는 실체가 무엇인지도 명확치 않는 트렌트하에서 Chef/Puppet에서는.... 


저작자표시

'Cloud' 카테고리의 다른 글

[Open] EYWA - Detailed Information  (0) 2014.03.03
AWS OpsWorks에서 Custom Chef Cookbook 사용하기  (0) 2013.10.28
Virtualization - Full vs Para (Appendix Pass-Through : Full vs Para)  (0) 2012.05.13
[PDF] - MIgration Xen to KVM  (0) 2012.05.12
CloudStack 3.0 설치 후기....  (0) 2012.05.06
Posted by 사랑줍는거지
,

CloudStack 3.0 설치 후기....

Cloud 2012. 5. 6. 21:19

후기랄것도 없다...


뭐가 이렇게 간단해??!!!!!!


2.x대의 그 애매모호성이 대폭 없어진 느낌... (물론 Zone이니, Pod니, Cluster, Host 등의 개념을 처음 접하면 역시나 난해함이 있을수도 있겠지만...)


그러나, 결론은 2.x에 비하자면 매우 만족!!!!!!!!!! 장비만 너끈하다면, 1시간이면 뚝딱 IaaS 인프라 구축이 완료될듯...


한마디로 요약하자면, Windows에서 프로그램 설치 하듯... 위자드(설치 마법사) 수준으로 쉬움~~ 강추~~!!


* 설치 메뉴얼은 따로 작성안한다... 왜? CloudStack공식 가이드 문서인 Quick-Installation 문서가 너무 잘 되어 있기때문에~ 굳이~ 사족달 필요 없다....


링크 : Quick Install Guide (English)

http://download.cloud.com/releases/3.0.0/CloudStack3.0QuickInstallGuide.pdf


저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

Virtualization - Full vs Para (Appendix Pass-Through : Full vs Para)  (0) 2012.05.13
[PDF] - MIgration Xen to KVM  (0) 2012.05.12
‎왜!! Citrix는 CloudStack을 Apache재단으로 옮겼나?"  (0) 2012.05.05
CloudStack + SDN  (0) 2012.05.01
Install OpenNebula-2.2-1 with Xen  (0) 2012.03.18
Posted by 사랑줍는거지
,

‎왜!! Citrix는 CloudStack을 Apache재단으로 옮겼나?"

Cloud 2012. 5. 5. 05:01

‎"Why Is Citrix Moving CloudStack to the Apache Foundation?"
"Why Align CloudStack with the AWS APIs?"



원문 : http://gevaperry.typepad.com/main/2012/04/is-citrix-opening-a-three-front-war-with-cloudstack.html





In the Game of Clouds, You Win Or You Die: CloudStack

Citrix is making a big announcement today. It has two parts. First, it's moving its CloudStack framework, which was owned by Citrix and distributed at CloudStack.org through a GPL license, to the Apache Foundation. Second, it is aligning CloudStack withAmazon Web Services' architecture and APIs.

This is big news that's sure to ruffle some feathers in the cloud computing space. So the questions I have are:

  • Why are they doing this?
  • What are the implications?

Why Is Citrix Moving CloudStack to the Apache Foundation?

The move appears straightforward. Citrix acquired CloudStack through its $200 millionacquisition of Cloud.com in July 2011. From what I'm hearing, it has had good success with enterprise and provider adoption of the product, but it was far from being accepted as an industry de facto standard, which is what, I assume, they had hoped for. So it would make sense for them to move it to a respected open source foundation like Apache.

But wait. There was already a OpenStack vying for that de facto standard open source platform status, and Citrix announced its support for it two months before the Cloud.comacquisition. The company said it would continue to support both platforms after the acquisition, so what happened?

Citrix claims that the OpenStack foundation wasn't run well: it was dominated by Rackspace and had a "pay-to-play" model. The result was that the APIs were poorly designed and the product lacked stability and maturity (a claim I have heard from others). At the same time, while OpenStack is getting support from the likes of Cisco and HP, the community is somewhat fragmenting, with multiple distributions and extensions from the likes of startups Cloudscaling and Piston Cloud. This started creating a problem for enterprise customers and providers who were getting confused and having a bad experience with OpenStack.

In the meantime, Citrix is feeling competitive pressure from the company it views as its primary rival for actual customers (as opposed to winning the hearts and minds of the "community"): VMWare.

It simply couldn't wait and had to go on the attack with a bold move. This is it -- and it's a pretty good one.

Why Align CloudStack with the AWS APIs?

The final piece in making CloudStack the de facto standard cloud platform is the API. By aligning with the Amazon APIs, CloudStack gains a hghly-adopted, proven API with a massive ecosystem of integrated tools and services around it. They tell me they will have 100% compatibility by the end of this year.

But the catch is this comes on the heels of Eucalyptus's announcement that it is aligning with the AWS APIs. Eucalyptus, just a reminder, is another open source cloud platform that has been vying for leadership among enterprise customers.

Game of Clouds

With this move complete, Citrix has a production-proven stable product, which is now an open source platform managed by the widely-respected Apache Foundation, using a popular API with a massive ecosystem around it. Pretty clever, I think.

On the other hand, CloudStack is fighting on three fronts now: its traditional arch-enemy VMWare, the OpenStack camp with the dozens of vendors -- large and small -- behind it, and Eucalyptus. A regular game of thrones. And to paraphrase Game of Thrones: In the Game of Clouds, you either win or you die.

저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

[PDF] - MIgration Xen to KVM  (0) 2012.05.12
CloudStack 3.0 설치 후기....  (0) 2012.05.06
CloudStack + SDN  (0) 2012.05.01
Install OpenNebula-2.2-1 with Xen  (0) 2012.03.18
Install - CloudStack CE 2.1.x ManagementComputing Node  (0) 2012.03.18
Posted by 사랑줍는거지
,

CloudStack + SDN

Cloud 2012. 5. 1. 16:43


  • 특징
    • VLAN의 제한을 벗어남 (예: VLAN 개수가 4k 이상 운영 불가 등등)
    • GRE 터널링을 활용해서, L3위에서 L2에 대한 Overlay 네트워크 실현 (IDC간에서도 Network 통합)
      • 기존의 임기응변 격이었던 VPN을 통한 L2 Overlay 네트워크 흉내내던 것에 대한 대안...
    • VLAN개수 제한 대신 테넌트키(Tanant-Key)라는 것을 통해 계정별 트래픽 격리
      • Tanant-Key가 기존의 VLAN에서 VLAN-Tag(ID) 속성에 매칭되는 듯...
  • 걱정거리...
    • GRE 터널링에서 Tanant-Key활용은 분명 기존의 VPN에 비해 복잡성을 많이 제거 했으나, 터널링이라는 것에 의한 속도 문제는....
    • SDN과는 별개의 이야기지만, RouteVM이라는 병목 구간에 대한 개선점은 잘 보이지 않음....


이상, 간략히 훌터본 바로는 이상과 같다... 자세한 것은 실제로 테스트 정도는 해봐야 윤곽이 나올듯...

저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

CloudStack 3.0 설치 후기....  (0) 2012.05.06
‎왜!! Citrix는 CloudStack을 Apache재단으로 옮겼나?"  (0) 2012.05.05
Install OpenNebula-2.2-1 with Xen  (0) 2012.03.18
Install - CloudStack CE 2.1.x ManagementComputing Node  (0) 2012.03.18
CloudStack 2.2.13 with XenServer (on ESXi)  (0) 2012.02.25
Posted by 사랑줍는거지
,

Install - CloudStack CE 2.1.x ManagementComputing Node

Cloud 2012. 3. 18. 00:14

 http://redmine.nehome.net/redmine/projects/cloudstack/wiki/Install_-_CloudStack_CE_21x_ManagementComputing_Node 



[Management Server(CentOS 5.x)]
(JDK install/setting)

hostname is FQDN
Edit /etc/hosts : All node
Setup DNS Server (Option) 
yum -y install mysql-server
sed -i '/^[mysqld]/a innodb_lock_wait_timeout=600' /etc/my.cnf
sed -i '/^[mysqld]/a innodb_rollback_on_timeout=1' /etc/my.cnf
service mysqld start
chkconfig mysqld on
mysqladmin -uroot password '1234'
wget http://download.cloud.com/foss/centos/cloud.repo -O /etc/yum.repos.d/cloud.repo
yum clean all
yum -y install cloud-console-proxy
yum -y install cloud-client
cloud-setup-databases cloud:1234@localhost kvm --deploy-as=root:1234
virsh net-destroy default
rm -f /etc/libvirt/qemu/networks/default.xml
service dnsmasq stop
service libvirtd stop
chkconfig dnsmasq off
chkconfig libvirtd off
cloud-setup-management
reboot

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

[Computing Nnode]

wget http://download.cloud.com/foss/centos/cloud.repo -O /etc/yum.repos.d/cloud.repo
yum clean all
yum -y install cloud-agent
cloud-setup-agent
cloud-setup-agent --no-kvm (not use kvm module)
virsh net-destroy default
rm -f /etc/libvirt/qemu/networks/default.xml
(on CentOS)
#iptables -I INPUT -i cloud0 -j ACCEPT  
#iptables -I FORWARD -i cloud0 -o cloud0 -j ACCEPT  
#iptables -I FORWARD -i cloudbr0 -o cloudbr0 -j ACCEPT 
#iptables -I INPUT -m tcp -p tcp --dport 5900:6100 ?j ACCEPT 
(on Fedora)
#iptables -I FORWARD -i cloudbr0 -o cloudbr0 -j ACCEPT 
#iptables -I INPUT -m tcp -p tcp --dport 5900:6100 ?j ACCEPT
service iptables save
reboot
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

CloudStack + SDN  (0) 2012.05.01
Install OpenNebula-2.2-1 with Xen  (0) 2012.03.18
CloudStack 2.2.13 with XenServer (on ESXi)  (0) 2012.02.25
정말 AWS가 클라우드의 표준(Standard)은 아니잖아~  (0) 2012.02.07
Cloud.... 'Beta'는 없다.  (0) 2012.02.04
Posted by 사랑줍는거지
,

CloudStack 2.2.13 with XenServer (on ESXi)

Cloud 2012. 2. 25. 23:05
CloudStack 2.2.13 가상화 기반에서 테스트 가능하네요... 물론 KVM은 불가... XenServer를 사용한다면 HVM이 필요 없음에도, CloudStack은 HVM을 기본으로 체크해서 Computing Node 등록이 불가했었는데, 이걸 페이크 처리 하는 팁이 CloudStack Knowledge Base에 공개되었네요.. Citrix가 인수 하다보니 그런건지... 작년에 이부분때문에 한동안 이슈가 많이 올라오던데 별 진전이 없더만.... MySQL DB의 configuration테이블에 Advanced 속성 하나를 수작업으로 만들어 주니 되는군요... VMware ESXi에서 확인 했습니다~ 설치 문서는 기존 2.2 퀵인스톨 PDF 대충 참조.....
http://docs.cloud.com/Knowledge_Base/How_to_use_CloudStack_without_Hardware_Virtualization
물리 인프라 때문에 이것저것 테스트에 제약이 많았는데~ 이제 맘놓고 Advanced Networking도 실컷 내맘대로 테스트 해볼 수 있을듯~ 야호~
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

Install OpenNebula-2.2-1 with Xen  (0) 2012.03.18
Install - CloudStack CE 2.1.x ManagementComputing Node  (0) 2012.03.18
정말 AWS가 클라우드의 표준(Standard)은 아니잖아~  (0) 2012.02.07
Cloud.... 'Beta'는 없다.  (0) 2012.02.04
[기고/시트릭스 조동규 부장] 클라우드 자체가 목적지는 아니다  (0) 2012.01.23
Posted by 사랑줍는거지
,

CloudStack 2.2.2 Release -> 2.2.3

Cloud 2011. 3. 17. 16:58
헛........ CloudStack 2.2.2가 릴리즈 되었네요.
가장 눈에 뛰는건 CE 2.1.x에서는 Hypervisior로 KVM만 지원이 되었는데, 2.2부터는 CE(Community Edition)도 XenServer5.6에다가 VMware(vSphere)까지 지원되는 것 같네요!!!!!!!!!!!!!! (+_+) 게다가, Snapshot기능도 활성화 된듯.... CE버전도 이제 좀 구색이 갖춰지는듯.........
전체적인 개념은 2.1.x와 비슷하나, UI가 상당히 바꼈고, SSVM(Secondary Storage VM)이라는 개념이 새로 생긴듯하네요. 이게 뭔지~~ 삽질좀 해봐야 겠습니다. 2.1.x에서는 단순히 Secondary Storage용도로 공유스토리지만 마운트 해주면 끝났는데, 이놈은 이름으로 봤을때, 분명히 VM 인스턴스인데, 이놈이 Secondary에 저장되는 Template이나, Snapshot, ISO등을 관리 해줄것 같은 냄새가 물씬......... 어떤식으로 관리가 될지는......

자세한건 http://cloud.com/ 참고.............
그럼... 설치의 삽질로.........휘리릭.......(업데이트 형태도 지원하는걸로 되있는데, 안된다...ㅜㅡ;;;)
 

-----------------------
(2011-03-18)
설치 하느라 옴팡지게 삽질 했고, 운영해보는 과정에서도 안되고 에러 배터내고 하는게 엄청 많다 싶은 생각이 들더니만, 2.2.2 나온자 몇일 되지도 않았는데, 2.2.3-1이 또 릴리즈 되었네..ㅡㅡ;; 얼마나 급했으면 릴리즈 노트도 없고, 정보도 없이 버전만 덜거러니~ 올랐네... SourceForge상으로 지금부터 3시간전에 올라 온듯....... 에고......... 누가 OpenSource 아니랄까바..............ㅡㅡ;  
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

데스크톱 가상화 : VDI로 도약하기  (0) 2011.11.14
CloudStack 2.2.x - Networking Model 분석  (0) 2011.10.30
클라우드프론티어2011..............  (0) 2011.10.26
(낙서) 자체 전산실 구축에 비해 Cloud(클라우드)가 제공해줄 수 있는 가치는 뭘까.......  (1) 2011.04.04
[웹OS] 10년전 Web OS로 본 한국의 Cloud  (0) 2011.03.10
Posted by 사랑줍는거지
,

[IaaS] - CloudStack CE 2.1.7 설치

Cloud/KVM 2011. 2. 22. 22:04
그간 잊어 먹을까 노심초사..... 메모해둬야지....했던걸 이제서야 정리 한다. 지극히 주관적인 눈높이에, 메모 수준이지만, 안해두는 것보단 나을듯......
(Cloud.com에 공개되어 있는 PDF 설치 문서 내용에 다 있는 내용이다. 해당 문서를 먼저 참조 하길.......)

CloudStack CE......... 꽤 괜찮은 물건이다. WEB-UI는 물론이고 IaaS의 기본적인 환경(물론 제약사항은 있다)을 아주 쉽고 빠르게 구축해준다. 작동 메커니즘에 대한 이해도를 어느정도 쌓는다면, CE(Community Edition)만으로도 중소규모의 IaaS는 거뜬히 소화해낼 수 있을 듯하다. Opennebula의 경우 사용자가 원하는대로 구축해 나갈수 있는 요소들이 많은 반면, CloudStack은 가져다 쓰면 그만이다. 즉, 여러가지 고민하기는 싫고, 웬만한 IaaS 환경은 다 제공되었으면~~ 할 때 쓰기 딱! 좋다. (물론 단점도 있다... 이건 직접 찾아보시길.........)

보다 자세한 CloudStack의 소개나 아키텍쳐등의 정보를 원하면 아래 사이트를 참조하시고(문서들이 PDF로 아주 잘 작성되어 있음), 본 글에서는 CentOS기반(설치 문서도 사이트에 있음)에서 CloudStack CE 설치 과정 요약해둠.

설치는 크게 두 부분으로 나뉘는데, [관리노드], [컴퓨팅노드] 로 구분지음.
(CloudStack CE는 Hypervisior로 KVM만 지원함.) 

사이트 : http://cloud.com


[환경]

- OS
- 관리노드/컴퓨팅노드 : CentOS 5.5 x86_64 (최소 설치)

-  KVM (Kernel based Virtual Machine) 운영이 가능한 H/W
- yum -y groupinstall KVM

- JDK

- MySQL
- innodb 설정 조정함.

- Hostname
- 반드시 FQDN이어야 함. ex) test.foo.com

- DNS를 운영하거나, /etc/hosts 파일을 이용 권장




[설치]

<관리노드>

- 클라우드 노드 관리
/etc/hosts 또는 DNS Server(Option) 

- MySQL 설치
yum -y install mysql-server
sed -i '/^\[mysqld\]/a innodb_lock_wait_timeout=600' /etc/my.cnf
sed -i '/^\[mysqld\]/a innodb_rollback_on_timeout=1' /etc/my.cnf
service mysqld start
chkconfig mysqld on
mysqladmin -uroot password '1234'

- CloudStack CE Yum-Repo 다운로드/설치
wget http://download.cloud.com/foss/centos/cloud.repo -O /etc/yum.repos.d/cloud.repo
yum clean all
yum -y install cloud-console-proxy
yum -y install cloud-client

- 관리노드 DB 생성
cloud-setup-databases cloud:1234@localhost kvm --deploy-as=root:1234

- CloudStack CE에 불필요한 libvirt 관련 기본 기능 Off
virsh net-destroy default
rm -f /etc/libvirt/qemu/networks/default.xml
service dnsmasq stop
chkconfig dnsmasq off

- 관리노드 기본 환경 구성
cloud-setup-management

- 관리 콘솔 구성
cloud-setup-console-proxy

- 관리노드 설치 완료 및 재부팅
reboot

- WEB-UI 접속
http://{관리노드 IP}:8080/client
Default Auth : admin / password

<컴퓨팅노드>
- CloudStack CE Yum-Repo 다운로드/설치
wget http://download.cloud.com/foss/centos/cloud.repo -O /etc/yum.repos.d/cloud.repo
yum clean all
yum -y install cloud-agent
cloud-setup-agent
(cloud-setup-agent --no-kvm (not use kvm module))

- CloudStack CE에 불필요한 libvirt 관련 기본 기능 Off
virsh net-destroy default
rm -f /etc/libvirt/qemu/networks/default.xml
service dnsmasq stop
chkconfig dnsmasq off

- Console-Proxy를 위한 iptables 정책. (/etc/rc.local에 추가)
/sbin/iptables -I INPUT -i cloud0 -j ACCEPT  
/sbin/iptables -I FORWARD -i cloud0 -o cloud0 -j ACCEPT  
/sbin/iptables -I FORWARD -i cloudbr0 -o cloudbr0 -j ACCEPT 
/sbin/iptables -I INPUT -m tcp -p tcp --dport 5900:6100 -j ACCEPT 

- 컴퓨팅노드 설치 완료 및 재부팅
- 재부팅 완료후, 정상적으로 cloud-agent 서비스가 수행되면, 관리노드의 WEB-UI의 Host탭에서 컴퓨팅노드가 보여야 함.

<끝>


* 설치는 매우 간단하지만, 운영에 있어서는 반드시 cloud.com의 PDF문서들은 꼭! 필독!

'Cloud > KVM' 카테고리의 다른 글

Resize qcow2 image  (0) 2013.09.28
KVM/QEMU Guide #1 (Intro & Basic)  (0) 2012.06.22
KVM/QEMU - How to Migration(include LIve)  (0) 2012.05.13
[KVM] CentOS 5.x에서 qcow2 이미지파일 직접 마운트/접근 (with LVM)  (1) 2011.04.01
Posted by 사랑줍는거지
,

티스토리툴바