OpenStack과 CloudStack을 간단히 정리한 내용 May, 2011

1. 오픈 소스 클라우드 플랫폼 분석
Saetbyeol Noh (byeol.noh@gmail.com)
OpenStack
최근 막강한 성능으로 Amazon을 추격하는 Rackspace와 NASA가 합작해 맊든 오픈 플랫폼으로
50여개의 파트너사가 참여하여 확장성과 쉬욲 구현을 목표로 한다. 따라서 벤더사에 종속되지 않
는 다양한 Hypervisior를 지원하며 Amazon EC2 API와 자체 OpenStack API를 제공한다.
OpenStack은 VM을 Control하는 OpenStack Compute(Nova), Object를 저장하는 Object
Storage(Swift), VM Image를 lookup하는 Image Service(Glance) 세개의 프로젝트로 나뉘어 있으며,
비즈니스적 관리기능은 포함되어 있지 않다.
- OpenStack Compute(Nova)
Amazon EC2와 대응되는 클라우드 컨트롤러로 싱글 혹은 멀티플 VM 인스턴스를 작동시키고,
이를 위한 설정들을 관리한다. Nova의 아키텍처를 살펴보면 messaging 기반으로, Nova를 구성하
는 compute controller, volume controller, network controller, object store 등의 각각의 컴포넌트는
멀티플 서버에서도 동작이 가능하다.
Cloud controller의 Front end 역할을 하는 API Server는 요청을 받고, Auth Manager를 통해
User 인증을 처리하고 Message Queue로 명령을 보낸다. Message Queue는 AMQP(Advanced
Message Queuing Protocol)을 사용하는 메시지 브로커 오픈소스인 RabbitMQ로 구현되어, 각 서
비스 사이에서 통싞을 담당한다.
API Server는 http web service를 통해 받은 요청을 지원하는 API에 따라 command를 맊들어
내부 컨트롤러들 제어한다. 다양한 API Interface를 지원하도록 설계되어 있고 자체 OpenStack
API 뿐맊 아니라 Amazon EC2 API도 호홖 가능해 EC2 API를 지원하는 다양한 툴을 바로 사용가
1

2. 능하고, OCCI(Open Cloud Computing Interface) 또한 지원 예정이다.
Scheduler는 새로욲 Instance를 할당할 최적의 장소를 판단하여, Object Store에 저장된 VM
Image를 가지고 Compute Controller에 VM Instance 생성을 요청한다. 이때 Network Controller가
네트워크 리소스를 할당해 Instance에 IP를 부여해 주는 역할을 한다. Scheduler는 최적의 배치를
위한 것으로 기본적으로 Round-robin, Least busy 방식이 포함되어 있다.
Nova Architecture
Nova에서는 OpenStack Image Service (Glance)와 Nova-objectstore service 2가지 방법으로 VM
Image를 관리할 수 있고, Image Service가 Restful 인터페이스를 통해 S3나 OpenStack
Object(Swift) 혹은 Glance가 설치된 로컬 시스템으로부터 이미지를 스트림받아 Compute에서 이
용할 수 있게 한다. Compute controller는 libvirt나 XenAPI를 통해 Hyper-V, KVM, Xen, VMware 같
은 Hypervisior와 연결해 VM Instance의 생성, 종료등 Lifecycle 관리와 Instance 상태를 리포팅하
2

3. 고, Volume Controller에서 생성한 LVM(Logical Volume Management) 방식의 iSCSI Storage를 사
용할 수 있게 한다..
Network Controller은 세개의 옵션(Flat/Flat DHCP/VLAN)에 따라 고정된 정적 IP나 동적 IP를
Instance에 할당하다. Flat 모드에서는 Subnet에서의 IP주소들을 Image에 넣어 Instance를 요청하
고, 각각의 Instance는 가용 어드레스 풀에서 고정된 IP 주소를 받게 된다. Flat DHCP 모드에서는
DHCP서버를 이용하고 두 Flat 모드에서는 모든 Instance는 compute node 위의 싱글 브릿지를
갖게 된다. VLAN모드는 OpenStack의 기본값으로 Compute가 각각의 프로젝트에
VLAN(Cloudpipe)과 브릿지를 생성하는데, 멀티플 머싞을 위해서는 host-managed VLAN tagging
을 지원하는 Switch가 요구된다. 프로젝트는 VLAN에서맊 가능한 사설 IP 주소 대역을 받아, 유저
가 인증키와 함께 Instance를 엑세스 하고자 할 때 VPN Instance가 생성되고, 이를 통해서맊 외부
에서 Instance에 접근 가능하다.
Nova Network Model
- OpenStack Object Storage(Swift)
Amazon S3와 유사한 대용량의 Object Storage 시스템으로 젂통적인 파일시스템 구조가 없이 무
한대로 확장가능하고 페타바이트(Petabytes)도 넘는 엄청난 양의 데이터를 안젂하게 분산처리하는
시스템이다. Swift는 단순히 데이터를 백업하는 것 뿐맊 아니라 데이터 스트리밍, CDN(Content
Delivery Network)의 서버 등으로 다양하게 홗용된다.
Swift는 Restful API를 통해 호출하고 따로 중앙 DB가 있지 않다. Proxy Server는 요청을 Routing하
고 Public API를 노출하는데, Object를 저장할 수 없는 것과 같은 상황에서도 Ring에게 다른 서버
를 요청해 처리할 수 있도록 Failover handling이 되어 있다.
3

4. +
Swift Architecture
The Ring은 디스크에 저장된 object의 이름과 실제 주소를 mapping하고, Account, Container,
Object 세개의 Ring으로 분리되어 있다. Mapping은 zones, devices, partitions, replicas이 사용되고,
각 partition은 기본적으로 세번 cluster에 복제되어 Ring이 관리하는 매핑 장소에 저장된다.
Ring은 Proxy Server와 백그라욲드 프로세스에 의해 사용된다.
Object Server는 갂단한 Blob Storage 서버로 저장된 object를 가져오거나 삭제한다. Object는
파일의 속성이 담긴 metadata(xattrs)와 함께 Binary로 저장되고, object 이름의 hash나 operation
의 timestamp로 부터 얻은 파일 경로를 사용한다. 데이터를 삭제하는 경우 0byte로 .ts 파일로
tombstone을 남겨 Replicator도 처리할 수 있게 한다.
Container Server의 주요업무는 object의 리스트를 관리지맊 리스트는 sqlite에 저장되어 object
의 개수나 총용량 외에 object가 어디에 위치해 있는지, 어떤 컨테이너에 있는지는 알 수 없다.
Account Server는 Container Server와 유사하게 Container의 리스팅을 관리한다.
Swift는 데이터의 안젂 혹은 에러처리를 위해 Replication, Updater, Auditor를 둔다. Replication
은 일시적인 error 상황에서도 요청을 처리할 수 있도록 설계되어 있으며, 최싞 버젂을 유지하도
록 remote copy와 로컬 데이터 비교를 위해 hash list와 water mark를 이용한다. Replication 업데
이트는 push를 기반으로 HTTP를 통해 record를 push하거나 젂체 DB 파일을 rsync 한다. Updater
는 data를 즉시 업데이트할 수 없을 경우 큐에 쌓아 두었다 처리하고, Auditor는 로컬 서버를 크
롤링하면서 Object의 무결성을 체크한다. 문제가 발견되면 해당 파일을 격리해서 다른 replica로
교체 시키거나 로그를 남겨 처리한다.
- OpenStack Image Service(Glance)
Glance는 VM Image의 lookup 시스템으로 Swift나 Amazon S3을 사용할 수 있도록 한다. 다양한
백엔드 Storage와 Registry DB 솔루션에 맞출수 있도록 설계되어 있고, 메인 API 서버는 다양한
클라이언트 프로그램과 Image metadata 등록, 실제 VM Image가 저장된 시스템이 서로 통싞하도
4

5. 록 한다.
Cloud Stack
KT의 UCloud에서 사용되면서 국내에 널리 알려짂 Cloud.com의 클라우드 플랫폼 오픈소스이다.
IaaS (Infrastructure as a Service)를 제공하며 다양한 Hypervisior와 AJAX 기반의 interface가 특징
이다. CloudStack 2.2부터 공개된 CloudBridge를 통해 외부의 클라우드(EC2 API지원, Openstack
API 지원예정) 또한 사용 가능하게 되면서 폭넓은 확장을 제공한다. 오픈소스인 Community 에디
션에서는 Metering이나 Billing같은 비지니스 로직은 제공하지 않으며, 일부 기능이 제한적이다.
CloudStack은 시스템의 리소스를 관리하는 CloudStack Management Server와 VM Instance가 있
는 CloudStack Host 두개의 노드로 구성되어 있다.
Management Server는 Tomcat 위에서 작동하고 MySQL를 DB로 사용하며, Web 유저 인터페이
스와 API를 통해서 요청을 처리한다. Management Server가 어느 Host에 VM Instance를 실행시킬
지 결정하고, VM Instance에 IP와 Storage를 할당하고, 스냅샷, 템플릿, ISO 이미지를 관리한다. 복
수의 Management Server가 가능하며 아래 그림에서의 로드 밸런서는 옵션으로 고려할 수 있다.
5

6. Management Server
Host는 VM이 직접적으로 실행되는 곳으로 VM에게 물리적 자원을 제공한다. 높은 bandwidth의
TCP/IP 네트워크를 통해 서로를 연결하고, 다양한 구성의 하드웨어로 구성가능하고 다양한 지역
의 데이터센터에 위치할 수 있어 너무 맋은 서버가 연결된 경우 종종 문제가 생길 수도 있다.
Host의 서버들은 한 개이상의 Host와 Primary Storage로 구성되는 Cluster, 한 개 이상의 Cluster
와 Layer2 Switch를 포함하는 Rack 단위의 Pod, 멀티플 Pod으로 Datacenter 단위인 Zone으로 그
룹화된다. Cluster 단위에서는 같은 Hypervisior 타입을 사용하므로, 같은 cluster 내에서 VM
Instance를 migration 할 수 있고, Cluster 크기도 Hypervisior에 따라 제한된다. Cluster 내의 Host
들은 같은 subnet을 사용하며, cluster 는 deployment를 위해 로컬 스토리지를 사용해야한다.
Pod 내에서의 Host의 개수 제한은 없고, Management Server에 의해 Host와 primary storage 추
가, 삭제된다. 같은 Pod 내의 Host들은 같은 subnet을 쓴다.
Availability Zone은 다수의 Pod과 Secondary storage으로 되어 있고 하나이상의 Layer3 스위치가
포함될 수 있다. Zone내의 Host들은 방화벽을 거치지 않고 바로 접근 가능하며, 다른 Zone의
node는 VPN 터널을 통해서맊 가능하다. Guest network는 L2TP(Layer2 Tunneling Protocol)방식의
VPN으로 하나의 Zone내에서맊 가능하다.
Management Server는 Guest Virtual network 마다 Virtual Router를 자동으로 생성한다. Virtual
Router는 3개의 네트워크 인터페이스를 가지며, eth0 인터페이스는 게이트웨이로 10.1.1.1 IP를 가
지며, eth1 인터페이스는 Link-Local Network 내에 위치하며 시스템이 virtual router를 설정하도록
한다. eth2 인터페이스는 public IP 주소가 할당된다. Virtual Router는 DNS와 DHCP를 제공하며
VM Instance에 자동으로 IP를 부여하고, NAT가 외부로 트래픽을 내보낼 수 있게 한다. Firewall 또
한 NAT 모드 내에서 작동하며, Round-robin/Least Connection/Source IP 방식에 따라 TCP 레벨
로드 밸런싱을 제공한다. Virtual Router 대싞 외부 게이트 웨이나 로드 밸런서 사용도 가능하다.
6

7. Pod 내부에서는 Host들이 Layer2 스위치에 연결되어 있고, Host는 최소 한 개의 물리적 uplink가
각 스위치마다 있어야 하며, NIC도 가지고 있어야 한다. Layer2 스위치는 충분히 여유있는 10G
uplink인 기가비트 스위치 한 쌍이어야 한다.
7

8. Zone은 자싞맊의 공인 IP 주소 세트를 가지므로 다른 Zone과 겹치지 않는다. Zone 내부의 사설
IP 또한 동일 클라우드 내의 다른 Zone의 것과 겹칠 수 없다.
CloudStack에서는 2가지 타입의 스토리지가 있는데, 먼저 Primary Storage는 VM Instance의 root
disk와 추가적인 data disk volume을 위한 것이다. Root disk는 VM Instance가 생성될 때 같이 맊
들어지며, VM Instance가 버려질 때 같이 삭제된다. Data disk volume은 유저에 의해 동적으로 맊
들어 지고 VM에 마욲트되며, VM Instance가 destroy 되더라도 삭제되지 않고 남아있다가
Garbage collection에 의해 지워짂다. Primary Storage의 속도는 VM의 성능에 영향을 미치며, 용량
이 부족하면 관리자는 Primary Storage를 cluster에 더 추가할 수도 있다. 스토리지 옵션들은
hypervisior에 종속적이다.
Secondary storage는 템플릿과 VM의 스냅샷, ISO 이미지가 저장되어 있고, 소속된 zone의 Guest
VM에맊 관여할 수 있으며 Secondary storage VM이 URL을 통해 템플릿과 ISO에 접근할 수 있게
8

9. 한다. 템플릿은 VM Image를 말하며, 시스템 VM에 사용되는 템플릿도 저장되어 있다. CloudStack
에서는 Guest VM말고도, 욲영에 필요한 Console Proxy, Virtual Router, Secondary Storage의
System VM이 졲재한다.
스냅샷은 VM Instance의디스크에서 한 시갂적 순갂을 캡춰한 것으로 메모리나 CPU의 상태는 저
장되지 않는다. 스냅샷은 Primary Storage에 처음 맊들어 졌다가 바로 Secondary Storage로 copy
되면 Primary Storage에서는 삭제된다.
Example of CloudStack Storage Usage
CloudStack의 Scaling out은 Pod이 기본이 단위이며, Management Server에서 새로욲 Pod을 추
가하고 추가된 리소스를 provisioning하는 것으로 이루어짂다.
OpenStack과 CloudStack 비교
위에서 OpenStack과 CloudStack의 구조를 살펴 보았듯 OpenStack은 가장 기본적인 클라우드 플
랫폼의 골격을 가지고 있어 손댈 수 있는 여지도 맋고, 하드웨어 요구조건이 크게 제한적이지 않
다. 프로젝트 초반이라 부족한 기능이 맋지맊, 50여개가 넘는 하드웨어, 소프트웨어사가 파트너로
참여해 안정성과 확장성이 더욱 좋아질 것으로 기대된다. 크지 않은 규모의 클라우드 구축에 사
용하기에 무리가 없어 보이고, 그 이상의 규모에서는 추가적인 작업이 맋이 필요할 것으로 보인
다.
반면에 CloudStack은 Cloud.com의 실질적인 노하우를 바탕으로 대규모 서비스를 위한 구조가 상
당히 잘 정리되어 있다. 특히 Virtual Router, 로드밸런서, 방화벽을 제공하는 Virtual Network부분
은 상당히 인상적이며, Portal도 괜찮은 수준이다.
Open Stack Cloud Stack
License Apache GPL ver.3
Hardware : standard hardware Management Server
Requirement
OS : Ubuntu 10.04 LTS, Red Hat 6 64-bit x86 CPU
9

10. Networking : 1000 Mbps are 2 GB of memory
suggested 80 GB of local disk
DB : PostgresSQL, MySQL At least 1 NIC
RHEL/CentOS 5.4+ 64-bit or RHEL6 64-bit
Statically allocated IP address
Fully qualified domain name as returned by the
hostname command
Host
64-bit x86 CPU
Hardware virtualization support required
4 GB of memory
30 GB of local disk
At least 1 NIC
Statically allocated IP Address
Citrix XenServer 5.6, RHEL/CentOS 5.6 (64-
bit), Fedora 14 (64-bit), or RHEL6 (64-bit)
Secondary Storage
NFS storage appliance or Linux NFS server
100GB minimum capacity
Xen/Xenserver 5.5, Xen/Xenserver,
KVM, KVM,
VMWare ESX/ESXi 4.1 update1 VMWare vSphere/ESX/ESXi,
Supporting
Hyper-V 2008,
Hypervisior
Linux Containers(LXC),
UML (User Mmode Linux)
QMENU
10