NSX-T 환경에서 3rd party Inline LB 사용(Asymmetric Routing)

NSX-T 환경에서 3rd party 로드밸런서를 사용할 경우에 발생하는 이슈를 확인 해 보겠습니다.

 

NSX-T 환경에서 Inline mode LB를 사용하여, Client IP를 직접 Server까지 전송하기를 원하는 경우가 발생할 수 있습니다.

여기에 Load Balancer의 위치를 가장 서버 측과 근접한 환경을 위하여, NSX-T의 T1 Router에 구성을 하기를 원할 것입니다.

 

이상적인 구성의 흐름은 아래와 같습니다.

그림-1. 인라인 모드 LB - 격리 네트워크

 

NSX-T는 Zero Trust를 지향하고 있으며, 이에 따라 T1 라우터의 L2 역할을 수행하는 segment에서부터 방화벽 기능인 분산 방화벽이 적용이 되고 있습니다.

 

그림-1과 같이 인라인 모드(서버 측의 Gateway 주소는 LB가 되어야 함.)와 같은 구성을 할 경우에는 일반적인 방법에서 본다면 LB의 풀 멤버인 서버 측은 LB를 통해서만 모든 트래픽이 처리가 되어야 합니다. 이를 위해서는 LB 상단의 라우터에서는 LB에 있는 VIP 혹은 VIP 대역에 통신을 위해서 VIP와 VIP가 위치하는 네트워크 대역이 동일하거나, 혹은 VIP와 VIP가 위치한 네트워크 대역이 다를 경우에는 상단 라우터(여기서는 T1)가 static route 설정을 통해서 LB의 floating IP를 next hop으로 구성하는 경로가 필요합니다. 마찬가지로 서버와 통신을 위한 목적지를 서버측 대역으로 하는 경로 또한 필요할 것입니다.

 

이 환경에서는 서버 측 segment를 생성하였으나, T1 라우터에 gateway 연결을 하지는 않음으로서 격리 네트워크 환경을 구성하여, LB에 구성된 동일한 네트워크 대역으로서 LB의 floating IP를 서버 측에서 gateway 주소로 사용을 한다는 점입니다. 이렇게 하여, 서버측 VM에서는 모든 오가는 트래픽은 LB를 거쳐야만 합니다.

 

이 형태의 장점은 경로가 명확하다는 점과 로드 밸런싱을 위한 pool member에 속한 서버는 LB 하향 측면의 격리된 네트워크에 구성 되었다는 점입니다.

반대로 단점은 모든 트래픽이 LB를 거쳐서 이루어진다는 점이며, 사전 설정을 통해서 서버 측 Gateway 주소로 사용 할  floating IP를 LB에 추가 구성해야 한다는 점입니다.

(NSX Advanced LB를 3rd party LB로서 NSX-T와 통합 없는 구성으로 하였습니다.)

 

그림-2. T1 라우터에 연결된 풀 멤버

그림-2와 같은 형태로 이미 기존 세그먼트에 LB를 사용해야 하는 서버와 일반 서버가 함께 존재할 경우에는 T1 라우터에 이미 서버 측 세그먼트는 연결이 되어 있습니다. 이에 따라 해당 세그먼트에 인라인 모드의 LB를 구성할 경우에는 아래와 같은 유형으로 구성이 됩니다.

  i) LB의 pool member에 속하지 않은 서버: T1 라우터의 IP를 게이트 웨이 주소로 사용

  ii) LB의 pool member에 속한 서버: LB의 서버 측 인터페이스 IP를 게이트 웨이 주소로 사용

 

외부 클라이언트 -> VIP -> 서버로 이동하는 트래픽 흐름은 문제가 되지 않을 것입니다. 모든 트래픽 경로를 단일 LB를 통과하기 때문입니다.

 

그렇다면, 서버 측에서 생성된 트래픽이 LB를 통해서 외부에 전달 후, 다시 돌아올 경우에는 어떤 현상이 발생하는지 보겠습니다.

 

그림-3. 호스트에서 생성된 트래픽 흐름

 

호스트에서 바로 생성된 트래픽은 송신 시에는 LB를 거쳐서 전달이 되나, 돌아오는 트래픽의 경우 LB 상향 측면의 라우터에서 서버 대역을 목적지로 트래픽 경로를 LB 측으로 틀어주지 않을 경우에는 그림-3과 같이 라우터에 연결된 세그먼트를 통해서 돌아오게 될 것입니다.

 

우리는 기존 세그먼트에서 이미 다수의 VM들이 Gateway 주소로 T1 라우터를 가지고 있고, 동일 세그먼트에 있는 일부 서버를 인라인 모드 LB를 구성하고 있는 특이한 상황이라는 점을 잊지 않아야 합니다.

 

이러한 구성에서 일부 서버는 LB를 게이트 웨이 주소(113.11)로 갖게 되고, 일부 서버는 T1 라우터를 게이트 웨어 주소(113.254)로 갖게 됩니다.

 

이 경우에는 비대칭 라우팅 형태가 나타나게 됩니다.(Asymmetric routing)

일반적인 물리 환경에서도 이런 비대칭 라우팅 경로는 종종 나타나게 되나, 크게 문제가 되지는 않습니다.

 

그러나, NSX-T 환경에서는 그림과 같이 DFW(분산 방화벽) 기능이 모든 VM의 입출력 레벨인 세그먼트에서 동작을 하고 있습니다. 기본적인 분산 방화벽은 stateful 기반으로 동작을 하고 있으며, 이로 인해 정상적인 패킷 전송 흐름에 영향을 주게 됩니다.

 

그림-4. LB로 모든 트래픽 흐름

당연히 하나의 세그먼트 안에 있는 모든 VM들이 LB를 게이트웨이로 보도록 구성 변경하는 것입니다. 그러나, 이는 모든 서버에서 발생하는 트래픽 라우팅을 LB가 전담해야 하기에, 로드 밸런싱이 필요치 않는 서버들까지 수용하는 것은 LB의 성능과 가격적인 측면을 고려하면 효율적이지 않습니다.

혹은 처음부터 LB 풀과 일반 호스팅 서버들을 서로 다른 세그먼트에 배치하도록 구성을 했어야만 할 것입니다.

 

그러나, NSX-T의 분산 방화벽은 stateless 기능을 지원하고 있기에 해당돠는 IP 혹은 IP 대역만을 지정하여, 새로운 방화벽 정책을 추가하고 적용을 한다면, LB pool member에 대해서만 stateless 동작을 통해서 문제 없이 비대칭 트래픽 흐름에서도 동작을 시킬 수 있습니다.

 

그림-5. Stateful 끄기 옵션

그림-6. 분산 방화벽 신규 정책과 룰

 

추가로 그렇다면 NSX Advanced LB의 성능 지표는 어떻게 될까요?

VIP 서비스를 제공하는 LB의 성능은 아래 URL를 통해서 공개된 데이터시트를 확인할 수 있습니다.

https://avinetworks.com/docs/latest/nsx-alb-performance-datasheet/

NSX Advanced Load Balancer Performance Datasheet

 

LB 서비스가 아닌 단순 라우팅 트래픽 처리를 위해서 iperf 도구를 이용하여 테스트를 진행 했으며, SE(Servic Engine) VM의 spec으로 2vCPU, 4GB vMEM으로 배포 하고, MTU 8,900으로 설정 테스트 결과

 - 약 9Gbps 정도의 라우팅 트래픽 처리를 하는 것을 확인 하였기에 LB pool member인 서버 측에서 서비스를 위해 다른 곳으로 이동하는 트래픽에 대해서도 성능적인 걱정을 할 필요는 없을 것으로 보입니다.