Cloud datacenter network architecture (2014)

클라우드 데이터센터 네트워크 아키텍처
2014.12
2014년 문서로 현재에 유효하지 않는 내용이 있어 이점에
대해서 인지하고 보시기 바랍니다.

Cisco Massively Scalable Data Center Design (MSDC)
MSDC Scale Characteristics : 클라우드 환경의 대규모 데이터 센터의 특징
[ 특징/요인 ] [ 기존 데이터센터 디자인과 MSDC와의 차이 ]
1) Commoditization
리소스(CPU,RAM 등) 조립, 분할이 용이
2) Cloud Networking
컴퓨트, 메모리, 스토리지의 사용량(Utilization)의 효율적
사용 [하단 그림 참고]
3) Operations and Management (OaM)
4) Scalability
애플리케이션 확장에 용이한 수용 처리
5) Predictability
간단하고 단순하며, 모듈화 구성을 통하여 IT 인프라에 예
측 가능 요구됨 (Latency 등)
[그림1] 클라우드 최적화의 장점
1) Fault Tolerance vs Fault Avoidance
⚫ 기존DC : Fault Avoidance(장애 예방)에 중점을 두어,
라인카드/Sup이중화 및 Link 이중화 등 구성하며,
Fault Tolerance(장애 극복) 기능을 구현
⚫ MSDC : 장애 예방 구현 시 과다 비용 발생하며, 장애
발생 시 다른 공간에 복제 등을 통한 장애 극복으로 처
리
2) MSDC Scale (일반적인 규모)
⚫ 250,000이상 서버, 800이상 네트워크, 24,000 P2P 링크
⚫ 10~수천 대 이상 컴퓨트, 메모리, 스토리지 리소스
3) Churn = Network flux
⚫ 다양한 장애 발생 시에도 안정적인 라우팅 환경 제공
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/MSDC/1-0/MSDC_Phase1.pdf

I. Traditional Data Center Design Overview (1/2)
[ 기존 데이터센터 구성 ]
[그림2] 전통 데이터센터 네트워크 구성도
1) Operational complexity
운영 복잡
2) Configuration complexity
설정/구성 복잡
3) Cost of Redundant Hardware
중복 하드웨어 구매 비용
4) Inefficient use of bandwidth
비효율적인 링크 대역폭 사용
⚫ 3Tier 구조이며, Core-Dist-Agg(Accee 포함)
⚫ 장애극복 디자인 (이중화)
▪ STP로 50% 이하 링크 사용, VRRP로 1대 라우터 사용
▪ 장애 극복 구현을 위한 Network Infra의 50%만 실제 사용
⚫ 위 구성을 위한 실 사용에 비한 과다 비용 필요
⚫ East-West 트래픽 처리에 용이하지 않음
[ 단점 ]
다수
트래픽
Flow

I. Traditional Data Center Design Overview (2/2)
[ Evolution, From the Field ] [ 3-Stage Folded Clos Topology ]
다수 트래픽 Flow
⚫ 3Tier 구조 혹은 2Tier 구조(Spine, Leaf)
⚫ East-West 트래픽 처리 극대화 = ECMP 사용
⚫ Clos Design (Full Mesh, 1:1 oversubscription, ECMP)
⚫ 서버 - Acc – Agg – Dis – Core : 전 구간 Active-Active 사용
⚫ Spine Node 1개 장애 발생 시 전체
적인 트래픽 처리에 큰 영향 없음
⚫ Leaf 장비는 보통 ToR 스위치

II. Design Goals
[ Design Tenets ] [ Customer Architectural Motivations ]
1) Cost
네트워크 인프라에서 절감 필요
(예를 틀어 서버의 NIC1개 절감 시 $1M 절약)
2) Power
저전력 구성 고려
3) East-West BW
데이터센터의 트래픽의 80%가 East-West 트래픽 [1]
Cisco Global Cloud Index 에서 76% 가 E-W 트래픽 [2]
1개 트래픽 인입 시 backend 에서 100개 transactions
4) Transparency
East-West 간 통신 시 용이하게 Overlay 등 구성 필요
5) Homogeneity
단순 운영이 아닌 확장 시 표준화/모듈화를 통한 Scale
6) Multi-pathing
fault 최적화를 위한 ECMP 구성
7) Control
프로그래머빌리티, 자동화, 모니터링을 통한 운영/관리
[1] Source : Gartnet – Synergy Research Gruop [2] http://blogs.cisco.com/security/trends-in-data-center-security-part-1-traffic-trends
⚫ 기존 데이터 센터의 경우 single node 가 fail 시
50%의 처리 성능 저하 발생
⚫ MSDC 경우 1개 node 가 fail 시 처리 성능 저하
가 최소화됨 (ECMP, Full Mesh)
⚫ 라우팅 프로토콜을 통하여 장애 발생 시에도 안
정적인 라우팅 테이블 유지가 필요함
[ Top of Mind Concerns ]
1) Operations and Management
무엇보다 운영/관리가 중요함, 배포 자동화, 관리 시간 절
약, 더 뛰어난 가시성/모니터링 확보, 휴먼 에러 최소화
2) Scalability
MSDC도 Churn 네트워크 관리에 확장성에 제한
3) Predictability
초 저 지연 확보, IT인프라 예측 가능 필요

III. Reference Topologies and Network Components (1/8) : 테스트 및 예제 구성 소개
Building Blocks
[ Building Blocks ]
⚫ 모든 leaf SW 연결됨, P2P Links 연결 및
Loopback 을 통한 라우팅 정보 교환
⚫ 일반적으로 Spine은 외부와 연결되지 않음
⚫ 단, 일부 외부 연결된 Border leaf SWs가 Spine과
연결되고 Border leaf 가 default route 전달광고
⚫ 예) N7K F2는 48x10G, 저전력, 초 저 지원, 큰 버
버 지원
⚫ Building Blocks는 효율적 비용, 저전력, Simpler,
프로그래머블, multipath(HW/SW) 만족해야함
⚫ 3개 Area : Leaf layer, Spine layer, Fib
[ leaf layer ]
⚫ 일반적은 ToR SW, 서버들이 연결되는 SW
⚫ 서버들의 Subnet 을 광고함 (L3 구성 시)
⚫ oversubscription ratios 로 spine 갯수 결정됨
⚫ 예) Nexus3064는 64x10G, 64-way ECMP 지원
[ Spine layer ]
[Fib ]
⚫ 대규모의 Network 처리를 위한 FIB 관리 필요
⚫ 서버네트워크, P2P, Loopback 및 Cloud-aware,
virtual-aware 처리를 위한 네트워크 등 기존 데
이터센터 네트워크 갯수에 비해 폭발적인 네트워
크 처리 필요
⚫ 관리전략1 : 고객 네트워크(end-host 서브넷)와
인프라 네트워크 분리(P2P, Loopback)
⚫ 관리전략2 : 물리적 활성화 링크에 포함된 네트
워크만 관리(?)
FIB : RIB중 실제 Forwarding 사용되는 정보

Interconnecting Building Blocks
[ Traditional Tree Hierarchy ]
[ Oversubscription Scenario ]
⚫ aggregation pairs(AGGs) 세트 형태(ToR SW)
⚫ 대역폭이 상단으로 갈 수록 집중
⚫ non-blocking/oversubscription 지원에 어려움
⚫ 24개 서버가 Acc 장비에 연결
⚫ Acc는 최소 240G port capa 필요
⚫ Uplink 2개 10G 경우 12:1
oversubscription
⚫ 트래픽 집중 발생 시 문제 발생
⚫ 애플리케이션에 따른 적절한
oversubscription ratio 선정 필요

[ Traditional Tree Hierarchy ]
⚫ Red(SrvA->SrvZ), Green 트래픽
동시 발생 시 12:1
oversubscription 으로 인해 DIS
layer 에서 Queue 혼잡으로 Red
트래픽은 Blocking 됨
⚫ DIS 장비는 수테라 트래픽을 COR
layer 로 전달
⚫ 해결책으로는 Srv에서 10G의 8%
정도만 트래픽 발생
⚫ 망 확장 시 더 많은 트래픽 부하
및 복잡, 포트 Queue 관리 필요
⚫ East-West 트래픽 처리 어려움
[ Blocking Scenario ]

[ Clos Topology ]
⚫ 6-port Switch 사용 시
⚫ num(edgeport) = k(h-1)/(h-1)
⚫ k = total edge node
⚫ h = number of stages
⚫ 18=6(3-1)/3-1
[ 3-Stage Clos ]
⚫ 1953, Charles Clos 토폴로지 이론,
⚫ Non-blocking, multi-stage topology
⚫ 3-Stage Clos Fabric > Folded Clos Fabric 가 좀 더 효율적 형태

[ Clos Topology ]
[ 5-Stage Clos ]

[ Fat Tree Fabric ]
⚫ 각 Layer 에 Device 를 동일하게 배치
⚫ 가장 극대화된 트래픽 처리, 장비/케이블링 비용 증가 발생

[ Other Topologies ]
⚫ 4 port building-block (20 boxes, 32 links)
[ Bene Network Fabric ]
[ Hypercube Network Fabric ]
[ 3D Toroid ]
⚫ N-S 처리 힘듬, E-W 처리 효율적 토폴로지

How a Clos Architecture Addresses Customer Concerns
[ SDU MSDC Test Topology ]
⚫ Spine : N7K(F2), 16개
⚫ Leaf : N3K, 16개, 16개 ECMP(64개 가능)
⚫ Boarder Leaf : 외부 인터넷 연결 구간
⚫ Cost
⚫ Power
⚫ East-West BW : Spine
2.5Tbps , Leaf
160Gbps 처리
⚫ Transparency : 오버레
이 네트워킹
⚫ Homogeneity : 장비
표준화
⚫ Multipathing
⚫ Control : 배포(PoAP),
모니터링

Arista cloud network scalability
Arista 클라우드 네트워킹 확장 소개
[ Key Points ] [ 장비 ]
Arista 7250X, 7300 and 7500 Series
1) No proprietary protocols or vendor lock-ins
표준 프로토콜 사용, 벤더 종속 되지 않음
2) Fewer Tiers is better than More Tiers
Tier 를 적게 구성 시 절감(비용, 복잡도, 케이블링, 파워/
난방)
3) No protocol religion
Scale-out 디자인 제공, L2/L3 or Hybrid L2/L3, 표준
VXLAN(L2/L3) 지원
4) Modern infrastructure should be run A/A
Layer2 환경에서 MLAG 와 Layer3 환경에서 ECMP 기능
으로 any devices 에서 모든 포트가 Active/Active 동작
5) Designs should be agile and allow for flexibility
in port speeds
서버 NIC의 1G/10G는 2013-2015 현재 사용
이후에는 10G/40G/100G NIC로 예측
6) Scale-out designs
ECMP 기능 제공(2way/4/8/16/32way)
7) Large Buffers can be important
scale-out 스토리지 arrays 는 NIC의 기술 요구되어짐
TCP Segmentation offload(TSO), GSO(generic
segmentation offload), LSO(Large Segment Offload)
이 기술은 CPU의 부하(Segmant, CheckSum)를 NIC 단에
서 처리
8) Consistent features and OS
Arista 의 모든 장비간 동일 EOS 사용으로 일관성
9) Interoperability
호환성이 뛰어남
http://www.nvc.co.jp/pdf/product/arista/Cloud_Networking__Scaling_Out_Data_Center_Networks.pdf

Spline 디자인 소개, Spine Leaf(L2/MLAG) 디자인 소개
[ Spline Network Design ] [SPINE/LEAF NETWORK DESIGNS, L2/MLAG ]
• Spine for Storage and HPC
• High Performance
• Investment Protection
• Linear Scale
• 100 - 1,000 Servers
• single spline 구조
• 가장 저 비용의 capex/opex 제공 (장비간 인터링크
없음)
• Arista 7300/7250X/7050X 경우 104~2048x10G 포
트를 제공
• MLAG Spine Scale out
• 100 – 10,000 Servers
• MLAG, L3 Gateway(AnyCast)를 이용한 A-A 구성
• Spine과 Leaf 간 2계층 관계, 확장성 제공(1개 Spine,
다수 Leaf SW)
• Leaf SW에 96x10G port(서버 등)과 8x40G 업링크
형태 권장
• 위 구성 시 oversubscribed ratio는 3:1
• Spine 2~64개, Leaf 72~512개, 서버포트
3456~393,216개 제공 가능
확장

Layer3/ECMP, L2 over Layer 3 VXLAN 구성
[ Layer3 / ECMP ] [ L2 over Layer 3 VXLAN ]
• ECMP Spine Scale out
• Simple, Open
• Network Wide Scale
• 100 – 100,000 Servers
• 앞장의 Layer2 / MLAG 와 물리적 구성은 동일하나
상단/하단SW간 Layer3 구성
• VLAN 제약과 MAC address Mobility 제약 조건
• ECMP Spine Scale out
• Simple, Open
• Network Wide Scale
• 100 – 100,000 Servers
• 왼쪽의 Layer3 / ECMP와 물리적 구성은 동일하나
상단/하단SW간 Layer3 구성에 Overlay VXLAN 구
성
• VLAN limit 해결, MAC address Mobility 가능
• VXLAN 처리 필요(Hardware, Software)

확장성 시 고려사항
[ Design Considerations for LEAF/SPINE NETWORK DESIGNS ]
• 다수의 Tier 경우 확장성을 가져가지만, 복잡성, 비용
등 단점도 가져감
• 적정한 Tier 구조 설계가 필요
[ Oversubscription ]
• legacy DC large oversubscription 20:1 가지기도 함
• Multi-core CPUs, 서버 가상화, flash 스토리지, 빅데
이터, 클라우드 컴퓨팅 환경에서는 lower
oversubscription 필요(3:1 , 1:1 요구 필요)
• Leaf SW 3:1 oversubscription (48x10G down to
4x40G up)
[ Two-Tier SPINE/LEAF scale-out over TIME ]
• 처음 구성 시 Spine 의 1개 라인카드로 Leaf SW들을
수용
• 확장 시 Spine에 2번째 라인카드 장착 후 Leaf 연결

네트워킹 선택 시 고려사항(L2, L3, Overlay)
[ layer2 or layer 3 or layer underlay with vxlan overlay ]
[ Layer2 or Layer3 ]
• Layer2 경우 유연한 VLAN 구조를 가지며,
MAC 주소 마이그레이션 시 통신 용이 구조
• Layer2 단점은 mac tables size 제한(저 성능
SW) 및 STP 구조로 장애 발생 시 느린 컨버전
스 타임
• Layer3 는 빠른 컨버전스 타임과 MLAG 및
ECMP를 통한 non-blocking 환경 지원
• Layer3 단점은 MAC 이동성 제한, VLAN 정보
제한
• Layer2 네트워크 문제(큰 브로드캐스트 도메인,
장애 처리 어려움, STP로 인한 Control-plane
CPU 부하). STP는 'fail open' 이 아니라 'fail
closed', 만약 STP에 문제 발생 시 루핑 발생.
[ Layer 3 underlay with vxlan overlay ]
• VXLAN은 Layer3를 통하여 Layer2 통신환경으로 Layer3 단점을 보안함
• Layer2 장점인 VLAN/MAC 이동성과 Layer3 장점인 확장/Scale 네트워크, 빠른 컨버전스 타임을 동시 제공
• VXLAN을 소트웨어처리가 아닌 하드웨어 처리를 권장

Forwarding Table 고려 사항
[ Forwarding Table sizes ]
• 이너넷SW ASIC은 전달 결정에 3가지
방법을 사용
• MAC tables (L2), Host Route tables
(L3) and Longest Prefix Match (LPM)
for L3 prefix lookups
• NW 최대 사이즈는 L2 or L3 tables 의
크기와 관계됨
• 과거 서버는 1개 NIC에 1개 IP와 1개
MAC을 가지지만, 현재 가상화 환경에
서는 서버에 여러개 NIC에 여러개 IP
와 여러게 MAC 가짐
• Layer2는 GW를 통하여 외부 통신하며,
Layer3는 모든 route prefix를 처리
• VMs 갯수가 networking
table sizes
[ Forwarding Table 특징 L2/L3 디자인 ]

ARISTA TWO-TIER SPINE/LEAF SCALE-OUT DESIGNS
• 각 Leaf는 모든 Spine에 연결됨
• L2 or L3(좀 더 Scale)구성 가능
• Leaf – (MLAG) – Spine : A-A
• 13824대 x 1G = 서버 NIC 연결
• Leaf = 288대
• Spine = 2대
• Oversubscribed 1.2:1(48G:40G)
• Leaf = 72대
• Spine = 2대
• Oversubscription3:1(480G:160G)
• Leaf = 36대
• Spine = 2대
• Non-Oversubscription (320G)
[설명은 왼쪽 구성 기준]

ARISTA LARGE-SCALE SPINE/LEAF DESIGNS UPLINK(10G)
• 6912대 x 10G = 서버NIC 연결
• Leaf = 144대
• Spine = 4대
• Oversubscribed 3:1(480G:160G)
• ECMP = 4way
• Spine 의 확장, L3라우팅(ECMP)
• Leaf = 288대
• Spine = 8대
• ECMP = 8way
• Leaf = 576대
• Spine = 16대
• ECMP = 16way
• Leaf = 576대
• Spine = 4대
• Oversubscribed 1.2:1(48G:40G)

• Leaf = 72대
• Spine = 4대
• Non-oversubscribed 1:1(320G)
• ECMP = 4way
• non-oversubscribed 디자인
• Leaf = 144대
• Spine = 8대
• ECMP = 8way
• Leaf = 288대
• Spine = 16대
• ECMP = 16way
• Leaf = 576대
• Spine = 32대
• ECMP = 32way

• Leaf = 144대
• Spine = 4대
• oversubscribed 3:1(480G:160G)
• ECMP = 4way
[ Arista Features]
1) MLAG (Multi chassis Link AGGregation)
✓ L2 환경에서 2대 이상의 스위치 링크가
Active/Active 로 동작(L3 Anycast GW)
2) ZTP (Zero Touch Provisioning)
✓ 장비 기동시 오토 프로비즈닝 제공
✓ 반복 작업에 대한 자동화 및 병렬화 가능
3) VM TRACER
✓ VM(ESX서버, VM호스트)의 실시간 트랙킹
✓ VM호스트가 vMotion 시 해당 VLAN 정보를 자
동 생성/삭제(zero config on switch)
4) VXLAN
5) LANZ
✓ 사전에 버퍼의 용량과 패킷 드랍을 모니터링
✓ 이에 따른 영향을 사전 모니터링
6) ARISTA EAPI
✓ eAPI가 제공되어 EOS에 프로그래밍 구현 가능
7) OPENWORKLOAD
✓ 다양한 오케스트레이션 시스템과 연동
✓ SDN 컨트롤러와 연동
8) SSU (SMART SYSTEM UPGRADE)
✓ 업그레이드/패치 작업 시 최소 중단 작업 가능
9) NETWORK TELEMETRY
✓ Network Telemetry 빠른 장애 처리를 도우며, 다
양한 모니터링 App(Splunk, ExtraHop, Corvil,
Reverbed)과 연동하며 가시성 확보
10) OPENFLOW AND DIRECTFLOW
✓ Arista EOS 는 OpenFlow 지원
✓ 컨트롤러없이 트래픽 경로 지정 가능(DirectFlow)

Cloud datacenter network architecture (2014)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cloud datacenter network architecture (2014)

Similar to Cloud datacenter network architecture (2014) (20)

More from Gasida Seo

More from Gasida Seo (6)

Recently uploaded

Recently uploaded (8)

Cloud datacenter network architecture (2014)