오픈소스 클라우드 기술 최신동향

안재석 2013. 06. 24

Overview 00

오픈소스 클라우드 기술

Cloud Operating System

클라우드 구축을 위한 오픈소스 기술 00

Open Compute 00

2011년 4월 페이스북이 시작한 오픈 프로젝트.

‘최소 비용으로 표율적인 컴퓨팅 인프라를 구축하자’ 라는 목표로 페이스북은 자사

데이터센터 구축 관련 기술을 공개하며 시작 하였고, 오픈컴퓨트를 통해서 페이스북

의 데이터센터 서버 디자인부터 시작해 컴퓨터 설계 도면까지 누구나 볼 수 있다.

2013년 5월 – SDN을 위한 오픈 네트워크 스위치 개발 발표

가상화 기술 00

• Hypervisor

• XEN (Open Source) • 상용라이센스 제품: Citrix XenServer

• KVM (Open Source) – 2007년에 Linux Kernel에 포함됨 • 상용라이센스 제품: Redhat Enterprise Virtualization

• KVM이 빠르게 마켓확장을 해 오고 있음. • KVM은 Linux Kernel에 기본으로 포함됨. • Xen에 대한 Citrix의 영향력

• 최근 동향

• Xen이 Linux Foundation의 Collaborative Project로 변환 (탈 Citrix)

Cloud OS (Cloud Management Platform) 00

• 가장 치열한 경쟁구도를 이루는 분야중 하나 • 가상화엔진, 네트워크, 스토리지등 다양한 기술을 연동하여 완성된 서비스를 만드는 중요 플랫폼 • CloudStack

• Citrix 프로젝트에서 아파치 재단으로 이동하며, 오픈소스 프로젝트로써 재 탄생

• OpenStack

• Rackspace/NASA가 시작하여, OpenStack Foundation으로 무사히 전환 완료.

• 현재 가장 강력한 커뮤니티와 에코시스템을 가진 오픈소스 프로젝트로 발전

Overview 01

OpenStack 기술 동향 및 에코시스템

Cloud Operating System

OpenStack Projects 01

Cloud Operating System

OpenStack Core Project • OpenStack Compute (code-name Nova) - core project since Austin release • OpenStack Networking (code-name Quantum) - incubated to be a core project in Folsom release • OpenStack Object Storage (code-name Swift) - core project since Austin release • OpenStack Block Storage (code-name Cinder) - incubated to be core in Folsom release • OpenStack Identity (code-name Keystone) - core project since Essex release • OpenStack Image Service (code-name Glance) - core project since Bexar release • OpenStack Dashboard (code-name Horizon) - core project since Essex release Incubation Projects • Metering (Ceilometer) https://launchpad.net/ceilometer • Basic Cloud Orchestration & Service Definition (Heat)

Emerging Projects (not yet accepted into the OpenStack incubation process): • Savanna: Hadoop as a Service for Private Cloud with OpenStack • Tempest / Cloud-Café: Testing Framework • Red Dwarf: OpenStack Database as a Service ://wiki.openstack.org/Heat

OpenStack Conceptual Architecture 01

Cloud Operating System

OpenStack Logical Architecture 01

Swift Glance Nova Cinder Quantum

Keystone

Dashbaord

Netapp

HP

Dell

EMC

Nexenta

Ceph

Zadara

…

OF controllers

NEC

Floodlight

NTT

Open Daylight

VMWare Nicira

Midokura

Cisco

Arista

Bigswitch

Brocade

MS Hyper-V

Linux Bridge

OVS

…

Netapp

Nexenta

Ceph

…

Quantum Neutron 01

• 상표권문제로 프로젝트 이름 변경

• OpenStack-Networking (Neutron)

Quantum 구조 01

Cloud Operating System

Quantum 구조 (plug-in with external technology) 00

Nova Compute Nova Compute

Nova Compute Nova Compute

Tenant Scripts

Horizon

Nova

Quantum Server

Quantum Plugin

Create-net

.

.

. Create-port

virtual switch

Internal plugin communication.

Quantum API

Create-net

.

.

. Create-port

Interfaces from a service like

Nova plug into a switch manages by the Quantum

plugin.

API + Plugin = Quantum Service

Uniform API for all clients

External Manager

DB

DB API

Extensions

(사례) OpenStack Quantum + OVS 02

Cloud Operating System

Quantum 구조 02

Cloud Operating System

Quantum 구조 01

Cloud Operating System

OpenStack내 Quantum 개발진행에 대한 비판 01

• Grizzly (2013.4월 출시) 까지의 주요 개발 업적

• Vendor들의 많은 기술들을 위한 Plug-In이 개발 • Quantum이 공통 서비스 인터페이스로써 발전

• 비판사항

• Vendor기술이 없는 Quantum은 Controller역할을 못함 • 기존 Nova-network 기능들중 수용하지 못한 부분 존재

• Flat-network (L3) with multi-host mode • Security Group with Quantum

Looking Back (What Quantum Promised) 01

기술적인 한계성 극복을 목표로 내세움

• 클라우드 환경이 가져온 네트워크의 새로운 요구사항 – Legacy on-primise 환경과 Data Center와의 연동 (Hybrid Cloud)

– Massive Sclae의 multi-tenancy 환경

– Commodity Network 장비 사용 가능성

– VM 이동성 확보 (inter / intra datacenter)

• OpenStack Nova의 한계성 – VLAN이 기본 multitenancy방법 (확장에 한계성)

– Simple Linux Bridge 사용 (QoS, ACLs, monitoring등이 쉽지 않음)

– “network controller” node가 병목지점이자 Single-point of failure 지점이 되고 있음

현실은… – 여전히 L3-agent에 대한 clustering 불가능

– OVS bridge 구현은 기능적인 제약성이 많은 상태임

– Nova-network가 가지고 있던 기능들도 아직 전부 migration이 되어 있지 않음

– Quantum자체에서 구현된 advanced기능은 거의 없음 (심지어 Load Balancing Service도 불가)

– Open Flow를 비롯한 SDN기술은 벤더 종석성만 커지고 있음

Looking Back (What Quantum Promised) 01

현실은… – Interface로서의 역할은 훌륭히 수행 (다양한 벤더/네트워크 기술들이 plug-in형태로 연동)

– 하지만, 벤더 기술을 제외하고는 상용적용 가능성이 있는 기술이 거의 없으므로, 오픈소스가 주는 장점들을 활용하기가 어려움.

– 어떤 기술을 선택해야 할지 (SDN 춘추전국시대) 판단하기가 어렵고, 기술들의 성숙도를 판단하기 어려운 상태임.

문제 해결을 위한 새로운 네트워크 기술의 등장

• 기술적 문제를 해결하기 위한 새로운 네트워크 기술 등장. – Software-defined Networking (SDN) / OpenFlow

– Network Virtualization / Overlay tunneling

– 그 외 다수의 신기술이 등장하고 있음.

• Qauntum은 이러한 기술들을 수용하기 위한 plug-in구조를 가지고 있고, 이를 서비스와 연동하기 위한 Middleware역할을 수행할 수 있음

지금까지 주요 사용된 현실적인 선택안 01

• Essex (2012 상반기 릴리즈)

• No Quantum • Network는 Nova (Compute)의 종속 프로세스 • Implementation

• Network-Node • Single Point of Failure, NAT부하

• Multi-host mode • Network node와 compute node 일치화

Quantum기반 상용화에 대한 우려 01

• Quantum은 Folsom (2012 하반기 릴리즈)에서 소개 • 알파버전 성격으로 시작 • 제한된 기능 셋

• Grizzly (2013 상반기)

• 베타버전 성격으로 발전 (여전히 안정성/기능범위 제약) • Vendor기반 기술들의 접목은 활성화 • Quantum자체의 controller기능은 미약

• Havana (2013 하반기)

• 상용적용 가능버전으로 예상 • 개발방향의 scope변화로 인해 quantum 자체의

controller기능 강화 예상

Service Provider입장에서의 Quantum / SDN 01

• OpenStack/Quantum • 오픈소스 소프트웨어로 자체 개발의 가능성 증대 기대 • 하지만,

• 여전히 Vendor 기술에 대한 의존성 존재 • 대표적인 Quantum/SDN사례는 Rackspace

• Nicira를 도입하여 구성. (Vendor기술 필요)

• SDN • 내부적인 잇점들 (작업 효율화, Capex/Opex절감등) • 하지만,

• 사용자에게 줄 수 있는 Benefit이 명확치 않음

주요 요구사항 01

• 물리적 네트워크 토폴로지와 논리적 네트워크의 분리 • 네트워크도 Programmable한 인프라 리소스로 변화 필요

• 네트워크 서비스 Provisioning의 자동화

• 많은 네트워크 작업들이 네트워크 운영자의 수동작업 필요

• 대표적인 클라우드 네트워크 모델인 vlan모드의 제약 극복 • Virtual Network / SDN기반 확장성 확보

• Hybrid Cloud의 기본이 될 네트워크 연동 필요

• Public Cloud Network / On-premise Private Network

• 클라우드 확산에 따른 기반네트워크의 변화 필요