“클라우드컴퓨팅을 위한 네트워크 설계를 말하다.”

본 글은 필자가 네트워크 타임즈 단행본 "클라우드 빅데이터"에 기고한 글입니다.

(스크롤 압박 졸라 심함)

클라우드 컴퓨팅을 제대로 구현하는 데 있어서는, 가상화 서버와 물리적 서버의 설계, 스토리지의 올바른 선택과 디자인을 많이들 떠올리게 마련이다.
하지만 또 하나의 중요한 근간이자 축이 바로 네트워크 설계이다.

필자는 클라우드 컴퓨팅 프로젝트에 참여하면서, 이러한 이슈와 다양한 고객의 요구사항들을 자주 목격하고 접했다.

이러한 경험을 토대로 클라우드 컴퓨팅 기반의 데이터센터를 설계할 때 네트워크 측면에서 고려할 사항들에 대해 몇가지 소개하고저 한다.

수평적 구조의 네트워크 - Cisco Nexus 스위치

네트워크 설계에 있어서 가장 중요한 기술들은 대부분 Layer 3 기반의 라우팅 기술과 Layer 2 기반의 스위칭 기술이다.

특히 일반적으로 캠퍼스 네트워크라 불리우는 건물내부 설계 및 건물간 설계에 있어서 주로 논의 되는 설계 사상은 라우팅테이블, MPLS/BGP, VRF와 같은 기술과 스위칭 패브릭 용량과 모듈러 스위치의 슬롯은 몇 개며 포워딩 성능은 얼마나 되느냐? 와 같은 철저히 캠퍼스 스위칭 기술이 주가 된다.

매우 일반적이고, 단순한 반론이지만 사실 데이터센터 네트워크에서는 이러한 부분들이 중요도가 높은 것은 아니다. 실제 캠퍼스 네트워크는 상,하로 흐르는 종적인 트래픽 플로우를 중점해서 설계하지만, 데이터센터 네트워크는 좌,우로 흐르는 횡적인 트래픽 플로우를 중점적으로 설계하는 것이 맞다.

쉽게 예를 들어 설명하자면, 데이터센터의 서버들은 대부분 물리적 구성별 또는 논리적 구성별로 하나의 서비스들의 집합체 인데, 하나의 서비스는 3Tier 구조로 이뤄져 있다.
웹서버, WAS 서버, DB 서버로 이뤄져 있고 이들 트래픽은 외부에서 웹으로 액세스한 이후 모두 횡으로 흘러다니는 트래픽이다. 여기에 DB 트랜젹션을 통해 값이 수정되거나 기타 다른 데이터가 변경될 때 스토리지의 원본 데이터도 변경이 일어나고 , 스토리지는 다시 1차, 2차 백업이 일어난다. 심지어 3차 백업은 DR 사이트의 스토리지에 저장하는 방식이다.

 

[그림1-전통적인 데이터센터의 네트워크 구조]

그렇다면 여기서 종으로 흐르는 트래픽은 사실은 웹서비스에 국한이 된다.

나머지는 모두 종적인 트래픽이다. 그런데 우리는 데이터센터를 설계할 때 항상 종적인 흐름에만 집중한다는 것이다. 실제 데이터센터의 트래픽은 8:2 이상의 비율로 횡으로 흐르는 트래픽이 많다는 결과도 많다.

만약 네트워크 설계가 이러한 서비스 구조에 맞지 않고, 웹서버와 WAS 서버, DB 서버를 별도의 네트워크로 분리해서 사용한다면 데이터센터는 어떤 응답속도와 피드백을 얻을 수 있을까?
웹서버가 WAS서버로 이동하기 위해 액세스 스위치, 분배 스위치를 거쳐, 극단적으로는 코어 스위치까지 거쳐서 다시 WAS 서버가 위치해 있는 분배 스위치와 액세스 스위치를 가야 하므로 흔히 말하는 Hop이 여러 개 발생할 것이다. 또한 Hop을 거칠 때 마다 응답시간은 저하 될 것이다.
이것이 오늘날 데이터센터의 현재 모습이다.

일반적으로 캠퍼스 네트워크는 응답시간이 초단위 차이는 사용자가 느끼지 못하고, 중요도가 높진 않지만 데이터센터에는 무수한 어플리케이션과 DB가 존재하므로 서비스와 해당 어플리케이션에 따라 응답시간은 매우 중요하다.

따라서 데이터센터, 그리고 클라우드 컴퓨팅센터에서는 데이터센터를 되도록 이면 수평적 구조의 설계를 구성하는 것이 바람직 하다. 그래서 최근 시스코, 주니퍼, 브로케이드와 같은 데이터센터 네트워킹을 주도하는 벤더들은 모두 수평적 구조의 네트워크를 이야기하고 있다.

네트워크의 계위를 최소화 한 후 , 서버들과 그 안에 있는 가상화 서버들이 수평적 환경에서 움직이도록 함으로써 서버 이동을 자유롭게 하고 응답시간을 최소화 하겠다는 것이다.
하지만 여기에도 함정은 존재한다. 바로 네트워크 단위가 IP 서브넷이나 Vlan으로 분류됨에 따라 어차피 수평적 구조라고 하더라도 라우팅 프로토콜이 동작하고 , 네트워크 장비의 제어를 받게 된다는 것이다.

또한 기존의 데이터센터 Layer2 구성은 대부분 STP(Spanning Tree Protocol)을 사용하고 있음에 따라 대역폭의 절반만 사용할 수 밖에 없는 구조라는 점도 더욱 데이터센터 네트워크 운영을 어렵게 하고 있다.

그래서 현재 시스코에서는 Fabric Path라는 표준화 기술 TRILL을 기반으로 하여, L2 네트워크에서 라우팅 기술과 같은 기반기술을 탑재했다고 보면 쉽게 이해할 수 있다.

물리적으로 연결된 모든 스위치는 몇 개의 홉을 거치던 Fabric Path를 적용하게 되면 하나의 공유하는 네트워크로, 단일된 네트워크로 구성이 된다. 또한 관리자가 특별하게 구성을 하지 않아도 Plug-N-Play 처럼 자동 구성할 수 있다.

가장 중요한 점은 Layer2라는 기술을 쓰면서 Layer3 처럼 계층적인 구조형태의 제어를 구현하여 물리적으로 수평적이지만 논리적으로는 계층적으로 사용할 수 잇음에 따라, Layer2의 단점을 극복하고 Layer2 장점과 Layer3 장점만을 결합하는 형태로 사용한다는 것이다.

이렇게 되면 데이터센터는 매우 수평적인 구조로 사용될 수 있게 됨에 따라 더욱 빠른 응답시간과 간결하고 확장된 연결구조를 수립할 수 있다.

 
[그림2-시스코 데이터센터 기술을 적용한 수평적 네트워크 구조]

단일 네트워크, Unified Fabric

데이터센터에서는 주로 패브릭이라는 용어를 많이 사용한다.
이러한 패브릭이라는 용어를 생소하고 어렵게 느끼는 경우가 많으나 의외로 아래와 같이 간단명료한 개념을 가지고 있다.

①    네트워크 패브릭 : 네트워크 IO를 처리하는 네트워크 장비의 모든 데이터 흐름을 제어하는 데이터,제어부를 포함하는 용어

②    SAN 패브릭 : SAN IO를 처리하는 SAN 장비의 모든 데이터 흐름을 제어하는 데이터,제어부를 포함하는 용어

③    관리 패브릭 : 데이터센터 전체 장비를 관리하는 네트워크

네트워크 구조를 아무리 수평한 구조로 혁신 한다고 하더라도, SAN 패브릭과 관리에 대한 패브릭은 엄연히 별도로 존재해야 한다. 재밌는 사실은 이 패브릭의 종류에 따라 관리조직도 별도로 데이터센터내에 존재한다는 것이다.

네트워크 패브릭을 관리하는 조직은 네트워크팀, SAN 패브릭을 관리하는 조직은 SAN/Storage 팀, 이 모든 패브릭을 교집합으로 연결하는 조직이 서버팀이다.

이렇게 패브릭이 많아짐에 따라 비효율적인 계층들이 생겨나고, 이러한 계층을 통합,단일화 하고저 나온 개념이 바로 Unified Fabric 이다.

Unfied Fabric은 FCoE(Fiber Channel Over Ethernet)을 기반으로 데이터센터의 장비들과 서버의 IO Card, 그리고 스토리지 까지 이러한 기술을 담게 되면 별도의 패브릭과 연결구조가 단일화 되도록 한다.

이러한 솔루션을 구성하게 됨에 따라 현재 데이터센터의 구조 자체를 혁신적으로 변화할 수 있다는 큰 장점이 있다.

[그림3-전통적인 데이터센터 구조와 시스코 Unfied Fabric 기반의 데이터센터 아키텍쳐]

네트워크 관리 구조의 혁신 - Cisco FEX

데이터센터 네트워크가 점점 확장되다보면, 근본적으로 대두되는 문제로 패치판넬과 ToR(Top Of Rack), EoE(End Of Rack)과 같은 물리적인 구성과 관리 문제가 많이 등장한다.
비교적 데이터센터가 적은 구조에서는 그다지 느끼지 못하는 문제이지만, 중견기업급 이상의 서버룸이나 데이터센터의 경우 수많은 케이블 구성과 해당 스위치 관리에 대한 고민은 늘 존재해 왔다.
이러한 이슈를 해결하는 방식이 바로 FEX(Fabric Extender) 기술이다.

Fabric Extender 기술은 ToR 스위치가 패치판넬과 같은 역할을 동시에 수행하면서, 가상 샤시의 모듈로 동작하는 방식이다.

즉 ToR 스위치가 50대가 있다면, 50개 슬롯이 있는 대형 Chassis 스위치를 운영하는 방식이다.
이렇게 되면 관리 포인트가 단 하나로 줄어들게 되고, IP Address 역시 하나로 줄어 들게 된다.

뿐만 아니라 필요에 따라 ToR 스위치가 늘어나게 되면 대형 Chassis 스위치 역할을 하게 되는 네트워크 제어부가 포함된 장비에 연결만 하면 모듈을 추가하는 것 처럼 보이게 된다.

즉 데이터센터 전체 네트워크 관리를 단 하나의 장비에서 구현할 수 있다는 의미를 이야기 한다.

클라우드 컴퓨팅이 구현된 데이터센터에서 수많은 장비 관리가 버거운 현실에 네트워크 장비를 단하나의 운영제어권으로 전체 네트워크 장비를 관리한다고 생각해 보라.

이 얼마나 즐거운 상상인가? 즐거운 상상이 아니라 바로 현실이다.

가상화의 이동성을 보장하는 네트워크 구조

필자가 네트워크 업계 벤더 출신이다 보니, 클라우드 컴퓨팅 네트워크 환경에서 가장 많이 받는 질문의 네트워크가 다른데 VM Motion이 가능하냐는 질문이다.
사실 가상 서버가 어느 네트워크로 이동할 수 있느냐는 문제는 기술적으로 그리 어렵지가 않다.
문제는 이동을 하더라도 네트워크가 다르기 때문에, 서비스를 쓸수 없다는 것이다.

데이터센터의 물리적인 구성으로 보면 두가지 케이스가 있는데, 하나는 서로 다른 데이터센터간의 가상 서버가 이동이 가능하냐는 것이고, 또 다른 하나는 같은 데이터센터 내에서 서로 다른 호스트가 전혀 다른 네트워크에 연결되어 있을 때 이동성을 보장 할 수 있냐는 것이다.
현재 기술로 물론 가능하지만 이슈가 존재한다.

첫번째는 서로 다른 데이터센터 내부에서 가상화 서버를 이동하기 위해서는 같은 네트워크로 인지해야 하므로, MPLS/VPLS/EoMPLS와 같은 터널링 기반의 Tag Switching을 쓰거나 또는 물리적으로 데이터센터간 케이블 구성을 해야 한다.

문제는 Tag Switching을 하더라도 서버들의 Mac 어드레스 학습과 주기적으로 일어나는 ARP Flooding 현상으로 한쪽에서 발생한 Flooding 문제가 다른 데이터센터까지 영향을 미칠 가능성이 매우 높다는 것이다.

또한 물리적으로 광케이블을 원거리에 접속한다는 것은 비용적 문제가 고민이 된다.

시스코는 이러한 문제를 해결하기 위해 OTV(Overlay Transport Virtualization) 기술을 적용한다.
이 기술은 이미 전세계 1500개 레퍼런스를 보유하고 있으며, Nexus 7000의 스위치를 통해 원거리 데이터센터간 같은 네트워크 인 것 처럼 OTV 기술이 터널링을 열어 주게 되면 자유로운 가상화 서버 이동이 가능하다.

MPLS나 GRE와 비슷한 구성으로 보이겠지만, 데이터센터가 많아 질 수로 복잡한 병렬 구성과 ARP Flooding 현상에 대한 이슈는 해결할 수 없다. 그런데 OTV는 병렬구성이 필요없고, 손쉬운 구성으로 Point to Point 구성을 할 수 있으며, ARP 관리를 데이터부가 아닌 제어부에서 하드웨어 기반 관리를 하게 되므로 이에 대한 부담도 없다.
따라서 데이터센터 간 가상 서버 이동을 자유롭게 할 수 있다.

뿐만 아니라 시스코는 데이터센터 내부의 VM 이동을 네트워크 구성환경에 구애 받지 않고 이동할 수 있도록 VxLAN이라는 기술을 VMware, Citrix, Redhat 등과 함께 표준화 등재를 완료 했으며, OpenStack 네트워크 플랫폼인 Quantum 에 포함 시켰다.

따라서 네트워크 구성에 관계 없이 자유로운 VM 이동이 가능해 졌다.

 
[그림4-Cisco OTV 기반의 데이터센터간 가상화 서버 이동기술]

가상화 네트워크를 단순하게...

클라우드 컴퓨팅 구조에서 가장 모호한 부분이 바로 서버와 네트워크 연관성 부분이다.

특히 데모나 파일럿 형태의 클라우드 컴퓨팅 구조에서 등장하지 않던 이슈가, 실제 프로덕션에 투입되어 규모가 커질수록 큰 골치덩어리가 바로 네트워크 구성이다.

그 핵심에 바로 하이퍼바이저에 기본 구성되는 가상 스위치이다.

사실 가상 스위치는 VMWare,Ctirxi,MS 대부분 스위치라는 이름이 무색하게 과거 브릿지 정도의 수준을 보여 준다. 

저가형 물리적인 스위치에서 기본 제공되는 보안정책, 포트미러링, QoS 등이 구현이 불가능하고, MAC Rewrite 등이 불가능하여 가상화 서버들이 특정 서비스로 트래픽을 우회할 수 있는 방법들도 없다.

이런 상황이다 보니 서버가 많아 질수록 가상스위치에 대한 기술적, 관리적인 고민이 깊이가 깊어진다.

이러한 고민을 해결하기 위해 나온 기술이 바로 가상스위치의 모든 제어부와 관리부를 외부의 별도 장비에서 관리하는 방식이다. 이렇게 되면 서버 담당자는 더 이상 가상 스위치에 대한 부담을 고민하지 않아도 되고, 네트워크 담당자는 서버를 굳이 관리하지 않으면서 외부에서 제어와 관리를 통해 전체 가상 스위치를 관리할 수 있으므로 매우 편리하게 구성할 수 있다.

또한 기존 스위치 기능에서 제공하는 보안, QoS, 포트 미러링, Netflow등을 사용할 수 있게됨에 따라 네트워크 관리의 연속성을 그대로 유지할 수 있다는 큰 장점이 있다.

뿐만 아니라 장기적으로는 실제 스위치 기능이 서버에 소프트웨어 기반으로 탑재되어, 가상화 내부에 방화벽이나 어플리케이션 가속기, L7 스위치등을 사용할 수 있도록 MAC address Rewrite 기능을 지원하므로 각종 네트워크 서비스를 물리적 환경과 동일하게 쓸 수 있다는 점도 큰 장점에 해당된다.

 
[그림5 – Cisco Nexus 1000V 기반의 가상화 스위치 기반 기술 모델]

앞서 클라우드 컴퓨팅 환경에서의 네트워크 설계에 고려할 점들과 솔루션을 살펴보았다.

이밖에도 클라우드 컴퓨팅 환경에서의 네트워크 설계 사상은 무수히 고려할 점이 많다.

모두 소개할 수는 없겠지만 , 가장 중요한 점은 클라우드 컴퓨팅에서 매우 중요한 부분이 바로 네트워크 설계이다.

아무리 서버 설계와 가상화 구현이 잘되어 있더라도 모든 트래픽이 흘러다니고, 가상화 서버가 이동하는 길은 모두 네트워크이다.

필자는 지난 수년간 클라우드 컴퓨팅 설계에 참여하면서, 대규모 고객들이 어려움을 겪는 모습을많이 보아 왔고, 그 중 많은 부분이 네트워크 이슈였다는 점을 자주 목격했다.

클라우드 컴퓨팅은 어느 하나의 인프라만 잘 설계 된다고 해서 제대로 구현할 수 있는 것이 아니다.

최소한 클라우드 컴퓨팅의 인프라 전체가 잘 구현되고 유연성을 확보하기 위해서는 클라우드 컴퓨팅의 네트워크를 제대로 설계하는 방법론에 있다는 점을 꼭 인지해야 한다.