카테고리: SDN

SDN/NFV 공부

Anatomy of OpenFlow – Chapter 2. SDN 개요

이 챕터에서는 SDN의 기원과 그 속에 숨어있는 기반 아키텍쳐 및 선구자들의 이야기를 다룬다. 우리가 SDN의 역사에 대해 이야기하고, 그것이 어떻게 SDN 아키텍쳐의 프로토콜인 OpenFlow와 연관되는지에 대해 주목하는 것은 중요하다. “Software Defined Network”라는 용어가 처음으로 등장한 것은 2009년 3월에 출판된 Katie Green의 응용 연구에서였다. 하지만 SDN의 개념에 대한 논의는 한참 전부터 주류가 되어 있었다.

 

SDN의 기원

 

SDN의 동인(動人)

잘 알다시피, 오늘날의 인터넷은 예측이 불가능하다. 인터넷은 수 많은 기업들, 네트워크 장비들 그리고 프로토콜들이 서로 같이 협업하는 거대한 집단이며, 네트워킹 역사의 각 시점마다 각기 다른 프로토콜들이 직면한 문제를 해결하기 위해 만들어졌다.  우리는 현재 SDN의 핵심 동인이 되는 몇 가지 일반적인 네트워크 트랜드들을 알 수 있다.

  1. 이더넷은 어디에나 있는 것은 아니지만, 거의 모든 곳에 있으며 곧 그렇게 될 것이다.
  2. X86프로세서가 널리 적용되고 이해된다.
  3. 네트워크 흐름(flow)의 지능화에 따라 대부분의 네트워크 연결들은 좀 더 잘 활용될 수 있다.
  4. 대부분의 L2/L3 네트워크 장비들은 폐쇄 시스템이다.

Figure 1을 보면, 네트워크 장비들이 닫힌 관리와 통합(Integration) 스택으로부터 더 개방된 관리 스택으로 옮겨가는 것을 알 수 있다. NETCONF와 같은 XML 베이스의 프로토콜들은 이러한 디바이스들의 관리, 프로비져닝 그리고 자동화를 이끄는 핵심 동인이 될 것이다. 하지만 통합(integration) 스택은 여전히 닫힌채로 남아있다. SDN 아키텍쳐에서는 프로그래밍과 비즈니스, 프로세스, 정책 흐름과 같은 조직에 대한 최적화를 통해 개방된 시스템을 만들려 하고 있다. 필수적으로, 우리는 개방된 관리 서비스와 제어 평면을 만들어 내려 하고 있다. 우리가 이 아키텍쳐에 뛰어들기 전에, 먼저 SDN과 SDN에 포함된 프로토콜인 OpenFlow가 어디로부터 왔는지 알아보도록 하자.

 

OpenFlow의 역사

 

OpenFlow의 기원은 2006년으로 거슬로 올라간다. 스탠포드 대학교의 박사학위 과정(PhD) 학생인 Martin Casado는 Ethane이라 불리는 것을 만들었다. 그는 교수인 Nick Mckeown과 Clean Slate 프로그램의 일부에서 일하고 있었다.

Clean Slate 프로그램

Clean Slate 프로그램은 “만약 우리가 향후 15년간 완전한 백지로부터 인터넷을 다시 만들어낸다면 어떻게 될까?” 라는 질문에 답하기 위하여 시작되었다. 이 연구는 NSF(National Science Foundation) 의 두 프로젝트와 밀접한 연관이 있다.

첫번째로, GENI(Global Environment for Network Innovations)라는 네트워크 아키텍쳐를 위한 전 세계 규모의 프로그래밍 가능한 플랫폼과, 새로운 네트워크 아키텍쳐를 개발하는 FIND(Future Internet Network Design)가 그것이다.

Clean Slate 프로그램은 몇 가지 핵심 연구 영역으로 구성되어 있다.

  • 네트워크 아키텍쳐
  • 혼성 어플리케이션들
  • 혼성 물리계층 기술들
  • 네트워크 보안
  • 경제와 정책

이 프로그램은 종료되었지만 몇 개의 핵심적인 후속 프로그램을 만들었다

  1. OpenFlow와 SDN
  2. 모바일 프로그래밍 기능성을 위한 POMI 2020
  3. 모바일을 위한 소셜 미디어: MobiSocial
  4. 스탠포드 실험 연구실(Stanford Experimental Lab)

Casado는 중앙에서 관리되는 네트워크에 대한 동적인 광역 정책을 적용하는 방법에 대해 연구했다. 다시 말해, 프로그래밍 기능성과 네트워크 정책의 적용을 강제하기 위해 네트워크의 상태를 추적하려면 어떻게 해야 할까? 그래서 그의 스탠포드 소속의 그룹(Michael J. Freedman, Justin Pettitm Jianying Luo, Nick McKeown) 과 버클리의 Scott Shenker은 네트워크의 상태를 관리하고 정책 기반의 포워딩 동작 변경을 수행하는 컨트롤러를 만들었다. 이를 통해 OpenFlow와 중앙 집중화된 컨트롤러가 탄생하였다.

Ethane에 대한 더 많은 정보를 얻으려면 다음 논문을 참고한다: Ethane: Taking Control of Enterprise

SDN 기본 아키텍쳐

이제, 아이디어 그 자체에 대한 것과 몇 가지 정의에 대해 이야기해 보자. SDN의 개념은 프로그래밍 가능한 네트워크를 만들었다. 그리고 이 프로그래밍 가능한 네트워크라는 개념은 몇 가지 구성요소를 가진다.

  1. 프로그래밍 가능한 제어 평면
  2. 기존의 프로토콜과 명세들
  3. 데이터 평면 추상화
  4. 하부 네트워크에 대한 가상화

Figure 2는 네트워크 OS와 잘 정의된 API로 구성된, “간단한” 패킷 포워딩 아키텍쳐를 포함한 SDN 기본 아키텍쳐를 보여준다. 이 개념은 Figure 1의 네트워크 스택 진화와 연관되어 있다. 네트워크 OS가 얼마나 많은 지능을 가지고 있어야 하는지는 현재 논란거리이지만, 네트워크 OS가 상태 정보를 보관하고 있으면서 그것을 패킷 포워딩 장비들에게 보내줘야 한다는 것에는 모두 동의하고 있다. 이 아키텍쳐를 검토해 보면 여기에는 기존 프로토콜들이  들어갈 곳이 3군데 있다.

  1. 네트워크 OS와 패킷 포워딩 장비 사이의 인터페이스
  2. 네트워크 OS 그 자체
  3. 네트워크 OS 상단의 API

2015년 현재, 네트워크 OS는 컨트롤러라는 장비 위에서 동작한다. 이것은 개방된 것일수도 있고, 폐쇄된 것일수도 있다. 패킷 포워딩 장비로는 Cisco, Juniper, Brocade, Arista 등의 네트워크 벤더가 만든 것과, 오픈 소스 장비(White Box) 혹은 가상화된 장비(vSwitch)가 있다. API는 현재 개발 중이며, 이 책의 후반부에서 다룬다.

 

Figure 3는 SDN 아키텍쳐의 세부 사항을 보여준다. 사람들은 종종 SDN을 Southbound, Northbound와 같은 방향과 함께 언급하는데, 이것은 네트워크 OS를 중심점으로 한 소프트웨어적인 방향을 말한다.

  • Northbound 인터페이스: 컴퓨터 네트워킹과 아키텍쳐에서 컴포넌트의 Northbound 인터페이스란 컴포넌트에서 사용되는 저수준의 세부사항을 개념화하는 것을 말한다. SDN 아키텍쳐에서 이것은 오케스트레이션 시스템을 향하는 API를 의미한다.
  • Southbound 인터페이스: 특정 네트워크 컴포넌트가 저수준 컴포넌트와 통신할 수 있게 한다. SDN에서는 OpenFlow 등의 프로토콜이 있다.
  • East-West 인터페이스: 그룹과 컨트롤러 집단이 HA를 위해 동기화를 할때 사용한다. 이 프로토콜은 아직 표준화되지 않았다.

SDN의 정의

그래서, 우리는 SDN을 명확하게 정의할 수 있을까? 인터넷을 찾아보면 다음과 같은 정의들이 나올 것이다.

정의 1: 소프트웨어 정의 네트워크는 하드웨어로부터 제어 기능을 분리하여 그것을 컨트롤러라 불리는 소프트웨어에게 주는 것이다.

정의 2: SDN은 중앙 집중화된, 프로그래밍 가능한 제어 평면을 만들어 네트워크 운영자가 가상화된 네트워크를 직접 제어하고 관리할 수 있게 한다.

정의 3: SDN은 네트워크의 기능을 전용 네트워크 장비로부터 소프트웨어로 이동시키는 것이다.

 

이 모든 정의들은 하나의 공통점을 가지고 있다. 제어 평면의 분리를 골지로 한다는 것. SDN은 중앙 집중화된 제어 평면에 대한 토론 그 이상이며, 우리가 Layer 3 포워딩 장치의 변화에 대해 예상하는 것 보다 더 큰 변화를 가져올 것이다. 옛날에는 wire-speed 전송이 보편적이지 않았다. 그리고 지금, 벤더간의 OS와 소프트웨어적인 기능 차이를 제외하고 장비들 사이에 어떤 차이가 존재하는가?

SDN은 네트워크를 프로그래밍 가능하게 하고, 하나 이상의 제어점에서 트래픽 제어를 하는 네트워크 아키텍쳐로 정의될 수 있다. 이 개념은 우리가 네트워크를 디자인하고, 트래픽 흐름을 제어하기 위해 개방된 프로그램 가능한 인터페이스를 제공하는 방식을 바꾸었다.

 

표준들의 제정 주체

다양한 단체들이 SDN 아키텍쳐에 필요한 프로토콜들의 표준화를 시도하고 있다. 여기에는 다음과 같은 단체들이 포함된다

  1. ONF(Open Network Foundation)
  2. OpenDaylight
  3. IETF
  4. NFV/ETSI

Open Networking Foundation

ONF는 2011년에 설립되었고,  SDN의 선발 단체들 중 하나로 여겨지며, ONF는 내부의 워킹 그룹에 기여하는 회원들로 구성되어 있다. ONF의 본래 목적은 OpenFlow 스위치의 표준화를 수행하는 것이었다. 이 표준은 스위치에게 패킷을 어디로 전송해야 할 지를 알려주기 위한 것이며, 챕터3, 4에서 다루겠다.

OpenFlow Config와 OpenFlow Test를 포함한 다른 표준도 있다. OpenFlow Config는 OpenFlow 컨트롤러가 OpenFlow 스위치를 설정하는 방법을 정의하는 상호 보완적인 프로토콜이다. OpenFlow Test는 파이썬 베이스로 만들어졌으며, OpenFlow 스위치 테스트 프레임워크와 테스트 케이스들의 집합이다. OpenFlow Test는 파이썬 표준 배포판에 포함되어 있는 Unittest를 기반으로 하였다.

ONF가 조직이 되면서, 더 많은 워킹 그룹들이 만들어졌다. 현재 존재하는 워킹 그룹들은 다음과 같다.

– 아키텍쳐와 프레임워크: Architecture and Framework 워킹 그룹은 SDN 아키텍쳐에서 다룰 광범위한 문제들을 정의함으로써 SDN의 표준화에 도움을 주기 위하여 만들어졌다.

– 설정과 관리 : The Configuration and Management 워킹 그룹(CMWG)은 OpenFlow 표준의 핵심적인 운용, 경영, 관리를 담당한다.

– 확장성 : The Extensibility 워킹 그룹은 OpenFlow 스위치 프로토콜의 확장을 개발하여 가장 최근의 혁신들을 받아들이게 하며, 그 혁신을 OpenFlow 표준에서 채택하도록 만든다.

– 포워딩 추상화 : 버전 1.3에 이르기까지의 OpenFlow 표준은 컨트롤러가 스위치에게 포워딩 방법을 하나 하나씩 실행 시간에(runtime) 알려주는, 일종의 프레임워크이다. 이것을 위해서 하드웨어 추상화 계층(HAL)은 개별 flowmod가 실제 하드웨어에 적용될 수 있도록 해야 한다. The Forwarding Abstractions 워킹 그룹(FAWG)은 OpenFlow 표준의 적용 방법을 단순화시키고, HAL의 유연성을 개선하는 일을 한다.

– Market Education : The Market Education Committee(MEC)는 ONF에서 외부를 향하는(outbound facing arm) 곳이다. MEC의 우선 목표는 SDN 커뮤니티에서 OpenFlow 기반의 소프트웨어-정의 네트워크를 교육하는 것과 ONF 표준의 적용을 촉진하는 것이다. 그리고 MCE는 시장의 피드백을 전달하여 Technical Working Group을 지도하고,  실 적용 사례의 정의, 고수준 요구사항에 대한 개발에 도움을 준다.

– 마이그레이션 : Migration 워킹 그룹은 데이터 센터, WAN 등의 기존 네트워크 서비스들을 OpenFlow 기반의 SDN 네트워크로 이전할 수 있는 방법들을 만든다.

– Northbound Interface : The Northbound Interface(NBI) 워킹 그룹은 노스바운드 인터페이스에 대한 견고한 요구사항, 아키텍쳐와 실제 구현을 위해 만들어졌다.

– Optical Transport : Optical Transport 워킹 그룹은 SDN과 OpenFlow 표준 기반의 제어 기능이 광 전송망에 적용될 수 있도록 한다. 이것은 적용 케이스를 식별하는 것과, 광 전송망 제어를 위한 OpenFlow 표준을 적용할 수 있는 목표 아키텍쳐를 정의하는 것을 포함한다. 그리고 이를 위한 OpenFlow 프로토콜 확장을 만든다.

– Testing and Interoperability :

 – Wireless and Mobile : The Wireless and Mobile 워킹 그룹은 OpenFlow를 통한 RAN과 Core 네트워크 제어 방법을 논의한다.

OpenDaylight

2013년에 설립된 OpenDaylight는 리눅스 제단에 의해 운영되는 오픈소스 프로젝트들의 집합이다. ODL의 주된 목표는 작동하는 솔루션을 만드는 것이며, 표준을 제정하는 일은 그 다음이다. 이 솔루션은 SDN(그리고 NFV)환경을 구축하는 것에 사용될 수 있다. Figure 4는 OpenDaylight 프로젝트의 프레임워크를 보여준다. Core의 목표는 Java가 동작하는 어느 장비에서나 SDN 컨트롤러가 구동될 수 있도록 하는 것이다. 컨트롤러는 Northbound와 Southbound API 모두를 포괄하는 여러가지 기능을 제공하는 소프트웨어 패키지들로 구성된다. Southbound API는 서비스 추상화 계층 -Service Abstraction Layer- (SAL)에 동적으로 연결된다.

Figure 4. OpenDaylight Operational View

이 프로젝트들은 계속하여 OpenDaylight를 만들어가고 있으며, OpenDaylight와 그 프로젝트는 계속 진화중이다. 몇 가지 예로써, OpenDaylight에 포함된 프로젝트들을 적어 본다.

  • OpenDaylight Controller
  • OpenDaylight Network Virtualization Platform
  • OpenDaylight Virtual Tenant Network(VTN)
  • Open DOVE
  • OpenFlow Plugin
  • Affinity Metadata Service

OpenDaylight SDN 컨트롤러의 공식적인 최초 릴리즈는 ‘Hydrogen’이었고, 2014년에 Helium으로 대체되었다. (역자 주:2017년 현재, 최신 릴리즈는 Boron이다)

Anatomy of OpenFlow – Chapter 1. 소개

소프트웨어 정의 네트워크(SDN)는 널리 알려진 buzzword가 되었다. 이제, 모든 네트워크 벤더들은 자신들만의 SDN 솔루션을 가져야만 한다. 그리고 ‘SDN’에 대한 언급이 없는 마케팅 브로셔는 거의 배포되지도 않게 되었다. 이러한 추세로부터 판단컨데, 이제 클라우드와 SDN을 빼놓고서는 네트워크에 대해 많은 것들을 이야기 할 수 없게 될 것이다.

‘이 용어'(SDN)가 너무나 유명해진 나머지 비슷하면서도 다른 많은 용어들이 만들어졌다. 소프트웨어 정의 데이터센터, 소프트웨어 정의 스토리지, 소프트웨어 정의 애플리케이션 배포, 네트워크 기능 가상화(NFV) 등등.

업계의 수많은 CIO와 CTO들의 머리를 아프게 만드는 이 ‘SDN’이라는 용어란 과연 무엇일까? 그리고 그들의 사업에 대해서 어떤 의미를 가지는 것일까? 내가 알기로는 SDN이란 ‘컨트롤 평면과 데이터 평면을 분리하는 것’, ‘네트워크에 프로그래밍 기능을 제공하는 것’이다. 물론, SDN이 ‘데이터 평면을 추상화 한 것’이라는 것을 안다. 하지만 그게 대체 무슨 뜻인가? SDN은 OpenFlow와 동의어인가? NFV와 SDN의 차이점은 무엇일까? 그리고 현 시스템에 SDN을 도입하는 것을 검토할 때, ‘파괴적인 기술’이라는 것은 대체 무슨 의미인가? SDN을 도입하려면 기존 시스템을 없애야 한다는 말인가?

이 무엇보다 중요한 것은, SDN은 어떤 효용성을 가지는 것일까?

이 책이 OpenFlow를 다루고 있음에도 불구하고, SDN 아키텍쳐에서 OpenFlow의 역할을 알기 위해서는 먼저 SDN을 이해할 필요가 있다. 이 챕터는 OpenFlow에 대해 이야기하기 위해 필요한 기본적인 개념을 다룰 것이며, 몇 가지의 기본적인 질문들에 대해 답할 것이다.

 

SDN이란 무엇인가?

먼저, 2가지의 정의로부터 시작해보자. 하나는 매우 구체적이며, 다른 하나는 조금 더 일반화된 것이다. 두 정의 모두 현재 산업계가 직면한 문제점에 대한 지향점을 보여준다.

정의 1.

SDN은 중앙 집중화된 컨트롤러가 분산된 스위치들의 포워딩 동작을 제어하는 L2/L3 아키텍쳐이다

정의 2.

SDN은 개별 네트워크 구성 요소들을 최소한의 조작만으로 프로그래밍 할 수 있는 추상화된 네트워크를 위한 개념적인 프레임워크이다.

이 두 가지의 정의가 같은 것을 의미한다고 하기에는 상당히 무리가 있을지도 모른다. 하지만 이 두 정의는 분명 ‘동일하다’. 당신은 SDN의 첫번째 정의를 자주 들어 보았을 것이다. 하지만 첫번째 정의는 두번째 정의를 좀 더 엄밀하게 정의한 부분집합에 불과하다.

우리는 먼저 첫번째 정의로부터 시작하여 두번째 정의를 향해 나아갈 것이다.

 

컨트롤 평면과 제어 평면

전체 SDN 아키텍쳐는 네트워크의 초창기로부터 이어져 온 연속적인 발전들을 상징한다. 개념적으로는 오래 전 스위치에서 관리, 데이터, 제어 평면이 분리되었을 시점으로 거슬러 올라간다.

 각 평면들의 기능에 대해 간단하게 다루자면

  • 관리 평면은 동작 모니터링과 접근 기능을 제공한다. CLI와 SNMP, syslog, NetFlow 등이 여기에 속한다.
  • 데이터 혹은 포워딩 평면은 수신한 PDUs(Protocol Data Units)를 전송하는 포트 혹은 인터페이스와 스위칭 패브릭, 인터페이스 사이에서 포워딩을 수행하기 위한 필수적인 정보로 구성되어 있다. 예를 들어, 라우터에서 이러한 정보는 FIB(Forwarding Information Base)에 저장되어 있으며, 패킷을 보내기 위한 목적지 주소와 인터페이스 정보, 그리고 이더넷 스위치에서는 포트별로 매핑된 MAC 주소 테이블이 있다.
  • 제어 평면은 데이터 평면이 올바르게 PDU를 전송하기 위해 필요한 정보들을 제공한다. 라우터의 제어 평면에서는 OSPF, IS-IS, BGP 등의 라우팅 프로토콜이 동작하며, 데이터 평면의 FIB를 갱신한다.

 

제어 평면은 네트워크에서 ‘지능적인’ 것으로 간주되는데, 왜냐하면 그것이 PDU를 이상적인 경로로 전송하는 것과 루프 회피, QoS, 장애 복구, 그리고 트래픽 관리에 있어 중요한 결정을 내리기 때문이다. 데이터 평면은 PDU를 최대한 빠르고 효율적이게 입력 포트에서 출력 포트로 내보내는 일만을 한다. 데이터 평면은 PDU가 어떻게, 어디로 보내지는지에 대해 아무런 결정을 내리지 않는다.

 

1990년대 말, 고성능 스위치에서 한 샤시 내에서 데이터 평면과 제어 평면이 하드웨어적으로 분리되는 혁신을 이루었다. 제조업체들은 독립된 제어 평면을 라우터 프로세서(Router Processor), 혹은 Supervisor Module이나 Routing Engine 등으로 불렀다. 이 구조를 택함으로써 얻는 이점은 동일하다. 제어 평면에 대한 부하가 데이터 평면의 전송 속도에 영향을 미치지 않고, 그 역도 마찬가지이다. 그리고 데이터 평면이 제어 평면 없이도(Headless) 잠시 동작할 수 있게 되면서 NSF(Non Stop Forwarding), ISSU(In-Service Software Upgrades) 등의 고가용성 기술이 등장하게 되었다.

한편, MPLS는 데이터 평면과 제어 평면을 좀 더 밀접한 관계로 만들었다. 네트워크의 “지능적인” 부분은 경계면으로 옮겨지고, MPLS Privider Edge(PE) 라우터가 최적 경로 결정을 내리고, 코어의 Provider 라우터는 단순히 패킷을 스위칭하기만 하면 되었다. 하지만 MPLS Provider 라우터도 자신만의 제어 평면을 가지고 있었는데, 때문에 PE 라우터 없이도 자체적으로 라우팅 기능을 수행할 수 있었다.

MPLS 네트워크는 IP 네트워크에서 제어 평면에 대한 생각의 방향성을 바꾸어 놓았다. 우리는 분산된 토폴로지에서 제어 평면을 최적화하는 일에 많은 시간을 투자했다. 모든 라우터가 각각의 제어 평면을 가지고 있지만, 전달 경로 선택은 라우터 단독으로 이루어질 수 없었다. 그래서 라우팅 프로토콜을 사용하여 서로간의 최적 경로를 결정하게 되었다. 여기서의 핵심 과제는 각각의 제어 평면들이 네트워크에 대하여 동일한 정보를 공유하는(Convergence)것에 시간이 걸린다는 점이다. IP 네트워크에서 루프를 피해서 믿을만한 최적 경로를 결정하는 것에는 시간과 계산이 필요했지만, MPLS는 대부분의 제어 평면을 PE 라우터가 전담하게 되면서 분산된 제어 평면의 문제점을 상당히 감소시킬 수 있었다.

그리고 이 두 가지의 경향성 -독립된 하드웨어에 설치된 제어 평면이 데이터 평면에게 정보를 보내주는 것과 제어 평면을 네트워크의 에지에 위치시키는 것-을 합친 것이 기본적인 SDN 아키텍쳐이다. 네트워크에서 “뇌”의 역할을 하는 제어 기능은 중앙 집중화하고, 포워딩 정보를 네트워크의 스위치들에게 업데이트 해 주는 것이 바로 그것이다.

 

중앙 집중화된 컨트롤러는 분산된 제어 평면 환경에서 발생한 몇 가지 문제들을 해결해 준다.

  • 장애에 대한 정보를 다수의 노드에게 공유할 필요가 없기 때문에, 링크 혹은 노드의 장애 대처를 더 빠르게 수행할 수 있다.
  • 컨트롤러가 전체 네트워크의 청사진을 가지고 있기 때문에 루프 회피가 더 간단해진다.
  • 프로그래밍 가능한 네트워크에서 가장 중요한 개념으로, 데이터 평면과 유저 사이의 단일 인터페이스로 포워딩에 대한 오케스트레이팅을 수행할 수 있다.

물론, 중앙 집중화된 컨트롤러는 또 다른 주의점을 가지고 있다.

  • 하나의 컨트롤러는 전체 네트워크의 단일 장애점(Single Point of Failure)이 될 수 있다. 그러므로 동기화와 리던던시 확보를 위한 멀티호밍이 요구된다.
  • 중앙 집중화된 컨트롤러는 좋은 공격 대상이다. 만약 당신이 컨트롤러를 지배할 수 있다면, 네트워크 전체를 가진 것과 같다.
  • 컨트롤러에서 스위치로의 FIB 업데이트는 일시적으로 비일관적인 포워딩을 만들 수 있고, 따라서 마이크로 루프가 발생할 수 있다. 물론, 동일한 문제점이 하드웨어적으로 제어 평면과 전송 평면이 분리된 라우터들에서도 나타난다. 하지만 ‘지리적으로’ 멀리 떨어지게 되면 문제가 더 커질 것이다.

주로 언급되는 장점으로 관리자가 네트워크 변경을 매우 빠른 시간에 적용할 수 있다는 것이 있다(buzzword로는 Network Agility라 한다). 컨트롤러에 변경사항이 적용되면, 컨트롤러가 스위치들에게 포워딩 규칙들을 전송하고, 네트워크를 구성한다. 관리자는 개별 스위치들을 설정할 필요가 없으며, 벤더별 명령어들을 외울 필요도 없다.

 

OpenFlow란 무엇인가?

 

네트워크의 모든 스위치들에 탑재된 OS의 명령어들을 컨트롤러에 입력하는 것은 거의 불가능하다. 하나의 벤더에서 나온 스위치들도 여러 OS를 가지고 있으며, 각각의 OS에 따라서 명령어들에 약간, 혹은 아주 많은 차이가 있다. 예를 들어 Cisco Systems의 경우, 대형 네트워크를 모두 Cisco사의 장비로 구축할 때 당신은 IOS, IOS-XR, CAT-OS 그리고 NX-OS를 운용하게 될 것이다. 이 OS들은 모두 각각 다른 기능을 지원하고, 다른 명령어 문법을 가진다. 여기에 배포된 소프트웨어의 종류와 버젼에 따른 차이를 고려하면 문제는 더욱 복잡해진다. 그리고 당신이 네트워크 장비를 구매하려고 할 때 -이더넷 스위치 뿐만 아니라, 라우터, 방화벽, 로드 밸런서, 웹 가속기, NAT, WAN 옵티마이저, 터널 서버, IDS/IPS 등등- 이 모든 장비들이 하나의 벤더의 제품일 가능성은 거의 없다.

그러므로 스위치와 컨트롤러 사이에는 반드시 개방된 통신 표준이 필요하다. 여기서 바로 OpenFlow가 등장한다.

OpenFlow는 다음과 같은 사항을 정의한다.

  • 스위치의 포워딩 동작을 정의하는 flow instruction들
  • 컨트롤러의 변경 사항을 스위치에서 수신하기 위한 메시지들
  • Instruction과 메시지를 담는 포맷
  • 컨트롤러와 스위치 사이에서 메시지를 주고 받기 위한 프로토콜

 

고수준에서는 OpenFlow는 다음과 같은 컴포넌트로 이루어져 있다

  • 컨트롤러
  • 스위치의 OpenFlow 인터페이스
  • 컨트롤러와 스위치 사이의 보안 채널
  • Flow instruction들로 이루어진 flow table

이것들은 OpenFlow를 구성하는 가장 기본적인 요소에 불과하다. 3장에서 OpenFlow의 세부 구성요소와 프로세스, 메시지 구조를 다룰 것이다. 하지만 SDN 아키텍쳐에서의 OpenFlow를 이해하는 것에는 이러한 고수준의 정의만으로 충분할 것이다.

이를 요약하자면 다음과 같다.

“OpenFlow는 제어 평면이 데이터 평면에게 포워딩 동작을 지시할 수 있게 해 주는 둘 사이의 통신 프로토콜이다.”

 

그리고 OpenFlow를 이해하는 것에는 ‘OpenFlow란 무엇인가?’만큼이나 ‘OpenFlow는 무엇이 아닌가?’도 중요하다.

  • OpenFlow는 컨트롤러와 스위치의 상세를 정의하지 않는다. OpenFlow는 오직 둘 사이의 통신 규약만을 정의할 뿐이다.
  • OpenFlow는 데이터 평면과 제어 평면을 제외한 다른 어느 곳에서도 동작하지 않는다. OpenFlow는 SDN 아키텍쳐에서 한 부분을 뚜렷하게 차지하고 있다.
  • OpenFlow는 네트워크 자신이나 네트워크의 구성 요소들을 만들어내지 않는다. OpenFlow는 오로지 데이터 평면의 포워딩 동작만 제어할 뿐이다.
  • 제어 평면과 데이터 평면이 통신하기 위한 수단으로 OpenFlow만 있는 것은 아니다. OpenFlow를 대체하기 위한 기술들로는 NETCONF, XMPP, BGP, OVSDB(OpenvSwitch Database Management Protocol), 그리고 시스코의 One’s PK가 있다.

OpenFlow와 마찬가지로, 이들 중 많은 수가 공개 표준이다. -다중 벤더 지원과 API 개발 및 개선을 위하여- 하지만 OpenFlow는 이 점에 있어 다른 솔루션들을 크게 앞서는데, 넓은 범위의 벤더 지원과 그들의 강력한 개발 커뮤니티 덕분이다. 또한, OpenFlow는 거의 모든 다른 대체제들과 비교하여 Flow Instructions를 스위치의 FIB나 TCAM에 직접 입력할 수 있다는 장점이 있다. 대부분의 솔루션들은 로컬 노드의 OS와 통신하여 기능을 구현한다. 이 점에 있어 다른 대체제들이 개별 노드로부터 제어 평면을 없애는 것에 실패하였다는 입장과, SDN이건 아니건 스위치 OS는 일정 부분의 제어 기능을 가지고 있어야 한다는 입장 사이에서 논쟁이 이어지고 있다.

 

간단한 SDN 아키텍쳐

‘SDN과 OpenFlow란 무엇인가’에 대해 어느 정도 답변이 되었을 것이다. 이제, 우리는 “왜”라는 질문에 답해야 한다. 설득력 있는 적용 사례 없이는, 최고의 기술적인 솔루션이라도 고독한 최후를 맞이하게 될 것이다.

SDN에 대한 공감대는 ‘오늘날의 평면들(Planes)을 우리가 어떻게 제어할 것인가’ 에서 출발한다. 데이터 평면은 반드시 분산되어야만 한다. 우리는 출발지와 목적지 인터페이스를 최대한 가까이 위치시켜야 한다. 하지만 우리의 현 세대 장비들은 하나의 샤시에 통합되었거나 분리된 컨트롤러가 붙어 있다. 그러므로, 제어 평면 또한 데이터 평면 노드와 같은 장소에 분산되어 위치한다. 이 말은 라우팅, CoS, 보안, 루프 회피, 장애 복구 등의 제어 평면 기능을 네트워크 사이에서 수행하는 일이 매우 복잡해진다는 것을 의미한다. 최악의 경우, 네트워크에 n개의 노드가 있을 때 모든 노드는 반드시 다른 모든 노드와 통신해야만 하며, n2-n의 간접 연결이 필요해진다.

OSPF를 예시로 들어보자. 각 노드로부터 다른 노드까지의 최단거리 트리를 계산하는 OSPF의 알고리즘은 간단하고 빠르다. OSPF의 복잡성은 모든 연결이 신뢰성 있는 adjacencies를 성립해야 하며, Link-State Database(LSB)를 구성하고 인접 라우터와 LSB를 동기화해야 한다. 그리고 현 시점에서 데이터베이스 엔트리가 모두 정확해야 한다는 것에 기인한다. OSPF의 n 제곱 복잡도는 area를 설정하는 것으로 경감될 수 있다. 하지만 이 경우 라우팅 정보의 정확성을 어느 정도 희생하게 된다. 링크 상태의 변경에 대한 알림이 네트워크 전체로 전파되는 것에는 시간이 걸리며, 그 동안 블랙홀과 마이크로 루프가 발생할 수 있다.

네트워크의 모든 노드들이 링크 상태를 다른 모든 노드로 전파하는 것 대신 중앙 집중화된 컨트롤러로 직접 정보를 전달한다고 가정해 보자. 컨트롤러는 변형된 SPF 계산을 수행하고, 다른 노드의 FIB를 직접 갱신한다. 이 경우 단 하나의 컨트롤러만이 존재하기 때문에 복잡한 컨트롤러간 동기화를 수행할 필요가 없다. 또한 네트워크에 단 하나의 제어 평면이 존재하기 때문에 마이크로 루프와 블랙홀은 감소한다. 그러므로 FRR(Fast Reroute)나 LFA(Loop-Free Alternates)와 같은 제어 평면이 재수렴을 수행하는 동안 트래픽을 우회시키기 위한 기술들의 필요성이 줄어든다.

이 시나리오는 완벽함과는 거리가 있다. 중앙 집중화의 효율성은 네트워크의 지리적 크기가 점점 커짐에 따라 감소하고, 복잡도는 중복 컨트롤 노드들이 분산되어야 함에 따라 증가한다. 그리고 컨트롤러와 스위치 간의 직접 통신에 따르는 비용은 두 장치 간의 거리에 비례하여 늘어난다.

그럼에도 불구하고, SDN 솔루션을 검증하고 도입을 계획할 강력한 인센티브들이 있다.

  • CAPEX 감소: 대부분의 고성능 스위치에 들어가는 비용은 제어 평면에서 나온다. 특수한 서버와 별반 다를 것이 없는 하드웨어가 아니라, 컨트롤러에 포함된 네트워크 OS의 가격 때문이다. 이 소프트웨어는 개발에 수 만 시간이 들었고,  -한 네트워크 장비 제조사는 그들의 OS를 자신들이 축적해온 경험의 저장소라고 칭했다- 이 비용은 반드시 회수되어야만 한다. 중앙 집중화된 컨트롤러는 새 네트워크 노드를 구입할 때마다 비용을 지불하는 것이 아닌, 단 한번의 비용 지출만 이루어지면 된다는 것을 의미한다.
  • OPEX 감소: 운영은 IT 예산에서 언제나 가장 큰 비중을 차지해 왔다. 인적 자원은 비싸다. 하지만 네트워크의 모든 장비들을 다루는 것이 아닌, 단 하나의 제어 평면만을 설정하는 것으로 충분하다면 비용은 절감될 것이다. -특히 다수의 CLI와 OS가 존재하는 환경에서는 더 긴 교육 기간을 가지게 된다-
  • 신뢰성 증대: 사람의 직접적인 조작은 네트워크 단절의 주된 원인이다. 그리고 설정 실수의 가능성은 설정해야 하는 장비들의 개수와, CLI의 종류에 비례한다. SDN 컨트롤러는 이러한 설정의 일정 부분을 자동화시키고, 일관성을 보장해 준다. 그리고 사람의 조작에 대한 가이드라인들의 모음인 운영 정책이나 절차는 매우 중요하지만 만들고 유지하는 데에는 비용이 많이 들어간다는 것도 특기할 법 하다. SDN은 이러한 정책과 절차의 중요성을 감소시켜 신뢰성을 높이고 운영 비용을 감소시킨다.
  • 작업 흐름(Workflow) 통합: 특히 데이터 센터에서 네트워크 재설정은 가상화 워크플로우와 서버/스토리지/애플리케이션의 이동성에 방해물이 된다. SDN은 네트워크를 가상화 관리에 통합시키는 것으로 시작했다.
  • 민첩성: SDN은 새로운 서비스를 도입하거나 서비스 프로파일을 변경하는 것에 드는 시간을 감소시킨다. 그러므로 클라우드 서비스가 더 에자일해지는 것에 따른 이점이 있다.
  • 접근 제어: SDN은 L2/L3 환경에서 집중화된 정책 적용을 가능케 한다. 또한 컨트롤러도 REST API를 통해 L4-7의 동적인 정책 제어와 변동하는 애플리케이션 요구에 통합적으로 대응하는 것이 가능하다. 그러므로 애플리케이션 주도의 네트워크에 좀 더 가까지 다가갈 수 있다. 여기에 대해서는 이 챕터의 뒤에서 좀 더 자세하게 다룬다.

 

구체적인 사례: 차세대 데이터 센터

 

SDN은 스탠포드와 다른 몇몇 대학들이 네트워크 기술을 개발하기 위하여 만든 학술 네트워크로부터 시작되었다. 챕터 5,6에서는 다양한 SDN 적용 사례들을 알아본다. 하지만 지금, SDN은 데이터 센터에서 압도적으로 많이 적용되고 있다. 그 이유를 찾는 것은 어렵지 않다. 수 년 전까지만 해도 대부분의 데이터 센터 네트워크는 15년도 더 된 기술들과 싸우고 있었다. 데이터 센터 엔지니어에게 있어 가장 독한 놈은 바로 STP(Spanning Tree Protocol)이었다 -넓은 의미에서는 여전히 문제가 된다-. L2 토폴로지의 빽빽한 연결 사이에서 루프를 방지하기 위해 개발된 STP는 리던던시를 위해 50% 이상의 대역폭을 차단했고 끔찍한 장애 복구 시간과, 잘못된 설정에 취약했다.

수 년간 이러한 부작용을 감소시키기 위해 많은 STP의 개량형들이 등장했다.

  • RSTP(Rapid Spanning Tree Protocol, 802.1w): 30-50초씩 걸리던 STP의 장애 복구 시간을 약 6초로 줄였다. -하지만 밀리초에서 마이크로초 단위의 정밀도가 필요한 곳에서는 여전히 수용 불가능하다-
  • MSTP(Multiple Spanning Tree Protocol, 802.1s): 다른 VLAN그룹끼리 독립된 스패닝 트리를 구성함으로써 자원 활용성을 높였다.
  • LACP(Link Aggregation Control Protocol, 802.1ax): 다수의 병렬 링크를 묶어 STP가 마치 그것들이 단일 링크인 것 처럼 취급하게 한다.
  • SPB(Shortest Path Bridging, 802.1aq)와 Transparent Interconnection of Lots of Links(TRILL): 최단 경로 우선 알고리즘을 L3에서 적용하여 루프 방지, 장애 복구 시간의 감소를 이루었다.

SPB와 TRILL을 제외한 모든 프로토콜들이 문제가 있는 프로토콜(STP)를 임시로 때워놓은 것에 불과하다. 여기서 한 가지 사실을 고려해보자. ‘토폴로지에 트리가 없으면, 스패닝 트리도 필요없다’. 이것이 바로 최근 몇년 사이 몇몇 벤더들에 의해서 소개된 스위칭 패브릭의 목표이다.

벤더별로 스위치 패브릭의 적용 방법이 각각 다르긴 하지만, 기본적인 개념은 동일하다. 평평한, 가상화된 데이터 평면을 만들어 데이터 센터 내의 모든 TOR(Top of Rack), EOR(End of Row)스위치를 단일 스위치에 연결된 것 처럼 만든다. 모든 물리 또는 가상 스위치의 포트들은 하나의 스위치 패브릭에 속한다.

데이터 센터가 가상 스위치 패브릭으로 이전하는 것에는 그 외에도 많은 이유가 있으나, 간략한 논의의 범주를 벗어나기에 다루지 않는다.  우리의 논의에 있어서 핵심은 L2 데이터 평면이 서로 연결된 스위치에서 가상화된 단일 스위치로 진화하였다는 것이다. 이 스위치는 여전히 다수의 물리 장치로 구성되어 있다. 하지만 스위치들은 하나의 스위치처럼 동작하고 관리된다. 다시 말해, 데이터 평면은 ‘추상화되었다’. 우리는 이제 전체 데이터 평면을 한번에 운용할 수 있게 되었다.

 

-가상화와 추상화

 

가상화에 대한 이해 없이는 데이터 센터에서 살아남을 수 없다. 만약 당신이 네트워크 기술자라면 언제나 가상화와 대면하게 될 것이다: 가상 회로, 가상 LAN, 가상 사설 네트워크, VRRP, VRF, VPLS 등등. 모든 경우에서 가상 네트워크의 본질은 진짜처럼 보이는 것이 사실은 진짜가 아니라는 것이다. 그것은 백그라운드에서 동작하는 물리적 장비들에 의해서 만들어지고, 나타난다. 예를 들어 VRRP(Virtual Router Redundancy Protocol)의 경우, 호스트에게는 하나의 라우터가 존재하는 것 처럼 보이지만, 이 라우터는 사실 존재하지 않는다. 대신 둘 이상의 실제 라우터가 서로를 감시하고 있으면서, 호스트로부터의 업스트림 경로가 언제나 유지되도록 한다. 달리 말해, VRRP 토폴로지의 실제 라우터들은 가상 라우터로 추상화되어서 호스트에게 노출된다. 호스트의 트래픽은 실제 라우터들에 의하여 처리되지만, 토폴로지 장애는 호스트에게 감춰진다. 백업 라우터가 가상 라우터의 일을 넘겨받아 포워딩을 계속 수행한다.

이 사례로부터 심지어 기능과 서비스에 대해 심지어 그것들이 변동되더라도 사용자에게 일관성 있는 시점을 제공해 주는 추상화가 가지는 이점을 확인했을 것이다.

 

이 모든 것은 다음과 같은 결론을 이끌어낸다: 만약 추상화가 우리에게 통합된 데이터 평면을 제공한다면 제어 평면 또한 통합되어 추상화되어야 할것이다. 그리고 이 챕터의 시작 부분에서 다뤘던 SDN의 2번 정의에 가까워졌다:  ‘SDN은 네트워크를 추상화되어 동작하게 하는 개념적인 프레임워크이다’

이것은 또한 우리를 첫번째 정의로부터 멀어지게 만들었다. 우리가 SDN을 중앙 집중화된 컨트롤러라고 생각하는 동안은 개별 서버와 장비들, 혹은 심지어 중앙 집중화된 서버와 장비들에 대해서도 SDN은 필요하지 않았다. 이제, SDN은 네트워크 인터페이스로 기능하는 소프트웨어의 집합체이다.

그러나 우리는 이 일반화로부터 더 나아갈 수 있다.

 

프로그래밍 가능한 네트워크를 향하여

 

오퍼레이터는 관리 평면을 통하여 스위치와 라우터의 제어 평면에 접근한다. -CLI, GUI, SNMP, XML 기반 API 등등-  설정을 변경하고, 통계를 모으고, 장치들을 모니터링한다. 간단히 말해, 관리 평면은 오퍼레이터와 제어 평면이 서로 통신하기 위한 방법이다.

우리는 이미 그 방법을 보았다. 하부의 데이터 평면이 추상화되고, SDN 제어 평면은 오퍼레이터가 개별 네트워크 장비들과 직접 상호작용할 필요성을 없앴다. 그리고 OpenFlow와 같은 “Southbound” 프로토콜은 데이터 평면과 상호작용하기 위하여 오퍼레이터 혹은 제어 평면 자신이 벤더별 언어를 익힐 필요를 없엤다.

이와 비슷하게, 추상화된 제어 평면은 일반화된 “Northbound” API를 관리 평면에 제공한다. 오퍼레이터는 이 단일 인터페이스를 통하여 전체 네트워크를 프로그래밍하고 정보를 얻을 수 있다. 이것의 중요성을 이해하기 위하여, 다시 데이터 센터의 진화로 돌아가 보자.

현대 데이터 센터에 있어 가상화는 거의 당연한 일이다. 서버와 스토리지는 급격히 변하는 요구에 맞추어 그때그때 만들어지고, 변경되고, 이동한다. 만약 데이터 센터가 그 자체로 사업이라면-예를 들어 클라우드 프로바이더의 경우- 에자일한 이익 중심점의 오케스트레이션은 사업 성공을 위하여 반드시 필요한 일이다. Puppet, Salt, Ansible, Chef, CFEngine과 같은 설정 관리 툴은 수만대의 서버에 대한 반복되는 오케스트레이션 작업을 자동화시켰다. 그렇지만 이들은 여전히 진짜 프로그래밍 언어 – 배포와 관리 작업 루틴을 기술할 수 있는- 가 아니다. 이 프로그램들은 단지 모든 디바이스들에게 한번의 CLI 명령으로 설정을 적용할 수 있는 방법을 제공할 뿐이다. 당신은 한 곳에서 어떠한 일이 일어날 것인지를 정의하고, 당신의 명령은 네트워크 전체에서 실행된다.

그리고 서비스 유래 인프라의 배포와 관리를 위해 가상화된 데이터 센터를 제어하는 관리 수트가 있다. 이들 중 널리 알려진 것으로 OpenStack이 있는데, 클라우드 서비스를 배포하기 위하여 사용된다. OpenStack은 오퍼레이터가 자신들의 클라우드를 관리할 수 있게 할 뿐만 아니라 사용자가 직접 서비스를 프로비져닝하고 관리하는 것을 가능케 한다. OpenStack은 계산, 스토리지, 네트워킹을 관리하는 소프트웨어와 그것들을 오케스트레이팅 하기 위한 대쉬보드로 구성되어 있다. 그 외에도 여러 클라우드 오케스트레이션 수트들이 있으나, 오픈 스택의 강력한 공개 지원과 개발 커뮤니티 때문에 대부분의 대형 클라우드 프로바이더들은 오픈 스택을 사용한다.

OpenStack의 유명세가 부분적으로 OpenDaylight 커뮤니티에 의해 개발된 오픈 소스 SDN 컨트롤러에 영향을 끼친 것은 의심의 여지가 없다. 다음 그림에서 OpenDaylight 컨트롤러가 데이터 평면과 OpenFlow, BGP, LISP, NETCONF, 그리고 몇 가지 다른 방법으로 통신하는 것을 볼 수 있을 것이다. Northbound로는 유저와 컨트롤러가 GUI, CLI를 통해, OpenStack 과는 Neutron을 통해 통신하는 것을 알 수 있다.

여기서 예시로 든 것은 OpenDaylight 컨트롤러에 대한 선전이 아니다. -폐쇄된, 혹은 공개된 다른 많은 컨트롤러들이 있다- 단지 이 예시는 데이터 평면과 제어 평면이 프로그래밍을 위하여 어떻게 추상화되지는지를 보여주기 위한 것이다.

물리적, 논리적 토폴로지 디자인을 포함한 전통적 네트워킹에서 네트워크 노드간의 케이블 설치와 설정은 당신의 설계에 따라야 한다. 그것은 정적인 모델이다: 만약 네트워크 동작을 바꿔야 한다면 개별 노드들을 다시 찾아 재설정 해야 할 것이다.

SDN은 제어 평면에게 당신이 “If, Then, Else” 명령어를 이용하여 데이터 평면에서 적절한 명령어를 실행하도록 할 수 있다. 이런 프로그램적 접근은 당신의 네트워크를 더 에자일하고, 적응적이고, 동적으로 만들어 줄 것이다. 그리고 이것이 우리가 추상화에 역점을 두는 이유이기도 하다. 추상화에 의한 유용하고 편리한 프로그래밍 기술 말이다. SDN의 경우, 우리는 네트워크의 모델을 프로그래밍 한다. 그리고 컨트롤러가 그것을 실제로 적용한다.

우리는 이제 두번째-그리고 더욱 정확한- SDN의 정의에 완전히 도착했다. 그러니 여기서 다시 한번 살펴보자: SDN은 개별 네트워크 구성 요소들을 최소한의 조작만으로 프로그래밍 할 수 있는 추상화된 네트워크를 위한 개념적인 프레임워크이다.

 

네트워크 기능 가상화

 

“소프트웨어 정의 네트워크”라는 용어는 마치 그것이 네트워크의 구성요소나 기능을 정의하는 것 처럼 들린다. 이건 이해할 수 있는 오해지만, 실제로 SDN이 동작하는 방법을 흐리게 만든다. 더 명확하고 간단한 다른 용어로 NFV(Network Function Virtualization)이 소개되었다. NFV는 두 가지 측면을 갖는다.

  • NFV는 VPN, VRF, 터널, QoS와 보안 정책, VLAN, 오버레이 등의 네트워크 기능을 정의한다.
  • NFV는 소프트웨어적으로 기존의 물리 네트워크 장비였던 라우터, L2 스위치, 방화벽, 로드 밸런서, IDS/IPS, WAN 가속기 등을 정의한다.

여기에 맡은 일의 명확한 차이점이 있다.

  • SDN은 flow를 프로그램 한다.
  • NFV는 네트워크 기능을 프로그램 한다.

보통, 이건 항상 명확한 것은 아니다. 이 둘 사이에는 트래픽 엔지니어링과 같은 여러 모호한 영역이 존재한다. 우리는 네트워크 흐름을 프로그래밍 해서 TE를 달성해야 할까? 혹은 논리적 경로를 프로그래밍 해서 달성해야 할까? SDN과 NFV는 누구도 이 질문에 대답할 수 없을 정도로 새로운 기술이다. 왜냐하면 이 기술들은 여전히 진화중이고 산업계 또한 아직 믿을 수 있는 정의를 찾지 못했기 때문이다. 하지만 SDN과 NFV의 개발 목적은 빠르게 변화하고 있고, 조만간 산업계가 좀 더 정확한 정의를 만들어 낼 수 있을 것이다.

당신은 이러한 정의에 동의하지 않는 사람을 쉽게 찾을 수 있을 것이다. 하지만 괜찮다. 우리가 이 책에서 이야기하고자 하는 부분은 오로지 차이점만 알고 있으면 된다.

 

-유전적 다양성

흥미롭게도 SDN과 NFV는 다른 유산을 가지고 있으면서 서로 보완적이다. SDN은 학계로부터 시작하였고 빠르게 데이터 센터에 적용되었다. 이제 SDN은 데이터 센터에서 WAN, 전화, 이동통신, 서비스 공급자망으로 이동하고 있다

한편, 대형 통신사업자와 전화 사업자들은 ETSI를 통하여 NFV를 발족시켰다. 그것의 유전자는 전화에 뿌리를 두고 있다. 하지만 NFV 응용은 빠르게 데이터 센터와 클라우드 제공자망으로 이동중이다.

SDN과 NFV는 서로 별개로 사용될 수 있다. 하지만 함께일 때 그것들은 우리가 네트워크를 구축하고  운용하는 방식을 바꾸어 놓을 것이다.

 

SDN은 파괴적인 기술인가?

 

SDN과 NFV는 네트워크의 혁신적인 변화를 위한 촉매이다. 우리는 추상화되고, 가상화되고, 노드간의 개별 링크가 아닌 그것들을 실어 나르는 흐름(flows)를 다루는 세계로 나아가고 있다. 다년간 우리는 네트워크를 구름으로 표현했다. 그리고, 지금 구름이 여기 있다.

SDN은 그저 파괴적인 기술이 아니다. 우리가 TCP/IP의 출현에서 본 것과 같이 SDN은 아주 파괴적인 기술이 될 것이다.

 

혼란스러운 기능들

SDN은 다른 훌륭한 네트워크 관리 시스템이 그렇듯이, 그저 우리가 네트워크와 상호작용하는 방법을 바꾸지만은 않을 것이다. SDN은 우리가 네트워크를 바라보는 시각을 노드끼리 서로 연결된 그래프에서 종단점 사이의 흐름군(system of flows)으로 바꾸었다. 우리는 더 이상 개별 기기 및 연결과 상호작용하지 않는다. 대신 네트워크 전체와 상호작용한다.  여기에 NFV를 더하면, 개별 네트워크 기능들이 물리 장치에서 가상 기능들로 바뀔 것이다.

 

혼란스러운 재무 모델들

시장 지배적 위치에 있는 라우터나 스위치 벤더는 자신들의 제어 평면 소프트웨어에 심도 있는 기술적 투자를 한다. 그리고 당신이 라우터나 스위치를 구매할 때마다 당신은 같은 소프트웨어를 구매하면서 벤더들의 투자비용 회수에 기여한다.

SDN은 이 모델을 바꾼다. 네트워크 OS를 위해서 단 한번만(혹은 몇 번) 비용을 지불하면 되고, “베어 메탈” 기기를 이용하여 OS 없이, 혹은 최소한의 OS만으로 당신만의 데이터 평면을 구성할 수 있다.

 

이러한 관점에서 보았을 때, 시장 지배적 기업이 SDN에 대한 논의를 제어하고, SDN을 재정의하고, 주제를 완전히 바꾸려고 하는 이유는 매우 명백하다.

 

혼란스러운 능력들

우리는 이미 데이터센터의 가상화가 직무 설명과 능력들을 어떻게 혼란시키는지 보았다. 한 때 애플리케이션 개발자와 오퍼레이션 엔지니어는 다른 직업이었다(그리고 때때로 서로 다투기도 했다). 그리고 가상화는 이 둘을 DevOps로 묶었다 -개발자는 계산과 스토리지 리소스를 Operations 전문가 없이 사용할 수 있게 되었다-

지금의 DevOps에서는 네트워킹에 대한 내용이 빠져있다. 그리고 SDN이 그것을 바꿀 것이다. SDN과 NFV의 범위에 따라 가상화된 네트워크 구성요소와 제로-터치 프로비져닝을 가능하게 한다. “CLI Jockeys”-엄격하게 검증된 벤더 전용 네트워크 OS-는 필요성이 줄어들 것이다.

네트워킹은 애플리케이션과 더 긴밀하게 통합되고, 네트워크 엔지니어는 네트워크 프로그래머가 될 것이다.

 

애플리케이션 정의 네트워크를 향하여

 

SDN과 NFV는 궁극적인 파괴를 이끌 수 있을 것이다. 네트워크에 대한 인간의 간섭을 완전히 막는 것이 바로 그렇다. 네트워크를 설계하고, 구축하고, 유지하는 것 뿐만이 아니라 애플리케이션에 맞춰 네트워크를 적용하거나 그 역에 이르기까지 말이다.

생각해보자, 지금은 “인간 계층”이 네트워크와 애플리케이션 사이에서 중재자 역할을 하고 있다. 우리는 어떠한 애플리케이션이 돌아갈지 분석하고, 어떤 네트워크 자원이 사용 가능한지, 그리고 최대한 타협하여 설정한다. 지금은 SDN과 NFV가 프로그램 가능한 패러매터와 모인 네트워크 정보를 기반으로 오케스트레이션을 수행할 수 있다. SDN이 완전히 자리를 잡으면, 우리는 애플리케이션 계층이 오케스트레이션 계층과 직접 상호작용하도록 만들 수 있을 것이다.

우리는 이미 네트워킹을 아는 애플리케이션을 가지고 있다-적어도 어느 정도는-. 하지만 그건 앞뒤가 바뀐 것이다. 네트워크가 애플리케이션을 지원하기 위해 존재하는 것이 더 낫다. 네트워크는 애플리케이션을 모니터하고 무엇이 필요한지 추론한다. 혹은 애플리케이션이 네트워크에게 무엇이 필요한지 직접 이야기하거나?

실시간으로 애플리케이션 요구 사항에 맞추어 동적으로 조정하는 네트워크를 상상해 보라. 애플리케이션 정의 네트워크는 SDN 이후의 파괴적인 물결이 될 수 있을 것이다.

 

결론

 

이 챕터에서는 SDN의 기본적인 내용을 알아보았다. 제어 평면과 데이터 평면을 분리하는 것이 SDN의 핵심이며, 이것을 이루는 방법에는 여러가지 길이 있다는 것을 아는 것은 중요하다.

이 챕터를 읽은 뒤, SDN과 NFV에 의해 탄생한 사업 케이스들이 있다는 것은 매우 명백하게 보일 것이다. 데이터센터는 명백히 더 나은 스케일 능력과 리소스 사용을 보여주었고, 서비스 제공자들은 NFV를 부가가치 서비스와 조직의 이윤 창출에 활용할 수 있었다.

이 책의 나머지 부분에서는 공개 SDN의 개념에 초점을 맞출 것이며, OpenFlow 프로토콜의 역사와 기능을 자세히 다룰 것이다.

SDN과 NFV 개론

 

1. 들어가며

IT, 그 중에서도 네트워크 산업에 종사하고 있다면, 최근 들어 SDN과 NFV라는 용어를 자주 들어보았을 것이다. 각각 Software Defined Network와 Network Functions Virtualization의 약어인 이 용어들은 클라우드에서, 데이터센터에서, LAN에서, WAN에서 시도 때도 없이 등장하며 우리들을 괴롭혀왔다. 그런데, 과연 SDN과 NFV는 무엇일까?

지금부터 이 두 기술의 공통점과 차이점, 지향하는 목표와 관련 기술들에 대하여 알아보도록 하겠다.

 

2. SDN과 NFV가 뭐지?

  앞서 말했듯이, SDN은 Software Defined Network, NFV는 Network Functions Virtualization의 약어이다. 둘 다 소프트웨어적으로 제어가 가능한 네트워크 구축을 목표로 하기에 얼핏 보면 비슷한 개념으로 착각할 수도 있지만, 실상은 전혀 다른 기술들이다.

먼저, SDN은 종래의 폐쇄된(Proprietary) 구조의 네트워크 하드웨어를 물리적으로 분리해 각각 데이터 평면(Data Plane), 제어 평면(Control Plane), 애플리케이션 평면(Application Plane)으로 추상화(Abstraction)하는 것을 목표로 한다. 이것을 통해 기존의 네트워크 장비가 가지는 벤더 의존성을 탈피하여 좀 더 유연하고 비용 절감적인 네트워크를 구축할 수 있도록 한다.

반면, NFV는 기존의 네트워크 장비에서 지원하던 기능들을 가상화하여 범용 서버에서 실행/관리하는 것을 목표로 한다. 이것을 위해서 반드시 데이터 평면과 제어 평면이 분리될 필요는 없으며, NFV에서 핵심이 되는 부분은 네트워크 기능(Network Function)의 가상화와 이들을 연동하고 관리하기 위한 표준화된 인터페이스이다.

 

이로써 SDN과 NFV의 개념을 간략하게 살펴보았다.

비록 SDN이 NFV보다 더 넓은 범위를 커버하고 있기는 하지만, Legacy Network를 완전히 대체하는 SDN에 비해 기존 장비를 재활용할 수 있고, 안정성을 담보할 수 있는 NFV가 기존 인터넷 서비스 사업자들에게 선호되고 있다. 같은 이유로 새로이 시스템을 구축하거나, 안정성에 대한 부담이 덜한 데이터센터와 내부 네트워크에 SDN이 먼저 적용되고, 성과를 거두었다.

 

3. SDN(Software Defined Network)와 표준화

 SDN은 차세대 네트워크 기술로 주목받고 있으며, ONF, IETF, ITU-T에서 각각 표준화 작업을 진행중에 있다.

이 세 단체는 각기 다른 지향점을 가지고 있는데, ONF(Open Network Foundation)은 스탠포드 대학교에서 만들어진 OpenFlow를 기반으로 표준화를 진행중이며, 서비스 사업자 위주의 클라우드/데이터센터 적용을 목적으로 표준화를 진행중이다. IETF는 기존에 사용된 IETF Standard를 활용하며, 새로이 네트워크 애플리케이션과 네트워크 관리를 위한 인터페이스의 제공을 목표로 표준화를 진행중이다. 마지막으로 ITU-T는 통신 사업자 위주로 표준화를 진행중이며,  현재 전송망(T-SDN)에 대한 적용과 궁극적으로 전체 캐리어 네트워크에 대한 적용을 목표로 표준화를 진행하고 있다.

각기 목표하는 지향점과 범위가 다르기에 당분간 SDN은 각 표준이 계속 발전해나가며 서로 경쟁하는 관계가 될 것으로 보인다.

 

3-1. ONF가 추구하는 SDN

  ONF는 스탠포드 대학에서 개발된 OpenFlow 프로토콜을 중점으로 SDN 표준화를 진행 중인 단체이다. 대표적인 회원사로는 AT&T, Dell, HPE, Cisco, Intel, Ciena, China Mobile, Facebook, Google, Microsoft, Oracle, Tancent 등이 있으며, 클라우드 서비스 중심의 소프트웨어/웹  회사와 후발 소프트웨어 솔루션 회사를 주축으로 표준화를 진행중이다.

ONF는 OpenFlow를 클라우드, 광 전송망, 무선 네트워크망 등에 적용할 수 있도록 모델 수립과 기술 표준화 작업을 진행하고 있으며, 구글은 자사의 데이터센터에 OpenFlow 기반의 SDN 전송망을 도입함으로써 얻을 수 있었던 이득과, 상용화 사례를 공유하고 있다.[1](http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf)

ONF는 SDN을 다음과 같이 정의하고 있다. ‘SDN은 네트워크의 제어 기능과 전송 기능을 분리하여 제어 기능을 직접 프로그래밍 가능하게 하고, 하부의 장비들(underlying infrastructure)을 애플리케이션과 네트워크 서비스에게 추상화여 제공하는 것을 의미한다.'[2](https://www.opennetworking.org/sdn-resources/sdn-definition)

ONF가 밝히는 SDN 아키텍쳐 구조도는 아래의 그림과 같다.

890x

Infrastructure Layer에 네트워크 하드웨어가 위치하고, Control Layer와 통신하여 가상 네트워크 레이어를 구성하기 위한 프로토콜로 OpenFlow를 사용한다. 그리고 Control Layer는 Application Layer의 요청을 API를 통하여 받아들여, 가상 네트워크 토폴로지를 구축한다. 이 API는 MD-SAL(Model Driven Services Access Layer)을 통해 제공된다.

이를 통해 확인할 수 있는 ONF의 주된 표준화 작업 목표는 하부의 물리 장비들과 통신하기 위한 OpenFlow 프로토콜의 명세 정의와 SDN 망을 관리하는 Controller 의 구현, 그리고 Control Layer와 Application Layer 사이의 통신을 위한 API를 정의하는 것이다.[3](https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/evolution-of-sdn-and-of.pdf)

ONF는 현재 Operator, Specification, Market 워킹 그룹을 구성하여 표준화를 진행중이며, Carrier-grade SDN, 데이터센터, Migration, Framework, Model, South-Northbound Interface, Security 등을 논의하고 있다.

3-2. IETF가 추구하는 SDN

IETF는 SDN의 구현에 있어서, 기존의 장비와 프로토콜을 완전히 대체하지 않는 방향으로 표준화를 진행 중에 있다. ONF는 데이터 평면과 제어 평면을 완전히 분리하는 것을 기본 원칙으로 삼고 있지만, IETF는 이 둘을 물리적으로 분리하지 않는다. 마찬가지로 제어 평면에서 사용되는 프로토콜도 OpenFlow가 아닌 I2RS이며, 기존 인터넷 망의 프로토콜에 더해 ICMP를 대체하는 NETCONF 프로토콜의 정의 등, 기존의 망에서 SDN 기능을 제공하는 것에 초점을 맞추고 있다.

RFC7426-1

IETF RFC7426에 정의된 SDN Architecture[4](http://www.sdnskills.com/learn/sdn-terms-01/)

IETF의 SDN 아키텍쳐에서는 관리 평면과 제어 평면이 분리되어 있는 것이 눈에 띈다.

3-3. ITU-T가 추구하는 SDN

ITU-T는 SDN을 다음과 같이 정의하고 있다. ‘SDN이란, 개방형 인터페이스로 네트워크를 프로그래밍하고, 오케스트레이션하고, 제어하고 관리할 수 있는 기술이다. 또한, 이 기술은 네트워크 사용을 쉽게 만들고 빠른 배포와 자동화를 가능하게 한다.’ ITU-T에 따르면 SDN을 구현하기 위해서 다음과 같은 기능들이 필요하다[5](https://www.itu.int/rec/T-REC-Y.3300/en).

– 네트워크 자원의 프로그래밍 기능

– 네트워크 자원과 SDN 어플리케이션의 오케스트레이션

– 네트워크 리스스의 동작을 변경하기 위한 애플리케이션 레이어의 인터페이스

– 네트워크 리소스를 제어하기 위한 인터페이스

– 네트워크 리소스와 SDN 제어 평면의 분리

– 하부 네트워크 리소스에 대한 추상화

– 물리적 네트워크 리소스에 대한 관리 기능

다음은 ITU-T에서 제시하는 SDN 아키텍쳐이다.

Y3300-Arch

전체적으로 ONF의 그것과 비슷한 구성을 가진다. ITU-T SG 13은 현재 SDN 세부 아키텍쳐의 표준화에 착수하였으나, 관련 정보를 얻는 것이 힘들기 때문에 ITU-T의 SDN 아키텍쳐는 여기까지만 다루겠다.

이상으로 각 표준화 단체의 SDN 표준화 방향에 대해 알아보았다. 개인적인 의견으로는 오픈소스 커뮤니티와 협력하여 표준화가 진행 중인 ONF의 표준이 가장 완성도가 높았고, ITU-T의 표준화 작업이 가장 더디게 진행되고 있는 것으로 보인다.

 

4. NFV(Network Functions Virtualization)와 표준화

SDN이 서비스 사업자들의 데이터센터을 위주로 도입되고 있다면, NFV는 통신 사업자들의 필요성에 의해 만들어진 기술이다. 기존의 하드웨어/벤더 의존적인 네트워크 기술들(VPN, DPI, QoS 등)을 하드웨어로부터 분리시켜 좀더 관리와 제어가 편리하도록 가상화하는 것을 목표로 한다. NFV의 표준화를 위한 표준화 그룹은 ETSI NFV ISG로, 약 40여개의 통신 사업자와 회사, 단체가 참가 중이며 국내에선 SKT, KT, 삼성, ETRI가 멤버로 참여하고 있다. ETSI NFV ISG의 표준화 작업은 현재 Phase-2가 진행 중이다.

NFV의 표준화 작업, 특히 Phase-1의 결과물에 대해서는 차후에 표준을 읽어 본 뒤 다시 추가하도록 하겠다.

통신 사업자가 NFV를 도입함으로써 얻을 수 있는 이득으로는 고가의 전용 장비를 사용해야 했던 기능들을 저가의 하드웨어에 소프트웨어를 설치하는 것으로 사용할 수 있다는 것과, Layered Network 구성을 들 수 있다. 덧붙여, 후자는 SDN-NFV이다.