클라우드데이터센터네트워크아키텍처(20141202)

클라우드 데이터센터

네트워크 아키텍처

KrDAG

[email protected]

2014.12

mailto:[email protected]

http://sola99.tistory.com

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)

• 3456대 x 10G = 서버 NIC 연결 • Leaf = 72대 • Spine = 2대 • Oversubscription3:1(480G:160G)

• 1152대 x 10G = 서버 NIC 연결 • 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)



• 27648대 x 1G = 서버NIC 연결 • Leaf = 576대 • Spine = 4대 • Oversubscribed 1.2:1(48G:40G)




• 2304대 x 10G = 서버NIC 연결 • Leaf = 72대 • Spine = 4대 • Non-oversubscribed 1:1(320G) • ECMP = 4way

• non-oversubscribed 디자인







• 6912대 x 10G = 서버NIC 연결 • 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)

클라우드데이터센터네트워크아키텍처(20141202)

Internet

Transcript of 클라우드데이터센터네트워크아키텍처(20141202)