앞의 글에서는 SDN이 태어나게 된 역사를 이야기했다고 보면.. 이번에는 진짜! SDN은 왜 그런 구조를 가지고 있는가?에 대해 다루는 글입니다.
물론 기술적인 부분만으로 SDN을 이해할 수도 있겠으나 제 생각에 SDN의 개념은 제대로 알고 시작하지 않으면 잘못된 방향으로 SDN을 이해하지 않았으면 하는 바램입니다..
1. SDN을 시작하려면 Abstract의 개념부터!
자 그럼 SDN이 어떤 것을 추구하고 어떻게 그 목표를 이뤄냈는지 한번 알아보겠습니다.
SDN을 이해하기 위해서는 Abstraction이라는 개념을 먼저 깔고 가는 것이 좋습니다.
Abstraction
추상 = 개별의 사물이나 표상의 공통된 속성이나 관계 따위를 뽑아냄.
위와 같은 뜻으로 생각하시면 될 것 같습니다.
공통된 것들을 묶어서 뽑아낸다는 뜻이고 결국 공통되지 않는 것들은 독립적으로 보겠다. 라는 것을 한번 새겨두고 넘어가시길 바랍니다. 이게 SDN을 말하는 전부라고 해도 과언은 아닐 것 같습니다.
2. 지금의 네트워크는 덩어리일 뿐!
자 현재 우리가 다루고 있는 기존 네트워크를 한번 볼까요?
출처: <http://bradhedlund.s3.amazonaws.com/2011/openflow-scale/switch-control-data-planes.png>
위의 그림처럼 기존 네트워크는 데이터 처리와 컨트롤에 대한 분리가 없는 덩어리죠.
말 그대로 모니터와 본체가 하나로 합쳐져 있는 일체형 PC로 한번 설명을 해볼까요?
2.1. 덩어리의 문제점(기존 네트워크 장비의 문제점)과 개선방법
보시는 것처럼 일체형 PC를 보시면 장점은 일단 배제하고 우리가 PC 수리기사라고 생각했을때 갑자기 화면이 안 나온다면…? 본체 부분부터 모니터 부분까지 차례차례 다 살펴봐야 할겁니다. 이처럼 사용하기 편한 장점은 있을 지 몰라도 문제가 생겼을 때 해결은 꽤나 어렵다는 것입니다.
저희가 사용하는 네트워크 장비도 마찬가지로 어떤 문제가 생기면 관련된 것들을 하나하나 확인해보면서 확인해야 하죠.
Cisco Nexus 장비를 보면 Feature로 장비의 기능을 나눠놨죠.
그로 인해 필요한 기능들을 제어할 수 있습니다. 기능에 대한 On/Off 스위치라고 생각하시면 됩니다.
얼마 전 운영중인 Nexus 장비에서 특정 Process의 CPU 점유율이 70%를 넘어가는 버그가 있었습니다. Telnet Process의 문제였죠.
기존의 장비였다면 해당 문제를 해결하기 위해 크게는 reload 하는 방법으로 처리해야 했을지도 모르겠지만 Nexus 장비에서는 간단하게 콘솔 접속 후
#No Feature telnet
#Feature telnet
과 같은 방식으로 다른 서비스에는 전혀 영향없이 해결할 수 있었습니다. 기능의 모듈화를 통해 문제 해결의 방법이 엄청나게 개선되었죠. SDN도 모듈화를 통해 더 나은 환경을 만들자는 거죠.
3. 덩어리를 분해하자.
일체형 같은 장비는 장점도 있겠지만 앞에서 든 예처럼 장애처리(Trouble Shooting)에 있어 취약합니다. Control Plane의 문제인지 Data Plane의 문제인지 포괄적으로 확인해야 합니다. 이가 분리되어 있다면 한 부분만 확인해도 될 것을 합쳐져 있기 때문에 전체를 봐야만 하는 것이죠.
그러면 Abstraction은 각각의 요소를 분해하는 것으로부터 시작하게 됩니다.
각 요소들을 계속해서 분해하여 해당 요소가 하나의 목적에만 집중할 수 있을 정도로 분해해서 정의하는 것입니다.
네트워크 장비를 크게 나눠보면 Control 과 Data 그리고 Management 의 세 가지로 분해 할 수 있습니다.
이렇게 보면.. 좀 정신 없네요.. 좀 더 저희가 이해하기 쉬운 자료를 참고해 보겠습니다.
http://www.menog.org/presentations/menog-12/115-OpenFlow_and_SDN_(MENOG).pdf
위와 같이 보시면 이해가 쉬우실 겁니다.
이렇게 보시면 딱 이해가 가시죠? Management Plane은 따로 언급 하지 않는 경우가 더 많기는 한데 크게 보면 Control Plane에 포함이라고 볼 수도 있어서 그런 것 같습니다.
SDN에서는 Application Plane을 담당한다고 생각하시면 됩니다.
SDN은 앞서 말씀 드린 것처럼 Control Plane과 Data Plane이 뭉쳐있는 저 덩어리를 분리하여 모듈화 시키자는 거죠. 덩어리를 동일한 맥락의 추상화된 구성요소는 모아서 모듈화를 시키자는 거죠.
여기서 다시 SDN에 대해 짚어보면 SDN의 목적은 어떻게 보면 Data Plane과 Control Plane을 분리한다. 라고 볼 수 도 있습니다만…
추상(Abstraction)화 시키는 것과 모듈화(Modularization) 시키는 것에 의미가 있다고 보시면 됩니다. 장비에서 각 할 일에 맞게 이를 분해한 것이 아래와 같은 그림으로 나누어 졌다고 보시면 됩니다.
제가 말씀드리고 싶은 것은 SDN은 Control Plane과 Data Plane이 분리된 Architecture를 가지고 있다. 라고 SDN에 대한 정의를 하는 게 아닌 각 파트에 맞는 모듈화를 위해 Control Plane과 Data Plane을 분리한 Architecture이다.라는 생각을 가지고 가셨으면 좋겠습니다.
어떻게 보면 같은 결과이지만 분명히 큰 차이가 있다고 생각합니다.
4. Layering은 필수!
이러한 Layering 이 정말 중요하다는 점은 저희가 네트워크를 시작하면서 정말 많이 보고 많이 언급된 7! osi 7 layer를 봐도 알 수 있습니다.
출처: <http://knowcitrixx.wordpress.com/xenserver-6/osi-7-layer-explained/>
현재 인터넷의 눈부신 발전도 위의 OSI 7 Layer를 통해 잘 정리 되어있지 않았다면 불가능한 일이었을 겁니다. SDN도 이와 같이 네트워크를 잘 짜여진 layer 구조로 만드는 것에 있습니다.
지겹도록 들었던 OSI 는 빠르게 접어두고 다시 SDN으로 돌아와서 결국 Data Plane은 패킷을 전달하는 동작을 하고 Control Plane은 Data Plane에서 어떻게 동작해야 할지를 판단해주는 것입니다.
자 그럼 Control Plane에 대해서 좀 더 알아보면…
기존 네트워크 장비의 Control Plane을 살펴보면… 발전에는 더딜 수 밖에 없는 구조입니다.
각 벤더들은 각자의 장비에 맞는 hardware/software 제어를 위한 방식을 가지고 있고, 가장 큰 문제 중 하나는 모든 장비를 각각 설정해야 한다는 것입니다.
SDN은 이러한 부분을 중앙집중화를 통한 Server에서 이런 동작들을 제어하고 관리하면서 Data Plane과 Control Plane을 분리하여 제어하자는 것이죠.
현재(과거)의 네트워크는 각각의 장비가 개별적으로 동작을 하지만 SDN은 독립적으로 동작하는 OSPF, EIGRP 와 같은 Distributed control Protocol을 지양하자는 겁니다.
즉, SDN의 Control Plane은 장비 제어를 Configuration이 아닌 Global Network View를 통한 Function 제어로 네트워크 환경을 바꾸자는 것입니다.
SDN은 독립적이고 효율적이지 못한 Distribute Control Protocol을 사용하는 것이 아닌 Nerwork OS와 API를 사용해서 Control Mechanism을 프로그래밍 할 수 있게 하는 것에 또 하나의 큰 의미를 가지고 있습니다.
5. Layer를 연결하자!
자 그럼 각자 Layer를 연결하는 무언가가 있어야겠죠. 그림을 잠깐 보시고 넘어가서..
5.1. Application Plane <-API-> Control Plane
먼저 API… Application Programming Interface
네트워크만 다뤄보신 분들은 이 단어가 생소할 수도 있습니다. 다른 무엇인가와 연동하여 사용하기 위한 인터페이스 라고 생각하면 쉬울 것 같습니다.
예를 들어 Windows에서 사용하는 프로그램을 개발할 때 내가 만든 프로그램과 윈도우의 기능들을 연동하는 것을 말합니다.
SecureCRT의 코드로 간단하게 만들어 본 메시지 창입니다.
이를 직접 구현하려면
# $language = "VBScript"
# $interface = "1.0"
sub main
temp = crt.Dialog.MessageBox("ryusstory.tistory.com", cap, BUTTON_CANCEL)
end sub
결국 한 줄의 코드로 위와 같은 대화창을 생성할 수 있는 것이죠. 정해진 방식으로 윈도우에서 제공하는 기능을 쓰는 것이라고 생각하시면 됩니다.
어떠한 Platform을 제어하게 해주는 언어 같은 거죠.
SDN도 이와 마찬가지로 Network OS의 기능을 API를 통해 자유롭게 Application을 개발할 수 있는 것이죠. SDN에 있어 API를 사용한다는 의미는 매우 큽니다.
이 부분은 차후에 한번 더 말씀드리고 다음으로 넘어가서.
5.2 Control Plane <-API-> Data Plane
Control Plane과 Data Plane을 이어주는 것 중 하나가 바로 우리가 흔히 들어본 Openflow입니다.
출처: <https://www.opennetworking.org/sdn-resources/sdn-definition>
OpenFlow는 간단하게 Data Plane(장비)와 Control Plane을 이어주는 기술이라고 생각하시면 됩니다. 이 글 처음에 보신 기존 스위치 그림을 기억하시려나요…
출처: <http://bradhedlund.com/2011/04/21/data-center-scale-openflow-sdn/>
출처: <http://bradhedlund.com/2011/04/21/data-center-scale-openflow-sdn/>
두 그림을 한번 비교해 보시면 이해가 쉬우실 것 같습니다.
즉, SDN 네트워크에서 Data Plane을 Openflow를 통해서 제어하고 중앙에서 제어하는 Controller 와 통로를 만들어 주는 장비이다. 라고 생각하시면 될 것 같습니다.
저도 처음 시작할 때는 Openflow와 SDN의 위치 개념이 좀 애매했는데, 이해가 잘 되시려나 모르겠습니다. 하지만 저도… 아직은 좀 제대로 구분이 가지 않는 부분이 있습니다.
차후에 기술적으로 공부하면서 잘못된 부분이 있으면 수정하겠습니다.
SDN은 왜 등장하였고 무엇인가? – 1. 역사와 등장배경 http://ryusstory.tistory.com/271
SDN은 왜 등장하였고 무엇인가? – 2. 개념부터 정리하는 SDN http://ryusstory.tistory.com/273
SDN은 왜 등장하였고 무엇인가? – 3. 대세는 Platform http://ryusstory.tistory.com/274
