오픈소스 MANO 프로젝트 : OSM

반응형

오픈소스 MANO 프로젝트 : OSM 

안녕하세요 김민욱입니다. 

 

이번 포스팅에서는 NFV, MANO에 이어 실제 오픈소스 MANO 프로젝트들에 대해 알아보고 이들에 대한 비교를 해보고자 합니다. 오픈소스 MANO 프로젝트들은 ETSI 표준 문서를 기반으로 각자 개발되고 있습니다. 어떤 MANO 프로젝트는 연구소 하나가 프로젝트에 참여하는 경우도 있으며, 특정 프로젝트는 불특정 다수의 개발자들이 함께 개발하는 경우도 있습니다.

 

이번 포스팅에서는 오픈소스 MANO 프로젝트 중 OSM(Open Source Mano) 구조를 알아보고, 어떤 특징을 가지고 있는지 설명 드리겠습니다. 

 

해당 포스팅은 White Paper 3를 기반으로 연구하여 이에 대한 내용을 바탕으로 작성하였기 때문에 이해가 어려운 부분이 있을 수 있습니다. 해당 부분에 대해서는 말씀해주시면 언제든지 설명드리겠습니다. 

 

추가적으로 Openstack에서 제공하는 MANO 프로젝트인 Tacker는 이미 오픈스택 연구하기(2): NFV Project Tacker라는 제목으로 포스팅을 업로드 해두었습니다. 

 

오픈스택 연구하기(2) : NFV Project Tacker : https://delightwook.tistory.com/17?category=766948

 

오픈스택 연구하기(2) : NFV Project Tacker

오픈스택 연구하기(2) : NFV Project Tacker 안녕하세요 김민욱입니다. 본 포스팅에서는 오픈스택 NFV project인 Tacker에 대해 알아도록 하겠습니다. Takcer는 제가 NFV 환경에 대해 연구 할때 가장 많이 사용했..

delightwook.tistory.com

 

혹 부족한 내용, 문의가 있으시다면 연락주시면 답변드리겠습니다. 감사합니다. 

 

[출처] 해당 포스팅에서 나오는 모든 그림(그림 5,6,7은 일부분 수정)은 모두 White Paper Release 3 A Technical Overview(October 2017) 문서에서 가져온 것입니다.

 

OSM Scope

OSM은 Open Source Mano의 약자로 ETSI에서 주도하고 있는 MANO 프로젝트입니다. 해당 내용은 ETSI OSM 커뮤니티 White Paper Release 3 A Technical Overview(October 2017) 문서[1]를 바탕으로 연구를 위해 정리한 내용을 기반으로 작성되었습니다. 혹 틀린 내용이 있다면 말씀 부탁드립니다.

 

그림 1. OSM 심볼

OSM은 차이나 모바일의 Open Orchestrator와 AT&T의 ECOMP가 합쳐진 프로젝트입니다. 따라서 프로젝트의 크기가 굉장히 많은 부분을 포함하고 있습니다. 해당 포스팅에서 OSM에 대해서 하나하나 디테일하게 다루고 싶으나 그 양이 너무 방대해 우선 OSM이 무엇이고 어떤 모듈이 있는지에 간략히 먼저 말씀드리고 추후 자세하게 다루어 보도록 하겠습니다.  

 

그림 1. ETSI NFV MANO와 OSM 맵핌

그림 1에서는 ETSI NFV MANO와 OSM을 맵핑시켜놓은 것입니다.( 이번 포스팅에서 나오는 OSM 관련 그림은 모두 White Paper 3을 참조하였습니다.) 기존에 NFV에서 보던 구조와 조금 다른 부분이 있다고 느껴지실 것 같아서 이에 대해 간략히 먼저 설명을 드려야 할 것 같습니다.  OSM 커뮤니티에서는 프로젝트에 대해 디자인 타임과 런타임으로 두 개를 모두 포함하는 넓은 범위의 프로젝트를 정의하였습니다. 따라서 Ve-Vnfm 인터페이스와 연결된 부분은 VNFM, 그 위에는 NFVO, 그 아래는 VIM 이 될 것입니다. 여기서는 VIM으로써 Openstack과 같은 Private 클라우드뿐만 아니라 AWS와 같은 Public 클라우드도 염두에 두고 있습니다.

 

그럼 ETSI NFV OSM에서 말하는 Run 타임의 범위는 어디까지 일까요? White Paper R3 를 보시게 되면 해당 범위는 다음과 같습니다. 

* NFV 기반으로 라이프 사이클에 대한 여러 사항을 단순화하는 자동화된 서비스 오케스트레이션 환경

* SDN 컨트롤러 통합 플러그인 모델

* VIM 통합 플러그인 모델

* 모니터링 통합 플러그인 모델

* GUI, CLI, Python 기반 클라이언트 라이브러리 및 REST 인터페이스

 

다음은 디자인 타임의 범위입니다. 

* ETSI NFV MANO 데이터 모델 표준 규격 지원

* 네트워크 서비스에 대한 CRUD(Create / Read / Update /Delete) 지원

* VNF 패키지 생성 간소화

* 사용자 편의를 위한 GUI 제공

 

여기까지 런타임과 디자인 측면에서 OSM이 어느 정도의 범위를 가지고 프로젝트를 개발하고 있는지 알아보았습니다. 지금부터는 OSM Three의 구조를 보고 OSM에 대해 구체적으로 알아보겠습니다. 

 

OSM Three Architecture

OSM은 두 가지의 관점에서 여러 가지 프로젝트들을 통합하여 MANO로써의 기능을 제공하는 거대한 통합 프로젝트로 볼 수 있습니다. 이를 위해서 여러가지 프로젝트들과의 연동을 위한 플러그인, 모니터링, 기타 VNF 관리 툴들이 존재하고 있고 이에 대한 여러가지 관련 프로젝트도 함께 포함되어 있습니다.

 

그림 3. OSM Release 3 구조

그림 3에서는 OSM Release 3의 구조를 나타내고 있습니다. 주로 다른 프로젝트들과 연동을 위한 플러그인을 한 곳으로 묶어서 정의하고 있는 것 같습니다. 특이하게 DevOps라는 컴포넌트를 포함하고 있습니다.  요즘 주요 개발 키워드이기도 한 DevOps는 개발과 운영이 분리된 기존과 달리 개발자가 운영도 함께 하는 개념입니다. 따라서 OSM은 DevOps를 지원하고 있습니다. 

 

그림 4. OSM CI/CD 워크플로우

그림 4에서는 OSM의 DevOps 컴포넌트에서 CI/CD 워크플로우에 대해 설명하고 있습니다. 먼저 CI/CD는 CI(Continuous Integration)과 CD(Continuous Development)의 약자로 지속적으로 코드를 개발하고 기존의 프로그램에 추가해 나가는 것을 의미합니다.(실시간으로) 이에 따라 OSM에서도 DevOps를 위해 CI/CD가 어떻게 동작하고 있는지 나타내고 있습니다. 

 

OSM과 같은 오픈소스 커뮤니티에서는 Gerrit을 통해 코드 관리를 진행하고 있습니다. CI/CD 워크플로우의 Stage 1에서는 개발자가 업로드한 OSM의 특정 코드를 Trigger 모듈을 통해 Stage 2로 보내게 됩니다. Stage 2에서는 코드 라이선스, 모듈 테스트, 패키지 빌드, 아카이브 작업 등을 진행합니다. 특히 OSM 모듈은 모두 Docker 컨테이너를 지원하고 있습니다. 

 

Stage 3에서는 시스템 설치 테스트 및 Smoke 테스트 즉 기존 OSM 기능이 계속 작동하는지 API를 통해 확인하고 VNFD 업로드 등의 테스트를 수행한다고 합니다. 아마 제 생각에 Stage 3에서는 기본 적인 모듈 테스트가 진행되면 이를 시스템에 설치하고 OSM 기능 테스트를 진행하는 것 같습니다. 이 부분에는 조금 더 확인이 필요할 것 같습니다. Stage 4에서는 최종적으로 OSM 전체의 기능을 포함하는 테스트를 진행한다고 합니다. 

 

여기까지 OSM White Paper3에 나와있는 대로 OSM이 가지고 있는 DevOps 모듈에 대해 제가 이해한 것을 바탕으로 간략하게 설명을 진행하였습니다. 다음은 OSM의 User Interface 모듈에 대해 정리해보겠습니다. 

 

User Interface 모듈은 아마 아름에서도 알 수 있듯이 사용자가 OSM을 사용하기 위해 인터페이스를 제공합니다. 예를 들어 VNF, VNFD를 생성하기 위한 GUI 혹은 CLI 등이 이에 포함될 수 있습니다. 문서에서 말하는 주요 부분은 VNF 패키지 및 NS 카탈로그를 작성하는 모듈입니다. 또한 이에 대한 도구를 지원합니다. 뿐만 아니라 VNF/NS에 대해서 생성을 위해 어떤 디크스립터를 신속하게 개발할 수 있도록 그래픽 사용자 인터페이스도 제공하고 있습니다. 또한 VIM에 대한 액세스 자격 관리, GUI, 라이프사이클 관리 등을 모두 제공하여 OSM의 기능을 사용할 수 있도록 하고 있습니다. 


Service Orchestrator 모듈 또한 비교적 간단합니다. API 엔드포인트를 제공함으로써 관리자 UI를 통해 들어온 명령을 읽어 들여 다른 모듈들에게 전달하여 명령을 수행하도록 합니다. 이중 Service Orchestration Engine은 테넌시, 프로젝트, 사용자 등을 구분하고 이들에 대한 액세스 권한을 제어합니다. 물론 해당 기능은 오픈스택에도 존재하고 있습니다. 뿐만 아니라 Network Service 엔진은 NS 및 VNFD 구성을 진행하기 위해 데이터를 실질적으로 명령을 수행하는 모듈에게 전달합니다.

 

또한 해당 디스크립터에 대한 문법 체크를 진행합니다. Catalog Manager는 VNFD 혹은 NSD에 대한 라이프 사이클을 관리합니다. 한마디로 해당 모듈은 여러 모듈들과 사용자 UI를 연결해주기 위한 API를 관리하고 뿐만아니라 사용자, VNFD, NSD 등을 관리하여 다른 모듈들이 정상적으로 명령을 수행할 수 있는 일종의 게이트웨이로 볼 수 있습니다. 

 

이제 나머지 모듈들에 대해서도 간단하게 알아보도록 하겠습니다. 사실 해당 모듈들은 콘셉트적인 모듈들이라 문서에서도 구체적으로는 나타나 있지 않았습니다. 따라서 콘셉트적으로만 이런 것이구나 느낌만 이해하시면 될 것 같습니다. 

 

* Network Service to VNF Communication Module

   => N2VC 모듈은 Service Orchestrator 계층과 VCA 모듈을 연결하기 위한 플러그인 프레임 워크입니다.

* VNF Configuration and Abstraction

   => VCA는 VNF/EM에 대한 구성, 액션, 알람 활성화를 한다고 합니다.(사실 해당 부분은 구체적으로 보지 못해서 이해가 어렵네요)

* Resource Orchestrator Module

  => RO 모듈은 지리적으로 분산된 VIM과 SDN 컨트롤러들의 리소스를 관리하고 조정합니다. 

 

다른 모듈들에 대해서 각각의 역할에 대해 대략적으로 모듈의 역할에 대해 이해하셨다면 굉장히 잘 이해하셨다고 말씀드리고 싶습니다. OSM은 크기가 굉장히 큰 프로젝트라 하나하나 디테일하게 이해하기 어렵기 때문에 우선은 이런 식으로 모듈에 대한 역할과 어느 정도의 범위를 가지고 있는지 파악한 뒤 추후에 기회가 된다면 좀 더 자세하게 알아보도록 하겠습니다. 

 

OSM의 Monitoring 모듈의 핵심은 " 새로운 모니터링 시스템 및 기존 모니터링 시스템"과의 연동입니다. 사실 기존에 이미 활용 중인 모니터링 시스템들은 많이 존재하고 있고, 컨테이너 시대가 도래하면서 컨테이너 모니터링 시스템 또한 릴리즈 되어 있습니다. 이에 따라 OSM에서는 별도의 모니터링 시스템을 구축하는 것보다 여러 모니터링 시스템을 활용할 수 있는 플러그인 모듈을 구현한 것입니다. 아키텍처에서는 각 VIM에서 사용 중인 모니터링 시스템을 지원하는 것으로 나타나 있습니다. 

 

Real Implementation of OSM

제가 OSM을 연구하면서 가장 궁금했던 부분은 ETSI 표준 문서를 얼마나 많이 지켰냐 였습니다. 사실 아닌 MANO 프로젝트들도 있겠지만 제가 확인한 MANO 프로젝트들은 VNF=VM으로 인지 되어 있었습니다. 또한 표준 문서에서는 VNF는 하나 이상의 VNFC로 이루어져 있고, 이들은 내부 네트워크로 연결되어 있다고 명시되어 있었습니다.

 

그래서 ETSI에서 주도하고 있는 이 OSM에 대한 실제 VNFD를 살펴보고 분석하였습니다. 

 

그림 5. OSM VNFD - Network

그림 5에서는  OSM의 VNFD 예제입니다. 좌측에는 실제 VNFD가 명시 되어 있는 부분이고 우측은 VNFD에 따라 생성되었을 때 VNF의 구조를 나타냅니다. 먼저 외부 포트는 mgmt0와 west로 만들어져 있습니다. 해당 VNF의 이름은 Ref_Vnf_11입니다. 내부 VNFC 간에는 iface11, iface21로 연결됩니다. 이처럼 OSM의 VNFD는 표준에 따라 VNFC 간의 네트워크 및 외부와의 연결 네트워크를 VNFD에 구현하였습니다. 

 

그림 6. OSM VNFD - VM

그림 6에서는 OSM VNFD에서 VM에 대한 명시를 나타내는 그림입니다. iface10 인터페이스는 외부와의 연결을 위한 인터페이스이고 이는 mgmt0와 연결 됩니다. iface 11은 내부 네트워크로 정의되어 있습니다. VM 하나의 이름은 Ref_VM1이며 이미지는 ref_vm1.qcow2가 됩니다. 그 이외에는 VM의 가상 리소스를 정의하고 있습니다.

그림 7. OSM NSD

그림 7에서는 OSM NSD를 나타냅니다. 앞선 포스팅 NFV의 이해(2) : MANO 편[2]에서 하나의 NS는 여러 개의 VNF로 이루어질 수 있음을 확인하였습니다. 따라서 ETSI 표준 문서에는 VNF 간의 내부 네트워크가 정의되어 있습니다. 따라서 과연 OSM NSD에는 VNF 간의 네트워크가 정의되어있을까요? 먼저 하나의 NS 내부에  각 VNF는 인덱스로 번호가 새겨지게 됩니다. 그다음 각 VNF의 인터페이스(mgmt, west 등)는 서로 연결 되게 되며 이는 NSD에 명시하게 됩니다. 이처럼 OSM의 NSD는 VNF 간 내부 네트워크 및 VNFC 간 내부 네트워크에 대해서 VNFD, NSD에 각각 작성할 수 있는 기능을 지원하고 있습니다. 

 

 

결론

이번 포스팅에서는 OSM에 대하여 White Paper Release 3을 중심으로 내용을 작성하였습니다. 사실 OSM에 대해서 전반적인 큰 그림에 대한 이해를 목적으로 글을 작성하여 Release 3에만 포함되어 있는 내용들은 최소화하여 중간중간 빠진 내용이 있을 수 있습니다. 하지만 OSM의 구조나 특징에 대해서는 이해하시기에 괜찮으실 것이라고 믿고 부디 꼭 도움이 되셨으면 좋겠습니다.

 

감사합니다.

인용글

[1] OSM White Paper Release 3 : https://osm.etsi.org/images/OSM-Whitepaper-TechContent-ReleaseTHREE-FINAL.PDF

[2] NFV의 이해(2) : MANO : https://delightwook.tistory.com/15?category=766946

업데이트로그

-------------------------------------------------------------------------------------------------------------------------------

해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.

 

반응형

댓글

Designed by JB FACTORY