RoCEv2를 이용한 로스리스(Lossless) 네트워크 검증 ~ 2. 네트워크 기술 편 ~

본 기사는 총 세 회에 걸쳐 전달해 드리는, RoCEv2를 이용한 실기 검증 시리즈의 두 번째 기사입니다.

첫 번째였던 지난 회에서는 검증 시작을 위한 포인트가 되는 몇 가지 개념(RDMA, All-Reduce 등)에 대해 적절히 이미지를 사용하여 해설해 왔습니다.

두 번째인 이번 회에서는, Ethernet 상에 로스리스(Lossless) 네트워크를 구축하는 데 있어 전제가 되는 네트워크 측(Cisco Nexus)의 구체적인 기능 이야기에 들어가겠습니다.

통상적인 TCP/IP 통신에서는 패킷 로스(Packet Loss)가 발생하더라도, OS의 TCP/IP 스택에 의한 재전송 제어를 통해 복구됩니다.

반면, RDMA, 특히 RoCE에서는 애플리케이션의 데이터 전송이 OS 커널을 거의 거치지 않고, RDMA 대응 NIC가 메모리와 네트워크 간의 전송을 주도합니다.

그렇기 때문에 신뢰성 제어나 재전송 처리도 주로 NIC 측의 메커니즘(RDMA Transport)에 의존합니다.

즉, 패킷 로스가 발생하면 NIC 측에서 유실된 데이터의 재전송이나 순서 제어를 수행해야 하며, 그동안 후속 데이터 처리가 대기되거나 송신 레이트(Transmission Rate)가 저하됩니다.

결과적으로 RoCE에서는 작은 패킷 로스일지라도 통신 전체의 레이턴시(Latency)나 스루풋(Throughput)에 큰 영향을 미칠 가능성이 있습니다.

따라서 RoCEv2에서는 "애초에 패킷 로스를 발생시키지 않는다"라는 설계 사상 아래, 네트워크 측에서 몇 가지 제어를 조합하여 로스리스 환경을 실현합니다.

여기서부터는 Ethernet 상에서 로스리스 네트워크를 구축하기 위해 필요한 네트워크 스위치 측의 기술에 대해 써 내려가겠습니다.

(1) 패킷 로스 방지 (PFC)

먼저, 버퍼가 넘침으로써 발생하는 패킷 드롭(Packet Drop)을 방지하기 위해 PFC(Priority Flow Control)를 이용합니다.

PFC는 특정 우선도의 트래픽에 대해 전송 일시 정지를 지시하는 메커니즘입니다.

구체적으로는, 스위치가 혼잡(Congestion)을 감지하면 송신 측에 Pause Frame이라고 불리는 전용 프레임을 송신함으로써 트래픽 송신을 일시적으로 정지시킵니다. 이를 통해 패킷 로스를 미연에 방지합니다.

RDMA 트래픽에 설정된 우선도에 대해 PFC를 적용함으로써, 로스리스한 RDMA 통신을 실현하기 위한 베이스가 만들어집니다.

(2) 혼잡 제어 (ECN + DCQCN)

한편, PFC가 발동하고 있는 동안에는 해당 스위치로부터 프레임 송신이 멈추게 되므로, 당연히 스위치 내부 버퍼에는 한 단계 앞선 스위치로부터 도착한 프레임이 점차 쌓이게 됩니다.

이것이 지속되어 일시 정지의 영향이 다른 기기에도 전파되면, 최종적으로는 네트워크 전체에서 트래픽 전송이 정지되어 버리는 리스크(Head-of-Line Blocking이라고 불립니다)도 생각할 수 있기 때문에, PFC가 발동하기 전 단계에서 혼잡 그 자체를 완화하는 메커니즘도 필요합니다.

여기서 사용되는 것이 ECN(Explicit Congestion Notification) 입니다.

ECN은 스위치가 혼잡을 감지했을 때 패킷을 드롭하는 것이 아니라, "혼잡이 발생하고 있다"라는 정보(CE 비트)를 패킷에 마킹합니다.

CE가 포함된 패킷을 받은 수신 측 서버는 이 정보를 바탕으로 송신 측 서버에 통지(CNP: Congestion Notification Packet)를 송신하여, RDMA 트래픽의 송신 레이트를 저하시킵니다.

RoCEv2에서는 이 일련의 제어를 DCQCN(Data Center Quantized Congestion Notification)이라는 알고리즘으로 실현하여, 엔드 투 엔드(End-to-End)로 혼잡을 컨트롤합니다.

(※ DCQCN의 구체적인 동작 흐름에 대해서는 후술.)

(3) 혼잡 제어의 전제: 트래픽 식별 (DSCP / CoS)

위의 (1), (2)가 상정대로 동작하기 위해서는 RDMA 트래픽을 네트워크 내에서 올바르게 식별하고 있는 것이 근본적인 전제가 됩니다.

RoCEv2에서는 IP 헤더의 DSCP(Differentiated Services Code Point)나 Ethernet의 CoS(Class of Service)를 이용하여 트래픽을 분류합니다.

이를 통해 스위치는 RDMA 트래픽을 특정 큐(Queue)나 우선도에 매핑하여, PFC나 ECN과 같은 제어를 적절하게 처리하는 것이 가능해집니다.

DCQCN이 동작하는 모습을 그림을 사용하면서 시계열로 써 보겠습니다.

이번에는 Server-1에서 Server-2를 향해 RoCEv2의 RDMA 트래픽이 송신되는 사례를 통해 생각해보겠습니다.

(1)

먼저, Server-1의 RDMA 대응 NIC가 RDMA 트래픽을 생성하여, DSCP 26이 부여된 상태로 Leaf-1으로 송신합니다. 이 DSCP 26은 네트워크상에서 RoCEv2 트래픽으로 식별하기 위한 마킹(Marking)입니다.

Leaf-1에서 수신된 RDMA 트래픽은 Spine을 경유하여 Leaf-2로 전송됩니다. Leaf-2에서는 Server-2를 향하는 출력 큐(Output Queue)에 RDMA 트래픽이 축적됩니다.

만약 이 출력 큐가 혼잡해져서 ECN 마킹 임계값(Threshold)에 도달하면, Leaf-2는 해당 패킷을 폐기하는 대신 IP 헤더의 ECN 필드에 CE(Congestion Experienced)를 마킹합니다.

즉, Leaf-2는 "이 경로는 혼잡해지기 시작했다"라는 정보를 Server-2로 향하는 패킷 자체에 기록하여 전송하는 동작을 수행하게 됩니다.

(2)

CE 마킹된 패킷을 수신한 Server-2 측의 NIC는 해당 정보를 바탕으로 네트워크상에서 혼잡(Congestion)이 발생하고 있음을 인식합니다. 그리고 해당 패킷의 송신처인 Server-1에 대해 CNP(Congestion Notification Packet)를 송신합니다.

CNP는 수신 측에서 송신 측으로 전달되는 혼잡 통지입니다. Server-1의 NIC는 이 CNP를 수신하면 "자신의 송신으로 인해 네트워크가 혼잡해졌다"라고 판단하여, RDMA 트래픽의 송신 속도(Transmission Rate)를 낮춥니다.

이처럼 ECN은 스위치가 서버에 "혼잡을 알리기" 위한 메커니즘이며, CNP는 그 통지를 받은 수신 측 NIC가 송신 측 NIC에 "송신 페이스를 낮춰달라"고 전달하기 위한 메커니즘이라고 할 수 있습니다.

ECN에 의해 Server-1 측의 송신 속도가 조정되더라도, 혼잡 상황에 따라서는 Leaf-2의 출력 큐 상황이 즉시 개선되지 않는 경우가 있습니다. 이대로 방치하면 최종적으로는 버퍼(Buffer)가 넘쳐서 Leaf-2가 트래픽을 드롭(Drop)할 가능성이 있는데, 이를 방지하기 위한 최종 수단과 같은 역할로 사용되는 것이 PFC입니다.

(1)

앞서와 동일한 통신 시나리오에서, Leaf-2 측의 Priority 3에 대응하는 출력 큐가 더욱 증가하여 PFC 발동 임계값에 도달한 경우를 가정합니다.

(2)

그러면 Leaf-2는 인접 장치인 Spine-1(Spine-2)에 대해 Pause Frame을 송신합니다.

여기서 중요한 점은, PFC는 엔드 투 엔드(End-to-End) 제어가 아니라 인접 장치 간의 링크 단위로 동작하는 흐름 제어(Flow Control)라는 점입니다.

즉, Leaf-2는 Server-1에 직접 Pause를 보내는 것이 아니라, 우선 자신에게 RDMA 트래픽을 보내고 있는 직전의 장치, 이번 사례에서는 Spine-1(Spine-2)에 대해 "Priority 3 트래픽을 일시적으로 보내지 말아달라"고 통지합니다.

(3)

Spine-1(Spine-2)은 Leaf-2로부터 Pause Frame을 수신하면, Leaf-2를 향하는 해당 포트에서 Priority 3 트래픽의 송신을 일시 중지합니다.

※ 이때 중지되는 것은 기본적으로 Priority 3로 분류된 RoCEv2/RDMA 트래픽이며, 모든 통신이 멈추는 것은 아닙니다. PFC는 Priority 단위로 Pause할 수 있기 때문에 다른 Priority의 통신은 계속할 수 있습니다.

이처럼 PFC는 버퍼가 넘치기 직전에 인접 장치를 일시 정지시키는 링크 단위의 긴급 브레이크로서 동작합니다.

RoCEv2의 로스리스(Lossless) 네트워크에서는 우선 ECN/CNP를 통해 송신 속도를 조정하고, 그럼에도 큐가 급격히 증가할 경우 PFC로 패킷 로스(Packet Loss)를 방지한다는 역할 분담으로 이해하면 쉬울 것입니다.

본 검증에서 Server(Ubuntu) 및 Nexus에 적용한 Config 예시(일부 발췌)를 기재해 둡니다.

# RDMA 트래픽에 대해 DSCP/CoS 값 설정
mlnx_qos -i <iface> --dscp2prio='set,26,3’
# CoS=3 트래픽에 대해 PFC 활성화
...

<트래픽 분류>
# RDMA 트래픽 분류를 위한 클래스 맵(Class Map) 생성
class-map type qos match-any qos-rdma
...

지금까지 Ethernet 상에서 패킷 손실을 방지하기 위한 메커니즘으로서 QoS (PFC / ECN + DCQCN)에 대해 해설해 왔습니다.

이에 더해 RoCEv2 환경에서는 트래픽을 여러 경로로 어떻게 분산시킬지도 중요합니다.

여기에서는 대표적인 로드 밸런싱 (Load Balancing) 기법의 메커니즘을 간단히 정리합니다.

Flowlet은 하나의 플로우 (Flow)를 '시간적으로 분할된 단위 (Flowlet)'로 취급하는 방식입니다.

패킷 전송에 일시적인 간격 (Gap)이 발생한 타이밍을 경계로, 후속 트래픽을 다른 경로로 배분합니다.

이를 통해 하나의 플로우 내에서도 여러 경로로의 분산이 가능해집니다.

Per Packet은 패킷 단위로 경로를 결정하는 방식입니다.

동일한 플로우에 속하는 패킷이라 하더라도 각각 독립적으로 경로 선택이 수행되어 서로 다른 경로로 전송됩니다.

즉, 플로우라는 단위가 아니라 '패킷 단위'로 트래픽이 분산됩니다.

Static Pinning은 특정 통신을 미리 정해진 경로에 고정하는 방식입니다.

예를 들어,

• 특정 송신측·수신측 쌍
• 특정 플로우

에 대해 사용하는 경로를 정적으로 할당합니다.

이 방식에서는 통신 시작 시 결정된 경로가 그대로 유지됩니다.

ECMP (Equal-Cost Multi-Path)는 본래 여러 개의 동일 비용 경로에 대해 트래픽을 분산하는 메커니즘이지만, 일반적으로 (앞서 언급한 각 로드 밸런싱 기법을 명시적으로 설정하지 않을 경우) 다음의 5가지 정보 (5-tuple)를 바탕으로 해시 (Hash)를 계산하여 사용하는 경로를 결정합니다.

• 송신측 IP 주소
• 수신측 IP 주소
• 송신측 포트 번호
• 수신측 포트 번호
• 프로토콜

이 경우, 동일한 5-tuple을 가진 패킷은 항상 같은 경로를 통과합니다.

본 기사에서는 RoCEv2를 통한 로스리스 (Lossless) 네트워크를 구축하기 위해 핵심이 되는 네트워크 기술에 대해 해설해 왔습니다.

특히 네트워크 스위치에서의 QoS와 로드 밸런싱 관점에 중점을 두어 해설했습니다만, 이러한 메커니즘이 동작할 때의 시계열 이미지는 다음과 같은 느낌일 것입니다.

RoCEv2 실기 검증 시리즈의 최종회가 될 다음 기사에서는 드디어 실제 검증 파트에 대해 다루게 됩니다.

본 기사에서 해설한 각종 QoS 설정이나 로드 밸런싱 기법의 차이가 RoCEv2 환경의 RDMA 트래픽에 어떤 영향을 미칠 수 있는지, 실제로 트래픽을 흘려보내며 확인해 보고자 합니다.