VMMB: Virtual Machine Memory Balancing for Unmodified Operating Systems

VMMB: Virtual Machine Memory Balancing for Unmodified Operating Systems

Changwoo Min, Inhyeok Kim, Taehyoung Kim, Young Ik Eom

J Grid Computing (2012)

Abstract

가상화에서 CPU와 I/O는 시간적으로 분리하여 공유가 가능하지만 Memory는 하나의 공간을 공유하는것이 불가 하기 때문에 자원을 효율적으로 사용하는것이 중요하다. 

실시간으로 메모리의 demand를 모니터 하여 주기젓으로 re-balance하는 VMMB라는 것을 구현하였고 실험하였다.

메모리 공간의 여유가 3.6배의 향상된 결과가 나왔다 낮은 오버해드로(1% 모니터링 하는 overhead) 

Introduction

// 물리적으로 메모리량을 증가 시키키는 어려움 

메모리는 시간적인 분리를 통하여 공유 하여 사용할수 없기 때문에 그 메모리 량을 늘리는 방법으로 해결할수 있다.

하지만 메모리 량을 늘리는것은 어렵고 비용이 발생한다, 외냐면 마더 보드에 스롯과 메모리를 지원하는 모듈이 같이 추가 되어야 하기 때문이다. 

그리고 메모리량을 늘리는것은 에너지 문제도 발생한다. 일반 서버 컴퓨터의 사용 전력의 40% 메모리가 사용한다 이 량은 CPU 의 사용량보다 약간 더 많은 규모이다. (메모리의 량을 늘리는것은 에너지 소비의 상승을 말하게 된다.)

// 가상화를 위하여 메모리 공유의 효율성을 향상시키는 데이터 센터에서 사용하는 방법 2가지

dynamic memory balncing : VM의 메모리 요구를 분석하여 그 요구에 따라 할당하는 방법

VM migration : overload된 VM을 찾아내고 그리고 이상적인 물리적 머신으로 재 할당한다. 

마이크레이션 하는 동안 VM은 완전하게 사용이 중단된다. 이것은 데이터 센터에 부정적인 영향을 미치게 된다. 마이그레이션은 무거운 해결책이기 때문에 데이터 센터에서 최소화 해야만 한다. 그렇기 때문에 VM migration기술은 지속적으로 overload가 발생할경우 suited한 기술이다. 이에 반하여 dynamic memory balncing은 일시적인 workload에 적합하다. 

// 데이터센터의 메모리 오버로드에 대한 분석 논문 [19]

[19]번 논문의 결과 데이터 센터의 메모리 오버로드는 대부분 일시적인 으로 발생한 2분 이하로 그리고 데이터 센터에서 발생하는 오버로드 자체가 매우 잖다. 1.76%정도 발생하게 된다. 이 의미는 물리적으로 컴퓨터를 공유하는 VM이 동시에 상호 연계 된 메모리 과부하가 발생할 가능성이 존재 한다는 것이다. 

데이터 센터의 메모리 과부하의 특성을 고려하여, 동적 메모리 밸런싱 기술은 메모리 과부하의 대부분을 완화 할수 있다. 하지만 그것은 아직 한계를 가지고 있다. 통계적인 샘플링으로는 현재 할당 된 메모리 크기보다 메모리 수요가 크게 추정 할 수 없다. 그리고 현재 메모리 할당된 자원보다 낮게 측정될수도 있다 버퍼 캐시에 영향을 받기 때문에 또한 이 페이지 오류 및 버퍼 퇴거를 추적하는 페이지 테이블 업데이트 정보에 의존하기 때문에, 게스트 페이지 테이블을 조작 할 때 VMM에 트랩을 제거 하드웨어 MMU 가상화 지원과 호환되지 않습니다. (가상화이기 때문에 VMM이 게스트 페이지 테이블를 추적할수 있는 트랩이 제거 된다는 이야기 같음 하드웨어의 MMU 가상화를 사용할수 없다.) 하이퍼 바이저의 전용캐시를 통하여 메모리 사용 요구의 증가와 축소를 추론할수 있다(하드웨어 가상화 이용) 하지만 이것은 게스트의 소스 코드가 없다면 사용할 수 없다.

왜나면 이것은 게스트 OS의 수정이 필요하다 to 버퍼캐시의 eviction와 promotion을 모니터 하기 위해서

//논문[5] 에서 사용량을 예측 하는 방법이 제안 되었다. 

LRU histogram이 재안 되었는데 기본적으로 매모리 요청을 예측하는것이다. 하지만 이것은 큰 working set에서 많은 overhead를 발생시키낟. 왜 냐면 LRU histigram을 업데이트 하는 계싼 비용이 working set 사이즈에 크기에 선형적으로 증가 하기 때문이다. 

// 위같은 배경때문에 요구되어진 VMMB에 대한 설명 

이 논문에서는 VMMB에 대하여 설명하게 되는데 이 메카니즘은 vm할당된 메모리의 크기를 다이나믹하게 재 할당하는 방법이다. VMM은 메모리 효청를 추정하기 위해 각 VM의 메모리 사용량을 모니터링하고 주기적으로 추정 메모리 수요에 따라 메모리의 균형을 조정한다. 이전 작업들과 VMMB와 구별되는 특징은 다음과 같다. 

1. VMMB는 게스트 커널을 수정하지 않고 LRU 히스토그램을 사용하여 할당 된 크기 위 아래 메모리 수요를 추정 할 수있다.

swapping 게스트를 모니터링하기위한 메모리 액세스 및 pseudo swap device 모니터링하기위한 nested page fault 사용하여 달성된다. // 하드웨어 가상화 기술을 사용하는것 이므로 SPARC에서는 적용 할 수 없다. 

그리고 효율적으로 LRU 히스토그램을 생성하는 방법을 제시한다. 

2. 그리고 Qos를 지원하는  LRU histogram 가이드된 메모리 할당 알고리즘을 제안한다.

제안된 알고리즘은 페이지 미스율을 최소화 할 수 있는 VM메모리 할당 크기를 결정한다. 

VM은 서로 다른 Qos요구사항을 가지고 있으며 이것은 메모리 할당 결정에 반영된다.

3. 마지막으로 이들은 ballooning을 기술을 조합하여 사용하였다. 그리고 VMM 수준에서 효율적으로 victim page를  선택하고 그리고 즉각적으로 메모리를 할당한다 to VM의 이익을 위하여 

VMM수준의 스와핑 효율을 위한 avoid double paging anomaly 기술에 대해서도 소개한다. 같은 페이지가 VMM과 VM에 의해 victim page로 선택 때 심각하게 성능이 저하 될 수 있습니다.

2 Design of the System 

전체적인 시스템에대하여 설명할것이며 

1) 게스트 코드의 수정없이 효율적인 LRU 히스토그램을 구성하는 방법 

2) 각각의 VM의 메모리 demand에 따라서 메모리를 다이나믹하게 re-balancing 하는 방법

3) 효율적인 VMM 수준의 스와핑에 대하여 설명한다. 

2.1 system overview

 위 그림과 같이 구성되 어 있으면 3가지 부분으로 나눌수 있다. 

1. VMM은 VM으로 부터 메모리 접근과 swapping operation을 인터셉트 하여 LRU histogram을 생성한다. 

2. VMM은 주기적으로 각각의 VM에게 할당되어야할 최소한의 메모리  할당의 크기를 결정해야 한다. (페이지 미스 비율이 최소화 할수 있는 량을 정하는데 LRU histogram을 바탕으로 유도된다. Qos도 고려 된다. )

새로운 메모리를 할당할때는 ballooning technique이 사용된다. 언제 VM에게서 메모리를 회수할때 이것은 VMM에게 보고되어 그 메모리를 다른 VM에 할당 할수 있도록 한다.  

3. VM으로 부터 VMM은 보조메모리를 교환하여 VMM수준에서 스와핑한다. 

VMM은 우선적으로 메모리를 확보하기 위해 ballooning technique를 사용한다. 그러나 메모리가 충분한 시간에 회수되지 않은 경우, 시스템은 스와핑 장치로 떨어진다. 

2.2 Building the LRU Histogram

LRU historgam은 VM의 메모리 접근과 스와핑 오퍼레이션을 모니터링 하여 구성하게 된다. 메모리 접근을 모니터링 하는것은 현재 할당된 메모리의 수요를 추정하는데 필요하다. 

이들은 nested page table (=second level address translation 하드웨어 가상화 지원도구) 의 bit를 해제 하는 방법을 사용하게 되는데 이렇게 함으로써 게스트 OS의 소스 코드를 수정 하지 않아도 된다. 스와핑 오퍼레이션을 이용하는것은 현재 할당 된 메모리 요청을 추정하는데 필요하다. 

위 사항을 만족 하기 위해서 이들은 VSWAP라는 개념을 도입한다. 이것은 프로트 엔드디바이스와 백엔드 디바이스로 구성되어있다. 프론트 엔드 디바이스는 게스트 커널 내부에 존재하면 일치 하는 백엔드 드라이브와 통신을 하게 된다.

// 히스토 그램을 만들떄 생겨나는 overhead를 최소하하는 방법 

VM의 페이지 사용량이 늘어 나면 페이지 리스트의 크키가 커지면 커질수록 오버해가 된다 LRU 히스토그램을 구성하는 일이 그렇기 때문에overhead를 최소할 필요가 있다.

이들은 다음 그림과 같은 방법을 제안 한다. 

VMM은 3가지 부류로 각각의 VM의 page list를 유지 하게 된다 : hot, worm, cold

hot list는 가장 최근의 접근한 page를 보유란다. 오버헤드를 줄이기 위해서 이들은 hot list는 모니터링 하지 않는다. 

우리의 시스템은 동적으로 모니터링 오버 헤드와 LRU 히스토그램의 정확성 사이의 균형을 유지하기 위해 뜨거운 목록의 용량을 변경합니다. cold는 VM과 VMM에 의하여 제거된 페이지를 보유 한다. 각각의 목록은 페이지를 유지 하기 위한 제한된 용량을 가지고 있다. 

새로운 page는 ht list의 head 부분에 추가되고 접근한 페이지 또한 head부분으로 이동하게 된다.  hot list가 용량보다 만은 페이지가 추가 된다면. hot list의 꼬리 부분이 worm list의 머리 부분으로 이동하게 된다. VM은 VMM이 정한 사용가능한 메모리 한도를 넘은 사용을 하게되면 worm list에 꼬리 부분이 cold list의 머리 부분으로 이동하게된다. 유사하게 VM에서 버리는 페이지들고 콜드 페이지의 머리 부분으로 들어 가게 된다.