ONAP DCAE(Data Collection Analytics and Events Project) 연구

반응형

ONAP DCAE(Data Collection Analytics and Events) 연구

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

 

이번 포스팅에서는 ONAP 프로젝트에서 모니터링, 이벤트, 분석 등의 HA 기능들을 제공하는 ONAP DCAE(Data Collection Analytics and Events)에 대해 포스팅하고자합니다.

 

본 포스팅 내용은 예전에 DCAE에 대해 관련 연구를 진행하면서 정리한 내용을 기반으로 작성하였습니다. 먼저 간단하게 DCAE에 대해 소개를 한 뒤 아키텍쳐를 중심으로 하나하나 세부적으로 설명드리겠습니다. 

 

참고로 포스팅의 내용은 DCAE 공식 문서[1]를 참조하여 작성하였습니다.

 

DCAE는 하나의 단일 어플리케이션이 아닙니다. 이름에서 알 수 있듯이 데이터 수집 프로젝트, 분석 프로젝 트, 이벤트 트리거 프로젝트등이 하나로 모여 서로 간의 연동에 의해 일종의 HA(High Availability)를 제공하는 프로젝트입니다. 

 

따라서 DCAE는 DCAE외에 여러 ONAP 프로젝트들과 연동하면서 NFV 환경 전반에서 발생하는 장애, 분석 등의 기능을 제공합니다. 이를 위해 성능, 사용량과 같은 일반적인 모니터링 메트릭을 수집합니다. 물론 모니터링 메트릭을 수집하기 위한 프로젝트를 사용합니다. 

 

한마디로 DCAE는 VNF, 인프라등으로부터 데이터 수집하고 특정 이벤트를 처리하고 장애 분석을 위한 프레임 워크를 제공하는 NFV 환경 통합 장애 관리 프로젝트로 생각하실 수 있습니다.

 

DCAE Architecture

그림 1에서는 DCAE 하이레벨 아키텍쳐를 나타냅니다. 다소 복잡한 느낌이 드는데, 따지고 보면 각각의 역할에 맞게 프로젝트들과 기능을 분류해 놓은 컴포넌트의 집합입니다. 

그림 1. DCAE 하이레벨 아키텍쳐(참조 : [1])

크게 Analytic Application, Platform, OA&M, SDK, OpenECOMP의 컴포넌트와 연동하기 위한 인터페이스로 구성 됩니다. 기본적으로 DCAE는 멀티사이트를 기반으로 배포 되는데 이는 여러 개의 사이트 즉, 여러개의 클라우드 혹은 컨테이너 인프라를 가지는 경우에는 DCAE는 엣지 DCAE와 중앙 DCAE로 구분 됩니다. 

 

Data Collection Framework

Collection Framework는 클라우드 인프라, VNF 등으로부터 데이터를 수집하기 위한 여러 데이터 수집 툴들의 집합니다. 이는 가상화 된 대상 뿐만 아니라 클라우드가 운용되고 있는 물리 서버의 범위를 가집니다. 수집 범위로는 인프라에 대한 이벤트를 수집하거나, 성능 및 자원 사용량을 수집합니다. 예를 들어 사용량에 대해서는 실시간 스트리밍 방식으로 이를 수집해야하며, 로그 혹은 파일은 일괄 수집을 하기 때문에 Data Collection에서는 이를 나누어 놓았습니다. 

 

Data Movement

해당 컴포넌트는 수집한 데이터를 다른 사이트에게 전달하는 역할을 합니다. 이는 DCAE 핵심이기도 하면서 ONAP을 구성하는 여러 컴포넌트들 간 데이터 송수신이 가능하도록 합니다.

 

Analytic Applications

해당 컴포넌트에서는 분석을 위한 여러 컴포넌트들이 실행됩니다. Analytic Framework를 통해 필요한 분석 어플리케이션을 개발할수 있습니다. 이는 트래픽, 장애, 분석 모니터링 및 RCA 혹은 빅데이터를 위한 레포지토리가 포함될 수 있습니다.

 

ONAP DCAE 문서에서는 Analytic Application을 다음과 같이 분류하였습니다.

 

Analytic: 일반적으로 수집된 데이터를 분석, RCA 어플리케이션들을 위해 이를 처리합니다. 이는 리소스 사용량, 메트릭 계산, 여러 대상으로부터 수집한 데이터를 조건에 따라 처리하는 등의 기능을 가집니다. 

 

Fault / event correlation: 수집된 데이터를 기준으로 발생한 장애 혹은 이벤트 알람을 기반으로 이벤트 혹은 장애가 발생한 원인을 찾아내고, 이를 관련 프로젝트에게 전달하는 어플리케이션입니다. 참고로 이는 오픈소스 RCA 프로젝트 : ONAP Holmes에서 포스팅하였습니다.

 

Performance surveillance and visualization: 분석, 모니터링, 이벤트에 대한 여러 상태들을 관리자에게 제공하기 위한 시각적 도구들을 제공하는 어플리케이션입니다. 

 

Capacity planning: 여러가지 물리적인 레벨에서 리소스에 대한 증가/감소 조건을 관리 할 수 있는 기능을 제공합니다. 

 

Testing and troubleshooting: 특정 조건에 따라 기능을 테스트하고 문제를 해결하기 위한 기능을 제공합니다. 이는 간단한 기능 테스팅을 시작으로해 여러가지 테스트 검증을 진행합니다. 

 

Security: SDN 혹은 가상 네트워크 환경에서 보안 관련 데이터를 수집해 이를 탐지하고 해결하는 기능을 제공합니다.

 

여기까지 하이레벨에서의 대략적인 DCAE 구성을 살펴보았습니다. 이제 실질적으로 DCAE를 어떤 프로젝트들이 구성하고 있고 어떤 역할을 하는지 DCAE R1 버전을 기준으로 확인해보겠습니다. (현재 버전의 구성과 다소 다를 수 있습니다. )

그림 2. DCAE R1 아키텍쳐(참조 : [3])

그림 2에서는 DCAE R1버전의 구조를 나타내며, 구성하는 프로젝트들이 어떤 역할을 하는지 대략적으로 살펴보도록 하겠습니다.

 

Cloudify Manager: 다양한 레벨에서의 리소스 관리 프로젝트들을 연동하고, 서로 다른 기술들을 사용가능하게 하는 플러그인을 제공합니다. 또한 DCAE의 라이프 사이클 관리 엔진으로 다양한 리소스를 배포하고, 할당하거나, 구성합니다. 

 

Consul: 분산 환경에서 오류를 감지하거나 KV(Key-Value) 레포지토리를 위한 기술로 DCAE는 서비스 및 구성 레포지토리로 Consul을 사용합니다. 이를 통해 서비스 구성 자동화를 진행합니다.

 

Service infrastructure: DCAE를 운용하기 위한 플랫폼으로는 Docker 컨테이너와 하둡 클러스터를 지우너합니다. 컨테이너의 경우 다양한 어플리케이션을 실행하기 위한 환경이며 하둡 클러스터의 경우 빅 데이터 분석을 실시하기 위해 사용합니다.

 

Dispatcher: DCAE 서비스 제공을 위한 Northbound API를 제공합니다. 서비스 배포, 구성 변경 등과 같은 모든 트리거는 Dispatcher를 거쳐 Cloudfy Manager 플러그인을 통해 실질적인 동작을 수행하도록 합니다. 

 

Inventory: 다양한 템플릿, 리소스 정보, 가상 네트워크 간의 관계 등과 같은 정보 등을 추적합니다. 

 

PGaas: S데이터 저장을 위해 PostgreSQL 데이터베이스가 인벤토리를 지원합니다.(실질적 데이터 저장)

 

Policy Handler and Service Changing Handler: 외부 구성 요소를 위한 인터페이스 모듈입니다.

 

CDAP(Cask Data Application Platform: S오픈소스 소프트웨어로 Hadoop에 데이터 어플리케이션 플랫폼을 제공합니다. 

 

CDAP Broker: CDAP와 Cloudify Manager 사이의 CDAP Broker 인터페이스를 통해 Cloudify는 CDAP 관련 작업을 수행합니다.

 

여기까지 간단하게 ONAP DCAE를 구성하는 실질적인 프로젝트들을 간단하게 살펴보았습니다. 하나 하나 구체적으로 확인하기에는 내용이 방대해지기 때문에 여기서는 필요한 키워드만 찾고, 검색을 추천드립니다. 또한 현재는 R1을 기준으로 설명을 드렸기 때문에 현재 나와있는 혹은 나올 예정인 구조와 조금 다를 수 있습니다. 

 

DCAE Workflow

다음은 DCAE의 워크플로우에 대해 알아보겠습니다. 사실 ONAP에서는 데이터 수집, 장애 발생, 장애 처리, 장애 복구 등에 대해 Closed loop 프로젝트가 있습니다. CLAMP(Control Loop Flows and Models Platform)라고 불리우는 프로젝트는 장애 발생 부터 복구까지 closed loop 형태로 관련 프로젝트 들을 통합하여 기능을 제공하는 프로젝트입니다. 

 

그림 3, Closed Loop Flow's(참조 : [4])

그림 3에서는 Closed Loop의 흐름을 나타냅니다.  VNF로 부터 Collector들은 데이터를 수집합니다. 수집 된 데이터는 Analytics 어플리케이션들에 의해 분석 하고 정책에 따라 정책 관리를 담당하는 특정 컴포넌트에게 신호를 보내게 됩니다. 여기까지가 DCAE가 하는 담당하는 일입니다. 만약 장애가 발생하게 되면 정책 담당 컴포넌트는 어플리케이션을 관리하거나, 서비스를 관리하는 여러 컴포넌트들에게 명령을 내리고 사전에 정의 된 복구 액션 혹은 여러 액션에 따라 장애 복구를 수행하게 됩니다. 

 

결론

이번 포스팅에서는 ONAP DCAE 컴포넌트에 대해 설명 드렸습니다. 사실 ONAP 자체도 워낙 방대하고 DCAE를 구성하는 하나하나의 컴포넌트들 모두 각각의 세부적 기능을 가지고 있기 때문에 이번 포스팅에서는 관심있는 부분에 대해서만 대략 파악 하시고 추가 내용은 문서를 확인하시는 것을 추천드립니다.

 

혹 수정할 내용이나 궁금하신 사항이 있으시다면 언제든지 문의 주시면 답변드리겠습니다.

 

감사합니다.

인용글

[1] DCAE wiki : https://wiki.onap.org/pages/viewpage.action?pageId=1015831

[2] 오픈소스 RCA 프로젝트 : ONAP Holmes : https://delightwook.tistory.com/35

[3] DCAE - Service Components Onboarding and Lifecycle Management

[4] ONAP CLAMP : https://wiki.onap.org/pages/viewpage.action?pageId=4719898

업데이트로그

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

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

 

반응형

댓글

Designed by JB FACTORY