Final Exam

Confirm

gVisor 외 3개의 Container에 대한 Fire Read 에 대한 성능 비교

Host, LXC, gVisor 는 Disk 로 부터 읽어와야되기 때문에 파일의 크기와 상관없이 Read Throughput 이 약 200MB/sec 로 동일하다. Firecracker 는 3가지 종류로 나누어서 평가하였다. 먼저 알아두어야 할 것은 flushing cache 라는 것인데, 캐쉬를 일정 시간동안 사용하지 않으면, cache에서 데이터를 삭제한다.

Firecracker 는 microVM 의 캐시를 초기화하였음
Firecracker + host 는 호스트 커널의 캐시를 초기화하였음
Firecracker (fc+host) 는 두 군데 모두의 캐시를 초기화하였다.

Firecracker (fc+ host) 는 모든 곳에서 캐시를 삭제하였기 때문에 다른 Host, LXC, gVisor 와 마찬가지로 디스크로 부터 읽어오므로 성능이 유사하다.

Firecracker + host 는 guestOS 캐시로부터 데이터를 가져오므로 성능이 가장 좋다. 거의 RAM 에서 가져오는 속도(memory speed)와 같다.

Firecracker 는 microVM 의 캐시가 없고, Host 커널에 존재하는 캐시로부터 데이터를 가져와야하므로 Firecracker 보다는 속도가 빠르지만, Firecracker + host 의 절반 성능이다.

Expectation

Why Vserver is in Isolation 2? what isolation is missed? (VServer)

Hypervisor-based
COS(container-based operating system)-based : Solaris 10, Virtuozzo for Linux, Linux VServer

Fault Isolation is missed

Fault Isolation : 결함을 가진 VM 이 정상적인 VM 을 손상시키지 않는 것을 의미한다. 완전한 Fault Isolation 을 보장하기 위해선, VM 과 VM 에 속한 코드 및 데이터를 공유하지 않는 것이다. VM 같은 경우 다른 주소에 위치하면서 독립이 되지만 코드나 데이터 같은 경우 일부 공유되기 때문에 서로 영향을 미칠 수 있다.
- Hypervisor : 적은 인터페이스(narrow interface) 로 덜 노출이 된다.
- COS : 방대한 ABI 로 (wide system call ABI) 로 취약하다고 볼 수 있다.
Resource Isolation : 하나의 자원이 다른 VM 자원 사용을 방해하지 않는 것을 의미한다. Hypervisor, 그리고 COS 는 resource schedulers 을 제공함으로써 Resource Isolation 을 보장한다.
Security Isolation : VM 이 파일, 포트 번호, 프로세스 id 등에 접근하지 않는 것을 의미한다. 하나의 VM 이 속한 파일명 등을 다른 VM 이 알 수 없다. COS 는 부분적 고립하는 방식을 채택하기도 하였지만, Hypervisor, 그리고 COS 는 시스템의 안전성을 위해서 논리 객체를 서로 감춘다.

Vserver Filesystem

VM 들 간의 공통적으로 사용되고, 거의 쓰이지 않는 파일들 (ex. OS 배포판의 라이브러리 파일) 은 공유 파일시스템 (shared filesystem) 안에 하드링크로 연결될 수 있다. 하드링크는 안전한데, guest vm 의 파일이 지워져도 공유된 파일 시스템에서 지워지지 않고, 같은 inode 를 공유할 수 있기 때문에 amount of disk space, inode cache, 등의 자원을 줄일 수 있다. 결점은 vm 이 고의적이든 그렇지 않든 이 파일에 지우거나, 수정할 수 있는데, 이것은 하드 링크된 파일에 속성을 CoW(Copy on Write) 속성으로 바꾸면 해당 파일의 private copy 를 주기 때문에 해결될 수 있다.

하드링크 : 원본 지워져도 지워지지 않음 / 수정 원본, 하드링크된 파일 둘다 반영
소프트 링크 : 원본 지워지면 무용지물
복사 : 원본 지워져도 지워지지 않음 /

성능 평가 (VServer)

하나의 프로세서 기반에서 Linux 와 VServer 는 CPU 사용량 약 70%만을 가지고, Line rate 에 근사하였다. Xen3-Up 과 같은 경우, CPU 사용량을 초과하고도 line rate 의 60% 를 달성하였는데 이는 host VM, guest VM 그리고 hypervisor 가 모두 single CPU 에 묶여 있고, VM 간의 스위칭에 오버헤드가 걸리기 때문이다. 두개 CPU 를 사용한 Xen 은 host 와 guest 가 서로 방해하지 않기 때문에 Linux, VServer 와 같이 line rate 를 달성할 수 있다. (Figure5)
VServer 의 Performance Isolation 은 좋지 않다. 시분할 시스템 unix 에서 Resource Consumption Attack에 취약하다. Vserver 가 이러한 간섭에 얼마나 성능이 변화하는지 확인하기 위해서 모든 VM 이 공유하는 디스크에 dd(6GB 을 쓰는 작업) 을 수행하였다. 그 결과, VServer 의 평균 네트워크 출력 (tcp/sec) 이 13% 감소하는 것을 파악하였고, 이는 VServer 의 block cache 가 모든 VM 이 공유하는 공간에 존재함을 이야기 한다. 반대로 Xen 은 각 VM 이 물리적으로 분리된 disk 에 block cache 가 존재하므로 방해를 주지 않는다. 따라서 Xen 의 출력 성능이 더 좋은 것을 볼 수 있는데, Xen-UP 은 기존보다 12% 감소하였고, Xen-SMP는 1% 증가하였다. 전자는 dd 라는 동작도 프로세스 시간을 취하기 때문에 그런 것이고, 후자는 처음부터 성능이 scheduling 기법으로 낮았기 때문에 오른 것이라고 할 수 있다. (Figure9)

Borg 의 사용자는 구글 개발자이고, 그들은 자신들의 Task 로 이루어진 JOB 을 Borg cell 에게 요청한다. 높은 우선수위에 있는 job 을 prod 라 하고 그 외의 job 을 non-prod 라고 하자.

cell sharing : non-prod job 과 prod job 을 분리하여 cell 에게 줄경우, 20~30% 의 머신이 더 필요하다. 왜냐하면, 간혹 있는 스파이크 시점을 처리하기 위해, 평상시에는 사용하지 않는 리소스들을 예비해두기 때문이다. Borg 는 사용하지 않는 리소스들을 non-prod job 에게 주면서 전체 더 적은 머신을 필요로 하게 된다. 따라서, Borg 는 수천개의 고객으로 부터 오는 job 들을 borg cell 들이 공유한다.

하지만, 서로 다른 종류의 job 들이 cell 에서 공유될 경우, (ex. 공유: fdai 연구실이 자연어처리도 하고 객체인식도함. 분리 : fdai 연구실은 객체인식만함) 더 많은 머신들이 필요하지 않을까? 고민하여 CPI 기준으로 실험하였다. CPU 성능은 공유 될 때 더 낮았다. 즉 cell 을 공유할 때, 프로그램 수행속도가 더 느렸다. CPU 속도 저하는 머신 수를 줄이는 것보다 더 높게 평가될 수 없으므로 메모리, 디스크 자원 사용에 공유 방식은 이점이 있다.

Resource reclamation (Borg)

Borg task 가 얼마나 많은 자원을 요청하고, 나머지들을 환원활지 추정을 하는데 이 추정을 Reservation 이라고 한다. 이 추정은 학과장님(Borgmaster) 에 의해 매초마다 일어나고, 초기 reservation(얼마나 많은 연구실, 연구원을 필요로 할지) 은 job 에 명시된 것에 따른다. 그리고 300초 후에 Borglet 에 의해서 사용량(usage) 이 된다.

Performance Isolation (Borg)

Borg 에서 Performance를 Isolation 하는 방식(하나의 Task 가 다른 Task 의 성능을 미치지 않도록)은 (1)Borg 의 모든 Task 는 Linux cgroup based container 안에서 실행되면서 리소스 컨트롤을 한다. (2) Task 를 Latency sensitive-AC 와 Batch-AC 로 나누어서 LS-AC 는 우선순위가 높은 Task 를 먼저 신경쓴다. (3) Compressible (ex. CPU cycles, disk I/O bandwidth) 는 그의 성능을 줄이면서 환원될 수 있다. 하지만 Non-compressible (ex. memory) 는 task 를 죽이지 않으면 환원할 수 없다. 따라서 Non-compressible 이 소진될경우, 낮은 순위의 Task 부터 task 를 kill 하며, compressible 이 소진되면, throttles usage (사용량을 감량하고) 그래도 안되면 kill 한다. (4) Borglet 은 동적으로 LS task 가 요구하는 자원량으로 조정하고, 따라서 몇분동안 batch task 가 없는 상태를 막는다. (5) 스케줄링의 지연시간을 줄이기 위해서 batch task 가 LS task 에 의해 매수되는 것을 허용하며, 다수의 LS task 가 하나의 CPU 위에서 실행 될 시, 더 나은 상호자용을 위해 scheduling quantum 을 줄인다.

Why 1500B performance is lower than 64B? (ClickOS)

최적화하였을 때는, 8->344까지 크게 상승한다. xen 에 기본적으로 있는 Open vSwitch 대신에 VALE(netmap) 를 사용하여 스위치를 변환시킨다. 1200kpps 까지 크게 상승하여서 스위치를 바꾸는 것도 네트워크 성능에 영향을 준다. 하지만 왜 1500 byte 의 패킷에서는 64 byte 패킷보다 성능이 낮을까? (hold)

성능 평가 (clickos)

IO pipe line rate 만큼의 성능을 낸다. (Figure7)
KVM 과 비교하여 XEN 은 성능이 비슷하였으나, 최적화한것은 훨씬 우수하였다. (Figure8)
chaining(firewall follwed by IDS) 이 많아질수록, 성능이 저하된다. (Figure 10)
VM 이 증가하여도 크게 Click OS 의 확장성이 차이가 나지 않는다. (Figure 11)
다양한 middle box 에서 ClickOS의 성능 측정시, Throughput 은 line rate 와 유사하였다. 1pps = 672bps (Figure13)

생성, 정지, 통합등의 동작을 위해 XenStore 사용을 포기할 수 있는가? (LightVM)

VM 의 중요한 정보(ex. VM's id)들은 하이퍼바이저에 저장되어 있고 이미 centralized store 역할을 하기 때문에 포기할 수 있다. (1)새로운 VM 생성 시, Xen 의 하이퍼바이저의 메모리를 생성하여 VM 의 정보를 기록하도록 하였다. (2) 그리고 이 메모리로부터 읽고 쓸수 있는 hypercall 을 만들었다. (guest : read-only, dom0 : modification-보안상의 이유로 backend 만 memory write 이 가능함.)

따라서, VM 생성시 (1) toolstack 은 backend 에게 memory page 를 만들어달라고 요청한다. (2) toolstack 은 하이퍼바이저에게 중요 정보를 device page 에 기록하라고 요청한다.

VM 이 부팅시, (1) 하이퍼바이저에게 device page 의 주소를 요청한다. (2) hypercall 을 이용하여서 page 를 그 주소에 매핑시킬 것이고, (3) guest 는 백엔드와 communication 하는데 이를 사용할 것이다.

성능 평가 (LightVM)

LightVM 이 Instantiation 가장 빠르고, VM 이 늘어나도 상관없다. 하지만 Daytime unikernel 을 사용했다는 것을 고려하자. 이를 Nox Driver or XenStore + Toolkit 과 비교함 (Figure9)
750VM 까지 TinyX 는 Container 와 성능이 유사하였다. 그 후부터 데몬이 백그라운드에서 실행되므로 부팅시간이 증가한다. Unikernel : 4ms - 이상적임, Tinyx : 200ms - 현실적임 (Figure11, Booting time)
Checkpoint 이 LightVM 이 Xen 보다 훨씬 빠름(Figure12)