1. Alteon의 SLB (Server Load Balancing ; 일반적인 구성)
DSR구성을 아시려면 먼저 Alteon의 SLB부터 아셔야 하는데여...
__________________________________________________________________________________
Layer 4 switch는 기본적으로 TCP header를 살펴보고 header 정보를 이용하여 , Traffic을 배분하여 주는 장비를 이야기 합니다.이런 부분은 기존의 Layer 3장비와 다르다고 하여서(Layer 2 switch는 layer 2 정보를 참조하여 traffic을 배분하고 Layer 3는 layer3까지의 정보를 참조하여 Traffic의 방향을 결정해 주져..^^) Layer 4 switch라고 이야기들을 많이 합니다. 정확한 명칭은 Multilayer application switch라고 하는 것이 맞을 것 같습니다. 이런 기법을 이용하여 여러가지것들을.. 주로 loadbalancing하는데 사용되어 지는데...대표적인 것이 SLB(Server Load Balancing)와 FWLB(Firewall Load balancing)과 같은 것이 있읍니다.
SLB에서 중요한 것은 TCP의 해당 서비스 별로 이를 서버에게 배분해주어야 하는 문제점이 생기는데 이를 위해서 IP header부분의 destination ip와 destination mac정보를 바꾸어 주는 일을 filter를 통해서 하고, 이런 filter들을 server enable, client enable이라고 표현합니다.
보통의 Cisco Access-list에서는 IP header정보를 바꾸거나 하는 일을 하지 않습니다.(단지 drop이냐 permit이냐의 결정을 하져..) 하지만 layer 4 장비에서는 이런일들을 하기 때문에 잘 살펴보아야 정확한 loadbalancing을 해줄 수 있읍니다.
__________________________________________________________________________________
SLB를 하실때 중요한 점은 먼저 무슨 서비스(web, email, dns...)를 어떤 IP하나로 묶어주느냐를 먼저 결정해야 합니다. 즉 실재 서버(이를 Real Server IP ; RIP)들을 하나로 묶어 줄 IP가 필요하게 되는데 이를 VIP(Virtual Server IP)라고 합니다. VIP는 알테온 장비가 가지고 있는 가상 IP이며 가상 mac을 가지게 됩니다.
* 여담이지만 과거에 어떤분이 저에게 DHCP서버를 Load balancing해달라고 해서..ㅎㅎ DHCP서버는 Load balancing 불가입니다. 이 부분은 나중에 또 기회있으면 왜 안되는지 이야기 해보겠읍니다.
중요한 것은 Alteon이 SLB할때 어떤일을 하는지를 이야기 하는 것이 중요하므로...암튼 DHCP가 down되어도 골치아픈데..쩝..
그림을 한번 그려 보겠읍니다.
Client A(IP 4번)
|
|
|
______c____________
alteon ( vip 1번) service web
___s_____________s__
| |
| |
| |
real server(IP 2번) real server (IP 3번)
s : server enable filter
c : client enable filter (해당 uplink port에 enable)
Virtual IP를 알테온이 가지고 있다고 이야기 했져... 그럼 실재 통신이 어떻게 되는지 봐가면서 이야기 하면 원리를 이해 할 수 있읍니다.
Client 4는 VIP1번으로 80통신을 하고자 합니다. VIP 1번은 당연히 DNS에 등록이 되어 있겠져...www.xxx.com 처럼 말이져... Real Server의 IP를 DNS에 등록하는게 아닙니다.
그럼 client 4가 VIP 1번으로 실제 통신할때의 TCP/IP 3 way handshake는 어떤식으로 맺어지게 될까여?
Client to Server : Sip ( 4번-client ip ) Dip ( 1번- virtual ip ) SYN
이 패킷이 알테온 스위치까지 당연히 오겠져.. Alteon이 1번 VIP를 가지고 있으니까여?
그런데 위에서 간단히 쓴 SYN packet은 당연히 Real server로 보내져야 합니다. Real server로 어떻게 보낼까여? 목적지 IP가 1번이기 때문에 알테온스위치에서 더이상 나아가지 못합니다. 지금 상태로는 ..(1번은 VIP이고 1번에 대한 IP정보 MAC정보 모두 알테온에 설정되어 있으니까여..) 서비스를 받기 위해서는 당연히 Real server로 보내야 겠져...어떻게 보낼까여?
당연히 DIP를 바꾸어 주면 됩니다. DIP를 Real Server IP인 2번 아니면 3번으로 바꾸어 주면 되겠져...
그리고 당연히 Dmac또한 Real Server의 mac으로 바꾸어 주는 작업을 하게 되면 됩니다.
이런 역활을 하기 위해서 client enable이라는 filter가 존재합니다. client enable filter는 외부에서 오는 packet을 검사하여 destination이 vip이고 해당 tcp destination port가 web일 경우 destination ip를 vip에서 rip로 virtual mac에서 real server의 mac으로 바꾸어주는 일을 합니다.
그런데 또 문제가 있읍니다. 이번에는 반대로 Real Server가 syn에 대한 syn-ack packet을 client로 날릴때도 생각을 해주어야 합니다.
그럼 Real Server 2번이 syn을 받았다고 하고 보내는 경우를 가정 하겠읍니다.
Server to Client : Sip ( 2번-real server ip ) Dip ( 4번- client ip ) syn-ack
흠 이러면 통신이 될까여 ? 당연히 안되겠져...ㅎㅎ
왜냐하면 현재 통신이 Client IP (4번)이 VIP (1번)과 통신하려고 syn을 보냈는데 이에 대한 응답측 source ip가 (2번 - real server ip)그대로 나아가게 되면 안되겠져..당연히 source ip인 2번을 virtual ip인 4번으로 누군가가 바꾸어 주어야 합니다.
이런 역활을 Alteon이 해주게 되고 이런일을 하는 filter를 server enable이라고 표현을 합니다.
server enable filter는 해당 서버에서 날아오는 packet중에 source web이고 source ip가 real server이다면 real server의 IP를 virtual server의 ip로 바꾸어 주는 일을 하게 됩니다.
그리고 중요한 점은 Alteon으로 SLB구성을 하실때 client to server syn packet이 반드시 알테온을 거쳐서 가야 하며 이에대한 응답도 alteon을 거쳐서 가야 한다는 점입니다. 이런 과정을 무시한 것을 DSR이라고 하는데여...이부분은 2편에서 보시면 됩니다. ^^
흠 머리가 복잡하시져.. 정리를 하면..
SLB에서 알테온 스위치가 해야 할 일을 다시한번 정리하면
___________________________________________________________________________________
알테온 스위치는 destination이 vip이고 destination service가 web인 packet(session)을 찾아서
destination ip를 vip에서 rip1혹은 rip2 destination mac을 vmac에서 rmac으로 바꾸어 주는 일을 해야하며- 이런 일을 하는 filter를 client enable이라고 합니다.
또한 반대로 real server에서 응답이 올때 real server에서 온 packet의 4계층 header정보를 조사하여 source port가 80이며 ip가 real server일 경우 rip를 vip로 바꾸어서 최종적으로 응답을 하게 하는 일을 하는데 이 역활을 하는 filter를 server enable이라고 표현을 한다.
_____________________________________________________________________________________
어느정도 정리 되실지 모르겠읍니다. 또하나 더 이야기를 하자면 Alteon에서의 filter는 모두 inbound 방향의 filter입니다. Cisco의 Access-list처럼 in, out 양방향의 filter를 가질 수가 없읍니다.
A=CIP B=VIP C =RIP1, C1=RIP2
_____________________
Alteon switch
______________________
------------------> Client enable ------------------à
(1) (2)
ß----------------- Server enable <-------------------
(4) (3)
지난번 이야기한 SLB 내용이 너무 난해 한 것 같아서 그림을 다시 그려보았습니다.
* CIP : Client IP VIP : Virtual IP RIP : Real Server IP
SMAC SIP DIP DMAC 구분
__________________________________________________
CIP VIP VMAC (1)
CIP RIP RMAC (2)
RIP1 CIP (3)
VIP CIP (4)
위 표 중에 빨간색칠 한데를 잘 보시면 무엇이 Traffic흐름에 따라서 바뀌는지 잘 표시되어 있읍니다.
헐 제 정성 브이 ^^ 말을 못하니 표라도 많이 그려야지..ㅎㅎ
이때 어떤 filter가 적용되는지는 말 안해도 되리라 굳게 믿습니다.
SMAC은 왜 생략되었는지 아실 것 같아 생략하였습니다. 또한 DMAC도 마찬가지로여..^^ Alteon은 layer 2 switch역활 layer 3역활을 그대로 수행한다고 생각하셔도 됩니다. 일반적인 Traffic은여 ..
2. DSR(Direct Server Return)이란 ?
RIP 1, RIP2
위 그림이 DSR의 전형적인 그림입니다. 중간에 스위치는 L2 switch 이고여 초록색 상자가 L4 switch입니다.
지난번에 L4 switch의 SLB의 중요한 점은 한번 packet이 L4로 지나가면 그에 대한 응답도 반드시 L4로 지나가야 한다고
말한 것 같습니다. 그런데 DSR은 말 그대로 (Direct Server Return) 서버의 응답패킷이 L4를 거치지 않고 바로 클라이언트에게
가야 한다는데 문제가 생깁니다. 그럼 뭐하러 DSR을 쓸까여… DSR은 L4 switch의 port(물리적 PORT)가 부족하거나 할 때 구성하는 방법 중에 하나입니다.
이제 그림 보면서 이야기 해보겠습니다. 위에 그림 그려놓은 것 중에서 (1)번 과정은 똑같습니다. 다시 위에 표를 가지고 와보겠습니다.
SMAC SIP DIP DMAC 구분
__________________________________________________
CIP VIP VMAC (1)
CIP RIP RMAC (2)
RIP1 CIP (3)
VIP CIP (4)
(1)에서 DIP가 VIP가 되는 것 까지는 좋은데 문제는 (3)에서부터 발생하게 됩니다. 위의 구성이라면여 , DSR은 (4)이 생략되기 때문에 (3)번의 packet이 client에게 직접가게 됩니다. 이러면 통신이 될까여? 절대 안되겠져.. Client입장에서는 VIP를 목적지로 통신을 시도하려고 했는데 목적지에서 날아온 패킷의 SIP가 RIP1으로 기재되어 있다면 Client는 이를 무시하게 됩니다. 흠 그럼 무언가 해결 방법이 있어야 할 것 같은데 ?
해결 방법은 간단합니다. 위의 그림에서 (2)번으로 packet을 보낼 때 RIP를 변경시키지 않는 것입니다. 다시 표를 그려볼게여…
SMAC SIP DIP DMAC 구분
__________________________________________________
CIP VIP VMAC (1)
CIP VIP RMAC (2)
VIP CIP (3)
위와같이 변경시키면 될 것 같습니다. 위의 표처럼 IP를 바꾸지 않고 MAC만 바꾸어 주어서 traffic의 방향을 변경시키면 됩니다.다시한번 말하면 (1)에서 변경시켜야 할부분은 VMAC-> RMAC으로 변경시키고 VIP는 변경을 하지 않는 것 입니다. 그런데 이렇게 해서 (2)으로 넘어가게 되면 서버가 자신의 MAC주소로 온 packet은 맞는데 자신의 IP가 아닌 VIP를 목적지로 온 packet이라 drop을 하는 문제점이 생기게 됩니다. 그래서 생각해낸 것이 Server에 local loopback 주소를 VIP로 맞추어주게 되면 이를 해결 하게 될 수 있습니다.
그때 언뜻 질문내용이 기억이 안나는데 서버에 왜 local loopback주소를 VIP로 하냐고 질문하신 분이 계셔서 …이렇게 허접 하게 답변을 해봅니다.
이렇게 되면 전혀 문제가 없겠져…(관련설정은 생략하겠습니다. 넘 말이 길어지니까..혹 매뉴얼 보시면 설정하는 것은 자세히 나옵니다.)
그리고 주의하셔야 할 사항은 L4 옆에 스위치가 L2 switch라는 점입니다. 왜 L2 switch일까는 L4 switch가 packet의 header중에 어디를 ( L2정보만을) 변경시켜서
loadbalancing을 하는지를 생각하신다면 쉽게 의문이 풀리실 겁니다.
도움이 되셨는지 모르겠습니다. 참고삼아 대형 portal site중에 저런 DSR구성을 한데가 있읍니다.
주로 portal service를 하는데서 위와 같은 구성을 하려고 하져..
그렇지만 관리적 측면에서 위와 같이 구성하는 것은 한번쯤 생각을 더 해보아야 하지 않을까 하는 생각이 가끔이지만 들때가 있읍니다.
댓글