http://www.datanet.co.kr/news/articleView.html?idxno=58809
"웹하드·ASP 발달한 국내, 퍼블릭 클라우드 성공할까"

이 기사에 대한 개인적인 소감은... "역시,,, 그닥 희망적이진 않군~" 이다. 그래도 국내에서 가장 화끈하게(?) 추진한 KT도 요즘은 별 진전이 없는지 조용~하고... 로컬 클라우드?? 헐... 이건 또 몬 말장난인지... 중요한건 규모... 이전의 방식으론 커버가 안되는 규모다... Amazon이나 Google의 가장큰 무기는 실전에서만 얻을 수 있는 '시행착오'와 '경험치'다.... 책상위에서, 회의실에서 어떻게 가능한 것이 아니다... 흉내만 낼려고 하지 말고 부딧히고, 깨지고, 망가져 봤을 때에만 얻을 수 있는게 있는데... 그러면서 점점 키워 나가야... 클라우드... 'Beta'는 없는것 같다.. 아니 끝까지 'Beta'여야 하지 않을까 싶다... 뭐 지금의 막강한(?) SI구조에서는 꿈같은 이야기겠지만....

Posted by 사랑줍는거지
,

작년 한해를 가장 뜨겁게 달군 IT 키워드는 과연 무엇이었을까요?

그 정답은 아마도 클라우드가 아닐까 생각됩니다가상화와 클라우드정말 한해 동안 폭풍적인 성장과 이를 둘러싼 이슈들로 가득했던 한 해가 아니었나 싶습니다.

 

오늘 이 시간에는 과연 클라우드가 현재까지 올바른 방향으로 흘러가고 있는지 또한 클라우드가 제공하는 진정한 가치는 무엇인가에 대해 생각해 보는 시간을 갖도록 하겠습니다.

 

이를 위해 시트릭스시스템스코리아 클라우드 및 젠서버 부문 조동규 부장의 기고문을 여러분들과 함께 공유하고자 합니다.

 

[기고클라우드 자체가 목적지는 아니다

시트릭스시스템스코리아 조동규 부장

 

대학때 많은 수업을 들었지만 정말 손에 꼽을 정도로 남는 이야기가  가지 있습니다  하나가 교통개론을 배우면서 교수님이 목청을 높여서 이야기 하신 내용이 "누구도 도로를 목적으로 하지 않는다 도로는 어디로 가기 위한 수단이고 얼마나 빨리  갈수 있느냐가 중요한 잣대이지 도로 자체가 목적인 사람은 아무도 없다라는 내용을 배웠습니다 사용자가 목적지에 다다를  있도록 도와주는 도구라는 것입니다생각해보면 도로공사나 도로 자체에 관심이 많지 누구도 도로에 관심이 많지는 않습니다도로로 인한 기대 효과를 생각하지 도로 자체가 목적인 사람은 없기 때문입니다.

 

현재 돌아가는 클라우드를 보면 마치 클라우드 자체가 무슨  대단한 비지니스 성공의 잣대인 것처럼  목소리를 높이고 있는 실정이 마치 목적을 상실한  도로를 방황하는 것과 비슷한 상황이 아닌가 생각해 봅니다

 

그렇다면 클라우드를 제대로 구축하고 활용하려면 어떤 점들이 고려 되어야 할까요?

 

1. 클라우드 인프라 구축을 위한 분명한 목표가 있어야 한다

마치 도로를 만들기 위해서는 도로가 필요한 이유와 향후 주변 도시간의 인구성장인구이동도시 소득 등 뒷받침이 되야 도로 계획설계 그리고 구축에 들어갑니다클라우드 역시도 비지니스에 부합하는 그리고 향후 회사의 비지니스를 가능하게 하는 도구로서 분명한 목표와 방향이 있어야 합니다그냥 현재의 이슈를 풀어볼까또는 비용이 절약 된다는데등등의 지엽적이고 작은 부분들로 클라우드를 생각하면 오히려 빈대잡으려고 초가산간  태우는 상황이 발생하게 됩니다분명히  클라우드 아니면 안 되는가에 대한 명확한 이유와 비지니스 목표가 있어야 합니다.

 

2. ROI 대한 명확하되 유연한 규정이 필요하다

가상화 까지는 대부분 ROI 분명합니다상면을 줄이고 노후서버를 재활용하고 전력을 줄이는 등의 비교적 명확한 ROI 나오면서 가상화를 일부 또는 전면 도입하고 운영하는 수준까지는 그리 어렵지 않은 거 같습니다다만 클라우드로 넘어가게 되면 빌링미터링자원관리자동화빠른 서비스 지원 등등 가상화 보다 진전된 수준의 서비스 등은 모두 업무 프로세스나 비지니스를 좀더 명확하게 하는 부분이라 일반적인 ROI 잣대를 대기보다는 실제로 얻어지는 개선에 대한 내부 동의가 필요하고 특별히  클라우드 여야 하는 부분이 결정권자와 실무자간의 강한 동의가 있어야 성공할  있습니다.

 

3. 걸음마 부터 차근차근

여러 고객 분들을 만나면서 가장 아쉬운  중에 하나가 시간의 개념이 상대적으로 약하다는 것입니다클라우드는 마케팅적으로도 훌륭한 도구임에는 분명하지만 기술적으로는 그리 쉽지만은 않으면 실제로 구현해서 비지니스와 결합된 형태의 서비스로 정착되기 까지는 상당히 오랜 시간이 걸리게 됩니다물론 가상화를 대규모로 운영해본 경험이 있다면 이러한 시행착오 시간들을 줄여줄 수는 있겠지만 가상화+클라우드를 동시에 진행한다는 것은 실로 어려운 것이 현실입니다 걸음마를 제대로 하기 전에 뛰는 것과 마찬가지로 매우 위험하고 실패할 가능성이 농후 합니다따라서 급하더라도 가상화에 대한 충분한 노하우와 안정화 시간이 필요하며 가상화 프로젝트와 클라우드 프로젝트를 같이 하기 보다는 별로도 검토해서 진행하는 것이 좋다고 생각합니다.

 

4. 시간의 중요성을 생각해야 한다

최근 들어 오픈소스소프트웨어(OSS : Open Source Software) 대한 인기가 급등하면서 여러 개발자 커뮤니티들이 활 황기에 있습니다기업들도 비싼 상용보다는 내부적으로 오픈소스를 지원하고 활용하는 형태로 발전을 해나가고 있습니다주의 해야 할 것은 향후 관련 분야의 기술습득이나 개발에 대한 명분은 있지만 자칫 기술소유에만 몰두 하다 보면 실제로 비지니스에서 필요한 기능이나 요구사항을 제때 반영하지 못하는 경우도 생길  있습니다클라우드 분야는 아직 관련 개발자나 전문가가 부족하기 때문에 실제로 광범위한 프로젝트를 하다 보면 상당한 인력난에 부딪치게 됩니다비지니스는 시간의 개념이 매우 중요합니다언제 제품과 서비스를 출시하느냐 얼마의 인원이 어느 시간 동안 투입을 하느냐 개발 또는 외부 지원을 받을 때  비용의 함수관계를  따져야 하며 단순히 오픈소스가 도입비용이 저렴하거나 개발 또는 일부 개발을 기술을 내재화 하겠다는 것이 너무 우선시되어 적시에 시장에 진출하지 못함에 따라 아예 비지니스 기회를 잃어 버릴 수도 있습니다내부 인력과 또는 외부 인력 그리고 이에 따른 개발 시간의 관계를  검토 해야 합니다.

 

5. 선택과 집중이 필요하다

위의 내용과도 비슷하지만 클라우드는 단순한 한두 가지의 기술이 아닌 여러 기술들의 복합체이며 이러한 기술들이 단순히 IT 연계된 것이 아니라 회사 내부의 프로세스와도 연동이 되어 있습니다클라우드 인프라를 구성하는 솔루션들이 요즘 계속 발전하고 쉽게 되어 있어서 간단하게 구성하는 것은 그리 어렵지 않습니다마치 클라우드가 고속도로라면 고속도로를 쭈욱 구축하는 것은 문제가 아니나 정작 고속도로에 접근하기 위한 톨게이트요금정산주변도로신호체계구호체계 등등도 역시도 같이 구비가 되어야 합니다 역시도 상당한 시간과 비용이 들어가는 작업이며 오히려 주변 부속도로나 장치들은 외부 벤더가 개발하는데 한계가 있고 내부 프로세스를 모르기 때문에 대부분이 고객사에서 준비하고 개발합니다그러다 보니 정작 주객이 전도되어 클라우드 솔루션을 설치는 했는데  이상 진보가  되는 경우도 상당히 많습니다기술의 문제가 아니라 실제로 회사 프로세스와 연동돼서 운영을 하려다 보니 발생되는 문제 입니다시간과 비용과 인력의 선택과 집중이 어느 프로젝트 보다 중요한 상황입니다.

 

도입에 말씀 드린 것처럼 클라우드는 마치 도로와 같습니다도로를 만드는 것도 중요하지만 실제로 도로가 제대로  구실을 하려면 도로의 목적이 분명해야 하며 차근차근 그러나 느리지 않게 하되 선택과 집중을 통해서 목표한 바를 이루어야 합니다실제로 지방에 수천억을 쓰고도 제대로 사용 못하는 공항들을 보면 구축이 목적이 아니라 비즈니스 니즈에 정확히 부합해야 하며 제대로 쓰기 위한부속시설이나 내부 프로세스와 연동하기 위한 개발 부분도 간과해서는  되는 부분입니다

 

클라우드는 기존의 IT문제를 해결하고  나아가 기업의 비지니스를 가능하게 하는 역할을 수행합니다최근 들어 여러 기업들이 클라우드 구축에 몰두할 정도로 인기이지만 자칫 기업의 실패를 가져올 정도로  책임도 막중해 지면서 좀더 신중하자는 의견들도 나오고 있습니다그렇기에 좀더 비지니스 중심적이면서도  클라우드를 해야 하는지를 명확히 해야 성공적인 클라우드가 되지 않을까 합니다.


http://m.blog.naver.com/citrixblog/90133552072
Posted by 사랑줍는거지
,
http://www.itworld.co.kr/techlibrary/72742


서버 가상화 : 비용, 트렌드 등에 관한 전문가 개요

2011.11.21

가상화 전략을 성공으로 이끌려면IT 전문가는 필요한 재해복구 작업뿐만 아니라 관련된 소프트웨어 비용과 하드웨어 비용을 모두 포괄적으로 이해하고 있어야 합니다. SearchServerVirtualization.com과Dell이 제공하는 본 전문가E-Guide에서는 가상화와 관련된 비용 개요를 제공하고, 2010년 예상 가상 서버 트렌드를 설명하고 있습니다. 가상화와 관련된 유형 비용(Tangible Cost)에 대한 통찰력을 얻고 변화하는 서버 가상화 시장의 흐름에 발맞추는 방법에 대해 알아보십시오. 그리고 귀사에서 가상 하드웨어 플랫폼이 담당하게 될 중추적 역할에 대해 살펴보십시오.
 
주요 내용
가상화 비용에 포함되는 소프트웨어, 하드웨어 및 인건 비용
2010년부터 진화하게 될 가상 재해복구
가상 하드웨어 플랫폼 설명
Dell과Intel의 리소스

 
Posted by 사랑줍는거지
,

데스크톱 가상화 : VDI로 도약하기

2010.10.12

우아하며 쉽게 관리할 수 있는 데스크톱 인프라에 대한 유토피아적인 비전은 데스크톱 시대의 개막과 함께 IT 주위를 맴돌아 왔다. 히드라와 같은 데스크톱을 길들이기 위한 시도는 많았으나, 어느 것도 보편적인 솔루션은 제공하지 못해왔다. 마이크로소프트 터미널 서비스(Terminal Service), 시트릭스 젠앱(XenApp)을 비롯한 수많은 기업들이 나름대로의 시장은 확보했으나, 데스크톱 구원에 대한 탐구는 계속되고 있다.

 

가장 최근의 유망주  : VDI

단순하게 말하면, VDI(Virtual Desktop Infrastructure)는 하이퍼바이저 상에서 구동하는 사용자당 한 개의 데스크톱 가상머신에 지나지 않는다. 서버 가상화와 마찬가지로, 각 데스크톱 가상머신에는 RAM, 디스크, 그리고 입출력 자원이 할당되고, 운영체제 전체 설치본은 가상 디스크에 저장된다.

 

사용자는 마이크로소프트의 RDP(Remote Desktop Protocol)나 시트릭스의 ICA(Independent Computing Architecture) 같은 원격 디스플레이 프로토콜을 사용해서 데스크톱 가상머신과 상호작용한다. 클라이언트는 대개 디스크가 없는 저성능 씬 클라이언트 시스템으로, VDI 인프라에 연결하는 것 외에는 하는 것이 거의 없거나 어떤 작업도 하지 않는다.

 

VDI를 비롯한 다른 서버 기반 데스크톱 컴퓨팅 솔루션의 결과, 핵심 기능성, 그리고 모든 소중한 기업 데이터가 수 많은 칸막이 사무실이나 몇 Km나 떨어져 있는 원격지 사이트에 멀리 그리고 폭넓게 퍼져있는 것이 아니라 데이터센터 내부에 들어가게 되었다.

 

데스크톱을 중앙 집중화시킴으로써, 관리와 보안이 간단해졌고 결함 있는 전원 공급장치, 하드 드라이브 등의 교체 같은 기본적인 데스크톱 유지보수 필요성이 없어졌다. 전력 소비도 감소되었고, 어떤 경우에는 모든 팻(Fat) 클라이언트 시스템과 250와트의 전원 공급장치를 제거한 덕분에 밀집된 사무실 공간의 냉각 비용이 급격하게 줄었다. 긍정적인 면이 상당하다.

 

VDI 세부사항에 숨어있는 골칫거리들

하지만, VDI에도 확실히 단점이 있다. 이런 문제 중 몇 가지는 다른 서버 기반 데스크톱 컴퓨팅 솔루션에서 찾아볼 수 있으며 VDI 구현에도 영향을 준다.

 

그 중에서도 가장 중요한 문제부터 살펴보기로 하자.

 

사용자의 수용도와 전반적인 성능. 각각의 VDI 인스턴스(Instance)는 문서 작성, 이메일 작성, 또는 스프레드시트 공식 실행 같은 상대적으로 평범한 작업을 수행할 때는 빠르고 뭐든지 척척 해내지만, 플래시 애플리케이션, 비디오, 또는 다른 멀티미디어 애플리케이션 같은 리치 콘텐츠와 맞닥뜨리면 상당히 영향을 받을 수 있다. 이는 대체로 VM의 성능보다는 데스크톱 디스플레이 전송 프로토콜 때문이지만, 바로 그 점 때문에 문제 해결이 더 어려워졌다. 사용자 수용도는 아주 공개적인 문제가 생길 수 있으며, 이 문제가 발생하면 어떤 대형 프로젝트라도 종말을 고하는 경우가 많다.

 

이 문제에 대한 솔루션은 비용이 많이 들 수 있다. 몇몇 공급업체는 서버와 클라이언트 측의 노력을 결합해서 디스플레이 프로토콜과 함께 오디오와 비디오 스트림을 전송하여, 클라이언트 단에서 일치시키고 클라이언트의 처리 능력을 사용해서 비디오를 렌더링(Rendering)한다. 그 결과 훨씬 더 깔끔한 재생을 할 수 있으나, 늘어난 작업부하를 처리하기 위해서 더 강력하고 비싼 씬 클라이언트가 필요하다.

 

그런 솔루션은 표준 비디오 재생에 대해서는 잘 동작하지만, 플래시 비디오나 플래시 애플리케이션과는 문제가 남아있다. VDI나 표준 RDP 프로토콜을 사용하고 있는 다른 서버 기반 데스크톱 컴퓨팅 솔루션의 성능을 테스트하기는 쉽다. 그저 마이크로소프트 RDC(Remote Desktop Connection: 원격 데스크톱 연결) 클라이언트를 사용해서 서버나 데스크톱 시스템 연결한 다음에, 유튜브를 보기만 하면 된다.

 

100Mbps 이상의 LAN을 사용하고 있다면 재생이 상당히 잘 되겠지만, 그 이하에서는 한마디로 그럴 가능성이 없다. 일반적으로 말해서, RDP 접속을 경유해서 비디오를 보기 위해서는 3.5Mbps의 지속적인 대역폭이 필요하다.

 

대역폭에 대한 우려는 WAN 회선(높은 지연편차 및 낮은 대역폭이라는 고전적인 시나리오)을 통한 데스크톱 세션 제공 같은 어떤 형태의 서버 기반 데스크톱 컴퓨팅에 대해서도 문제를 일으킬 것이다. USB 기기에 대한 인쇄와 적절한 매핑(Mapping)도 문제가 많다. 이런 문제는 도구와 예산을 제대로 조합하기만 하면 정리할 수 있고, VID 고유의 문제도 아니지만 VDI 계획 단계에서는 고민할 필요가 있다.

 

VDI 고유의 문제 : 스토리지

다른 문제들은 전적으로 VDI 고유의 문제이다. 가장 중요한 첫 번째 문제는 스토리지 요구조건이다. 몇몇 VDI 실행 환경은 다른 VM과 마찬가지로 모든 데스크톱 시스템이 반드시 가상 디스크를 가질 것을 필요로 하고 있다. 데스크톱 가상머신당 8GB나 10GB를 고려하고 있다면, 이를 예상 VDI 사용자 수로 곱하면, 곧 바로 스토리지가 고가의 문제가 돼버린다.

 

또한, 각각의 가상머신은 다른 데스크톱 시스템처럼 개별적으로 관리되어야만 하는 섬이므로, VDI는 데스크톱 소프트웨어 관리 요구조건을 줄여주기 위해서 거의 하는 일이 없다는 사실도 명심하기 바란다. 이는 업데이트를 배포하고, 소프트웨어를 설치하거나, 변경을 하기 위해서는 서드파티 툴을 사용해야 함을 의미한다.

 

그리고 그 다음에는 가격도 문제다. 한편으로는, VDI가 기존 가상화 인프라를 활용하므로, 다른 서버 기반 데스크톱 솔루션보다 초기 하드웨어 비용을 더 낮춰줄 가능성도 있어 보인다. 하지만, 일단 VDI에 필수적인 여러 단계의 소프트웨어 라이선싱 계층을 하나하나 벗겨나가다 보면, 결국에는 마찬가지라는 사실을 알게 될 것이다.

 

선택한 솔루션에 따라서, ROI는 이미 저 멀리 가버린 상태에서 기존의 팻 데스크톱 클라이언트 시스템 보다 더 많은 비용을 데스크톱 VM별로 지불하게 되고 말 수도 있다. 어떤 형태의 VDI이건, 뛰어들기 전에 이 모든 숫자들을 계산해 보는 것이 극히 중요하다. 씬 클라이언트 비용, 구현 비용, 라이센싱, 그리고 기존 가상 인프라의 확장 비용들을 감안하라.

 

VDI 대 터미널 서비스

VDI와 기존의 마이크로소프트 터미널 서비스 간에는 명확한 평행선을 그을 수 있다. 이 두 가지는 다수의 데스크톱 세션을 한 대의 서버나 서버 세트 상에 둘 수 있으며 세션을 동일한 씬 클라이언트에게 전달하기 위해서 같은 프로토콜을 사용한다. 두 가지 모두 중앙집중형 관리 도구를 제공한다. 하지만, 유사성은 거기까지다.

 

터미널 서비스 환경에서는 서버에 대한 모든 사용자 세션을 서버 운영체제에 둔다. 이는 윈도우 서버 2003이나 윈도우 서버 2008에 대한 한 개의 인스턴스만이 베어 메탈(Bare-metal) 서버에 설치되고, 모든 사용자가 해당 서버 인스턴스에 로그인 한다. 개개 사용자 세션은 자체 데스크톱이 있는 것처럼 표시되지만, 해당 특정 서버 상에서 다른 모든 세션들과 함께 구동한다.

 

이 시나리오의 이점은 확장성에 있다. 일반적으로 말해서, 물론 애플리케이션 세트에 따라서 다르기는 하겠지만 아마도 한 대의 물리적인 서버에 VDI 세션보다 더 많은 수의 터미널 서버 세션을 밀어 넣을 수 있을 것이다. 한편, VDI 환경에서는 간단하게 데스크톱 가상머신의 자원을 정의하기만 하면, 어떤 사용자 세션의 자원에 대해서도 신속하고 확실한 제한을 둘 수 있다.

 

VDI 실행 환경에서는 서버가 전체 운영체제가 아니라 하이퍼바이저를 구동하고 있으며, 몇 개의 데스크톱 가상머신을 호스팅하고 있다. 그 결과, 각 방법이 여러 개의 데스크톱 세션을 동일한 서버에 두기는 하지만, 그런 세션들의 관리성은 크게 다르다.

 

예를 들어, 터미널 서비스에서는 가상머신을 스냅샷(Snapshot)하듯이 세션을 스냅샷할 수 있는 방법이 없으며, 활성 세션을 한 서버에서 다른 서버로 이전시킬 수 있는 방법도 전혀 없다. 이는 유지보수를 위해서 해당 서버를 다운시키기 위해서는, 모든 사용자가 반드시 로그오프 해야만 함을 의미한다.

 

관리성에서 확연한 차이 보이는 VDI

VDI에서는 해당 서버 성의 모든 활성 데스크톱 세션을 서버 팜의 다른 서버로 중단 없이 이전시킬 수 있다. 통상 이 모든 VM을 호스팅 하는 서버는 누구도 알아차리지 못하게 유지보수를 위해 다운시킬 수 있다.

 

실제로, 어떤 고급 가상화 인프라에 대해서도, 단 한 개의 애플리케이션을 오프라인으로 만들거나 단 한 명의 사용자도 방해하지 않은 채, 전체 물리 서버 기반 구조를 완전히 재구축할 수도 있다.

 

더 나가서, 제대로 구현된 VDI 솔루션에서는 부하 분산도 기본적으로 제공된다. 한 개 이상의 데스크톱 VM이 한 호스트 시스템 상의 자원을 많이 사용하고 있다면, 그 시스템의 다른 VM들을 순식간에 다른 물리 호스트로 이전해서, 모든 데스크톱이 돌아가기 위해서 충분한 자원을 확실하게 가질 수 있게 할 수 있다. 기존 터미널 서버 환경에서는 이것이 불가능하다. 한 개의 대형 사용자 세션이 어떤 자동 해결 방안도 없이 동일 서버 상의 다른 세션에 부정적인 영향을 줄 수 있다.

 

하지만, 터미널 서비스도 한 가지 커다란 관리 상의 장점이 있다. 호스트 서버에 대한 변경 사항을 모든 사용자 세션에서 사용할 수 있다. 애플리케이션 설치가 상당히 간단해지고 글로벌한 수정 작업도 상대적으로 쉽다.

 

VDI에서는 항상 그렇지는 못하다. 데스크톱 가상머신의 배포 방식에 따라, 업데이트나 변경을 위해서 각각을 일일이 수작업으로 해야만 하거나, 서드파티 관리 도구를 사용하거나,  또는 데스크톱 가상머신 템플릿을 작동시켜서 수정 작업을 한 다음에, 템플릿을 저장해야 할 필요가 있을 수 있다. 마스터 템플릿에 연결된 데스크톱 가상머신은 사용자가 다음에 로그인할 때 변경 사항이 반영된다.

 

그렇기는 하지만, 터미널 서비스에 비해 VID의 애플리케이션 처리는 커다란 장점 중 한가지로 작용한다. 많은 애플리케이션이 터미널 서비스 환경에서는 동작을 무조건 거부한다. 다른 애플리케이션은 제한된 기능만을 제공하거나 터미널 서버 환경에서는 해당 애플리케이션 공급업체의 지원을 받지 못할 수도 있다. 이는 어떤 터미널 서버 기반의 인프라에서도 실질적인 문제로 대두되고 있지만, VDI에서는 문제가 아니다.

 

VDI는 사용자 별로 한 개의 전용 데스크톱 인스턴스를 구현해서, 운영체제 수준에서 실제 데스크톱과 분간할 수 없다. 팻 클라이언트 상에서 구동되는 어떤 애플리케이션도 VDI VM 상에서 구동된다 (비디오나 그래픽 성능에 대해서는 약간의 예외를 두고). 바로 이것이 일부 조직이 터미널 서버 대신에 VDI를 밀고 있는 중요한 이유이다.

원문 : http://itworld.co.kr/news/62797/%EB%8D%B0%EC%8A%A4%ED%81%AC%ED%86%B1+%EA%B0%80%EC%83%81%ED%99%94+:+VDI%EB%A1%9C+%EB%8F%84%EC%95%BD%ED%95%98%EA%B8%B0 

Posted by 사랑줍는거지
,
from : http://redmine.nehome.net/redmine/projects/cloudstack/wiki/CloudStack_22x_-_Networking_Model_%EB%B6%84%EC%84%9D


CloudStack 2.2.x - Networking Model 분석 (1차)

Reference : 첨부파일

Account??? Guset???

  • Account???
    - i.g) 팀 조직.
    
    - Virtual-Network 모드에서 RouteVM 단위. 즉 RouteVM을 포함해, 그 밑에 전체 Instance들이 존재. 또는 Direct-Network모드에서는 단순히 Instances 전체.
    
  • User (하기에 나오는 Guest도 같은 의미인듯 하나, 확실치는 않음).
    - i.g) 팀내 팀원.
    
    - Virtual-Network이든 Direct-Network이든, 그 Account("팀")내에서 다시, 일부 VM들에 대해 권한을 가진 사용자.
    

Networking 모델 카테고리

  • Basic
    - use untagged VLAN (Not support Isolation)
    
  • Advanced-Virtual
    - Use VLANs for Isolation
    
    - Use RouteVM
    
    - VPN Available
    
    - LoadBalancer Available
    
    - 1:1 NAT Available
    
    - Public IP Required
    
    - Metering Available
    
  • Advanced-Direct
    - Use VLANs for Isolation
    

VLAN with Advanced Mode

3-type VLANs

  • Public VLAN
    - Public IP들을 위해 예약된 VLAN ID범위.
    
    - Zone내의 모든 Pod들에 걸쳐 Trunking.
    
    - RouteVM들에 개별적으로 할당되는 VLAN으로 예상.
    (Zone VLAN에 이미 격리되어 있던Instance들에서 발생되는 패킷중 NAT되는 패킷에 대한 격리 모델인듯...)
    
  • Zone VLAN
    - Guest(Account)들의 가상네트워크를 위해 예약된 VLAN ID범위.
    
    - Zone내의 모든 Pod들에 걸쳐 Trunking.
    
    - Instances(VM)이 운영중인 Guest의 가상네트워크 마다 1개의 VLAN ID가 할당.
    
  • Direct VLAN
    - Direct(tagged) 네트워크를 위해 예약된 VLAN ID범위.
    
    - VLAN 설정시 Scope에 따라 아래 2가지중 선택. (일반적으로 대부분 Zone-Wide가 권장됨.)
    
        1. Zone-Wide : 모든 Account가 이용 가능.
    
        2. Account-Specific : 하나의 Account만 이용 가능.
    
    - Zone내의 모든 Pod들에 걸쳐 Trunking.
    
    - 관리자가 필요시 제공.
    
    - Zone-VLANs 처럼 관리를 위해, CloudStack에게 별도로 범위는 사전 부여하지 않음.
    

Physical-Host & Physical-Storage

  • Untagged & Private-Network 영역에 위치.
  • 각각의 Pod에 있는 Untagged & Private-Network는 Unique VLAN이어야 하고, L3 스위치에 존재하는(Routing가능한) IP 범위에 속해야 한다.

CloudStack VLAN 범위 예약 내역

  • VLAN ID는 4094(?)으로 제한된 자원.
  • 적절히 용도와 용량에 맞게 CloudStakc에서는 Network모델에 따라 적절한 범위를 권고함.
  • VLAN을 사용자하지 않는 Basic모드에서는 해당사항이 없고, 오직 Advanced-Virtual/Advanced-Direct에서만 해당.

VLAN for Advanced Virtual Networking

  • Zone 레벨에서 하나의 Guest에게 필요한 VLAN
    (다소 애매한 부분... Account아이디 단위로 하위의 모든 Guest User들을 통합해 하나의 VLAN이 할당되는 것인지, 아니면, 그 Guest User마다 또 개별적으로 VLAN을 부여하는 것인지는... 현재로서는 전자 내용으로 판단됨...)
VLAN IDs Use
< 500 관리목적으로 예약되어 있고, 개별 Pod들을 위한 Untagged & Private-Network 영역.
500 ~ 599 Public VLANs
600 ~ 999 Zone VLANs
> 1000 별도 예약

VLAN for Advanced Direct-Tagged Networking

  • Direct(Public IP가 Instance에 직접 할당)이므로 RouteVM존재가 없다. 당연히 Public VLAN 역시 필요 없다.
VLAN IDs Use
< 300 관리목적으로 예약되어 있고, 개별 Pod들을 위한 Untagged & Private-Network 영역.
300 ~ 499 Direct Attached VLANs
> 500 별도 예약(상기 Virtual-Networkin이용시 해당 VLAN영역이 포함.)

VLAN for Virtual Networking & Direct-Tagged Networking

  • 상기 두가지 모델의 혼합 형태이다. 즉, 둘다 하나의 Zone에서 혼용할때 VLAN영역 분할 권장 테이블.
  • VLAN 영역이 달라지지 않는다. 애초부터 혼합을 염두해고, 앞선 두 모델에서 서로의 영역을 벗어나 권장하고 있으므로...
  • 그냥 Advanced타입의 두 모델 Virtual Networking, Direct-Tagged Networking을 합친 것...
VLAN IDs Use
< 300 관리목적으로 예약되어 있고, 개별 Pod들을 위한 Untagged & Private-Network 영역.
300 ~ 499 Direct Attached VLANs
500 ~ 599 Public VLANs
600 ~ 999 Zone VLANs
> 1000 별도 예약

IP Address 할당 체계

  • 여러가지 방식의 IP 할당 체계 제공.
  • 어떤 방식 필요한지는, 어떤 Networking 모델(상기 3개 중..)이 사용중이냐에 따라 달라짐.

Public-IP

  • Advanced 모델(엄밀히 Virtual-Networking)에서는, 기본적으로 Account당 1개의 Public IP가 제공됨.
  • 이 Public-IP는 RouteVM이 가지고, 하부에서 사설IP(Guest-CIDR)를 가진 Instance들에 대한 NAT역할 수행.
  • 필요시, Guest(Account내의 User??)는, Public-IP를 추가/할당 할 수 있다.
  • 관리자는 사전에 Public IP 범위를 지정해 두어야 한다.
  • 프라이빗클라우드 환경하에서는, Public-IP로 RFC1918 address를 사용할 수도 있다.

Private-IP

  • Pod에 존재하는 Host들에 할당되는 IP. (관리용도의 접근만 가능하면 됨.)
  • 일반적으로 RFC1918 주소들이 사용됨.
  • Console-Proxy와 Secondary-Storage-VM들 역시, 이 Private-IP가 할당.(Pod들의 CIDR내에 위치.)
  • 관리자는 Pod내의 System(Host)들을 위해 사전에 준비/설정.
  • KVM/XenServer기반에서는, Pod당 요구되는 Private-IP들의 주소 개수는 호스트당 1개.
  • 즉 Pod당 Private-IP대역(서로 다른?? 같아도 되는지는..)이 필요하고, Pod내의 Host에는 1개씩의 IP가 소요됨.
  • Pod규모의 증설 상황을 고려해, 가능한 충분히 많은 여유 Pirvate-IP를 Pod마다 확보가 유리.
  • Advanced Virtual-Networking 모델에서, Private-IP들의 필요 개수는 해당 Pod내에서 구동되어지는 Hypervisor가 무엇이냐에 따라 달라진다.
    [on Advanced Virtual-Networking]
    
    - KVM/XenServer의 경우, 이론적으로 65,000개 이상으로 IP Block으로 사용이 가능.(즉, 이론적으로는 1개의 Pod내에 65000개 이상의 Host구축이 가능하다는 의미로 보임.)
    
    - 이와는 대조적으로 VMware ESXI의 경우, 특유의 지정된 Subneting구조로 인해, 하나의 Pod내에서 단지 255개의 Pirvate-IP만 제공된다.(VMware관련된 추가 내용은 문서 참조)
    
    - 요약하자면, Pod의 규모는 시간이 지남에 따라 증가할텐데, 이에 맞춰 Host추가를 위한 충분한 IP할당이 가능한 것이 유리.
    
    - i.g)이유는 Guest들의 Virtual Route(RouteVM)들의 적정한 분산이 필요하기 때문. 만일 어느시점부터 Pod내 Account가 증가하여 하나의 Host에 다수의 RouteVM이 배치될 수 밖에 없는 상황이 발생할 수도 있다.. 그렇게 되면???
    

Direct-IP

  • Basic 모드에서는, Pod의 CIDR범위 내의 IP가 Instance에 직접 할당.
  • 사전에 관리자에 의해 가용 Direct-IP 범위가 지정되어 있어야 한다.
  • Host의 Untagged VLAN과 같은 영역에 포함.
  • 즉, Instance와 Host는 동일 레벨의 IP를 사용하고 동일 VLAN에 속함.
  • Advanced 모델중, Direct-Tagged 모드에서는 VLAN-ID와 IP범위 그리고 Gateway가 정의되고, 그 이후, 임의의 IP가 Instance에 직접 할당.

Guest-IP (on Advanced Virtual-Networking)

  • Virtual-Networkin 모델하에서, Instance들에 할당되는 IP.
  • 관리자에 의해 사전에 [Global Configuration]에서 CIDR 지정/설정.
  • ClouStack에서는 보통 일반적으로, 10.0.0.0/24 를 사용함.
  • Account별로 동일 적용되는 IP. 즉, "A" Account내에서도 10.0.0.0/24내에서 VM들의 IP가 주어지고, 동일 Pod이더라도 "B" Account에서도 10.0.0.0/24내에서 VM들의 IP가 주어진다. 앞서 살펴 본대로 VLAN으로, 또 RouteVM내의 NAT/iptables으로 Isolation되므로 가능.
  • VM의 IP할당 주체는 RouteVM이다. (DHCP서버 기능 담당.)

Layer-3 Switch

  • 가용 Zone레벨에서 L3 스위치는 Core 스위칭 레이어.
  • L3 스위치는 하기와 같은 내용으로 미리 프로그램되어 있어야 한다.
    - Direct-Tagged 또는, Virtual-Networking 모델(혼용 모델 제외)이라면, L3 스위치는 Pod단위에서 Public-VLANs, Zone-VLANs, Direct-Attached-VLANs 에 대해 Trunk 설정.
    
    - L3 스위치는 Untagged & Private-Network(Host와 SSVM, Console-Proxy)에 대한 Gateway기능을 담당하게 설정.
    
    - 개별 Pirvate-IP 범위에 대한 분리된 VLAN은 L3 스위치에서 생성.
    
    - (Note) Direct-Tagged & Virtual-Networking의 혼용 모델에서, VLAN은 본 내용과 아래 [Layer-2 Switch]섹션 내용을 참고해, L2/L3 스위치에서 적절히 설정해야 함.
    

Layer-2 Switch

  • L2스위치는 Pod내부에서의 Acceess switching 담당.
  • Pod내에 존재하는 모든 Computing(Host)들에 대해 Public-VLANs, Zone-VLANs, Direct-Attached-VLANs 에 대해 Trunk 설정.
  • Computing(Host)과 StorageVM(SSVM)을 포함한 Private-IP Networking을 위해 Untagged 트래픽에 대한 Switch 가능하도록 설정.
  • 앞서 이야기된 L3 스위치는 Private-IP Networking의 Gateway역할을 제공.

END

  • 첨부파일을 참조 해서 미천한 네트워크 지식으로 일단 요약 정리한 것이라, 오류나 잘못된 부분 댓글 피드백 바람....
Posted by 사랑줍는거지
,
얼마전 클라우드 프론티어에 OpenStack CEO 앤드류~어쩌구~저쩌구가 OpenStack발표하는 말미에 이런 이야기를 하더군요...

"사람들이 종종 묻기를...“OpenStack은 클라우드 코어로서 사용될 준비가 되어 있는지요?”라고 묻는다... 그런데, 이 질문은 조금 잘못된 것 같다. 나는 이렇게 되 묻고 싶다. “그게 OpenStack이든 뭐든,... 그것들을 사용할 '준비'가 되어 있는가??” 여기서 제가 말하는 '준비'는 전문성이나 기술력이 되겠죠... OpenStack은 현재 여러모로 부족합니다. 그러나, 가능성은 대단합니다. Linux가 처음에 그러했 듯이 OpenStack도 그러할 것입니다."

Cloud한다는 분들은 곱씹어 볼 내용이지요.... '준비'가 되어있는지.... 아무튼 그날 들은 내용중 젤 인상 깊게 남는듯......
Posted by 사랑줍는거지
,
이번 OpenStack - Diablo... 극 실망...아니, 좌절.... 한마디로 오픈소스 최대 약점 중 하나를 극명하게 보여줌... 하나부터 열까지 Cactus 대비(사실 Cactus도 탁월함과는 거리가 멀었다.) 제대로 되는게, 뻥좀 쳐서 하나도 없었다... 반쯤 만들다가 공언했던 일정 임박하니, "에라~ 모르겠다~ 오픈소스가 원래 그런거 아니겠어!!? 그냥 배포하니, 문제되는건 리포트나 좀 하고 알아서 고쳐 쓰겠지...뭐.." 이런 심산으로 뿌렸다는게 대충이지만 만지작 해본 결론........ 오픈소스만의 특유의 책임감? 가능성? 아무튼 그런게 전혀 없는듯 했다....... keystone같은 경우, ubuntu용 패키지 받아서 설치 해보니 conf파일 마저 누락되어 있었다... 어처구니 없어 하면서, 열심히 뒤져서 copy&paste로 해결... 프로젝트 단위도 짧게는 3개월.. 길어야 6개월... 엉망으로 발표한거 개삽질 디버깅해서 다 고쳐서 엉성하게 나마 이제 돌아가게 할때쯤이면, 새 버전이 나온다는 이야기다... 푸헐~ 비유가 쪼매 야시시 하지만... 첫 날밤 새색시 옷고름 다 풀고 보니 날 밝아 버린??... 아무튼 갠적으로 정말 맘에 안든다... 개념도 불필요하다 싶을 정도로 복잡/난해... 클라우드... 사용자의 수고를 덜어주고 빠른 응답성을 가지는게 기본 컨셉중에 하나임에는 분명한듯 하나... 그 수고를 줄이는 것을 목적으로 해야지... 서비스 제공자로의 이동 및 증가를 가져오는 클라우드라면 문제가 있는거 아닐런지...
Posted by 사랑줍는거지
,
원문 : http://www.cyberciti.biz/tips/centos-linux-6-download-cd-dvd-iso.html


CentOS Linux version 6 has been released. It is a community-supported operating system based on Red Hat Enterprise Linux (RHEL) version 6. CentOS Linux is considered as the most popular Linux distribution for web servers with almost 30% of all Linux servers using it.

CentOS Linux 6 Desktop Screenshot

Fig.03: CentOS Linux 6 Desktop Screenshot


From the release notes:

The CentOS team is pleased to announce the immediate availability of CentOS-6.0 for i386 and x86_64 Architectures. CentOS-6.0 is based on the upstream release EL 6.0 and includes packages from all variants. All upstream repositories have been combined into one, to make it easier for end users to work with.

CentOS Linux 6 Screenshots

CentOS 6 Download

You can download CentOS Linux 6 via the web/ftp server or via BitTorrent (recommended) client.

CentOS 6 DVD ISO download

CentOS Linux 6 DVD ISO Torrents

Torrent files for the DVD's are available at the following location:

A Note About CentOS Linux version 6.1

From the mailing list:

Since upstream has a 6.1 version already released, we will be using a Continous Release repository for 6.0 to bring all 6.1 and post 6.1 security updates to all 6.0 users, till such time as CentOS-6.1 is released itself. There will be more details about this posted within the next 48 hours.

Featured Articles:

Posted by 사랑줍는거지
,

한동안 회사일로 Chef Server/Client (CentOS기반) 구축문서 마무리를 못했었는데, 일신상의 이유로 여유가 생겨 다시 이어서 작성하고자 OPScode의 Installation Wiki문서를 찾았다. 그런데... 또 바뀌었다..ㅡㅡ;; 
이전의 번거롭던 설치 과정이 다 필요 없어졌다. CentOS든 FrameOS든 VM어플라이언스 형태로 제공되기 시작한듯 하다. 여기에 FrameOS의 경우, RPM(yum)를 통해서도 설치를 지원한다. 희소식이긴 하나, 이전의 나의 삽질은 정말 삽질이 되버렸다. 물론 도움은 많이 되었고, Chef운용에도 여전히 참조될 정보들이긴 하나, 좀 허무하다~ ㅎㅎ;;

자세한 정보는 아래 링크주소와 스크랩 내용을 참조....
http://wiki.opscode.com/display/chef/Installation+on+RHEL+and+CentOS+5+with+RPMs

RPM Package Support Deprecated

RPM installation via ELFF has been deprecated, as the RPM based approach has proved difficult to maintain with the fast moving nature of the rubygems ecosystem. Please refer to Install Chef Server From Rubygems, or Install Chef Client with Rubygems for an Opscode supported approach.

Community RPM Package Support

Community members are actively working on third-party repositories for Chef on Redhat based distributions - some of which Opscode has used successfully with some customers.

These are not officially supported by Opscode for Opscode Platform customers, and we have not committed time to testing and ensuring the functionality of these packages with Chef. They may still be options community users want to consider, turning to the Open Source Community Help Resources for support.

Alternate RPM Repositories

Alternatives that leverage RVM

Pre-built, RPM based Virtual Appliances

Futures


The future solution to this problem will be full-stack installers delivered both as stand-alone installable binaries and native packages, but with the entire dependency chain included. That this is the right solution is starting to be pretty widely embraced - you can see the evidence in several past package maintainers for chef moving to a model exactly like this.

Opscode has an full-stack or 'fatty' installer in development. Further information and detail regarding the 'fatty' installer will be forthcoming as it progresses through product planning.

 








Posted by 사랑줍는거지
,
CentOS 6이 너무 늦는군요.... FrameOS 6을 사용중이지만, 그래도 기대되는건..........
오늘 관련해서 검색하다가, RHEL 6의 또다른 클론 버전을 발견......(RHEL 클론 버전들이, 그것도 유용한 것들이 많네요. 이런걸 발견할 때마다 느끼지만, 나만 몰랐던 것 같은....)
하나는 Scientific Linux 6 이고, 하나는 Fermi Linux이다. 이중 활성화 정도로 봐서는 Scientific Linux 6이 더 나은듯 하다.
일전에 소개한 FrameOS는 초기 구성이 아주~ 너무나 컴팩트하게 구성되어 VM용에 최적화 되어 있는게 특징이었다. Scientific Linux 6는 아직 설치까지는 해보지 못했지만, 구글 검색결과 외국에서 대학 연구실이나, 과학 연구부서에서 많이 사용된다고 한다.

http://scientificlinux.org/

위 주소에서 보다 자세한 정보를 얻을수 있다. 참고로 5.x까지는 CD/DVD 이미지가 제공된듯 하나, 6부터는 DVD만 지원하는듯....





Posted by 사랑줍는거지
,