청주에 사는 대학 친구가 소개해준 맛집~
맵다고 했지만 내가 생각하는 매운 강도와 그 친구가 생각하는 매운맛은 다르기에
흔쾌히 콜~~ 달려갔습니다. 자리는 딱 3자리..
생각보다 비좁더군요. 예약하지 않으면 가더라도 못 먹습니다. -_-;;;


모임친구와 함께 맛집 도착
들어가자 마자 한마디 던졌습니다.
"사장님~~ 엄청 맵게 해주세요~!!"
사장님 왈 "어느정도 맵게 해주길 원해요?"
다시 한번 " 사장님~ 이 집에서 가장 맵게요~!!"
이 한마디가 큰 휴유증을 남겼습니다. ㅡㅡ;;



먹다 너무 매워 갤포스 긴급 투입~
으어엉~~ 설마 했는데 엄청 매웠따는..
양쪽 테이블은 보통 매운맛으로 시켰음에도 매워 어쩔줄 몰라하더군요..



저처럼 매운거 좋아하시는 분은 꼭 한번 가보세요..
단, 매우 매운 맛으로 주문후 시식하시기 바랍니다.
부부가 함께 운영하시는 가게인데, 모두 친절하고 좋더군요.. 예약은 필수~!!

작년 친구들과의 모임에서 공수한 굴~!!
목포에 사는 친구가 직접 공수한 오리지널 굴!!
가져온 통채로 일반 냄비 넣고 4~5번 삶았다는 전설이;;




복분자와 굴의 궁합~!! 
위생상 조금 문제가 되었지만 -_-;;
덕분에 하나씩 굴을 껍질과 분리하느라
고생했다는 소문이.. 




굴껍질 하나씩 벗기다 발견한 신기한 사진 ㅋ
아기개 ㅡ.ㅡ;; 굴에 붙어 있더군요
신기해서 한컷 찍었습니다. 음햐햐~




선미는 너무 예뻐요!~

사용자 삽입 이미지


 

일본

 

NIKKEI225

현지시간

09:00 ~ 11:00 12:30~15:00

한국시간

09:00 ~ 11:00 12:30~15:00
홍콩 HanSeng 10:00 ~ 12:30 14:30~16:00 11:00 ~ 13:30 15:30~17:00  
중국 Shanghi 09:30 ~ 11:30 13:00~15:00 10:30 ~ 12:30 14:00~16:00  
대만 Weighted 09:00 ~ 13:30 10:00 ~ 14:30  

오늘은 웬지 큰 행운이 나에게 있을 것이다.

나는 뭐든지 할 수 있어.

1.1   "시스템의 CPU 사용량" 은 어떻게 측정되는가?

Solaris 운영체제는 1초에 100번씩 CPU가 어떤 일을 하는지 감시한다. 이때 CPU가 user mode에서 작업을 실행하면 user_tick에 1을 증가 시키고, system mode에서 작업을 실행하면(애플리케이션이 시스템 콜을 호출하여 커널에서 실행되고 있는 경우) system_tick에 1을 증가시킨다.
CPU가 실행할 작업이 없어서 쉬고 있는 경우, I/O(block device: hard disk)를 기다리는 작업이 있으면 wait_tick에 1을 증가시키고, 그렇지 않으면 idle_tick에 1을 증가시킨다.
vmstat나 sar 명령어는 이러한 값을 시스템으로 부터 얻어서 주어진 시간간격(interval) 의 차이 값을 구하여 각각을 백분율(%)로 나타낸 것이 CPU 사용율이다.

만일 sar 명령어로 10초 간격으로 시스템 사용량을 조사하면, sar 명령어는 먼저 위에서 설명한 값을 시스템으로 부터 얻어 오고, 10초 후에 한번 더 얻어와서 2회 측정한 값의 차이 값을 각각의 백분율로 보여 준다.

예를 들어, 10초 간격으로 CPU 사용율을 조사하면,

Tick

First

Second
(10 sec later)

Delta
(Total: 1000)

%

user

230

430

430-230 = 200

200/1000*100 = 20%

system

350

500

500-350 = 150

150/1000*100 = 15%

wait

160

310

310-160 = 150

150/1000*100 = 15%

idle

160

660

660-160 = 500

500/1000*100 = 50%

다음은 CPU 사용율을 알아보는 명령어 sar 와 vmstat 명령어의 결과이다. 

# sar -u 1 10
14:43:22    %usr    %sys    %wio   %idle
14:43:23       3       7      26      64
14:43:24       0       5      33      62
14:43:25       1       4      39      56
14:43:26       1       3      40      56

# vmstat 1 
 procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr f0 s0 s1 s1   in   sy   cs us sy id
 0 0 0 2330808 102048 3  18 21  4  4  0  3  0  1  0  0  430  431  339  1  0 99
 0 1 0 674656 95224 215   8 6720 0 0  0  0  0 808 0  0 1879 9666 1871  3 11 86
 0 1 0 674656 89584 190   0 3560 0 0  0  0  0 406 0  0 1601 4239 1064  0  5 94

위의 결과에서 보면, sar 명령어는 CPU 사용량을 %usr(user)와 %sys(system)과 %wio(wait)와 %idle(idle)로 구분하고, vmstat에서는 us(user)와 sy(system)과 id(idle)로 구분한다.
%wio의 값은 CPU의 사용율과는 무관하다. 이 값은 CPU가 놀고 있을 때, IO를 기다리고 있는 프로세스가 있는지 여부를 알아보는 힌트이다.
IO를 기다리는 프로세스가 있다는 것은 그 IO가 완료되면 곧 바로 CPU를 다시 사용할 것이라는 것을 암시한다. 유닉스,솔라리스,scsa,scna,csa,솔라리스학원,유닉스학원,유닉스보안,unix유닉스,솔라리스,scsa,scna,csa,솔라리스학원,유닉스학원,유닉스보안,unix유닉스,솔라리스,scsa,scna,csa,솔라리스학원,유닉스학원,유닉스보안,unix,solaris

sar 와 vmstat 명령어의 결과는 다음과 같은 관계이다. 

         sar     vmstat		CPU
---------------------------------------------------
         %usr  =  us		run on user mode
         %sys  =  sy		run on system mode
%wait + %idle  =  id		idle
선 솔라리스 solaris, scsa, scna 선 솔라리스 solaris, scsa, scna 선 솔라리스 solaris, scsa, scna
이제 가상화에 대한 기존의 고정 관념으로부터 탈피할 때입니다

Bill Vass가 새 레터로 여러분을 다시 찾아 뵙습니다. 애독자들이 행여라도 제 글에 두서가 없다고 생각하시기 전에, 저는 이 레터를 통해 당사가 기업 데이터센터의 비용 절감, 하드웨어 이용률 증대, 애플리케이션의 가용성과 성능 향상 등을 가능하게 하는 다양한 기술들을 구축하고 있다는 사실을 밝혀 두는 바입니다.

최근의 레터에서 우리는 어떻게 썬의 CMT 프로세서가 데이터센터의 요구사항을 감소시키고, 오픈소스와 OpenSolaris가 보안 및 애플리케이션 성능을 강화하고, 오픈소스 미들웨어가 레거시 투자를 최대한으로 보호할 수 있는지에 관해 살펴보았습니다. 이번 호에서는 잠시 발길을 되돌려 오늘날의 기업들에게 초미의 관심사가 되고 있는 가상화에 관해 논해볼까 합니다.

가상화를 아주 간단하게 설명하자면 기본적인 하드웨어로부터 컴퓨팅 리소스를 추출하는 일이라고 할 수 있습니다. 한편, 가상 머신 기술은 최근에 가상화 자체와 거의 동의어가 되어버린 새로운 현상으로 부상하기에 이르렀지만, 가상 머신은 결코 가상화의 ‘시작이자 끝’은 아닙니다. Solaris Container와 같은 운영체제 가상화 방식은 매우 중요한 역할을 담당합니다. 또한 보다 넓은 관점에서 볼 때, 그리드는 애플리케이션의 개발/제공 방식을 획기적으로 바꾸어 놓을 수 있는 그리고 이미 광범하게 보급된 가상화/공유 아키텍처에 커다란 잠재력을 부여합니다.

가상화의 사업적 타당성
데이터센터에서 하드웨어를 유지 보수하는 데 상당한 비용이 초래될 수 있다는 것은 누구나 알고 있는 사실이며, 실제로 전력, 냉각, 공간 관련 비용은 IT 예산의 3중고에 해당한다고 할 수 있습니다. 대부분의 기업들의 경우, 피크 로드에 대비해서 시스템을 증축하긴 하지만 피크 타임은 사분기 말이나 연말에 집중될 뿐이고 나머지 기간의 하드웨어 이용률은 10%에서 15% 선에 불과합니다. 그 결과 상당량의 리소스가 그대로 방치되는데, 이는 자본과 전력과 공간의 엄청난 낭비로 이어집니다.

대형 서버 팜의 관리는 비용 증가의 또 다른 요인으로 작용하게 되며, 하드웨어 가격이 하락함에도 불구하고 관리비는 계속해서 치솟습니다. 대규모 데이터센터의 직접 비용은 차치하고라도, 모니터하고 유지 보수할 물리적 시스템의 수를 줄이는 일은 가상화 기술을 채택할 수밖에 없는 또 다른 동기가 됩니다. 물론, 이것은 기업이 단순히 물리적 관리를 가상 머신 관리로 대체하지 않는다는 가정 하에서의 얘기입니다.

자주 거론되지는 않지만 이에 못지 않게 중요한 것은 기업들이 애플리케이션의 가용성을 하드웨어에 주로 의존한다는 사실입니다. 대부분의 조직체는 애플리케이션과 비즈니스의 지속적인 운영을 보장하고 심각한 다운타임을 피하기 위해 리던던트 하드웨어를 구현하곤 하지만 하드웨어 리던던시는 애플리케이션 가용성을 보장하는 데 완벽한 수단이 되지 못할 뿐 아니라 데이터센터의 비용을 가중시키기까지 합니다.

이용률과 리던던시 문제를 동시에 해결할 수 있는 수단으로 부상하게 된 가상화는 애플리케이션과 운영체제 인스턴스가 하드웨어 리소스를 공유하게 함으로써 이용률과 투자수익률을 높여줍니다. 가상화는 기본 하드웨어에서 소프트웨어를 추출함으로써 까다로운 하드웨어에 의존하지 않고도 애플리케이션 리던던시를 구현할 수 있으므로 가용성 향상에 특히 효과적입니다. 요컨대, 조직체는 가상화를 통해 다음의 목표를 달성할 수 있게 합니다.

  • IT 및 비즈니스 유연성 향상
  • 인프라의 신속한 확장 및 축소
  • 가용성 향상 및 애플리케이션 성능 강화
  • 애플리케이션 관리의 간소화 및 소요 비용 대비 애플리케이션 성능 증대

가상 머신의 여명기
이제 가상 머신 기술은 가상화의 일반적 형태로 확고하게 자리매김하였습니다. 본질적으로 이 기술은 특정 물리적 시스템이 복수의 가상 운영체제 인스턴스를 호스트할 수 있게 해주며, Solaris, Linux, Windows와 같은 다양한 운영체제가 동일 하드웨어 상에서 평화롭게 공존할 수 있도록 도와줍니다.

근년 들어 VMware 기술은 가상 머신 시장에서 가장 유력한 후보로 떠올랐는데, VMware 가상화 기술의 원리는 먼저 부트되는 미니 운영체제처럼 행동하면서 본질적으로 기본 하드웨어를 작은 조각들로 가상화하여 동일한 물리적 서버 상에서 다양한 운영체제가 실행될 수 있도록 하는 하이퍼바이저를 생성하는 것입니다. 이런 접근법은 혼용 운영체제 환경을 필요로 하는 레거시 애플리케이션을 보유한 조직체에게 특히 유용한 것으로 입증되었습니다.

 
가상화에 의한 통합: Sun x64 서버 제품 라인

VMware 가상 머신 방식은 매력적이긴 하지만 성능 면에서 볼 때는 상대적으로 고가입니다. 일반적으로 하이퍼바이저는 총 CPU 파워의 5~15%를 소비하며, 각 운영체제의 오버헤드는 점진적으로 증가하게 됩니다. 결국 기업들은 단지 가상 머신 인프라를 지원하기 위해 대량의 CPU 리소스를 소비하게 되는 셈입니다. 또한 가상 머신은 애플리케이션에 장애가 발생할 경우 애플리케이션, 운영체제, 가상 머신 기술 중 어디에 원인이 있는지 파악하기 어렵기 때문에 가시성(observability)에 부정적인 영향을 줄 수 있습니다.

최근에는 Open Source Xen 소프트웨어가 VMware의 대안으로 떠오르고 있는데, Xen도 VMware와 마찬가지로 동일한 하드웨어 상에서 복수의 게스트 운영체제를 실행할 수 있게 해줍니다. Xen은 훨씬 낮은 레벨의 가상화 방식으로, 관리자가 메모리와 CPU를 포함한 시스템의 다양한 부분을 가상화할 수 있게 합니다. Xen은 이처럼 낮은 레벨에 상주하기 때문에 상당한 수준의 리소스와 장애 격리 기능을 제공할 수 있습니다.

Xen을 고려하지 않을 수 없도록 만드는 이유로는 여러 가지가 있습니다. 첫째, Xen은 오픈소스입니다. 둘째, Xen은 상대적으로 경량이므로 과도한 양의 CPU 리소스를 소비하지 않습니다. 셋째, Xen은 가상 머신 기술 간에 높은 수준의 격리 효과를 실현합니다. 끝으로, Xen은 다른 가상 머신 기술과 마찬가지로 혼용 운영체제와 버전을 지원하며 관리자가 서비스에 영향을 주지 않고 운영체제 인스턴스를 동적으로 인스턴스화하고 실행할 수 있게 해줍니다.

가상 머신으로 Solaris Container 사용하기
모든 솔라리스 10 OS 사용자에게 무료로 제공되는 또 다른 형태의 가상화가 존재하는데, 그것은 바로 Solaris Container입니다. 솔라리스 환경에서는 Solaris Container를 이용해서 각 애플리케이션에 자체적인 IP 주소, 파일 시스템, 사용자, 할당된 리소스를 부여함으로써 애플리케이션 환경을 가상화할 수 있습니다. 게다가 Solaris Container는 커널 레벨에서 가상화가 이루어지기 때문에 극히 부담이 적다 할 수 있습니다. 또한 복수 커널의 오버헤드가 추가되지 않기 때문에 단일 서버 상에서 수천까지는 아니더라도 수백 개의 Solaris Container를 실행하는 것도 가능합니다. 이 외에도, ‘Solaris Containers for Linux Applications’과 더불어 Solaris Container에서도 Linux 애플리케이션을 전혀 수정하지 않고 실행할 수 있습니다.

Solaris Container는 복수의 운영체제 인스턴스를 허용하지는 않지만 그 외에 다음과 같은 여러 가지 이점을 제공합니다.

이용률 향상: 컨테이너는 오버헤드를 추가하지 않고 작업부하로 인해 요구되는 리소스만을 소비하기 때문에 이용률을 증대시켜 줍니다.
관리비 경감: 관리자가 각각의 작업부하를 위해 별도의 운영체제 인스턴스를 유지할 필요가 없기 때문에 관리비 절감 효과가 뛰어납니다.
탁월한 가시성: 특히 실시간 문제해결을 위한 DTrace 등의 다른 솔라리스 기능과 연계하여 가상화된 환경에 대해 뛰어난 가시성을 제공합니다.
신속한 프로비저닝: 다양한 시스템과 서비스 구성에 대해 광범위한 회귀 검사(regression testing)를 수행하는 QA 환경에서처럼 신속한 프로비저닝과 호스트의 단기적 가용성을 보장해 줍니다.
라이센스 비용 절감: 하나의 OS 라이센스로 수백 개의 Solaris Container를 지원할 수 있기 때문에 잠재적으로 라이센스 비용을 절감시켜 줍니다.

하지만 가상 머신이 제공하는 더 높은 레벨의 리소스와 장애 격리 기능을 과소평가해서는 안 됩니다. 때로는 애플리케이션이 Solaris Container의 능력을 넘어선 수준의 격리를 요구하는 경우가 있는데, 바로 이런 경우에 가상 머신을 Solaris Container와 연계해서 사용하면 최고 수준의 격리, 이용률, 관리 용이성을 달성할 수 있습니다.

Solaris Container와 가상 머신의 혼합
가상 머신과 Solaris Container의 혼합이 유용한 사례를 살펴보기로 하겠습니다. 보안이나 성능상의 이유로 패치가 필요한 애플리케이션, 그리고 패치 레벨이 충돌하는 또 다른 애플리케이션이 있다고 가정합시다. 그리고 Windows 운영체제에 연결된 제3의 레거시 애플리케이션이 있습니다. 이 세 개의 애플리케이션은 세 가지의 서로 다른 가상 머신 운영체제 인스턴스에서 실행되어야 합니다. 이번에는 동일한 환경에 패치의 관점에서 관용성을 지닌 4개의 애플리케이션이 더 있다고 가정해 봅시다.

이 예에서, 자체적인 운영체제 인스턴스를 요하는 세 개의 애플리케이션은 가상 머신을 이용하여 가상화될 수 있고, 네 번째 가상 머신 운영체제 인스턴스는 단지 하나의 솔라리스 인스턴스를 요하는 애플리케이션들을 위한 4개의 Solaris Container를 수용할 수 있습니다. 이 경우 다음과 같은 이점이 있습니다.

  • Solaris Container는 애플리케이션들이 동일한 패치 세트를 공유할 수 있게 해줍니다.
  • 관리자는 단 하나의 운영체제 인스턴스만 유지하면 됩니다.
  • 관리자는 복수의 가상 머신을 추적할 필요가 없습니다.
  • 조직체는 관리비를 절감할 수 있습니다.

그리드: 과거와 현재와 미래의 가상화
지금까지 이 레터의 내용은 가상화를 둘러싼 논의의 지평을 확대한다는 면에서 상당히 온건한 편이었습니다. 하지만 이제부터는 다릅니다. 가상화가 오랫동안 사용되어 왔으면서도 가상화의 측면이 거의 거론된 적이 없던 영역이 있습니다. 그것은 바로 그리드입니다. 그리드는 첫눈에 가상화처럼 보이지 않을지도 모르지만, 이 레터의 시작 부분에서 제시한 정의-기본적인 하드웨어에서 컴퓨팅 리소스를 추출하는 작업-를 상기한다면 가상화의 사례로 이보다 더 알맞은 것도 없을 것입니다.

기업이 가상화 환경을 향해 나아가다 보면 가상화는 본질적으로 그리드 환경을 지향한다는 것을 알게 될 것입니다. 그 이유는, 가상화된 솔라리스 인스턴스와 복수의 Solaris Container가 있을 경우, 이 컨테이너의 리소스는 복수의 그리드에 의해 소비될 수 있기 때문입니다. 애플리케이션 그리드는 소프트웨어를 서비스로 제공하는 그리드 프레임워크에 의해 형성·제어될 수 있으며, 그리드 엔진은 컴퓨트 그리드의 초과 사이클(excess cycles)을 활용할 수 있습니다. 실례합니다. 여느 때처럼 제가 좀 서두르는 것 같군요.

그리드는 물론 새로운 것이 아니며, 연산 집약적 작업을 집단적으로 처리하기 위한 수단으로 이용되어 왔습니다. 즉, 그리드는 복잡한 기상 시뮬레이션을 제작하고, 막대한 지하 유전을 측량하고, 핵 폭발의 결과를 유추하고, 복잡한 금융 파생상품의 재정 실적을 시뮬레이트하고, 영화의 개별 프레임에 다층 구조를 추가하는 등의 작업에 사용되어 왔던 것입니다. 결국 과중한 프로세싱 요구에 직면하는 대다수의 산업이 그리드에 크게 의존하고 있는 것이 현실입니다.

“Stateless vs Stateful” 그리드
전통적인 그리드의 작동 원리는 매우 단순했습니다. 영화 스튜디오에서 어떤 영화의 1,000개 프레임을 텍스처 매핑해야 하는 경우, 그리드 컨트롤러는 1,000개의 병렬 프로세스를 산출하고 이를 같은 수의 서버로 보냅니다. (물론, 가상 환경에서라면 1,000개의 물리적 서버 또는 CPU 대신 1,000개의 Solaris Container만으로 쉽게 해결되겠지만.)

 
그리드의 작동 방식을 보려면 Sun Utility Grid를 참조하십시오

어떤 경우든, 하나의 서버가 다운되면 그리드 컨트롤러는 다른 999개의 작업부하를 수집하여 1개가 모자라는 것을 확인한 다음 나머지 부하를 정상적인 서버로 분산시킵니다. 이 가장 기본적인 형태의 그리드를 stateless 그리드라고 하는데, 그 이유는 누군가가 한 서버에 접근해 전원을 차단하더라도 전체적으로는 별 차이가 나지 않기 때문입니다. 그리드 컨트롤러는 단순히 없어진 작업부하를 다른 서버에 재할당하는 것입니다—아무런 손상이나 충돌도 없이 말이죠.

최근에는 이른바 stateful 그리드가 출현하기에 이르렀습니다. 썬은 엄청난 양의 불필요한 프로세싱 파워를 지닌 데스크탑을 여러 대 설치하는 대신 디스플레이 그리드와 Sun Ray 씬 클라이언트를 연계하여 사용자가 필요로 하는 시간과 장소에 맞추어 데스크탑을 제공합니다. 또한 썬의 그리드 컨트롤러는 700대의 디스플레이 그리드 전용 서버 중에서 각 개인이 필요로 하는 프로세싱 파워만을 제공합니다.

예를 들어, 어떤 직원이 사무실에 출근해서 StarOffice를 가동시키면 일반적으로 CPU의 총 프로세싱 파워 중 60% 정도가 필요할 것이므로, 그리드 컨트롤러는 이에 해당하는 양을 직원에게 제공하는 것입니다. 썬 디스플레이 그리드를 stateful 그리드라고 하는데, 그 이유는 사용자가 기본 인프라에 상태 기반(stateful) 연결을 하기 때문입니다. 따라서 누군가가 데스크탑의 전원을 꺼버리면 대개의 경우 사용자는 이를 알아차리게 됩니다.

애플리케이션 그리드를 통한 리소스 최적화
이번에는 보다 진보된 형태의 stateful 그리드인 애플리케이션 그리드에 대해 살펴보기로 하겠습니다. 어떤 회사가 비(非) RAC Oracle ERP 시스템을 그리드 환경으로 전환하려 하는데, 그 시스템은 전형적인 3-티어의 프레젠테이션 레이어, 애플리케이션 레이어, 데이터베이스 레이어 아키텍처로 구성되어 있다고 가정해봅시다. 웹 서버로 20개의 그리드 컨트롤러를 할당하고 그 중 4개를 로드 밸런서로 지정할 수 있습니다.

그런 다음 기업은 애플리케이션 서버의 역할을 하는 두 세트의 컨테이너 간에 stateful 클러스터를 생성하여 누군가가 애플리케이션 서버 중 하나를 꺼버릴 경우 그리드 컨트롤러가 정상적인 애플리케이션 서버에서 해당 작업을 재개하도록 할 수 있습니다. 이제 회사가 그리드에 데이터베이스 레이어를 추가할 경우 그리드는 컨테이너를 stateful 컴포넌트로 할당하고, 심지어 그 컨테이너들을 그리드 전반에 걸친 고가용성 클러스터로 만들어 컨테이너들이 다양한 물리적 위치를 차지하도록 할 수 있습니다.

과거에는 이런 아키텍처를 구축하려면 독립형 Oracle ERP 시스템이 각 레이어에 대해 20개 정도의 CPU를 전담시켜야 했을 것입니다. 전형적인 ERP 시스템의 경우 오전에 맹공을 당하고 잠시 소강 상태를 유지하다가 오후에 다시 프로세싱 요구가 피크에 달하는 경향이 있다는 사실에도 불구하고 말이지요. 역시 이 경우에도, 피크대를 위해 지나치게 많은 하드웨어와 리소스가 낭비될 뿐입니다.

 
이제 규모를 막론한 거의 대부분의 조직체들이 각자의 기본적인 하드웨어 인프라 전체를 모든 애플리케이션이 공유하는 리소스로 취급하게 되는 것은 시간 문제라 할 수 있습니다.

그리드 환경에서는 그리드 컨테이너를 이용해서 동일한 아키텍처를 생성할 수 있습니다. 따라서 웹 서버 레이어는 20개의 컨테이너로 구성되고, 애플리케이션 레이어는 10개의 주 컨테이너와 10개의 리던던트 컨테이너를 보유하고, 데이터베이스 레이어는 또 다른 10개의 컨테이너와 10개의 리던던시를 보유하도록 하는 것이 가능합니다. 그리고 모든 레이어가 동일한 가상 하드웨어 리소스를 공유하게 되는 것이지요.

하드웨어 이용률 100%를 향하여
진정한 변혁은 동일한 그리드 상에서 부하를—stateless이건 stateful이건 관계없이—믹스 앤 매치하는 것이 가능해진다는 사실입니다. 그리고 부하의 statefulness 또는 criticality가 주어진다면 우선순위를 할당하는 것도 가능해집니다. 예를 들어, StarOffice를 가동하는 직원은 백그라운드에서 실행되는 대규모의 stateless 부하로부터 CPU 파워를 가져옵니다. 마찬가지로, Oracle 애플리케이션이나 데이터베이스 서버가 프로세싱 파워를 요구할 경우 StarOffice 직원은 잔여 CPU 사이클을 확보하고 stateless 부하가 나머지 프로세싱 파워를 모두 가져오게 되는 것입니다.

결국, 모든 애플리케이션이 동일한 가상화 인프라를 공유하도록 하고 적절한 리소스 관리를 활용함으로써, 기업은 오늘날의 현실인 15%가 아닌 100%에 육박하는 하드웨어 이용률을 실현하고 애플리케이션 리던던시와 가용성을 동시에 향상시킬 수 있게 될 것입니다.

가상화와 그리드를 모두 함께
본 기사에서 그려 보인 시나리오는 결코 그림의 떡이 아닙니다. 바로 현실입니다. 기업들은 이미 VMware나 Xen과 같은 가상 머신 기술을 유용하게 활용하고 있으며, 많은 조직체가 이용률 향상을 위해 Solaris Container를 배치하고 있습니다.

또한 거대한 자동차 회사와 세계적 수준의 금융기관을 비롯한 일부 선도적 기업들은 가상화 운영체제, 가상화 애플리케이션, 공유 데스크탑 인프라, stateless/stateful 부하를 처리하기 위한 그리드 등을 포함하여 완벽한 가상화 환경으로 이동하고 있습니다.

이는 부정할 수 없는 대세입니다. 이제 규모를 막론한 거의 대부분의 조직체들이 각자의 기본적인 하드웨어 인프라 전체를 모든 애플리케이션이 공유하는 리소스로 취급하게 되는 것도 시간 문제라 할 수 있습니다. 이익은 크고 사업적 타당성도 너무나 명확한데 이에 관심을 갖지 않을 기업이 과연 있을까요?

Bill Vass
CIO
Sun Microsystems, Inc.
cio@sun.com


출처 : kr.sun.com

+ Recent posts

티스토리툴바