Sun Developer Network 공식 블로그

근 몇 년 사이에 서버 분야에서 통합화(Consolidation) 와 더불어 가장 많이 들을 수 있는 단어가 가상화(Virtualization) 이다. 비단 서버 분야뿐만 아니라 소프트웨어 업계에서도 이 가상화란 단어가 많이 쓰이고 있다. 이 글을 읽는 독자들 중에서도 VMWare 혹은 Virtual PC 등을 이용해서 가상머신에 윈도우나 리눅스 등을 설치해본 독자가 상당 수 있을 것이라고 생각된다. 이번에 다룰 주제는 오픈 솔라리스와 가상화 기술이다. 본격적으로 오픈 솔라리스의 가상화 기술을 다루기 전에 ‘가상화’ 라는 개념의 의미와 종류에 대한 설명으로 시작하려고 한다. 그 후에 오픈 솔라리스의 대표적인 가상화 프로젝트인 존(Zone), Branded 존, 솔라리스 Xen, CrossBow 등의 기본 지식과 의미를 살펴보고 각 프로젝트들의 현황 및 특징도 살펴보려고 한다.


by  이창재 eggboy@gmail.com
현재 오픈 솔라리스 한국 유저그룹 리더를 맡고 있으며 솔라리스 테크넷 운영진으로도 활동하고 있다.


#######################################################################


가상화(Virtualization) 의 의미

비교적 일반적인 의미를 알기 위해 웹2.0 사이트의 원조 격인 위키피디아(wikipedia.org)를 살펴 보자.

In computing, virtualization is a broad term that refers to the abstraction of computer resources. One useful definition, from independent IT analyst firm Enterprise Management Associates, is "a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources. 이후 생략.." 

컴퓨팅 분야에서 가상화란 컴퓨터 자원을 추상화 한다는 뜻을 가지고 있고 그러한 자원을 다루는 어플리케이션 혹은 엔드 유저에게 물리적인 속성을 숨겨주는 기술을 말한다고 한다. 다른 말로 설명하자면 기반에 깔린 물리적 자원들의 복잡함을 숨기고 논리적인 자원들로써 엔드 유저들에게 보여주게 하는 기술이라는 뜻이다. 간단한 예를 들어 보자. 윈도우를 사용하다 보면 메모리를 많이 소비하는 소프트웨어를 실행하는 도중 ‘가상 메모리가 부족합니다. 가상 메모리를 늘려주세요’ 라는 오류 메시지를 본 경험이 있을 것이다. 결국 페이지 파일의 용량을 늘려서 문제를 해결했었던 기억도 있을 것이다. 여기에서는 복잡한 페이징 이론을 굳이 알지 못하더라도 하드디스크의 용량을 메모리의 용량으로 바꾸어 보여주게 했다는 점에서 일종의 가상화라고 생각해 볼 수 있을 것이다.
가상화란 단어는 컴퓨터 분야에서 1960년대부터 쓰였다고 하니 꽤 역사가 오래된 단어라고 할 수 있다. 역사가 오래 되었기 때문에 여러 분야의 기술들이 나타났고 결과적으로 "broad term" 이라고 표현할 만큼 여러 가지의 종류도 가지고 있다. 이러한 종류를 표로 단순히 알아보자. <표 1>은 위키피디아의 분류를 토대로 정리해 놓은 표이다.

<표 1> 가상화의 종류

가상화가 주목 받는 이유는 여러 가지가 있다. 일단 물리적인 자원의 가상화를 통해 머신의 자원을 효율적으로 사용할 수 있다는 점, 가상 서버의 경우 하나의 서버에 오류가 생겨도 다른 서버로 오류가 전이 되지 않음으로써 시스템의 안정성이 높아진다는 점, 각 서버가 각각의 역할 분담이 되어 있어서 오류 발생 시 발생 지점을 찾아내기 쉽다는 점 등 가상화를 통해 얻을 수 있는 장점이 많기 때문에 가상화란 단어가 마치 ‘웹 2.0’의 2.0 붙이기 붐과 같이 유행하고 있다고 필자는 생각한다.

오픈 솔라리스의 가상화 기술

본격적으로 오픈 솔라리스의 가상화에 대해 살펴보자. 먼저 <그림 1>을 보면 스토리지 가상화 기술인 ZFS를 제외한 나머지 기술들이 잘 나타나 있다. 첫 번째로 Dynamic System Domain의 경우 High-End 급의 서버 시스템에서 쓰이는 기술로써 각 보드 (보드마다 CPU와 메모리가 마치 주변기기처럼 부착되는 방식) 를 Domain 이라는 물리적인 단위로 나눌 수 있도록 해준다. 이렇게 나누어진 도메인은 그 자체로 하나의 서버가 된다. 솔라리스 8부터 포함된 기술로 꽤 역사가 오래된 기술이다. 두 번째로 Xen 의 경우는 앞에서 설명한 Para-virtualization 의 한 종류로써 그림에서 보듯이 머신 위에 Hypervisor 라고 하는 계층이 있는 것이 특징이다. Xen 자체는 오픈 솔라리스의 프로젝트는 아니고 캠브리지 대학(University of Cambridge)에서 처음 시작된 오픈 소스 프로젝트이다. Xen 에 대해서는 이후에 다시 설명하도록 하겠다. 세 번째는 OS Virtualization으로 분류될 수 있는 Container 이다. 보통 컨테이너(container) 와 존(zone) 두 용어를 혼용해서 쓰는 경우가 있는데 정확하게 말해서 SRM 즉 솔라리스 리소스 관리 설비를 사용하는 존을

컨테이너라고 부른다. 마지막 네 번째로 SRM 은 CPU 혹은 메모리 같은 자원들을 pool 이라는 단위로 묶어서 존 등에 지정할 수 있는 기술이다. 즉 존이 사용할 수 있는 CPU 와 메모리 자원들을 미리 지정해 줌으로써 한 존의 부하가 다른 존에도 영향을 미치는 것을 막아 줄 수 있는 기술이라고 할 수 있다. SRM 은 이 글에서 자세히 다루지 않는다. 그 밖에 이 그림에선 나오지 않지만 나중에 설명할 CrossBow 도 있다.

SRM(Solaris Resource Manager)

SRM은 CPU, 메모리, 네트워크 대역폭 등의 리소스 등을 컨트롤 할 수 있도록 해주는 기술이다. 그림 2를 보면 CPU의 셋인 pset 이 각 존에 할당 되는 모습을 보여주고 있다. 동시에 FSS라고 하는 CPU 스케줄링 방법을 사용하도록 지정하고 있다. 뒤에 나오는 그림인 <그림 3>의 Virtual Platform 부분을 보면 이해하는 데 도움이 될 것이다. 관리할 수 있는 자원에는 CPU외에도 메모리의 최대 사용량 한계 지정, 네트워크의 QOS 지원 등이 있고 이러한 자원들의  효과적인 최대한 효과적인 사용을 위해 쓰이는 것이 SRM 인 것이다.

오픈 솔라리스 가상화 기술과 커뮤니티

존이나 ZFS, CrossBow 같은 프로젝트들은 오픈 솔라리스 커뮤니티 안에서 지속적으로 발전되고 있다. 일반적으로 새로 공개된 기술들은 일정 기간이 지나서 테스트가 가능해질 정도의 수준이 되면 오픈 솔라리스에 정식으로 포함되어서 배포 된다. ZFS 같은 경우는 원래 솔라리스 10 출시와 동시에 배포되려고 했었지만 버그 수정이 늦어져서 오픈 솔라리스 빌드27부터 정식으로 포함 되었다. CrossBow 는 2006년 8월에 early access 버전이 커뮤니티에 공개된 상태로 직접 바이너리를 다운로드 받아서 설치해야 한다. 오픈 솔라리스의 모든 프로젝트들은 오픈 소스 프로젝트로 누구에게나 열려 있다. 커뮤니티 참여에 관심 있는 독자들은 직접  각 커뮤니티에 방문해 보기 바란다.

오픈 솔라리스 존(Zone)

첫 번째로 소개할 가상화 기술은 존 이다. 앞에서도 설명했지만 존 은 OS Virtualization 이다. 파일 시스템, 네트워크, 네트워크, 프로세서등 OS의 Layer를 모두 가상화 한다. 호스트에 있는 솔라리스 상에서 존 이라는 독립적인 구역에서 돌아가는 또 다른 작은 솔라리스가 있다고 생각하면 이해가 빠를 것이다. <그림 2>를 살펴보면 global 존 하나와 dns1 존, dns1 존, web2 존, mail 존 등의 non-global 존들 이 있다. 여기서 global 존은 앞에서 말한 호스트에 있는 솔라리스 이고 나머지 non-global 존 들이 Guest OS 라고 생각할 수 있다.

  <그림 3> 존의 아키텍쳐

존의 특징과 관련 데몬

존의 특징은 존의 사용을 위해서 기억해 둘만한 가치가 있다. 일단 각 존은 존의 고유한 존 ID 를 가지고 있고 global 존의 존 ID는 0번이다. 그리고 오직 global 존에서만 non-global 존을 생성하거나 수정할 수 있다. 존은 애초에 서로 독립적인 가상 실행 공간을 제공하고자 만들어 졌기 때문에 non-global 존 끼리는 서로의 존재를 전혀 알지 못하고 네트워크로의 연결을 제외한 직접적인 접근 또한 불가능하다. 존에 관련된 두 가지 데몬도 알아보자. zonedmd 와 zsched 가 바로 그것이다. <그림 3>을 보면 각 존이 zonedmd 를 바탕으로 삼고 있음을 볼 수 있다. zonedmd 는 다음과 같은 역할을 담당한다.

존의 부팅과 종료 관리
존 ID의 할당 및 zsched 데몬 시작
존의 리소스 제어
가상 네트워크 인터페이스
루프백 혹은 일반적인 파일 시스템 마운트

zsched 는 존 서브시스템들을 커널 쓰레드 단위로 작업할 수 있도록 스케줄링을 담당하는 역할을 하고 있다. 즉 각 non-global 존들은 커널 상에서 각각의 커널 쓰레드로 동작하고 있고 이러한 쓰레드들을 소유하고 있는 것이 바로 zsched 데몬이다.

존의 파일 시스템

특징에서 언급한대로 non-global 존은 네트워크를 통한 연결 이외에 직접적인 접근이 불가능하다. 이것은 non-global 존이 서로 독립적인 파일 시스템을 갖기 때문에 가능하다. 존을 생성할 때 각각의 존 마다 파일 시스템이 사용할 zonepath 라는 속성을 지정해 주게 된다. 예를 들어 존1은 /export/zone1, 존2는 /export/zone2 이렇게 각각의 zonepath를 지정해주게 되었을 때 존1에 들어가서 보게 되는 실질적인 루트 디렉토리 / 는 사실은 /export/zone1 이 되는 것이다. 이러한 원리로 각각의 존은 서로의 파일 시스템 영역을 침범 할 수 없도록 되어 있다.(루트 디렉토리 보다 더 밑으로 내려갈 방법은 없으니까) 존의 생성 시 파일 시스템은 기본적으로 global 존의 /usr, /lib, /platform, /sbin 디렉토리들을 읽기전용으로 루프백 파일 시스템을 통해 non-global 존에 마운트 된다. /etc, /proc, /dev, /var 등의 디렉토리는 쓰기가 가능한 상태로 마운트 된다.

존 의 활용

존은 가상화로 인한 오버헤드가 전혀 발생하지 않고 매우 안전하면서 보안성이 강하므로 많은 분야에서 유용하게 쓰일 수 있다. <그림 3>이 존을 활용할 수 있는 아이디어를 제공한다. DNS, 메일 서버, 웹 서버 등을 각 존에 분리 배치해 놓음으로써 관리가 편해지고 장애 발생 시 유연하게 대처할 수 있다. 또한 존의 특성상 다른 존의 존재 여부를 전혀 알지 못하므로 해커의 공격으로 인해 시스템 전체를 공격당할 위험이 없어진다. 서비스 시스템의 분리 외에도 소프트웨어 개발 시에 여러 개의 개발 환경을 분리된 공간에 구축해서 활용 하는 방법도 있을 수 있다.  mod3 (http://www.mod3.co.uk/) 라는 사이트는 아예 솔라리스 존 의 호스팅을 서비스 하고 있다. 이 사이트를 참고로 해서 앞으로 설명할 Branded 존을 이용한 리눅스 존 호스팅을 하는 것도 하나의 아이디어가 될 수 있겠다.

리눅스와 솔라리스 그리고 프로젝트 Janus

리눅스 사용자들이 솔라리스로 이동 하려고 할 때 가장 불편한 이유 중에 하나가 리눅스에서 사용하는 어플리케이션을 솔라리스에서 수정 없이 사용할 수 없다는 것이다. 그렇다면 솔라리스에서 리눅스 어플리케이션을 수정 없이도 실행 시킬 수 있다면 어떨까? 사실 오래전부터 이러한 노력이 있어 왔다. Sun 은 lxrun 이라는 오픈 소스 프로젝트에 참가하기도 했었고(지난 5년간 별다른 업데이트가 이루어지지 않고 있음) 리눅스를 에뮬레이션 할 수 있는 Project Janus 를 발표하면서 솔라리스10 정식 출시 때 패키지에 포함시키려는 계획을 발표 하기도 했다. 그러나 Janus는 여러 가지 문제로 출시가 계속 지연되었다. 정확한 이유는 발표되지 않았지만 필자가 듣기로 개발은 완료 했으나 여러 가지 배포판을 지원하지 못하고 존과의 결합도 이루어지지 못해서 결국 프로젝트를 원점에서부터 다시 고려했다고 한다. 결국 존과의 보조를 맞출 수 있는 프로젝트를 새로 시작했고 이 결과 리눅스 만을 위한 목적으로 진행 되었던 Janus Project 에서 한층 발전된 BrandZ 를 내 놓았다.

BrandZ 와 리눅스

Branded 존은 말 그대로 하면 존을 브랜드화 했다는 의미로 해석할 수 있다. 즉 리눅스 브랜드, 맥OS 브랜드, GNU 솔라리스 브랜드 이런 식으로 존이 브랜드를 가진다는 것이다. 이것은 네이티브 솔라리스 존이 아닌 비-네이티브 브랜드 존이 생성이 가능하다는 의미이고 그 중 제일 첫 번째로 나온 것이 리눅스 브랜드, 즉 lx 브랜드 이다. lx 브랜드는 리눅스 어플리케이션에 별다른 수정을 가하지 않아도 존에서 실행이 가능하도록 한다. 주의 할 점으로 아직까지 리눅스의 모든 배포판이 사용 가능하지는 않다는 점이다. 일단 CentOS와 그의 형님 격인 레드햇의 경우는 (특정 커널 버전 이하로만 해당. 아래의 제약사항 참조) 정상적으로 사용이 가능하고 Sun 에서도 동작을 보증하고 있다. 기타 다른 배포판의 경우 Sun 이 보증하고 있지는 않지만 필자가 알기로는 Debian 의 경우는 Debian 커뮤니티에서 시도해서 성공했다고 하고 SuSe 엔터프라이즈9 역시도 성공했다고 한다. Sun 이 지속적으로 다른 배포판의 공식적인 지원을 위해 노력하고 있다고 하니 FreeBSD 나 Ubuntu 같은 배포판의 지원도 곧 추가 될 것이라고 생각한다.

BrandZ의 제약사항

그러나 lx 브랜드는 기술의 구현 특성상 여러 가지 제약 사항이 있다. 존 자체가 OS-level Virtualization 이므로 Full-Virtualization 수준의 지원을 기대하는 것은 애초에 무리가 있다. 일단 리눅스 커널의 모든 기능을 지원하지는 않는다. 즉 리눅스 파일 시스템이나 커널 모듈, 디바이스 드라이버 등의 지원을 제공하지 않고 또한 몇몇 시스템 콜들도 지원하지 않는다. 또 한가지 제약 사항으로는 lx 브랜드가 제공하는 인터페이스가 리눅스 커널 2.4.21 버전에 glibc 2.3.2 버전에 대응하므로 이러한 버전 이후에 환경에서 빌드 된 리눅스 배포판의 어플리케이션들은 100% 동작을 장담할 수 없다는 것이다. 또한 기계적인 제약 사항으로는 현재 x86/x64 에서만 실행이 가능하다는 점이다. 이렇게 몇 가지 제약 사항과 한계 때문에 완벽한 수준의 어플리케이션 호환성을 기대했던 유저라면 실망했을 수도 있지만 현재 계속해서 발전하고 있는 프로젝트 이므로 앞으로의 발전을 지켜보도록 하자. 또한 용도에 따라서는 Xen을 사용하는 것도 방법이 될 수 있음도 기억하자.

BrandZ 설치 및 생성

BrandZ를 설치 할 수 있는 방법은 두 가지가 있다. 기존에 오픈 솔라리스를 사용하고 있다면 다운로드 페이지(http://www.opensolaris.org/os/community ··· loads%2F)에서 패키지를 직접 다운로드 받아서 설치하는 방법이 있고 이번 기회에 새로 경험을 하고 싶으신 독자분 들께서는 다운로드 페이지에 있는 BrandZ 가 합쳐진 솔라리스 익스프레스 DVD 를 다운 받아서 설치 할 수도 있고 VMWare image를 다운받아서 간단히 VMWare 에서 실행시키는 방법도 있다. 이 글에서는 BrandZ 의 자세한 생성 과정은 생략 하도록 하겠다. 생성 과정은 (http://www.opensolaris.org/os/community ··· loads%2F) 을 참고하기 바란다. 보통은 존 생성 시 별다른 문제가 발생하지 않지만 필자의 경우 DVD로 설치했을 때 존 생성 시에 약간의 오류가 있었다. SUNWlx 템플릿을 이용해서 존을 생성하는 'create -t SUNWlx' 명령을 실행 시키면 ‘SUNWlx: No such zone configured' 라는 에러가 발생 하는 것이었다. 문제를 피할 수 있는 방법은 매우 간단하다. SUNWlx 템플릿을 이용하지 않고 직접 생성 하는 것이다. ’create -B lx' 명령으로 lx 존을 만들어 주고 이후 과정을 동일하게 수행하면 별 무리 없이 문서대로 존을 설치할 수 있다. 이렇게 존을 설치 한 후에 테스트한 결과는 <화면 1>에 잘 나와 있다.

<화면 1> BrandZ 설치 완료 후의 모습

화면 중간에 'uname -a' 의 결과가 ‘BrandX fake linux’ 라고 나오는 점이 흥미롭다. 이 화면을 통해 필자가 만든 linux_zone 이라는 존이 커널 2.4.21에 기반을 둔 lx Branded 존으로 레드햇 용 gcc 가 설치 되어 있음을 확인 했다.

BrandZ의 활용

BrandZ 를 이용해서 각 리눅스의 배포판들을 위한 존을 가질 수 있으므로 이것을 활용할 수 있는 방법은 여러 가지가 있다. 특히 솔라리스로의 마이그레이션을 고려하는 사용자들에게 좋은 소식이 될 수 있다. 굳이 현재 사용하고 있는 어플리케이션을 수정하지 않고도 환경을 그대로 옮겨서 서비스 할 수 있기 때문이다. Sun 의 성능 측정 조사에 따르면 BrandZ에서 리눅스 어플리케이션의 성능은 리눅스에서의 실행과 별 차이 없다고 하므로 성능 문제를 걱정할 필요는 없을 것 같다. 또한 DTrace 의 lx 브랜드 지원도 지속적으로 추가되고 있기 때문에 리눅스 어플리케이션에 DTrace를 이용할 수도 있다는 장점을 가질 수도 있다. 결과적으로 개발자들에게는 좋은 선택이 될 수 있다. 리눅스의 각 배포판을 직접 설치하지 않고도 브랜드 존에 설치함으로써 리눅스용 어플리케이션의 테스트나 개발이 매우 용이 하고 소프트웨어 마이그레이션 작업의 환경을 손쉽게 구축 할 수 있기 때문이다.

Xen 소개

Xen 은 근래에 가장 각광 받고 있는 가상화 프로젝트 이다. Xen은 처음에 캠브리지 대학에서 시작 되었고 현재는 여러 하드웨어와 소프트웨어 벤더들이 지원하는 대형 프로젝트로 발전 했다. 미국 시간으로 2006년 12월 27일 부로 3.0.4 버전이 최선 버전으로 나와 있고 이 버전에는 기존에 불편함으로 지적했었던 GUI 형식의 관리 툴이 포함되어 있다고 한다. Xen 프로젝트를 바탕으로 공식적으로 상용 사이트가 나왔는데 주소는  http://www.xensource.com/ 이다. 관심 있는 독자는 한번 씩 방문해 보는 것을 추천한다.

Xen의 특징

Xen 디자인의 기본으로 “어플리케이션은 수정 없이 실행 가능해야 하고 성능이 빨라야 하며 서버간 VM의 마이그레이션이 쉬워야 하다” 는 데에 초점을 맞추었다고 한다. Para-Viruailization의 대표인 Xen 이 요즘에 이렇게 각광 받고 있는 데에는 오픈소스라는 점과 함께 성능이 놀라울 정도로 빠르다는 점도 큰 요인으로 작용하고 있다. 몇가지 성능 데이터를 살펴 보자. 자료 1과 자료2 를 봤을때 Native 한 실행 환경에서 실행 했을 때와 성능의 차이가 1%미만으로 나타나고 있다. 자료에 따르면 전체적으로 봤을 때에는 약 2~3% 정도의 성능차이가 난다고 한다. 성능측면 뿐만 아니라 실시간 마이그레이션의 측면에서도 엄청난 강점을 가지고 있다. 365일 24시간 돌아가야 하는 환경에서는 실시간 마이그레이션시 downtime 이 크면 클수록 엄청난 장애 요인으로 작용하게 된다. 그렇기에 다음의 그림은 꽤 놀라운 자료이다. 이 자료는 실제로 VM의 마이그레이션을 테스트 한 자료로써 리눅스월드 2005의 가상화 BoF 세션에서 발표된 것이다. <그림 4> 는 두 개의 동일한 사양을 가진 머신에 웹서버를 두고 실시간 마이그레이션 했을때 생기는 downtime을 측정한 자료이다.



 

결과 는 오직 155ms 로 1초가 약간 넘는 downtime 만에 마이그레이션이 된 것이다. 이정도면 거의 실시간이라고 봐도 무방한 데이터라고 할 수 있다. Xen의 마이그레이션에 대한 강점이 입증된 것이다.

Xen의 아키텍쳐

Xen의 구조를 이해하기 위해 Xen의 핵심인 Hypervisor에 대해 먼저 설명해 보겠다. Hypervisor는 Virtual Machine Monitor 라고도 불리며 사실 완전히 새로운 개념은 아니다. Hypervisor 는 하드웨어의 메모리, CPU, IO 장치들을 컨트롤 해주고 많은 수의 실제 디바이스들을 에뮬레이트 해준다. <그림 5>의 Xen Virtual Machine Monitor 가 바로 이 Hypervisor 인 것이다. 이 Hypervisor 위의 도메인들이 모두 가상머신이라고 보면 된다. Xen 은 이중에서 domain0 에서 시작된다. domain0 이 Xen 의 핵심 바이너리들이 있고 이 도메인에서 다른 도메인의 생성과 제거 그리고 마이그레이션 등의 관리 작업을 모두 하게 된다. 이 domain 0 을 바탕으로 domU(Unprivileged Domain 의 약자)을 실행 시킬 수 있다. 이 domU 로 인해서 마치 VMWare의 가상머신처럼 솔라리스 리눅스 윈도우즈를 한 OS 인스턴스에서 동시에 돌릴 수 있다. 즉 한창에는 윈도우를 또 다른 창에는 리눅스를 띄워 놓고 사용 할 수 있다는 것이다.

  <그림 5> Xen 의 아키텍쳐

오픈 솔라리스 dom0 과 domU

현재 dom0 호스트로써 사용할 수 있는 운영체제는 꽤 다양하다. 수세 엔터프라이즈, 레드햇 엔터프라이즈, 데비안, 페도라 젠투, FreeBSD, NetBSD 등 버전에 따라 차이는 있지만 이 모든 운영체제들이 모두 호스트로써 지원 된다. Sun 도 솔라리스 dom0을 발표 했다. dom0과 domU 모두 오픈솔라리스 Xen 프로젝트 페이지(http://opensolaris.org/os/community/xen/download)에서 설치 및 다운로드가 가능하다. 오픈 솔라리스 dom0 은 이중에서도 돋보이는 강점을 가지고 있다. 일단 DTrace의 사용이 가능하다는 것만으로도 충분히 이유가 된다고 생각한다. DTrace의 강력함은 써보면 써볼 수록 빠져들게 되는데 기회가 되면 독자 여러분들도 꼭 한번 체험해 보시기 바란다. 존, ZFS 등 다른 가상화 기술과의 연계를 통해 가상화의 단계를 극도로 끌어 올릴 수 있다는 점도 큰 강점이 될 수 있다. 오픈 솔라리스 domU의 특징도 살펴보자. 일단 32-비트 64-비트의 프로세스를 모두 지원하며 단일 프로세서와 멀티 프로세서(가상으로 무려 32-way 까지 가능함)를 지원한다. 가상 디스크와 메모리 등의 기능도 제공하며 CPU와 메모리 핫 플러그 기능까지 제공한다. 현재 Xen 버전 3.0.2-3에서 동작하며 오픈솔라리스 빌드 44 이상에서 사용이 가능하다. 아까지는 x86/x64 시스템에서만 사용이 가능하지만 수개월내에 SPARC에서도 사용이 가능 할 것이라고 한다.

오픈 솔라리스와 Xen
 
솔라리스의 존과 Xen은 서로 다른 방식의 가상화를 구현하고 있지만 그렇다고 서로가 대립되는 개념은 아니다. 오히려 상호 보완적인 관계로 사용 할 수 있다는 점에서 좋은 협력자가 될 수 있다. 둘 다 모두 발전의 단계를 지나 성숙의 단계로 나아가고 있기 때문에 앞으로 협력의 좋은 모델이 나올 것이라고 믿는다. 오픈 솔라리스 Xen과 관련된 자세한 정보는 커뮤니티 페이지 http://opensolaris.org/os/community/xen/ 에서 확인하기 바란다.

CrossBow 프로젝트 소개

CrossBow는 네트워크 수준의 가상화를 이룩한 프로젝트이다. 사실 네트워크 수준의 가상화는 여러 가지 많은 제약사항이 따르는 작업이다. 일단 솔라리스는 커널의 큐에 있는 패킷 데이터를 인터럽트를 통해 처리하기 때문에 기술 구현의 난이도가 있고 네트워크 리소스 관리를 위해 추가적인 처리 작업이 일어날 경우 수많은 패킷이 오고 가는 네트워크 환경에서는 그로 인해 발생하는 오버헤드가 무시하지 못할 정도가 되기 때문이다. 이러한 문제점을 해결하고 또한 global 존이 non-global 존과 하나의 네트워크 스택을 공유하기 때문에 발생하는 분리의 문제를 해결하기 위해 Sun 은 CrossBow 프로젝트를 시작 하게 된다. CrossBow의 프로젝트 페이지는 http://www.opensolaris.org/os/project/crossbow/ 이고 여기서 최신 정보들과 Early Access 버전을 다운로드 받을 수 있다.

CrossBow 의 기본

오픈 솔라리스에서는 VNIC 라고 하는 가상 네트워크 인터페이스 카드(Virtual Network Interface Card)라는 개념이 정의 된다. 이 VNIC는 물리적인 여러 개의 NIC를 논리적인 가상 NIC들로 나누어서 이것들을 존이나 Xen 에 지정 할 수 있도록 해 준다. 한 개의 1G 혹은 10G의 NIC를 여러개로 나누는 것도 가능하다. CrossBow는 이 VNIC 혹은 서비스와 프로토콜 별로 우선순위와 대역폭의 한계를 지정 할 수 있다. 또한 존에 어떤 특정한 네트워크 스택을 지정하는 것도 가능하다. <그림 6>을 통해 좀 더 자세히 살펴 보자

 <그림 6> CrossBow VNIC의 예제
그림을 보면 각 존에 VNIC를 지정했음을 알 수 있다. 그리고 Flow Classifier라는 NIC의 중간 계층이 각 프로토콜 혹은 서비스 별로 Squeue와 연결된 모습을 볼 수 있다. 여기의 Squeue 는 FireEngine, Nemo 에서 파생되어 나온 것으로 Squeue 와 Flow Classifier의 상호 작용에 의해 CrossBow의 리소스 관리 작업이 이루어진다.


FireEngine과 Nemo

기존 솔라리스의 네트워크 스택 속도 문제를 해결하기 위해 완전히 새로운 형태의 스택을 만들어내서 속도를 혁신적으로 향상시킨 기술이다. 현재 솔라리스 10의 초기 버전과 비교하여 솔라리스 10 업데이트1 이후 그리고 솔라리스 익스프레스의 네트워크 스택은 계속해서 새로워지고 있다. Nemo의 경우 고성능을 위한 새로운 디바이스 드라이버 프레임웍이다. 이 두 기술의 조합으로 인해 솔라리스의 네트워크 속도가 이전 9이전 버전에 비해 혁신적으로 빨라졌다.

CrossBow 와 Xen

<그림 7> CrossBow 와 Xen

앞에서도 언급했지만 CrossBow를 Xen 과 같이 사용할 수도 있다. CrossBow와 Xen의 연동 구조는 <그림 7>에 나와 있다. <그림 6>의 존과의 연동과 구조는 거의 비슷하다. 다만 한가지 차이가 있다면 dom0 호스트의 NIC Virtualization Engine을 통해 domU VNIC 들의 리소스의 제어가 이루어진다는 점이다.

CrossBow 의 장점

CrossBow는 DOS(Denial Of Service) 공격에 방어 할 수 있는 구조로 되어 있다. 일단 공격을 받으면 오직 해당 되는 서비스 혹은 가상 머신만이 영향을 받게 되고 해당 서비스의 새로운 연결은 모두 최하의 우선순위를 가지도록 한다. 후에 어플리케이션이 인증이 되면 다시 우선순위를 정상으로 되돌려 놓는다. 이러한 구조 때문에 DOS의 공격에도 안전한 구조로 되어 있다. squeue 별 사용량 통계를 얻을 수 있는 기능을 통해 적절한 네트워크 설계를 할 수도 있다. 통계는 컨테이너별, 서비스 혹은 프로토콜별로 주기적으로 낼 수 있기 때문에 이 자료를 토대로 VNIC 구조를 개선 시켜 나갈 수 있다.

CrossBow 의 현황 및 전망

현재 CrossBow는 Early Access 상태로 VNIC의 핵심 기능, TCP의 대역폭 조절 기능, 스택 인스턴스 기능 등만이 구현된 상태이다. 오직 일부분만이 구현된 상태로 테스트 목적이외의 용도로 사용하는 것은 무리다. 시작되지 얼마 되지 않은 프로젝트로써 벤치마크 등의 자료를 구하기도 힘들지만 CrossBow의 개념과 그 활용 가능성만으로도 기대를 걸어 볼 만할 것 같다는 것이 필자의 생각이다. 오픈 솔라리스의 CrossBow 커뮤니티 페이지에서 새로운 소식이 나오기를 기다려 보자.

마무리 하며

이상으로 오픈 솔라리스의 가상화 기술들에 대해 간단하게나마 살펴보았다. 존, Xen, ZFS, CrossBow 등 혁신적인 가상화 기술들을 포함하고 있는 오픈 솔라리스는 개발자들에게나 신기술을 좋아 하는 geek 들에게는 분명 매력적인 하나의 ‘도구’ 가 될 수 있다. 필자가 제일 아쉬운 것은 국내의 오픈 솔라리스에 대한 관심도가 너무 낮다는 것이다. 엔터프라이즈 유닉스 시장에 살아남은 몇안되는 운영체제 중 하나이고 게다가 오픈 소스인 이 운영체제는 사람들의 관심을 받을 만한 가치가 충분히 있다고 생각한다. 오픈 솔라리스 커뮤니티의 멤버로써 2007년에는 오픈 소스 운영체제에는 ‘리눅스’ 만 있는 것이  아니라 ‘오픈 솔라리스‘도 있다는 것과 더불어 여러 사람들이 오픈 솔라리스 프로젝트에 참여해서 같이 활동 했으면 좋겠다는 것이 필자의 바램이다.