Virtio Block 성능 세부 분석

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

예전 포스트에서는 iozone을 이용해 Virtio block 드라이버의 성능을 간단하게 측정해봤다면  이번 글에는 범용적으로 사용되는 스토리지 벤치마크인 fio를 이용해 Virtio Block의 성능을 좀더 디테일하게 분석해보려고 한다.


실험의 큰 단위를 Sequential, Random으로 나누고 각각의 I/O size를 바꿔봤을 때 Host와 VM의 성능 차이가 어느 정도 나오는지를 분석 해봤다.


1. Seq 512K, Rand 4K


 

 Host

VM 

Ratio 

Random Read 

7705MB/s 

5184MB/s 

67% 

Random Write 

120MB/s 

69.9MB/s 

58% 

Sequential Read 

13.5GB/s 

12.4GB/s 

91% 

Sequential Write 

501MB/s 

346MB/s 

69% 


Sequential에는 512K의 io size를, Random인 경우에는 4K 단위로 io size를 줬다. 이 값들은 실제 스토리지 벤치마크에서 자주 사용되는 단위다. 


결과 값의 편차가 크기는 하지만 Sequential의 경우가 Random의 경우보다 성능이 더 잘 나오는 것으로 보인다. 그런데 random이 sequential 대비 성능이 이렇게 떨어지는 것은 이상해 보인다. 읽는 과정은 크게 차이가 없어 보이는데 말이다.


2. Random 512K 


 

 Host

VM 

Ratio 

 Random Read

13.3GB/s 

12.5GB/s 

93% 

 Random Write

524MB/s 

366MB/s 

70% 


Random Access가 원인이기 보다는 I/O size의 크기에 따라 성능이 달라지는 것 같아서 Random의 경우에도 Sequential과 동일하게 I/O 사이즈를 512K로 줬다. 그러자 Sequential 때와 거의 비슷한 수준으로 성능이 나타났다. I/O 사이즈에 따라서 성능이 들쭉날쭉한다. 


3. Virtio Block Process Sequence




간략하게 표현하면 Virtio Block 드라이버의 처리 루틴은 위와 같은 방식으로 이뤄진다. 실제 스토리지 장치에 접근하는 Block Driver는 Native와 똑같은 장치를 사용하고 있으니 이 지점에서는 Native와 Virtual Machine 모두 똑같은 원리로 동작해 성능 차이가 나지 않는다. 오버헤드가 발생할 수 있는 부분은 이 지점 이외의 부분, VM에서 Block 드라이버까지 요청이 전달 되는 화살표로 표현한 과정에서 발생한다. 화살표 요청의 횟수가 적을수록 Native에 비슷한 성능을 내고 많을수록 저조한 성능을 보인다.


4. I/O operations between 4K random and 512K random 


QEMU의 trace 기능을 이용해 4K일 때와 512K일 때 Virtio Block 함수를 호출하는 횟수를 측정 해봤다.


 

 4K

512K 

 4K / 512K

 Random Read

 279727

25733 

 10.87 : 1

 Random Write 

 3920485

141694 

 27.6687


Read의 경우에는 4K의 경우가 512K보다 10배 정도 더 Virtio Block 관련 함수를 호출하고 Write의 경우에는 27배 더 호출하고 있다. 호출 횟수와 실제 성능과 비교해보면 Random Read의 Host 대비 성능(67%)이 Random Write의 결과값(58%)보다 높게 나온 것으로 보아 Virtio Block 함수 호출 횟수와 어느정도 비례하고 있는 것을 알 수 있다. 


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

Virtio Block 성능 세부 분석  (0) 2019.05.20
Virtio Block 성능 벤치마크  (0) 2018.12.23
QEMU를 이용해 커널 이미지 바꿔서 부팅해보기  (0) 2018.12.20
kvm ioeventfd  (0) 2018.08.11
kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08
TAG Block, FIO, virtio

Virtio Block 성능 벤치마크

컴퓨터공부/가상화기술 2018.12.23 14:08 Posted by 아는 개발자 아는 개발자

QEMU와 KVM환경에서 띄운 Ubuntu VM의 스토리지 성능을 Virtio Block을 사용할 때와 아닐 때를 각각 나누어서 측정을 해보았고 최적화 옵션을 적용할 때 Host대비 얼마정도의 성능을 내는지도 실험 해봤다.


1. 실험 방법


벤치마크툴은 iozone을 사용했고 적용한 옵션은 다음과 같다.

iozone -e -I -a -s 100M -r 4k -r 4096k -r 16384k -i 0 -i 1 -i 2


여기서 주목해야할 옵션 항목만 짚고 넘어가자.

  • -r 은 record할 사이즈를 말하며 여러개의 인자를 전달하면 인자의 개수만큼 측정한다.
  • -i 는 측정할 실험 항목을 의미한다. (0=write/rewrite, 1=read/re-read, 2=random-read/write)
  • -s 는 읽고 쓸 데이터의 크기를 의미한다.

2. 실험환경


Host 환경


- CPU: Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz

- Memory: 8G

- Storage: SSD


Guest VM 환경


- CPU: Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz

- Memory: 4G

- Storage: VirtioBlock(1) / Qemu Storage(2)


3. 측정결과 및 분석


(1) Record Size: 4K


4K

write

rewrite

read

reread

R/Read

R/Reread

Host

108531

140209

130116

149202

41372

108057

VM(VirtioIO)

56260

76539

74808

76864

33816

73393

VM(QEMU Storage)

10231

13252

11558

15289

13324

17782


(2) Record Size: 4096K


4096K

write

rewrite

read

reread

R/Read

R/Reread

Host

475827

493225

500618

506168

506449

491150

VM(VirtioIO)

381458

385537

406131

403043

408653

387712

VM(QEMU Storage)

254328

260574

261297

268813

254842

259518


(3) Record Size: 16384K


16384K

write

rewrite

read

reread

R/Read

R/Reread

Host

495826

502281

524808

521351

520112

502445

VM(VirtioIO)

394283

431118

423213

417768

435611

418307

VM(QEMU Storage)

276397

269190

273982

288246

288831

268841


* 결과 단위는 KB/S이다.


- 측정 단위가(Record Size) 작을수록 VirtioBlock과 QEMU Storage의 성능차이가 많이 나며 커질 수록 어느정도 좁혀지나 40~60% 정도 Virtio Block의 성능이 더 우수한 것으로 수렴한다.


- QEMU Storage 일때는 Host의 절반 정도(53%~55%)이지만  Virtio Block 옵션을 적용하면 Host 대비 80% 정도의 성능을 낸다. Host의 Storage 성능이 워낙 빠르기 때문에 (SSD) 20% 정도의 성능을 손해보더라도 불편함없이 사용할 수 있을 것 같다.


- SSD로 띄운 VM은 최적화 옵션을 넣지 않아도 HDD로 띄운 Host보다 성능이 우수하게 나온다. 성능 구린 PC를 하나 더 사는 것 보다는 성능 좋은 PC에 Virtual Machine을 띄우는게 경제적으로나 성능적으로나 우수해보인다.


16384K

write

rewrite

read

reread

R/Read

R/Reread

Host(HDD)

135480

126629

155426

168672

136012

126976

VM (Virtio based SSD)

394283

431118

423213

417768

435611

418307

VM(QEMU Storage)

276397

269190

273982

288246

288831

268841


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

Virtio Block 성능 세부 분석  (0) 2019.05.20
Virtio Block 성능 벤치마크  (0) 2018.12.23
QEMU를 이용해 커널 이미지 바꿔서 부팅해보기  (0) 2018.12.20
kvm ioeventfd  (0) 2018.08.11
kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08

QEMU를 이용해 커널 이미지 바꿔서 부팅해보기

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

전가상화를 지원하는 QEMU는 게스트 커널을 수정하지 않고 띄울수 있다는 장점이 있지만 virtio 같은 최적화 옵션을 사용하려면 커널의 일부 수정이 필요하다. 기존에 게스트 이미지에 내장된 커널을 수정하는 방법으로 가장 쉽게 떠올릴 수 있는 것은 게스트를 띄운 다음 이 안에서 커널 코드를 수정하고 빌드하는 것인데 답답한 게스트의 성능때문에 오래 걸리고 답답하다.


QEMU에서는 이런 점을 고려해서 파라미터를 이용해 사용할 커널 이미지를 지정할 수 있도록 만들었다. 개발자는 호스트 PC 환경에서 게스트에서 사용할 커널 이미지를 빌드한 후 스크립트에 -kernel 파라미터로 지정하면 된다. 


#!/bin/bash
DISK_PATH=.

qemu-system-x86_64 \
        -cpu host \
        -smp 8 \
        -enable-kvm -m 2048 \
        -kernel ./bzImage \
        -append "root=/dev/vda1 console=ttyS0" \
        -drive file=${DISK_PATH}/ubuntu.qcow2,cache=none,if=virtio \
        -display gtk \


위 스크립트에서 -append라는 옵션이 보이는데 이건 커널의 커맨드라인(cmdline)으로 들어갈 스트링을 지정할 수 있는 파라미터다. 새로 빌드한 커널에는 CONFIG_VIRTIO_BLK 옵션을 넣었기 때문에 커널에서 마운트할 디바이스의 이름(/dev/vda1)를 이곳에 기입했고 console로 시리얼 값을 보기 위해 ttyS0 옵션을 넣었다. 이게 없으면 따로 커널 코드에 넣지 않는 이상 마운트하다가 죽는다.


위의 올린 스크립트를 이용해 실행해보니 부팅이 정상적으로 된다. VIRTIO_BLK 옵션이 들어가서 그런지 예전보다 부팅이 조금 빨라진 것 같았다. 그래도 커널이 정상적으로 바뀌었는지 'uname -r' 명령어로 확인해봤다. Makefile에 넣은 EXTRAVERSION 값이 내 아이디로 들어간 것으로 보아 커널이 바뀐 것을 확인할 수 있었다.




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

Virtio Block 성능 세부 분석  (0) 2019.05.20
Virtio Block 성능 벤치마크  (0) 2018.12.23
QEMU를 이용해 커널 이미지 바꿔서 부팅해보기  (0) 2018.12.20
kvm ioeventfd  (0) 2018.08.11
kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08

kvm ioeventfd

컴퓨터공부/가상화기술 2018.08.11 23:10 Posted by 아는 개발자 아는 개발자

* 개인 공부용으로 정리한 것이라 부정확한 내용이 있을 수 있으니 참고용으로만 사용하길 바랍니다.


IOEVENTFD


eventfd를 응용해서 guest에 interrupt를 보낼 수 있는 기능을 만든 irqfd것과 비슷하게 ioeventfd도 eventfd를 이용해서 guest에게 mmio 기능을 전달 할 수 있는 매커니즘을 만들었다. 초기화 작업도 irqfd와 거의 비슷하다.


1. QEMU에서 kvm으로 mmio 값 전달.


QEMU에서 장치가 사용할 주소 값과 flag, eventfd 값을 세팅하고 kvm에 ioctl 을 날린다. 이때 전달인자 fd는 MemoryRegionIoeventfd 라는 구조체의 EventNotifier 값을 뽑아낸 것이다. 구조체 이름이 매우 와닿지 않는다.

// qemu/accel/kvm-all.c
static int kvm_set_ioeventfd_pio(int fd, uint16_t addr, uint16_t val, 
                      bool assign, uint32_t size, bool datamatch)
{
    struct kvm_ioeventfd kick = {
        .datamatch = datamatch 
                       ? adjust_ioeventfd_endianness(val, size) : 0, 
        .addr = addr,
        .flags = KVM_IOEVENTFD_FLAG_PIO,
        .len = size,
        .fd = fd,
    };   
    r = kvm_vm_ioctl(kvm_state, KVM_IOEVENTFD, &kick);

2. 받은 값을 이용해 _ioeventfd 자료구조 생성 및 초기화


_ioevent라는 자료구조를 선언하고 qemu 에서 전달한 값을 세팅한다. args는 QEMU에서 전달받은 인자 값이고 eventfd는 MemoryRegionIoeventfd 의 EventNotifer의 파일 디스크립터 값이다. VirtQueue와 비슷하게 선언된 것 같다.

// virt/kvm/eventfd.c
static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
                enum kvm_bus bus_idx,
                struct kvm_ioeventfd *args)
{
    // HK: Define ioeventfd data structure
    INIT_LIST_HEAD(&p->list);
    p->addr    = args->addr;
    p->bus_idx = bus_idx; // HK: bus_idx is defined by ioeventfd flag
    p->length  = args->len;
    p->eventfd = eventfd;
}

3. IO Device 초기화


초기화한 _ioeventfd에 ioeventfd 작업인 write와 destructor 함수를 세팅한다.. kvm ioeventfd 기반에서 사용할 수 있는 함수들을 설정하는 작업으로 보면 될 것 같다. ioeventfd_write 함수는 쓰려는 값이 range 안에 있는지 확인하고 있으면 eventfd_signal을 보낸다. 값을 업데이트해서 QEMU에 알림을주려는 용도다. 

// virt/kvm/eventfd.c
static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
                enum kvm_bus bus_idx,
                struct kvm_ioeventfd *args)
{
    // HK: Set ioeventfd operation for this device
    kvm_iodevice_init(&p->dev, &ioeventfd_ops);

static const struct kvm_io_device_ops ioeventfd_ops = {
    .write      = ioeventfd_write,
    .destructor = ioeventfd_destructor,
};

/* MMIO/PIO writes trigger an event if the addr/val match */
static int
ioeventfd_write(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
      gpa_t addr, int len, const void *val)
{
    struct _ioeventfd *p = to_ioeventfd(this);

    if (!ioeventfd_in_range(p, addr, len, val))
        return -EOPNOTSUPP;
            
    eventfd_signal(p->eventfd, 1);
    return 0;
}

4. KVM IO bus 등록


mmio로 사용할 주소와 bus index, mmio 동작 작업을 kvm io bus에 등록한다. 버스에서는 등록된 mmio 장치의 주소 값을 보고 event를 날려주는것 같다. bus쪽은 공부가 좀더 필요한 부분이다.

    ret = kvm_io_bus_register_dev(kvm, bus_idx, p->addr, p->length,
                      &p->dev);
    if (ret < 0) 
        goto unlock_fail;
    
    kvm->buses[bus_idx]->ioeventfd_count++;


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

Virtio Block 성능 벤치마크  (0) 2018.12.23
QEMU를 이용해 커널 이미지 바꿔서 부팅해보기  (0) 2018.12.20
kvm ioeventfd  (0) 2018.08.11
kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08
virtio  (0) 2018.07.08

kvm irqfd

컴퓨터공부/가상화기술 2018.08.11 14:02 Posted by 아는 개발자 아는 개발자

* 개인 공부용도로 정리한 것이라 부정확한 정보가 있을 수도 있으니 참고용으로만 사용하세요.


IRQFD


irqfd는 QEMU에서 정의한 eventfd와 GSI(Global System Interrupt) 값을 이용해서 Guest에 바로 interrupt를 바로 쏘아 줄 때(irqfd_inject) 사용하는 kvm interrupt 라이브러리다. 간단한 event를 만들 때 사용하는 eventfd 메커니즘을 응용한 대표적인 예다. 


좀더 디테일한 동작 내용을 이해하기 위해 초기화 코드를 순서대로 분석해보자. 


1. QEMU 장치 정보 세팅 후 kvm으로 ioctl 전달


QEMU에서는 장치가 사용하려는 GSI(Global system interrupt)와 상태에 대한 정보를 저장하는 flag 값 그리고 qemu/VM 간 데이터를 주고받는 통로인 virtqueue의 file descriptor 값을 kvm에게 ioctl로 전달한다.

// qemu/accel/kvm/kvm-all.c
static int kvm_irqchip_assign_irqfd(KVMState *s, int fd, int rfd,
                                               int virq, bool assign)
{
    struct kvm_irqfd irqfd = {
        .fd = fd,
        .gsi = virq,
        .flags = assign ? 0 : KVM_IRQFD_FLAG_DEASSIGN,

    return kvm_vm_ioctl(s, KVM_IRQFD, &irqfd);
}

2. irqfd 자료구조 생성 및 동작 함수 세팅


QEMU로부터 전달받은 정보들을 토대로 kvm은 현재 VM 이 사용할 irqfd 자료구조를 할당하고 값을 세팅한다. args로 참조하는 값은 QEMU에서 받아온 값이고 eventfd는 QEMU에서 전달받은 VirtQueue의 file descriptor 값을 이용해 추출한 주소다. VirtQueue가 eventfd 기반으로 만들어진 자료구조 인 것 같다. irqfd->inject,shutdown은 irqfd가 runtime에 수행할 함수들이다. irqfd_inject는 인터럽트를 guest에 주입하는 함수고 irqfd_shutdown은 irqfd 자료구조를 제거할 때 사용된다.

// linux/virt/kvm/eventfd.c
static int kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args) 
{
    irqfd->kvm = kvm;
    irqfd->gsi = args->gsi;
    INIT_LIST_HEAD(&irqfd->list);
    INIT_WORK(&irqfd->inject, irqfd_inject);
    INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
    seqcount_init(&irqfd->irq_entry_sc);
...
    irqfd->eventfd = eventfd;


3. poll table, waitqueue 초기화


irqfd의 poll table의 콜백 함수와 waitqueue의 콜백 함수를 설정한다. 설정 목적은 eventfd 메커니즘으로 전달받은 이벤트를 irqfd로 쏘아주기 위함이다. eventfd부터 최종적으로 irqfd 함수가 불리기 까지의 동작은 마지막에 설명하도록 하자. 여기서는 poll_table이라는 것을 사용했다는 것에 주목하자

// linux/virt/kvm/eventfd.c
static int kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args) 
{
    init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
    init_poll_funcptr(&irqfd->pt, irqfd_ptable_queue_proc);


4. kvm irq routing 정보 입력


Guest로부터 넘겨받은 GSI 값에 대한 irq routing entry 정보를 받고 업데이트한다. 이부분은 배경 지식이 부족해 정확하게 이해하지 못한 부분이기는 한데 코드만 보면 대충 짐작하기로는 kvm 자료구조에서 irq routing에 대한 정보가 있으며 이 값은 GSI값에 따라 처리할 수 있는 entry 정보가 별도로 존재하는 것 같다. 추출한 entry 값을 irqfd 자료구조에 설정한다.

// linux/virt/kvm/eventfd.c
static int kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args) 
{
    irqfd_update(kvm, irqfd);
static void irqfd_update(struct kvm *kvm, 
                             struct kvm_kernel_irqfd *irqfd)
{
    // HK: Get the entries of irq_rt->map[gsi]
    // Set mapping between irqfd(kernel) to user space
    n_entries = kvm_irq_map_gsi(kvm, entries, irqfd->gsi);
// linux/virt/kvm/irqchip.c
int kvm_irq_map_gsi(struct kvm *kvm,
            struct kvm_kernel_irq_routing_entry *entries, int gsi)
{
    irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
                    lockdep_is_held(&kvm->irq_lock));

    // HK: Define kvm_irq_routing_entry
    //     Each entry properties depend on gsi value...
    if (irq_rt && gsi < irq_rt->nr_rt_entries) {
        hlist_for_each_entry(e, &irq_rt->map[gsi], link) {
            entries[n] = *e; 
            ++n;


5. irqfd 리스트 추가 및 pending된 인터럽트 처리


지금까지 세팅한 irqfd 자료구조를 kvm irqfds 리스트에 추가한다. 장치가 여러개 있으니 VM별로 여러개의 irqfd를 가질 수 있다. 그리고 지금까지 초기화 하는 도중에 인터럽트가 발생했는지 확인하고 있으면 스케줄링으로 저리한다. 여기서 poll이라는 콜백함수로 이벤트가 있는지 확인하는데 poll 함수는 eventfd_poll이다. eventfd 값이 변경되면 새로운 event가 발생한 것으로 보고 interrupt를 날리려는 용도다.

// linux/virt/kvm/eventfd.c
static int kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args) 
{
    /* HK: Add new irqfd to kvm irqfd list */
    list_add_tail(&irqfd->list, &kvm->irqfds.items);
    events = f.file->f_op->poll(f.file, &irqfd->pt);

    if (events & POLLIN)
        schedule_work(&irqfd->inject);


초기화 작업을 바탕으로 분석한 irqfd의 동작 과정은 다음과 같다


eventfd_poll => irqfd->pt (poll table) => (callback) irqfd_ptable_queue_proc

=> add_wait_queue(wqh, &irqfd->wait) => irqfd_wakeup => schedule_work(&irqfd->inject);

=> kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,


eventfd_poll 함수에서는 irqfd가 갖고 있는 eventfd 값이 변경되길 기다리며 event 발생시 poll table에 물려있는 콜백함수(irqfd_ptable_queue_proc)함수가 불리고 이 함수에서는 waitqueue의 콜백 함수로 설정한 irqfd_wakeup 함수를 부른다. 이 함수에서는 interrupt를 날리는 함수인 irqfd_inject 함수가 불리고 이 함수에서 최종적으로 guest에게 interrupt를 쏴주게 된다. 휴 어렵네;


kvm_set_irq 함수 내의 while문에서 콜백 함수로 set이 불리는데 이 함수는 아키텍처별로 설정되는 함수다. ARM의 경우에는 vgic의 vgic_irqfd_set_irq 함수가 불리며 x86 에서는 irqchip 타입에 따라서 콜백 함수가 다르다.

// virt/kvm/irqchip.c
int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level,
        bool line_status)
{
    while (i--) {
        int r;
        // HK: kvm_set_msi architecture specific callback!
        //     set -> vgic_irqfd_set_irq (vgic-irqfd.c)
        r = irq_set[i].set(&irq_set[i], kvm, irq_source_id, level,
                   line_status);


사용 예시


Guest가 virtio 드라이버를 사용하는 경우, QEMU에서 에뮬레이션된 virtio backend 드라이버가 요청 받은 작업을 마치고 Guest에 VirtQueue를 이용해서 알림을 주게 된다. 이때 QEMU에서 VirtQueue에 결과 값을 입력하면 커널에서는 이전에 초기화한 VirtQueue의 eventfd 값이 변경된 것을 감지하고하고 초기화된 함수들이 연달아 불리게 된다. 최종적으로 interrupt_inject 함수가 불리게 되면서 Guest에게 interrupt가 전달된다.

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

QEMU를 이용해 커널 이미지 바꿔서 부팅해보기  (0) 2018.12.20
kvm ioeventfd  (0) 2018.08.11
kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08
virtio  (0) 2018.07.08
VFIO, Passthrough  (0) 2018.06.30

vhost

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

Vhost는 Virtio를 이용한 장치 가상화의 성능을 개선하는 모듈이다. 일반적으로 Virtio를 이용하는 장치들은 모두 virtqueue 기반의 킥 메커니즘으로 backend와 frontend가 통신한다. 그런데 이때 virtqueue를 처리하는 주체는 QEMU에서 만든 유저 프로세스이기 때문에 다른 우선순위가 높은 작업들이 처리 될 때 까지 연기되며 실제 Host의 장치 드라이버를 사용하기까지 오랜 시간이 걸린다. 이것 뿐만아니라 장치를 에뮬레이션 하는 작업 또한 유저 스페이스에서 이뤄지기 때문에 커널내의 작업보다 미뤄게되고 실제로 장치를 사용하는 Native 드라이브와 통신하기 위해선 여러번 context switch가 일어나게돼 오버헤드가 발생한다. 


그림 1. virtio 장치 구조


이런 오버헤드를 해결하기 위해 창안된 구조가 vhost다. vhost는 QEMU처럼 유저스페이스위에 돌아가는 virtqueue를 Host의 커널에서 직접 접근 할 수 있고 이를 바탕으로 backend 드라이버와 emulation 코드가 native driver가 있는 kernel 영역에서 동작하도록 한다. 이런 구조면 virtqueue로 주고 받는 통신을 qemu에서 처리할 필요가 없어 지연 될리가 없고 또한 이미 kernel내로 내려왔기 때문에 그림 1 처럼 장치 에뮬레이션을 하기 위해 번거롭게 여러번 context switch를 할 필요도 없다.


그림 2. vhost 구조


vhost를 사용한 대표적인 장치는 vhost-net, 네트워크다. 아무래도 네트워크를 사용하면 Host와 Guest가 패킷을 주고 받는 일이 많은데 이때 기존의 킥 매커니즘을 사용하면 오버헤드가 많아 이를 손보기 위해 가장 먼저 나온 것 같다. 


그런데 몇몇 드라이버의 경우에는 user space에서 존재하는 드라이버를 사용하는 경우가 있다. 이때는 backend를 커널 내에서 돌리는 것보다 유저단에서돌아가야 하며 user space에서 돌아가는 드라이버 프로세스와 통신해야 한다. vhost-user는 이런 경우를 대비해서 만들어졌다. vhost의 구조는 그대로 따라가는 대신 user space에서 돌아가는 에뮬레이션 구조로 보면 된다



아래 참고사이트를 이용하면 이해하는데 훨씬 도움이 될 것 같다.


1. VMSPLICE 블로그

2. Vhost-User Feature for QEMU

3. xiaorg




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

kvm ioeventfd  (0) 2018.08.11
kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08
virtio  (0) 2018.07.08
VFIO, Passthrough  (0) 2018.06.30
QEMU 성능 문제 - 개론  (0) 2018.05.30

virtio

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

QEMU를 이용해서 Full virtualization으로 VM을 돌릴 경우 Guest OS에 별다른 수정 사용 할 수 있다는 장점이 있으나 매번 Guest의 명령어를 트랩해서 장치를 에뮬레이션 해줘야 하므로 느리다는 단점이 있다. 그래도 과거와 달리 요즘에는 하드웨어가 좋아져서 마우스나 키보드를 사용할 때 버벅거리지 않아 거의 성능에 문제가 없어 보이는 착각이 들지만 실제로 벤치마크 툴을 이용해 Guest 장치의 성능을 Host와 비교해보면 심각할 정도로 낮다.


이런 문제를 해결하고자 가상화 개발자는 virtio라는 구조를 창안해냈다. 이 구조의 주요 개념은 일부 장치에 대해서는 매번 트랩해서 emulation 하지 말고 Hypervisor와 Guest가 바로 통신 할 수 있는 채널을 만들어 불필요한 오버헤드를 줄이자는 것이다. 이를 위해 Guest에는 특정 장치가 Host와 통신하기 위한 frontend 드라이버가 있어야하고 마찬가지로 Hypervisor에도 Guest와 특정 장치가 통신 할 수 있는 backend 드라이버가 필요하다. 


그림 1. Virtio 구조.


그림 1의 왼쪽 구조는 기존에 Guest OS에 아무런 수정 없이 Full Virtualization을 사용 했을 때고 오른쪽 구조는 Guest OS와 Hypervisor에 front/backend 드라이버를 추가 했을 때다. 왼쪽 구조에서는 Guest가 장치를 사용하려는 경우 매번 트랩을 해야하는데 오른쪽 구조에서는 front/backend에서 직접 통신을 하기 때문에 별도의 트랩이 필요 없어 효율적이다. Virtio-Backend에서는 Frontend에서 받은 요청을 바로 Hypervisor에게 Emulation을 요청한다.


virtio는 Guest의 일부 수정이 필요하다는 단점이 있지만 채택시 얻게될 성능상 이득을 고려하면 이정도 불편함은 감수해야 할 것 같다. 다행히도 Linux인 경우에는 몇몇 장치들에 대해선 virtio frontend 드라이버 코드가 이미 커밋돼 있고 Windows도 주요 하이퍼바이저 커뮤니티에서는 드라이버 코드를 올려둔 상태니 적절히 찾아서 사용하면 될 것 같다.


참고문헌


1. Virtio: An I/O virtualization framework for Linux IBM Developer works

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

kvm irqfd  (0) 2018.08.11
vhost  (0) 2018.07.08
virtio  (0) 2018.07.08
VFIO, Passthrough  (0) 2018.06.30
QEMU 성능 문제 - 개론  (0) 2018.05.30
KVM - ARM  (0) 2018.01.01

VFIO, Passthrough

컴퓨터공부/가상화기술 2018.06.30 13:40 Posted by 아는 개발자 아는 개발자

VFIO (Virtual Function I/O)


일반적으로 유저 애플리케이션에서 특정 장치를 이용하기 위해선 먼저 Host OS에서 해당 장치를 전담하는 유저 서비스(안드로이드는 surface flinger 같은게 있다)에게 요청하고, 유저 서비스는 커널 단의 장치 드라이버에 작업을 전달하며 장치 드라이버는 전달 받은 요청에 따라 장치를 실제로 움직이게 된다. 이러한 형태는 유저 앱의 입장에서 꽤 단순한 작업을 해도 커널 단의 장치드라이버에 불필요한 작업이 많다면 이에 비례해서 처리하는 시간이 늘어나게돼 유저앱의 성능이 저하되는 일이 발생한다.


이를 해결하고자 리눅스 커널에서는 유저 영역에서 직접 장치에 접근 할 수 있는 플랫폼을 만들었다. 간단히 말해 장치 드라이버를 커널에 두지 않고 유저 영역에 드라이버를 둘 수 있는 형태다. 이런 구조는 불필요한 커널 스택을 거치지 않고 사용 목적에 따라 드라이버를 만들 수 있기 때문에 효율적이고 최적화된 코드를 짤 수 있으며 혹시나 만든 드라이버가 죽더라도 커널 영역이 아니기 때문에 시스템 전체가 크러쉬되는 부담은 줄어드는 장점이 있다. 그리고 무엇보다 회사 입장에서는 유저 영역에서 코드를 작성하기 때문에 GPL 라이센스를 따르지 않아 코드를 공개하지 않아도 되는 메리트가 있기도 하다. (물론 오픈소스 철학과는 상반되지만)


Passthrough


애초에 Type2 하이퍼바이저를 목표로두고 설계한 구조는 아니지만 구글에 VFIO를 치면 QEMU와 연관된 자료들이 무수히 많이 나오는데 아마 VFIO를 가장 유용하게 사용할 수 있는 대표적인 예가 가상화이기 때문에 그런것 같다. QEMU에서 만들어준 장치들은 이미 VM내의 커널 드라이버를 거치고 왔기 때문에 그 이후 이뤄지는 Host 커널 영역에서 이뤄지는 작업은 어찌보면 같은 일은 두번 반복하는 불필요한 작업이기도 하다. 이때 VFIO를 사용하면 불필요한 작업 없이 에뮬레이션 장치의 결과물을 그래도 실제 장치에 전달 할 수 없어 성능을 대폭 향상 시킬 수 있다. VM이 직접 장치에 접근 할 수 있는 구조가 되는 것이다.


이처럼 Guest가 Host의 중재 없이 직접 장치에 접근 할 수 있는 구조를 Passthrough라고 한다. 여기서 VFIO는 Type2 하이퍼바이저에서 Passthrough를 할 수 있는 일종의 플랫폼 역할을 하는 것이며 Xen과 같은 Type1 하이퍼바이저에서는 장치를 front/backend의 형태로 안쓰고 Guest가 native driver를 사용할 수 있도록 변형해서 Passthrough를 사용한다.



그림 1. VFIO 개념도

  • 간단하게 그래픽 장치에 바로 접근한다고 설명했지만 실제로 고려해야할 일들은 무수히 많다. 벤더에 따라서 해야하는 일이 천차만별.

  • 주로 그래픽카드와 네트워크 장치에 사용한다.

보안 위험성

대부분의 장치가 MMIO로 사용하기 때문에 VM이 직접 장치를 사용하기 위해선 장치의 물리 메모리 주소에 VM이 접근 할 수 있어야 한다.  그런데 VM이 실제 물리 주소를 알고 변환 과정 없이 물리주소로 사용하는 경우 보안상 위험이 존재한다. 실제 물리 주소를 알게 되면 물리 메모리 영역의 전반적인 주소 값을 추측 할 수 있게 되고 (물론 정확하진 않지만) 추측한 값을 통해 할당된 장치 뿐만 아니라 주변 장치 또는 메모리 영역까지 접근 할 수 있게 된다. 악의적인 목적을 가지면 Host나 다른 VM의 메모리 값을 오염시키는 것도 가능하다. 

위와 같은 보안상의 위험을 막기 위해선 VM이 자신에게 할당된 장치 영역 이외의 물리 주소는 접근 하지 못하도록 막아야 한다. iommu를 사용하면 page table을 사용할 때처럼 VM의 가상 주소를 실제 장치의 물리주소와 매핑하기 때문에 VM으로부터 장치의 주소의 정보를 숨기면서도 접근은 가능하게 되고 뿐만 아니라 할당 되지 않은 메모리에 접근하려고 하는 경우에는 fault를 발생시켜서 보안 위협을 막을 수 있다. 

참고자료


- Virtual Open System, vfio에 대해서 전반적인 소개를 하는 자료. 

- Platform Device Assignment to KVM-on-ARM Virtual Machines via VFIO 논문, 그림을 가져왔다. 자세하게 설명해주고 있어 많은 도움이 됐다.

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

vhost  (0) 2018.07.08
virtio  (0) 2018.07.08
VFIO, Passthrough  (0) 2018.06.30
QEMU 성능 문제 - 개론  (0) 2018.05.30
KVM - ARM  (0) 2018.01.01
QEMU와 KVM - 2  (0) 2017.11.11

QEMU 성능 문제 - 개론

컴퓨터공부/가상화기술 2018.05.30 23:54 Posted by 아는 개발자 아는 개발자

Host OS의 유저 앱으로 구동되는 Guest OS는 Hypervisor가 만들어 준 가상 장치로 동작하고 있기 때문에 실제 물리 장치를 이용하는 Host OS에 비해서 성능이 확연히 낮다. Hypervisor가 만들어준 가상장치도 결국에는 실제 하드웨어에서 동작하게 되는 것이니 이론상으론 시스템 하드웨어 성능이 높아지면 가상 장치로 동작하는 Guest OS도 좋은 성능을 가질 수는 있다. 그러나 아무리 좋은 하드웨어를 사용해도 Host OS처럼 직접 접근해서 사용하는 것과는 확연하게 차이가 난다. 배틀그라운드의 권장사양을 훨씬 뛰어넘는 그래픽카드와 CPU를 장착해도 Guest OS로 실행되는 윈도우에서는 배틀그라운드는 커녕 스타크래프트도 온전하게 플레이하기 어렵다.


qemu를 이용해 스타크래프트를 하는 유튜브. 사진을 클릭하면 실제 영상을 볼 수 있다


성능 문제를 해결하기 위해선 가능한 Guest OS에서 장치를 실행하는 명령과 실제 하드웨어의 동작 사이의 오버헤드를 줄이는 것이 관건이다. 앞선 포스트에서도 이미 설명 했듯 인텔과 ARM과 같은 하드웨어 제조사들은 이점을 고려해 Guest OS가 일반 연산에 사용하는 장치(CPU, Memory, Interrupt)를 직접 또는 좀더 빨리 접근 할 수 있는 구조를 만들었고 KVM처럼 위 구조를 적절하게 활용한 소프트웨어를 사용한 Guest OS의 CPU와 메모리 성능이 Host OS에 못지 않다.


CPU와 메모리의 성능이 Host와 비슷하니 시스템 전반의 성능도 비슷하지 않을까 싶지만 실제로는 그렇지 않다. 일반 연산 장치를 제외한 장치는 여전히 가상 장치로 사용하기 때문에 여러 개의 장치를 동시에 사용하는 소프트웨어는 Host OS처럼 부드럽게 사용하기가 어렵다. 쉬운 예로 Guest OS에서 곰플레이어를 이용해 영화를 본다고 해보자. 영상 파일을 모니터에 출력하고 소리를 내기 위해선 CPU와 메모리 뿐만 아니라 GPU와 사운드카드도 필요하다. 그런데 GPU와 사운드카드는 여전히 가상 장치다. Guest OS의 CPU 속도가 높아도 정작 화면 출력을 담당하는 가상 GPU 장치를 사용하면 화면 출력이 느려지고 Guest OS의 메모리 처리 속도가 높아도 가상의 오디오를 사용하면 음악이 끊길 수 밖에 없다. 이런 상황에서 키보드, 마우스같은 인풋 장치를 빈번하게 사용하는 FPS 게임을 실행한다면 말할 것도 없다. 총알 한방 쏘는것도 쉽지 않을 것이다.


Passthrough, VFIO 는 위와 같은 문제를 다룬 대표적인 솔루션이다. 꽤 오랜 기간 연구했으며 논문도 풍성하다. 안타깝게도 새로 나오는 것은 없지만. 앞으로 포스트에서는 이것들이 무엇이며 어떻게 동작하는지 그리고 이것들을 사용할 경우 어떤 문제가 발생하는지에 대해서 차근차근 공부해보려고 한다. 



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

virtio  (0) 2018.07.08
VFIO, Passthrough  (0) 2018.06.30
QEMU 성능 문제 - 개론  (0) 2018.05.30
KVM - ARM  (0) 2018.01.01
QEMU와 KVM - 2  (0) 2017.11.11
QEMU와 KVM - 1  (0) 2017.11.01

KVM - ARM

컴퓨터공부/가상화기술 2018.01.01 11:41 Posted by 아는 개발자 아는 개발자

아주아주 먼 옛날 가상화 기술이 핫 할때 Intel과 ARM 같은 제조사들은 자사의 칩에서 동작하는 가상화 소프트웨어의 성능을 높이고자 하드웨어단에서 여러 옵션을 추가 했다. 소프트웨어 개발자들은 제조사들이 제공하는 옵션을 활용해 하이퍼바이저를 만들었는데 KVM 또한 이때 만들어진 하이퍼바이저중 하나다. 좀더 구체적으로 말하면 QEMU같은 Type2 소프트웨어가 하드웨어의 가상화 확장 기능을 쉽게 사용 할 수 있도록 인터페이스의 역할을 하는 커널의 모듈이다.


그런데 제조사들은 가상화 기술의 성능을 높이기 위해 어떤 기능을 제공하고 있을까? 여러 OS를 동작하는 작업인 만큼 매우 오버헤드가 심할텐데 어떤 옵션이 있었기에 VMware로 리눅스가 쌩쌩 잘 돌아가는거지? 그리고 KVM은 하드웨어의 기능을 어떻게 반영 했을까? 기능을 반영하기 위한 특별한 구조적 의사 결정 과정은 없었을까? 파일과 코드의 양은 상당한데 말이다.


궁금증을 해소하고자 아키텍처단의 양대 산맥인 ARM과 x86에서 제공하는 가상화 기능을 살펴보고 이들의 특성이 어떻게 KVM에 적용됐는지를 아주 차근차근 분석해보려고 한다. 이번 포스트는 ARM에 대한 내용이다.


포스트를 작성하기 위해 KVM/ARM: The Design and Implementation of the Linux ARM Hypervisor 논문을 참조했다. 이 논문은 ARM에서 제공하는 가상화 기술이 나오게 된 계기와 작동 방식을 다루었고 위 특성을 반영한 KVM 코드를 리눅스 커널 메인라인에 반영하는 작업을 쭉 정리했다. 하드웨어 옵션을 쓰기 위한 여러 후보 구조를 도출하고 각각의 장단점을 분석한 후 선택하는 구조적 의사 결정 과정도 정리했는데 혹시 관심 있는 분들은 읽어보면 좋을 것 같다. ARM 아키텍처를 심도있게 이해하는데도 도움이 된다. 이번 포스트에서는 구조적 의사 결정의 결과만 다룰 예정이다.


꼼꼼하게 여러번 읽어 봤지만 글쓴이의 역량 부족으로 아직 온전히 이해하지 못했다. 잘 이해가 되지 못하는 부분은 두루뭉실 하게 쓴 것 같은데 이런 부분은 논문은 참조 해주셨으면 좋겠다. 친절하게 링크도 남긴다. 15달러는 못드린다.


1. CPU Virtualization, HYP Mode


HYP Mode는 SVC, USR 모드보다 더 높은 권한을 갖고 있는 CPU 모드중 하나다. SVC가 USR에서 동작하는 프로세스의 Trap을 받는 것처럼 HYP 모드는 SVC, USR의 Trap을 대신 받아 처리할 수 있으며 SVC, USR의 레지스터값들을 읽고 수정 할 수 있다. Exception Level 2로 불리기도 한다.


ARM에서 HYP 모드를 추가하게 된 배경은 Xen과 같은 standalone 하이퍼바이저 때문이다. Host OS 없이 동작하는 Type-1 하이퍼바이저의 경우에는 위에 동작하는 Guest OS보다 더 높은 권한을 쥐고 말썽을 부리는 경우 적극적으로 개입해 통제하는 역할을 해야한다. 그런데 CPU가 SVC, USR인 경우 이런 요구사항을 아키텍처적으로 설계하기가 애매하다. 하이퍼바이저의 권한을 살려 SVC 모드에 하이퍼바이저만 동작하게 하고 USR 모드에 Guest OS를 올리자니 SVC 모드에서 동작하는 걸 염두해두고 설계된 OS가 실행할 수 없게 된다. 그렇다고 Guest OS와 하이퍼바이저가 SVC 모드에 공존하게 하자니 Guest OS가 말썽 부리는 경우 대처 할 방법이 없다. 개념적으로는 훌륭한 구조였으나 SVC, USR 모드만으로는 설계가 불가능하다.


이런 문제를 해결하기위해 ARM은 SVC와 USR보다 권한이 더 높은 HYP 모드를 만들고 소프트웨어 개발자들로 하여금 하이퍼바이저를 HYP 모드에 넣도록 했다. 이것 덕분에 교통 정리가 끝났다. 이제 하이퍼바이저가 Guest OS에 제대로 통제권을 쥘 수 있게 되고 Guest OS는 SVC모드에서 동작하는 코드를 그대로 실행 할 수 있게 됐다.


KVM처럼 Type-2 하이퍼바이저는 좀 애매하다. Host OS의 모듈의 형태로 동작하기 때문에 일부 기능을 Host API에서 가져와야하는데 만약 Host가 EL1으로 동작하고 있다면 KVM또한 EL1에서 동작하고 있어야 한다. 그런데 Guest 보다 더 높은 권한을 가지려면 EL2에서 동작하기도 해야한다. 참 골치가 아픈 상황이다.


KVM은 두 가지 요구 사항을 반영해 구조를 Lowvisor/Highvisor로 두가지로 분리했다. Lowvisor는 HYP Mode에서 동작하는 Hypervisor이며 VM의 instruction을 trap하고 이를 Highvisor에게 전달한다. Highvisor는 Kernel Mode에서 동작하며 Host에 있는 커널 코드를 사용해 VM 운영중 필요한 기능을 제공한다.


Lowvisor에서 동작하는 코드는 Highvisor에 비하면 매우 적다. EL2 벡터테이블과 World Switch 사용되는 코드 일부 정도다. 코드의 양만 보면 Type1에 비하면 활용도는 적은것 같다.



그림 1. ARM/KVM 구조도. 논문 내용을 참조해서 그렸다.


논문에선 위와 같은 두개의 구조로(Highvisor/Lowvisor) 만들기 전에 아예 커널을 HYP Mode에서 부팅하는 작업도 고려했었다. Mode 변경으로 인한 cost를 줄일 수 있는 방법인데 왜 위 구조를 채택하지 않았는지는 논문을 참조해보길. 생각보다 간단한 이유였다.


* ARM은 하이퍼바이저를 넣으라고 HYP 모드를 설계 했는데 정작 퀄컴이나 삼성같은 칩 제조사들은 여기에 하드웨어 기능을 추가/보완 할 수 있는 소프트웨어 모듈을 넣고 있다. 역시 인생은 의도대로 흘러가지 않는 것 같다


2. Memory Virtualization


ARM은 Stage-2 Translation이란 기능을 제공했다. 간단히 말해서 Virtual Machine 내에서 도출한 물리 메모리 주소(IPA: Intermediate Physical Address)를 하드웨어 물리 주소(PA: Physical Memory)로 변환 할 수 있는 기능을 하드웨어 단에서 제공한다. 위 기능을 사용하기 전에는 IPA를 매번 소프트웨어적으로 물리 주소를 찾아가야 했고 Fault가 발생하면 처음부터 찾아야해 성능이 저하될 수 있는 문제가 있었다. 그런데 메모리 가상화 기능이 추가되면서 IPA 주소를 MMU에서 PA로 변환해줄 수 있게 됐다. KVM은 Host와 VM 간의 World Switch가 일어날 때 Stage-2 Translation 기능을 On/Off만 하면 된다. MMU는 Stage-2 Table의 register 주소 값을 참조해 변형한다.


그림 2. ARM/KVM 메모리 translation 작업.


3. Interrupt Virtualization


Interrupt Virtualization을 도입 하기 전에는 GIC의 CPU Interface를 VM과 공유하기 때문에 하드웨어에서 전달하는 Interrupt를 어디서 trap해 처리할 것인지가 주요한 이슈였다. Kernel 모드에서 모두 trap 한다면 효율적이나 Hypervisor가 하드웨어 통제권을 갖지 못하는 문제가 있고 HYP 모드에서 모두 처리한다면 매번 Interrupt를 처리하기 위해 HYP 모드로 변경해야 하는 오버헤드가 발생한다. 


이 문제를 해결하고자 ARM에서는 CPU가 VM과 통신 할 수 있는 Virtual CPU Interface를 제공한다. 위 인터페이스를 활용해 CPU는 별다른 Mode 변경 없이 interrupt를 Kernel Mode에서 동작하는 VM에 전달 할 수 있게 된다. Hypervisor는 더이상 인터럽트를 대신 받고 에뮬레이션 해주지 않아돼 성능적으로 우수하며 또한 VM이 VGIC과 바로 연결돼 있기 떄문에 여전히 통제권을 가지고 있는 것으로 볼 수 있다. VM과 Host가 분리되어 있기 때문에 따로 운영이 가능하며 초기 VM을 생성할 때 VGIC과 잘 연결만 시켜주면 된다.


그림 3. VGIC interface


단 CPU간의 interrupt인 경우(Inter Processor Interrupt, IPI) Distributor를 거쳐야 하는에 이부분은 여전히 Host와 공유하는 영역이라서 Hypervisor의 통제를 받는다. KVM은 Highvisor에 Virtual Distributor를 두어서 받은 interrupt를 에뮬레이션해 전달한다.


4. Timer Virtualization


OS에서 스케줄링 할 때 주기적으로 프로세스가 CPU에서 동작 할 수 있는 시간을 할당하고 사용한 시간을 확인하게 되는데 이때 사용하는 기기가 타이머다.. 스케줄링의 주기는 ms 단위로 짧기 때문에 Host는 타이머를 주기적으로 자주 이용하고 있으며 VM 또한 내부적으로 스케줄링을 위해 에뮬레이션된 타이머에 자주 접근하게 되는데 이를 Hypervisor에서 모두 처리해준다면 매번 Mode Change가 일어나서 시스템 전반 성능에 부담이 된다.


이에 ARM에서는 Virtual Timer라는 것을 두어서 VM이 주기적으로 Virtual Timer 값을 읽을 수 있도록 했다. VM은 trap 모드로 이동하지 않도 타이머 값을 읽을 수 있어 Mode Change의 부담을 덜 수 있게 됐다. 단 Timer가 expire 돼 CPU에 interrupt를 보내야 하는 경우에는 HYP 모드로 이동해서 하이퍼바이저를 통해 Virtual Interrupt를 보낸다. 이는 아키텍처적인 고려사항이라고 한다.



사진 출처


그림 3. http://slideplayer.com/slide/7615418/

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

VFIO, Passthrough  (0) 2018.06.30
QEMU 성능 문제 - 개론  (0) 2018.05.30
KVM - ARM  (0) 2018.01.01
QEMU와 KVM - 2  (0) 2017.11.11
QEMU와 KVM - 1  (0) 2017.11.01
6. XenStore, Xenbus  (0) 2017.01.22

QEMU와 KVM - 2

컴퓨터공부/가상화기술 2017.11.11 11:03 Posted by 아는 개발자 아는 개발자

KVM(Kernel-based Virtual Machine)


그림1. KVM 공식 로고다. 펭귄이 던지고 있는 공은 VM을 의미하는 것 같다.


"KVM은 리눅스 커널을 하이퍼바이저로 변환하기 위한 가상화 인프라스트럭처의 하나이다"라고 위키 백과에선 설명하는데 이것만 가지곤 KVM의 제공하는 기능을 이해하긴 힘들다. KVM을 공부하기 전에 같이 사용되는 하이퍼바이저, QEMU에 대해 먼저 공부해보면 KVM의 사용 목적에 대해서 더 쉽게 이해할 수 있다. QEMU 포스트 읽어보기


Intel과 ARM같은 하드웨어 개발 회사들은 컴퓨터 내에서 가상화 기술을 지원하기 위한 장치들(Intel VT 또는 AMD-V )을 넣어뒀다. 이런 장치들은 가상화 기술의 고질적인 성능 저하 문제를 해결 하기 위해 만들어졌는데 이 장치들을 적절히 이용한 하이퍼바이저는 장치를 Emulation 해서 만든 방식보다 뛰어난 성능을 보였다(몇몇 기능은 Host OS와 거의 동일한 성능을 내기도 했다). 하지만 유저영역에서 동작하는 가상화 소프트웨어는 가상화 지원용 하드웨어를 직접 사용 할 수 없다. 하드웨어에 접근하는 일은 모두 커널을 거쳐야 하기 때문이다.


그림2. KVM 사용시 시스템 구조


KVM은 제조사에서 만든 가상화 하드웨어 기능을 범용성 있게 사용할 수 있도록 최적화하고 유저영역에서 동작하는 소프트웨어가 최적화한 기능을 쉽게 사용할 수 있도록 인터페이스를 제공한다. 인터페이스 접근은 간단하게 입출력 제어 함수(ioctl)를 호출해서 할수 있다. QEMU 소스 코드를 보면 실제로 kvm에 ioctl 함수를 보내는 코드들을 볼 수 있다.


지금까지는 하드웨어 제조사의 가상화 솔루션을 사용하기 위해 KVM이 사용되고 있다고 설명했는데 이것 말고도 다양한 기능을 제공하고 있다. 여기서 KVM이 제공하는 기능들 중 중요한 것 두가지만 살펴보자.


1. Virtual Machine 생성 및 관리


VM 생성 및 관리하는 작업을 하이퍼바이저가 아니라 KVM에서 관리 하기도 한다. 이런 경우 VM들이 커널내에서 관리되기 때문에 유저 영역에서 동작 할 때 보다 상대적으로 안정적이며 생성된 VM들은 커널 프로세스의 형태로 존재하기 때문에 유저프로세스로 존재할 때보다 전반적인 성능도 향상된다.


2. 장치 Emulation


CPU, Memory, Interrupt Handler처럼 VM 성능에 결정적인 장치들을 Emulation 해준다. 앞서 설명한 VM 생성 관리 작업처럼 이 장치들도 유저 영역에서 존재 할때보단 커널 영역에 있을 때 더 좋은 성능을 보이며 뿐만 아니라 하드웨어장치를 컨트롤 할 수 있는 함수를 호출 할 수 있는 장점이 있다. 여기서 Emulation 된 장치들은 제조사에서 추가한 가상화 솔루션을 지원하는 장치들이다.


이외에도 KVM이 제공하는 기능들을 적절하게 사용한다면 유저영역 하이퍼바이저에서 할 일은 "생성할 VM의 파라미터를 잘 받고 KVM 모듈의 함수를 잘 호출 하는 것"과 "KVM에서 제공하지 못한 장치들을 Emulation 하는 것"이다. 그래픽같은 경우 가상화 기술을 상용화 할 때 가장 크리티컬한 요소인데 아쉽게도 KVM에선 따로 지원하지 않는다. 이런 경우엔 하이퍼바이저에서 그래픽 관련 요소들을 처리 할 수 있는 솔루션을 제공해야한다.


사진 출처


- https://sort.veritas.com/public/documents/vie/7.3/linux/productguides/html/infoscale_virtualization/ch01s03.htm (그림 2)

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

QEMU 성능 문제 - 개론  (0) 2018.05.30
KVM - ARM  (0) 2018.01.01
QEMU와 KVM - 2  (0) 2017.11.11
QEMU와 KVM - 1  (0) 2017.11.01
6. XenStore, Xenbus  (0) 2017.01.22
5. 이벤트 채널 소개  (0) 2017.01.07

QEMU와 KVM - 1

컴퓨터공부/가상화기술 2017.11.01 00:59 Posted by 아는 개발자 아는 개발자

QEMU


'Quick Emulator' 풀네임 만으로는 와닿지 않지만 QEMU는 현재 PC에 설치된 운영체제와 다른 여러 개의 다른 운영체제를 구동 할 수 있는, 전가상화(Full Virtualization)를 지원하는 가상화 소프트웨어중 하나다. 전가상화 소프트웨어로는 VirtualBox나 VMware가 대중적으로 알려져있지만 가상화 기술 개발자들 사이에선 QEMU는 빼놓을 수 없는 가상화 소프트웨어중 하나다. 거의 가상화 기술 초창기를 주도 했던 소프트웨어이며 이때 만들어진 개념들도 상용화된 가상화 소프트웨어에서 사용되고 있다. 실제로 VirtualBox에선 상당부분을 QEMU 소스를 사용했다고 한다.


QEMU는 다른 가상화 소프트웨어와는 다르게 오픈소스로 개발됐다(물론 VirtualBox도 오픈소스지만 대부분 Oracle에서 개발했다) 가상화 기술이 한창 붐일때 부터 시작해서 현재 버전 2.10 까지 나왔다. 시간이 꽤 많이 흘렀지만 여전히 많은 개발자들이 참여하고 있는 만큼 질문 피드백이나 하드웨어 업데이트도 빠르고 포럼도 매년 열리고 있다.


VirtualBox나 VMware는 x86용 OS 구동만 지원하는 것에 비해 QEMU는 x86뿐만 아니라 다양한 하드웨어에서 구동 할 수 있도록 지원한다. ARM처럼 모바일 시장을 장악한 아키텍처 뿐만 아니라 지금은 거의 사장되기 싶은 alpha, i386같은 아키텍처도 qemu에선 돌려 볼 수 있으며 뿐만 아니라 동일한 아키텍처 내에서도 라즈베리파이나 삼성 smdk 보드 처럼 특정 하드웨어 머신을 설정할 수 있다. 상용화된 가상화 솔루션들은 비용적인 측면 때문에 지원하지 않은것 같은데 QEMU는 다양한 영역에서 활동하고 있는 개발자들이 참여하고 있기 때문에 인기가 없는 하드웨어들 까지도 서비스되는 것 같다. 물론 A/S는 본인의 몫이다



(QEMU를 이용해 라즈베리파이를 구동한 모습)


Guest OS의 수정없이도 잘 돌아가야 하기 때문에 QEMU내에선 Guest OS가 사용할 CPU, USB, PCI처럼 컴퓨터 본체에 있는 모든 디바이스들을 만든다(Type2 가상화 글을 참고). 이 방식은 모든 OS를 돌릴 수 있다는 장점이 있지만 막상 실행해보면 사용하기 어려울 정도로 매우 느리다.  사실 당연한 것이 Host의 관점에선 QEMU에서 만든 device들은 결국 process나 thread의 일종일 것이다. User process들은 Kernel process에 비해 우선 순위가 낮기 때문에 기존에 사용하던 운영체제와 동일하게 사용하는것이 거의 불가능 하다. 게다가 만약 Host 내에서 처리해야하는 일이 많다면 자연스레 QEMU 작업들은 뒤로 밀릴 수 밖에 없다.  


이런 고민을 소프트웨어 회사만 한 것이 아니다. 한창 가상화 기술이 뜨고 있을 무렵 Intel과 ARM 같은 아키텍처 하드웨어 회사도 어떻게 하면 하드웨어적으로 가상화를 지원 할 수 있을지를 연구를 했고 그에 맞춰 칩을 새롭게 디자인 했다. 리눅스에선 하드웨어 상에서 지원하는 가상화 feature들을 모두 KVM이란 모듈에 통합해서 관리하도록 만들었다.


QEMU는 workload가 높은 작업들을 적절히 KVM으로 돌려서 Host에 가까운 성능을 내도록 했다. 구조적으로는 이렇게 잡아서 사용했다.


(kvm - QEMU 개념도)


자세한 작동 방식은 KVM 포스팅에서!


출처


- https://azeria-labs.com/emulate-raspberry-pi-with-qemu/ - QEMU를 이용해 라즈베리파이를 구동한 모습, 사진

- http://www.admin-magazine.com/CloudAge/Articles/Virtualization-with-KVM - kvm QEMU 개념도, 사진

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

KVM - ARM  (0) 2018.01.01
QEMU와 KVM - 2  (0) 2017.11.11
QEMU와 KVM - 1  (0) 2017.11.01
6. XenStore, Xenbus  (0) 2017.01.22
5. 이벤트 채널 소개  (0) 2017.01.07
가상화기술의 대표적인 보안 문제  (0) 2016.12.10

6. XenStore, Xenbus

컴퓨터공부/가상화기술 2017.01.22 13:40 Posted by 아는 개발자 아는 개발자

Dom0의 장치드라이버인 Backend와 DomU의 장치드라이버인 Frontend가 서로 통신하기 위해선 각 상대 드라이버(Otherend) 상태와 연결 포트와 같은 정보들이 필요하다. 이런 정보들을 각 드라이버들마다 따로 정보를 관리하는 툴을 만들어서 처리 할 수 있겠지만, Xen에서는 이런 정보들을 Xenstore라는 자료구조를 통해 일괄적으로 관리할 수 있게 한다.


Xenstore에는 이런 정보들이 입력된다.



Dom0에서 xenstore-ls를 입력하면 현재 활성화된 Domain의 목록과 각 Domain들이 갖고 있는 장치들의 종류와 상태, 위치, 타입 등등을 알 수 있다. 그림을 보면 "local/domain/[domain id]/[device type]/[driver name]"처럼 경로의 형태로 관리해서 눈으로 보기도 편하다. Xen에서는 경로로 되어있는 주소 값들을 간단히 자료구조화 해서 필요한 정보들을 쉽게 제공한다.


저장되어있는 값들을 분석해보자.


"/local/domain/1/store"는 Domain1이 Xen Store와 통신하기 위해 필요한 정보들을 갖고 있다. "/store/port"는 Xenstore용 포트로 1번을 두었고 "store/ring-ref"는 store와 연결된 페이지(mfn)을 매핑하는 grant table의 엔트리 번호가 "634199"번임을 의미한다.


"/local/domain/2/device/vbd/768" 경로에 담고 있는 값들은 Domain2의 Frontend Block Driver에 대한 정보들을 담고 있다. state는 1이고 device type은 "disk"이다. 여기서 Frontend, Backend들이 주로 참고하는 값은 "state"값이다. 


Xenstore에서 갖고 있는 값들은 각 Frontend, Backend드라이버들이 연결 될 때 중요한 Dom0가 갖고 있는 Backend는 Frontend가 초기화 상태인지, 아니면 죽어가고 있는 상태(Dying)인지에 따라서 취해야 할 작업들이 존재한다. 각 드라이버들의 상태를 저장해둔 값이 state값이고 각 Backend와 Frontend 드라이버가 watch를 상대 드라이버에 경로 state값에 걸어준 후 값이 변경 될 때 마다 필요한 작업들을 실행하도록 콜백을 호출한다.




Xenstore와 각 Domain들이 값을 읽고 쓸 수 있는 연결 통로가 필요한데 이때 사용되는 것이 Xenbus이다. 컴퓨터에서 각 장치들끼리 연결 되기 위해 필요한 통로로 bus를 사용하는데 Xenbus는 bus의 소프트웨어 버전이라 생각하면 된다(소프트웨어적으로 구현된 bus는 Xenbus말고도 여러 개가 존재하는데 xenbus는 Xen환경에 최적화해서 만든 bus다)




Dom0와 DomU는 xenbus를 통해서 Xenstore에 접근해 각각의 장치 드라이버 초기화에 필요한 정보(state, ring-ref값 등등)를 얻고 이 정보들을 통해 Backend-Frontend를 xenbus로 연결한다. 이 xenbus를 통해서 각 드라이버들은 요청/응답을 받을 수 있는 루틴이 완성된다. 이때 사용되는 메커니즘이 Domain간 통신방법 포스트에서 설명한 Ring과 이벤트 채널이다. Xenbus는 심플한 두 매커니즘을 이용해 드라이버간의 연결을 담당한다.

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

QEMU와 KVM - 2  (0) 2017.11.11
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

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

가상화기술의 대표적인 보안 문제

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

가상화 기술은 각 OS들 간의 isolation을 지원해 다른 VM들에 비해 보안이 우수하다고 하지만 가상화 기술 또한 보안 문제에서 자유롭지 못하다. 기존 OS가 갖고 있는 보안 문제를 회피 할 수 있으면서도 또 다른 양상의 보안 문제가 발생 할 수 있는데 이번 포스트에서는 가상화 기술의 대표적인 보안 문제점들을 정리 해보고자 한다.


1. Virtual Machine들 간의 공격.


가상화 기술의 가장 큰 장점은 VM들끼리 독립된 관계를 유지(isolation)되어 서로 영향을 주지 않는다는 것인데 만약 이 처리를 잘 해두지 않는다면 VM들간에 혹은 VM이랑 VMM 간에 공격이 발생 할 수 있다. 공격 양상은 VMM이 갖고 있는 데이터를 바꿔버리거나 혹은 읽어오는것 등등이 있다.


2. VM escape


주로 하나의 VM이 모든 하드웨어를 관리하고(Host VM이라 한다) 다른 VM들은 Host VM의 통제를 받고 하드웨어에 접근 하는데 권한이 없는 VM이 직접 하드웨어에 접근하려고 하는 경우 보안 문제가 발생 한다. 다른 VM들은 Host가 하드웨어를 통제한다고 생각하고 요청 명령을 내리는데 실제로는 다른 VM이 Hardware의 state를 바꿔버리는 문제가 발생한다.


3. Host machine이 죽어버리는 경우


Host machine의 권한을 많이 줄 수록 Host machine의 역할은 중요해진다. 그런데 Host machine이 죽어버리는 경우 다른 VM들은 Host machine에 권한을 주었던 일을 할 수가 없다. 따라서 Host machine은 어떻게든 튼튼하게 만들고, VM들 끼리는 최대한 isolation을 보장해야 한다. 그런데 말은 쉽지 실제로 하기는 어렵다.


4. 디도스 공격



다른 VM이 Host VM에 DDoS 공격을 가하는 것이다. DDoS 공격이란 것이 뭐 엄청난 기술이 아니고 요청을 무지 많이 보내는 것이다(청와대 홈페이지를 다운시켜버린 시민 디도스 공격 처럼). Host VM은 특정 VM이 보낸 요청들을 처리하느라 포화 상태가 되버리고 다른 VM들의 요청을 처리 할 수 없는 상태가 되버린다. 다른 VM들이 보낸 요청 중에 시스템적으로 중요한 사항이 있다면 문제가 심각해진다. 위 경우는 Host VM 이 죽는 경우랑 비슷하다고 보면 된다.

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

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
2. Xen 기본 구조/Hypercall  (0) 2016.11.05

4. Domain 장치 드라이버 개발

컴퓨터공부/가상화기술 2016.11.27 21:36 Posted by 아는 개발자 아는 개발자

Domain의 장치 드라이버 개발 설명에 앞서 왜 장치 드라이버 개발이 필요한지 먼저 알아보자.


일반적으로 OS는 각각의 드라이버(네트워크, 블록 등등)를 통해 실제 하드웨어 장치를 제어하는 시스템을 가지고 있다.



하지만 가상화 환경에서는 하드웨어는 하나인 상태에서 여러개의 OS가 떠있다. Xen 플랫폼 내에 구동중인 여러 Domain들이 각자 하드웨어 Device들을 각자의 방식으로 제어하려 한다면 어떻게 될까? 물건은 하나인데 주인이 여러명이 생기는 엉뚱한 상황이 벌어질 것이다. 각 Domain들의 하드웨어 통제권을 정리하기 위해 Xen은 Domain0에게 하드웨어를 제어하는 독점적인 권한을 주고 나머지 DomainU 들은 Domain0의 통해서 하드웨어에 접근 할 수 있도록 규칙을 세웠다.


간단히 도식화 하면 다음과 같다.

  1. DomainU가 하드웨어 제어권을 가진 Domain0에게 하드웨어에 대한 접근을 요청한다
  2. Domain0는 DomainU의 요청을 받고 드라이버를 통해 하드웨어에 접근한다.
  3. 드라이버에서 받은 결과값은 DomainU에게 다시 전달한다.
크게 세가지 구조로 이뤄져 있지만 실제 구현 방식은 위와 같이 간단하지 않다. 하드웨어 접근 요청을 하는 방식과 결과 값을 어떻게 전달 할 것인지를 생각하면 머리가 복잡하다. 하지만 요청과 결과값을 전달하는 방식은 이미 한 번 다룬 바 있다. Domain 간의 통신 방법에서 grant table과 ring을 이용해 요청을 전달하고 데이터를 전송 할 수 있었다.



Xen 위에서 동작하는 Domain0와 DomainU 장치드라이버들 들을 위와 같은 방식으로 구현해준다. 위 방식을 적용한 드라이버들을 Para-Virtualization(반가상화) 이름을 따서 PV드라이버라고도 한다. 크게 하드웨어 접근을 요청하는 DomainU의 PV장치드라이버를 Frontend라 하고 접근을 받아 처리하는 Domain0의 PV드라이버를 Backend로 정의한다. 

실제로 위와 같은 구현 방식으로 되었다고 PV드라이버 개발이 끝나는 것이 아니다. 각 하드웨어 장치들마다 저마다 특별한 요구사항이 있다(네트워크 드라이버인 경우에는 가상 브릿지, 스위치... 매우 복잡하다) 하지만 공통적인 드라이버 작동 방식은 위와 동일하다.

* 위와 같은 구조를 가진다면 요청 작업  + 전달 받는 작업이 있기 때문에 DomainU가 하드웨어에 접근 할 때 오버헤드가 발생한다.  오버헤드를 피하기 위해 특정 하드웨어는 Domain0에게 제어권을 주지 않고, DomainU에 제어권을 주는 Passthrough 방식도 있다고 한다. 주로 그래픽 드라이버 처럼 대용량 데이터를 처리해야 하는 경우에 적용된다고 한다. https://wiki.xen.org/wiki/Xen_VGA_Passthrough 참고





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

5. 이벤트 채널 소개  (0) 2017.01.07
가상화기술의 대표적인 보안 문제  (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

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

가상화기술 Type1

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

가상화 기술 Type1은 가상화 소프트웨어가 OS의 형태(OS로 말하기는 좀 부족하고 기능이 추가된 바이오스라 생각하면 좋다)로 구현된 것이다.


대표적인 소프트웨어로는 Xen,과 Window Server로 사용되는 Hyper-V가 있다. Type1은 일반 사용자들에게 익숙하지 않은데 아마 주로 서버 개발에 사용되기 때문일 것이다. 클라우드 컴퓨팅 회사에서 비싼 서버 한 대를 이용해 여러 개의 서버를 돌리듯한 효과를 주기 위해 Type1의 가상 기술을 이용한다.


위 방식은 Hypervisor가 하드웨어 통제권을 가지고 있다는 장점이 있다. Type 2에서 Hypervisor가 하드웨어의 통제권을 가지지 못해 하드웨어를 제어하는데 오버헤드가 많이 걸렸는데 여기선 Hypervisor가 하드웨어를 장악하고 있고 이걸 Guest OS에 빠르게 전달하기 위한 API를 따로 가지고 있기 때문에 각각의 Guest OS에 필요한 정보들을 빠르게 줄 수 있다.


이때 구현되는 Guest OS는 Para-virtualization의 형태로 구현된다. Para-virtualization은 Guest OS가 자신이 가상머신의 형태로 올라가는 것을 알고 있는 상태이다. Guest OS의 코드를 수정해서 Hypervisor에서 제공하는 API들을 사용할 수 있도록 구현해야 한다. 어떤 형태의 Hypervisor를 사용하느냐에 따라서 Guest OS의 수정 정도가 달라진다.


Hypervisor는 Guest OS의 생성과 운영을 책임진다. Guest OS가 부팅 될 때는 Hypervisor로 부터 RAM 영역이나(이건 소프트웨어에 따라서 다르다) 기본적인 하드웨어 정보를 전달 받고 작동중에는 Hardware 정보들을 전달, 전송 받는다. 만약 Hypervisor가 불안정하면 그 위에서 동작하는 Guest OS까지 불안정해지는 위험이 있다. 그렇기 때문에 최대한 안정성 있게 만들어야 한다.


정리하면 Type1으로 개발할 때는 다음과 같은 요구사항이 있다.

  1. 신속성: Hypervisor는 Guest OS와 Hardware사이의 중간 관리자이다. Guest OS가 요구하는 정보들을 빠르게 전달해야 한다.
  2. Guest OS 수정: Guest OS와 Hypervisor가 통신이 가능하도록 코드를 주어해야 한다.
  3. 안정성: GuestOS 동작이 불안해지지 않도록 만들어야 한다.
위 세가지가 Type1 가상화 기술 개발의 목표이다. 장점은 Hardware를 Hypervisor 입맛에 맞게 요리 할 수 있다는 것이고 단점은 Guest OS를 Hypervisor의 API에 맞춰서 수정해야 한다는 점이다.


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

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
가상화 기술이란?  (1) 2016.07.31

가상화기술 Type2

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

가상화 기술 Type2는 가상화 기술을 애플리케이션의 형태로 구현하는 방식이다.

대표적인 예로는 VMware, Virtual Box처럼 윈도우나 리눅스에 설치 할 수 있는 소프트웨어이다.


이러한 형태의 구현 방식은 기존 PC 시장에 쉽게 가상화 기술 소프트웨어를 도입 할 수 있다는 이점이 있다. 또한 Host OS가 제공하는 시스템콜과 하드웨어 제어권을 빌려오는 형태여서 여러가지 요소들을 신경쓰지 않고 구현(실제로는 생각을 많이 써야 하지만 처음부터 다 만들어 가는것은 아니기 때문에)할 수 있다. 애플리케이션 형태이기 때문에 안전성에 문제가 생겨도 Host OS 자체의 안정성은 침해하지 않는다는 장점이 있다.


하지만 위 방식은 느리다. 가상화 소프트웨어가 하드웨어를 직접 통제하는 것이 아니기 때문에 하드웨어에 명령을 전달하거나 받을 때 OS를 한 번은 거쳐야 하는 단점이 있다. 예를들어 가상화 소프트웨어에서 우분투를 실행하고 메모장에 특정 문장을 입력할 때를 생각해보자. Host OS에서 메모장에 글을 입력 할 때는 다음과 같은 플로우일 것이다.


타자 입력 -> Host OS interrupt handler -> 입력된 값을 메모장 process에 전달 -> 메모장에 출력.


하지만 우분투를 가상화 기술에서는 플로우가 추가된다.


타자 입력 -> Host OS interrupt handler -> 입력된 값을 가상화 소프트웨어에 전달 -

우분투(가상 OS) interrupt handler -> 입력된 값을 메모장 process에 전달 -> 메모장 출력


가상 OS또한 스스로가 OS의 형태로 동작하는 것으로 인식해야하기 때문에 기존 Host OS가 하는 방식과 동일하게 작동해야하고 이 과정에서 오버헤드가 발생한다.


프로세스가 2-level 로 페이지 테이블을 관리 한다면, Guest OS에서는 Host OS의 페이지 테이블(2-level) + Guest OS의 페이지 테이블(2-level) 총 4-level의 페이지 테이블을 사용하는 것과 같다. translation 오버헤드도 많이 생기게 된다.


위 단점을 해결하기 위해 다양한 솔루션들이 제시되었다. ARM, Intel같은 하드웨어 회사들은 OS의 virtualization을 지원하는 기능(LPAE, VT-x)등등을 제공하고 리눅스 커널에서는 이러한 하드웨어 feature들을 쉽게 사용 할 수 있도록 kvm과 같은 것을 제공한다. 이러한 기능들을 응용해서 네트워크나 그래픽 가속화 결과 기존 OS대비 90%정도의 효과들을 보고 있다고 한다.

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

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
가상화 기술이란?  (1) 2016.07.31

가상화 기술의 유형

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

가상화 기술은 어떤 방식으로 구현하느냐에 따라 크게 Type 1& Type 2로 나뉜다.


직관적으로 이해하기 위해 먼저 그림으로 표현하면 다음과 같다.



위 두 그림의 가장 큰 차이점은 Hypervisor(가상머신)의 존재 형태이다, Type1에서는 Hypervisor가 하드웨어를 관리하는 운영체제의 일종으로 보이고, Type2에서는 Host OS의 application과 동등한 형태를 띄는 것으로 보인다. 


가상화 기술은 "Hypervisor를 어떠한 형태로 개발할 것이냐"에 따라 두가지로 나눌 수 있다.


- Type1 : Hypervisor를 OS의 형태로 개발한다. 

- Type2 : Hypervisor를 Application의 형태로 개발한다.


아마 대부분의 사람들에게 익숙한 형태는 Type2일 것이다. 가장 많이 알려진 VMware나 VirtualBox가 위와 같은 방식으로 구현된다. Type1은 서버 가상화를 경험해본 사람이나 혹은 임베디드에 깊게 빠져본 사람이 아니라면 거의 대부분의 사람들 경험해보지 못했을 것이다.


그럼 이제 근원적인 물음을 던질 때가 되었다. 왜 Type1의 형태로 개발하는가? Type1과 Type2는 각각이 무슨 장점이 있는가?


짧게만 설명하자면 Type1은 가상화로 실행되는 GuestOS의 하드웨어 접근성을 높일 수 있다는 장점이 있고 Type2에서는 이미 만들어진 OS의 변경 없이 구현이 가능하다는 장점이 있다.

(하지만 각각의 구현 방식과 세부적인 장점을 설명하기엔 위 포스팅만으로는 짧은것 같아 다음 포스팅에 남긴다.)


위는 Hypervisor의 구현 형태에 따른 분류 방식이고, Guest OS와 하드웨어사이의 관계에 따라 전가상화와 반가상화로 나눌 수 있다.


- 전가상화(Full Virtualization): Guest OS가 스스로가 Guest OS인 것을 알지 모르는 상태. 즉 자신이 Hardware에 대한 통제권을 쥐고 있다고 인식하는 상태이다. Guest OS가 생각하는 Hardware는 Hypervisor에서 에뮬레이션 해준 형태이며, 이때는 Guest OS에 대한 특별한 수정이 없어도 구현이 가능하다. Type2로 개발 할 때 위와 같이 구현 한다.


- 반가상화(Para-Virtualization): Guest OS가 자신이 Guest OS로 구현된 것을 아는 상태. 즉 Guest OS를 수정해 Hardware에 접근하는 부분들을 Hypervisor에서 제공하는 API의 형태로 수정한 형태이다. Type1에서 위와 같은 방식으로 구현한다. Guest OS의 소스코드를 알지 못하면 구현하기 어렵다.




하드웨어 접근에 대한 방식이기 때문에 어떤 방식을 채택하느냐에 따라 Guest OS의 성능이 다르다. 세부적인 내용은 Type1, Type2를 설명하는 포스팅에 추가하도록 하겠다.

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

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
가상화 기술이란?  (1) 2016.07.31

가상화 기술이란?

컴퓨터공부/가상화기술 2016.07.31 23:22 Posted by 아는 개발자 아는 개발자

 대학교 1학년때 컴퓨터에 대해서 관심을 갖기 시작할 시절, 동기중 한 명이 Virtual Box라는 것을 이용하면 하나의 PC로 여러개의 운영 체제를 구동 할 수 있다는 것을 알려 주었다. 그 친구는 자신의 집에서는 윈도우 위에 우분투라는 것을 올렸다며 엄청난 기술이라고 호들갑을 떨었는데 당시 나는 전공 초짜였지만 기술 지식에서 뒤쳐지는게 싫어서 "오 그래? 대단한걸? 나도 집에가서 해봐야겠다!"라고 말해놓고 우분투는 대체 뭐고 왜 하나의 PC에 여러 개의 운영체제를 올려야 하냐며 혼잣말을 했었던 기억이 난다.


 하지만 운영체제 수업에서 리눅스라는 환경을 처음으로 경험하게 되고 후에 RoR(Ruby on Rails), NodeJs등을 이용해 개발하는 일이 늘어나면서 리눅스는 나와 뗄레야 뗄 수 없는 사이가 되었다. 리눅스 PC를 추가로 구매할 여력이 없던 학생 신분인 내게는 가상머신이 1학년때 한 말이 무색할 정도로 정말 필수적이었고 그중에서 VMware사에서 제공한 VMPlayer 가상머신은 구세주와 같은 존재였다(지금은 서비스가 중단되었다고 들었다)



( VMplayer를 이용해 윈도우10에서 Ubuntu를 사용하는 환경 가상화기술의 발전으로 윈도10에서 사용하는 것과 속도감 차이가 거의 없다 )


  하나의 PC에 여러개의 운영체제를 사용할 수 있는 소프트웨어로는 대표적으로 VMware사에서 제공하는 Vmware Workstation과 Oracle의 오픈소스 프로젝트중 하나인 VirtualBox가 있다. 아마 대학교 3학년 운영체제를 처음으로 경험하는 학생들이 가장 많이 사용하는 소프트웨어일 것이다. 이외에도 오픈소스로 운영되고있는 QEMU, 리눅스재단에서 운영되는 XEN등 여러가지 소프트웨어가 시중에 존재한다. 이러한 소프트웨어들은 다른 운영체제를 사용하는것 뿐만 아니라 현재 사용하고 있는 운영체제에서(기술 용어로는 Host PC라 한다) 추가한 운영체제(기술용어로 Guest 또는 VM이라 한다)의 네트워크나 CPU의 개수와같이 하드웨어 옵션을 변경 할 수 있는 기능도 가지고 있다..


 위의 소프트웨어들처럼 하나의 하드웨어로 여러가지 운영체제를 동시에 사용 할 수 있는 기술을 가상화기술이라고 한다. 하지만 이건 가상화기술의 부분적인 의미에 불과하다. 위키피디아에서는 "물리적인 컴퓨터 리소스의 특징을 다른 시스템, 응용 프로그램최종 사용자들이 리소스와 상호 작용하는 방식으로부터 감추는 기술" 로 가상화 기술을 정의한다. 나는 개인적으로 가상화 기술을 하드웨어 사용성을 극대화한 기술이라고 짧게 정의한다.


 시중에 가상화 기술을 응용한 소프트웨어는 정말 많다. 앞에서 언급한 VMware나 VirtualBox처럼 HostPC위에 GuestOS를 올리는 것뿐만 아니라 AWS, Microsoft Azure, Heroku같은 클라우드 컴퓨팅 서비스도 가상화기술을 사용한 소프트웨어의 일종이다. 클라우드 컴퓨팅회사가 가상화 기술을 사용하는것에 생소하게 느껴지시는 분들이 있을 것이다(나도 책을 읽어보기전에 그랬다)


 스타트업같은 소규모 회사에서는 클라우드 컴퓨팅 회사에 트래픽이나 코어의 개수와 같은 요구 스펙을 말하고 클라우드 컴퓨팅 회사는 사용자가 요청한 스펙에 맞게 서버를 열어준다. 그러면 사용자는 별도의 하드웨어를 구매할 필요 없이 클라우드 컴퓨팅 회사에서 제공하는 서비스를 사용 할 수 있다. 하지만 실제로 클라우드 컴퓨팅회사에서 사용자가 요구한 하드웨어를 100% 그대로 제공한 것은 아닐 것이다(그러면 직접 서버를 사는거랑 다를바가 없다)


  클라우드 컴퓨팅 회사에서 실제로 운영하고 있는 대규모의 하드웨어 서버가 있지만 유저가 원하는대로 각각의 매칭시켜주기에는 역부족일 것이다. 그래서 클라우드 컴퓨팅 회사들은 하드웨어 서버를 가상화해 효율적으로 사용 될 수 있도록 한 후 사용자가 요구에 따라 VM에 옵션을 바꿔주는 형태로 제공한다.


( 클라우드 컴퓨팅 회사 아키텍처 )


  *인터넷 쇼핑몰이었던 아마존이 박싱데이 시즌에 밀려드는 엄청난 트래픽을 감당하기위해 서버를 많이 사다 두었었는데 박싱데이 시즌을 제외하곤 정작 대부분의 서버들이 놀고있어 문제였었다고한다. 서버들의 사용성을 극대화하기 위해 생각해낸 비즈니스모델이 클라우드 컴퓨팅이었고 대성공을 이뤄 지금은 아마존과 별도로 AWS란 이름으로 운영된다.


  위에서 언급한 것 외에도 아직 내가 알고 있지 못한 분야에서 가상화 기술은 많이 활용되고 있다.


  가상화 기술의 개념은 동일하나 이것을 어떤 방식으로 구현할 것이냐에 따라서 크게 두가지(Type1, Type2)로 구분된다. 두 가지에 대해선 다음 포스팅에 쓰도록 하겠다.

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

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
가상화 기술이란?  (1) 2016.07.31
  1. Luke J 2019.08.15 11:16  댓글주소  수정/삭제  댓글쓰기

    최근에 가상화에 관심이 가기 시작한 "도대체 우분투는 뭐고..." 하는 수준과 별반 차이 없는 초보개발자입니다. 적당히 깊이로 잘 정리해주신 덕에 제 개인적으로는 아주 유익한 글들이었습니다.
    고맙습니다^^