#5 Datacenter Networking

DC 네트워킹과 인터넷은 차이가 있다.

 

density, bandwidth, connectivity의 복잡성은 인터넷보다 더한 것은 쉽게 예상할 수 있다.

시스템을 벗어나더라도 인근의 서버를 건들일 일이 빈번하다.

자기들간의 communication이 많다.

바로 옆의 서버와의 통신이 optimize되어야 한다.

 

서버 차원에서는 NIC 카드 많이 꽂고 선 많이 연결하면 되겠지만 이를 어떻게 cost effective하게 하는가가 문제일 것이다.

모든 도로를 8차선으로 뚫을 필요가 없듯이 어떻게 최적화하여 연결하는가

 

네트워킹 종류

CPU가 또다른 CPU를

GPU가 또다른 GPU를

CPU가 원격에 있는 SSD를

 

DMA를 가능하게 하는 가장 기본적인 기술 Memory Mapped IO

Virtual - Physical Mapping 내에서 DRAM으로 매핑되는 것이 아닌 IO device로 매핑이 되도록 하는 것

해당 방식으로 access하면 IO 장치의 특정 바이트를 읽거나 특정 동작을 트리거할 수 있다.

 

TX / RX overview -> 슬라이드 참고

 

Interrupt Optimization

Option 1 : single core

Option 2 : all core

Option 3 : send to core running app waiting for data

 

1 -> 2 -> 3 순서로 발전

대형 데이터센터 처리한다고 하면 아무 전제 없으면 3으로, 긴 워크로드로 bottleneck이 생기면 2로, 특수하게 real-time에 맞춰서 처리해야 할 것이 있다면 1로

각자 쓰임새가 다 있다.

 

Direct Cache Access

데이타가 올 때 네트워크 카드가 DRAM에 데이터를 넣는 것이 아닌 cache에다가 직접 적재하는 것

default로 on (intel)

workload traffic이 높아지면 performance가 unpredictable해지기 때문에 control을 원한다면 끄는 것을 추천

cache에 과적재, 또는 cache에 적재할 내용을 HW가 select하기 때문

 

Direct User Access

Zero-Copy하고도 일맥상통하는 내용

TX/RX 준비와 실시간 read/write

준비는 OS에서 하되, read/write가 일어날 때는 user level에서 직접 처리하도록

device driver가 부팅을 할 때, NIC 카드를 가상화, 특정 app이 사용할 때 가상 NIC 카드를 할당

보안을 위한 isolation

---

이제 middle point는 어떻게 처리되는지를 살펴보자.

 

한 end point에서 다른 end point로 정보를 보낸다고 하면 중간에 연결이 있어야 한다.

가장 무식한 방법으로 crossbar switch를 생각할 수 있다.

보내는 사람과 받는 사람간 모든 연결 point를 만드는 것 (N^2개의 node 필요)

 

구글의 2004년 디자인

ToR (Top of Rack) switch

Rack이 여러개 모여서 Point of Deployment가 된다.

PoD 내에서 Rack간 연결은 각 rack을 router에 연결

Rack -> Router -> Rack으로 연결된다.

Router를 몇 개 둘지는 workload에 따라서 결정된다.

 

또한 router 간에도 회선을 두는데 이는 장애시 fail-safe(redundancy)하게 만들기 위함이다.

물론 이를 활용해 load balancing도 할 수 있다.

보내는 rack입장에서는 1차적으로 보낼 router에서 목표 rack으로의 문제가 있을지 알 수 없다.

만약 문제 report를 하는 방식으로 설계된다면 그만큼의 비효율성이 발생한다.

때문에 만약 side link가 없다면 목표 rack까지 router가 취할 수 있는 경로는 1개 밖에 없어지므로 side link를 두는 것이다.

a로부터 b를 연결하는 경로가 여러개 -> 루프가 생긴다.

ARP 같은 프로토콜은 루프를 돌기에 이를 막기 위한 설계도 필요하다.

 

다른 구조로는 tree 구조를 들 수 있다.

hop 수가 달라진다.

a to b 임의의 연결은 위는 2 hop만에 갈 수 있는데 비해 tree는 최대 hop이 2 * depth가 된다.

그럼에도 tree를 쓰는 것은 확장성이 좋기 때문이다.

 

단위 unit 내에선 구글 structure가 좋을 수 있다.

2 layer를 뒀던 것은 너무 많은 연결을 피하기 위함

문제는 상위 layer 숫자가 늘어나면 그 node 사이 연결도 너무 많아진다.

그러면 또 상위 layer를 추가해서 연결 숫자를 줄이는 것이다.

이런식으로 상위 node까지 타고 올라가는 것

 

구글 배선과 tree 구조의 차이는

같은 layer내에서 더 많은 connectivity를 가지고 연결할 것인지, 아니면 상위 switch를 두어 연결할 것인지의 차이다.

 

FAT Tree

일반적인 트리 구조와의 차이는 상위 레벨로 갈 수록 연결하는 회선의 bandwidth가 증가한다는 것이다.

이렇게 하는 이유는 상위 레벨로 갈 수록 데이터 교환양이 집적되어 이를 support할 수 있어야 하기 때문이다.

데이터센터에서 선택할 수 있는 가장 무난한 연결 방식이다.

 

Clos Network

FAT Tree와 Clos는 반절 접으면 본질적으로 같다.

 

Pod에서 가장 처음 만나게 되는 상위 layer는 edge

그 내부에서 east-west traffic이 많은 경우 edge만으로는 감당이 안되는 경우가 있기 때문에 그 상위 layer인 aggregation을 둔다. 숫자와 성능은 workload에 따라 달라진다.

각 Pod cluster를 엮는 core가 최상단에 위치한다.

 

요새 추세는 스위치가 워낙 좋아져서 Pod 내에서는 1 layer로 가는 것이 일반적이다.

 

모두 같은 스위치를 쓴다고 했을 때 (k-port switch, 2 layer), 한 pod 당 (k/2)^2개의 connection이 올라온다.

최상위 단계에서 볼 때는 전체 pod의 개수를 P라고 하면 총 P * (k/2)^2개의 connection이 요구되는 것이다.

따라서 core 단계에서 필요한 최소 스위치 개수는 P * (k/2)^2 / k  = P * k/4 가 되는 것이다.

 

이는 north-south communication이 많이 요구되는 상황에서 유효한 구조이다.

 

bisection (대칭이 되도록 끊는 것 중 가장 bandwidth가 작은 것)

가장 critical한 것이자 bottleneck이 되는 것

두 개의 거대한 group을 연결하는 가장 빈약한 링크 

 

---

N개의 node가 fully connected 되어 있다면 총 링크 수는 O(N^2)이다. 정확히는 N*(N-1)/2

 

Spine-Leaf 구조 (industry에서 가장 흔하게 살펴볼 수 있는 구성)

통신의 척추 역할을 해 주는 것이 spine

Clos 구조의 다른 이름이다.

 

---

아... 피곤해

물리적인 연결도를 잡아놨으면 어떻게 찾아갈지를 설계해야 한다.

OSI 7 layer에서 routing이 되는 많은 mechanism이 있다.

어떤식으로 보내라는 것은 RIP, OSPF 등 프로토콜이 있다.

IP가 주어지면 어떤 식으로 찾아가는지는 프로토콜에 따라 달렸다.

자체 프로토콜에 따르기도 한다. (Software Defined Network)

 

데이터센터에서 문제가 되는 패턴인 in-cast 문제

unicast

multicast

broadcast

in-cast는 여러 source가 한 곳으로 집적되는 상황

switch에서 client로 오는 마지막 링크가 혼잡하게 된다.

 

online 서비스에서는 꽤나 흔한 상황이다.

각 포트마다 SRAM 버퍼가 있는데 이것마저 꽉 차서 drop되면 TCP에 의해 다시 retransmit 되면서 지속적으로 traffic이 유지되면서 이에 적응하기 위해 전송량을 점차 줄이게 된다.

때문에 기다리는 시간이 exponentially 늘어나게 된다.

이를 해결하려면

1. 스위치를 여러개 둔다. (이것도 서버가 많으면 한계가 있다)

2. TCP의 congestion control을 데이터 센터에 맞춰서 개조한다. 예를 들어 막히면 random하게 전송 (sync된 상황을 흐트려트려 congestion을 피한다, random backoff)

 

좀 더 잘하는 기법이 있긴 한데, 일단 여기까지만 이해하면 된다.

---

데이터센터가 완전히 알아서 하기 위한 infrastructure가 바로 SDN이다.

MGMT 유닛에서 프로토콜을 만들어 배포

 

overlay/underlay 네트워크

논리적으로 구성된 "터널"을 생성, packet 자체를 하나의 payload로 취급해서 목적지까지 옮기는 것

두 고객의 packet이 겹쳐서 지나가는 구간이 생길 수도 있으나, packet의 내용이 서로간에 보이지 않도록 할 수 있다.

자세한 것은 https://white-polarbear.tistory.com/69 참조

 

---

overlay에서 통신이 되지 않을 때는 문제를 찾기 난해한 경우가 있다.

이것을 visualize해서 분석할 수 있게 하는 기법이 있다.

미리 application이 취할 수 있는 통신 패턴을 미리 지정해놓으면 그것을 벗어났을 때 alert해주는 보안상의 이점도 있다.

패턴은 일정 기간동안 보호, 관찰 기간을 가져서 파악할 수 있다.

 

특정 패킷에 대해서 취해야 할 행동을 단계별로 테이블에 미리 정의해놓는다.

파이프라이닝 형태로 일정 단계를 지나도록 프로그래밍

 

underlay - traffic control

실시간으로 존재하는 여러 connection 중 하나를 선택해서 load balancing이 가능하다

elephant traffic은 이것의 benefit을 볼 수 있다.

 

---

센터 밖으로 나가는 것을 고려해보자.

end point까지 갈 수 있는 법은 많다.

유선 전용망 - 독점 계약을 통해 사용

유선 공중망

무선 공중망

 

데이터센터와 나 사이, 각 데이터센터 사이에서 연결해주는 역할을 한다.

MPLS와 인터넷 중 latency, 혼잡성, 데이터 타입에 따라 다르게 운영

그때마다 best로 보낼 수 있는 회선을 선택

 

핵심은 SDN에서는 중앙의 컨트롤러가 모니터링과 복잡한 알고리즘을 운영하면서 전체 시스템의 네트워크 효율을 최대한으로 뽑으려고 한다는 것이다.