본문 바로가기
Network Infra 쉽게 이해하기/L4 & L7 Network 쉽게 이해하기

L4 스위치 쉽게 이해하기 #9(2, 네트워크 구성 두 번째)

by 네트워크 엔지니어 환영 2021. 1. 27.
반응형
이번 문서 'L4 스위치 쉽기 이해하기'와 '서버 부하 분산 쉽게 이해하기', 다음에 이어질 문서인 'L4/L7 로드밸런싱 쉽게 이해하기'는 L4/L7 Network Swtich인 'F5 Networks' 장비를 기준으로 설명합니다. Alteon(Radware), Brocade, Cisco, Piolink, Pumkin, Citrix의 관점에서는 다소 다를 수 있습니다.

지난 문서에 이어서 L4 스위치의 네트워크 구성에 대해 계속 이야기해보도록 하겠습니다. 이번에 다룰 네트워크 구성은 'Direct Server Return'(이하 DSR)입니다. 줄여서 DSR이라고 부릅니다. DSR은 앞서 설명한 인라인과 원암처럼 별도의 독립된 구성이 아니고 원암 구성에서 파생된, 겉만 봐서는 원암과 별다를 것이 없는 네트워크 구성입니다. 그래서 One-Arm DSR이라고 부르기도 하지요. 모양은 원암 구성과 동일하지만 그 특징과 효과는 다르며 L4 스위치를 사용하지 않는 분들도 알게 모르게 그 효과를 받고 있습니다. 이제부터 DSR에 대해 알아보고자 합니다.

이 문서에서 말하는 DSR 구성은 L2(OSI Layer 2) DSR입니다. L3(OSI Layer3) DSR은 설명하지 않습니다.

 

Direct Server Return이란?

Direct Server Return이란 말 그대로 One-Arm(이하 원암) 구성에서 서버(Server)가 L4 스위치가 아닌 사용자에게 곧바로(Direct) 트래픽을 되돌려준다(Return)는 것을 의미합니다. 즉 원암 구성에서 파생된 구성임을 뜻하는데요. 지금까지 설명한 L4 스위치의 원암 구성 트래픽을 다시 떠올려보면 다음 그림과 같습니다.

<원암 구성에서의 트래픽 이동>
<원암 구성에서의 3-way handshake>

위 그림에서 보시는 것처럼 원암 구성에서는 L4 스위치를 통한 Request와 Response는 반드시 L4 스위치를 통해 이동합니다. L4 스위치 쉽게 이해하기 #5에서 말씀드렸던 2가지 특징 중 하나이지요. 3-way handshake 또한 모두 L4 스위치를 거쳐 이루어집니다.

하지만 DSR은 트래픽 이동이 약간 다릅니다. 사용자가 서버에게 전달하는 Request 트래픽은 L4 스위치를 통해 전달되지만, 서버에서 사용자에게 돌아가는 Reponse 트래픽은 L4 스위치를 거치지 않고 사용자에게 바로 돌아갑니다. 아래 그림처럼 말이죠.

<DSR 구성의 트래픽 이동>
<DSR 구성의 3-way handshake>

위 그림들을 보시면 사용자가 L4 스위치에 전달하는 Request 트래픽은 모두 L4 스위치로 전달되지만 서버에서 사용자로 돌아가는 트래픽은 사용자에게 직접 전달됨을 알 수 있습니다. 이러한 구성을 현업에서는 꽤 많이 사용합니다. 그렇다면 DSR은 왜 사용되는 것일까요?

 

DSR이 필요한 이유

전 요즘에 TV를 거의 안 봅니다만 헬스장에서 러닝머신을 뛰거나, 밥을 먹을 땐 TV를 켜서 뉴스만 봅니다. 그리고 채널을 돌리기 위해 리모컨을 쓰죠. 그다음부터는 리모컨을 쓰지 않고 방송국에서 송출하는 TV 화면을 보기만 합니다. 즉 사용자인 저는 TV를 켜고 원하는 채널을 보고자 할 때만 리모컨을 조작하는 것이지요.

출처 : https://www.research-paper.co.kr/

DSR의 사용 목적도 이와 원리가 비슷합니다. 사용자가 L4 스위치(리모컨)를 통해 서버(방송국)에 전달하는 Request 트래픽(채널 변경)이 Reponse 트래픽(방송 송출)에 비해 비중이 매우 적을 경우, Response 트래픽을 굳이 L4 스위치를 거치지 않고 서버에서 사용자에게 바로 전달합니다. 몇 번의 Request 트래픽 이후, Response 트래픽만이 존재한다면 굳이 L4 스위치를 지나갈 이유가 없기 때문입니다. 이로 인해 Response 트래픽이 L4 스위치를 거치지 않아 경로를 짧게 가져갈 수 있으며, 또 L4 스위치와 주변 장비의 부하를 줄일 수 있다는 큰 장점이 존재합니다.

IPTV 서비스나 콘텐츠 방송 플랫폼, 개인 방송 채널처럼 IP를 사용하여 인터넷 방송 서비스를 제공하는 경우, DSR 구성을 많이 사용합니다. 이 또한 사용자의 조작(Request)에 비해 화면 송출(Reponse)의 비중이 훨씬 크기 때문입니다. 물론 굳이 방송 서비스가 아니더라도 DSR은 많이 사용하는 편입니다.

반응형

DSR을 가능케 하는 Traffic Flow와 필요 기능

이제 Traffic Flow를 통해 어떻게 DSR 구성이 가능한 것인지 차근차근 보려고 합니다. DSR을 가능하게 하는 중요한 한 가지 원칙은 사용자를 속여야 한다는 것입니다. 이게 무슨 뜻인고하니 사용자는 L4 스위치와 커넥션을 맺었기 때문에 Response 트래픽의 Source IP가 L4 스위치의 IP가 아니면 받아들이지 않습니다. 자신이 보낸 Packet의 목적지 IP와 그에 대한 응답 트래픽의 출발지 IP가 다르면 안 안 되겠지요. 그러나 Response 트래픽은 서버가 보냅니다. 그러므로 사용자로 하여금 L4 스위치에게 Request를 보내고, L4 스위치에게서 Response를 받는다고 생각하게 해야 합니다. 이를 가능하게 하도록 L4 스위치와 서버의 설정을 변경할 것입니다.

<L4 스위치를 대신해 Response 트래픽을 보내는 서버>

아래 구성을 토대로 사용자, L4 스위치, 서버가 어떻게 트래픽을 교환하는지 구체적으로 확인해보겠습니다. L4 스위치와 백본 스위치, 서버는 모두 하나의 네트워크에 묶여 있고 외부 인터넷을 통해 사용자와 연결되는 구성입니다. 그리고 3-way handshake와 데이터 교환 과정을 모두 살펴볼 건데요, 그 과정은 글로만 표현하겠습니다. 

<예시 구성>

사용자가 서비스 접속을 위해 3-way handshake를 실시하려 L4 스위치에 SYN Packet을 보냅니다. 그렇다면 Source IP와 Destination IP는 다음과 같겠지요. 

사용자(15.15.15.15) - > L4 스위치 VIP(12.12.12.100:80)

L4 스위치의 Virtual Server에서 부하분산을 실시한 후, SYN Packet을 서버에게 전달합니다. 여기까지는 기존의 구성인 In-line과 One-Arm과 동일합니다. 하지만 목적지의 IP가 조금 이상합니다. 

사용자(15.15.15.15, bbbb.bbbb.bbbb) - > 서버(12.12.12.100:80, cccc.cccc.cccc)

실제 서버의 IP를 자세히 보시면 실제 서버의 IP가 아닌 L4 스위치의 Virtual Server IP입니다. 즉 실제 서버의 IP로 Destination IP NAT와 Destination Port NAT도 실시하지 않습니다. 왜냐하면 서버가 사용자에게 Response를 전달할 때, Source IP를  L4 스위치의 VIP로 유지하여 전달해야 사용자가 받아들이기 때문입니다. 위에서 한 번 언급한 것처럼 현재 사용자는 서버가 아닌 L4 스위치와 통신하는 것이기에 L4 스위치의 응답에만 반응합니다.

<L4 스위치를 대신해 Response 트래픽을 보내는 서버 2>

포트 또한 마찬가지입니다. L4 스위치의 Virtual Server Port를 그대로 유지해야 사용자가 거부하지 않습니다.  그리하여 Destination MAC Address만을 변경하여 이더넷 프레임을 서버에게 전달합니다.

L4 스위치 Virutal Server의 Destination IP Translation : 미실시
L4 스위치 Virutal Server의 Destination Port Translation : 미실시

SYN Packet을 전달받은 서버는 이제 SYN/ACK Packet을 사용자에게 전달해야 합니다. 하지만 자신을 목표로 하는 목적지 IP가 자신의 IP가 아닌 L4 스위치의 VIP이기 때문에 서버 자신은 이 IP를 갖고 있지 않아 제대로 처리할 수 없습니다. 이를 해결하기 위한 것이 Loopback IP입니다. L4 스위치의 VIP와 동일한 IP로 서버의 Loopback IP를 설정하는 것입니다.

서버의 Loopback IP : 12.12.12.100(L4 스위치의 VIP)

Loopback IP를 설정하여 서버도 L4 스위치의 VIP에 해당하는 IP를 보유하게 되었습니다. 그런데 여기서 문제가 하나 생기죠. 서버는 자신이 새롭게 갖게 된 IP에 대하여 Gratutious ARP(GARP)를 브로드캐스트 형식으로 전송할 것입니다. 동일한 네트워크에서 동일한 IP를 지닌 존재가 있으면 통신에 문제가 발생할 수 있기 때문에 자신이 이 IP를 사용하고 있음을 동일한 네트워크 내의 단말들에게 알려야 하기 때문입니다. 또한 다른 단말이 ARP Request를 보내면 이에 대해서도 응답을 해서는 안됩니다. 서버가 자신이 가진 Loopback IP에 대해 ARP Response를 보낸다면 L4 스위치의 VIP와 충돌이 발생할 것이 뻔합니다.

서버의 Loopback IP의 GARP : 미실시
서버의 Loopback IP의 ARP Response : 미응답

서버에 필요한 설정을 끝마쳤으니 이제 SYN/ACK Packet을 사용자에게 전송합니다. 

서버(12.12.12.100:80, cccc.cccc.cccc) - > 사용자(15.15.15.15, aaaa.aaaa.aaaa)

사용자는 SYN/ACK Packet을 받고 ACK Packet을 L4 스위치에게 전송합니다. 그런데 L4 스위치 쉽게 이해하기 #6에서 했던 "L4 스위치를 통한 3-way handshake는 모든 과정(SYN, SYN/ACK, ACK)을 L4 스위치를 통해 실시해야 한다"는 말을 기억하시나요? 그런데 위의 경우는 그 규칙을 어기는 상황에 해당합니다. 서버가 L4 스위치가 아닌 사용자에게 바로 전달하기 때문이지요. 그렇기에 3-way handshake는 반드시 L4 스위치를 거쳐야 한다는 정합성을 잠시 내려놓아야 합니다.

3-way handshake의 L4 스위치 경유 의무화 : 미실시
* 이 설정은 벤더마다 구현 방식의 차이가 큰 것으로 알고 있습니다.

SYN Packet만을 받은 상태인 L4 스위치는 이제 사용자에게서 ACK Packet을 전달받습니다. 하지만 위에서 언급한 기능을 해제하였기 때문에 L4 스위치는 딴지를 걸지 않고 바로 ACK Packet을 통과시킵니다. 이제 사용자와 서버, L4 스위치는 커넥션이 생성되었으며 통신할 준비가 되었습니다. 

사용자는 요청(예를 들어 동영상 재생)을 L4 스위치에게 보냅니다. 그리고 요청을 전달받은 서버는 그에 대한 응답(예를 들어 동영상 송출)을 L4 스위치를 거치지 않고 사용자에게 보내며 사용자는 받을때마다 L4 스위치를 향해 ACK Packet을 날리게 될 것입니다. 그리고 L4 스위치는 ACK Packet을 서버에게 전송하지요.

 

DSR을 위한 L4 스위치/서버의 별도 설정

이제 위에서 설명한 필요 기능을 어떻게 설정하는지 구체적으로 알아보겠습니다. L4 스위치는 F5 Networks의 BIG-IP, 서버는 리눅스를 기준으로 하겠습니다. 

L4 스위치(L4 Type Virtual Server 사용 필수)

1. L4 스위치 Virutal Server의 Destination IP/Port Translation 해제(Local Traffic - Virtual Server List - 해당 Virtual Server 설정)

<IP/Port Translation 해제>

IP와 Port의 Destination NAT 활성화를 해제합니다.

2. 3-way handshake의 L4 스위치 경유 의무화 실시 해제(Local Traffic - Profile - Protocol - FastL4 설정)

<L4 스위치 경유 의무화 해제>

'Loose Initation'과 'Loose Close'는 F5 Networks의 L4 스위치에서 3-way handshake, 4-way handshake에서 굳이 L4 스위치를 거치지 않아도 Packet Drop을 하지 않도록 막아주는 설정입니다.

3. L4 스위치 Virtual Server의 Source Port 변경 해제(Local Traffic - Virtual Server List- 해당 Virtual Server 설정)

<사용자의 Source Port 고정>

F5 Networks의 L4 스위치는 트래픽 유입시 간혹 사용자의 Source Port를 변경시킬 수 있습니다. 만약 변경된다면 서버가 사용자에게 Response 응답 전달 시 사용자가 사용하던 포트가 다닌 엉뚱한 포트로 향할 것임으로 막아야 합니다.

서버(리눅스)

1. Loopback IP 설정

vi /etc/sysconfig/network-scripts/ifcfg-lo:0
TYPE=Ethernet
DEVICE=lo:0
BOOTPROTO=none
ONBOOT=yes
IPADDR=12.12.12.100
NETMASK=255.255.255.255
IPV6INIT=no
USERCTL=no

L4 스위치의 VIP와 동일하게 Loopback IP를 설정하여 NAT되지 않고 들어오는 Request 트래픽을 처리할 수 있도록 합니다.

2. ARP 

# vim /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2

-- 적용 --
>ifup lo:0
>sysctl –p

서버가 가진 Loopback IP에 대해 GARP를 전송하지 않고, ARP Request에 대해 응답하지 않아 L4 스위치의 VIP와의 충돌을 방지합니다. 

여기까지가 Direct Server Return에 대한 내용입니다. DSR은 특이한 구성이지만 흔하게 사용되는 유용한 구성입니다. 다만 Response가 L4 스위치를 거치지 않기 때문에 장애처리나 트러블슈팅에 있어 다소 어려움이 있는 것이 사실입니다. 그러므로 이 구성에 대해 자세히 알고 있어야 보다 빠른 대처가 가능합니다. 이제 설명을 마치고 다음 문서에서는 L4 스위치의 이중화에 대해 알아보겠습니다. 감사합니다.

반응형

댓글