로컬 스위칭 성능 확인 필수 … 보안성·포트 집적도·응용 기능 중요

김재한
포스텐코리아 차장
jaehan@force10networks.com

지금까지 차세대 백본 네트워크로 주목받고 있는 10기가비트 이더넷 기술의 현주소에 이어 대표적인 응용 솔루션에 대해 살펴봤다. 이번 호에서는 10기가비트 이더넷을 이용한 솔루션 채택 및 구축 시 반드시 고려해야 할 사항에 대해 논하고자 한다. <편집자>

사실 지난 호의 10기가비트 응용 솔루션에 대한 가장 기본적인 조건은 10기가비트 장비 자체가 상당한 안정성을 가지고 있다는 생각에서부터 출발한 것이었다. 만약 이러한 조건이 충족되지 않는다면 그간 언급했던 여러 응용 솔루션 중 일부는 필자가 언급한대로 구현할 수 없는 네트워크 구성이다. 이처럼 네트워크 구성 자체를 변경할 만큼의 중요한 사항인 안정성을 가장 먼저 언급하는 것은 당연하다. 안정성에 부분에 대해 소프트웨어 아키텍처와 포워딩 아키텍처서의 2가지에 대해 언급한다.

안정성 - 소프트웨어 아키텍처
소프트웨어 아키텍처는 근본적으로 장비가 안정적인가 혹은 그렇지 않는가라는 가늠을 해 볼 수 있는 중요한 잣대다. 이것은 여러 분야에서 쉽게 찾을 수 있는데, 우리가 많이 이용하는 컴퓨터 운영체제에서도 쉽게 찾을 수 있다. 필자가 PC 운영체제에 대해 아는 것은 별로 없지만 실제로 윈도 98을 사용할 때보다 현재 사용하고 있는 윈도 XP가 훨씬 안정적이다라고 느끼고 있다.
일반적으로 네트워크 장비의 소프트웨어 아키텍처는 두 가지로 나뉜다. 첫 번째는 모노리틱(Monolithic) 소프트웨어 아키텍처다. 모노리틱 소프트웨어 아키텍처는 과거 네트워크 장비가 처음 등장했던 시기에 시작돼 현재까지도 상당히 많이 이용되고 있는 방법이다. 이 방법은 소프트웨어를 하나의 커다란 응용프로그램으로 설계하는 것이다. 이는 구현 용이성에 있어 나중에 소개할 모듈러(Modular) 소프트웨어 아키텍처 보다는 쉽지만 치명적인 문제점을 몇 가지 내포하고 있다.
이 중 가장 심각한 문제점은 바로 메모리 보호(Protection)다. 모노리틱 소프트웨어 아키텍처는 근본적으로 몇 개의 응용프로그램이 동시에 동일한 메모리 영역을 예약 사용할 수 있다는 위험성을 내포하고 있다. 이러한 상황이 발생하면 소프트웨어는 어떻게 처리해야 할지 모르기 때문에 응용 프로그램의 동작이 중단되는 크래시(Crash)가 발생하거나 혹은 시스템 자체의 크래시로 연결될 수 있다. 또한 소프트웨어의 버그로 인해 어떤 응용 프로그램이 일정 메모리 영역을 사용하고 반납하지 않는 경우에도 이러한 치명적인 결함이 발생할 수 있다. 메모리가 반납되지 않아, 결국에는 다른 응용프로그램이 사용하지 못하기 때문에 이도 응용 프로그램과 시스템 크래시로 연결될 수 있다.
반면 2000년 초에 개발된 제품들은 이른바 모듈러 소프트웨어 아키텍처를 이용하고 있다. 이것은 각각의 모든 응용 프로그램들을 모듈화 한 것으로 해당 모듈들은 각각 고유한 메모리 영역을 할당받는다. 이런 응용프로그램들은 BGP, OSPF 등의 라우팅 프로토콜뿐 아니라 인터페이스의 상태를 감지하는 애플리케이션, IPv4의 라우팅 정보만을 담당하는 애플리케이션 등 우리가 상상할 수 없을 만큼의 애플리케이션을 모두 모듈화 한 것이다.
이러한 모듈러 소프트웨어 아키텍처의 장점은 앞서 언급한 메모리 보호 관련 장애가 거의 없다는 점이다. 다만 모듈러 소프트웨어 아키텍처는 각 모듈들 사이의 싱크(Synchronization)를 어떻게 잘 맞추는가가 관건이다. 이러한 근본적인 안정성 차이 때문에 많은 제조업체가 모듈러 소프트웨어를 사용하고 있거나 모듈러 소프트웨어로 바꾸고 있다. 또한 새로운 기능의 추가나 기존 애플리케이션의 유지 보수가 모듈별로 가능하기 때문에 모노리틱 소프트웨어 아키텍처 보다 월등한 확장성을 지니고 있다.

다음 <표>는 모듈러 소프트웨어 아키텍처를 사용하고 있는 포스텐 제품을 사용하는 고객들이 어느 기간 동안 무장애로 장비를 운영하고 있는지 나타내고 있는 사례다. 10기가비트를 지원하는 라우터나 스위치 제조 업체중 모듈러 소프트웨어 아키텍처를 채용하고 있는 회사는 포스텐의 전 제품을 비롯 익스트림, 시스코 제품 등이 있다.

안정성 - 포워딩 아키텍처
포워딩 아키텍처라는 것은 사용자로부터 패킷이나 프레임을 받을 경우 이것을 어떻게 처리하는가를 나타내는 이름이다. 이러한 포워딩 아키텍처는 크게 플로우 기반(Flow Based) 아키텍처와 FIB(Forwarding Information Based) 기반으로 나뉜다. 플로우라는 용어는 마이크로 플로우에서 유래했으며, 일반적으로 다음의 5가지 인자를 갖는다.

· 출발 주소(Source IP)
· 목적 주소(Destination IP)
· 프로토콜 종류(TCP/UDP/etc)
· 출발 프로토콜 주소(Source Port Number)
· 목적 프로토콜 주소(Destination Port Number)

위의 5가지 인자 중 하나만 틀려도 플로우는 다르다고 말한다. 가령 1.1.1.1에서 2.2.2.2로 HTTP 트래픽과 FTP 트래픽이 있다라고 하면 플로우는 송/수신을 합쳐 모두 4개가 존재한다.
플로우 기반 장비에서는 첫 번째 플로우가 장비로 인입되게 되면, 즉 자신의 메모리 영역 어딘가에 해당 플로우 정보가 없다면 이 플로우를 어떻게 처리해야 하는지 결정하기 위해 해당 장비의 제어모듈 CPU로 보내게 된다. CPU에서 라우팅 테이블이나 혹은 MAC 주소 정보를 참조해 이 플로우를 처리하고, 해당 결과 플로우 정보를 메모리에 쓰게 된다. 이 후부터 들어오는 동일한 내용의 플로우는 CPU로 향할 필요 없이 메모리만 참조하고 보내게 된다.
사실 이러한 플로우 기반 포워딩 아키텍처는 사용량이 그 다지 많지 않던 예전에는 그리 크게 문제가 되지 않았다. 그리고 플로우 기반의 장비를 2계층 스위치로만 사용하고 네트워크의 총 사용량 혹은 PPS가 그렇게 크지 않는다면 지금도 문제가 될 것은 없다. 하지만 최근에는 스위치라고 하더라도 라우팅을 모두 사용하므로 이런 경우는 필히 문제가 생긴다.
2계층 전용인 경우에는 MAC 주소 정보만 사용하면 되지만, 3계층부터는 플로우 정보가 모두 이용된다. 이런 경우 TCP 목적 주소가 1번부터 65000번까지 바뀌어서 패킷이 들어온다면 모두 다른 플로우로 인식하므로 6만5천개의 패킷은 모두 CPU로 향해야 한다. 만약 TCP 출발 주소와 목적주소가 모두 바뀌어 들어오고 웜 바이러스가 활동하게 되면 플로우의 양은 65000×65000=42억개의 신규 플로우가 장비로 인입되는 결과를 낳는다.
독자들은 이게 문제될 것이 무엇이 있는가라고 반문하겠지만, 일반적으로 최근 장비의 CPU는 초당 최고 약 20만개 정도의 플로우 밖에는 처리하지 못한다. 따라서 이러한 형태의 웜 바이러스가 활동하게 되면 플로우 기반의 장비들은 매우 불안정해지며, CPU가 처리할 수 있는 것보다 많은 플로우가 들어오게 되면 일반적으로 드롭을 시키기 때문에, 사용자의 트래픽이 제대로 처리되지 않는 일들이 발생하게 된다.
이에 비해 FIB 기반의 제품들은 전혀 다르게 동작한다. 패킷을 어떻게 처리해야 할지 알려주는 정보인 라우팅 혹은 포워딩 정보를 위해 목적 주소(Destination IP address)만을 이용한다. 앞서 언급한 42억개의 플로우가 발생한다 하더라도 해당 목적 주소가 있다면 그냥 그리로 보내는 것이다. 주소만 있으면 된다. 주소가 없으면 폐기시켜 버린다. 이것은 플로우를 만들고, 저장하는 개념이 아니라 목적 주소를 알면 보내고 알지 못하면 보내지 않는 아주 간단한 개념이다. 여기서 목적 주소란 3계층 기능이 활성화되면 목적 IP 주소고, 2계층으로만 이용이 되면 목적 MAC 주소다.
3계층 목적 주소를 얻는 방법은 독자들도 잘 알겠지만 라우팅 프로토콜이다. 현재 전 세계적으로 이용되고 있는 3계층 주소를 전달하는 방법인 BGP(Border Gateway Protocol)의 테이블 개수는 14만개 정도이다. 즉 전세계 불특정 영역으로 향하는 플로우가 수 십억 개 혹은 수 천억개가 인입된다 하더라도, FIB 기반의 제품은 BGP를 이용한다면 14만개의 테이블만 있으면 되는 것이다. 만약 기본 정적 루트 정보(Default Static Route)만을 이용한다면 플로우의 개수가 수백 억 혹은 수 천 억개가 발생한다 하더라도 FIB 1개만으로 해당 플로우를 처리할 수 있다. 좀더 정확하게 표현하면 플로우의 수와 관계없이 모든 플로우를 처리할 수 있다.
이러한 FIB 기반 아키텍처는 일반적으로 라우터에서 많이 이용되고 있다. 하지만 최근에는 3계층 스위치에서도 이용되고 있다. 10기가비트를 이용한 백본 업그레이드나 신규 망 계획이 있다면, 백본 용량과 안정성을 고려해 반드시 FIB 기반의 제품을 선택해야 한다는 점이다. FIB를 기본으로 채택하고 있는 회사는 포스텐, 시스코 등이 있다.

성능
지난 호 10기가비트 응용 솔루션 사례를 보면 클러스터 그리드 컴퓨팅 응용 사례가 있다. 이러한 10기가비트의 응용 솔루션의 성공적인 구현은 안정성뿐 아니라 10기가비트 이더넷을 지원하는 장비들이 100%의 성능을 지원하고 언제나 동일한 성능을 보장하는가에 달려 있다. 하지만 이러한 성능은 ‘장비가 로컬 스위칭을 하지 않으면서 100%의 성능을 지원할 수 있는가’라는 보다 근본적인 질문에 대한 긍정적인 답변을 줘야만 가능한 응용 사례다.
로컬 스위칭이란 장비가 동일한 라인카드에서는 스위칭 패브릭을 거치지 않고 패킷을 바로 처리한다는 개념이다. 이러한 로컬 스위칭은 동일 라인카드 내에서는 100%의 성능과 보다 빠른 응답 속도를 고객에게 제공할 수 있지만, 다른 라인카드로 이동시에는 100%의 성능을 보장하지 못하는 단점이 있다. 물론 로컬 스위칭을 하는 장비들도 다른 라인카드 간에도 100%의 성능을 보장할 수 있지만 일반적으로 로컬 스위칭을 하는 장비들은 라인카드와 스위칭 패브릭 간의 통신 채널의 유효폭(Bandwidth)이 크지 않으므로 대부분의 경우에 있어 100%의 성능을 보장하지 못한다. 또한 고객에게 예측 가능한 성능을 보장할 수 없기 때문에 언제나 동일한 응답 속도와 결과를 요구하는 응용 솔루션에는 적합하지 못하다.
또한 다량의 10기가비트 이더넷 포트를 요구하는 ISP 등의 고객에게도 이러한 로컬 스위칭을 기본으로 하는 장비의 선택은 10기가비트 이더넷의 포트수가 증가하면 증가할수록 이에 반해 성능이 계속해서 떨어지기 때문에 10기가비트 이더넷을 구현할 때 반드시 고려해야 할 필수 사항이다. 이에 반해 논블록킹 기반의 분산 스위칭 구조는 언제 어디서나 동일한 성능을 보장하기 때문에 고객은 항상 동일한 응답 속도를 예상할 수 있어 망의 확장이나 업그레이드에 따른 예측 가능한 확장 시나리오를 제공할 수 있다.

기타 고려 사항
10기가비트 이더넷 응용 솔루션 구현시 고려해야 할 사항은 이 밖에도 장비 자체의 보안성, 포트의 집적도, 다양한 응용 기능 등이 있다. 특히 이 가운데에서도 보안성은 무시할 수 없는 분야다. 장비 자체가 해킹 공격을 당해 관리자 권한을 잃어버리거나 웜 바이러스 및 DoS/DDos 등의 공격이 장비로 향할 때 효과적으로 차단하거나 안정적으로 장비가 운영돼야 한다. 이 가운데에서 안정성은 이미 첫째 고려사항에서 언급했다.
DoS/DDoS 등에 대한 공격이 10기가비트 이더넷 장비 자체로 향할 때의 차단 방법은 현재로서는 제어 모듈의 CPU로 접근하는 비정상 트래픽을 차단할 수 있는 액세스 컨트롤 리스트(ACL)를 하드웨어적으로 구현한 FPGA 혹은 ASIC이 제어모듈에 탑재돼 있는가를 살피는 것이 최상의 방법이다.
포트의 집적도 또한 무시할 수 없는 고려사항이다. 최근의 추세는 단일 라인카드에 4포트 혹은 8포트 10기가비트 이더넷을 지원하는 카드가 속속 출시되고 있다. 고객 입장에서는 운용비용 및 투자비용 절감을 위해 보다 고밀도의 카드를 고려하는 것도 바람직하다.