Search

'Xen'에 해당되는 글 4건

  1. 2017.01.07 5. 이벤트 채널 소개
  2. 2016.11.06 3. Domain간 통신 방법
  3. 2016.11.05 2. Xen 기본 구조/Hypercall
  4. 2016.11.05 1. Xen Project 소개

5. 이벤트 채널 소개

컴퓨터공부/가상화기술 2017.01.07 17:52 Posted by 아는 개발자 아는 개발자

이벤트 채널에 대해 설명하기 전에 인터럽트에 대해서 간단히 소개를 하자. 인터럽트는 CPU에 즉각적인 처리가 필요한 작업을 알리는데 사용되는 프로세스이다. 사용 방법은 네트워크, 블럭 드라이버 같은 하드웨어에 처리가 필요한 작업이 들어온 경우 인터럽트 핸들러에 알리고, 요청을 받은 인터럽트 핸들러는 이들의 요구 사항을 디바이스 정보와 함께 CPU에 전달한다. CPU는 현재 실행중인 프로세스를 잠시 중단 시키고 요청을 처리한다. 인터럽트가 있기 때문에 나는 블로그 포스트를 쓰면서도 친구의 카톡메시지를 동시에 받을 수 있다.


이벤트 채널의 역할은 인터럽트와 거의 동일하다. 단지 쓰이는 곳이 다를 뿐이다. 앞서 포스트에서 DomainU들은 Domain0와 Frontend-Backend Driver 관계를 가진다고 했다. 이 둘 간에 통신 채널이 존재하고 Grant table로 데이터를 전송하고 Ring으로 두 드라이버 사이에 요청/응답을 전달 한다고 했다. 그럼 요청/응답이 왔다고 알리는 건 어떻게 할까? 그냥 Domain들이 Polling방식으로 매번 Ring을 검사하기엔 오버로드가 클 것이다. 이때 필요한 것이 이벤트 채널이다.


(도메인 간에 이벤트 채널로 연결되어있다)


이벤트 채널 구성은 인터럽트와 비슷하다. 기존 OS에서 각 장치별로 IRQ가 있었듯이, 이벤트 채널은 각 장치마다 port번호가 존재하고 이를 Domain은 포트 번호에 맞춰 지정된 Backend/Frontend에 알림을 준다. Interrupt Handler들을 각 Domain들마다 가지고 있다고 생각하면 편하다.

'컴퓨터공부 > 가상화기술' 카테고리의 다른 글

QEMU와 KVM - 1  (0) 2017.11.01
6. XenStore, Xenbus  (0) 2017.01.22
5. 이벤트 채널 소개  (0) 2017.01.07
가상화기술의 대표적인 보안 문제  (0) 2016.12.10
4. Domain 장치 드라이버 개발  (0) 2016.11.27
3. Domain간 통신 방법  (0) 2016.11.06

3. Domain간 통신 방법

컴퓨터공부/가상화기술 2016.11.06 12:49 Posted by 아는 개발자 아는 개발자

Guest OS들은 동작하면서 Block, Network Device처럼 다양한 장치에 접근할 일이 생긴다. Domain0는 Real Hardware driver를 갖고 있기 때문에 직접 접근 할 수 있지만, DomainU는 Control Domain의 역할을 하는 Domain0를 거쳐서 접근해야 한다. DomainU는 Domain 0에게 전송을 요청할 뿐만 아니라 Domain0에게 전송할 데이터들을 전달해야하는데 이때 Domain간에 통신 메커니즘이 필요하다.


가상머신에서 잠깐 물러나 일반 OS를 생각해보자. 두 개의 프로세스가 메시지를 전달 하는 방법은 여러 가지가 존재한다. 간단히 file에다가 값을 입력하는 방식도 있고 socket, pipe 공유메모리까지 사용 환경과 목적에 맞춰서 적용이 가능하다. 


(Wikipedia에 작성된 주요 IPC 메커니즘)


Xen은 프로세스간 통신 방법 중 공유 메모리(Shared Memory) 방식을 Domain간 통신 방법으로 적용 했다. 서로 통신하려는 두 Domain들을 Process 형태로 보고 Xen은 이를 관리하는 OS의 역할이다. 두 Domain중 하나가 Xen에게 공유메모리 영역 할당을 요청하면 Xen은 두 Domain이 공유 할 수 있는 메모리 영역을 할당한다.


공유 할 수 있는 영역을 할당 받은 Domain들은 이곳에 전달할 데이터 값을 쓰고 전달 받은 데이터 값을 읽어야 하는 Domain은 해당 영역의 값을 읽는 방식이다. Xen은 공유 메모리 영역을 페이지 단위로 할당했다.


Xen은 Grant Table이라는 자료구조로 Domain간 메모리 공유를 지원한다. Grant Table은 현재 Domain이 어떤 Domain과 매핑을 하고 있는지, 상태는 어떠한지를 정보를 저장해둔 자료구조이다. 메모리 영역을 할당 받으면 각 Domain들은 grant table의 entry 값을 업데이트해 어떤 방식으로 메모리 매핑이 이뤄져 있는지 정보를 저장한다.


특정 영역에 메모리 정보를 입력하고 grant table이 관리를 하는 것은 알겠다. 그런데 메모리 정보를 입력하기도 전에 다른 Domain이 해당 정보를 읽으려고 하면 문제가 될 것이다. Xen은 경우를 관리 하기 위해 Ring 이라는 비동기식 통신 채널을 만들었다.

Domain들은 Domain0와 연결된 분리장치 드라이버(backend/frontend)에서 각각 ring으로 연결되어 있고 이 ring을 통해 요청/응답처럼 간단한 메시지 값들을 전달한다. 원형으로 된 구조이며 해당 entry에 요청 값을 입력하면 반대편 Domain driver에서 요청 값을 읽고 응답 값을 배열 뒤편에 입력해주는 방식으로 구성된다. Domain들은 여기서 받은 요청 값을 읽고 grant table에 값을 입력/확인 한다.

'컴퓨터공부 > 가상화기술' 카테고리의 다른 글

가상화기술의 대표적인 보안 문제  (0) 2016.12.10
4. Domain 장치 드라이버 개발  (0) 2016.11.27
3. Domain간 통신 방법  (0) 2016.11.06
2. Xen 기본 구조/Hypercall  (0) 2016.11.05
1. Xen Project 소개  (0) 2016.11.05
가상화기술 Type1  (0) 2016.09.11

2. Xen 기본 구조/Hypercall

컴퓨터공부/가상화기술 2016.11.05 20:52 Posted by 아는 개발자 아는 개발자

Xen 기본 구조를 설명하기에 앞서 Hypervisor의 기본 형태중 Type 1에 대해서 간단히 설명을 한다.


Type1은 가상머신을 관리하는 Hypervisor가 OS처럼 직접 하드웨어를 통제하고 VM(Guest OS)들은 Hypervisor 위에서 동작하는 형태이다.



스케줄러, MMU, Page table처럼 OS의 기본적인 기능들을 Hypervisor가 갖고 있고 위 기능들을 잘 이용해서 여러 개의 Guest OS들을 관리한다(작은 OS인 느낌이다). 기본적인 개념은 Type1 Hypervisor들이 모두 같으나 Guest OS를 관리하는 메커니즘은 Hypervisor마다 차이가 있다.



Xen은 Guest OS들을 도메인이라 부르고 Domain이 생성된 순서에 따라 Domain + 생성순서로 이름을 붙인다. Domain중 Xen에서 가장 기본적으로 생성되는 Domain0는 Control Domain이라 한다. Control Domain의 역할은 말그대로 Control이다. Xen 부팅 될 때 생성되어 다른 Domain들을 부팅/종료 하고 Domain의 하드웨어 접근 작업을 관할 한다.


Domain들의 하드웨어 접근 작업을 관할한다는 것이 쉽게 와닿지 않을 것이다. 아마 Type1 구조를 본사람들은 가상화 환경에 대해 다음과 같은 형태를 상상 했을 것 같다


Control Domain 같은거 없이 모든 Guest OS들은 서로 동등하고 각각 자신이 필요할 때마다 Hypervisor를 통해서 Hardware에 접근하는 것이다. 내가 처음에 가상화를 공부할 때 이런 형태로 Type1을 이해했다.


하지만 위와 같은 형태로 만들어 질 때 결과를 예측해보자. 모든 Guest OS들은 각자 출력하고 싶은 것들을 모니터에 출력하려고 할 것이다. 하지만 모니터 장치는 하나이다. 그렇다면 각각의 GuestOS들이 출력한 결과물들을 모두 출력할 것인가? 그건 애초에 예상했던 결과물이 아니다. 가상화 소프트웨어는 여러개의 GuestOS를 동시에 부팅하고, 사용자가 번갈아가면서 모니터를 사용 할 수 있는 환경을 제공하려고 한다.


Xen은 위와 같은 경우의 관리를 Control Domain에게 맡겼다. Guest OS들의 드라이버 접근들을 직접 관할해 어떤 Domain이 하드웨어에 Access 하려고 하며 접근 명령을 받아 직접 Hardware에 Access 하는 작업을 Control Domain인 Dom0가 관리한다.

(Xen에게 관리를 맡길 수도 있겠지만 Xen을 lightweight하게 만들기 위해 Domain0를 둔 것으로 보인다)




위와 같은 구조에서 DomainU는 하드웨어에 접근하기 위해 반드시 Xen을 통해 Domain0에 신호를 보내야 하는 것으로 보인다. 하지만 이런 형태는 일반적인 OS시간에 배운 내용이랑 다르다. OS는 드라이버에서 하드웨어에 접근하기 위해 System Call을 사용하는데, 그러면 OS의 형태인 DomainU는 어떻게 명령어를 전달하는가?


Xen은 Domain들이 하드웨어에 접근 할 때 사용하는 명령어로 Hypercall을 두었다. Hypercall은 Systemcall과 Hypervisor에서 사용하는 systemcall이라는점만 제외하면 기능상으로는 동일하다. 단지 바로 Hardware에 접근하지 않고 Xen에게 명령을 전달한다는 점만 다를 뿐이다. Xen은 Guest OS에서 전송한 Hypercall을 받고 이를 Domain0 에게 신호를 전달한다. Domain0는 전송받은 값들을 갖고 직접 Hardware에 Access한다.


위와 같은 형태로 구현되려면 기존 OS에서 드라이버들이 Systemcall이 아닌 Hypercall들로 대체되어야 한다. 이런 이유로 Xen을 Guest OS들을 수정한 Para-virtualization 구조라 한다.

'컴퓨터공부 > 가상화기술' 카테고리의 다른 글

4. Domain 장치 드라이버 개발  (0) 2016.11.27
3. Domain간 통신 방법  (0) 2016.11.06
2. Xen 기본 구조/Hypercall  (0) 2016.11.05
1. Xen Project 소개  (0) 2016.11.05
가상화기술 Type1  (0) 2016.09.11
가상화기술 Type2  (0) 2016.09.11

1. Xen Project 소개

컴퓨터공부/가상화기술 2016.11.05 19:38 Posted by 아는 개발자 아는 개발자

반가상화(Para-virtualization) 소프트웨어로 가장 대표적인 Xen에 대한 포스트를 앞으로 써보려고 한다. 이번 포스트에서는 Xen에 대한 소개와 역사 및 앞으로의 포스트 순서에 대해서 소개해보려 한다.


1. 소개 


Xen은 Para-virtualization 형태로 여러 개의 Guest OS를 실행 할 수 있는 Hypervisor이다. 현재 Xen community에서 오픈소스의 형태로 개발중(www.xenproject.org)이며 작업에 따라서 여러가지 브랜치로 나눠져 있다. 크게 다음과 같이 세가지 Feature를 지원하는 것을 목표로 작업이 나눠져 있다.


 Feature

 Value 

 Hypervisor 개발

 여러개의 반가상화 Guest OS를 동시에 실행 할 수 있는 플랫폼을 개발한다. 확장성, 성능, 보안성, 유연성등 최적화된 가상화 환경을 만드는 작업으로 이뤄진다.

 Guest OS 수정 작업

 Xen은 반가상화 형태의 Hypervisor이기 때문에 Guest OS들의 수정이 필요하다. Xen community에서는 Linux, Windows, NetBSD, FreeBSD와 같이 점유율이 있는 OS들에 대해 Xen에 포팅 될 수 있도록 변경하는 작업을 진행한다.

 Cloud platform 제공

 여러가지 클라우드 환경(CloudStack, OpenStack)에 적용 될 수 있는 플랫폼을 제공한다. 


* Cloud platform 제공은 서버 가상화에 대한 내용인데 이건 Xen Server Project에서 별도로 관리한다. OS virtualization과 성격이 많이 다르다 보니 그런 것 같다. 이쪽은 아직 한번도 보지 않았기 때문에 패스한다.




마스코트는 닌자 판다를 쓰고 있다. 닌자인지 아닌지는 모르겠지만... Xen 관련 Slide Share와 wiki xen page의 첫장에 등장 한다.

어려운 내용을 설명하기 전에 잠시 머리 식히기 위한 의도(?) 인건지 그냥 리눅스 펭귄에서 따온건지 모르겠다. 전혀 가상화랑 관련 없어보이지만 왠지 모르게 친숙한 느낌을 주는 마스코트이다.


2. 역사


1990년대 후반에 XenoServer 프로젝트로 시작되어 왔고 2002년에 오픈소스의 형태로 재출범이 되었다고 한다. 그후 1년만에 정식 Xen 1.0 버전을 출범했고 x86 아키텍쳐에서만 만들다가 2008년에 Xen-ARM 프로젝트가 만들어졌다(삼성전자가 만들었다고 한다) 2009년에는 Xen Cloud Platform이 출범 되었다고 한다. 


2011년에는 리눅스 2.6.37에서 Xen의 Dom0로 부팅 할 수 있도록 릴리즈 되었고 3.x 버전 부터는 Xen Dom0, DomU 동시에 지원이 되도록 추가되었다고 한다. 대표적인 OS의 추가 기능으로 들어갔으니 아마 이때부터 Xen이 기술력을 인정받는 순간이 아니었나 싶다. 리눅스 OS를 다운 받으면 폴더 파일 명중 Xen이 있고 Xen에 포팅 될 수 있는 GuestOS로 컴파일 할 수 있도록 지원한다.


현재 버전은 4.7.0 까지 stable한 버전으로 릴리즈가 되었고 3.0 인가 부터는 Fully Virtualization도 지원한다고 된 것 같은데 많이 활성화는 된 것 같지 않다. 


정식 출범 이후 거의 13년 가까이 이뤄진 프로젝트인 만큼 기술적으로 안정적이고 대중적으로는 인지도를 가지고 있다. 많은 회사에서 Xen 을 이용해 가상화 기술을 만들고 있다고 한다(Community의 말로는 그렇다)


3. 앞으로 포스트 순서


가상화에 대한 기본적인 개념(Para/Full virtualization 정도는 구분 하는)을 알고 있으면서 Xen을 한 번도 접해보지 않은 사람들을 위한 포스트를 쓰려고 한다. Xen Feature중 Hypervisor 개발에 대한 내용들을 먼저 다루고 xenstore, xen-qemu처럼 Constrol Domain에 대한 내용은 후반부에서 다룰 예정이다. 다음의 순서로 포스트를 작성할 예정이다.


  1. Xen 기본 구조, Hypercall
  2. Domain간 메모리 공유 방법
  3. Xen용 장치 드라이버 만들기
  4. Xenstore, Xenbus


'컴퓨터공부 > 가상화기술' 카테고리의 다른 글

3. Domain간 통신 방법  (0) 2016.11.06
2. Xen 기본 구조/Hypercall  (0) 2016.11.05
1. Xen Project 소개  (0) 2016.11.05
가상화기술 Type1  (0) 2016.09.11
가상화기술 Type2  (0) 2016.09.11
가상화 기술의 유형  (0) 2016.09.06