본문 바로가기
서버운영 (TA, ADMIN)/네트워크

[네트워크] NMS와 TMN

12bme

네트워크의 비약적인 발전으로 초기 연구 모델이었던 네트워크는 거대한 규모로 발전하였습니다. 따라서 네트워크의 관리 필요성이 대두되었습니다. 초기 몇 명의 관리자가 수작업으로 관리할 수 있엇던 것이 이제는 관리가 불가능하게 되었습니다. 이제는 관리만을 위한 별도의 시스템으로 네트워크를 관리해야 효율적으로 관리할 수 있게 되었습니다. 이 장에서는 네트워크 관리 시스템인 NMS와 망관리 시스템인 TMN에 대해 알아보도록 하겠습니다.




NMS 소개


NMS

네트워크가 점점 커가면서 여러 문제들을 야기하게 됩니다. 네트워크가 커진다는 것은 하드웨어와 응용프로그램들 그리고 사용자들이 늘어나고 복잡해지는 것을 의미합니다. 이때 발생하는 문제를 간단히 생각해보면 이기종의 하드웨어와 응용프로그램들이 하나의 구조 속에 포함됨으로 새로이 발생하는 문제가 있을 것이며 확장된 네트워크가 제대로 성능을 발휘하는가와 확장된 네트워크에 에러는 없는가를 확인해야 되는 문제가 생깁니다.


커다란 네트워크망은 사람의 힘으로 관리할 수 없게 되는데 여기서 우리는 네트워크 관리툴 킷을 필요로 하게 됩니다. 이때 NMS는 물리적인 네트워크 시스템을 관리하는 소프트웨어 관리툴을 의미하는 것으로 네트워크망에 여러 벤더들의 다양한 장비가 포함되면 될수록 관리에 애를 먹게 됩니다. 그리고 네트워크를 조금 확장할 때마다 관리비용은 몇 곱으로 늘어나게 됩니다.


과거에는 네트워크의 구조가 단순하고 노드도 많지 않았으므로 NMS라는 소프트웨어에 큰 비중이 없었지만 최근의 네트워크는 규모도 클 뿐만 아니라 네트워크를 구성하는 하드웨어도 각양 각색이어서 네트워크 관리자의 물리적 네트워크 추상화에는 한계가 생기게 되었습니다.


NMS의 중요성이 부각되면서 SNMP(Simple Network Managerment Protocol)라는 표준이 제정되고 기존의 SNMP에 보안의 기능을 강화한 SNMP II와 secure SNMP가 표준으로 자리잡고 있습니다. NMS는 단지 관리의 기능뿐만 아니라 차후 네트워크의 확장을 위한 분석 툴로써의 가치도 지니고 있습니다.


NMS는 NMS가 포팅되는 플랫폼과 플랫폼에서 구동되는 애플리케이션이라는 범주로 구분할 수 있습니다. 여기서 플랫폼이라는 것은 NMS가 포팅되는 운영체제를 말하는 것이고 애플리케이션은 그 운영체계에서 작동하는 각종 네트워크 벤더들의 네트워크 관리 솔루션을 의미합니다.



SNMP와 RMON

SNMP(Simple Network Management Protocol)는 말 그대로 단순한 네트워크 관리 프로토콜 입니다. SNMP는 RFC 1157에 명시되어 있는데 여기서 RFC는 Request For Comment의 약자로 TCP/IP에 관련된 사양들을 명시하여 놓은 문서를 일컫습니다. 이 문서들은 때때로 새로운 프로토콜의 기반이 되는데 NIC(Network Information Center)이라는 곳에서 관장합니다.


NIC는 인터넷의 DNS(Domain Naming Service)를 부여하여 주는 세계적인 기관입니다. SNMP는 UDP 세션을 사용합니다. 보통 네트워크 관리를 위해서는 지속적이고 단순화된 네트워크 정보를 필요로 하므로 UDP 세션이 합리적입니다. SNMP는 모든 네트워크 정보들, 즉 현재의 네트워크 성능, 라우팅 테이블, 네트워크를 구성하는 여러 값들을 관리합니다.


이러한 값들을 관리한다는 것은 네트워크를 어떤 수치로서 제어할 수 있다는 것을 의미합니다. 최근의 SNMP 시스템들은 이러한 추상적인 구성을 보다 구체적으로 그래픽화하여 관리를 용이하게 하고 있습니다.


SNMP는 주로 라우터 정보, 활성 TCP 접속 정보, 라우터의 ICMP를 이용한 호스트의 활성 상태 정보를 알 수 있지만 가장 유용한 기능은 네트워크의 확장을 용이하게 할 수 있다는 것입니다. 여기서 확장성이라는 것은 네트워크의 대역폭 조정, 속도를 고려한 파일 시스템의 적용, 클라이언트의 재배치, 트래픽의 감시를 통한 네트워크의 합리적인 운영 등을 의미하비다.


SNMP의 경우, 폴링이라는 기능이 네트워크에서 대량의 패킷을 통해 네트워크 트래픽을 증가시킨다는 단점 때문에 최근에는 RMON(Remote Monitoring)이 각광을 받기 시작했습니다. SNMP는 원래 TCP/IP를 네트워크에서 라우터를 핸들링하기 위한 프로토콜로 디자인이 되었었습니다. 하지만 TCP/IP를 기반으로 하는 상위 계층의 서비스 프로토콜들이 계통을 이루게 되면서 점점 IP와는 독립적인 프로토콜로 설계되기 시작했씁니다.


즉, SNMP는 프로토콜 독립적인 프로토콜입니다. 때문에 IP기반 뿐만 아니라 IPX 기반위에서 서비스를 구현할 수도 있습니다. 하지만 설치 될 때는 IP를 기반으로 인스톨됩니다. SNMP는 단일 프로토콜이 아니라 다음의 두 가지 프로토콜과 더불어 패키지화 되는데 그것은 MIB(Management Information Base)와 SMI(Structure and identification of Management Protocol)입니다.


MIB는 네트워크의 상태를 저장하고 있는 일종의 데이터베이스를 의미하는데 뒤에서 소개될 TMN에서 소개 및 구현 방법까지 자세히 다룰 것입니다. SMI는 서버와 네트워크용 디바이스 장치들의 통신 방법에 대한 규정을 의미합니다. 


SNMP에서 관리를 위해 사용하는 명령의 종류에는 SNMP-Get, SNMP-Set, SNMP-Trap이 있습니다. 이들은 'TMN'에서 다루는 명령과 유사한 것으로 각각을 대비시키면 다음과 같습니다. SNMP-Get은 TNM의 M-Get, SNMP-Set은 TMN의 M-Set(M-Create, M-Delete도 포함), SNMP-Trap은 TMN의 M-Report-Get과 같은 기능을 담당합니다. 각각은 TMN 단원에서 자세히 설명하고 있지만 간단히 살펴보고 지나가면 다음과 같습니다.


Get은 관리자가 관리할 대상에 대해 알고자 하는 정보가 있을때 Get 명령을 내려 해당 정보를 받아 오게 됩니다. Set은 관리할 대상의 특정 정보를 바꾸거나 대상 자체를 생성하거나 제거할 때 사용합니다. Trap은 Agent가 Manager에게 알려야 할 이벤트가 발생하면 그 이벤트를 Manager에게 전송해주는 것을 뜻합니다. 


SNMP에서 PDU(Protocol Data Unit)의 흐름을 그림으로 그려보면 다음과 같습니다.



그림(A)는 Get, Set 또는 그 밖에 Manager가 Agent에게 명령을 내려 그 결과를 받는 것을 보여주고 있습니다. Manager는 Agent에게 PDU를 보내고 Agent에게서 결과를 PDU를 다시 받습니다. 그림(B)는 Agent가 Manager에게 알려야 될 내용이 있을때 PDU를 보내오는 것을 보여주고 있습니다. 앞에서 언급한 SNMP-Trap이  이 경우에 해당합니다.


네트워크 상에서 SNMP 서버와 통신하는 네트워크의 디바이스들은 SNMP 서버와 Polling이라는 방법과 Interruption이라는 방법으로 통신하게 됩니다. Poll이라는 의미는 사전을 찾아보면 '투표하다'라는 뜻이 있는데 네트워크의 모든 디바이스들은 SNMP 서버에게 자신의 현재 상태를 이야기하게 되는데 사실 Polling이 네트워크의 트래픽을 증가시키는 원인이 됩니다. 이것이 SNMP의 최대 약점이 되었습니다.


Interruption은 SNMP 서버가 네트워크 상의 디바이스로부터 검증된 인터럽트를 받는 것입니다. 만약 디바이스에게 어떠한 문제가 생기면 문제가 없는 다른 디바이스가 문제가 생긴 디바이스와의 연결을 통해 장애가 생긴 디바이스의 상태를 인터럽트 받는 것입니다.


Interruption 역시 문제가 있는데 그것은 디바이스가 SNMP 서버에게 보내는 메시지는 서버의 CPU 사이클을 너무 많이 요구한다는 것입니다. 때문에 네트워크 상의 병목현상을 초래하게 됩니다.


이러한 문제점 때문에 다른 프로토콜들이 시도되고 있습니다. 이기종 장비를 지원하는 CMIP(Common Management Information Protocol)이 한 예가 되는데 이것은 TMN에서 사용하는 프로토콜로 다음 절에서 자세히 다룰 것입니다. 그리고 또 다른 프로토콜에는 최근 웹브라우저를 통한 NMS를 구현하는 HMMS(Hyper Media Management Service)라는 프로토콜이 있습니다.


위에서 SNMP의 약점이 Polling과 Interruption이라고 하였는데 이러한 네트워크 트래픽으로 인한 문제점을 파악한 IETF(Internet Engineering Task Force) 위원회에서 RMON(Remote Monitoring) 규격을 제안하였습니다. SNMP는 일정한 간격을 가지고 폴링을 수행하는데 반해 RMON의 경우는 일정한 시간동안의 데이터들을 RMON이 관리하여 서버에게 보내게 됩니다.


즉, 서버는 RMON과 대화를 하는 것이고 RMON은 일종의 프록시 기능을 하는 것입니다. 하지만 RMON이 네트워크의 트래픽은 감소시켜 주지만 그 기능은 아직은 단순하고 기대에 못미치는 수준입니다. 특히 네트워크 상의 예외적인 에러에 대한 메시지 보고가 자세하지 않고, 메시지를 단순히 보고만 하는 수준입니다. 때문에 RMON II가 발표되어 이러한 에러 메시지에 대한 처리 사항까지 보고하는 수준, 즉 에러 진단 수준에 이르렀습니다. 이상에서 우리는 NMS에 대한 간단한 소개와 SNMP, RMON에 대한 정의 정도 수준의 내용을 살펴보았습니다. 굉장히 짧은 내용만을 살펴본 것인데 이것은 '망관리 시스템'의 주 내용인 TMN을 다루기 위한 서막이라고 생각하면 될것입니다.


이제 설명하고자 하는 TMN은 위의 문제들의 해결과 더불어 관리의 모든 기능을 포함하고 있다고 해도 과언이 아닙니다. 요즈음 TMN을 다루는 업체나 대학원이 늘고 있지만 기초적인 이론을 쉽게 다루고 있는 이론서는 전무한 상태입니다. TMN은 굉장히 포괄적인 내용이기에 그것을 작은 지면에 모두 다룬다는 것은 불가능하지만 기초적인 이론과 더불어 이해를 도울 수 있는 내용을 소개함으로 관련있는 독자나 관심이 있는 독자들에게 도움이 될 것입니다.



TMN


TMN이란

TMN(Telecommunication Management Network)은 용어에서 알 수 있듯이 네트워크를 관리하는 통신망을 의미합니다. 네트워크를 관리하기 위한 또 다른 통신망을 구축하는 것을 의미하지만 실제로는 물리적인 관리망을 새롭게 구축하는 것은 아닙니다. 간단히 말하면 TMN은 기존의 통신망을 공유하는 가상의 통신 관리망을 뜻합니다. TMN은 국제 표준을 따르는 것으로 국가 기간망등 거대한 네트워크를 관리하기 위해 많이 사용됩니다.


현재의 통신망은 여러 공급 업체들의 다양한 장비와 시스템으로 이루어져 있기 때문에 효율적인 운영 관리, 확장 및 유지보수가 굉장히 어렵습니다. 따라서 이러한 환경에서 변화에 능동적이고 효율적으로 대처하고 표준화된 개방형 방식의 망관리 체제 구축을 위해서 TMN의 도입이 요구되고 있는 것입니다.


TMN의 목적은 telecommunication 네트워크를 관리하는 것인데 표준화된 TMN 인터페이스는 기종이 다른 시스템 사이의 상호접속(interconnection)을 가능케하고 관리 시스템과 네트워크를 이루는 통신 사이에 관리 정보를 교환(exchange)할 수 있도록 합니다. 그리고 TMN 인터페이스는 교환된 관리 정보를 송신/수신(send/receive)하면서 자원들을 관리합니다.


TMN은 개념적으로 정보를 송수신하는 점에서 일반 통신 네트워크와 구분되지만 같은 네트워크 설비를 공유하면서 네트워크를 관리 및 제어하게 됩니다.



TMN의 필요성

TMN의 필요성(목적)에 대해서는 NMS를 소개하는 부분관 TMN을 소개하는 부분에서도 언급했지만 다시 한 번 간단히 기술하면 다음과 같습니다. TMN은 다른 서비스 제공자(provider)들 사이에서 관리 정보를 쉽게 교환(exchange)할 수 있도록 합니다. 즉, 표준화된 방법을 이용하여 통신 하드웨어와 응용 프로그램들이 통신하게 함으로써 새로운 하드웨어와 애플리케이션을 쉽게 부가 및 통합할 수 있게 하여 확장을 용이하게 합니다.


따라서 새로운 애플리케이션과 서비스를 쉽게 배치, 개시할 수 있게 됩니다. TMN은 특히 표준화된 인터페이스를 제공하기 때문에 여러 개발 회사들의 솔루션을 함께 사용할 수 있습니다. 그리고 non-OSI 시스템에 대해서도 인터페이스를 제공하여 TMN 기반이 아닌 기존의 시스템들과도 최대한 연동할 수 있도록 솔루션을 제공합니다.



TMN의 구조를 살펴보면 크게 두 개의 시스템으로 나눌 수 있는데 Manager와 Agent로 나눌 수 있습니다. 단어에서 알 수 있듯이 관리 시스템과 관리 대행자 시스템을 뜻하는 것으로 관리 대행자인 Agent는 자원(Resource)들을 관리하게 됩니다. 여기서 자원(Resource)이란 네트워크를 구성하는 H/W, S/W 등의 장비 일체를 뜻합니다.


위 그림을 간단히 살펴보면 Manager는 CMIP(Common Management Information Protocol)이라는 프로토콜에 각종 명령 및 요구들을 실어서 Agent에게 보냅니다. 그러면 Agent는 그 명령 및 요구들을 받아서 관리 객체(Managed Object, MO)를 이루는 트리에서 해당 관리 객체를 검색한 뒤 명령을 수행하게 됩니다. 


관리 객체란 실제 자원을 Agent가 관리할 수 있도록 모델링한 것인데 트리구조를 이루게 됩니다. 그리고 관리 객체들은 실제 자원과 연결이 되어 있어서 관리 객체의 변동은 그래도 실제 자원에 반영이 됩니다. 관리 객체에 대한 내용과 모델링에 대한 내용은 이후에 자세히 설명이 나옵니다. 그러고 나서 Agent는 실행 결과를 다시 Manager에게 보내게 되고 Manager는 결과를 수신받아 분석과 같은 일련의 작업을 하게 됩니다. Agent는 Manager가 보내온 명령만 수행하는 것이 아니라 끊임없이 관리객체들을 점검하면서 Manager에게 보내야 할 이벤트들이 발생하면 이벤트 리포트를 보내는 역할도 수행합니다.


TMN은 앞에서 표준을 따른다는 말을 했는데 실제로 모든 것이 표준으로 시작해서 표준으로 끝납니다. 그래서 Manager와 Agent가 주고받는 관리 정보들은 표준화된 내용으로 정해진 규칙에 따라 정해진 프로토콜을 이용하여 오가게 됩니다. 이제 각각을 자세히 알아보도록 하겠습니다.



구성 요소

컴퓨터와 관련된 모든 분야가 그렇겠지만 특히 TMN은 용어를 중시합니다. 이번 단원에서는 TMN을 이루는 요소들을 용어 위주로 설명할 것입니다. 이 부분을 잘 읽어야 이후에 내용이 쉽게 이해가 될 것입니다.


Manager와 Agent

SNMP속에서도 관리자와 관리 대행자라는 의미의 Manager와 Agent가 있지만 Agent dummy 시스템으로 실질적인 관리대행자의 역할을 수행치 못했습니다. 하지만 TMN속의 Agent는 스스로 역할을 수행하는 지능을 갖춘 시스템입니다. SNMP와 TMN을 다른 시스템과 비유하자면 중앙 집중의 시스템과 분산 처리의 클라이언트/서버 시스템으로 표현할 수 있으리라 생각됩니다.


각각을 설명하면 우선, Manager와 Agent는 네트워크 자원들 즉, 네트워크와 관련된 모든 것들을 관리하는데 목적이 있습니다. 먼저 Manager는 Agent에게 관리를 위한 명령을 보내고 Agent에게서 그 결과에 대한 보고 또는 에러메시지를 수신하게 됩니다.


Agent는 Manager로부터 온 명령을 수행하고 이에 대해 응답을 보내게 됩니다. 그리고 네트워크 자원을 끊임없이 관리하며 알려야 될 정보가 있으면 Manager에게 그 내용을 통지하게 됩니다. Agent가 네트워크 자원을 관리하는 방법은 실제 자원을 그대로 반영하고 있는 관리 객체(Managed Object)를 유지보수하는 것인데 논리적인 관리 객체의 변화는 그대로 물리적인 실제자원에 반영이 됩니다.



관리 객체(Manage Object)

관리 객체는 Agent가 관리하는 Tree인데 TMN은 객체 모델을 이용하여 통신자원들을 표현하고 관리하게 됩니다. 관리 객체는 관리를 받게 되는 자원들이 추상화된 것으로 속성(property)과 특성(characteristic) 그리고 자원들 상호 간의 관계(relationship)로 이루어지게 됩니다. 아래 그림은 모뎀을 예로 들어 모뎀의 관리객체를 표현한 것인데, 그림에서 느낄 수 있듯이 관리 객체는 관리 명령들이 실행될 실제 자원을 표현하게 됩니다.



Manager에서 관리 객체를 통해 실제 자원을 갱신하는 과정을 간단히 살펴보면 다음과 같습니다. 



Manager는 모뎀에 관련된 SET 오퍼레이션-속성값을 바꾸는 명령을 작성한 후 Agent에게 SET 오퍼레이션을 보냅니다. 그러면 Agent는 모뎀 관리 객체의 값을 보내온 값으로 set하게 됩니다. 그러면 자동으로 모뎀 하드웨어의 정보가 갱신됩니다.


관리 객체를 만들기 위해서는 관리 정보 모델인 MIB를 구성해야 됩니다. MIB를 설명하면 다음과 같습니다.



관리 정보 모델(Management Information Model)

관리 정보 모델은 네트워크 자원들을 관리하기 위해 자원들을 논리적으로 정의한 것을 의미하는데 이 속에서 자원에서 관리해야 할 속성들과 이벤트를 생성할 것인지 등을 정의하게 됩니다. 정보 모델은 ASN.1과 GDMO language를 이용하여 작성하게 됩니다. 그리고 정보 모델은 MIB(Management Information Base)이라 불립니다. MIB를 한마디로 정의하면 관리객체 인스턴스의 집합이라 할 수 있습니다. 여기서 인스턴스란 관리 객체 클래스를 이용하여 실제로 구현한 객체를 뜻합니다.


객체의 속성과 상호관계는 이 MIB(Management Information Base)속에 정의가 됩니다. MIB 속의 관리 객체를 정의하는데는 GDMO라는 언어를 사용하며 관리 객체속의 attribute의 syntax를 정의하는데는 ASN.1이라는 언어를 사용합니다. 그 용어를 풀이하면 GDMO는 Guidelines for the Definition of Managed Object이고, ASN.1은 Abstract Syntax Notation 1입니다. 계속해서 설명하면 GDMO는 객체지향언어입니다.


C++와 비슷한 형식을 취하는데 클래스를 정의하고 여러 인스턴스를 생성할 수 있으며 이 클래스는 다시 Package들로 나뉘게 되며 Package는 다시 attribute들로 구성이 됩니다. ASN.1은 앞에서 언급했듯이 attribute들의 Syntax를 정의하는데 이용됩니다. Syntax는 정수(integer)와 문자열(string)같은 간단한 형식 또는 복잡한 구조로 이루어지게 됩니다.


GDMO는 객체지향 언어라고 말을 했는데 GDMO로 구현한 MIB은 상속의 관계를 가지게 됩니다. 앞에서 관리객체의 예로 모뎀을 들었는데 이 또한 상속을 받아 구성하게 됩니다. 그것을 그림으로 표현하면 다음과 같습니다.



관리 객체와 객체의 속성을 GDMO로 정의하면서 이들은 객체 식별자(Oid - Object Identifier)로 유일하게 식별이 됩니다. Oid는 숫자의 연속인데 ISO는 이들을 식별할 수 있도록 유일한 Oid를 부여합니다. 그리고 이것을 이용하여 식별자로 구성된 트리를 만들 수 있습니다. 이 트리를 구성하려면 트리구조로 분기(branch)할 수 있도록 Oid의 값을 부여해야 합니다. 이렇게 해서 만든 트리를 Registration 트리라 합니다.



GDMO와 ASN.1에 대해서는 'Object Modeling'에서 자세히 다루게 되며 예제도 다루게 됩니다. 관리 객체와 관리 시스템 사이에는 정해진 관리 정보를 주고받음으로 관리가 이루어지게 됩니다. 이제 관리 정보의 교환에 대해 정의한 부분을 알아보겠습니다. 그리고 그러한 정보(혹은 명령과 응답)에는 어떤 것이 있는지 살펴보겠습니다. 



관리 정보 교환

여기서는 관리 정보를 어떻게 교환할 것인지, 무엇을 교환할 것인지 정의한 내용을 다룹니다. TMN에서는 이들 관리 정보의 교환을 위해 제공되는 서비스를 CMISE라 부릅니다.


CMISE는 Common Management Information Service Element의 약자로서 manager에게 get/set 등의 명령을 Agent에게 보낼 수 있도록 하고 또한 Agent로부터 오는 알람과 이벤트를 수신할 수 있도록 합니다.


1) Common Management Information Service(CMIS)

관리(Managment) 프로세스가 사용하는 서비스들이 정의되어 있습니다. 서비스들 중 하나를 예로 들면, 생성(create), 제거(deletion), 수정(set), 조회(get) 등이 정의되어 있는 운영 서비스가 있습니다.


여기에서 서비스를 정의한다는 것은 일반적으로 무슨 서비스를 가능하도록 하며 그 서비스에는 무슨 파라미터가 필요하며 또 서비스를 수행한 뒤에는 어떤 결과를 돌려줘야 하는지 등을 기술하는 것을 의미합니다. 그리고 이 정의는 language에 독립 적입니다.


2) Common Management Information Protocol(CMIP)

서비스를 제공하는 프로토콜을 정의한 것으로서 이 프로토콜은 추상적인(abstract) 서비스를 기계가 판독(machine readable)할 수 있는 포맷으로 전송(transmit)할 수 있도록 만들어 줍니다.


CMIS에는 다음과 같은 것이 있습니다. 간단한 응답에 기초한 서비스, Association 서비스, Notification 서비스, Operation 서비스가 있으며 스코핑(scoping) 필터링(filtering)을 제공하고 동기화(synchronization)와 Linked Reply를 제공합니다. 각각에 대해 알아보면 다음과 같습니다.



Operation Services


1) M-Create

Manager가 Agent에게 이 명령을 보내면 Agent는 오브젝트 클래스의 새로운 인스턴스를 생성하게 됩니다. 인스턴스란 비어 있는 클래스에 값을 집어 넣어 실제로 생성된 객체를 의미합니다. 이때 Agent는 manager가 보내온 정보에 따라 속성 값들을 새로이 할당하게 됩니다. 만일 새로운 값이 오지 않은 체 명령만 오게 되면, Agent는 내부에 정의된 default 또는 initial 값을 할당하게 됩니다.


즉, Create는 manager의 명령에 의해서 뿐만 아니라 Agent가 직접 내부적으로 명령을 내릴 수 있습니다. 이것은 보통 Agent가 필요한 관리 객체인 경우, 서비스가 개시되기 전 내부적으로 객체를 생성해야할 필요가 있을 때 사용합니다. 이 서비스는 Confirm 서비스인데, 이는 Manager가 보내온 명령을 Agent가 수행한 뒤 그 결과를 Manager에게 다시 전송하도록 지정하는 것을 뜻합니다. 


Manager에서 M-Create Request를 보내면 Agent는 생성작업후 M-Create Confirm을 Manager에게 되돌려 줍니다.


2) M-Set

하나 또는 하나 이상의 관리 객체의 속성 값을 검색하는 데 사용되는 명령으로 manager가 알고 싶은 관리 객체의 속성을 Agent에게 검색해서 결과를 보내오라고 시키는 것입니다. 이 서비스는 스코핑, 필터링, 동기화와 Linked Reply 등과 함께 사용할 수 있는데, 이들은 Get 명령을 쉽게 수행할 수 있도록 도와줍니다. 그리고 Get 명령도 Create(생성) 명령과 마찬가지로 Confirmed 서비스입니다.


3) M-Action

M-Action은 manager가 agent에게 특정 관리 객체에게 특정 행위(action)를 시키는 것을 뜻합니다. 예를 들어, 네트워크에 물려있는 장비 중 조건을 만족하는 특정 장비의 파워를 끄려고 할 때 이 명령을 이용하면 될 것입니다. 파워를 끄는 작업은 단순히 파워 속성을 세팅(M-Set)함으로 이루어질 수도 있지만 파워를 끄기 위해 필요한 작업이 순차적으로 이루어져야 할 경우, 명령의 조합을 이용해 필요한 작업을 수행해야 하기 때문에 M-Action 작업이 필요합니다.


M-Action 작업시 manager가 agent에게 보내는 정보에는 Object class/instance, action type, 특정 information에 대한 action 등이 있습니다. 이것은 관리 객체의 특성에 따라 action의 내용이 달라질 것입니다. 왜냐하면 관리 객체마다 action이 취해질 수 있는 범위가 다르기 때문입니다. Action은 앞서와 마찬가지로 스코핑, 필터링, Synchronization과 Linked Replay를 사용할 수도 있습니다. Action은 Confirmed로 지정할 수도 있고, 지정하지 않을 수도 있습니다.


4) M-Delete

오브젝트 클래스의 인스턴스를 삭제하는 명령을 의미합니다. 이것또한 스코핑과 필터링 그리고 Synchronization과 Linked Reply가 가능합니다.


5) M-Cancel-Get

특별한 이유에 의해 자료를 검색해서 결과를 가져오라는 Get 명령을 내린 뒤 그 명령을 취소해야 할 경우가 있습니다. 이때 이 명령을 통해 먼저 보낸 명령에 대한 응답을 보내지 말라고 지시하게 됩니다. 이 서비스는 Confirmed 서비스로써 agent가 이 명령을 받으면 manager에게 응답을 보내야 합니다.


6) M-Event-Report

Notification Service에 대해 알아보면 이것은 특정 이벤트가 발생하면 정해진 규격에 맞춰서 Agent가 Manager에게 그 내용을 보고하는 것을 의미합니다. M-Event-Report가 Notification 서비스를 뜻하는데 이때 보내오는 자료에는 오브젝트 클래스/인스턴스, 이벤트 타입 그리고 이벤트 속의 정보 등이 있습니다. 이것은 관리 객체에서 Notification에 대해 정의된 부분에 따라 그 내용이 달라집니다. 이 서비스는 Action과 마찬가지로 Confirmed일 수도 있고 아닐 수도 있습니다.



Synchronization

하나의 명령으로 복수 개의 인스턴스에 영향을 미쳐야 할 때 사용합니다. 여기에는 모든 것을 특정 값으로 세팅하는 것과 원하는 인스턴스들만 특정 값으로 세팅하는 것 등이 있습니다.



Linked Reply

하나의 명령을 통해 여러 개의 응답이 필요할 때 사용하는 것으로 보내온 명령과 응답을 서로 연결시키는 것을 뜻합니다. 이것은 스코핑과 필터링이 사용되었을 때에만 적용할 수 있는 것으로 앞에서 설명한 Cacnel Get 명령이 오게 되면 Agent는 수행하던 작업(값을 검색한다든지)을 중단하게 됩니다.


 

스코핑

스코핑(Scoping)에 대해 알아보면 스코핑은 하나의 명령이 다수의 객체를 대상으로 해야 할 때 사용하는 것으로 그 대상의 범위를 지정하는 것을 의미합니다. 앞에서 설명했듯이 관리 객체는 트리구조를 이룬다고 했습니다. 따라서 범위를 지정할때는 '저것을 첫번째 노드로 지정한 뒤 그로부터 몇 레벨까지를 대상으로 하겠음'하는 식으로 정하게 됩니다.


이때 사용되는 첫번째 노드 즉 첫번째 객체를 기본 관리 객체 인스턴스(Base Managed Object Instance - BMOI)라고 합니다. BMOI는 앞에서 말했듯이 다수의 객체에서 선택하고자하는 곳의 시작점을 의미하는데 다음과 같은 종류가 있습니다.


  • Only BMOI: 말에서도 알 수 있듯이 대상의 범위는 BMOI로 한정된다.
  • BMOI와 모든 하위의 n레벨: BMOI와 밑으로 n레벨까지 모두가 범위로 지정된다.
  • BMOI와 하위의 모든 레벨: 이것은 레벨의 지정없이 BMOI와 밑에 있는 모든 객체가 해당범위가 된다.



필터링

그러면 스코핑으로 범위를 지정하기만 하고 선별은 하지 않는가 하는 의문을 가질 수 있는데 이때 사용하는 것이 필터링입니다. 예를 들어 모뎀의 속도가 28,800bps ~ 33,600bps에 해당하는 객체만 명령을 수행할 범위로 지정하고 싶으면 스코핑으로 트리의 특정 레벨들을 지정한 후 필터링으로 속도의 범위에 해당하는 객체만을 걸러내면 됩니다.


이때 필터링은 수식(=, >=, <= 등)을 사용하여 려러 값들 중 일치하는 값을 가진 부분이 있는지를 조사하게 됩니다. 수식을 이용할 때에는 논리적 오퍼레이터의 조합을 이용할 수도 있습니다. 즉 And, Or, Not 등을 이용하여 여러 수식을 합쳐서 사용할 수 있습니다.


참고로, 애플리케이션에서 Event Forwarding Discriminator(EFD)라 하여 발생한 이벤트가 어떤 Manager에게 보내져야 하는지를 지정해줘야 하는 것이 있는데 이때에도 CMISE 필터를 이용하여 필터링 합니다.



스코핑과 필터링의 예

아래는 스코핑과 필터링의 한예를 보여주고 있습니다. 그림에서와 같이 BMOI와 하위의 레벨을 정의(점선으로 표시된 부분)한 뒤 아래와 같은 수식을 이용하여 원하는 객체를 지정합니다.


Filter=(isPresent(WorkstationId) && (PacketSent > 999) || (EthernetCard contains "Com"))


필터링은 속성의 존재 자체를 따지거나 속성에 기초한 논리적인 수식을 이용하여 범위를 줄이는 역할을 수행합니다. CMIP 오퍼레이션(M-Get, M-Set, M-Delete, M-Action)에서 이들을 이용하여 인스턴스들에게 명령을 내릴 수 있습니다.


이제 알아볼 것은 제이터베이스에서도 그렇듯이 관리객체에도 그것을 구별해 주는 키가 있습니다. 즉, 다른것과 구별되는 유일한 값을 의미하는 특별한 속성을 갖게 되는데, 이를 나타내는 값인 DN(Distinguished Name)에 대해 알아보도록 하겠습니다.



RDN와 DN

관리 객체가 정의되면 하나의 특별한 속성이 지정되게 되는데 이것은 다른 관리 객체와 구별하기 위한 것으로 이를 이름 속성(Naming Attribute)이라고 합니다. 객체의 이름 속성과 그 속성의 값을 붙인 것을 Relative Distinguished Name(RDN)이라 하여 이 RDN을 모아서 DN이라 하는데 앞에서 말했듯이 모든 것은 트리구조를 이루기 때문에 DN을 보면 자연스럽게 이 객체의 위치까지도 짐작할 수 있게 됩니다. 


그리고 DN(Distinguished Name)을 통해 MIT(Management Information Tree)에서 객체 인스턴스를 찾아낼 수도 있습니다. 다시 간단히 정리하면 DN은 RDN의 연속으로 이루지며 MIT에서는 DN을 이용하여 객체 인스턴스의 경로를 식별하게 됩니다.


Distinguished Name: NetworkId=1/Subnet="Sales"/WorkstationId=1


1) Association Services

시스템 간의 네트워크 통신을 연결하기 위해 ACSE(Association Service Element)를 사용합니다. 이것은 Negotiation을 이용하여 서로의 상태를 체크한 후 연결을 수립합니다. 여기서 사용하는 명령의 종류를 살펴보면 다음과 같습니다.


  • A-Associate: 네트워크를 상호 연결시킨다.
  • A-Release: 네트워크의 연결을 종료시킨다.
  • A-Abort: 네트워크의 연결을 종료시키는 것은 앞서의 Release와 같지만 이 경우는 예기치 못한 상황이 발생하여 연결을 종료시키는 것을 의미한다.


2) Event Reporting Management Function

이벤트에 관련된 모든 것 즉, 이벤트의 시작에서부터 종료 때까지를 제공하는 기능에 대한 내용으로 다음과 같은 것들이 있습니다.


  • 관리 객체로부터 명령결과에 대한 응답을 수신 및 분석
  • 이벤트 리포팅 서비스 개시
  • 이벤트 리포팅 서비스 종료
  • 이벤트 리포팅 서비스 중단 및 재개
  • 이벤트 리포팅 서비스 변경

이때 Event Forwarding Discriminator를 사용하여 이벤트를 수신할 시스템을 지정하게 되며 여기에 사용되는 속성에 Discriminator(CMISE 필터), Destination 리스트, Backup Destination 리스트가 있습니다.



3)기타

이제 앞에서 언급했던 용어들을 간단히 언급하면서 빠진 부분이 있으면 설명하도록 하겠습니다. 앞에서 말했듯이 TMN은 국제 표준을 따르기에 용어를 정리하는 것이 무엇보다 중요합니다.


먼저 '관리 객체'란 실제 자원의 모델들을 '추상화(abstraction)'한 것을 의미하는데 예를 들어 물리적인 자원으로 네트워크 카드 같은 것을 추상화할 수 있으며 논리적자원으로 사용자들도 추상화된 관리 객체에 포함시킬 수 있습니다. 또 하나 생각해야 하는 것을 계속해서 언급되고 있는 '관리'라는 용어인데 이것은 관리 객체의 활동을 모니터링하고 원하는 행동과 값을 설정하기 위해 제어하는 것을 의미합니다.


그리고 '정보 모델'이란 관리 객체를 정의한 것들을 모아놓은 것으로 이것을 다른 말로 MIB(Management Information Base)이라 합니다. 'MIT'란 주어진 시점에 자원들을 표현한 것을 의미합니다. 이 말은 MIT가 동적으로 변화하는 것을 수용하는 동적인 구조임을 의미합니다. MIT는 관리객체의 인스턴스들의 집합을 뜻합니다.


SMK(Shared Management Knowledge) 즉, agent와 manager가 통신하기 위해 필요한 것에는 Information Model 즉, MIB가 있어야 하며 상호 관리정보를 주고받을 수 있도록 프로토콜이 있어야 하고 자원을 표현하고 Access할 수 있도록 MIT와 관리 정보의 교환이 있어야 합니다.


TMN을 이루는 요소들을 물리적인 측면에서 설명하면 네트워크 요소들과 중개 장치등을 뜻하는 TMN 빌딩 블록이 있고, OSI 7계층으로 된 표준 인터페이스가 있으며 그 인터페이스와 연결된 프로토콜들이 있습니다. 아래 그림은 OSI 7계층을 이용하여 Manager와 Agent가 상호 통신하는 것을 보여 주고 있습니다.


 

각 그림속의 용어들을 설명하면 다음과 같습니다.


 용어

 설명

 AE

 Application Entity

 SMASE

 System Management Application Service Element

 CMISE

 Common Management Information Service Element - 집중 또는 분산된 관리환경에서 애플리케이션 프로세스들이 시스템 관리를 위해 제공되는 서비스를 의미한다.

 CMIP

 Common Management Information Protocol

 ROSE

 Remote Operation Service Element - Client/Server 방식에서 remote procedure를 호출할 때 사용하는 방법을 뜻한다.

 ACSE

 Access Control Service Element - 쌍으로 된 Application process들 사이의 connection을 수립(establish)하고 종료(terminate)할 때 사용한다.


TMN을 이루는 요소들을 논리적인 측면에서 설명하면 TMN의 논리적인 계층 구조는 관리를 위해 접근하는 순서로 나눠서 다음과 같은 계층이 있습니다.


 용어

 설명

 Element Management Layer

 Element를 직접 관리하는 계층으로 여기서 Element란 네트워크와 시스템을 구성하는 장치들로 예를 들면 스위치, 전송 시스템, 네트워크 카드 같은 것을 뜻한다.

 Network Management Layer

 Network System들을 관리하여 서비스가 제대로 전달되도록 합니다. 즉, 네트워크가 제대로 작동되는 것과 관련된 모든 것을 관리한다.

 Service Management Layer

 고객에게 제공되는 서비스들을 관리한다. 예를들면 고객에게 제공되는 서비스의 수준과 서비스 품질을 알맞게 하며 그 비용을 산정하고 시장에 출시되는 시점을 제대로 맞추는 것 등이 있다.

 Business Management Layer

 비즈니스의 종합적인 관리를 수행하는 계층으로 투자회수율(ROI)를 달성하고, 시장 점유율을 관리하고 사회와 환경목표에 부합되도록 관리하는 것 등이 있다.



TMN 기능


TMN이 제공하는 관리의 종류에는 다음과 같은 것이 있습니다.


  • Configuration Management: 서비스를 제때에 제공할 수 있도록 사전에 준비하는 역할을 수행하며 환경을 맞처주고 설정하는 것 등을 제어한다.
  • Fault Management: 네트워크에서 발생하는 알람을 검사하며 장애가 발생한 위치를 파악할 뿐만 아니라 그것을 교정하기도 한다. 그리고 항상 문제의 발생 여부를 테스팅하고 사전 발생을 방지하는 예방 유지보수도 수행한다.
  • Accounting Management: 서비스 사용에 대한 비용 등을 계산하며 그 요금을 정하는 역할을 수행한다.
  • Security Management: 접속 권한을 부여하기도 하고 해당 권한이 있는지 검사하는 기능을 가지고 있다. 그리고 접속한 사용자에 대해 조사를 하고 필요하면 추적을 하게 된다. 그리고 이 과정에서 발생하는 알람을 수신하고, 문제 발생시 문제를 해결하는 역할까지 수행한다.
  • Performance Management: 시스템이 제 성능을 내고 있는지 모니터링을 하고, 제어해야 할 부분을 검사하고 조작하게 된다. 그리고 모니터링 자체로 역할을 끝내는 것이 아니라 성능의 향상 여부를 분석하는 과정까지 거치게 된다.



TMN 표준

TMN이 적용되는 분야는 다양하고 광범위합니다. 예를 들면, 아날로그 통신망, 디지털 통신망, 공중 통신망, 사설 통신망, 교환 시스템, 전송 시스템 등에서 적용할 수 있습니다. 이렇게 다양한 분야를 가지는 TMN은 처음 ITU-T(CCITT)내에 TMN 관련 부서에서 규격을 제정하기 시작해서 점차 확대되어 왔습니다.


워낙 많은 내용을 다루어야 하기 때문에 필요한 주제 영역을 하나씩 나누어 표준화 활동을 전개했습니다. 만약 이렇게 나누지 않게 되면 많은 내용을 다루면서 중복을 피할 수 없기 때문입니다.


  • TMN의 구조에 대해서 ITU-T 권고안 M.3100 "Principles for a TMN"에서 기능, 정보, 물리 이상의 3가지 구조로 나누어 기술하고 있다.
  • 인터페이스에 관해서는 ITU-T 권고안 M.3020 "TMN Interface Specification Methodolgy"에 기술되어 있다.
  • 관리 서비스에 대해서는 ITU-T 권고안 M.3200 "TMN Management Services: Overview"에 기술되어 있다.
  • 관리 기능에 대해서는 ITU-T 권고안 M.3400 "TMN Management Functions"에 기술되어 있다.
  • 관리 정보 모형에 대해서 ITU-T 권고안 M.3100 "Generic Network Information Model"과 M.3180 "Catalogue of TMN Management Information"에 기술되어 있다.
  • 관리 정보 등록에 대해서는 ITU-T 권고안 X.722 "Guide-lines for the Definition of Managed Objects"에 기술되어 있다.
  • 통신 프로토콜에 관해서는 TMN에서 사용하는 프로토콜인 CMIP와 FTAM은 ITU-T 권고안 X.710 "Common Management Information Protocol"과 ISO 8571 계열의 "File Transfer, Access & Management"에 기술되어 있다.
  • 용어법에 대해서는 TMN 관련 용어 ITU-T 권고안 M.60 "TMN Terminology and Definition"에 기술되어 있다.


ITU-T M.3100

이 권고안은 관리 객체 클래스의 기술과 M.3100 권고안의 TMN 구조에서 정의된 인터페이스를 모두 포함하는 정보 모형을 제공하여 인터페이스를 통한 효율적인 관리 정보의 교환을 보여주고 있습니다. 여기서 제공되는 정보 모형은 실제 시스템, 서비스, 구조 등을 구축할 때에 적용할 수가 있습니다. 그리고 이 표준안은 관리 객체에 대한 여러 내요을 담고 있는데 조금 살펴보면 다음과 같습니다.


통신망 관점에서의 관리 객체

통신망 관점에서 바라본 관리 객체는 서로 연결되어 있는 전화망을 통해 정보를 교환할 수 있는 모든 관리 객체를 의미합니다. 예를 들면, 고객, 통신망 사업자, 특정 서비스 등을 포함합니다. 여기서 큰 통신망은 작은 통신망을 포함하기 때문에 포함관계를 형성합니다.


관리를 받는 구성요소 관점의 관리 객체

여기에선 관리 객체를 다음과 같이 나눌 수 있습니다.


  • 장비: 구성요소 중 물리적인 요소를 나타내는 관리 객체들을 의미하는 것으로 하나의 장비는 또 다른 장비에 포함될 수 있기 때문에 포함 관계를 형성한다.
  • 관리대상 요소: 전화망을 구성하는 장비 또는 관리 대상에게 제공되는 서비스로 구성된 관리 객체를 의미하는 것으로 여기에는 중계장치, 운영시스템도 포함이 된다. Manager는 표준 Q 인터페이스를 통해 관리 대상 요소와 통신하게 된다.
  • 소프트웨어: 소프트웨어는 프로그램과 장비들 속에 포함되어 있는 논리적인 정보까지 포함하는 관리 객체를 의미하는데 이 관리 객체도 포함 관계를 형성한다.


이 밖에도 아래와 같이 다양한 관점에서 관리 객체를 정의하고 있다.


  • 전송 관점의 관리 객체: Connection, Connectivity, Trail
  • Cross Connection 관점의 관리 객체: Cross Connection, Fabric, Group Termination Point(GTP), Multipoint Cross Connection, TP Pool
  • 기능 영역의 곤점의 관리 객체: Alarm Severity Assignment Profile(ASAP)



이상에서 우리는 TMN을 사용해야 하는 이유와 TMN의 역할 그리고 TMN을 이루고 있는 구성 요소들에 대해서 살펴보았고 표준안에 대해서도 알아보았다. 이번에는 정보 모델 즉, MIB(Management Information Base)를 구현하는 방법을 살펴보도록 하겠습니다. 이것은 관리 객체의 집합으로 실제 자원을 모델링해서 추상화한 것이라고 하였습니다. 그리고 추상화 도구에는 GDMO와 ASN.1이 있다고 했습니다.


이제 각각에 대해 보다 자세히 그리고 보다 구체적으로 살펴보도록 하겠습니다. 그리고 끝 부분에는 실제 자원을 추상화하는 과정을 Switch 시스템을 예로 들어 구현해 보도록 하겠습니다.



Object Modeling


GDMO

GDMO는 Guidelines for the definition of Managed Objects의 약자로써 이는 관리 객체를 정의하는 방법들을 모아 놓은 것입니다. 자원들은 이 방법으로 저으이가 되며 그 결과는 Management Information Base(MIB)가 됩니다. 관리 객체를 정의할 때에는 일관성을 가지고 정의하는 것이 좋습니다. 그리고 몇몇 MIB들은 이미 정의가 되어 있어 표준 관리 객체를 정의할 때에 이중의 수고를 하지 않아도 됩니다.


예를 들면 CDPD, SMI 등은 이미 정의가 되어 있는데 물론 관리하고자 하는 모든 대상을 MIB으로 구성해야 하기 때문에 기존의 MIB속에 없는 새로운 대상을 삽입하거나 변경이 필요할 시에는 GDMO를 이용하여 MIB를 새롭게 정의하거나 추가해야 합니다.



Object Class

GDMO는 객체 지향 도구로써 클래스를 사용하여 모델링을 하게되는 클래스의 형태를 간략히 살펴보면 Attributes, behavior, actions, notifications 등의 요소를 가지며 각 요소들은 연결된 템플릿을 가집니다. 관리 객체 클래스(MOC - Managed Object Class)는 클래스와 연결된 요소와 표현된 자원을 모두 묶습니다.


관리 객체 클래스는 'DERIVED FROM'을 통해 상속 관계를 보여줍니다. 즉, DERIVED FROM 뒤에 오는 클래스가 상위 클래스가 되며 그 클래스로부터 상속을 받게 됨을 의미하는데 이때 상속이란 상위 고나리 객체 클래스의 모든 속성을 물려받는 것을 뜻합니다.


관리 객체 인스턴스란 정적인 GDMO 템플릿 정의를 이용하여 만든 동적인 표현물을 의미하는 것인데 name binding 템플릿에 creation 항목이 존재해야만 인스턴스를 생성할 수 있게 됩니다. 그리고 name binding은 관리 객체 클래스에서 이름 속성(naming attribute)을 지정할때 사용하는 것으로 상위 관리 객체 클래스를 지정하는 기능도 가집니다.


이름 속성은 각 관리 객체 클래스의 연결 관계를 표현하는 것으로 관리 객체의 인스턴스에게 유일한 값을 부여하여 각각을 식별하게 합니다. 기억을 되살려보면 앞에서 MIT를 설명한 것이 기억날텐데, 이 MIT는 바로 관리 객체 인스턴스(MOI - Managed Object Instance)를 표현한 트리입니다. 이때 MIT에서 인스턴스의 위치는 name binding에 의해 결정이 됩니다.



Modeling 예 [SWITCH System]

지금 나오는 내용은 GDMO와 ASN.1을 이용하여 SWITCH 시스템을 모델링하는 과정을 보여주고 있습니다.


먼저 SWITCH가 가지는 attribute로는 switch를 식별할 수 있는 switchID와 포트의 개수를 나타내는 noPorts와 switch의 이름값을 변경시킬 수 있는(set 명령을 받아들일 수 있는) switchName 속성을 가지게 합니다. SwitchId는 생성 때 외에는 값을 변경할 수 없도록 get 속성만 부여하도록 합니다. 그리고 Switch에서 행할 수 있는 Action으로는 파워를 On/Off 할 수 있는 powerOnOff 속성을 가지도록 합니다. 그리고 포트 중에 접속이 실패한 포트가 있으면 통지(Notification)을 보내도록 합니다.


이제 각각의 GDMO와 ASN.1의 내용을 살펴보도록 하겠습니다.


GDMO

먼저 관리 객체 클래스(Managed Object Class)를 정의하도록 합니다. 앞에서 설명했듯이 관리 객체 클래스는 모든 것을 종합한 정보를 가집니다. 즉, Package, Attribute, Action, Notification 등을 가집니다. 관리 객체 클래스의 이름은 switch로 합니다. 그리고 이것은 이미 모델링을 통해 정의된 SMI 시스템의 모든 것을 상속 받는데, 이것은 아래의 Name Binding 부분을 보면 알 수 있습니다. 관리 객체 클래스 속의 Package 이름은 switchPkg입니다.

Switch MANAGED OBJECT CLASS     -- 이름을 Switch로 지정
DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2: 1992 :top;"  -- 상속 관계 지정
CHARACTERIZED BY
    SwitchPkg PACKAGE       -- package 이름 지정

    BEHAVIOR
        SwitchBehavior BEHAVIOR     -- switch에 대한 기술
        DEFINED AS Instantiable class represnting the switch device;;

    ATTRIBUTES                   -- switch가 가지는 attribute
        Switched GET,            -- 식별자로서 Get만 허용
        NoPorts GET-REPLACES     -- 포트의 수로 GET/SET 허용
        SwitchName GET-REPACE,   -- 스위치 이름 GET/SET 혀용

    ACTIONS
        PowerOnOff;              -- 파워를 끄거나 켤 수 있음

    NOTIFICATIONS
        SwitchingAlarm;;;        -- Manager에게 통지해야할 내용

REGISTERED AS {switchMObject 1};


이제 각각의 Attributes들에 대한 내용을 기술합니다. 여기에서 Syntax로 기술된 부분은 ASN.1과 매핑을 이루게 됩니다. 따라서 GDMO에 지정된 내용이 ASN.1 파일 안에 있어야 하고 ASN.1에는 각각의 Syntax가 정의되어야 합니다.

Switched ATTRIBUTE          -- switch의 ID를 나타내는 Attribute
    WITH ATTRIBTUE SYNTAX Switch-ASN1Module.SwitchIdl
    MATCHES FOR EQUALITY, ORDERING;
REGISTERED AS {switchAttribute 1};

NoPorts ATTRIBUTE           -- switch의 포트 개수를 나타내는 Attributes
    WITH ATTRIBUTES SYNTAX Switch-ASN1Module.NoPorts;
    MATCHES FOR EQUALITY, ORDERING;
REGISTERED AS {switchAttribute 2};

SwitchName ATTRIBUTE        -- switch의 이름을 나타내는 Attribute
    WITH ATTRIBUTE SYNTAX Switch-ASN1Module.SwitchName;
    MATCHES FOR EQUALITY;
REGISTERED AS {switchAttribute 3};

ProtNo ATTRIBUTE            -- 접속 실패의 포트숫자를 나타내는 Attribute
    WITH ATTRIBUTE SYNTAX Switch-ASN!Module.ProtNo;
    MATCHES FOR EQUALITY;
REGISTERED AS {switchAttribute 4};


이제 Action을 기술합니다. 여기서 주어지는 행동은 파워를 On/Off하는 것으로 모드는 Confirmed입니다. 즉, Manager가 Agent에게 Action을 요구하면 Agent는 그 행동을 하고 결과를 Manager에게 보내야 하는 것입니다. 따라서 Manager가 Agent에게 보내는 양식을 정해야 하고 반대로 Agent가 Manager에게 보내는 양식도 정해야 합니다.

PowerOnOff ACTION
    BEHAVIOR
    PowerOnOffBehavior BEHAVIOUR    -- 장비를 끄고 켬을 소개
        DEFINED AS "Turn the switching equipment on or off";;
    MODE CONFIRMED;                 -- ASN.1 파일 속에 아래의 2개를 지정
    WITH INFORMATION SYNTAX Switch-ASN1Module.PowerRequest;
    WITH REPLAY SYNTAX Switch-ASN.1Module.PowerReponse;
REGISTERED AS {switchAction 1};


이제 Notification을 기술합니다 Notification에서 지정된 내용을 Agent는 계속 체크하다가 event가 발생하면 그 내용을 Event-Report에 담아서 Manager에게 보내게 됩니다. 여깃는 포트 접속에 실패가 발생하는지를 체크하다가 발생하면 실패한 포트가 몇번째 것인지를 Manager에게 알려주게 됩니다. 

SwitchAlarm NOTIFICATION
    BEHAVIOUR
    AlarmBehaviour BEHAVIOUR
        DEFINED AS "Alarm emitted when a port on the switch fails";;
    WITH INFORMATION SYNTAX Switch-ASN1Module.SwitchingAlarm
        AND ATTRIBUTE IDS
        Switched switched,
        PortNo       portNo;
REGISTERED AS {switchNotification 1};


이제는 Name Binding을 기술하도록 합니다. Name Binding에는 상위 관리 객체 클래스가 무엇인지를 기술하게 됩니다. MIT(Managements Information Tree)를 구성할 때 상위의 관리 객체 밑에 switch 시스템이 생성됩니다. 앞에서 말했듯이 상위 객체의 속성을 모두 상속 받게 됩니다. 지금 작성하고 있는 스위치 시스템은 SMI 시스템을 상위객체로 하고 있습니다.


그리고 이전에 DN과 RDN을 설명했는데 RDN이 모여 DN을 이룬다고 했습니다. DN을 보면 시스템의 상위 객체로부터 차례로 이어지는 모습을 쉽게 알 수 있다고 했는데, 여기서는 스위치 시스템의 switchId가 스위치를 나타내고 있습니다. 예를 들어 시스템 1번 밑에 스위치 시스템 1번이 있으면 DN은 다음과 같습니다.

System = 1/switched = 1

Switch-system NAME BINDING
    SUBORDINATE OBJECT CLASS switch AND SUBCLASSES;
    NAMED BY
    SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2:1992:system"
    AND SUBCLASSES;
    WITH ATTRIBUTE switched;
    CREATE;
    DELETE DLETE-CONTAINED-OBJECT;
REGISTERED AS {switchNameBinding 1};


이상에서 switch system을 정의한 GDMO를 보았습니다. 이제는 앞에서 정의된 속성들에게 syntax를 부여하면 됩니다. MIB를 구성하기 위한 GDMO와 ASN.1의 짧은 예제를 살펴보았는데, 실제 모델링은 이렇게 간단치가 않습니다. 하나의 시스템을 제대로 모델링하기 위해서는 엄청난 시간과 비용이 소요됩니다. 하지만 위의 내용을 자세히 살펴서 소화하게 되면 이후에 MIB을 접할 기회가 있을 때 보다 쉽게 이해할 수 있을 것입니다.




웹기반의 관리 시스템


오늘날 정보화가 급속히 진행되면서 컴퓨터 네트워크는 하루가 다르게 발전하고 있습니다. 특히 TCP/IP를 기반으로 하는 인터넷은 웹 개념이 도입됨으로써 사회의 전 분야에서 사용되고 있습니다. 요즘 WWW에서의 앞선 정보처리 기법을 적용한 각종 응용 기술이 네트워크 관리에도 적용되고 있습니다.


이는 관리 시스템 구축에 따른 비용절감 효과가 크다는 장점, 편리한 접근 및 환경 변화에 따른 비용절감의 효과가 크다는 장점, 환경변화에 따른 응용프로그램의 변경이나 추가가 용이하다는 유연성 등의 장점으로 인해 기조느이 플랫폼 기반 네트워크 관리 애플리케이션의 대체기술로 주목받고 있습니다. 현재의 웹기반 관리기술은 TMN f와 x 참조점에 해당하는 구현기술이 주류를 이루고 있습니다. 현재 TMN F 인터페이스에 대한 연구는 M.3300을 중심으로 진행되고 있으며 여기에서 F 인터페이스 구현을 위한 요구사항을 제시하고 있습니다.


현재의 웹개반 기술은 관리 애플리케이션의 역할에 따라 각자의 선택 기준을 정하고 이를 만족시키는 시스템을 개발하는 방향으로 연구가 진행될 것으로 생가됩니다. 그리고 구현 도구에는 자바가 많이 사용되고 있는데 TMN에서도 요즘 GUI를 쉽게 만들고 또한 사용자가 인터넷 브라우저로 쉽게 사용할 수 있도록 하기 위해 자바를 사용하기도 합니다. TMN 구현 도구로 C 또는 C++를 만힝 사용하고 있는데 이를 자바로 모두 대체하는 시험도 행해지고 있습니다.


결론적으로 말하면 관리시스템은 TMN을 기반으로 구축하고 최종사용자를 위한 인터페이스는 웹을 많이 이용하지 않을까 생각합니다. 물론 앞에서 언급했듯이 특정 관리만을 목적으로 할때는 웹 개반을 채용하면서 말입니다. 번써 일부 업체에서는 웹을 기반으로 하는 제품들을 발표하고 있습니다.


이제 "NMS와 TMS"장을 마무리하도록 하겠습니다. 먼저 이장의 핵심 내용인 TMN에 대해 간단히 요약해보면, TMN 시스템은 관리 시스템인 Manager와 관리를 대행해 주는 Agent 시스템으로 크게 양분해서 생각할 수 있습니다. Manager에서는 Agnet에게 관리명령(권고안에서 기술한 Create, Delete, Get, Cancel) Get, Set, Action 등을 내리고 Agent에서 보내오는 응답이나 알람을 받으며 받은 내용을 분서하게 됩니다.


Agent는 관리 객체를 이용하여 관리 객체와 연동되어 있는 실제 자원들을 관리하게 됩니다. 그리고 manager가 보내오는 명령대로 관리객체를 생성하거나 제거하거나 검색하거나 변경하거나 하게 됩니다. Manager가 보내오는 명령뿐만 아니라 자체적으로 명령을 내리기도 하고 시스템을 점검하다가 필요한 정보가 있으면 Manager에게 통지해 주기도 합니다.


Agent가 관리하는 관리 객체는 모델링을 통해 구현을 하게 되며 실제 자원과 연동을 시켜 객체의 값이 변하면 실제 자원의 속성도 변하게 됩니다. 모델링은 GDMO와 ASN.1을 이용합니다. TMN이 관리하는 분야를 크게 5가지로 나눌 수 있는데 장애관리(Fault Management), 구성 관리(Configuration Management), 과금 관리(Accounting Management), 보안 관리(Security Management), 성능 관리(Performance Management)로 나눌 수 있습니다.


이상으로 우리는 NMS가 무엇이고 왜 필요한지를 살펴보았습니다. 그리고 자세히는 아니지만 SNMP와 RMON에 대해서도 살펴보았습니다. 그리고 비교적 자세히 TNM에 대해 알아보았습니다. 이상에서 배운 내용들은 네트워크의 발전을 위해 꼭 필요한 것으로 규모가 큰 네트워크에서는 제대로 구축이 되어야 하는 시스템입니다.





저작자표시

'서버운영 (TA, ADMIN) > 네트워크' 카테고리의 다른 글

[네트워크] HTTP 헤더 구조  (1) 2017.12.31
[네트워크] 클라이언트/서버 통신 원리  (1) 2017.11.06
[네트워크] 유닉스 네트워크  (0) 2017.08.27
[네트워크] 동기 I/O와 비동기 I/O의 비교  (0) 2017.08.26
[네트워크] 블로킹과 논블로킹 메커니즘  (0) 2017.08.26

티스토리툴바