[펌] L4 switch

Layer-4 Switching 개념이해(1)

LAN에서는 현재 각종 스위칭 기법들이 범람하고 있어서 춘추 전국시대를 방불케 하고 있다. 예를 들면, 3계층 스위칭, 4계층 스위칭, 무 계층(Layerless) 스위칭, 태그(Tag) 스위칭, IP 스위칭, 네트워크 계층 스위칭, 멀티레이어 스위칭, MPLS(MultiProtocol Label Switching) 등등. 이런 기법들이 미래 네트워킹 솔루션의 중요한 부분들이 될 것은 확실하다. 한마디로 말하면, 이런 스위칭 기법들의 대부분은 네트워킹 요소 중의 라우팅 측면에 대해 업체 또는 단체 고유의 해답을 제시하고 있으며 이런 방안들을 통해 네트워크가 이전에 비해 더 나은 성능을 제공하게 하여 네트워크의 확장성을 제고하는데 그 목적을 두고 있다고 말할 수 있다.

우선, 이러한 여러 가지 스위칭 기법들의 등장 배경인 라우터의 한계에 대해 알아보고 각종 스위칭 기법들에 대해 살펴보기로 하자.

라우터의 한계 (Layer-4 Switch의 등장배경)

지난 수년간 라우터에는 많은 기능들이 부가되었다. 라우터는 멀티프로토콜을 지원하며 LAN과 WAN을 연결해주고 구성 파라메터들도 수백 개로 늘어나 세련된 패킷 필터링이 가능하게 되었으며 네트워크에 대해 과거에 비해 상당한 제어력도 제공해주고 있다. 고속의 프로세서와 메모리 덕분에 라우터의 성능을 저해하지 않고 많은 기능을 제공할 수 있었다. 하지만, 네트워크에서 갈수록 더 많은 트래픽을 처리하게 되자 모든 패킷의 헤더를 처리해야만 하는 라우터에서 정체 현상이 빈번하게 발생하기 시작했다. 설상가상으로 라우터에서 정체가 발생하면, 라우터는 패킷을 폐기하기 시작하고 이는 다시 출발지의 재전송을 초래하여 상황은 더욱 악화되기도 한다. 물론, 이에 대한 각종 큐잉 기법이나 캐싱 기법들이 있기는 하지만 근본적인 해결 방안은 되지 못하고 있다. 또한, 확장성이 매우 뛰어난 라우터도 있으나 문제는 가격이 만만치 않다.


그렇다면, 어떻게 이 문제를 해결할 수 있을까? 답을 찾기 위해 잠시 시장에 들르기로 하자. 시장에서는 손님이 살 물건을 가져오면 주인이나 점원이 가격을 계산하고 돈을 지불하면 물건을 준다. 하지만, 손님이 많고 손님들이 구매한 물건의 종류가 늘어나면 계산대에는 줄이 늘어선다. 손님이 늘고 물건 종류가 늘어날수록 줄은 더 길어진다. 또한, 줄 중간에 신용카드나 수표로 지불하는 사람이 있으면 상황은 더 악화되어 대기 시간이 더 늘어난다.


최근 몇 년 동안 갑자기 수가 늘어난 양판점이나 대형 슈퍼마켓에서는 이에 대한 해답을 제공하고 있다. 슈퍼마켓에서는 손님이 물건을 가져오면 계산대의 점원이 바코드 리더로 물건에 붙어있는 바코드를 읽는다. 그러면 가격이 아주 신속하게 계산된다. 또한, 수표나 신용 카드 구매자들과 현금 구매자들은 서로 다른 계산대를 이용한다.


즉, 슈퍼마켓에서는 최소의 비용으로 사용자의 대기 시간을 최소화하고 서비스를 개선하기 위해서 바코드를 도입하였고 사용자 유형별로 별도의 계산대를 마련하고 있으며 계산대의 수도 시장의 점포보다 많이 가지고 있다. 또한, 점원들도 386 세대가 아닌 586 세대가 주류를 이루고 있다. 한마디로 말하면, 최근의 대형 매장에서는 바코드(라벨), 바코드를 기반으로 한 가격 계산(라벨 스위칭), 더 빠른 점원(라우터)과 늘어난 계산대(대역폭)를 모두 갖추고 있는 셈이다.

Layer-4 Switch 선택시 고려 사항

4계층 스위치는 트래픽 플로우에 따라 더 한층 정밀한 네트워크 튜닝(Tuning)과 우선 순위 부여 기능을 통해 2/3계층 스위칭을 한 차원 끌어올린 장비라 할 수 있다. 2계층 스위치는 MAC(Media Access Control) 어드레스를 사용하여 스위칭 기능을 수행하고 3계층 스위치는 IP 같은 네트워크 어드레스를 기반으로 라우팅을 하며 4계층 스위치는 4계층 프로토콜의 헤더 정보를 이용하여 정책 기반의 라우팅을 수행한다.


또한, 4계층 스위치는 어플리케이션에 따라 트래픽에 대한 우선 순위부여 기능도 수행한다. 이 기능은 네트워크 관리자들에게 어플리케이션을 제어할 수 있는 능력을 제공한다. 그리고 4계층 스위치는 네트워크 전반에 대한 CoS(Class of Service) 구현 방법을 제공한다.


4계층 스위치를 도입할 경우에는 다음 몇 가지 사항을 사전에 고려해야만 한다.


▶ 포트에 대한 우선 순위 부여 방안

어떤 어플리케이션이 어떤 포트를 사용하고 있는가? Well-known 포트 이외의 포트 번호를 사용하고 있는 어플리케이션의 포트 번호를 정확하게 파악하고 있어야만 Mission-critical Application에 상응하는 우선 순위를 부여할 수 있다. 또한, 포트 번호가 동일한 어플리케이션을 여러 명의 사용자가 동시에 사용하고 있다면 무엇을 기준으로 우선 순위를 부여할 것인가? 또한, 시시각각으로 포트 번호가 바뀌는 어플리케이션에 대해서는 어떤 방식으로 우선 순위를 부여할 것인가?


▶ 표준화 작업

아직까지는 복합(Heterogeneous) 네트워크 환경에서의 4계층 스위칭에 대한 표준이 없다. 즉, 여러 제품 공급업체들 간의 우선 순위 부여 방식이나 처리 방식이 서로 달라서 상호 운용성 (Interoperability)이 떨어진다.


▶ 중복 기술

IEEE 802.1p 표준도 트래픽에 대한 우선 순위 부여 기능을 가지고 있으며 4계층 스위치도 우선 순위 부여 기능을 가지고 있다. 이 경우, 언제 어떤 기술을 사용할 지를 결정해야 한다.


4계층 스위치는 어플리케이션 기반의 트래픽 우선 순위 부여 분야에서 많은 가능성을 가지고 있으나 네트워크 관리자는 4계층 스위치가 제공하는 고급 기술을 사용하기에 앞서 전술한 사항에 대한 준비를 갖추고 있어야 할 것이다.




Load Balancing(부하 분산) 기능


현재 많이 사용되고 있는 네트워크 장비들 즉, 2/3계층 스위치들이 네트워크 자체의 성능 개선을 통한 확장성 개선에 초점을 두었다면, 최근 등장하고 있는 4계층 이상을 지원하는 스위치는 사용자들에게 제공되는 서비스에 초점을 둔 장비들이라고 할 수 있다.


이런 스위치들은 게이트웨이(Gateway)와 마찬가지로 사용 목적에 따라 접두어가 붙는 경우가 많다. 즉, TCP/IP 네트워크와 IBM 호스트를 연동하기 위해 사용하는 게이트웨이를 3270 게이트웨이나 SNA 게이트웨이 혹은 SNA 서버라고 부르는 것처럼 부하 분산 스위치 또는 웹 스위치처럼 사용 목적에 따라 이름을 붙이는 경우가 많다.


인터넷의 보급 확산으로 기업과 단체는 물론이고 개인들도 웹을 통해 인터넷을 많이 사용하고 있다. 예를 들면, 웹 기반의 인트라넷, 쇼핑 몰, 검색 엔진, 사이버 주식 조회/거래, 사이버 스쿨 등이 널리 이용되고 있으며 앞으로는 더욱 더 많이 이용될 전망이다. 이런 서비스들의 특징은 다수의 사용자들이 동일한 내용(Content)에 동시에 액세스한다는 것이다.


사용자가 많지 않을 경우에는 단지 1 ~ 2대의 서버를 두고 캐싱 기술을 사용하여 어느 정도 원활한 서비스를 제공할 수 있으나, 사용자의 수가 늘어감에 따라 동시 접속 사용자 수도 늘어나게 되어 정체 현상이 발생하게 된다. 이럴 때는, 여러 대의 서버를 부하 분산 스위치에 연결하여 동시 접속 사용자들의 요청(Request)을 여러 대의 서버에 고르게 분산시켜서 원활한 서비스를 제공한다.

참고 : TCP 포트 번호
* TCP 포트 번호 0 ~ 1023은 네트워크 전체에서 어플리케이션이 사용하는 등록된 Well-known 포트 번호이다.
** ---- 에플리케이션층 프로토클 / 포트 번호 -----
----FTP / 20(데이타), 21(컨트롤)
----Telnet / 23
----SMTP / 25
----HTTP / 80
----NNTP / 119
----SNMP / 161, 162(SNMP 트랩)

Layer-4 Switching 개념이해(2)

Server Load Balancing(서버 부하 분산) 지원

서버 부하 분산
Internet을 기반으로 한 Network 환경이 날이 갈수록 복잡해지고 무거워지고 있다. 사용자들 client들은 예를 들어 HTTP라는 하나의 서비스를 받기 위해 Internet 어느 공간상의 실제 HTTP 서버에 접속하여 원하는 서비스를 받게 된다. 즉 서버가 Internet이라는 Network 환경에 붙어만 있다면 사용자들은 그것의 실질 적이며 물리적인 위치나 주소는 문제가 되지 않고 서비스를 받을 수 있다.
그러나 서버의 입장에서는 사용자들 client들의 입장보다 더 복잡한 문제를 갖는다. 사용자의 입장에서와 같이 서버도 Internet의 어느 한 공간에 접속되어 있다면 사용자에게 서비스를 제공하는 방법적인 문제에는 다를 것이 없으나, 서비스를 안정적으로 그리고 지속적으로 아주 많은 사용자들에게 제공하기 위해서는 서버 자신이 서비스를 처리할 수 있는 능력이 아주 강해야만 한다. 더 많은 사용자에게 정확한 서비스를 하기 위해서는 지금보다 더 강력한 성능의 서버 - 처리 능력이 우수한 - 로의 업그레이드가 거의 유일한 해결책이 되어 왔다. 그러나 현실적으로 무한정 서버를 업그레이드할 수는 없다.

위와 같은 문제를 해결하기 위하여 많은 방법들이 개발되었고 시도되었다. Cache Server를 두어 자주 참조되는 서비스를 WAN Traffic이 아닌 저장된 Local Traffic으로 처리하는 방법이나, 여러 개의 서비스, 예를 들어 HTTP, FTP, SMTP, POP3, NNTP 등를 각기 다른 서버에 두는 방법, 그리고 같은 기능을 하는 동급 수준의 서버를 여러 대 두어 전체 트래픽의 일부분만을 담당하게 하는 방법이 그것이다.


마지막 방법은 기존의 서버보다 아주 고성능의 서버 한대를 구입하는 것보다 동급 수준의 서버를 여러 대 두고, DNS에 같은 URI에 서로 다른 서버의 IP 주소를 할당함으로써 URI 참조시 각기 다른 서버에 서비스를 접속시켜주는 방법으로 서버 한대가 모든 서비스를 주관할때 보다 가격대 성능비로 우수한 효과를 낼 수 있다. 그러나 DNS에 의한 서버 부하 분산 방법은 IP 할당시 Round-Robin 방법이 사용하기 때문에 특정 서버의 장애나 경로상의 문제가 발생할 때는 원래의 목적했던 부하 분산을 하지 못할 수 있게 된다.


4계층 서버 부하 분산 Server Load Balancing (이하 SLB)이란 DNS에 의존하지 않고 다수의 서버들을 하나의 VIP (가상 IP 주소)로 묶어 사용자들에게는 VIP 만을 알려주고 SLB 제어를 통하여 IP address 뿐만아니라, 4계층의 TCP/UDP Port 로도 어떠한 서버의 장애에도 서버들간에 올바른 부하 분산을 할 수 있게 해주는 방법이다.

4계층 스위칭과 서버 부하 분산
▶ 4계층 프로토콜 유형(Type) 별로 트래픽 스트림(Stream) 구분
⊙ TCP 또는 UDP Port 번호
⊙ 나머지 Traffic Stream은 TCP 만을 사용하거나 별로 많지 않음
⊙ Well Known Socket Type - 예를 들면, FTP, HTTP, POP3, NTTP 등
⊙ 사용자 정의 Socket Type - 4004, 4500, 8001 등
⊙ 세션(Session)을 다음과 같이 정의할 수도 있다.
⊙ 목적지 IP + TCP/UDP 목적지 Port 번호 + 출발지 IP + TCP/UDP 출발지 Port 번호

▶ 4계층 필터링(Filtering)
⊙ 서비스 차단(Deny Service) - 특정 IP 주소에 대한 FTP 트래픽을 허용하지 않음

▶ 4계층 QoS - Hi Priority 또는 Normal Queuing
⊙ 스태커블 장비는 High Queue와 Normal Queue 구현
⊙ BirIron은 4개의 Priority Queue 구현

▶ 4계층 서버 부하 분산
⊙ TCP/UDP port Type을 기준으로 부하 분배
⊙ Hot Standby Redundancy - 서버와 스위치에 대해 Failover 기능 제공

Layer-4 Switching 개념이해(3)

서버 부하 분산
⊙ 사용자들은 하나의 VIP (가상 IP 주소)로 접속을 하지만 실지로는 다수의 물리적인 서버들이 서비스 제공
⊙ Traffic은 4계층 (이하 L4) Type에 따라 특정 서버로 전달

(보기)
⊙ HTTP 트래픽은 서버 1과 2로
⊙ FTP 트래픽은 서버 2와 3으로
⊙ 그리고, Email은 서버 4로

3가지 접속(Connection) 분산 정책
⊙ Round Robin - 차례대로 서버에 연결
⊙ Least Connections - Connection 갯수가 가장 적은 서버로 연결 (가장 최근의 접 속 요청 시점을 기준으로 함)
⊙ Weighted Distributions - 백분율(%)을 기준으로 부하 분배
⊙ 실제 서버 당 최대 접속 수를 설정, 집행
⊙ 서버의 용량 초과 문제를 없앰
⊙ 다른 유형의 트래픽은 초기 구성된 대로 실제 서버에 연결

서버/서비스 장애 복구
▶ 수차에 걸쳐 연속적으로 접속 장애가 감지되면 해당 서비스는 사용할 수 없는 것으 로 간주한다.
(사용자가 정의 가능하며 디폴트 값은 2)
⊙ 동일한 서비스를 제공하기 위해 사전에 구성된 다음 서버로 Failover (즉, HTTP, FTP, POP3, NTTP, 사용자 프로그램 등)
⊙ 그림에서, 서버 #2 상의 HTTP 서비스에 장애가 발생했으나 FTP 서비스는 여전히 동작 중임
⊙ 다른 서비스 포트(서비스 Port)들은 분배 정책(Round Robin, Least Connection, Weighted)에 대한 Pool이 된다.

▶ 장애가 발생했던 서비스가 복구되었는지를 주기적으로 검사한다 (검사 간격은 사용자 가 정의할 수 있으며 디폴트는 매 30 초)
▶ 서버 전체를 다운 시키지 않고 특정 서 비스 (HTTP)만 다운 시킬 수 있으므로 다른 서비스는 계속 운용할 수 있다.

▶ 유지보수를 위해 서버를 대체/수리 한 뒤에 서버 팜 (서버 팜) Pool에 다시 넣을 수 있다.

스위치 장애 복구(Failover) - 탁월한 가용성
▶ 전용 Synchronization Link
⊙ 1초 이내에 주(Primary) 스위치의 장애를 감지
⊙ 케이블 장애에 대비하여 최대 4 회선의 트렁크 그룹(Trunk Group)을 사용할 수 있 음
▶ 다음에 대한 공통 도메인 필요(Common Domains)
⊙ 스위치들과 실제(Real) 서버들
⊙ 스위치들에 대한 이중 접속(Dual-connect) 서버들을 연결(Hub)

▶ 두 스위치가 동시에 트래픽을 “청취”
⊙ 주(Active) 스위치는 클라이언트의 트래픽을 실제 서버로 전달
⊙ 백업(Standby) 스위치도 Network Address Translation (NAT) Table을 구축하나 대기 (Standby) 상태일 경우에는 어떤 그래픽도 전달 하지 않음

▶ 두 스위치 모두 동일한 MAC 주소로 지정 (대개는 Primary 스위치의 MAC 주소)
⊙ 백업 스위치 주소를 찾기 위해 ARP를 다시 하지 않음 (이유 - Primary와 동일하므로)
⊙ 클라이언트들은 백업 스위치가 활성화(Active) 상태에 있다는 것을 전혀 감지하지 못함
⊙ 백업 스위치가 활성화 상태로 되면 이를 알리기 위해 SNMP Trap을 생성

▶ 스위치에 장애가 발생할 경우 …
⊙ Sync Trunk는 초 당 10회 폴링(Polling)
⊙ 주 스위치가 백업 스위치와 통신에 실패하기 전까지의 동기화 된 세션 정보는 그대로 유 지됨
⊙ 장애가 발생하면 Backup 스위치가 “Active” 상태로 되어 제어권을 행사
⊙ 서버에 대한 클라이언트의 접속은 주 스위치에서 백업 스위치로의 Failover 동안에도 유 지됨.
⊙ 망실된 패킷(Packet)에 대한 재시도는 클라이언트/서버가 재개

▶ 주 클라이언트나 하위의 라우터는 ARP를 할 필요가 없음
⊙ 두 스위치는 동일한 MAC 주소로 구성되어 있음
⊙ 장애동안, 백업 스위치는 “Active” 스위치로 동작하여 트래픽이 흐르게 됨

▶ 서버 팜이 운용되는 중에 Primary 스위치를 교체할 수 있음
백업 스위치는 주 스위치가 Sync Link에 연결되었음을 감지하여 다시 “비활성(Inactive)” 상태로 Fallback 한다