[스크랩] L4/L7 스위치 개요 (로드밸런서)

L4/L7 스위치 개요 (로드밸런서)

from 이유있는 코드 2010/02/01 14:05

스위치의 분류 :

L2 : OSI 레이어 2에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비

L3 : OSI 레이어 3에 속하는 IP주소를 참조하여 스위칭하는 장비

L4 : OSI 레이어 3~4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비

L7 : OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함

L4/L7 스위치의 용도 :

일반적으로 서버들의 로드밸런싱을 위해 사용됨

복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을 시도하면, 스위치가 각 서버의 부하를 고려하여

적당한 서버와 연결시켜준다.

설정에 따라 순차적 연결 또는 접속이 가장 적은 서버에 연결하는 방식 등이 있다.

L4 스위치 :

Layer 4에서 패킷을 확인하고 세션을 관리하며, 로드밸런싱을 제공하는 스위치

TCP/UDP 패킷 정보를 분석해서 해당 패킷이 사용하는 서비스 종류 별로 처리(HTTP, FTP, SMTP...)

세션관리, 서버/방화벽 로드밸런싱, 네트워크 서비스 품질 보장

 

 

L7 스위치 :

L4 스위치의 서비스 단위 로드밸런싱을 극복하기 위해 포트 + 데이터 페이로드 패턴을 이용한 패킷 스위치

(e-mail 내용/제목, URL ...)

connection pooling(시스템 부하 감소), Traffic Compression (컨텐츠 압축 전송), 보안 기능

 

L4 vs L7 :

 

공통점 : 스위치로 들어온 패킷을 적절한 목적지로 전송해줌 (불필요한 패킷은 drop시킴)

차이점 : 

 

  기능과 역할은 동일하나 패킷을 분석하는 인텔리전스가 다름

  L7은 보안 기능 강화

  (DOS/SYN 공격 방어, CodeRed/Nimda 등 감염 패킷 필터링, 네트워크 자원 독점 방지 등)

L7 스위치에 대한 오해 :

 

  L7 스위치는 레이어 7 계층을 위한 스위치이다.

     : 기본적으로 L2, L3 및 부분적으로 L4 스위치를 지원한다. 레이어5 세션 계층 위주이다.

  L7 스위치는 URL 기반 스위치다.

     : L7 스위치 기능에 대한 일부분을 말한 것이다.

  L7 스위치는 모든 TCP/UDP 포트(0-65535)에 대한 인지가 가능하다.

     : 알려진 일반 포트에 대한 세션처리는 가능하지만, 순간적으로 사용하는 임시 포트는 제한적이다.

 

sticky session :

 

L4 스위치를 통해 분배된 서비스 세션은 하나의 연결 요청에 1~n 중에 한 대의 서버에 분배된다.

 

여러 번 시도해도 그 때마다 1~n 중에 한 대에 분배되므로, 같은 서버에 접속될 확률은 1/n이 된다.

 

그러나 처음에 접속했던 서버와 같은 서버에 계속 연결시킬 수 있다.

 

바로  sticky 옵션이다.

 

(일반적인 상태)

사용자A -> L4 -> 1번서버

사용자A -> L4 -> 3번서버

(sticky 상태)
사용자A -> L4 -> 1번서버
사용자A -> L4 -> 1번서버

기존 사용자의 세션 상태를 timeout 시간 내에는 계속 유지시켜주는 것이 sticky session이다.

timeout 시간은 60분 이내로 조절 가능하다.

 

 

sticky session의 문제점 :

L4 스위치의 가장 큰 목적(?)인 로드밸런싱이 제대로 동작하지 않을 수 있다.

 

개별 사용자가 사용할 경우에는 세션 timeout이 있으므로 어느 정도 로드밸런싱을 충족시킨다.

 

하지만 프록시서버를 사용하는 경우 문제가 된다.

 

예를 들어 회사에서 외부로 나가는 경우 각 PC의 IP가 아니라 프록시서버의 IP를 달고 나간다.

 

여러 사람이 timeout 시간 내에 접속하는 경우, 계속해서 한 서버에만 로드가 집중된다.

 

(외부에서 보기에는 동일한 사람으로 보이므로)

대안 :

SSL이나 기타 다른 보안모듈을 이용해서 인증된 특정 사용자에 대해서 Cookie/DB에 기록 후

 

해당 사용자에 대해서만 세션을 유지하도록 한다. (단점 : performance 저하 및 기타 cost)

 

그래서 L7 스위치를 사용한다.

 

< L7 스위칭 방식 >

URL 스위칭 :

URL 주소에서 특정 String을 검사하고, 검색된 문자열을 기준으로 부하를 분산시키는 방식이다.

 

http://www.test.com/test.html 이라는 주소로 사용자들이 웹페이지를 요청한다.

 

해당 페이지는 이미지가 빈번히 변경되고, 이미지 크기도 크다. (전체적으로 로딩이 느리다)

 

이런 경우, client의 http request 내용에 html이 들어가면, 메인 웹서버로 전송하고..

 

해당 request에 jpg 등의 이미지를 요청하는 경우 이미지 웹서버로 분산할 수 있다.

 

Cookie 스위칭 :

 

Http header의 cookie 값에 따른 특정 String을 기준으로 부하를 분산하는 방식이다.

 

Cookie 값 필드를 보고 설정된 분류 기준에 따라 어느 서버로 보낼지 결정한다.

 

Content 스위칭 :

 

legacy한 L7 스위칭은 URL/Cookie 스위칭을 사용했으나,

 

최근 L7 스위칭은 Content 스위칭 방식을 이용한다.

 

기존에는 제한적인 기능, 즉 호스트네임, URL, Cookie 를 기준으로 로드밸런싱을 하였으나,

 

L7 content 스위칭은 추가적인 기능을 지원한다.

 

  Http header 의 모든 필드를 기반으로 한다.

 

  XML content를 기반으로 한다.

 

  XML tags 나 multiple Http header를 기준으로 복잡한 로드밸런싱을 구현한다.

 

  Cookie 와 http header의 insertion과 deletion을 포함한 contents-rewrite 기능을 지원한다.

 

  alternate한 url이나 도메인의 redirecting request를 지원한다.

출처 : http://freeism.web-bi.net/tc/657

------------------------------------------------------------------------------------------

L4장비 로드 밸런싱 알고리즘

1. Hashing algorithm

 

Hashing (hash) 알고리즘에서는 새로은 연결(TCP/UDP)시 각 클라이언트에 대해 hashing key를 가지고 경로를 지정한다. Hashing key는 클라이언트의 IP + port 혹은 IP 주소만으로 결정된다.

 

장점 : 메모리를 적게 사용하고 요구 절차가 간단.

 

2. Round-robin algorithm

 

Round-robin 알고리즘은 round-robin 방식으로 경로를 지정한다. 모든 클라이언트는 동일하게 취급되며 실 서버 혹은 경로는 같은 처리량을 보유해야 한다. SLB에 많이 사용되며 만약 각기 다른 처리 능력을 가진 서버가 있을 경우 weigted round-robin 알고리즘이 더 효율적이다.

 

 

3. Weighted round-robin algorithm

 

Weighted round-robin 알고리즘은 서로 다른 처리 능력을 가진 서버가 있을 경우 사용한다. 가중치를 주어 많이 처리할 수 있는 서버로 많은 트래픽을 할당한다.

 

 

4. Least connection algorithm

 

이 알고리즘은 연결 수가 가장 적은 서버에 네트워크 연결방향을 정한다. 동적인 분산 알고리즘으로 각 서버에 대한 현재 연결 수를 동적으로 카운트할 수 있다.  동적으로 변하는 요청에 대한 부하를 분산시킬 수 있다.

 

5. Weighted least-connectin algorithm

 

이 알고르짐은 서버의 처리 능력을 고려하여 가중치를 부여하면서 least-connection scheduling을 적용하여 트래픽을 고루게 분산시키는 방법이다. 

--------------------------------------------------------------------------------------------

L4장비 사용( 로드밸런싱 사용 알고리즘 확인 필요)

1. 웹서버와 세션 유지시간 일치후 사용(sticky 옵션)

- 적절한 로드밸런싱이 이루어지지 않을 수 있음

> 단체에서 프록시 서버를 이용하는경우

- 라운드 로빈방식 보다는 hash방식에 적합

2. 세션 서버 사용

- 별도의 서버 필요(Redis, infinispan)

> 리소스 오버헤드

- 혹은 세션 클러스터링 설정(WAS, 라운드 로빈방식) 필요

3. 쿠키사용 

> 보안 이슈, 암호화 필요

> 부분 정보 쿠키 사용시 매번 api호출 오버헤드 발생

> 일부 쿠키 지원안하는 브라우저 사용유저 발생 가능성