위 내용은 SDN 공부를 위한 개인적인 정리 용도로 제작되었으며, <오픈소스를 활용한 OpenFlow 이해하기>를 참고하였습니다.
네트워크 장비의 구조
1) Data Plane : 패킷의 송수신 담당
2) Control Plane : 패킷 경로 설정, 관리 및 제어 기능 담당
3) Management Plane : 동작 상태 및 성능 관리 기능 담당
데이터센터에 요구되는 네트워크 디자인 요약
1) Flat Network : 네트워크 홉 최소화
2) Fat Tree : 대규모 서버 Access 환경 및 최적 경로
3) Fast Switching : 낮은 네트워크 대기 시간을 보장
4) Simplicity : 구성 운영 및 관리 용이성
현재 네트워크 구조와 한계
1) 운영 자동화와 중앙관리의 어려움
개별 장비에서 3가지 기능(Data, Control, Management)을 동시에 수행한다. 때문에 네트워크 구성의 변경이나 확장 시 관리자들은 해당되는 모든 라우터, 스위치, 방화벽, 인증 장비 등에서 일일이 변경된 정책과 설정을 입력해야 한다. 벤더별/장비별로 동일한 기능 구현 및 설정 체계를 통일한다면 운영 자동화 및 중앙 관리가 가능해져서 매우 효율적인 네트워크 구성 및 운용이 가능하지만 현재 네트워크 장비의 아키텍쳐 상에서는 현실적으로 불가능하다.
2) 효율과 비용 문제
네트워크에서 가장 중요한 기능은 STP(Spanning Tree Protocol)과 Routing Protocol일 것이다. 네트워크 디자인 시 안정성을 확보하기 위해 장비를 이중화로 구성한다. 하지만 이중화는 루프 발생 가능성이 커진다. 이로 인해 전체 네트워크가 다운되는 증상이 발생한다. 루프 방지를 위해 가장 많이 사용되는 방법은 STP를 설정하는 것이다. STP의 기본 개념은 이중화된 링크의 한 구간을 논리적으로 끊는 것이다. 이를 통해 루프를 방지한다. 만일 다른 쪽 링크에 문제가 생기면 논리적으로 끊어 놓은 링크를 자동으로 활성화시켜 활성된 곳으로 통신이 이루어지게 한다. 하지만 장비 복구 시간이 오래 걸리는 점과 링크 한쪽을 끊는 것이기 때문에 비효율적 회선 사용이 이루어지게 된다는 단점이 있다.
3) 개별 처리로 인한 네트워크 복잡성 증가
네트워크 라우팅 알고리즘을 짤 때 하나의 Control Plane에서 네트워크 전체를 관장하는 중앙 집중 방식으로 구현한 후에 이를 분산 방식으로 바꾼다. 중앙 집중 방식은 간변하고 효율적이며 테스트에 편리하다. 장비를 생산하는 벤더마다 RFC에 근거하지만 구현하는 방식에 특성이 있어 기종간 호환성 이슈가 발생하는 경우가 종종 있다.
OpenFlow : 네트워크를 경유하는 네트워크 스위치나 라우터의 포워딩 필레인에 권한을 제공하는 통신 프로토콜이다. 벤더에서 OpenFlow를 지원하지 않는다면 해당 벤더의 스위치를 가진 고객은 SDN을 구현하지 못하기 때문에 여전히 벤더 종속성이 존재한다.
ONF(Open Network Foundation) : 2011년 마이크로 소프트, 구글, 야후 등 8개의 이사회를 중심으로 설립되었다. 지금까지 OpenFlow와 비슷한 연구들은 많이 존재하였으나 논문을 위한 연구였을 뿐 활성화되지 못하였다. 이는, 표준화를 위한 단체의 활발한 활동과 그 단체에 기존 너트워크 벤더들이 매우 회의적이었기 때문이다. 하지만 ONF에는 구글, Goldman Sachs, 야후, 마이크로소프트, NTT, Facebook 등 세계적인 기업들이 가입되어 있고 활발하게 활동하는 중이다.
NFV(Network Function Virtualization) : 흩어져있던 네트워크 기능들을 고집적 장비에 몰아넣어 비용 절감 및 효율성 극대화에 목적을 둔다. 기존 네트워크 개념은 각 요소를 하드웨어 단위로 구분하였다. 때문에 개별 단위로 분류하는 경향이 강했고 심한 자원 낭비와 높은 전력 사용량이 문제점이었다. 하지만 NFV는 물리적 자원 최소화를 통한 전체의 효율성 향상과 시스템 복잡성을 감소시키는 것에 초점을 두었다. NFV가 반드시 SDN을 사용하는 것은 아니나 SDN에 적극적인 주요 벤더들이 NFV의 주요 벤더들이기 때문에 서로 상호보완적인 관계인 것은 분명하다.
SDN과 OpenFlow의 예시
명절이 되면 항상 고속도로가 막힌다. 아무리 교통 방송을 잘 듣고, 정체 예상 시간을 피하더라도 어느 시점에 차가 막히고 어느 구간에 빨리갈 수 있는지 정확한 정보를 얻는 것은 불가능하다. 하지만, 만일 중앙 통제실이 있어서 모든 교통 세부 사항을 실시간으로 감지할 수 있다면, 이러한 문제점을 해결할 수 있을 것이다.
네트워크도 마찬가지로 개별장비의 연산에 의해서 전송된다. 상대편 장비와 프로토콜을 맞추어 서로 통신은 하지만 트래픽에 대한 연산은 개별 장비에서 이루어지기 때문에 특정 구간에서는 엄청난 부하가 발생할 수 있지만 동일한 경로의 다른 구간에는 아무 트래픽도 흐르지 않는 경우가 빈번하다. 이로 인한 네트워크의 회선 사용률은 매우 낮아지며 비효율적 회선 사용에 의해 비용이 증가하게 된다.
SDN/OpenFlow를 쉽게 설명하면 SDN은 네트워크의 모든 교통 수단(네트워크 장비)를 지능화된 중앙 관리 시스템(Controllder)에 의해 관리하는 기술이다.
SDN이란?
SDN은 SoftWare Defined Networking의 약자이다. 소프트웨어 정의 네트워크라고 불리우며 네트워크 장비에서 하드웨어 기능과 소프트웨어 기능을 분리해낸 것이다. 스마트폰을 예시로 생각하면 이해하기 편한데, 기존 피처폰들과는 다르게 스마트폰은 기존 출고 시 나온 기능들 위에 내가 원하는 기능을 가진 어플리케이션을 설치하면 추가 기능 사용이 가능해진다. 만일 기존 피처폰에서 A라는 게임이 하고 싶었다면, A 게임을 지원하는 피처폰을 구매했어야 하였다. 위 예시에서 보면 알겠지만, 스마트폰은 하드웨어와 소프트웨어의 분리된 구조에 기반을 두고 있다. 기존 피처폰은 출고 당시에 해당 하드웨어에 어떤 소프트웨어들이 설치될지 결정되지만, 스마트폰은 출고 후 사용자의 입맛에 맞는 소프트웨어들이 추가로 설치된다. 하드웨어는 삼성, LG, Apple 등에서 제작하고 운영체제는 google의 안드로이드, Apple의 iOS를 사용하며, 어플 설치는 스마트폰을 구매한 사용자들이 결정한다.
네트워크 장비 구조는 크게 3가지로 구분할 수 있다.
1) Data Plane : 데이터 전송을 담당(하드웨어 영역)
2) Control Plane : 운영체제 기능을 담당(소프트웨어 영역)
3) Management Plane(어플리케이션) : 네트워크 지능화 기능을 담당(소프트웨어 영역)
초기 인터넷에서는 안정성의 문제를 이유로 개별 네트워크 장비 안에 3가지 구성요소가 동시에 필요했다. 하지만 인터넷 사용이 급증함에 따라 인터넷 사용에 대한 요구가 복잡해지면서 구조적 문제로 인한 한계점이 발생하였다.
|
|
기존 네트워크 |
SDN |
|
네트워크 관점 |
하드웨어 중심 |
소프트웨어 중심 |
|
구성 주도권 |
하드웨어 제공 벤더 |
사용자 |
|
기술 개방성 |
폐쇄적 구조 |
개방형 구조 |
|
연동 호환성 |
독자 프로토콜 |
표준 프로토콜 |
|
관리 효율성 |
비효율/고비용 운용 |
효율적/합리적 운용 |
|
신기술 수용 |
벤더의 필요에 따름 |
사용자 요구에 따라 수용 |
|
시장의 공정성 |
독과점 형태 |
공정 경쟁 |
SDN은 3가지 Layer로 구분되며 각 Layer는 Open Interface를 통해 서로 통신한다.
Network Control Layer와 Infrastructure Layer 간 Interface는 종종 Southbound API라 부르기도 하며, 이 영역에 포함되는 것이 OpenFlow이다. Network Control Layer와 Application Layer간 Interface를 Northbound API라 부른다. Northbound API는 표준화 된게 없기 때문에 표준화가 요구된다.
네트워크 장비에서 Data Plane이라고 부르는 영역은 SDN에서는 Infrastructure Layer라 부르고, Control Plane을 Network Control Layer라 부른다. 즉, 개별 Data Plane들의 집합체를 Infrastructure라고 부른다. 때문에 Infrastructure Layer에서는 실제적으로 다양한 Data Plane이 존재하지만, SDN에서는 논리적으로 마치 한 대의 네트워크 장비가 동작하는 것처럼 운용이 되는 것에 목적을 두고 있다. 이러한 Infrasturucture를 구축하기 위해서는 모든 개별 스위치들은 Control Layer와 긴밀하게 통일된 정보를 주고 받아야 한다. 이를 위한 프로토콜 중 가장 널리 사용되는 것이 OpenFlow 이다.
개별 Data Plane마다 서로 다른 Flow Table을 가지게 된다. OpenFlow는 표준 인터페이스로 주고 받는 Message에 대한 표준을 제시한 것으로 Flow Table의 장비별 동기화를 하는 프로토콜이 아니다.
Flow Table은 Rule, Action, Stats로 구성된다.
1) Rule : 어떠한 패킷을 처리할지를 정의하는 영역으로 OSI 7 Layer중 Layer1 ~ Layer4까지 12개의 구분자를 가지고 패킷을 처리한다.
2) Action : Rule에 의해서 정의된 패킷을 어떻게 처리할지를 정의한다.
3) Stats : 해당 Flow Table에 얼마나 많은 Packet이 매칭되었고, 얼마나 큰 Byte가 전송되었는지를 보여준다. 이 정보를 Controller에게 전송한다.
Controller는 OpenFlow를 통해 스위치의 정보를 가져온다. 이를 통해 Controller는 네트워크의 Topology를 구성한다. 스위치를 통해 패킷이 Controller에 가고 Controller에서 최적의 경로로 패킷이 전송되도록 해당 스위치에 Flow Table을 전송하는 것을 ReActive 방식이라고 한다. ReActive 방식은 길지는 않지만 Latency가 존재한다. 반면, 패킷이 도착하기 전에 Controller에서 Flow Table을 스위치에 전송하는 경우가 있는데 이를 ProActive 방식이라고 한다. ProActive는 Flow Setup Time이 존재하지 않아 Latency가 매우 좋다. 실제 운영 단계에서는 ReActive와 ProActive가 상황에 맞게 혼용해 사용한다.
Infrastructure Layer
데이터 전송을 담당하는 영역인 Data Plane 영역을 다른 말로 Infrastrutrue라고 부른다. 현재 네트워크 장비는 기존보다 비싸지고 있는데, 기존에 있던 Legacy 장비에 OpenFlow Agent 기능만을 올렸기 때문이다. SDN 진영이 꿈꾸는 Infrastructure를 구현하기 위해서는 현재의 하드웨어를 OpenFlow에 최적화된 구조로 바꾸는 것이 필수이다.
Controller Layer
SDN하면 가장 먼저 떠올리는 것이 Controller이다. 기존의 Legacy와 SDN의 가장 먼저 보이는 차이점이 Control Plane의 위치이기 때문이다.
Controller 구현은 공통부와 Application으로 나뉘어진다. 공통부는 OpenFlow와 직접적으로 관련된 영역이다. 대부분의 Controller에서 Topology Management, Path Management, Link Discovery 그리고 Flow Management 기능을 공통으로 제공한다. 이를 이용해서 네트워크 지능화를 하는 영역이 Application 영역이다. 일반적으로는 Application 영역에서 Routing Security 그리고 Monitoring 기능이 제공된다. Controller 내에서 제공하는 Application은 SDN Application이라고 하고 Application Layer에서 제공하는 Applicat,ion은 Business Application이라고 부른다. 하지만 이는 Controller마다 다르기 때문에 어떤 Controller에서 SDN Application인 것이 다른 Controller에서는 Business Application인 경우도 있다.
Controller의 디자인 방식은 크게 3가지로 나뉜다.
1) Centralized Controller : 가장 많이 사용되는 방식이다. 2대 이상의 Cntroller가 Active-Standby Controller로 구성되는 것으로 Active의 Controller에 장애가 발생하였을 때 이를 Standby Controller에서 바로 넘겨받는 구조이다.
2) Distributed Controller : Google의 G-scale에 적용된 방식(여러 개의 Controller 위에 Controller Signalling으로 묶여 있음)이다. 주로 전 세계적으로 연결이 되는 SDN 네트워크나 매우 큰 데이터의 잦은 통신이 일어나야 하는 환경에 적합하다. Controller 간 정보를 어떻게 동기화 할 것인지가 매우 중요한 요소이다.
3) Multilayer Controller : 광역단위의 본사-지사 간에 적용하는 방식(Device마다 Controller가 있음)이다. Controller를 통해서 Northbound API와 Southbound API가 제공되며, Controller는 아직까지 SDN에서 가장 중심을 차지하고 있다.
Application Layer
Layer4 ~ Layer7에 이르는 서비를 제공하는 솔루션을 다루며 운영을 위해 다루는 툴들도 Application이다. 모니터링을 하는 것도 Application이다. Application Layer는 Controller와 Infrastructure Layer를 제외하고 거의 대부분 Application이라고 해도 될 정도로 넓은 의미이다.
OpenFlow Protocol Message 종류
1) Controller-to-Switch : Controller가 생성하여 Switch에 전달하는 Message로써 주로 Switch의 상태를 관리하거나 점검하기 위해 사용한다. 이 메시지의 대표적인 것으로는 Features, Configuration, Packet Out, 그리고 Barrier가 있다.
- Features : OpenFlow Channel을 형성할 때 사용하며, 해당 Switch의 Capability를 확인하기 위해 사용된다. Controller에서는 features request를 원하는 Switch에 전송하며, 해당 Switch는 Feature reply를 통하여 Controller에 응답한다. reply 안에는 Switch에서 수행 가능한 Action 값들 및 port들의 연결 속도, duplex 등이 정보로 제공된다.
- Packet Out : Packet In Message를 통해 스위치로부터 수신한 Packet을 해당 스위치 상의 특정한 포트로 전송하기 위해 사용된다.
2) Asynchronous : Switch가 생성하는 Message로써, Switch의 상태 변경 및 Network Event를 Controller에서 업데이트하기 위해 사용한다. 주요 Message에는 Packet In, Flow-Reoved, Port-status와 Error가 있다.
- Packet In : Switch가 Controller에게 Packet을 전송하여 Packet에 대한 Control을 받기 위해 사용된다. Packet이 왔을 때 해당 Packet에 대한 Flow Table이 없으면 이를 Controller에 보낼 때 사용한다. Flow Table의 Action에 Controller로 보내라고 정해져 있을 때도 사욯된다.
3) Symmetric : Controller와 Switch에서 모두 생성되며, 상대방의 요청이 없어도 전송되는 특징이 있다. Hello, Echo, Experimenter가 주요 Message 이다.
- Hello : Controller와 Switch 간에 연결을 시작할 때 사용한다.
- Echo : Controller와 Switch 간 연결에 이상이 없음을 확인하기 위해 주로 사용되며 Echo에 대해서는 반드시 Echo Reply를 전송한다.
Controller와 OpenFlow Switch간 Session 연결 순서
1) TCP Session Established
2) Hello 교환
3) Feature Negotiation
4) Configuration Message 교환
5) Stats Message 교환
6) Vendor Message 교환
7) Flow Mod 전송
8) Stats Message 교환
9) Echo Message 교환
