Network Overlay - OTV 1편

Network Overlay - OTV 1편

네트워크 Overlay에 대한 2번째 연재편으로 OTV(Overlay Transport Virtualization)에 대해 이번달 부터 올리기로 했다.

전통적으로 데이터센터의 가장 큰 고민은 바로 DR에 대한 고민이다.

DR은 Disaster Recovery의 약어로, 말 그대로 현재 운영 중인 데이터센터가 장애가 발생했을 때 빠른 시간내에 Recovery를 할 수 있는 기술을 의미한다.

DR은 기본적으로 주로 FC 또는 FCIP 기반의 DR이 주를 이루었다.

FC기반의 DR을 하는 경우는 주로 근거리 이내의 Sync 방식의 동기화 구성을 하는 경우를 주로 사용하고, FCIP 기반의 DR을 하는 경우는 주로 원거리의 Async 방식의 비동기화 구성을 하는 경우이다.

FC,FCIP 모두 기본적으로는 SAN 방식이라고 할 수 있는데, 이러한 SAN 기반 즉 FC 기반의 DR을 선호하는 이유는 , 바로 데이터 보호에 있다.

기본적으로 DR에서의 핵심은 데이터 보호 이므로, Lossless 방식을 사용하는 FC SCSI 통신이 주를 이룬다. FC, FCIP가 동기화, 비동기화에 대해 주로 논의되는 이유는 별도의 연재를 통해 다루도록 하겠다.

어쨌든, DR은 기업에 있어서는 아주 중요한 기술 중 하나이다.

DR에 대해 새삼스럽게 거론하는 이유는 가상화 또는 클라우드 기반에서의 DR 을 어떻게 네트워크 측면에서 바라보느냐는 이슈 때문이다.

특히 DR을 위해 데이터센터를 별도로 짓는 경우, 보통 수백억 이상의 비용이 들게 마련이다.

뿐만 아니라, 데이터센터를 임대해서 사용하는 경우에도 DR 구성 비용만 만만치 않게 들게 된다.

따라서 TCO(Total Cost Ownership)이 더욱 중요해지는 최근에는 더욱 더 DR에 대한 진지한 고민들이 이뤄진다.

필자도 최근 국내에서 DR Cloud 또는 DR에 대한 효율성을 자주 접하게 된다.

결론은 DR을 Active DataCenter로 운영하면서, Active/Active DataCenter에 대한 논의가 이뤄지고 있는 것이다.

Storage 측면에서는 볼륨들이 두개의 서로 다른 데이터센터의 디스크들이 볼륨 구성이 되는 방식이 필요하고, 네트워크 측면에서는 IP에 대한 이동성이 자유로워져야만 가능해 진다.

특히 HA 측면으로 보면, vmotion과 같은 Live Migration이 가능한 구조가 되어야만한다.

결국 네트워크 측면에서 생각을 해보면 IP Tunneling이 가능해야 IP 이동성이 자유로워지므로, Layer 2 기반의 VPN이 구현되어야만 한다.

결론적으로는 EoMPLS 또는 VPLS 아니면 돈은 쫌 들지만 Dark Fiber 즉 날광 까는 방법이 있다.

우선 EoMPLS는 Peer to Peer 라는 측면에서 Layer2 확장에는 한계가 있고, VPLS는 Peer to Multi Point가 가능하다. 마지막으로 그림에서 처럼 간편하게 날광 깔기가 있다.

날광깔기가 가능한 회사는 국내에 손꼽힌다.

그럼 Layer2 VPN을 사용하는 방법이 있는데....어떤 문제가 있길래, 실제는 이러한 방법을 사용하지 않을까?

첫번째 이슈가 바로 Data Plane(데이터부)을 타고 Layer 2에서 발생하는 MAC Flooding이 모든 데이터센터를 넘나드게 될 것이라는 점이다.

별 문제가 아니라고 생각할 수도 있지만, 가상화가 구성된 단일 VLAN 또는 다중 VLAN을 수많은 ARP Flooding이 다른 데이터센터로 넘나들수 있을 가능성이 매우 높다는 데서 위험도가 크다.

이것은 데이터센터를 중급 규모 이상을 운영해 본 사람이라면 모두 MAC Flooding의 이슈에 대해 고민할 것이다.

두번째 이슈는, 터널 관리에 대한 이슈이다.

Pseudo-Wire 에 대한 기술적 이슈인데, 어려우니 한국 발음으로 수도와이어 이슈....이다.

VPN을 Site to Site로 Full Mesh로 묶으려면, P to M이 아닌 이상 모두 P to P로 일일히 연결해야 할 것이고, 데이터센터간 이동성 확보를 위해 모두 연결을 해야 한다.

그런데 데이터센터당 두개의 터널 포인트가 있다고 하면, 데이터센터가 3개 되는 시점 부터 엄청난 터널 관리가 있어야 한다.

거기에다가 multicast, broadcast가 잦을 수록 대역폭에 대한 낭비도 고려해야 한다.

과연 관리가 원할히 가능할까?

세번째 이슈는, Multi-Homing 이슈인데...

Layer2의 고민을 그래도 L2 VPN에도 가져올 것이라는 점이다.

기존 L2 STP는 절반의 네트워크는 Blocking 상태로 가져가는 구조이다.

STP 이슈를 그대로 가지고 있는 구조에서 오는 불안감을 WAN에서 적용한다는 것 역시 엄청난 부담이 될 것이다.

이러한 이슈들을 해결하기 위해 나온것이 OTV 이다.

세가지의 핵심적인 기술로 이러한 이슈를 말끔하게 해결하였다.

첫번째로, MAC 학습 방법을 DataPlane (데이터부)에서 Control Plane(제어부)로 변경했다.

따라서 다른 네트워크 장비에 Flooding 영향을 미치는 부분을 말끔하게 해소 했다.

두번째로 필요에 따라 동적으로 터널링을 위한 Encapsulation을 구현하는 방식을 통해, 앞서 소개한 Pseudo-Wire 이슈 역시 말끔하게 해소했다.

데이터센터의 숫자가 많아질수록 관리에 대한 부담을 말끔히 해소할 수 있다.

세번째로, Multi-Homing 이슈로 부터 자유롭다.

부하분산 기술을 OTV에 적용함에 따라 모든 링크들에 대한 부하 분산처리를 가능하게 하였다.

OTV의 장점들은 위의 그림처럼 8가지로 요약된다.

1. 동적 터널 관리 - 동적 터널 관리를 통한 관리의 부담을 줄일 수 있다.

2. 최적의 멀티캐스트 복제 - 멀티캐스트 관련 복제 기술을 포함하여, 불필요한 Overhead를 줄일 수 있다.

3. 다중 사이트 연결 기술 - 멀티 데이터센터의 연결을 편리하게 할 수 있다.

4. Point to Cloud 모델 - 단일 데이터센터에서 다중 데이터센터의 연결을 클라우드 기반으로 구성가능하다.

5. Loop 방지 기술 지원 - OTV 기술 기반의 Loop 방지 기술을 제어부에서 구성 제어 하도록 했다.

6. End to End Loop 방지 기술 지원 - 단순히 OTV 장비간 Loop 방지가 아니라, Inter/Intra에 대해 Loop 방지를 구현할 수 있다.

7. 유연한 사이트 확장/제거 - 데이터센터 사이트의 추가 확장 및 제거가 간편하다.

8. 자동화된 Multi Homing 기술 - STP를 사용하지 않으므로, 대역폭에 대한 활용도가 높다.

2편에서는 동작구조에 대해 살펴 보자.