Virtualized Datacenter as a Service (vDCaaS)

vDCaaS
Virtual Datacenter as a Service
2013/12/30
Jung-In. Jung.
call518@gmail.com

Conceptual changes
 가상화 기술과 H/W의 발전으로 인해, 집적도 상승.
 vServer, vStorage, vNetworking, Etc…
 많은, 그리고 쓸만한 OpenSource들
 CloudStack, OpenNebula, OpenStack, Proxmox, Etc.
 Cloud → "DC"에 대한 인식에 변화.
 '소유' → '대여', '경직' → '유연'
 그러나, Server Virtualization 중심적
 vServer를 제외한 Infra요소에 대한 구성/운영의 자유도가 상대적으로 낮은 상황.
 전통적인 "DC"의 주요 구성요소들의 개념 전환
 Cloud 이전: "사용자 관점" = "제공자 관점"
 Cloud 이후: 가상화를 기반으로, 두 관점이 상이 해짐.
 e.g.) Server, Network, Rack, Etc

Conceptual changes
1 Physical Server

Conceptual changes
Virtual Machine
1 vServer
1 Physical Server

Conceptual changes
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine

Conceptual changes
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
1 Physical Server

Conceptual changes
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
1 Physical Rack
1 Physical Server
(=vRack)

Conceptual changes
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
1 Physical Server
(=vRack)

Conceptual changes
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
VirtualMachine
1 Physical Server
(=vRack)

Conceptual changes
1 Physical Rack
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM

Conceptual changes
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
1 Physical Rack

Conceptual changes
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
1 Physical DC
(pDC)
1 Physical Rack
(=vDC)
vRack
#1
vRack
#2
vRack
#3 .............. vRack
#N

 vDC Concept
Conceptual changes
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
1 Physical Rack
(=vDC)

 vDC Concept
Conceptual changes
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
vServer
1 Physical Rack
(=vDC)

 vDC Concept
Conceptual changes
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
vServer
1 Physical Rack
(=vDC)
vRack

 vDC Concept
Conceptual changes
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
vServer
1 Physical Rack
(=vDC)
vDC
vRack

Conceptual changes
 New Issues
 Virtualization → VM 밀도 ↑ & Network 복잡도 ↑
 STP 이슈
 Virtual Switch를 비롯한, 논리적인 네트워크의 출현.
 복잡해진 네트워크 망, Hop에 대하여 STP 수행 → Overhead 증가
 Mac Flooding
 기존 대비 물리서버당 100개의 Mac이 추가된다고 가정해야 한다.

Isolation & Placement
 Isolation
 IaaS 및 vDCaaS의 Multi-Tenant들이 동일한 물리 환경에 혼재되어 있는 환경에서도, Co-
Location 또는 전용 DC를 사용하는 것과 동등한 수준의 Security(Isolation) 보장은 필수.
 Physical Network의 제약에서 자유로운 Logical Network모델이 요구된다.
(for Migration, Failover, Etc...)
 많은 Tenants가 혼재된 상황에서도, 상호간 격리된 서비스가 가능해야 한다.
 Placement
 Workload의 분산/재분배.
 자원(전력, 공간, 서버파워, 저장소, 망)의 효율 향상.
 VM의 배치/재배치 스케줄링 정책 요구
 개념은 쉬우나, 실무에 적용하기는 쉽지 않다. 경험적 노하우가 중요한 요소.

Isolation - Physical vDC
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Tenant #1 Tenant #2 Tenant #3
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Isolation - Physical vDC
Isolation Isolation
VM
VM
VM
VM
VM
VM
VM
VM
VM

Isolation - Logical vDC
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Physical vDC...

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VMVM
VM
VM
VM
VM
VM
VM
Pod #1 Pod #2 Pod #3
Logical vDC...

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VMVM
VM
VMVM
VM
VM
VM
VM
VM
Isolation Isolation
VM

Placement - Physical vDC
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Isolation Isolation

Placement - Physical vDC
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Isolation Isolation
Local
Migration

Placement - Physical
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Isolation Isolation
Power OFF
Nothing to do... Nothing to do...

Placement - Logical vDC
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Global
Migration

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Power OFF
Power OFF

Elements vDC
 Physical DC(pDC) 자원 → "Resource Pool"로 통합
 "pDC자원을 하나의 Pool로 통합 후, 필요할 때, 필요한 만큼 분할하여 사용."
 "효율적이고 유연한 통합관리 아키텍처와 정책 수립"이 관건.
 Computing Pool
 Storage Pool
 Network Pool
 Network Pool 요건
 Network Pool 모델이 vDC의 가장 중요한 근간
 Storage, Compute Pool 자체가 Network Model에 기반 함
 최대 4096개의 Tenant수를 가진 VLAN의 한계 극복
 기존의 범용 Network 장비의 사용/재사용 가능
 Network 자원에 대한 탄력적이고 기민한 운용 가능
 관리/운영의 복잡성 증가를 최소화 해야 함

Storage - Limitation & Requirement
 Virtualized Storage → "Flexibility & Availability"
 VM Mobility(Live-Migration) 확보
 자원 통합 → Storage 자원의 Utilization 향상 및 Available Capacity 증가.
 Shared Storage(NAS/SAN) 형태
 Shared Storage 구조에서, Bandwidth와 Latency 이슈.
 상대적으로 HA, DR, Backup에 대한 부담 존재.
 Capacity ∝ Performance (Linear)
 High IOPS 및 균일한 Latency → SSD
 VM Image의 Snapshot(for Template or AMI, not Backup) 지원.
 Archiving Storage 분리 권장.

Storage - Alternative #1
 DAS-Storage (in Each pServer)

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
 Local Storage (None-Traffic)
 Live-Migration 불가능
 pServer 장애 → VM 중단
 VM별 데이터 관리 및 Backup
 Latency 측면은 유리
Can't
Migration
Ⅹ

 DAS-Storage Clustering
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Clustering

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible
 Rack 단위 Storage
(Rack Traffic)
 pServer 장애 대응 가능
 제한적 Live-Migration
 Relatively low Latency
 비효율적 자원 활용 이슈
 Compute 편향...
 Storage 편향...
 POD단위 데이터 관리/백업
Can't
Migration
Ⅹ

 NAS-Storage per Rack
VMVM
VMVM
VMVM
VMVM

VMVM
VMVM
VMVM
VMVM
Migration
Possible

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible
Migration
Possible

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible
Migration
Possible
Can't
Migration
Ⅹ

VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
VMVM
Migration
Possible
 pServer와 pStorage 영역 분리
 Storage Layer SPOF 가능.
 전용 NAS/SAN으로 성능 확보.
 제한적 Migration 가능
 Relatively low Latency
 Rack당 관리 (POD개념)
 POD단위 데이터 관리/백업
Migration
Possible
Can't
Migration
Ⅹ

 Global NAS-Storage
Shared Storage Cluster

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Ethernet or iSCSI or FC

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Migration
Possible

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Availability - Least 3 Copies

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
A
A A
A
B
B
B
B

VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
A
A A
A
B
B
B
B
용량 ...
𝟏
𝟑

DR ?

Near-Realtime Sync for DR

용량... X2

용량... X2 Total...
𝟏
𝟔

용량... X2 Total...
𝟏
𝟔
Wasteful ?

(Note)
Capacity ?

 Compare Capacity
Traditional Storage Pool

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
Total: 400 GB Total: 200 GB

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
Can'tShare
Pooling

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
Utilization...
80%
20%
10%
30%
Can'tShare
Pooling
140GB/200GB
=70%

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
80%
20%
10%
30%
Can'tShare
Pooling
140GB/200GB
=70%
Utilization...
WARN
Wasteful

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
80%
20%
10%
30%
WARN
Can'tShare
Pooling
140GB/200GB
=70%
Utilization...
20 GB
Free
60 GB
Free
Capacity Failure
Wasteful

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
80%
20%
10%
30%
WARN
Can'tShare
Pooling
140GB/200GB
=70%
Utilization...
20 GB
Free
60 GB
Free
Capacity Failure
Wasteful
HA?

100 GB
100 GB
100 GB
100 GB
100 GB 100 GB
100 GB 100 GB
if 2 Copies...
80%
20%
10%
30%
WARN
Can'tShare
Pooling
140GB/200GB
=70%
Utilization...
20 GB
Free
60 GB
Free
Capacity Failure
Wasteful
HA?
But,......
B/W & Latency is...

 Flexibility (for VM Mobility)
 모든 vServer로부터 요청을 처리하므로, Latency 및 B/W 확보가 필수.
 vServer 입장에서 Storage 망과, 일반 Traffic망 분리.
 HA를 위해 Storage의 전체 가용 용량 감소 (3-Copies일 경우, 1/6)
 표면적으로 감소하나, DAS(Local Disk) 타입보다 효율적이고 안정적.
 Backup
 "Backup" → "특정 시점의 백업 사본을 확보하는 행위"
 #1, #2, #3 케이스의 경우, Storage레벨에서 Backup이 가능하다 볼 수 있다.
 #4의 경우, 매우 방대한 크기의 용량이다. (수 Peta까지 될 수 있다고 가정해야 한다.)
 Storage레벨에서 Backup을 수행한다는 것은 불가능 또는 비효율적이라 보는 것이 합리적.
 VM 개별적으로 Snapshot을 생성하고, Snapshot으로부터 백업 사본을 생성 및 물리적으로 분리된 저장소에 보
관하는 프로세스가 효율적.
 I/O 요청이 집중되는 구조
 도미노 현상 방지를 위해 구획화나, 적절한 I/O분산 설계와 B/W확보 및 병목 구간 집중 관리.
 단위 산정
 거대 단일 Storage의 경우 Error 상황이나, Client와의 Connectivity에 문제가 발생했을 경우 Critical한 SPOF.
 적정 규모 단위 셀로 구획화 → 장애 범위 최소화.
 적정한 규모의 Resource Set을 정의하고 각 Resource Set당 Storage Cluster를 구획화하여 연동 방안 검토.
 (주의) 지나치게 세분화된 구획화는, Mobility가 현저히 저하 시킬 수 있다. 적정선 선정이 관건.

Compute - Limitation & Requirement
 H/W 스펙 표준화
 Computing 자원의 Pool 규모 산정 최소 단위.
 호환성: 신속한 장애 장비 교체/수리가 상시 가능.
 VM Mobility(Live-Migration) 확보.
 Performance측면에서, Max보다 Average를 우선으로, 그리고 Min/Max 오차가 작은 H/W가 유리.
 고밀도 VM → High Cores, Memory, 그리고 High Speed & B/W의 I/O 대역폭 확보.
 Hypervisor
 e.g.) Xen, KVM, VMware, Hyper-V....
 KVM
 Full-Virtualization (include Para)
 Kernel Baseline 포함 (>=2.6.20)
 지원 OS Platform 광범위.
 (Note) Windows의 경우, Hyper-V기반이 License비용 절감 유리.
 HPET 및 Nested-VT(Optional) 지원.
 NUMA 아키텍처 고려.
 Hyper-Threading류의 기술은 Computing Power의 보장 측면에서 상세 검토 필요.
 각 자원에 대한 Overcommit 지원 검토 필요. (Storage의 Thin-Provisioning은 예외 검토)
 단일 VM의 최대 스펙은, 단일 pServer의 스펙을 초과할 수 없다.
 VM 상품별 Size와 특정 Resource의 Utilization 편향 최소화를 고려한 설계.
 e.g.) 최소 상품 스펙의 배수로 상품 카테고리 생성 및, pServer H/W 스펙 결정. (역산 가능)
 pServer 관리 자동화를 위해, Wake-on-LAN/DNS/PXE/DHCP/IPMI 활용 가능.

Compute - Limitation & Requirement
 e.g.) Simple Structure
 Using 'Shared Storage'
 2Core/4GB/1Gbps 스펙의 VM 기준, 최대 20개 VM 수용 가능.
 B/W의 경우 기본 Shared (Min: 500Mbps)
 Hypervisor레벨에서 Network B/W QoS 설정 및 대역폭 지정/제한 가능
 망 분리 권장: Service / Storage / Migration (Network 모델과 함께 검토)
 pServer는 언제든 교체, 수리, 폐기가 가능하다는 것을 전제, OS는 USB로....
≥ 32 Cores ≥ 128 GB ≥ 10 Gbps
OS - Hypervisor
≥ 1 Gbps
Example….

Compute - Example
 Simple Structure
 Shared Storage
WAN
TOR - Storage
TOR - Service
Switch - Storage
Switch - Service
VMVM
VMVM
VMVM
VMVMStorage...
선택적...
TOR - Migration
Switch - Internal

Network - Limitation & Requirement
Network Requirement
 Multi-Tenant
 기존의 4096개가 최대인 VLAN(802.1q)로는 Cloud상의 Tenant 규모에 대응하기 어렵다.
 각각의 Tenant내에서도 다 계층 네트워크 구성이 가능해야 한다.
 Dynamic Network Provisioning
 필요로 하는 Network Resource의 할당/생성, 그리고 Configuration이 즉시 가능.
 Self-Service & On-Demand
 Large L2 Domain
 Work-Load의 유연한 재배치를 위해, 동일 & 거대 Segment의 Network 모델 필요.

<Limitation & Challenges of Existing L2 Datacenter>
 Spanning Tree에 의한 제약
 L2는 중복 경로에 의한 Loop를 막기 위해 STP를 사용.
 STP는 프레임의 Looping과 복제를 막기 위해 특정 Link를 Off (Expensive)
 따라서, STP 모델에서는 Multipath 지원이 취약.
 Broadcast의 확장에 있어, Isolation/Security 한계
 L2에서 Broadcast 영역을 격리 하기 위해, 12bit(4096개) VLAN ID를 사용.
 Virtualization기반의 Cloud환경에서는 4096이라는 숫자는 충분치 않다.
 POD간 제약
 Server/Storage/Network를 모두 갖춘 단위인 POD에서, 다른 POD로 이동이 쉽지 않다.
 Virtual Machine 운영에 있어서, Host Machine의 Workload 조절을 위해 POD간 이동이 용이해야 함.
 L3는 Multi-Tenant에 부적합
 한 Tenant는, 다른 Tenant와의 IP 중복을 고려할 필요가 없어야 한다. (IP Overlap...)
 IP기반의 "Connectivity"는, VM-to-VM과 같은 L2통신에 의존하는 사용자를 제외 시킬 수 있다.
 TOR 스위치의 Mac Table 사이즈 한계
 Virtual Machine운영 환경에서는 Server당 100개의 Mac이 발견될 것이라 가정해야 한다.
 Rack당 24~48대의 서버가 하나의 TOR에 연결된다면, Mac Table 사이즈는 충분치 않다. (Mac Flooding)

<Limitation & Challenges of Existing L2 Datacenter>
 Spanning Tree에 의한 제약
 L2는 중복 경로에 의한 Loop를 막기 위해 STP를 사용.
 STP는 프레임의 Looping과 복제를 막기 위해 특정 Link를 Off (Expensive)
 따라서, STP 모델에서는 Multipath 지원이 취약.
 Broadcast의 확장에 있어, Isolation/Security 한계
 L2에서 Broadcast 영역을 격리 하기 위해, 12bit(4096개) VLAN ID를 사용.
 Virtualization기반의 Cloud환경에서는 4096이라는 숫자는 충분치 않다.
 POD간 제약
 Server/Storage/Network를 모두 갖춘 단위인 POD에서, 다른 POD로 이동이 쉽지 않다.
 Virtual Machine 운영에 있어서, Host Machine의 Workload 조절을 위해 POD간 이동이 용이해야 함.
 L3는 Multi-Tenant에 부적합
 한 Tenant는, 다른 Tenant와의 IP 중복을 고려할 필요가 없어야 한다. (IP Overlap...)
 IP기반의 "Connectivity"는, VM-to-VM과 같은 L2통신에 의존하는 사용자를 제외 시킬 수 있다.
 TOR 스위치의 Mac Table 사이즈 한계
 Virtual Machine운영 환경에서는 Server당 100개의 Mac이 발견될 것이라 가정해야 한다.
 Rack당 24~48대의 서버가 하나의 TOR에 연결된다면, Mac Table 사이즈는 충분치 않다. (Mac Flooding)
☞ Network Virtualization

 Conventional Structure (pDC) - BasicL2L3
Host #1 Host #2 Host #3

This Domain....
- VM to VM, Direct Communication...
- Migration is working well...

Same L2 Domain....
- VM to VM, Direct Communication...
- Migration is working well...
But....

 Conventional Structure (pDC) - Working-Level
L2L3L2

L2L3L2
Local Area Network

L2L3L2
Ⅹ
Different L2 Domain....
- L3 구간에 의해 분리된 도메인...
- 서로 다른 LAN이므로, 이동(Migration) 불가...
IP to IP

 Overlay Networking
"Cloud computing and virtual machines require significantly more logical
networks than traditional data center networks, and past network
segmentation techniques such as VLANs cannot scale adequately. Several
technologies were developed to enable Layer 2 overlay networks that are
tunneled over Layer 3 for scalable cloud network architectures."
- Matt Eclavea (Senior Solutions Architect, Brocade Communications Inc.)
- Jim Allen (Senior Architect, Limelight networks)
[PDF] https://www.apricot.net/apricot2013/assets/virtualized_l2_over_l3_et-final_matt-2_1361954087.pdf

Network - Alternative
 Overlay Networking
 L2 over L3
 Network Virtualization: Scalability/Isolation
 VXLAN, OTV, MAC-VPN, NVGRE, Etc...
 VXLAN
 Mac-in-UDP (Encapsulation of L2 Frame in UDP)
 VLAN 4096 (12bit) Limited → 16,000,000 (24bit)
 Traffic Engineering (Broadcast, Mac-Flooding, Etc...)
 L2, L3가 얽힌 복잡한 구조 단순화하고, Tenant 수용력 확장.
 Linux Kernel-3.7 이후 기본 지원. 그리고 기술 표준화 진행(Draft: IETF)
 Reference Document
 EMULEX: [White Pater] VXLAN Overlay Networks: Enabling Network Scalability for a Cloud Infrastructure
 http://www.emulex.com/search/query/redirect.jsp?qid=310998&did=119463&pos=1&idx=1&fid=&pdfq=%22vxlan%22
 VXLAN Whitepaper: Advanced Server network Virtualization (NV) Acceleration for VXLAN
http://www.broadcom.com/collateral/wp/VXLAN-WP101-R.pdf

Zone #1
L2 L2
 Overlay Networking - VXLAN e.g. (Physical)

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
VTEP VTEP VTEP
VM
#3
VM
#4
VM
#1
VM
#2
vSwitch vSwitch vSwitch
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
Tenant A

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
VTEP VTEP VTEP VTEP VTEP
VM
#3
VM
#4
VM
#1
VM
#2
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
Tenant A
Tenant B

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
VTEP VTEP VTEP VTEP VTEP VTEP VTEP
VM
#3
VM
#4
VM
#1
VM
#2
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
Tenant A
Tenant B
Tenant C

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
VM
#3
VM
#4
VM
#1
VM
#2
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
Tenant A
Tenant B
Tenant C
10.10.1.024
Multicast Group #2

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
VM
#3
VM
#4
VM
#1
VM
#2
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
Tenant A
Tenant B
Tenant C
10.10.1.0/24
Multicast Group #3
10.10.1.024
Multicast Group #2

Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
VM
#3
VM
#4
VM
#1
VM
#2
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
Tenant A
Tenant B
Tenant C
10.10.1.0/24
Multicast Group #3
10.10.1.0/24
Multicast Group #1
10.10.1.024
Multicast Group #2

Zone #2
L2
56.167.43.0/27
Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
56.167.43.1
56.167.43.156
VM
#3
VM
#4
VM
#5
VM
#1
VM
#2
VTEP VTEP VTEP
VM
#6
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
VM
#5
VM
#6
VM
#6
VM
#5
vSwitch vSwitch vSwitch vSwitch
Tenant A
Tenant B
Tenant C
10.10.1.0/24
Multicast Group #3
10.10.1.0/24
Multicast Group #1
10.10.1.024
Multicast Group #2

Zone #2
L2
56.167.43.0/27
Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
56.167.43.1
56.167.43.156
VM
#3
VM
#4
VM
#5
VM
#1
VM
#2
VTEP VTEP VTEP
VM
#6
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
VM
#5
VM
#6
VM
#6
VM
#5
10.10.1.0/24
Multicast Group #3
10.10.1.0/24
Multicast Group #1
10.10.1.024
Multicast Group #2
Tenant A
Tenant B
Tenant C

Zone #2
L2
56.167.43.0/27
Zone #1
L2
132.76.58.0/24
L2
132.76.102.0/26
132.76.58.24
132.76.58.1 132.76.102.1
132.76.102.18
56.167.43.1
56.167.43.156
VM
#3
VM
#4
VM
#5
VM
#1
VM
#2
VTEP VTEP VTEP
VM
#6
VM
#1
VM
#2
VM
#3
VM
#4
VM
#4
VM
#1
VM
#2
VTEP
VM
#3
VM
#5
VM
#6
VM
#6
VM
#5
Tenant A
Tenant B
Tenant C
VR
NAT
(Note)
Public Traffic

Zone #2Zone #1
 Overlay Networking - VXLAN e.g. (Logical)
Virtualized L2 Network
10.10.1.X
10.10.1.X
10.10.1.X
VNI 1
10.10.1.1 10.10.2.2 10.10.1.3 10.10.2.4 10.10.1.5 10.10.1.6
#1 #2 #3 #4 #5 #6
10.10.1.1 10.10.1.2 10.10.1.3 10.10.1.4 10.10.1.5 10.10.1.6
VNI 2
10.10.1.1 10.10.1.2 10.10.1.3 10.10.1.4 10.10.1.5 10.10.1.6
VNI 3
#1 #2 #3 #4 #5 #6
#1 #2 #3 #4 #5 #6
Tenant A
Tenant B
Tenant C

L2L3L2

 Overlay Networking - Virtualized Subnet by VXLAN
L2

 Overlay Networking - Virtualized Subnet by VXLAN
L2
Network
Resource
Pool

 Network Pooling, Then...

vNetwork

vNetwork
vStorage

vNetwork
vStorage
vServer

Resource
Pool

Resource
Pool
Tenant A
Tenant B

Resource
Pool
Tenant A
Tenant B
Migration
or
Re-Balance

Tenant A
Tenant B

Tenant A
Tenant B
Single LAN over pDC

Tenant A's Subnet #1

Multiple Private Network
per Tenant

But,...
Very weak point
in Network Pool

Weak Point in Network Pool
사설네트워크에
속한 VM으로부
터 인터넷으로
는 어떻게?
Internet
?

One Virtual Router
per Tenant
Internet
Internal Traffic (VXLAN Encapsulation)
External Traffic (NAT, LB)

Internet
External Traffic (NAT)
One Virtual Router
per Tenant
Strange.....

Internet
External Traffic (NAT, LB)만약,
Outbound를 필
요로 하는 VM
이 많아질 때...

Internet
Outbound를 필
요로 하는 VM
증가 하는 VM들...
(Traffic)

Internet
Outbound를 필
요로 하는 VM
Crash
(Traffic)
SPOF & Bottleneck

Internet
Inbound 역시
마찬가지...
Crash
SPOF & Bottleneck
(Traffic)

Internet
Inbound &
Outbound
Crash
• 특정 물리HOST에 종속적
• High Load시, 서비스 품질 저하
• 1-Router per Private-Net(Subnet)
• 확장이 쉽지 않다.
SPOF & Bottleneck

There is no clear solution...
(in OpenStack, CloudStack...)

Some Cloud-OS Solutions...
 각 자원의 Life-Cycle을 관리/운영 할 수 있는 "Cloud-OS"라 할 수 있는 솔루션이 필요.
 직접 구축 또는, OpenSource 활용.
 대표적인 Cloud-OS Open Source
 OpenStack
 CloudStack
 OpenNebula
 Proxmox
 Eucalyptus
 각자의 Pooling, Scheduling, Life-Cycle 시스템 등을 통해, 유연한 Cloud 운영을 목표로 한다.
 단, Network모델 측면에서 외부(e.g. Internet) Traffic 대해서는 SPOF와 Bottleneck 구간이 존재하
는 취약점이 있다. (VM-to-VM간의 내부 네트워크 통신은 논외)
 현재까지의 대안들
 가상화의 특징인 '유연함'을 일부 포기하고, Physical 장비를 Gateway로 사용하는 구조가 시도 되기도 함.
 다른 대안으로 VM의 Gateway IP를 달리하여, NAT를 수행하는 Virtual Router(VR)를 다수로 분산 하는 방
안이 제시되기도 했으나, 이 역시 VM입장에서는 특정 VR에 종속(특정 VR의 IP를 Gateway로 사용)되므로,
유연성 확보가 불가능하거나, Traffic 효율성 측면에서 기존보다 더 못한 결과를 초래할 가능성이 매우 높다.
 대표적으로 OpenStack과 CloudStack을 예로, 관련된 이슈를 자세히 살펴본다.

in OpenStack
 Neutron (legacy Quantum)
 성숙도가 매우 낮으며, SDN을 표방하다 보니 여러 벤더의 H/W에 의한 종속성이 강해짐.
 여러 면에서 Issue를 가지고 있으며, 기존의 nova-network의 기능을 완전히 대체하지 못함.
 nova-network 프로젝트와 Neutron 프로젝트가 공존/혼란.
 nova-network의 한계를 극복하고자 L3-Agent, Multi-Host 와 같은 개념들이 제안/시도 되고는 있으나, 완
전히 제공되지 못하고 한계를 보이고 있는 상태.
 서로 다른 Tenant에 대해서 IP 중복사용(Overlap)을 위해, "Linux Network Namespace"를 필요로 하는데, 이
는 Network Resource 관리 복잡도가 상승과, Topology 관리/추적에 어려움을 야기시킴.
 nova-network
 모든 Tenant가 nova-network가 구동되는 단일 물리 Host를 통해 외부와 통신하는 구조.
 다 계층 네트워크 생성이 불가 (Multiple Subnet per Tenant)
 Outbound에 대해서 모든 Tenant에 대해 Gateway(NAT)역할 수행.
 Inbound에 대해, "Floating-IP"라는 개념을 이용해 Private-Net에 있는 VM을 외부로 노출.
 nova-network이 실제 Working-Level에서 성능, 안정성 측면에서 많은 이슈를 보여, Multi-Host(모든
Compute노드에 nova-network모듈을 구동)라는 것을 제안하였으나, Solution이라기 보다는 우회방안에 가
깝다. (그림 설명)
 Flat모드를 기준으로 살펴본다. (Isolation을 위해 VLAN모드가 있으나, VR관점에서는 동일)
 Reference
 https://wiki.openstack.org/wiki/UnderstandingFlatNetworking
 http://www.slideshare.net/openstack/nova-network-the-dirty-details-041613-19109553

in OpenStack (Single Host)
 nova-network Basic (Multiple NIC)
Controller
nova-network
br100
(eth0)
Compute
nova-compute
br100
(eth0)
Compute
nova-compute
br100
(eth0)
Virtual Network (e.g. 10.0.0.0/8)
eth1 eth1 eth1
Physical Network (e.g. 222.122.156.0/24)

in OpenStack (Single Host)
 nova-network Basic (Multiple NIC)
Controller
nova-network
br100
(eth0)
Compute
nova-compute
br100
(eth0)
Compute
nova-compute
br100
(eth0)
eth1 eth1 eth1
SPOF &
Bottleneck

in OpenStack (Multiple Host)
 Alternative: Multiple nova-network (per Compute Host)
Compute
nova-compute
Compute
nova-compute
eth1 eth1
nova-network nova-network
br100
(eth0)
br100
(eth0)

Compute
nova-compute
Compute
nova-compute
br100
(eth0)
br100
(eth0)
eth1 eth1
10.0.0.3
10.0.0.11
(GW: 10.0.0.3)
10.0.0.4
10.0.0.12
(GW: 10.0.0.4)

Compute
nova-compute
Compute
nova-compute
br100
(eth0)
br100
(eth0)
10.0.0.3
10.0.0.11
(GW: 10.0.0.3)
10.0.0.4
10.0.0.12
(GW: 10.0.0.4)
eth1 eth1

Compute
nova-compute
Compute
nova-compute
br100
(eth0)
br100
(eth0)
10.0.0.3
10.0.0.11
(GW: 10.0.0.3)
10.0.0.4
10.0.0.12
(GW: 10.0.0.4)
eth1 eth1
but,....

Compute
nova-compute
Compute
nova-compute
br100
(eth0)
br100
(eth0)
10.0.0.3 10.0.0.11
(GW: 10.0.0.3)
10.0.0.4
10.0.0.12
(GW: 10.0.0.4)
eth1 eth1

Compute
nova-compute
Compute
nova-compute
br100
(eth0)
br100
(eth0)
10.0.0.3 10.0.0.11
(GW: 10.0.0.3)
10.0.0.4
10.0.0.12
(GW: 10.0.0.4)
eth1 eth1
!!............

in CloudStack
 CloudStack에서는 RVM(Router Virtual Machine) 구조를 가진다.
 각 Tenant마다 독립적인 Kernel Stack 및 Network Stack가지는 Gateway를 할당.
 nova-network보다는 유연하나, 여전히 SPOF 및 Bottleneck 이슈는 동일.

Host Host Host
vnbr1002
(eth0)
vnbr1002
(eth0)
vnbr1002
(eth0)
in CloudStack
vnbr1001
(eth0)
vnbr1001
(eth0)
vnbr1001
(eth0)
Tenant-A Virtual Network (e.g. 10.0.0.0/8)
eth1 eth1 eth1
Tenant-B Virtual Network (e.g. 10.0.0.0/8)
Tenant-A's VR
(10.0.0.1)
Tenant-B's VR
(10.0.0.1)
A B BA
Tenant B
Tenant A

Host Host Host
vnbr1002
(eth0)
vnbr1002
(eth0)
vnbr1002
(eth0)
in CloudStack
vnbr1001
(eth0)
vnbr1001
(eth0)
vnbr1001
(eth0)
Tenant-A Virtual Network (e.g. 10.0.0.0/8)
eth1 eth1 eth1
Tenant-B Virtual Network (e.g. 10.0.0.0/8)
Tenant-A's VR
(10.0.0.1)
Tenant-B's VR
(10.0.0.1)
A B BA
One VR per Tenant..
But, Still SPOF & Bottleneck
Tenant B
Tenant A

Solution of VR's SPOF & Bottleneck
 VR 모델 개선 요구사항
 OpenStack의 nova-network모델보다 CloudStack의 RVM모델이 적합.
 Tenant당 RVM을 둔다는 의미는, 독립적인 Kernel Stack 또는 Network Stack을 둔다는 의미로서, 모든
Tenant에 대해서 하나의 Stack으로 처리하는 nova-network모델보다 훨씬 유연한 대응이 가능.
 VR의 SPOF 제거를 위한 Gateway의 분산&클러스터링 방안 필요.
 여러 물리 Host에 동일한 역할을 수행하는 VR들의 운영이 가능해야 한다.
 담당 도메인내의 VM들에 대해서는, VR의 Gateway주소가 동일하며 유일해야 한다. (VRs 식별 불가)
 DHCP기능 분산&클러스터링.
 반드시 모든 물리 Host에 VR이 존재해야 하는 것은 아니다. 외부와의 Traffic Load를 처리하는데 충분
하게끔 언제든지 확장 가능한 구조를 가지는 것이 중요한 핵심이다.
 Traffic Engineering
 Broadcast 및 In/Out에 대한 Traffic 경로 최적화
 HA, LB 및 Failover 지원.
 동일 Gateway역할을 수행하는 VR들이 분산 가동되므로, 당연히 일부에 문제가 생겨도, VM들의 외부
Traffic 경로에는 문제가 없어야 한다.
 분산&클러스터링 VR시스템으로서, 외부로부터의 요청에 대해 효과적인 LB 지원해야 한다.
 VM입장에서는 로컬 VR이 최우선순위로 Gateway로 사용하겠지만, 어떠한 VR을 Gateway삼더라도 통
신에 문제가 없어야 한다.

Host Host Host
br-B br-B br-Bbr-A br-A br-A
Private-NET A
Private-NET B
A B BA A AB
Tenant B
Tenant A

Host Host Host
Private-NET A
Private-NET B
A B BA A AB
10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1
Tenant B
Tenant A

Host Host Host
Private-NET A
Private-NET B
A B BA A AB
10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1
GW: 10.0.0.1 GW: 10.0.0.1 GW: 10.0.0.1 GW: 10.0.0.1GW: 10.0.0.1 GW: 10.0.0.1
Tenant B
Tenant A

Host
Host Host
Private-NET A
Private-NET B
A B BA A AB
Selective
10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1
GW: 10.0.0.1 GW: 10.0.0.1 GW: 10.0.0.1 GW: 10.0.0.1GW: 10.0.0.1 GW: 10.0.0.1
Tenant B
Tenant A

Host
Host Host
Private-NET A
Private-NET B
A B BA
A
AB
Selective
10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1
GW: 10.0.0.1 GW: 10.0.0.1
GW: 10.0.0.1
GW: 10.0.0.1GW: 10.0.0.1 GW: 10.0.0.1
Tenant B
Tenant A

Host
Host Host
Private-NET A
Private-NET B
A B BA
A
AB
Selective
10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1
GW: 10.0.0.1 GW: 10.0.0.1
GW: 10.0.0.1
GW: 10.0.0.1GW: 10.0.0.1 GW: 10.0.0.1
Tenant B
Tenant A
X

Host
Host Host
Private-NET A
Private-NET B
A B BA
A
AB
Selective
10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1 10.0.0.1
GW: 10.0.0.1 GW: 10.0.0.1
GW: 10.0.0.1
GW: 10.0.0.1GW: 10.0.0.1 GW: 10.0.0.1
Tenant B
Tenant A
Reasonable

EYWA is(Elastic load-balancing & high-availabilitY Wired network Architecture)
Alternative

Features of EYWA
 Performance
 Load-Balancing by Multiple VR (No-limit)
 High Availability
 HA by Multiple VR (No limit)
 Traffic Engineering
 Save of Network Bandwidth
 Traffic Isolation by VXLAN (16,777,216)
 Multicast instead of Broadcast
 Decrease in Packet Floods
 Flat Address
 Multiple Gateway for Load-Balancer of Inbound & Outbound Traffic
 Cost
 Multiple VR instead of L4 Switch (Single Router)
 Scalable VR
 Demo Video (YouTube)
 http://www.youtube.com/watch?v=FsXDuiWqmJk

Demo Video http://www.youtube.com/watch?v=FsXDuiWqmJk

Summary
 vDCaaS
 All Resource of Datacenter is virtualized
 Resource, Dynamic Provisioning (On-Demand)
 User-Side, DIY (Self-Service & Self-Configuration)
 DC Resources
 Server: Standardization, High & Steady Performance for High-Density VM, Full/Para
 Storage: Shared, Replication, HA/DR, per certain scale, High IOPS, Low Latency
 Network: Multi-Tenant, Isolation, Dynamic, Wide-L2, Traffic Engineering
 Scheduler for Place/Re-Place/Failover/Etc…
 Solutions
 Local Experience & Know-how (Mandatory)
 Server: KVM, Self-Designed Chassis, 10Gbps
 Storage: GlusterFS, Sheepdog
 Network: VXLAN, EYWA, vRVM Based Networking Model

About vDCaaS
 Traditional Datacenter
전력
UPS
냉방
공조
관제
알람
엔지
니어
공간
서버
네트
워크
스토
리지

About vDCaaS
 DCaaS
공간
서버
네트
워크
스토
리지

About vDCaaS
 vDCaaS
공간
서버
네트
워크
스토
리지
Scale-In/Out
Scale-In/Out

About vDCaaS
 vDCaaS
 "Cloud Co-Location Service"
 in Datacenter Level, On-Demand & Self-Service
 Immediacy, Effectiveness, Flexibility
DCaaS

About vDCaaS
 vDCaaS
DCaaS
IaaS
PaaS
SaaS

About vDCaaS
 vDCaaS
vDCaaS
PaaS
SaaS
IaaS

About vDCaaS
 vDCaaS
by Virtualization
vDCaaS
IaaS
PaaS
SaaS

About vDCaaS
 vDCaaS
vDCaaS
PaaS
SaaS
IaaS
by Virtualization
진부하지만,,,,
실행하기는....

Virtual Data Center (vDC)
 Block Diagram
pRack
pServer pServer
pSwitch
Physical
pSpace

Virtual Data Center
 Block Diagram
pRack
pServer pServer
pSwitch
Physical
pSpace
Traditional
DC

 Block Diagram
pRack
pServer pServer
pSwitch
vSwitch vSwitch
VMVMVM VMVMVM
Physical
Virtual
pSpace
vServer

 Block Diagram
pRack
pServer pServer
pSwitch
vSwitch vSwitch
VMVMVM VMVMVM
Physical
Virtual
pSpace
vRack
vServer

pRack
pServer pServer
pSwitch
vSwitch vSwitch
VMVMVM VMVMVM
 Block Diagram
Physical
Virtual
pSpace
vRack
vDC
vServer

pSpace
Physical Rack
Physical Server Physical Server
Physical Switch
vSwitch vSwitch
VMVMVM VMVMVM
pRack
pServer pServer
pSwitch
vSwitch vSwitch
VMVMVM VMVMVM
 Block Diagram
Physical
Virtual
vRack
vDC
vServer

pSpace
Physical Rack
Physical Switch
vSwitch vSwitch
VMVMVM VMVMVM
Physical Rack
Physical Switch
vSwitch vSwitch
VMVMVM VMVMVM
pRack
pServer pServer
pSwitch
vSwitch vSwitch
VMVMVM VMVMVM
 Block Diagram
Physical
Virtual
vRack
vDC
vServer
Virtual Multi-DC

Storage - Appendix
 Storage Tiering
Required
High I/O?
I/O Request
Yes No
Tier-1
Tier-2
High Cost per Byte
Low Cost per Byte

Storage - Appendix
 Storage Tiering
Required
High I/O?
I/O Request
Yes No
Tier-1
Tier-2
Ideal...
High Cost per Byte
Low Cost per Byte

Scheduler for vDC
 Scheduler
 정교한 Monitoring 시스템 확보 선행.
”측정되지 않는 것은, 관리 될 수 없다."
 유연한 Resource Pool 확보 선행.
 배치/재배치 및 장애극복 알고리즘.
 가상화/추상화된 자원들의 Life-Cycle을 관리.
 Scheduler 고도화에 필수적인 경험적 노하우 축적.
 특화된 Scheduler 템플릿 제공 가능. (서비스 특성을 반영, 사용자 선택적)
 Performance
 Stability
 Cost
 경험과 노하우 축적 → vDC 운영의 핵심 자산(Technical Asset)

Virtualized Datacenter as a Service (vDCaaS)

Recommended

Recommended

More Related Content

More from JungIn Jung

More from JungIn Jung (9)

Virtualized Datacenter as a Service (vDCaaS)