Memory Balloning?
VM 가상화 환경에서 게스트에게 호스트의 메모리 부족 상황을 알 수 있도록 하는 메모리 오버커밋의 핵심적인 메모리 회수(Reclaim) 기법. 호스트가 다운되는 것이 동작중인 게스트 VM에게도 치명적인 상황이기 때문에 호스트의 메모리가 부족해지면, 게스트로부터 메모리를 회수, 확보하고, 다시 여유가 생기면 게스트에게 메모리를 돌려준다.
Resource overcommitment?
한 호스트의 어떤 종류의 리소스에 관하여 게스트에 설정한 리소스의 총합이 호스트의 물리 리소스 양을 초과한 상황을 해당 리소스가 오버커밋 되었다 라고 함.
8GB RAM을 가진 호스트에 4GB로 설정한 게스트 VM을 3개 실행했을 때. -> Memory overcommitment
4코어 CPU를 가진 호스트에 4코어 게스트 VM 2개 실행 -> CPU overcommitment
모든 게스트VM이 설정한 리소스를 항상 100% 사용하지 않기 때문에, 호스트 자원을 효율적으로 사용하기 위하여 오버커밋을 사용한다.
오버커밋의 정도는 VM의 용도, 안정성, 실행되는 프로세스의 성격 등을 고려하여 조절하는 것이 중요하다.
동작 방식
게스트 VM 내부에 드라이버 형태로 Balloon driver가 설치되어 실행된다. Fake process처럼 행동하면서 게스트 OS로부터 메모리를 할당받거나 해제한다.
- 호스트의 메모리 관리 모듈로부터 Balloon 크기와 Inflating 혹은 Deflating 명령을 받는다.
- 호스트의 메모리가 부족해지면, 게스트로부터 메모리를 회수하기 위해 각 게스트 Balloon Driver를 Inflating한다.
게스트VM내의 Balloon driver는 게스트 OS로부터 전달받은 크기에 해당하는 메모리 페이지를 할당받는다. 이 때, 게스트 물리메모리에 할당받은 페이지를 Pinning하여 게스트의 다른 프로세스가 해당 메모리를 할당받지 못하도록 한다. 그리고 할당받은 페이지에 대한 정보를 하이퍼 바이저에게 전달하여 호스트 물리 메모리에 매핑되어있던 페이지를 호스트가 사용할 수 있도록 한다. 결과적으로 게스트VM은 자신의 Balloon driver가 차지하고 있는 메모리를 사용하지 못하는 상태가 되고, 호스트는 그 만큼 자신의 메모리로 사용할 수 있도록 되는 것이다. - Inflating후에 호스트 메모리가 여유로운 상태가 되었을때 각 게스트의 Balloon driver를 Deflating한다.
위와 반대로 현재 Balloon 크기를 전달받은 크기에 맞도록, 메모리를 해제한다. Balloon driver가 Pinning하고 있던 프레임의 페이지가 해제되면서 다른 프로세스들이 해당 프레임을 할당받을 수 있게 된다.
정책
Balloon driver를 통제하는 주체는 호스트의 메모리 관리 주체인데, 레드햇의 RHEV, oVirt에서는 Memory overcommitment manager daemon(momd)이고 VMware의 vSphere에서는 (아마도)ESXi 하이퍼바이저이다. 메모리 관리 주체는 주기적으로 게스트마다 메모리 사용 통계를 수집하는데, 호스트의 메모리 부족상황이 발생할 때 이 통계를 참고하여 게스트의 메모리 회수율을 결정한다.
- 예를 들어 6GB 물리 메모리를 가진 호스트에 게스트 A, B가 있고 모두 메모리를 4GB로 설정. 그리고 게스트 A는 최근 평균적으로 4GB 메모리를 전부 잘 사용하고 있었고, 게스트 B는 4GB중 2GB만을 평균적으로 사용했다고 하자. 전체 6GB가 사용되고 있으므로 호스트 입장에서는 메모리 부족 상황이다. 이 때 호스트 메모리 관리 주체는 게스트A보다 게스트B에 대해서 더 많은 메모리를 회수한다.
단순한 예시일 뿐이고 이러한 정책적인 부분은 플랫폼 별로 매우 다르다. 하지만 적당한 부족상황에서는 이러한 상황을 고려하고, 극한의 상황에서는 고려해주지 않는 부분은 두 플랫폼에서 동일했다. 이러한 회수는 호스트 입장에서의 메모리 부족 기준(Pressure threshold)을 벗어날 때까지 일어나고, 여유가 생기면 다시 게스트에게 메모리를 반환한다.
이외의 기법
Page sharing
호스트 물리 메모리에서 같은 내용을 갖는 페이지들을 한 프레임으로 공유함. 주기적으로 해시테이블을 이용하여 페이지들을 스캐닝하고, 공유한다. 공유된 페이지는 Copy on write마크가 남겨져서 쓰기 요청 시에는 복사가 되어 사용된다. OS 이미지 같은 부분은 상당부분 공유할 수 있기 때문에 효율적으로 사용할 수 있다. 하지만 공유한다는 특성 상 보안이슈가 있는 것 같다. 그래서 VMware에서는 공유 스코프가 VM인 것이 기본이고(Intra VM), 호스트인 것이 옵션이다(Inter VM). 물론 후자가 페이지를 더 많이 공유한다.
KVM에서는 Kernel Same-page Merging, VMware에서는 Transparent Page Sharing라는 이름으로 제공된다(구조는 약간 다르다).
Hypervisor swapping(Host swapping)
호스트 기준의 Swap과 같은 의미로 알고 있다(게스트 기준 Swap과는 다름). 메모리 오버커밋 환경에서 Ballooning과 함께 필수라고 생각되는 기법중에 하나라고 생각한다(Ballooning의 주기가 매우 짧다면 사용하지 않아도 될 것 같긴하다).
