Abstract
Introduction
반 가상화를 통해 많은 OS 인스턴스를 고성능의 단일 물리적 시스템에서 동시실행가능
→ 물리적 리소스를 보다 효율적으로 사용가능
→ 개별 OS 인스턴스를 격리 할 수 있음
전체 OS와 어플리케이션 마이그레이션 하면,
프로세스 레벨 마이그레이션 접근방식이 문제 방지가능
1. 잔차 종속성 방지가능 - 가상화된 OS와 VMM간 인터페이스 협소로, 마이그레이션 된 프로세스를 대신하여 특정 시스템 호출 또는 메모리 엑세스까지 서비스할때면 기존 호스트 시스템을 사용가능, 네트워크 엑세스 필요
But, 가상시스템 마이그레이션을 사용하면 마이그레이션완료시 원래 호스트 해제
So, 원래 호스트 유지관리시 좋음
2) 전체 가상 시스템 수준에서 마이그레이션하면, 메모리 일관성, 효율적 전송
ex. 클라이언트 연결 필요없이 온라인 게임 서버나, 스트리밍 미디어 서버 마이그레이션 가능
3) 데이터 센터 또는 클러스터의 사용자와 운영자간에 문제 분리가능
로컬 마이그레이션과 관련된 문제 해결
1. 라이브 서비스를 호스팅하는 활성 so를 마이그레이션을 목표로하고있어 서비스를 완전히 사용할 수 었는 다운타임을 최소화
2. 총 마이그레이션 시간 고려 ( 두 시스템의 상태가 동기화 되어 신뢰성에 영향을 미칠 수 있음 )
3. Design
1) Migrating Memory
중요 포인트 : 다운타임, 마이그레이션 시간 최소화
문제점 1. 현재 실행중인 VM 인스턴스가 없어서 서비스 사용할 수 없는 기간. 이 기간에 VM으이 클라이언트에 서비스 중단으로 직접 표시
문제점 2. 마이그레이션이 시작되는 지점 과 원래 VM이 최종적으로 폐기될 수 있는 시점 사이의 기간. 유지보수나 업그레이드 등을 위해 소스호스트가 중단될 수 있음
이를 해결하기위해 이론적인 3가지 단계가 있음
1. Push phase
2. Stop-and-copy phase
3. Pull phase
대부분 1~2개만 적용함
예1) pure stop-and-copy : 원래 VM을 중지하고 모든 페이지를 대상으로 복사한 다음 새 VM을 시작하는 작업 포함
장 : 단순성
단: 다운타임과 마이그레이션 시간이 VM에 할당된 물리적 메모리의 양에 비례한다는 것을 의미 → 허용되지 않은 운영중단 발생가능
예2) pure demand-migration : 간단한 중지 및 복사 단게가 필수적인 커널 데이터 구조를 대상으로 전송
대상 VM이 시작되고 다른 페이지는 처음 사용 할때 네트워크로 전송
장: 다운타임 짧아짐
단; 총 마이그레이션 시간 훨씬 길어짐 So, 마이그레이션 후 성능이 저하되면, 전체적으로 문제가 발생할 수 있음
이 논문의 방법
pre-copy: 반복적인 Pull phase와 짧은 Stop-and-copy phase
1. 반복 : pre-copy가 round에서 발생, 라운드n일때, 전송될 페이지는 n-1에서 수정된 페이지 ( 모든 페이지는 라운드에서 전송). 모든 VM은 자주 업데이트 되서, pre-copying에 적합하지 않은 일부 페이지가 있는데, 그건 WWS 동작에 대한 분석을 기반으로 사전 복사 라운드 수를 제한함
활성 서비스에 미치는 영향도 중요함.
예를들어, 클러스터의 두 호스트간에 VM 메모리 이미지를 반복적으로 검색하고 전송하는 경우가 있음
이러면, 호스트 간에 사용 가능한 전체 대역폭을 쉽게 사용가능해서, 리소스 활성 서비스를 사용못할 수 있음.
성능 저하 현상은 모든 실시간 마이그레이션 계획중에 어느정도 발생.
→ 해결법 : 마이그레이션 프로세스에서 사용하는 네트워크 및 CPU 리소스를 제어.
활성 트레픽 또는 처리에 과도하게 간섭하지 않게 함
2) Local Resources
주요 과제 : 마이그레이션하려는 물리적 시스템과 연결된 리소스에 대해 수행할 작업
if, 로컬 디바이스로의 연결
문제1. 네트워크 리소스
- 마이그레이션된 os가 원래 호스트의 포워딩 매커니즘이나 아직 존재하지 않는 이동성이나 리디렉션 메커니즘에 의존하지 않고 모든 열린 네트워크 연결 유지를 원함
- So, 클러스터 환경에서 소스 및 대상 시스템의 너트워크 인터페이스가 일반적으로 스위치 LAN에 존재함.
- 네트워크에 대하 마이그레이션을 관리하기 위한 NAT 솔루션은 마이그레이션 된 호스트에서 IP가 새 위치로 이동했음을 알리는 요청되지 않은 ARP응답을 생성하는것
- 마이그레이션 된 호스트에서 요청하지 않은 ARP 응답을 생성하여 IP가 새 위치로 이동했음을 알립니다
- 피어가 재구성되서 새 물리적 주소로 패킷을 보낼 수 있고, 전송패킷 손실 매우적고, 간섭없이 열린 연결 계속 사용가능
- 일부 라우터는 IP 스푸핑을 방지하기 위해 브로드캐스트 ARP 응답을 수신하지 않도록 구성되 있어서 일부 작동하지 않을 수도
문제2. 로컬 스토리지 어떻게 처리할지
이건 다루지 않음
3) Design Overview
단계0 : 사전 마이그레이션, 물리적 호스트 A의 활성 VM으로 시작
단계1: 호스트 A에서 호스트 B로 OS를 마이그레이션 하기위한 요청 발행.
필요 리소스를 B에서 사용 가능? , VM 컨테이너 예약
단계2: 첫번째 반복에서 모든 페이지가 A → B로 전송. 이후는 이전 전송에서 더러워진 페이지만 복사
단계3: 실행중인 OS 인스턴스 일시중단, 네트워크 트레픽B로 리디렉션. 앞에서말했던 CPU상태와 일관성 없는 메모리 페이지가 전송됨. 이거 끝나면 VM복사본이 생기는데 실패하면 A사본에 있는걸 복사함
단계4:호스트 B는 A에 일관된 OS 이미지를 성공적으로 수신했음을 나타냄. 호스트A가 인정해주고, A는 원래 MV 폐기, 호스트B가 기본호스트가됨
단계5: B에서 마이그레이션 된 VM이 활성화됨. 마이그레이션이후 코드는 새 시스템에서 장치 드라이버를 연결하고 이동한 IP 주소를 알리기위해 실행됨
4 WritableWorking Sets
라이브OS를 마이그레이션할때 서비스 성능에 큰영향을 미치는 요소 : 가상 시스템의 메모리 이미지를 일관성 있게 전송하는 오버헤드
그래서, 운영체제가 실행되는 동안 메모리 이미지가 전송되는 사전복사 마이그레이션을 사용
-단점: 이후에 수정된 메모리 페이지를 전송하는데 낭비되는 오버헤드가 있어서 다시전송필요
사전복사 단계 중단 시점은?
4.1 Measuring WritableWorking Sets
Xen’s shadow page tables를 사용해서 모든페이지에서 더러워진 통계 추적
So, 가상 시스템에서 쓴 페이지 집합 언제든 확인 가능
x축은 시간, y축은 8초 간격내에 더러워진 메모리 페이지수 표시
쓰기 가능한 작업세트가 서로 다른 하위 벤치 마크 간에 크게 다른것을 알 수 있음
Gon은 마이그레이션에 적합한 후보, 아이딜.
Gap은 더뤄워 지는 비율이 높고, 마이그레이션할떄 문제일 수 있음
그래서, 운영체제 마이그레이션을 수행하면 시작되는 정확한 시점과, 워크로드에 따라 결과가 다를 수 있음
4.2 Estimating Migration Effectiveness
모든 시점의 대략적인 WWS 동작을 알고 있기 때문에, 최종 정지 및 복사 라운드에서 전송되는 데이터 전체 양을 추정해서 다운타임을 추정할 수 있다.
그래프 : 특정 네트워크 대역폭 제한에 해당하는 세개의 그래프
첫번째 행은 ( 한번의 사전복사 반복) : 단순 중지복사보다 더 나은 성능을 보임
회색: wws 히스토그램
다운타임이 4배감소, 리눅스 커널 컴피알이나 oltp벤치마크에서는 최소 16배 이상 줄어듬
대역폭이 클수록 더 많이 감소하는데, 이유는 모든 워크로드가 작지만 매우 자주 업데이트되는 핫 페이지 집합을 나타내기때문.
자주 더러워 지기 때문에, 최종 중지 및 복사 단계에서 전송되어야함
5 Implementation Issues
Xen virtual machine monitor로 호스트 시스템의 리소스를 각각 전용 OS 인스턴스로 실행하는 리소스 분리 가상시스템 집합으로 안전하게 나눔.
5.1 Managed Migration
- 관리마이그레이션: 관리VM에서 실행되는 마이그레이션 데몬에 의해 마이그레이션 외부에서 수행됨
대상 시스템에서 새 VM을 생성
네트워크를 통해 라이브 시스템 상태 전송을 조정하는 역할
실행중인 OS의 메모리 이미지를 전송할떄,
먼저, 제어 소프트웨어는 VM메모리 페이지에 대한 전체 검색을 수행하는 일련의 복사 수행.
이후 라운드에서는 이전 라운드 동안 더러워진 페이지로 복사
1st : 모든 메모리 페이지를 더티비트맵으로 표시
2nd VM의 더티 비트맵에서 적절한 비트 설정,
복사 라운드 시작할떄, 더티페이지는 다시 저송. 다음라운드를 위해 더티 비트맵 재설정
Nst 사전복사 단계가 유익하지 않다고 판단되면 마이그레이션에 적합한 상태로 자신을 일시중단
일관성 없는 메모리 페이지가 남아있는지 마지막으로 한번 검색, VM의 체크 포인트 CPu레지스터 상태와 함꼐 대상으로 전송. 이게 수신되면 VM상태 안전하게 폐기.
라운드 더티 비율이 임계치보다 츨떄 stop엔 copy시작
5.2 Self Migration
- 셀프마이그레이션: 대상시스템의 작은 s스텁만 있으면 마이그레이션 os 내에서 거의 완전히 구현
1. 마이그레이션 요청 수신, 빈VM 생성
지저분한 비트맵 추적 기능을 유지, 쓰기 오류가 발생할때 적절한 비트를 설정
더티 페이지는 다시 전송됨
다음라운드를 위해 비트맵 재설정
n번째라운드 더티 비율이 상한보다 크면 os는 모든 활동 비활서오하
모든 더니페이지를 새도우 버퍼에 복사
버퍼를 전송하고 새 페이지 업데이트를 무시
5.3 Dynamic Rate-Limiting
항상 필요한것은 아니지만, WWS의 핫페이지는 사전 복사 마이그레이션을 사용할 수 없어서 다운타임이 연장된 형태로 비용 지불필요
추가 네트워크 경합이 발생하도 대역폭 제한을 늘리면 다운타임을 줄일 수 있음.
SO, 각 사전 복사 라운드 동안 대역폭 제한을 동적으로 조종 관리자가 최소, 최대 제한 대역폭으로 페이지 전송
- 첫 사전복사 라운드는 최소 대역폭으로 페이지 전송
- 이후 라운드에서 이전 라운드에서 더러워진 페이지 수를 카운트해서, 더러워진 속도 계산
- 이걸 토대로 증분을 추가해서 결정
- 만약에 설정한 최대보다 크면 사전 복사 종료.
= 최종 중지 및 복사단계에서 최대허용으로 전송해서 다운타임 최소화
경험적으로 50Mbit/sec가 적절한 값
5.4 Rapid Page Dirtying
빨리 수정된 페이지가 특정 사전 복사 문제에서 전송하려고 할떄 다시 더러워질 가능성이 매우 높다는 것 관찰
주기적으로 현재 라운드의 더러운 비트맵을 'peek(훔쳐보다)',
스캔할떄 이전 라운드에서 더러워진 페이지만 전송
그리고, 오물은 물리적으로 뭉쳐지기도함. 페이지가 더럽혀지면 가까운 이웃이 곧 더럽혀지기도함.
그래서 한 페이지도 검색되지 않으면 아예 검색 안될 가능성이 커짐. 그래서 VM의 물리적 메모리 공간을 pseudo-random order.
5.5 Paravirtualized Optimizations
Stunning Rogue Processes.
사전복사는 더러워지는 속도보다, 더 빨리 메모리 페이지를 대상 호스에 복사할 수 있을때 적합
그러나, 문제가 발생하거나, 하나 이상의 불량 애플리케이션에 의해 길어지는 문제가 있을 수 있음.
이때, mange와 self 마이그레이션 모두 마이그레이션 시작될떄 OS 커널 내에서 모디터랑 스레드 강제적용해서 위험 완화
Freeing Page Cache Pages.
첫번쨰 전체 통과 반복에 걸리는 시간을 대폭 줄일 수 있음.
6 Evaluation
6.1 Test Setup
- Xeon 2GHz CPU 및 2GB 메모리
6.2 SimpleWeb Server
512kb 파일 하나를 100개의 동시 클라이언트 세트에 지속적으로 제공할떄 달성되는 처리량
웹 서버 가상시스템의 메모리 할당량은 800MB
추적시작하면, 870Mbit/sec의 일관된 처리량 달성 (27초까지)
속도가 100Mbit/se(12%CPU)로 제한되서 서버 처리량이 감소 (62초 지속)
이동안, 몇번의 반복을 걸쳐서 속도를 높히고 9.8초 뒤에 VM을 일시중단
마지막 중ㄱ지 및 복사단계에서는 나머지 페이지를 전송하고 165ms 중단후에 최대 속도로 다시 시작
이걸로, 짧은 다운 타임으로 마이그레이션 할 수 있음을 보여줌
정적 웹 서버의 예시 (SPECweb 99 벤치 마크)
가상 시스템의 메모리를 통해 첫번째 패스가 이루어져서 낮은 속도의 전송 시작
1라운드 : 54.1초, 676.8을 전송.
2라운드 더 낮은 레이트 126.7 전송
3라운드 낮게 39
그뒤에는 VM을 마지막으로 일시중단 하기전에 연속적으로 짧은 반복을 통해 페이지 오염률을 추적하는 방법 보여줌
SPEC 웹 클라이언트가 경험하는 총 210ms의 다운타임은 350개의 호환 클라이언트를 유지하기에 충분히 짧습니다.
이 결과, 로드가 많은 서버(최대 용량의 90%)가 별도의 물리적 호스트로 마이그레이션되며 총 마이그레이션 시간은 71초입니다. 또한 마이그레이션은 SPEC 웹 워크로드에서 요구하는 서비스 품질을 방해하지 않습니다. 이는 마이그레이션이 까다로운 라이브 서비스 관리자를 위한 도구로서 적용되는 가능성을 보여줍니다.
멀티플레이어 온라인 게임 서버
Queck 3 서버를 실행하는 64MB 메모리를 가진 가상 시스템, 6명의 플레이어가 게임에 참가하여 공유 영역 내에서 플레이하기 시작했으며, 이때 다른 머신으로 마이그레이션하기 시작
- 일반적과 유사한 진행을 보여주지만, 전송되는 데이터 양은 매우 적음
- 진행될 수록 속도는 증가하지만, 최종 중지 및 복사단계에서는 전체 대역폭이 사용되지 않을 정도록 적은 데이터 전송 148kb.
- 그림 10은, 두번 마이그레이션하고 클라이언트가 수신한 패킷의 도착간 시간을 측정하는 추가실험
응답 시간 50ms의 일시적인 증가, 하지만 사람들은 인지하지 못햇음
6.5 A DiabolicalWorkload: MMuncher
가상 시스템이 네트워크를 통해 전송될 수 있는 것보다 더 빠르게 메모리에 쓰는 경우
- 첫번쨰반복에서 메모리 절반이 전송
- 나머지는 테스트 프로그램으로 바로 더러워진것으로 표시됨
- 더러움 발생속도에 비례해서 자체 스케일링해서 적응하려고함
- 불충분함을 증명
- 3번쨰 라운드에서 500까지 확장됨
- 마지막 라운드도 실패하면, 가상 시스템이 일시중단되고 나머지 더티페이지가 복사되서 다운타임 3.5초 발생.
- 근데 이정도는 드뭄
7 FutureWork
7.1 Cluster Management
주요 과제는 가상 머신의 배치 및 이동에 대해 정보에 입각한 결정을 내릴 수 있는 클러스터 제어 소프트웨어를 개발하는 것입니다
이러한 특별한 경우에는 스케줄링된 유지 보수를 위해 중단해야 하는 노드에서 VM을 '탈퇴'하는 것입니다.
7.2 Wide Area Network Redirection