이 자료를 만든지는 1년 정도 되었습니다. 필요한 분들에게 도움이 됬으면 합니다.
1. NetCool Overview
Netcool은 이 기종 장비들에 대한 다양한 장애들을 어떻게 하면 실시간에 효율적으로 수집하고 관리 할 것인가. 또한, 장애가 발생하기 이전에 잠재장애에 대한 징후들에 대하여 조기에 발견하여 효과적인 방안을 강구하며 사전인지 및 대응조치를 할 수 있는 솔루션 입니다.
효율적인 수집 기능을 하기 위해 만들어진 Probe를 통해서 이벤트를 수집하고, memory 기반인 이벤트 처리 엔진을 통해 object server에 넣어주며, Impact 엔진을 통하여 각종 정보(database)를 이벤트와 결합시켜 정보를 추가(enrichment) 함으로서, 운영자에 보다 효과적이고 빠르게 장애에 대처 할 수 있게 해줍니다.
Netcool의 프로세스 절차는 수집, 통합,분석,디스플레이 입니다. 이것은 중요하므로 꼭 알고 있어야 합니다.
또한 Netcool을 다루기 위해서는 기본적인 perl 스크립트 언어, database query 문 정도만 알고 계신다면, 넷쿨 툴을 사용하기에 어렵지 않을 것입니다.
Perl 스크립트 언어는omnibus쪽에서 데이터를 파싱하고 가져오는 부분, impact 쪽에서 데이터 분석하는 부분에서 사용하게 됩니다.
앞으로 많이 듣게 되는 단어가 있을 것입니다. NetCool을 이루고 있는 기본적인 툴 요소 입니다. Probe , omnibus(object server), impact, Webtop 입니다. 이 4개가 NetCool을 이루고 핵심적인 rule 엔진 및 툴 입니다.
2. NetCool Architecture
먼저 Arhiecture에 대한 그림을 보도록 합시다.
overview에서 말씀 드렸듯이 프로세스는 수집, 통합, 분석, 디스플레이 입니다.
1) probe : 단일 유형의 event로서, 데이터 수집을 합니다.
이 probe는 능동적으로 장애를 알아서 캐치 하는 것이 아니라, File, DB, socket 에 있는 data 및 generic 한 것을 가져오는 역할을 합니다. 즉 passive역할 입니다.
좀더 자세하게 말씀드리면, file에 아래와 같이 있습니다.
NUMBER|LOCATION|DESCRIPTON
1. seoul|drop network
2 pusan|normal error
여기서 NUMBER, LOCATIOn, DESCRIPTION은 테이블의 필드 명이 되겠습니다.
File을 probe.rules에 정의한 대로 데이터 파싱을 하여 omibus(server object)로 전송하는 역할을 합니다. 그 역할을 하는 Probe.rules는 perl 언어로 되어 있습니다. 용도에 맞게 데이터 수집을 하는 probe는 약 350개 가량 있다고 합니다.
(스타에서 프로토스 종족은 프루브가 미네랄을 모은후 넥서스로 가져가지 않습니까? 이것처럼 넷쿨에서도 probe가 데이터를 수집해서 omnibus(object server)로 가져갑니다.ㅋㅋ)
2) omnibus(object server) : omnibus는 probe가 가져오는 데이터를 통합 할 수 있습니다. 즉, 데이터에 대한 필터링 및 이벤트 중복 제거, trigger를 할 수 있습니다. 이에 대한 데이터를 OMNIBUS 의 Object Server DB에 저장합니다. DB respository는 Derby DB를 임베디드 하여 사용하고 있었습니다.
3) impact : impact 또한 Netcool을 이루고 있는 것 중 핵심적 역할을 합니다.
Impact가 하는 일은 여러 데이터 소스(DAS 와 연결된 DB 및 미들웨어)와 OMNIBUS와 연계하여 데이터를 분석(analysis)하여 강화(enrichment)하는 것이 주된 목표 입니다. 이 부분 또한 중요하므로 따로 아래에 part를 만들어 설명하도록 하겠습니다.
4) webtop : probe, omnibus, impact에서 데이터 수집 및 통합, 분석을 한 데이터를 web 화면 또는 client화면에서 볼 수 있도록 하는 것이 webtop의 역할 입니다. 여기서는 SQL 문 입력을 할 수 있으며, SQL로 작성한 뷰를 그래픽적으로 볼 수 있습니다.
3. NetCool DB 분석
Netcool db분석을 하는 이유는 Netcool을 tool로 사용하는 것보다, 어떻게 이루어져 있는 내부적으로 보려고 합니다. IBM 교육에서는 이 부분에 대해 설명을 전혀 하지 않았지만, 이 부분을 알아야 netcool을 분해해서 볼 수 있다고 생각됩니다.
위에서 말씀 드렸듯이, probe가 수집한 데이터는 omnibus에서 통합한 후, object server에 데이터가 저장된다고 하였습니다. 또한 이 Object Server는 임베디드 Derby DB 입니다.
*. Database 구성 및 table 구성
1) alets (database) : 메시지 event에 대한 정보들이 저장되는 DB 입니다. 특히 눈여겨 볼 table은 status 입니다. 이 테이블 안에 모든 event 관련 정보가 들어가 있습니다.
2) iduc_system (database) : iduc_system DB의 역할은 probe 와 object server간의 channel 정보가 들어가 있습니다.
3) security(database) : ACL 관련 table이 들어가 있으며, User에 따른 권한 및 menu 속성, 트랜잭션 권한이 들어가 있습니다.
4) Service(database) : object server 상태에 관련된 정보가 들어가 있습니다.
5) tools(database) : menu, actions, prompt 에 대한 table이 있으며, webtob (display)에서 구성되어 있는 속성들을 확인할 수 있습니다.
위의 5개의 database들이 object server에서의 핵심적인 역할 을 하고 있습니다.
Object server를 하나 추가 할때마다 위의 DB들이 설치가 각각 된다고 보시면 됩니다.
4. NetCool Impact 분석.
Impact 를 좀더 뜯어 봅시다. 위에서 말씀 드렸듯이 impact는 여러 데이터 소스(DAS 와 연결된 DB 및 미들웨어)와 OMNIBUS와 연계하여 데이터를 분석(analysis)하여 강화(enrichment)하는 것이 주된 목표 입니다.
DSA에서는 참조 할 DB 및 middle ware(XML, LDAP, SNMP)등에 붙을 수 있는 adapter 모듈입니다.
Event Listener은 OMNIBUS와 붙을 listener 입니다. 물론 OMNIBUS 뿐만 아니라, DB ,IBM 기반의 event inventory와도 붙을 수 있습니다.
Policy engine은 Event Listener에 등록된 omnibus, 그리고 eventReader를 통해 omnibus에 있는 데이터를 읽어오며, DSA 에 붙은 참조할 데이터와 조합을 하게 되는 실질적인 Rule engine 입니다.
자, 여기서.. 그렇다면 impact를 통해서 enrichment를 한 데이터는 어디에 저장될까요? 그 데이터는 omnibus Object Server에 저장되게 됩니다. 즉, omnibus object server와 DSA에 붙은 모듈을 참조하여 가공한뒤 다시 object server에 데이터가 저장된다는 얘기 입니다.
5. NetCool 소스 자체 분석.
Netcool 소스에서 C 부분은 동적 컴파일 되어 있어 제가 까보진 못했고, jar 및 프로그램 아키텍쳐는 보통 어떻게 되어 있는지 확인해 볼 수 있었습니다.
6. Q&A (궁금한 사항을 질문/답변 형식으로 구성해 보았습니다.)
1) WEBTOB 같은 monitoring 및 display 화면을 커스터 마이징 할 수 있는가?(IBM에서는 지원하지 않는다고 합니다. 현재 있는 화면을 써야 합니다. 만약 우리가 구성을 하는 방법은, 생각해 보니 이렇게 하면 가능할 것 같습니다. Object Server에 모든 event 정보들이 들어갑니다. Derby DB에 붙여서 핸들링을 해서 사용할 수 있는 방법이 있으며, 다른 방법은 netcool에서는 gateway라고 하는데, 다른 DB에 구성(DB2 만 된다고 합니다.)을 하여 event정보를 online으로 sync를 맞추어 전달됩니다. 그쪽 DB에 붙여서 커스터 마이징 하면 가능합니다.)
2) Omnibus는 memory db라는데 어느 정도 데이터를 저장하고 실시간 처리를 하는데 무리가 없는가?
(event성 데이터 이기 때문에 , 하루 정도 데이터만 event 저장을 한다고 합니다. 백업을 두기 위해서는 gateway를 설정을 하거나 백업을 두어야 합니다.)
3) probe에서 지원되지 않는 데이터를 수집하기 위해서는 어떻게 해야 하는가? (in-house경우)
(probe를 직접 만들 수 있으나, 시간 및 공수가 많이 들어갈 것으로 보입니다. 우회 할 수 있는 방법은 해당 event data를 file로 저장하거나 socket으로 뿌려줄 수 있는 external programing을 하는 방법이 좋을 것 같습니다. )
4) netcool을 가지고 개발을 하게 된다면 어떤 langague및 어느정도 실력이 필요한가?
(probe 및 impact에서 perl 스크립트 언어 기반을 사용합니다. 물론 IBM에서 perl 스크립트를 가지고 api wrapping을 하였습니다. 그것을 가지고 사용합니다. 기본적인 스크립트 실력이면 가능하리라 봅니다.)
감사합니다.
