OpenShift – 네트워크 흐름도 및 이슈 분석

OpenShift는 v3.x, v4.x 버전 상관 없이 기본적으로 OpenvSwitch(OVS) 기반의 openshift-sdn cni plugin을 사용한다.
고객사에서 Application 지연 부분이 생기면, OpenShift 플랫폼 상의 문제가 있지 않느냐라는 이슈 제기를 좀 하는데,
SDN의 대부분은 VXLAN 기반이므로 성능상의 이슈가 있을수는 있겠지만, 크게 크리티컬한건 별로 못 봄.

Application 부분과 네트워크 단에서 문제가 발생하는 상황이 대부분이었고, 이를 책임 전가하는 부분이 너무 많았음.
그래서, 네트워크 흐름도를 만들었고 니네 구성이 개판이라 발생한 것이고 그걸 까기 위한 내용을 공유 한다.

실제 데이터 요청은 아래와 같은 흐름을 통해 전달 된다.

l4 switch -> router node nic(eth0) -> iptables dnat rule -> tun0(ovs) -> br0(ovs) -> vethx(ovs) -> router pod(eth0)
-> HAProxy Route Map(domain) -> front-end -> backend pod ip -> router pod(eth0) -> vethx(ovs) -> br0(ovs) -> vxlan0(ovs)
-> router node nic(eth0) -> worker01 node nic(eth0) -> vxlan0(ovs) -> br0(ovs) -> vethx(ovs) -> app a pod(eth0)

app a pod(eth0) -> vethx(ovs) -> br0(ovs) -> vxlan0(ovs) -> iptables snat -> worker01 node nic(eth0)
-> worker02 node nic(eth0) -> iptables dnat rule -> vxlan0(ovs) -> br0(ovs) -> vethx(ovs) -> app b pod(eth0)

app b pod(eth0) -> vethx(ovs) -> br0(ovs) -> tun0(ovs) -> iptables snat rule -> worker02 node nic(eth0)
-> L2/3/7 or firewall -> external network -> external c service

app a pod(eth0) -> veth1(ovs) -> br0(ovs) -> veth2(ovs) -> br0(ovs) -> veth1(ovs) -> br0(ovs) -> app b pod(ethx)

app b pod(ethx) -> veth2(ovs) -> br0(ovs) -> tun0(ovs) -> iptables snat rule -> worker01 nic(eth0)
-> L2/3/7 or firewall -> external network -> external c service

위와 같은 네트워크 흐름에서 OpenvSwitch(OVS)의 역할은 L2 스위치와 같다고 보면 된다.

즉, 같은 네트워크 대역에 존재하는 OpenShift 클러스터에서 Node to Node 통신은
OpenvSwitch(OVS)의 vxlan0 bridge interface에 UDP/4789 포트를 통해 다른 node에 트래픽을 전달하는 형태이며,
같은 Node에 존재하는 Pod to Pod 통신의 경우 OpenvSwitch(OVS)의 br0(ovs) interface에서 통신이 된다.

OpenShift 노드단의 통신은 가상 L2 스위치에 IPTABLES NAT 정책에 따라 통신되는 구조이기에,
OpenShift 노드단에서 존재하는 네트워크 구간 어딘가에 있을 방화벽이 존재하는 경우 패킷이 drop 될 수 있는 가능성이 있다.

따라서, 패킷 덤프를 통해 내부든 외부든 패킷 drop이 의심될 경우 네트워크를 먼저 의심 해봐야 한다.

tcpdump를 통해 지연이 발생했던 Application Pod 단에서 패킷 캡쳐한 파일을 기반으로 정리하면 아래와 같다.

패킷이 중간에 유실 됨을 의미 한다.

ACK 패킷이 손실 되어 중복으로 ACK 패킷이 재전송 된 경우다.

즉, ABCDEF 데이터가 전송 되었다가 D 데이터 손실 이후 EF가 들어왔을 경우
Client는 Server로 부터 ACK 응답 패킷을 받은적이 없으므로, 패킷을 제대로 받았다는 데이터가 EF이므로,
Client는 EF 전 데이터인 B 데이터를 다시 중복으로 보낸 상황이라 보면 된다.

TCP Dup ACK가 3번 정도 발생이 되면, RTO(Retransmission Timout)가 되기전에 TCP Fast Retransmission이 여러번 수행 된다.

패킷 데이터가 뒤섞여서 목적지에 도착하는 현상.
TCP Dup ACK 가 지속적으로 발생되거나, RTO(Retransmission Timeout)가 발생하여, 재전송(TCP Retransmission)이 발생한 상황.

Packet lost, ACK lost, Early Timeout에 대한 부분을 확인하고
해당 데이터가 도달하지 않는다면 데이터 손실로 판단하고 재전송을 요청한다.

Client가 Server로 SYN 패킷을 보냈지만, 중간에 유실되어 Server에 도달하지 못함.  
Server는 Client로 부터 SYN 패킷을 받은적이 없으므로 ACK 패킷을 보내줄 이유가 없는 상황.

Client가 Server로 SYN 패킷을 보냈고, Server도 ACK 패킷을 보냈지만,  
중간에 ACK 패킷이 유실되어 Client에게 도착하지 못한 상황

Client가 Server로 SYN 패킷을 보냈고, Server도 ACK 패킷을 Client에게 보냈지만,  
네트워크 지연이 발생해서 Client의 Timer가 만료가 된 이후 ACK 패킷이 Client에게 도착한 상황.

위와 내용은 결국 3-way hanshake시 데이터 유실 및 패킷이 Drop 되는 현상이 발생되어 재전송(TCP Retransmission)이 반복되는 현상이라 보면 된다.

같은 내용을 적긴하지만, OpenShift는 외부에서 Pod 내부로 접근하거나, 반대로 Pod 내부에서 외부에 접근시 통신은 OpenvSwitch(ovs)에서 tun0 interface를 타고 전송한다.

또한, OpenShift Node to Node 통신은 OpenvSwitch(ovs)의 vxlan0 bridge interface를 경유하여 br0에 붙어있는 vethx 가상 network interface로 전송한다.

따라서, 외부에서 Pod 내부로 들어오는 네트워크 구간과 내부 Pod의 Node에서
외부로 나가는 네트워크 구간 사이에 패킷 손실이 발생 할 수 있다.

이게, 방화벽에서 문제가 되는 경우도 있고 네트워크 스위치 성능이 좋지 않은 경우나 설정이 잘못 된 경우에 발생이 될 수 있다.

인프라단에서 가장 많이 확인 되는 이슈로는 IaaS로 구성된 경우 네트워크 설정 부분이나,
Storage의 경우 SAN을 사용하여 VM OS DISK로 사용하는 경우 HBA가 문제가 되어 OS 자체가 많이 느리게 되는 경우가 있다.
Bare-metal 서버의 경우 NIC의 불량정도가 있었다.

요즘 좀 많이 짜증난다.

[1]: Outbound Openshift connections going through F5 load balancer suddenly fail
[2]: Connections stall, fail, or take a long time to complete due to excessive TCP retransmissions
[3]: TCP packets sent over a tun (such as to a VM guest) are segmented, reducing performance
[4]: F5 BIG-IP: K50411377: Overview of the TCP profile (16.x and later)