Improving the efficiency of deploying virtual machines in a cloud environment

Improving the efficiency of deploying virtual machines in a cloud environment

- Risto Laurikainen, Jarno Laitinen, Pekka Lehtovuori CSC – IT Center for Science Ltd, Jukka K. Nurminen Aalto University

 

본 논문은 Opennebula에서 가상 머신 이미지를 배포하는 방식에 있어서, Bittorrent 방식과, 멀티캐스트 방식 2가지(UDPcast, UFTP)를 가지고 전송하는 이미지의 크기(Small / Big)에 대해 배포 시간을 측정, 비교하며, Front-end에서 발생한 트래픽량과 Bittorrent 방식에 있어, 다양한 Piece Size에 따른 비교에 대한 연구를 하였다.

 

Opennebula Transfer Manager

* Transfer Manager에 대해 논문에서 다루고 있긴 하지만, 정확한 동작방식에 대해서 설명하고 있지 않아 Opennebula (www.opennebula.org)의 도큐먼트를 참고 하였다.

 

Opennebula는 하나의 Front-End와 다수개의 Cluster Node로 구성된 구조로 이루어진다. Opennebula는 Front-End에 ONED라는 이름으로 관리 데몬으로써 운영하며, ONED에서 운영중인 드라이버는 SSH로 다수의 Cluster NODE를 관리한다. Cluster node는 실제 가상 머신이 운영되는 서버로 하이퍼바이저만 설치되며, Opennebula는 설치 하지 않고 운영한다.

Opennebula Transfer Manager는 Cluster Node에 가상머신 이미지를 전송하는 역할이며, 현재 Transfer Manager Model은 이미지 파일을 물리적 호스트로 복사하는 Clone Script를 실행한다. 다시 말하자면, 현재 전송 메커니즘은 다중 독립적 유니캐스트 전송이라 볼 수 있다.

이에 본 논문에서는 단일 전송 섹션으로 다중 물리적 호스트에게 이미지를 전달하는 멀티캐스트 방식과 Bittorrent 방식을 테스트한다.

Transfer Manger - Bittorrent

 

Bittorrent Transfer Manager을 구현하기 위해 RTorrent를 사용하며, Tracker는 OpenTracker을 사용한다. RTorrent는 Image Repository와 HOST 양쪽 다 설치된다. Image Repository는 초기 Seeder의 역할을 하며, Torrent 파일은 Image Repository에서 생성되며, 저장된다.

1) Transfer Manager가 가상머신에 이미지를 Clone시킬 때, 먼저 이미지가 Clone하려는 HOST에 이미지가 있는지를 확인한다.

-> 있으면, 이미지를 전송하는 대신에 그 이미지의 Local Copy를 만든다. (이 경우는 이전 이미지 배포에서 이미지를 전달 받은 경우라 볼 수 있다.)

-> 없다면, Transfer Manager는 HOST에서 구동하는 RTorrent(Client)에게 토렌트 파일을 전송한다.

2) HOST에서 구동하는RTorrent (Client)는 토렌트 다운로드가 끝나면, 클라이언트는 Transfer Manager Script (Image Clone)를 실행한다.

3) Transfer Manager는 호스트에 이미지를 VM Directory 아래의 Subdirectory에 Clone시킨다. 다운이 완료되면 Image를 구동하기 위한 Space로 Image를 Copy시킨다.

4) 이미지 파일을 받은 호스트는 Seeder가 되어, 다른 호스트에게 이미지를 Clone시켜준다.

Transfer Manger - UDPcast

 

UDPcast는 멀티캐스트 File Transfer tool이며, UDP Sender(Server 프로세스), UDP Client(Receiver 프로세스) 가 파일을 주고 받는 개체가 된다. UDP Client는 멀티캐스트의 그룹원이 되고 UDP Sender는 멀티캐스트의 그룹에게 파일을 한번 전송한다. 파일의 전송은 슬라이스라 불리는 패킷의 다중 세트로 나누어져서 전송된다. 전송 속도는 Sender와 Clinet간에 자동적으로 조절 된다.

신뢰성은 슬라이스내에 잃어버린 패킷에 대한 NAK를 기반으로 실시한다.

슬라이스를 보낸 후, UDP sender는 UDP Client가 보낸 NAK를 바탕으로 슬라이스 내의 잃어버린 패킷을 재전송한다.

Transfer Manger – UFTP

 

UFTP는 또 다른 멀티캐스트의 파일 전송 Tool이다. UDPcast와 비교해서 주요 차이점은 신뢰할 수 있는 멀티캐스트 프로토콜이란 점이다. 파일을 슬라이스로 분리하여 전송하는 대신에, 서버는 처음부터 어떠한 재전송 없이 시종일관 연속적으로 파일을 보낸다.

 

신뢰성은 부정 응답(NAK)를 통해 이루어지며, 수신자가 수신한 데이터가 손실 데이터라는 것을 알게되면 서버로 NAK를 보낸다. 서버는 이러한 NAK를 모든 수신자에게 수집하여, 첫번째 라운드가 끝날 때, NAK를 보낸 수신자에게 모든 패킷의 유니온을 재 전송한다.

 

이 과정은 모든 수신 호스트가 모든 패킷을 가지고 있을 때까지 반복한다.

 

UFTP의 Server 프로세스는 Front-End에 구동하고, 가상 머신 호스트의 Receiver 프로세스에게 고정적인 속도로 전송한다. Server 프로세스에 대한 입력은 호스트 목록을 가진 파일이며, 이 파일은 멀티캐스트의 그룹으로 규정한다.

 

Receiver 프로세스는 HOST에서 항상 실행되어 있으며, 파일은 VM Directory에서 전송 받고, 전송이 완료 되면 VM 이미지를 구동하기 위한 공간으로 파일을 복사 시킨다.

 

 

 

Test Environment

Transfer Manager Test는 CSC IT센터의 클라우드 시스템에서 실시 하였으며, 모든 호스트는 똑 같은 네트워크에 연결되며 2개의 48Port 스위치를 사용한다. Front-end는 10Gbe Link를 가진 스위치중 하나와 연결된다. 또한 72개의 가상 머신 호스트를 사용하며, 여기서 절반은 Front-end와 같은 스위치로 연결되고, 나머지 절반은 다른 스위치에 연결된다. 호스트와 스위치 연결 사이는 1Gbe 연결이며, 스위치는 서로 연결된다.

 

Result

 

Opennebula의 Defualt Transfer Manager는 이미지 데이터를 복사하기 위해 SCP를 이용한다. 즉, 물리적으로 분리된 2 기계간의 디렉토리 사이에서 암호화된 유니캐스트 전송을 실시한다. CSC에 이용된 방식은 파일을 복사하기 위해 SCP대신 NFS을 사용한다. 그리하여 이러한 옵션에 대해 비교하기 위해 NFS Transfer Manager를 테스트하는데 Front-end와 스토리지 컨트롤러 둘 다 이용하여 테스트하였다. 하지만 스토리지 컨트롤러는 다른 Transfer Manager를 테스트 할 때는 사용하지 않았다.

1) Deployment Speed : large Image

< 그림 1 : 9.77 단 하나의 가상머신 평균 배포시간과 동시배포시에 대한 전체 배포시간, 9.77GB의 이미지를 사용하였고, NFS NetAPP의 결과는 스토리지 컨트롤러에 의해 송출된 스토리지의 결과이고, NFS Front-End의 결과는 Opennebula Front-end에서 locally로 이용 가능한 스토리지에 대한 결과 이다. >

 

NFS Front-End의 경우 현저하게 성능이 낮다. Front-end위의 NFS 셋팅은 효율적이지도 않을 뿐만 아니라, NFS는 병렬 연결에 적합하기 때문이다. NFS NetAPP의 경우 성능은 비교적 잘 나왔다. 유니캐스트 전송 중 가장 빠른 방법이기 때문이다.

두 가지 멀티캐스트 중에서 UDPcast가 더 좋은 성능을 보인다. UFTP를 이용할 때 발생되는 패킷손실은 트래픽이 증가하게 되고 배포 속도에 영향을 미치기 때문이다.

유니캐스트 방식인 NFS, SCP는 적은 배포수에 있어서는 성능이 높고, 배포 수가 많아지면 (UFTP=40, UDPcast, Bittorrent = 20) 와 같은 Transfer Manager가 더 성능이 좋다.

2) Deployment Speed : small Image

< 그림 2 : 899MB의 작은 이미지의 Test 결과 >

작은 이미지로 Test한 결과를 보면 큰 이미지의 결과와 크게 다르다는 것을 한눈에 알 수 있다. 가장 빠른 옵션은 NetAPP을 통한 NFS이며, UDPcast의 경우 가장 느린 옵션이다. 이를 볼 때, 네트워크 사용에 대한 효율은 더 이상 배포시간을 결정하는 것의 우선순위를 차지하는 요인이 아니라 할 수 있다. Transfer 프로세스에 대한 오버헤드가 더 중요하다고 할 수 있다. 예를 들면, 멀티캐스트 전송 세션을 Bootstrapping하는 것은 유니캐스트 세션을 Bootstrapping 하는 것보다 시간이 더 걸린다. 멀티캐스트의 경우 서버는 수많은 호스트를 negotiate해야 하고 기다려야 한다. 반면 개별적 유니캐스트 전송의 경우, 바로 시작할 수 있다. Transfer Manager가 멀티 캐스트 그룹을 형성하는 것이 필요한 UDPcast와 UFTP는 상당히 시간이 많이 걸릴 수 밖에 없다. 예를 들면 UDPcast Transfer Manager가 준비되는 시간은 60초이고, Openstack Default Transfer Manager(SCP)의 경우 30초가 소요 된다.

Bittorrent역시 처음에 기다려야 하는 제약사항을 가지고 있지 않더라도, Small 이미지의 테스트의 NFS보다 느리다. 왜냐하면, 전송 뒤에 추가적인 복사 단계를 하여야 하기 때문이다. 하지만 Copy는 Copy-on-Write(COW)를 지원한 파일 시스템 또는 이미지 포맷을 이용하여 속도를 줄일 수 있는 방법이 있다.

3) Front-End Traffic Measurements

<그림 3 : 배포하는 Virtual Machine수 증가에 따른 Front-End가 전송한 전체 데이터량 / SCP는 큰 차이 때문에 따로 그래프를 두었다, 테스트한 이미지는9.77GB >

당연하게도 멀티캐스트 기반 UDPcast, UFTP Transfer Manager는 최소량의 트래픽을 Front-End에서 발생한다. 그중 UDPcast는 가장 효율적이다. UFTP의 오버헤드는 꾸준히 증가하고 UDPcast는 노드 수의 상관 없이 대략 7%정도이다. 그 둘의 차이는 전송 속도 제한 메커니즘으로 인해 발생한다. UFTP는 항상 특정 전송 속도에 맞춰 설정될 것이고 UDP cast는 최적의 전송 속도를 달성하기 위해 전송 속도를 dynamic하게 변경할 수 있다.

Bittrorrent를 이용할 때 데이터량은 멀티캐스트를 이용했을 때 보다 더 크다. Bittorrent는 Front-End에 의해 이동된 데이터량은 다른 호스트들에서 배포되는 데이터량보다 작다. 또한 더 많은 데이터가 Front-End로 이동되거 있을지라도, 멀티캐스트 방식 보다 더 빠른 옵션이 있기 때문에 멀티캐스트가 우위에 있다라고 비교하기는 어렵다.

 

 

5) Bittorrent Piece size

< 그림 4 : Piece Size 크기에 따른 이미지 배포 시간의 평균과 합, 각각 조각마다 20번을 테스트함, 이미지는 9.77GB>

다양한 Bittorrent Piece 크기를 60개의 가상머신에 이미지를 배포하는데 배포시간과, 전체 배포시간을 측정하였다. 테스트에 사용된 이미지는 9.77GB로 하였으며, 20번 반복하였다. 평균 배포시간을 고려해봤을 때 256KB가 가장 최적의 Piece 크기라 할 수 있다. 하지만 큰 차이는 아니다. 예를 들면 256KB와 8MB 사이에 배포시간의 차이는 5%에 불구하다. 배포시간이 현저하게 느린 경우는 Piece 크기가 매우 클 때이다.

재미있는 부분은 8MB는 전체 배포시간이 빠르다는 점인데. 본문에서 이점에 대해

"We do not know the reason for this" 라고 말하고 있다.

 

Conclusion

이 논문에서는 Opennebula 에서의 3 Transfer Manager를 구현하였고, 평가하였다. 하나는 Bittorrent, 나머지 2개는 멀티캐스트를 기반으로 한다. 구현한 Transfer Manager는 Opennebula에서 제공하는 Defualt Transfer Manager보다 더 좋은 성능을 제공한다. 최적의 Transfer Manager는 이동하려는 이미지 데이터의 양에 의존하며, 이것은 호스트의 수와 이미지의 크기에 따라 결정된다. 유니캐스트가 가장 빠른 옵션이지만, Bittorrent와 UDPcast가 더 많은 배포에 있어 더 빠르다.