Skip to content

 
 
[L4/L7 스위치①]
등록일 :  2002.09.23
출    처 :  NETWORK TIMES
작성자 :  조영철 파이오링크 부설연구소 소장
로드밸런싱의 ‘꽃’, L4/L7 스위치 관심 집중
스위칭ㆍ패킷 필터링ㆍ미러링ㆍ보안 기능 결합 …
초당 연결수ㆍ동시 연결수ㆍ처리용량이 성능 잣대


L4/L7의 등장 배경

최근 다양한 기능과 성능을 보유한 이더넷 스위치들이 등장하고 있다. 이더넷 스위치의 발전 과정을 다양한 측면에서 바라볼 수 있으며 <그림 1>과 같이 대역폭(Bandwidth), 기능(Function), 지능(Intelligence)을 큰 축으로 발전하고 있다.



<표1> OSI 주요 계층에 쓰이는 프로토콜
OSI 참고모델의
주요 계층
널리 쓰이는 프로토콜
레이어 2 이더넷Ⅱ, IEEE802.3/802.2 SNAP, 네트웨어, 802.3 Raw
레이어 3 IP, ARP, IPX, Non IP/IPX, IPv6
레이어 4 TCP, UDP, ICMP
레이어5~7 HTTP, SNMP, 텔넷, FTP, RTSP


대역폭 측면에서 이더넷 스위치는 초기의 CSMA-CD(10Mbps)방식에서 패스트 이더넷, 기가비트 이더넷, 10기가비트 이더넷으로 확장되고 있다. 한편 기능적 측면에서는 랜 안에서 네트워킹 유닛(호스트) 간에 물리적인 연결을 목적으로 했던 이더넷 L2 스위치는 지역망이 복잡해지고, 단일 랜 환경이 맨 영역으로 확대됨에 따라, 가상랜 QoS를 특징으로 하는 L3 스위치가 기업시장을 중심으로 광범위하게 사용되고 있다. 이더넷 스위치를 지능적인 측면에서 크게 OSI 참조 모델에 의한 7계층의 정의에 따라서, L2/L3/L4/L7 스위치로 구분이 가능하다.


레이어 4 스위치ㆍ로드밸런서의 차이

레이어 2 스위치는 OSI 참조 모델의 레이어 2 범주(이더넷 프로토콜 상에서 소스 MAC, 목적지 MAC)에서 패킷의 경로를 제어하고, 레이어 3 스위치는 OSI 참조 모델의 레이어 3 범주(TCP/IP 프로토콜 상에서는 소스 IP, 목적지 IP)에서 패킷의 경로를 제어한다.

레이어 4 스위치는 기존의 이더넷 레이어 2 스위치와 다른 차원이 스위치다. 레이어 4 스위치는 레이어 4 범주의 패킷을 분류하고 경로를 제어하는 것에서는 레이어 2 스위치 혹은 레이어 3 스위치와 동일하지만, 레이어 4 스위치의 독특한 기능은 레이어 4에서 발생하는 세션을 관리하고, 세션 관리를 위한 패킷도 조작한다는 것이다.

레이어 4 스위치의 기능은 벤더마다 조금씩 차이가 있을 수 있으나, 핵심 기능은 로드밸런싱 기능이다. 로드밸런싱 기능을 제공하는 제품군을 일반적으로 ‘로드밸런서’라고 부른다. 이런 차원에서 레이어 4 스위치는 로드밸런서의 한 제품 형태라고 할 수 있다. 로드밸런서의 제품들은 크게 서버 기반, 스위치 기반, 소프트웨어 기반의 제품으로 나눌 수 있다.

서버 기반 로드밸런서는 이더넷 카드를 여러 개 장착한 일반 서버형태로 구성되어 있다. 주된 기능은 범용 CPU상에서 포워딩 엔진으로 동작한다. 시중에는 F5 네트웍스의 BIG-IP, 코요테 포인트 이퀄라이저, 시스코의 로컬디렉터, 넷스케일러의 제품들이 있고 리눅스 오픈 프로젝트의 리눅스 버추얼 서버 프로젝트가 여기에 속한다.

소프트웨어 기반의 제품은 소위 클러스터링 소프트웨어로 분류할 수 있다. 별도의 각각의 서버에 클러스터링 모듈을 탑재해 트래픽을 분산하며, 다양한 트래픽 관리기능을 갖추는 것이 특징이다. 서버의 종류나 운영체제에 의존적인 면이 단점이다. 마이크로소프트 2000 서버의 클러스터링 서비스, 리소네이트(Resonate)의 제품들이 이에 속한다.

이에 반해 스위치 기반의 로드밸런서는 일반 L2/L3 스위치의 기능과 형태에 추가적으로 로드밸런싱이 더해진 형태이다. 이러한 형태의 스위치는 레이어 4의 기능을 전용으로 수행하기 위해 L2/L3 칩을 내장하면서 동시에 로드밸런싱을 고속으로 수행하기 위한 전용 엔진을 탑재하고 있으며, 전문적으로 로드밸런싱을 위한 ASIC을 장착하기도 한다. 시스코의 컨텐츠 서비스 스위치, 노텔의 알테온 웹 스위치, 파이오링크의 핑크박스 시리즈, 파운드리의 서버아이언 제품이 여기에 속한다.

역사적으로 L4 스위치의 모티브는 서버기반의 로드밸런서였다고 할 수 있으며, L4 스위치는 로드밸런싱 기능 이외에도 L2/L3 스위칭 기능 및 패킷 필터링, 미러링, 보안 등 다양한 기능들이 추가되고 있다.



L4/L7 스위치의 주요 기능

L4/L7 스위치의 주요 기능은 크게 다음과 같다.

  • 서버 로드밸런싱(SLB) 기능
  • 캐시 리다이렉션(CR) 기능
  • 방화벽/VPN 로드밸런싱(FWLB) 기능
  • 패킷 미러링/필터링 기능
  • 보안 기능

    이러한 기능들을 통해 L4 스위치는 인터넷 서버의 성능 확장, 서비스의 속도 개선, 인터넷 서비스의 안정성 향상, 인터넷 트래픽을 효율적으로 관리해야 하는 경우에 적용될 수 있다.

    SLB기능은 인터넷의 서버(웹서버, 파일 서버, 메일 서버 등)의 부하분산 기능을 말한다. 여러 대의 서버를 마치 하나의 서버(서버 팜)처럼 동작하게 함으로써, 인터넷 서버의 성능 및 안정성을 향상시킬 수 있다. SLB에 대한 기능은 다음 호에 자세히 다룬다.

    L4 스위치의 CR기능은 인터넷으로 급속한 확산으로 많이 사용되고 있는 캐싱 서버를 좀더 효율적으로 사용할 수 있게 하는 것이다. 캐시는 인터넷의 서버와 클라이언트 단에서 속도 향상과 왠 구간의 트래픽 감소을 위해 서버의 데이터를 일시적으로 저장하는 장치이다. 과거에 캐싱서버는 클라이언트 측면에서 프락시 형태로 동작했지만, L4 스위치를 사용해 ‘투명한’ 캐싱 서비스를 제공할 수 있다. 여기서 투명하다는 의미는 클라이언트단에서 웹브라우저에 아무런 설정 없이 캐싱 서비스를 제공받을 수 있다는 의미이다.

    L4 스위치의 FWLB기능은 방화벽이나 가상사설망(VPN) 게이트웨이 장비의 성능향상과 안정성향상을 위한 기능이다. VPN게이트웨이는 방화벽과 다른 장비로 분류되지만, 패킷의 흐름이 유사한 관계로 L4 스위치에서 FWLB기능으로 분류된다. 기존까지 VPN게이트웨이 장비를 로드밸런싱하는 경우는 VPN게이트웨이의 특성에 의해 기술적인 문제가 많았으나, 시장의 요구와 기술적인 문제의 해결로 인하여 점차로 보편화되고 있는 추세이다. VPN 장비의 로드밸런싱 기능을 위해서는 특별한 패킷 처리가 필요하다.


    L4/L7 스위치의 성능 지표

    L4/L7 스위치는 L2/L3 스위치로서 모두 동작할 수 있는 기능이 있지만, L4/L7 스위치의 가장 중요한 특징은 로드밸런싱 기능이라고 할 수 있다. 로드밸런싱 기능은 L2/L3 기능과 달리 국제 표준에 의해 정해진 기능이나 성능 지표가 없다.

    1. 초당 연결수(Connections per second)

    순수한 로드밸런싱의 성능을 나타낼 때, 시간당 얼마만큼의 TCP 트래픽(예, HTTP)을 처리할 수 있느냐가 중요한 지표이다. 하나의 TCP 연결은 클라이언트와 서버간의 쓰리-웨이 핸드쉐이크(three-way handshake) 동작(하나의 SYN과 두개의 ACK 패킷)으로 정의된다. 따라서 이 성능 지표는 제품에 따라 ‘초당 트랜잭션(transactions per second)’ 혹은 ‘초당 세션(sessions per second)’으로 불리기도 한다. 하나의 TCP 세션을 열고(opening) 닫는(closing) 작업은 L4 레벨의 기본 세션관리의 가장 핵심적인 동작이고, L4의 포워딩 엔진 부분에 가장 많은 작업량을 요구하는 작업이므로, 이 지표는 L4의 네트워크 프로세서 디바이스나 커널의 성능에 따라 좌우된다.

    시장에 출시된 제품들은 TCP 세션을 시간당 얼마나 성립(opening)할 수 있는지를 제시하고 있다. 따라서, 만약 세션을 닫는 동작까지를 고려할 경우 초당 연결 수를 계산하면 세션이 성립되는 경우의 초당 연결 수의 약 2분의 1이 나온다고 보면 된다.

    한편, 모든 로드밸런싱에서 초당 연결 수가 의미 있는 수치는 아니다. 예를 들어 SLB에서 UDP 패킷에 대해 초당 연결 수는 무의미한 값이다. UDP 패킷은 쓰리-웨이 핸드쉐이크 방식이 아니라, 커넥션리스(connection-less) 프로토콜이므로 단일 UDP패킷에 대하여 연결(connection)이 바로 성립된다. 따라서, UDP 프로토콜에 대한 로드밸런싱을 구축하는 경우에 초당 연결 수는 의미가 없다고 할 수 있다. 한편, FWLB에서는 초당 연결수 보다도 다음에 설명할 처리용량(throughput)이 더 중요한 성능 지표라고 할 수 있다.

    2. 동시 연결수(Concurrent connections)

    동시 연결수는 얼마나 많이 성립된 TCP 세션을 유지할 수 있는지에 대한 수치이다. 일반적으로, 하나의 TCP 세션이 열렸을 때, 바로 즉시 세션이 닫히는 것이 아니라, 사용자의 그 TCP 세션을 사용하고자 하는 시간동안 계속 세션을 유지를 하여야 한다. 특히, HTTP v1.1 프로토콜에서는 HTTP v1.0에 비해 TCP 세션하나를 지속적으로 사용하므로, 로드밸런서 장비는 성립된 TCP 세션을 되도록 오래 지속할 필요가 있다.

    동시 연결수는 L4 스위치의 네트워크 프로세스나 커널에 부착된 메모리의 양에 의존적이다. 시중에 출시된 L4 스위치가 제공하는 동시 연결수는 수천개에서 무제한(unlimitted)까지다. 특히, 무제한까지 지원한다는 의미는 이론적으로 메모리를 사용하지 않는 스테이트레스(state-less) 로드밸런싱 알고리즘(예, 해싱)을 적용할 경우이며, 현실적인 의미에서는 기타 네트워크 장벽(barrier)에 의해 동시 연결수는 제한될 수밖에 없다.

    한편, UDP 패킷에 대해 오해가 될 수 있는 점이 있다. UDP 패킷은 커넥션리스 프로토콜이므로 UDP 패킷을 로드밸런싱하는 경우에 동시 연결수와 연관이 없다라고 생각할 수 있으나 이는 잘못된 견해이다. UDP 패킷에 대한 세션 성립을 L4 스위치가 수행하지는 않지만, 상태를 기억해야 하는 로드밸런싱 알고리즘(예: 라운드 로빈, 리스트(least) 커넥션)을 사용하는 경우 각 UDP 패킷과 실제 서버의 연결정보를 기억해야 하므로 최대 연결 수는 TCP에서와 같이 중요한 지표라고 할 수 있다.



    3. 처리 용량(Throughput)

    시중에 출시된 많은 L4 스위치에서 ‘우리 제품의 스위칭 용량이 몇 Gbps, 혹은 수십 Gbps다’ 라는 사양을 제시한다. 이러한 사양은 고객이나 사용자에게 로드밸런싱(L4 레벨의 패킷 처리)을 수 기가 혹은 수십 기가에서 처리할 수 있다는 오해를 불러일으키기 쉽다. 스위칭 용량이 수 Gbps, 혹은 수십 Gbps라는 의미는 L4 스위치 내의 포트간에 패킷을 처리하는 L2 레벨의 패킷 처리 용량, 더 엄밀하게는 내부의 스위치 패브릭의 용량이 그렇다는 의미이지 L4 레벨의 모든 동작이 그 용량으로 처리된다는 것은 아니다. 정확한 L4의 용량은 이와는 별도로 제시되어야 함이 옳다. 일반적으로 L4 스위칭에 대한 처리 용량은 다양한 구성 및 경우에 따라서 다른 값을 나타낼 수 있으므로, 하나의 수치로 표현될 수 없다.

    다른 한편으로, 처리 용량은 각 스위치 장비가 지원하는 업링크(Uplink) 포트의 인터페이스 규격(패스트 이더넷, 기가비트 이더넷)에 제한된다고 할 수 있다. 예를 들어, 수 Gbps의 L2 스위칭 처리용량을 가지는 L4 스위치라고 하더라도, 업링크에 따라서, 최대 100Mbps, 1Gbps에 제한될 수밖에 없다. 이러한 제한점을 극복하기 위해서 업링크를 여러 개 트렁크해 사용하는 것이 제시 될 수 있으나, 일반적인 L2 레벨의 트렁킹(trunking)은 간단한 해싱함수에 의해 패킷을 분산시키므로 두개 이상의 업링크 포트를 효율적으로 사용할 수 없는 단점이 있다. 이러한 업링크 포트에 대한 성능의 제한을 극복하기 위해서 SLB의 구성에서는 DSR(Direct Server Return) 기술을 사용할 수 있는데, 이는 다음 호에서 자세히 설명하기로 한다.

    처리 용량을 나타내는 단위는 두 가지 형태로 생각할 수 있다. 하나는 bps(bit per second)이고, 또 하나는 pps(packet per second)이다. 여기서 패킷이란 이더넷 패킷을 대부분 지칭하고, 이더넷 패킷은 최소 40바이트에서 최대 사이즈는 1,500바이트가 일반적이다. 하나의 패킷은 바이트의 단위로 표현되고, 1바이트=8비트이므로, 아래의 수식으로 둘 사이의 관계를 표시할 수 있다.

    bps = (pps) x (패킷 사이즈) x (8)
    따라서, 처리용량을 pps로 제시할 경우는 패킷의 사이즈를 함께 제시하여야 정확한 bps의 처리용량을 계산할 수 있다. 반대로, bps로 처리용량을 제시할 경우는 처리에 사용되는 패킷의 길이를 제시해야 한다.

    예를 들어, 처리용량이 10,000pps라고 하면 10,000pps=10K×1.5Kbytes(MTU)×8bps=120 Mbps 이므로 최대로 처리할 수 있는 120bps의 이론값을 갖는다. 하지만, 실제 pps의 기준이 모호하므로 만약, 실제 환경에서 많이 전송되는 패킷 사이즈, 약 64바이트 패킷을 기준으로 한다면 10,000pps=10K×64바이트× 8bps=4.9Mbps이다. 이는 앞서 제시한 이론적인 최대치인 120Mbps와 큰 차이가 있다. 100Mbps 패스트 이더넷 인터페이스와 1Gbps 기가비트 이더넷 인터페이스를 100% 활용하는 경우에 각 패킷 사이즈에 따라, pps를 계산하면 <표 2>와 같다.

    <표2> 패킷 사이즈에 따른 PPS 계산
      64바이트 128바이트 512바이트 1024바이트 1500B바이트
    100Mbps 204.8K 102.4K 25.6K 12.8K 8.7K
    1Gbps 2048K 1024K 256K 128K 87.3K


    4. 임계치(Threshold)

    좀 더 현실적으로 어떠한 L4 스위치도 처리해야 하는 트래픽이 많아지거나 고급의 기능을 수행할 경우에는 처리속도가 급격히 떨어지는 현상이 발생할 수 있다. 만약, 어떤 L4 스위치가 L4 스위칭을 처리할 경우에는 아무런 지연현상(Latency) 없이 90Mbps로 패킷을 처리할 수 있지만, URL-파싱(parsing)이나 쿠키 기반 퍼시스턴스(cookie-based persistence)를 적용했을 경우 45Mbps 정도만을 처리할 수 있을 것이다. 이것은 위의 기능을 수행하기 위해 L5~L7 레이어 레벨에서 패킷을 더 조사하고, 조작하여야 하기 때문이다. 이러한 현상을 임계현상이라고 정의하고, 임계현상이 발생하는 처리용량을 임계치라고 한다. 예를 들면, HTTP의 리퀘스트에 대한 로드밸런싱을 어느 정도까지는 무난히 처리하다가, 어느 임계치를 넘으면 처리 속도가 현저히 떨어질 수 있다. 이러한 특성은 서버기반의 로드밸런서와 ASIC을 기반으로 하는 로드밸런서 모두에서 나타날 수 있다. 특별히, 서버기반의 로드밸런서에서는 L4의 처리를 중앙 CPU에서 처리하는 부분이 많으므로 선형적으로(linearly) 성능의 저하가 발생하는 경우가 많다. 반면에 분산처리 구조의 ASIC이나 전용 하드웨어 구조를 가진 L4 스위치는 처리용량이 큰 장점이 있으나 임계현상이 두드러지게 나타날 수 있다.

    최근에는 이러한 임계현상의 극복을 위해서 L4 기능뿐 아니라, L5~L7 기능을 성능저하나 지연현상(Latency) 없이 처리하기 위한 네트워크 프로세서 혹은 ASIC 개발에 주력하고 있다. 이러한 네트워크 프로세서 칩 개발 동향 및 L4/L7 스위치 구조에 대해서는 다음 호에서 자세히 설명한다. (www.dataNet.co.kr)

  • profile

    일요일은 짜빠게뤼~ 먹는날~^^

    엮인글 :
    http://adminplay.com/3711/0d8/trackback
    List of Articles
    번호 제목 글쓴이 날짜 조회 수sort
    287 CentOS Samba 설정 ADMINPLAY 2010-11-08 24884
    286 가볍고 강력한 SNMP를 이용한 모니터링 프로그램입니다. file ADMINPLAY 2009-10-31 24859
    285 리눅스 - htop file ADMINPLAY 2010-09-12 24838
    284 favicon 만들기 ADMINPLAY 2009-09-30 24835
    283 네트워크 관리자를 위한 통합 모니터링 툴 - N.E.W.T file [2] ADMINPLAY 2009-10-31 24705
    282 리눅스 - zip 압축 해제 ADMINPLAY 2009-07-25 24646
    281 [CentOS] ffmpeg 설치 ADMINPLAY 2012-02-07 24495
    280 리눅스 Proxy Server[Squid] 설정법[RedHatLinux8.0] ADMINPLAY 2009-11-26 24408
    279 커널 컴파일 장애 처리 perl: warning: Please check that... ADMINPLAY 2009-08-08 24378
    278 대용량 하드 디스크 파티셔닝 (GPT 파티션) ADMINPLAY 2009-06-04 24364
    277 lighttpd와 Apache의 성능 차이 file [2] l2zeo 2012-03-08 24242
    276 [Flash] 크로스 도메인 설정 방법 ADMINPLAY 2010-08-31 24233
    » 로드밸런싱의 ‘꽃’, L4/L7 스위치 관심 집중 ADMINPLAY 2009-11-30 24151
    274 kernel panic 발생 시 자동으로 리부팅 설정 ADMIN 2008-12-10 24084
    273 하드웨어정보 확인(lshw) file ADMINPLAY 2008-11-03 24038
    272 MRTG 소스 설치 ADMINPLAY 2010-05-11 24028
    271 리눅스에서 특정 파일을 제외하고 삭제하기 ADMIN 2008-11-03 23970
    270 VI 에디터 유니코드(UTF-8)로 인코딩 전환 ADMINPLAY 2010-04-02 23966
    269 리눅스 공유 메모리의 설정 (세마포어) ADMINPLAY 2010-04-28 23950
    268 젠투리눅스에서 잃어버린 암호를 다시 설정하기 ADMINPLAY 2010-04-15 23899

    Copyright ADMINPLAY corp. All rights reserved.

    abcXYZ, 세종대왕,1234

    abcXYZ, 세종대왕,1234