기술전략팀 이석훈

창의적인 발상은 창의적이고 자유로운 공간에서 나온다고 합니다. 일부 회사들은 직원들이 창의적인 아이디어를 끌어낼 수 있도록 사무공간과 환경을 개선하기도 합니다. KTH는 개발자의 창의적이고 자유로운 공간을 개발자 클라우드를 통해 마련하고자 하였고, 그 내용을 상세히 공개합니다.

Overview

사내 개발자들에게 전혀 업무와 상관없이 지극히 개인적인 용도의 놀이터로서 개인 서버 장비로 쓸 수 있는 개발자 클라우드를 구축하게 되었습니다. 수년 전이였다면 개인 업무용 PC 외에 서버용도의 PC를 던져주고 사무실의 온도와 소음만 높였을 터인데 이제는 Cloud가 대세인 시대가 아닌가요! 또한 저희는 기존 서비스 운영을 위해 사용되던 수백대의 VM(Virtual Machine) 제공 방식처럼 사양 및 OS 환경의 요구사항에 맞게 VM을 제공해 주는 것이 아니라, 사내 개발자들이 자율적으로 VM을 운용하고 커뮤니티 VM Template 들을 서로 공유하고 의견을 나눔으로써 개개인의 기술적인 노하우들이 자연스럽게 Open & Share 할 수 있기를 원했습니다.

저희는 회사내의 다양한 상황을 고려해 아래와 같은 원칙을 세웠습니다.

        1.  VM(Virtual Machine)의  생성 및 자원 할당을 포함한 모든 관리는 개발자 스스로 할 수 있어야 한다.

        2. 일반적인 서비스포트를 제외한 모든 가상화 장비로의 접근은 사내 VPN 을 통해 접근하도록 한다.

        3. 회사내의 서비스 인프라에 영향이 없도록 물리적/ 논리적으로 분리되어야 하며 공개된 서비스 포트 외의 접근을 허용하지 않는다.

위의 원칙을 기준으로 가장 먼저 진행한 것은 개발자들에게 제공될 VM(Virtual Machine) 이 Self-Service Portal 형태로 제공이 가능하게 해줄 수 있는 Open Source 기반의 SW 플랫폼의 선정 이였으며 KT ucloud biz 에서 도입하여 국내 상용 서비스에 적용한 CloudStack 을 적용하기로 결정하고 제공되는 매뉴얼을 기반으로 구축하였습니다.

 

1. About CloudStack

먼저 CloudStack에 대해 간단히 소개하자면 AWS(Amazon Web Service)의 EC2와 같은 IaaS 구축을 위한 Open Source 기반의 클라우드 구축 운용 Software Suite (환경 구축 툴) 이며 작년에 Citrix사가 인수하였으며 최근 3.X 정식 버전이 릴리즈되어 많은 부분들이 개선되었고, 오픈소스 소프트웨어 프로젝트 지원단체인 ASF(Apache Software Fundation)에 기증한다고 발표하였습니다.

•  CloudStack 특징
  • Scalable Architecture
  • Multiple Hypervisor Support (Xenserver, KVM, VMware vSphere,… )
  • Automatic Configuration Management ( support virtual appliances)
  • Graphical User Interface ( support Admin/EndUser  Web UI )
  • Standard API Support
  • Extensibility (pluggable allocation architecture )
  • High Availability configurations
  • Virtual Networking to segment network traffic into VLANs
• CloudStack 구축 예
  • Public Cloud 환경 구축
    • Amazon EC2™ service와 같은 서비스 제공
    • 구축회사 : KT, TATA, IDC Frontier
  • Private Cloud 환경 구축 (Enterprises)
    • 구축 회사: Zynga, KTH(?)

 

2. 구축 환경

우리가 구축했던 시스템 및 SW환경은 아래와 같으며, VM의 Virtual disk Image인 Root Disk 과 Data volume을 저장하기 위한 Primary Storage는 iSCSI Storage 를 사용, Template, ISO images, snapshot 등의 정적 데이터를 저장하기 위한 Secondary Storage는 NFS(Network File System) 을 사용하여 구축하였습니다.

• Hypervisor  – Citrix Xen Enterprise 5.6 SP1
• Operating system – Red Hat Linux 4.1
• CloudStack version 2.2.13

 

3. 개발자 클라우드 구성

CloudStack 에서 제공하는 여러 메뉴얼들은 CloudStack 기반의 Cloud self-service Portal 을 구축하는데 부족함이 없으며 기본적으로 CloudStack의 네트워크 모델에 대한 이해가 필요합니다. 사내 클라우드 인프라팀에서는 이미 우리만의 네트워크 아키텍쳐를 적용하여 가상화 시스템 환경을 구축하고 XenCenter(XenServer Management Client)를 통해 XenServer 기반의 VM을 운영하여 회사내의 여러 서비스를 제공하고 그에 대한 노하우가 있는 상황으로 시작이 두렵지는 않았었습니다. 물론 초기 구축 시에는 전통적인 회사 네트워크 아키텍쳐 기준으로 CloudStack 네트워크 설계를 고려하여 개발자 클라우드 구성에 몇 차례 시행착오가 있기도 했었습니다.

현재 구축된 KTH 개발자 클라우드는 CloudStack 네트워크 모델을 기준으로 구성되었으나 Zynga가 CloudStack을 기반으로 Zcloud를 구축하여 AWS의 의존도를 20%수준으로 낮춘것처럼 추후 CloudStack 을 커스터마이징 하여 사내 서비스를 위한 가상화 서버군의 아키텍쳐를 수용 가능하도록 개선하고 기존의 인프라 운영을 위한 Legacy 시스템의 연계를 진행해 보고 싶은 것이 개인적인 욕심입니다. 

 

3.1 시스템 구성

CloudStack의 구성은 크게 Management Server와 Cloud Infrastructure로 나눌 수 있으며 Management Server를 통해 Cloud Infrastructure의 관리를 수행합니다.

Cloud Infrastructure는 여러 개의 Zone (datacenter)로 구성되며, 해당 Zone 안에는 VM(Virtual Machine)을 동작시키는 Host Computer 가 존재합니다. 큰 단위 순으로 나열해보면 Zone > Pod > Cluster > Host 순으로 구성이 이루어집니다.  제공되는 메뉴얼에는 규모에 따른 클라우드 구성에 대해 제안을 하고 있으며 구축 용도 및 상황에 따라 참고하여 구성할 수 있습니다.

현재 구축된 KTH의 개발자 클라우드의 시스템 구성은 아래와 같습니다. (네트워크 구성과 관련된 부분은  개발자 클라우드 구축 멤버이신 클라우드기획팀 이장원 팀장님이 첨언 해주셨습니다.)

 

 

• Layer 3 스위치는 C사 제품으로 방화벽과 L3 스위치 모듈이 하나의 블레이드내에 존재합니다. 방화벽 설정의 경우 인바운드 트레픽의 경우는 ACL를 설정하여, 허용된 트래픽만 통신이 가능하며 아웃바운드 트레픽은 차단하지 않았습니다. 라우터의 경우 VRRP(Virtual Router Redundancy Protocol)을 이용하여 고가용성을 구현하였습니다.
• Layer 2 스위치는  각 Pod 와 연결되는 구조로 Pod 구분은 물리적인 스위치를 통한 분리가 아니라 동일 L2스위치내에서 VLAN을 통한 별도의 IP Class 제공을 통한 분리 방식을 채택하였습니다., 또한 스위치의 경우 일반적인 이중화 방식인 INTER-LINK를 이용하여 이중화 하였고, 각 호스트머신은 Bonding 구조로 연결되어 있습니다.
• Management Server에는 Cloud Infrastructure 관리를 위한 Self-Service Portal 과 Mysql DB가 설치되며 되며 각각 Single Node 및 Multi Node 구성과 Single 및 Primary/Backup 형태로 구성이 가능합니다. 저희는 현재 모두 Single로 구축하였으며 접근 허용을 위한 공인망(시스템 자체 방화벽 설정을 통해 사내, VPN을 통해 접근 가능하도록 설정)과 클라우드 자원들을 관리하기 위한 사설망 연결 구성을 하였습니다. (물론 상용으로 서비스를 런칭하였다면 당연히 이중화를 고려했을 것이라는 것을 의심하지 않길 바라는 마음입니다. ^^;)
  • 관리자용 EndUser용 WEB UI 제공
  • API 제공
  • 새로운 VM생성 요청시 Offering 조건에 맞는 Host Computer에 배정
  • 예약된 범위 내에서 Private/ Public  IP 자동 할당
  • DISK 할당 관리 ( Root Data, Data Volume )
  • Snapshots, Templates, ISO image 관리
  • user 권한의 API에서 Portal의 계정 패스워드를 변경 못하게 되어있는 부분에 대해서는 납득이 어려웠습니다. 모든 Self-Service Portal의 제어는 내부적으로 API로 연동이 되기 때문에 실제 내부용 서비스의 오픈 이후에 포털 계정에 대한 비번 변경에 대해서 모두 Admin 권한으로 수정하였습니다.  CloudStack 3.0에서는 LDAP 연동을 지원하여 사내 그룹웨어 시스템과 연동이 가능하게 될 것으로 보여 이 부분에 대해서는 업그레이드로 해결하려고 계획하고 있습니다. 
• Zone은 하나의 datacenter로 볼 수 있으며 CloudStack 플랫폼상에서 가장 큰 단위의 집합 구성으로 CloudStack은 개념적으로 하나 이상의 Zone을 가질 수 있습니다. Zone은 하나 이상의 Pod와 Secondary Storage로 구성되어 있으며 하나 이상의 Layer3 Switch가 포함될 수 있습니다.  우리의 경우 규모가 크지 않아 현재 한 개의 Zone으로 구성하였습니다.
• Pod는 일반적으로 Rack 하나를 의미하며 Layer-2 스위치와 하나 이상의 Cluster로 구성되며 동일 Pod 내의 Host는 같은 subnet을 사용합니다. 보통은 Pod에 한 개의 Cluster의 관계를 가지고 구성된다고 합니다.
• Cluster는 하나 이상의 Host Machine과 Primary Storage로 구성되며 동일한 Hypervisor 타입 (Xenserver, KVM, vSphere, Oracle VM)이 가능합니다.  우리가 적용한  Xenserver 기준으로는 최대 8개의 Host Machine을 Pool로 구성하여 CloudStack의 Cluster에 연결 시킬 수 있습니다. Citrix Xenserver Hosts의 Pool 구성 및 네트웍 세팅은 관리툴인 Xencenter를 통해서 설정하였고 Xenserver 제어가 가능한 콘솔 명령어들이 있지만 몇몇 정보를 확인하기 위한 용도로만 사용하였습니다. 우리가 적용한 CloudStack 2.2.13 에서 VM의 이동은 동일 Cluster 내에서 가능합니다. (CloudStack 3.X 부터는 동일 Pod내의 Cluster 간의 VM 이동이 가능하도록 개선되었습니다.)
• Host는 Cluster 내에 있는 Compute Node 이며 VM을 호스팅합니다.
  • CPU, Memory, Storage, 네트워크 리소스를 제공
  • 다양한 CPU 속도와 Memory 구성이 가능하며, Offering 형태로 제공
  • 동일 Cluster 내에는 동일 CPU로 구성
  • VM의 root disk는 service-offering에서 data volume은 disk-offering에 정의
  • Offering : Template(OS+Software), Service-offering (Cpu + Memory), Disk-offering으로 구성됨
  • 우리 개발자는 모두 평등한 자유시민! 이기 때문에 동일한 사양으로 제공하고 Disk Volume만 다양성을 두었습니다. 만일 신규 도입 및 구축 플랫폼 테스트를 위해 고성능 또는 다수의 리소스를 제공하는 테스트 Cloud 팜을 구성하게 된다면 다양한 Offering 을 제공했으면 합니다. 이런 테스트 Cloud 팜은 개발자들이 임시로 리소스를 할당 받아 구축한 아키텍처를 스스로 검토하기 위해 정말 필요합니다.
• Secondary Storage는 Template, ISO images, snapshot 등의 정적 데이터가 저장되며 Zone내에 위치하며 Multiple Storage Server를 등록 가능합니다. Zone내에만 존재하기 때문에 동일 Zone에 있는 VM에게만 서비스 됩니다. Secondary 스토리지의 경우 NFS 프로토콜만 지원하기 때문에 IDC내 운용중인 Scale-out(*가상화 환경에 중요한 포인트) NAS 스토리지를 통하여 1TB 디스크 볼륨에 Template, ISO, Snapshot의 증가를 예측하여 Auto Scale-out 볼륨으로 최대 5TB 제공되도록 구성되었습니다.
• Primary Storage는 VM의 Virtual disk Image인 Root Disk와 Data Volume을 저장하며 Cluster내에 위치하며 Multiple Storage Server를 등록 가능합니다.  iSCSI, NFS지원이 가능하며 VM의 Performance에 많은 영향을 줍니다. Primary Storage 없이 Host Machine의 Local Storage의 사용도 가능하나 VM의 이동 backup 설정이 불가능해져 fault tolerant 한 운영이 힘들어 집니다. 저희는 iSCSI 를 통해 구성하였으며 iSCSI 스토리지도 Secondary Storage와 마찬가지로 Scale-out 구조의 디스크 볼륨의 크기가 Thin provisioning 지원이 가능한 스토리지를 통하여 구성되었습니다. 기존 전통적인 SAN 스토리지의 경우 고가용성 측면에서 DBMS 가상화등에 운영하고 있으나 금번 개발자 클라우드환경의 경우 유연한 가상화 인프라 구조의 테스트?(네크워크 통합) 및 효율적인 디스크 볼륨의 사용을 위하여 스토리지 가상화 기술 활용 차원에서 Thin Provisioning을 통한 디스크 볼륨의 제공으로 디스크 리소스 사용요청에 유연하게 대응 할수 있는 환경을 제공하게 되었으며, 실제 서비스 운영환경에도 점진적으로 SAN 구조의 디스크 할당 방식에서 iSCSI 기반으로 Thin Provisioning 구조의 스토리지 사용을 확대할 계획을 가지고 있습니다.

 

3.2 네트워크 구성

CloudStack의 네트워크 아키텍쳐상 여러 유형의 Network가 존재하며 Physical, Virtual 두가지 Type의 네트워크로 분류됩니다. CloudStack 기반의 Cloud 구축시 반드시 이해하고 있어야 할 부분이라서 간단하게 살펴보면 아래 표와 같습니다.

Network Type	내용	비고
Guest Network	- VM이 연결된 Virtual 네트워크	Isolation을 지원
Private Network	- VM간 트래픽을 전달하는 Physical네트워크	Guest Network : Virtual Networking
Link-local Network	- Hypervisor Host와 system VM(Virtual Machine) 간 통신을 위한 네트워크 (RFC 3927  Network)
Public Network	- VM, 인터넷간 트래픽을 전달하는 Physical 네트워크 – Guest Network이 Driect Attached Networking 일 경우 guest 간 트래픽을 전달.	- VM에 Public IP 할당
Management Network	- 관리서버, Host, Storage 간 Physical 네트워크
Storage Network	- Host와 Storage간의 Optional Physical 네트워크	트래픽이 많이 발생하는 링크 분리

※ 하나의 NIC으로 여러 Physical Network 사용이 가능

 

CloudStack 의 네트워크 모델은 Basic Mode 와 Advanced Mode 두가지 모드를 지원하며 Zone 구성 시 선택 및 설정이 가능합니다. VM의 인터넷에 직접 연결 여부에 따라 “Direct Attacked”와 “Virtual”로 구분되며 아래 표와 같이 정리할 수 있습니다.

항목	Virtual Networking	Direct Attached tagged Networking	Direct Attached Untagged Networking
VM, 인터넷간 트래픽	- Virtual Router 거침	- 직접연결	- 직접연결
Network Isolation 여부	- Virtual Router가 Isolation 지원- Account별 VLAN(zone-wide)	- Tag로 Isolation 지원- Account별 VLAN Isolation	- 지원안함(Security Group으로 가능)
Mode	- Advanced	- Advanced	- Basic
Virual Router(VR) 역할	- VM에 Private IP 할당- Source NAT, LB, Firewall, VPN, DHCP, DNS	- VM에 Public IP 할당	- VM에 Public IP 할당
비고	- External Network Device 구성가능, 단 DHCP, DNS 기능은 VR에서 수행		- Private Cloud에 유용함

 

저희는 개발자 클라우드의 네트워크 모드로 Basic Mode를 선택하여 구성하였습니다. Advanced Mode 중 Virtual Networking의 경우에는 계정 별로 시스템 관리를 위한 System VM 중에 하나인 Router VM이 생성되며 계정에 연결된 여러 대의 장비의 Router 역할을 하며 Router VM 역시 host 장비의 자원을 사용하며 Amazon EC2와 같은 Public Cloud 환경에 적합합니다. 현재로선 개인당 가상서버 1개씩만을 나눠 주는 우리 개발자 클라우드의 특성 상 부적합하다고 판단하였습니다.

현재 구축된 KTH 개발자 클라우드에 적용된 네트워크 구성은 아래 그림과 같습니다.

 

 

개발자 클라우드 구성에서 가장 고심한 부분은 네트워크 구성이였습니다. 기존의 클라우드 플랫폼 매니지넌트 솔루션(CloudStack 포함)들의 기본적인 컨셉은 IDC 운영의 전통적인 네트워크 인프라 구조와 많은 차이를 가지고 있습니다. 이 부분에 대해서는 설명이 좀 길어질 수가 있는데 간단히 정리하자면 KTH의 경우 백업, 스토리지,모니터링, 관리등을 위한 별도의 사설 네트워크와 서비스를 위한 공인 네트워크 구조를 가지며 호스트머신은 각각 물리적으로 분리된 별도의 NIC를 사용하도록 구성되어야 할 필요가 있었습니다. 이를 지원하기에는 별도의 IP 클래스를 제공하는 L3~L2 레이어 스위치가 필요한 환경으로 클라우드 매니지먼트 솔루션으로 관리하기 어려운 인프라스트럭처를 가지게 되는 문제를 가지게 됩니다.

유연한 네트워크 구조를 제공하기 위하여 금번 개발자 클라우드에 적용한 방법은 VLAN을 통하여 단일 L2 스위치 상에서 공인, 사설, 스토리지, 관리 네트워크를 VLAN 분리하고, IP Class를 VLAN Tag를 이용하여 구분하도록 구성하였습니다. 물론 단일 채널에 여러 트레픽이 몰리는 부하를 예상하여 스위치와 호스트머신간에 케이블 채널링을 통하여 네트워크 대역의 전송량을 높이고, 일정 부분 QoS 적용을 통한 네트워크 품질을 보장하도록 구성하였습니다.

 

4. 마치면서

사실 개발자 클라우드를 구축하고 테스트하면서 이렇게 Web기반 Self-Service를 통해서 가상머신들이 원하는 Offering이 적용되어 십여 초 만에 생성되는 것들 지켜보고 있자면 참 경이로웠습니다. 직접 무엇인가 만들어보고 이런 느낌이 드는 것은 참 오랜만 이였던것 같습니다. CloudStack은 그 자체만으로도 Cloud Selft-Service 환경을 구축을 시작하기에 훌륭한 SW 툴킷이라고 개인적으로 생각합니다. (물론 완벽하지는 않지만 지속적으로 개선되고 있는 상황입니다. 우리가 시행착오를 겪으며 Cloud Infrastructure의 생성 및 삭제를 빈번하게 했었는데 Fault가 발생했을 때 정상적으로 데이터가 제거 되지 않는 경우가 많아 DB를 통해 쓰레기 데이터를 삭제하기도 했었습니다.)       

CloudStack 도입 결정부터 마지막 보안정책 결정 이후, 사내 개발자를 위한 Cloud Self-Service 포털 오픈까지 약 한달 정도 걸린 듯 합니다. 처음 시작할 때는 CloudStack 에서 사용하는 용어도 많이 낮설어서 (이 글을 작성하면서 CloudStack에서 사용하는 용어들을 정리해보니 이제서야 좀 친숙하게 느껴집니다.) 내용을 엉뚱하게 해석하고 진행하다가 시행착오도 있었지만 되돌아보면 꽤 즐거운 시간 이였고 이런 시스템을 구축할 수 있는 기회와 환경이 주어졌던 것에도 고맙게 생각됩니다.

앞으로의 계획은 단기적으로 CloudStack 3.0으로의 업데이트이며 사내 LDAP 서버와 계정을 연동할 계획입니다. 또한 중기적으로는 이번 기회를 통해 Public/Private Cloud 환경의 구축에 관심을 많이 갖게 된 KTH 개발자 클라우드 구축 멤버들과 함께 CloudStack 3.0 코드분석, Network 일반 (같이 작업했던 인프라팀 멤버분과 네트워크 관련해 커뮤니케이션을 하다 보면 개발 쪽에서는 놓치는 부분이 많았었는데 네트워크에 대한 기본지식이 많이 부족하다는 것을 느꼈었습니다.) 등에 대해서 COP(Community Of Practice)를 진행하여 사내 상용 인프라에 적용 가능한 Private Cloud 환경 구축에 대한 방안을 찾아 보고자 합니다.