네트워크 관리 시스템
네트워크 관리 시스템(NMS, Network Management System)은 컴퓨터 네트워크 또는 네트워크들을 모니터링하고 관리하는데 사용되는 하드웨어와 소프트웨어의 조합을 총칭한다. 개별 네트워크 구성요소(NE, Network Element)들은 구성요소 관리시스템(Element Management System)에 의해 관리된다.
목차
개요[편집]
개별 네트워크 구성요소들은 구성요소 관리시스템에 의해 관리된다. 네트워크 관리 시스템은 네트워크의 감시, 유지 및 최적화를 위해 설계된 시스템이다. 하드웨어와 소프트웨어를 모두 포함하지만, 네트워크 관리 시스템은 대부분 네트워크를 관리하는 데 사용되는 소프트웨어를 가리킨다. 인터넷과 인트라넷의 활성으로 많은 업무가 네트워크를 통하여 이루어지게 된다. 의사 전달을 위한 이메일이나 그룹웨어, 클라이언트-서버 업무 처리 등 네트워크의 중요성은 날로 높아지고 있다. 네트워크 환경이 대형화되고 복잡해짐에 따라 네트워크의 관리 또한 중요한 비중을 차지하게 되었다. 네트워크의 다운이나 속도 저하로 인해 업무처리가 늦어진다면 이는 단순한 문제가 아니다. 네트워크 관리 시스템을 사용하여 네트워크상의 장비를 모니터링하고 장애에 대한 신속한 대처를 할 수 있도록 구성해야 한다. 네트워크 관리 시스템을 통해 네트워크 구성상의 문제를 발견할 수 있으며 이러한 자료들이 네트워크 구성을 효율적으로 구성하게 하고 향후 네트워크 설계의 자료가 될 수 있다. 이처럼 네트워크 관리 시스템은 네트워크 구성요소를 관리하는 역할을 수행하기 때문에 매니지드 디바이스(managed device)라고도 불린다. 디바이스 관리는 고장, 구성, 회계, 성능 및 보안 관리를 포함한다. 그리고 관리 작업에는 네트워크 인벤토리의 발견, 디바이스 상태 모니터링, 시스템 성능에 영향을 미치는 상태에 대한 경고, 문제의 식별 및 출처의 파악과 함께 가능한 솔루션의 제공 등이 있다.[1]
역사[편집]
네트워크 관리 기능은 1970년대말 국제표준기구 ISO(International Standard Organization)에 의해 형성된 개념인 OSI(Open System Interconnection)에서 구성, 장애, 성능, 보안, 계정 관리의 다섯 가지 기능 영역으로 나누어 정의했다.
1980년대에는 급속한 발전이 있었다. 더 크고 더 복잡한 네트워크를 향해 네트워크 관리의 상당한 확산을 야기했다. 기술 특정 네트워크 관리 툴을 제공하는 시점은 1987년 11월 SGMP(Simple Gateway Monitoring Protocol)가 발행된 시점이었다. 1988년 초에 IAB(Internet Architecture Board)는 SNMP(Simple Network Management Protocol)를 승인했다. 네트워크 관리를 위한 단기 솔루션 SNMP 및 CMIP(Common Management Information Protocol)과 같은 표준은 표준화된 네트워크 관리 및 개발을 위한 기반을 마련했다.[2]
1990년대 중반 모든 사무환경에 정보 인프라 구축을 위한 네트워크가 자리잡기 시작한 이래 점차적으로 대규모의 네트워크가 형성되었고, 이에 따른 라우터, 스위치 등과 같은 다양한 네트워크 장비들의 증가는 네트워크 관리에 더 많은 노력과 시간을 요구하게 되었다. 결과적으로 네트워크 관리자는 효과적인 중앙 집중관리를 위하여 효율적인 관리 도구들이 필요하게 되었고, 이러한 상황들이 네트워크 장비의 물리적인 장애를 해결하고 상태 점검과 제어를 수행하는 시스템인 네트워크 관리 시스템의 발전을 이끌어내게 되었다.
1990년대 말에는 본격적으로 네트워크 관리 시스템 시장이 활성화되면서 대부분의 네트워크에는 관리를 위한 네트워크 관리 시스템 도입이 추진되었다. 이후로 네트워크에 광대역 분산 컴퓨팅 환경을 수용함에 따라 다양한 이기종의 하드웨어, 플랫폼, 프로토콜들이 등장하게 되었고, 이러한 동향은 네트워크 관리 시스템에 대한 요구사항이 수많은 전사적 자원들을 처리하기 위한 관리 시스템으로 확대되는 추세에 있다. 네트워크 관리 시스템은 PC 또는 워크스테이션과 같은 하드웨어상에 네트워크 관리 시스템 제품 소프트웨어를 설치하여, 네트워크 관리자가 네트워크 장비를 제어 및 감시할 수 있게 하는 것으로 구현된다.[3]
특징[편집]
필요성[편집]
네트워크가 점점 커가면서 여러 문제들을 야기하게 된다. 네트워크가 커진다는 것은 하드웨어와 응용프로그램들 그리고 사용자들이 늘어나고 복잡해지는 것을 의미한다. 이때 발생하는 문제를 간단히 생각해보면 이기종의 하드웨어와 응용프로그램들이 하나의 구조 속에 포함됨으로 새로이 발생하는 문제가 있을 것이며 확장된 네트워크가 제대로 성능을 발휘하는가와 확장된 네트워크에 에러는 없는가를 확인해야 되는 문제가 생긴다. 커다란 네트워크망은 사람의 힘으로 관리할 수 없게 되는데 여기서 네트워크 관리툴 킷을 필요로 하게 된다. 이때 네트워크 관리 시스템은 물리적인 네트워크 시스템을 관리하는 소프트웨어 관리툴을 의미하는 것으로 네트워크망에 여러 벤더들의 다양한 장비가 포함되면 될수록 관리에 어려움을 느낄 수 있다. 그리고 네트워크를 조금 확장할 때마다 관리비용은 몇 곱으로 늘어나게 된다.
과거에는 네트워크의 구조가 단순하고 노드도 많지 않았으므로 네트워크 관리 시스템이라는 소프트웨어에 큰 비중이 없었지만 최근의 네트워크는 규모도 클 뿐만 아니라 네트워크를 구성하는 하드웨어도 각양 각색이어서 네트워크 관리자의 물리적 네트워크 추상화에는 한계가 생기게 되었다. 네트워크 관리 시스템의 중요성이 부각되면서 SNMP(Simple Network Managerment Protocol)이라는 표준이 제정되고 기존의 SNMP에 보안의 기능을 강화한 SNMP II와 보안 SNMP(secure SNMP)가 표준으로 자리잡고 있다. 네트워크 관리 시스템은 단지 관리의 기능뿐만 아니라 차후 네트워크의 확장을 위한 분석 툴로써의 가치도 지니고 있다. 네트워크 관리 시스템은 네트워크 관리 시스템이 포팅되는 플랫폼과 플랫폼에서 구동되는 애플리케이션이라는 범주로 구분할 수 있다. 이때 플랫폼이라는 것은 네트워크 관리 시스템이 포팅되는 운영체제를 말하는 것이고 애플리케이션은 그 운영체계에서 작동하는 각종 네트워크 벤더들의 네트워크 관리 솔루션을 의미한다.[4]
기능[편집]
네트워크 관리 기능은 1970년대말 국제표준기구 ISO에 의해 형성된 개념인 OSI에서 구성, 장애, 성능, 보안, 계정 관리의 다섯 가지 기능 영역으로 나누어 정의하였다. 이러한 다섯 가지 관리 기능은 구성 관리를 통해 네트워크 구성정보를 공유하여 장애, 성능, 보안, 계정 등의 타 관리 기능과 유기적인 상호 작용올 통해 총체적인 네트워크 관리를 한다.
- 구성 관리(Configuration Management) : 상호 연결 서비스의 계속적인 운영을 위한 기능으로 관리 네트워크로부터 네트워크 구상정보를 수집하여, 그 정보를 바탕으로 네트워크 장치의 구성 정보를 추가, 저장, 갱신하고 그 구성 형태에 대한 보고를 수행하는 기능을 담당한다. 구성 정보 수집 방식은 관리자가 직접 네트워크 구성 정보를 입력하는 수동적인 데이터 수집의 두 가지 방식이 있다. 이러한 구성관리를 통해 네트워크 장비에 대한 추적 및 제어 기능과 타 관리 기능과의 유기적인 상호 작용을 통한 관리 기능이 확장될 수 있다.
- 장애 관리(Fault Management) : 네트워크 상에 발생하는 문제를 찾아내서 수정하는 과정으로 네트워크의 현재 상태를 나타내는데 필요한 정보를 제공하는 도구이다. 장애관리 과정은 장애의 식별, 장애원인 격리 그리고 장애 수정의 세 단계로 이루어진다. 첫 번째로 장애 식별은 회선 장애, 장치 재작동, 호스트르부터의 불충분한 반응시 네트워크 이벤트 로깅을 적절한 시간간격으로 폴링을 통해 확인한다. 두 번째로 장애원인 격리는 장애 원인을 식별하면 장애의 우선 순위를 결정하고 네트워크 관리의 범위와 네트워크의 크기를 고려하여 원인을 격리한다. 마지막으로 장애 수정은 격리된 장애에 대한 수정을 수행한다.
- 성능 관리(Performance Management) : 네트워크 장비 및 관련 링크를 지속적으로 모니터링하여 이용률, 에러율 등의 성능 지표를 계산하고 사용자들에게 일정 수준의 서비스를 지속적으로 제공하기 위한 기능을 제공하는 것으로 네트워크의 혼잡과 접근 불가 횟수를 줄이는 이점을 갖는다. 또한 그 이용률을 지속적으로 모니터링하여 링크의 확장들에 관련된 용량 계획을 지원하며 시간대별 네트워크 피크(peak)를 파악함으로써 대큐모 데이터의 전송 등을 파악하여 보다 효율적인 네트워크 관리를 지원할 수 있다. 성능 관리는 실시간과 누적 분석 기능의 두 가지 영역으로 나누어 네트워크 성능을 모니터링한다. 실시간 성능 모니터링은 이용률, 에러율 등을 통해 현재 성능 관리 지표의 변화 추이를 분석하는 것이며 누적 분석 기능은 주기적으로 네트워크 성능 지표를 수집하고 일주일, 한달, 일년의 일정 기간에 대한 성능 통계를 분석하여 그 정보를 장기적인 네트워크 관리에 사용하는 것이다. 일반적인 성능 관리 지표가 임계치를 초과하는지를 평가하고, 어느 시간에 트래픽이 최대 또는 최소가 되는지를 평가하는 방식으로 이루어진다.
- 보안 관리(Security Management) : 호스트 네트워크 장비에 대한 사용자 접근을 제한하고 관리자에게 보안 침해 사건을 보고하는 과정으로서, 운영체제 보안과 물리적 보안으로 구분할 수 있으며 불법적인 접근, 변경, 삭제로부터 정보를 보호한다. 또한 다중 계층에서 접근 제어를 수행하고 암호화를 통해 데이터를 보호하거나 패킷 필터링을 통해서 불법적인 패킷의 접근을 통제한다. 접근 제어의 방식으로 호스트 인정, 사용자 인증, 키 인증과 같은 기법을 사용한다.
- 계정 관리(Accounting Management) : 네트워크 자원 이용률에 대한 이해를 바탕으로 투자 네트워크에 대한 자금 회수 및 사용자에게 공정한 요금을 청구하기 위한 관리 기능이다. 일반적으로 비정기적으로 데이터를 수잡하는데 과금 정액으로는 월간 정액제 방식과 이용량에 따른 차등 요금 부하 방식이 있는데 이용량은 일반적으로 트랜잭션의 수, 패킷량, 바이트량으로 평가된다.[3]
기술 표준[편집]
네트워크 관리에 대한 관련 기술 표준은 ISO, ITU-T, IETF 등의 국제기구에 의해 규격화된다. 그러나 장애, 구성, 성능, 계정, 보안관리 등 네트워크 관리 시스템이 구현하는 다섯 가지 관리 기능은 일반적인 네트워크 분야에서 언급되는 원칙과는 달리 권고사항이기 때문에 다섯 가지 관리 기능을 모두 가지고 있어야 네트워크 관리 시스템의 자격을 갖춘다는 것은 아니다.[3]
표준 관리 프로토콜[편집]
표준 관리 프로토콜은 크게 SNMP와 CMIP/CMIS 등 2가지로 나뉜다. SNMP는 네트워크 장비를 주기적으로 관리하지만 관리 기법이 단순한 반면에 CMIP는 주기적으로 관리된 내용을 항상 보고하는 보다 복잡한 형식을 취하고 있다.[3]
SNMP[편집]
SNMP는 FTP나 텔넷과 마찬가지로 TCP/IP의 응용 계층 프로토콜로 설계되었고 전송계층 프로토콜로는 UDP(User Datagram Protocol)를 사용한다. 관리국 상의 관리 애플리케이션은 SNMP 에이전트의 MIB에 대한 접근을 조절하고, 네트워크 관리자에 대한 인터페이스를 제공한다. 각각의 에이전트는 반드시 SNMP, UDP, IP를 구현해야만 한다. 게다가 에이전트 프로세스는 SNMP 메시지를 해석하고, 에이전트의 MIB를 조정한다. 에이전트 장치는 필요하면 UDP뿐만 아니라 TCP 등과 같은 애플리케이션도 지원할 수 있어야 한다. SNMP의 프로토콜 동작 내역은 관리국상의 관리 애플리케이션이 세 가지 형태의 SNMP 메시지, 즉 GetRequest, GetNextRequest, SetRequest를 생성하여 에이전트로 전송한다. 그러면 에이전트는 GetResponse 메시지로 관리국에 응답을 하게 된다. 그리고 에이전트는 MIB에 영향을 미치거나 관리 자원에 발생할 수도 있는 사건을 알리기 위해 Trap 메시지를 만들기도 한다.[3]
<SNMP 메시지> 1. GetRequest : SNMP 관리국이 값을 얻고자 하는 변수들을 SNMP 에이전트에게 알림 2. GetNextRequest : SNMP 관리국이 연속해서 값을 얻고자 하는 변수들을 SNMP 에이전트에게 알림 3. SetRequest : SNMP 관리국이 변수들에 대해 지정하고자 하는 값을 SNMP 에이전트에게 알림 4. GetResponse : GetRequest, GetNextRequest, SetRequest 등에 대한 응답을 보냄 5. Trap : 하위 모듈, 즉 UDP가 장애 등의 특정한 사건들을 SNMP 모듈에게 알림[3]
- 구성
TCP/IP 네트워크를 관리하기 위한 4가지 모델은 관리 시스템, 관리대상 에이전트, MIB, 네트워크관리 프로토콜로 구성된다. 관리 시스템은 네트워크 관리자에게 전 네트워크 상황을 볼 수 있는 인테페이스를 제공하며 관리 데이터의 분석, 장애관리 등의 기능수행을 위한 데이터베이스를 구축하고 있다. SNMP 에이전트는 피관리대상장비, 즉 호스트, 라우터, 브릿지, 허브와 같은 네트워크 장비에 설치되어 관리 시스템의 요구에 따라 관리 정보를 송달하거나 관리 시스템의 액션 요구를 수행하며 문제 발생시 자동적으로 장애 상황을 관리 시스템에 통보한다. 네트워크 관리 프로토콜로서 가장 널리 사용되는 SNMP는 OSI에서 정의된 CMIP와 공존하며 일정기간 계속 사용되리라 예상되고 있다.[5]
- 동작
SNMP는 매니저와 에이젼트 사이에 관리정보를 주고 받기위한 프로토콜이다. 이들 정보의 교환은 메시지 단위로 이루어지며 SNMP 메시지는 GetRequest PDU, GetNextRequest PDU, SetRequest PDU, GetResponse PDU, Trap PDU의 다섯 가지 형태를 갖는다. GetRequest PDU는 매니저가 하나 또는 그 이상의 에이젼트에게 오브젝트 값을 요청하기 위해 사용한다. GetNextRequest PDU는 GetRequest PDU와 같지만 이 경우, 돌려받는 오브젝트 값은 MIB상에 정의된 어휘적인 순서로서의 다음 오브젝트 값이다. SetRequest PDU는 값을 요청하기 위한 것이 아니라 값을 설정(변경)하기 위해 매니저가 에이젼트에게로 보내는 메시지이다. 세 가지 메시지에 대한 응답은 GetResponse PDU로 돌려진다. Trap PDU는 에이젼트가 자신에게 일어나 사건들에 대한 정보를 매니저에게 알리는 메시지이다. SNMP는 비연결 지향형인 UDP(user datagram protocol) 상에서에 동작하지만 앞으로는 전송-레벨의 여러 다양한 프로토콜 상에서 동작하도록 향상될 것이다.[5]
CMIP/CMIS[편집]
CMIP/CMIS는 잘 정리되고 훌륭한 개념임에도 불구하고 지나치게 방대하게 규정되어 있어서 구현하기가 쉽지 않고 시스템도 SNMP에 비해서 무척 커서 SNMP를 쉽게 대체하지 못하고 있다. 그러나 TMN(TeleCommunication Management Network)이라는 개념이 도입되면서 CMIP/CMIS가 주목을 받게 되고 이와 관련하여 CMIP를 이용한 각종 개발 도구들이 발표되고 있다. CMIP/CMIS 프로토콜에서의 관리 객체들에 대한 저보를 주고 받는 일곱가지 서비스가 있다. 특히 관리 에이전트에서 관리국으로 관리 객체에 발생한 특정 상황을 통지하는 M-EVENT-REPORT 서비스는 SNMP 프로토콜의 TRAP과 같은 기능을 수행하나, 이 메시지를 받은 CMIP 관리국은 메시지를 받았다는 확인을 해주어야 한다는 차이가 있다.[3]
- CMISE(Common Management Information Service Element)
OSI 시스템 관리자에서 기본적인 기능이 두 시스템(manager, agent) 간의 정보를 교환하는 것이다. 이 시스템 관리를 목적으로 정보와 명령을 교환하기 위해서 이용하는 기능이 CMISE이다. CMISE는 사용자와의 인터페이스 서비스를 담당하는 CMIS와 PDU 및 관련 절차를 규정한 CMIP로 이루어진다. CMISE 서비스는 기본적으로 요청받은 서비스에 대해서 실패, 성공이나 요청을 받았다는 응답을 해주는 확인 서비스들과 응답을 하지 않는 비확인 서비스로 나눌 수 있다. 이들 서비스는 3가지 범주로 나뉜다.
- 어소시에이션 서비스(Association Service) : 통신을 하기 위해서 해당 시스템의 애플리케이션간의 연결 및 해제를 하기 위해서 필요하다. 이는 ACSE(Association Control Service)를 이용한다.
- 관리-보고 서비스(Management-notification Service) : 관리 객체들에 대한 특정 사건을 보고하는데 이용하는 것으로 필요한 속성, 행동 및 작동 절차 등에 대한 것은 각 관리객체들에 정의되어 있다.
- 관리-운영 서비스(Management-operation Service) : 시스템 관리를 위해서 정보를 주고 받는데 이용된다.[5]
- CMIS(Common Management Information Service)
시스템간 연결 및 해제를 위한 서비스인 A-Associate, A-Reases, A-Abort가 있고,대리인에서 관리자에게 관리 객체에 발생한 특정 상황을 통지하는 M 이벤트 리포트 서비스가 있다. M 이벤트 리포트는 SNMP의 트랩과 같은 기능을 수행하나 이 메시지를 받은 관리자가 받았다는 확인을 해주어야 한다는 차이가 있다. 실제로 관리 객체들에 대한 정보를 주고 받는 서비스인 MOS(Management Operation Service)에는 다음과 같은 메시지가 있다.[5]
<CMIP 메시지> 1. M-GET : CMIP 관리국이 CMIP 에이전트에게 관리정보를 요청 2. M-SET : CMIP 관리국이 CMIP 에이전트의 관리정보를 수정하도록 요청 3. M-ACTION : 관리객체에 사전에 정의된 특정한 동작을 실행하게 함 4. M-CREATE : 객체 클래스의 새로운 사례를 만들기 위해서 사용되는 서비스 5. M-DELETE : 에이전트의 하나 이상의 관리 객체를 삭제시에 이용됨 6. M-CANCLE-GET : 이미 요청된 M-GET을 중지시킬 때 이용됨 7. M-EVENT-REPORT : 에이전트가 관리국에게 관리객체에 발생된 특정상황을 통지[3]
- CMIP
CMIP는 관리정보를 전송하는 절차 즉 CMISE사이에 CMIS 서비스를 완성시키기 위해서 교환하는 CMIP PDU를 만들고 전송하는 것에 대해 정의해 놓은 것이다. 양단의 CMISE 사용자(관리자와 대리인 또는 양단의 CMISE 애플리케이션)들이 정보교환을 위해서 시스템을 연결하기 위해 ACSE를 이용하는데, 이때는 CMIP이 이용되지 않는다. 관리 서비스를 위해서 CMISE는 PDU를 교환하기 위해서 CMIP를 채용한다. 그리고 CMIP는 CMIP PDU 전송을 위해서 ROSE(Remote Operations Service Element)를 이용한다. CMIP는 CMIS 서비스를 처리하기 위해서 11개의 PDU를 정의해 놓았다. CMIP는 항상 ROSE 3를 이용한다. 그리고 확인 서비스를 위해서는 집합 2 또는 3을 이용하고 비확인 서비스를 위해서 집합 5를 이용한다.[5]
MIB[편집]
MIB(Management Information Base)란 TCP/IP를 기초로한 관리 모델에서 각 피관리 대상장비의 관리 되어질 요소들에 대한 정보를 포함하고 있는 데이터베이스이다. 이때 관리되어지고 있는 각 정보들을 오브젝트라고 하며 MIB는 이러한 오브젝트들의 계층적 트리구조로 이루어져 있다. MIB를 SMI 규칙에 따라 5가지 기능분야로 분류된다.
- 구성관리 : 네트워크상의 장비와 전반적인 물리구조를 매핑 하는 기능을 말한다.
- 성능관리 : 가용성, 응답시간, 사용량, 에러량, 처리속도 등 성능 분석에 필요한 통계 데이타를 제공하는 기능을 말한다.
- 고장관리 : 문제의 검색, 추출 및 해결을 제공하는 기능을 말한다.
- 보안관리 : 정보의 제어 및 보호 기능을 말한다.
- 계정관리 : 각 노드별로 사용현황을 측정하는 기능을 말한다.
네트워크나 인터네트워크에서 각 시스템(워크스테이션, 서버, 라우터, 브릿지 등)등은 관리 대상의 상태를 보여주는 MIB를 가지고 있다. 네트워크 관리는 MIB에서 오브젝트의 값를 읽음으로 자원을 모니터할 수 있으며, 그 값을 수정함으로 자원을 조정할 수 있게 한다. MIB가 네트워크 관리 시스템에서 역할을 다하기 위해서는 확실한 관리대상이 있어야 한다. 각 시스템에서 특별한 자원을 나타내기 위한 오브젝트들은 같아야 한다. 시스템에서 TCP에 관하여 저장된 정보의 예를 들어보자. 일정 시간동안 열리는 모든 접속은 액티브 오픈(active open)과 패시브 오픈(passive open)으로 되어있다. 시스템에서 MIB는 관련된 3개(액티브 오픈의 수, 패시브 오픈의 수, 전체 오픈의 수) 중에서 2개를 저장하고 있으며, 나머지 한 개는 필요로 할 때 계산해낼 수 있다. 게다가 다른 시스템에서 저장을 위해 다른 쪽을 선택한다면, 요구하는 정보에 접근하기 위해 하나의 프로토콜로는 어려울 것이다. 그러한 상황에서, TCP/IP에 관한 MIB 정의는 저장된 액티브 오픈(active open)과 패시브오픈(passive open) 숫자를 나타난다. 공통 기준을 나타내기 위해서는 반드시 공유 가능한 환경이 되어야 한다. 오브젝트가 같아야 한다는 것은 MIB에서 오브젝트와 오브젝트의 체계화를 정의하는 것을 통해 나타난다.[5]
- 구조
SNMP 환경에서 운영되는 오브젝트는 계층적인 구조나 트리 구조로 정돈되어 있다. 트리의 잎(leaf)에 해당하는 것이 실제로 운영되고 있는 오브젝트이며, 각 오브젝트는 자원, 행동 또는 운영되는 관련된 정보를 나타낸다. 트리 구조 자체는 논리적으로 이해관계를 가지고 있는 체제의 그룹화를 말한다. MIB 안에 있는 각 오브젝트형과 관련된 것 중 ASN.1타입 오브젝트 식별자(object identificial)의 아이디가 있다. 이 아이디가 오브젝트의 이름이 된다. 그 외에도 오브젝트 식별자와 관련된 값은 계층 구조이기 때문에, 이름을 붙이는 규정이 오브젝트형의 구조를 명시한다. 오브젝트 아이디는 고유한 값이며, 그 값은 연속적인 번호로 되어 있다. 정의된 오브젝트의 세트는 뿌리에 해당하는 부분이 ASN.1 표준을 의미하는 트리 구조로 되어 있다. 각 오브젝트의 ID는 트리의 뿌리 부분부터 가지까지 구성한다. 뿌리에서 시작해서, 첫번째 레벨에는 iso, ccitt, joint-iso-ccitt의 3가지 노드가 있다. iso, ccitt, joint-iso-ccitt의 iso 노드에서, 하나의 서브트리는 조직집단(org)을 위해서 사용된다. org의 하위트리 중 한 개는 미국방성(dod)이다. RFC1155는 아래와 같이 dod의 서브트리중 1개가 IAB( Internet Activities Board)에 의한 관리를 위하여 할당된 것으로 처리한다.[5]
인터넷 노드는 1.3.6.1이라는 오브젝트 아이디를 가지고 있다. 이것은 트리구조의 experimental 노드 앞에 붙은 타이틀이다. 아래와 같이, SMI 다큐먼트는 internet 노드에서 4개의 노드를 정의하고 있다
- directory : 추후 OSI 디렉토리 사용을 위하여 예약된다.
- mgmt : IAB가 승인한 문서에 의해 정의된 오브젝트를 위하여 사용된다.
- experimental : 인터넷 실험에서 각 오브젝트를 식별하기 위해 쓰인다.
- private : 일방적으로 정의된 오브젝트를 정의하는 데 쓰인다.
mgmt 서브트리는 IAB로 인증된 MIB 정의를 포함하고 있다. MIB-Ⅰ과 MIB-Ⅱ의 두 가지 버전의 MIB이 개발되어 있다. MIB-Ⅱ는 MIB-Ⅰ에서 확장된 것이다. 어떤 구성도에서는 두 MIB 중 하나만 있기 때문에, 서브트리에서 둘의 오브젝트 아이디는 같다. 그 외의 오브젝트들은 다음 세 가지로 구분된다.
- MIB-Ⅱ 서브트리는 확장되거나 완전히 새로운 리비전으로 교체될 수 있다. MIB-Ⅱ를 확장시키기 위해 새 서브트리가 정의된다. 예를 들면, 원격 네트워크 감시(RMON, Remote Network Monitoring) MIB은 MIB-Ⅱ에서는 16번째 서브트리로 정의된다.
- 시험적인 MIB은 특별한 애플리케이션으로 구성될 수 있다. 그러한 오브젝트들은 후에 mgmt 서브트리로 옮겨질 수도 있다. 이러한 예는 IEEE802.5 토큰링과 같이 다양한 전송매체에 관리정보를 포함한다.
- private 확장은 private 서브트리에서 추가될 수 있다. RFC에서 문서화된 것 중 한 개가 MUX(mulyiplexer) 관리정보이다.
private 서브트리에는 enterprise 노드라고 정의된 차일드(child) 노드가 있다. 서브 트리의 이 부분은 벤더의 장비운영 향상을 위해 사용되며, 시스템 내의 공유환경을 필요로 하는 다른 사용자와 벤더들의 정보공유에 사용된다. enterprise 서브 트리내의 가지(branch)는 각 enterprise 오브젝트 아이디를 등록한 각 벤더에 할당된다. 4개의 서브트리로 나뉘는 internet 노드는 MIB 변화에 기반을 구축한다. 벤더나 다른 사용자들이 이 오브젝트들의 사양이 표준화되기 전에 새로운 오브젝트를 시험 사용하므로 실용적인 노하우를 얻을 수 있다. 그러므로 MIB은 오브젝트 MIB 내에 표준화되어 있는 오브젝트 운영에 즉각 사용될 수 있으며, 기술이나 상품의 변화에 유연성있게 대처할 수 있다. 이러한 변화는 TCP/IP 안에 있는 프로토콜과 같은 이치이다. 위의 모든 프로토콜들은 광범위한 시험과 디버깅을 거쳐서 표준화 프로토콜이 된다.[5]
관리 프로토콜이 장비를 체크하는 항목이 수록된 MIB는 MIB-Ⅰ, MIB-Ⅱ, 그리고 원격지역 네트워크 관리를 위한 RMON(Remote MONitoring)-Ⅰ, RMON-Ⅱ 등과 그 외에 ATM MIB, NT MIB 등의 표준화가 진행되어있다. 공통적으로 MIB의 자료구조 표현은 ASN31(Abstract Syntax Notation One) 방식에 의해 표현된다.[3]
OSI MIB[편집]
OSI MIB의 가장 큰 특징은 객체지향적인 개념을 수용하고 있다는 점이다. OSI MIB는 X.720, X.721, X.722에 잘 정의되어 있다. 특히, X.722에 정의된 GDMO(Guidelines for the Definition of Managed Objects)는 객체들의 클래스, 객체의 행동, 속성,등을 명시하는 방법을 제공하는 구조화된 기술 언어이다. X.720 시리즈인 관리 정보 모델은 관리 객체에 대한 개념이 세밀하게 기술되어 있다. 또한 관리 객체의 이름을 만드는 방법도 정의되어 있다. OSI에서 정의한 객체는 행동 및 속성, 통지, 작동 등을 캡슐화하며 그 객체를 상속해 새로운 객체를 만들 수 있다. 또한 동질성을 이용하여 과거의 객체등을 손쉽게 관리할 수 있다. 알로모피즘은 객체지향의 다향성의 특별한 경우이다. SNMP가 테이블의 개념으로 객체를 관리하는데 반해서 OSI MIB는 ‘포함(Containment)’이라는 개념을 이용한다. 즉 한 객체가 하나 이상의 다른 객체를 포함할 수 있다. 물론 객체를 포함하고 있는 객체도 다른 객체의 하위 객체가 될 수 있다. 그러나 한 객체는 하나의 상위 객체에만 포함돼야 한다. 관리 뼈대로 객체지향적인 GDMO와 그렇지 않은 SMI에서 거의 모든 차이가 발생한다. 대부분의 장비가 SNMP를 이용하고 있으나 모든 장비의 통합관리라는 개념의 TMN하에서는 CMIP가 채택되고 많은 개발 도구들이 등장하고 있다. 광섬유망에서 셀룰러와 위성을 기반으로 한 무선 통신시스템이 등장하면서 관리의 필요성 때문에 TMN이 각광 받으면서 CMIP도 관심의 대상이 되고 있다.[5]
SNMP MIB[편집]
관리 에이전트의 각종 네트워크 관리 정보를 기록하는 저장소로, 국제 표준에 의해서 데이터베이스의 트리구조를 정의한다.[3]
CMIP/CMIS MIB[편집]
ITU-T/OSI 정의 표준에 의해서 데이터베이스의 트리구조를 정의한 것으로 객체지향적인 개념을 수용하고 있다.[3]
RMON[편집]
네트워크의 효율적 이용을 위해서 현재의 네트워크 상태를 측정하고 과거의 기록을 토대로 향후 네트워크 문제를 사전에 예견, 유용하게 이용되는 것이 RMON(Remote network Monitoring)이다. 기존의 SNMP MIB들이 보유하고 있는 대리인(Agent)이 탑재된 장비 자신의 처리 결과만을 보유하고 있는 데 반해서 RMON 대리인은 한 세그먼트 전체에서 발생하는 트래픽을 파악하게 해준다. 즉, 전체 발생 트래픽, 세그먼트에 연결된 각 호스트의 트래픽, 호스트들간의 트래픽 발생 현황을 알려준다. 이런 처리를 위해서 RMON 대리인은 전체 통계 데이터, 이력(history) 데이터, 호스트 관련 데이터, 호스트 매트릭스와 사전에 문제 예측 및 제거를 위해서 특정 패킷을 필터링하는 기능과 임계치를 설정, 이에 도달하면 자동으로 알려주는 경보 기능, 및 사건 발생 기능을 보유하고 있어야 한다. 네트워크에서 발생한 트래픽 모두를 관찰하고자 나온 것이 네트워크 모니터링이다. 또는 분석기(Analayzer), 프로브(probe)라고 부른다. 네트워크 데이터를 수집하는 대리인은 보통 단독 장비로 또는 웍스테이션, PC, 허브, 스위치 등의 장비에 탑재하는 경우가 있다. 단독 장비는 모든 트래픽을 분석할 수 있으나 별도로 구입함으로써 비용이 고가이고 기존장비에 탑재된 경우는 비용절감 효과는 있으나 장비 고유의 업무처리 때문에 트래픽을 정확하게 분석할 수 없다는 단점이 있다.[5]
- 기능
RMON이 정의되어 있는 RFC1757은 주로 RMON MIB에 집중되어 있다. 이 문서는 기본적으로 SNMP를 기반으로 한 RMON 대리인과 RMON 관리자간의 각종 절차를 담고 있다. 즉 대리인과 관리자의 요청에 의해서 어떻게 데이터를 채집하고 그리고 그 데이터를 보관하고 어떻게 삭제하는가에 관한 것이다. RMON이 갖추어야할 기본적인 목표를 다음과 같이 제시하고 있다.
- 오프라인 동작 : 대리인은 관리자와 RMON 대리인간의 통신에 영향을 받지 않고 해당 세그먼트의 성능, 구성 정보 등을 축적하고 관리할 수 있어야 한다.
- 프로액티브 모니터링(Proactive Monitoring) : 대리인에 주어진 자원에 따라 네트워크를 진단하고 성능 자료의 이력 관리를 통해서 장애 및 장애에 대한 기록을 관리자에게 보고할 수 있어야 한다.
- 문제 타지 및 보고 : 관리자가 특정 상태(오류,특정패킷)에 대한 보고를 명령하면 이를 계속 감시하다가 탐지되면 이 사건을 기록하고 관리자에게 통보할 수 있어야 한다.
- 부가 가치 자료 : 수집한 자료에 의미있는 가치를 부여할 수 있어야 한다. 즉 가장 많은 트래픽과 오류를 발생시키는 호스트들을 집중 관찰함으로써 문제 해결에 대한 세밀한 정보를 관리자에게 줄 수 있다.
- 복수의 관리자 : 여러 관리자가 보내는 명령을 모두 수용해야 한다. 이때 대리인의 시스템 용량에 따라서 메모리 부족등으로 관리자 명령대로 수행을 못하거나 거역하는 경우가 발생할 수도 있다.[5]
RMON MIB[편집]
RMON은 새로운 피관리 객체들을 정의하기 위해서 추가된 MIB로, 표준 SNMP 전송 메커니즘과 커맨드를 이용하여 분산 랜 환경에 위치한 원격 모니터링 장비가 어떻게 네트워크 데이터를 수집, 저장할 것인지를 규정한 표준이다. 해당 세그먼트상의 트래픽 정보를 수집하고 처리하여 관리국이 요구하는 정보만을 전송하기 때문에 네트워크상의 SNMP 트래픽이 격감하고, 네트워크 관리 시스템의 부하를 감소시킬 수 있다. RMON MIB 구성은 이더넷과 토큰링용 정보를 포함한 MIB-Ⅰ과 보다 세부적인 트래픽 정보를 제공하는 MIB-Ⅱ로 나누어진다.[3]
- 기능
- 통계 : 한 세그먼트내에서 발생한 패킷/바이트 수, 브로트캐스트/멀티캐스트 수, 충돌(collision) 수 및 패킷 길이별 수 그리고 각종 오류에 대한 통계를 제공한다.
- 이력 : 관리자가 설정한 시간 간격내에 발생한 각종 트래픽 및 오류에 대한 정보를 제공한다. 기본적으로 단기/장기적으로 간격을 설정가능하고 1~3.600초를 간격으로 제한한다. 이 자료를 통해 시간대별 이용 현황 및 다른 세그먼트와 비교가 가능하다.
- 경보 : 주기적으로 특정한 값을 체크해 기준치(임계치)에 도달하면 관리자에 보고하고 대리인이 자신이 기록을 보유하고 있다. 기준치는 절대값 및 상대값으로 정할 수 있고 계속적인 경보 발생을 막기 위해서 상/하한치를 설정해서 넘나드는 경우에만 경보가 발생한다.
- 호스트 : 세그먼트에 연결된 각 장비가 발생시킨 트래픽, 오류수를 호스트별로 관리한다.
- 상위 N개의 호스트 : 위 호스트 테이블에 발견된 호스트 중에서 일정시간 동안 가장 많은 트래픽을 발생시킨 호스트를 찾는다. 관리자는 원하는 종류의 자료(입/출 패킷, 바이트, 외부오류, 브로트캐스트/멀티캐스트 패킷)와 시간 간격 및 원하는 호스트의 갯수를 설정해서 정보를 얻을 수 있다.
- 트래픽 메트릭스 : 데이터 링트 계층, 즉 맥주소를 기준으로 두 호스트간에 발생한 트래픽 및 오류에 대한 정보를 수집한다. 이 정보를 이용해서 특정 호스트에 가장 많은 이용자가 누구인지를 어느 정도는 알 수 있다. 다른 세그먼트에 있는 호스트가 가장 많이 이용했다면 이것은 주로 라우터를 통과함으로써 실제이용자는 알 수 없다.
- 필터 : 관리자가 특정한 패킷의 동향을 감시하기 위해서 이용한다. 이를 이용해서 특정패킷의 발생여부를 알 수 있고 경보와 사건 기능을 이용해서 한계치 이상 발생시에 알 수가 있다.
- 패킷 수집 : 세그먼트에 발생한 패킷을 수집해서 관리자가 분석할 수 있도록 한다. 관리자는 패킷의 전부 또는 일정한 길이만 보관하고 읽을 수 있도록 설정이 가능하다.
- 사건 : 일정한 사건이 발생하면 그 기록을 보관하고 관리자에게 경고(trap) 메시지를 보낸다. 트랩 발생 및 기록 보관은 선택적이다. 경보와 연관되어서 사건이 발생하면 사건 기록 및 트랩 발생은 관리자가 사전에 설정 가능하다.[5]
- 구성
- 프로토콜 디렉토리(protocolDir) 그룹 : Probe가 해석할 수 있는 모든 프로토콜의 마스터 디렉토리로 각각 프로토콜의 엔트리를 가지고 프로토코로 디렉토리 테이블을 포함한다.
- 프로토콜 분배(protocolDist) 그룹 : 각 프로토콜 당 랜 세그먼트에 의해 생성된 트래픽의 양에 대한 총 통계를 관리한다.
- 주소 맵(adressMap) 그룹 : 정확한 맥주소와 포트에 연결된 장치 그리고 서브넷의 물리적 주소를 위해 각 네트워크 주소를 매치하여 관리한다.
- 네트워크 레이어 호스트(nlHost) 그룹 : 네트워크 레이어 주소를 기반으로 한 호스트들의 입출력 트래픽 양에 대한 통계를 관리한다.
- 네트워크 레이어 매트릭스(nlMatrix) 그룹 : 네트워크 레이어 주소를 기반으로 한 호스트들 사이의 트래픽 양에 대한 통계관리, TopN 통계치를 다루는 제어 테이블과 자료 테이블을 포함하여 몇몇 메트릭스에 따라 상위 N개의 호스트 쌍을 관리한다.
- 애플리케이션 레이어 호스트(alHost) 그룹 : 특정 호스트의 응용 레벨 프로토콜의 트래픽에 대한 통계 정보를 관리한다.
- 애플리케이션 레이어 매트릭스(alMatrix) 그룹 : 응용 레벨 주소를 기반으로 한 호스트 간에 트래픽 양에 대한 통계를 관리한다.
- 사용자 이력 모음(userHistory) 그룹: 사용자 명세 변수와 사용자 정의변수에 의한 데이터 로그같은 주기적인 샘플들을 관리한다.
- 프로브 배열(Probe Configuration) 그룹 : 원격으로 Probe들을 구성하기 위한 구성 파라미터들을 제어하는 방법을 제공한다. 에러 Trap 전송 개소, Probe와 모뎀의 통신 방법, Probe에 의한 데이터 로드시키는 방법 등을 예로 들 수 있다.[3]
RMON2[편집]
기존에 발표된 RMON은 한 세그먼트에 대한 트래픽을 감시하는 데는 적합했다. 그러나 RMON은 맥 계층까지만 분석이 가능하므로 어떤 프로토콜이 사용되는지 그리고 어떤 애플리케이션이 네트워크에 영향을 주는지는 거의 알 수가 없었다. 결국 이런 점을 보완하기 위해서 등장한 것이 RMON2이다 RMON2에 추가된 것은 프로토콜별 분포현황, 네트워크 계층 즉 IP, IPX, DECnet, 애플톡 등의 호스트별 트래픽을 수집한다. 네트워크 계층의 호스트간의 트래픽을 수집함으로써 애플리케이션, 웹서버와 같은 호스트에 가장 많은 트래픽을 발생시키는 호스트를 찾을 수도 있다. 그리고 애플리케이션 계층 차원에서 호스트별 트래픽의 감시 및 호스트간 트래픽을 관찰 할 수 있다. RMON2의 발표로 네트워크 관리자는 이제 OSI 7계층 모두를 관찰할 수 있게 되었다. 그러나 이 모두를 구현하자면 대리인의 시스템 자원이 충분해야 하고 성능이 우수해야 한다. 이 모든 기능을 갖추려면 단독 장비로 구성해야 한다. 그러나 요즘 네트워크 구성이 스위치를 이용해서 세그먼트를 분리하는 방향으로 나아가고 있다. 이때 스위치의 각 포트당 하나의 세그먼트가 되는데 여기에 하나씩 RMON 대리인을 장착하기에는 비용이 문제다 이를 해결하기 위해서 대부분의 스위치 장비가 RMON을 탑재하고 있으나 RMON과 RMON2의 모든 기능을 지원하기에는 본래의 스위치 기능에 악영향을 줄 수 있다. 대안으로 나온 것이 스위치의 각 포트에 연결된 허브에 RMON을 탑재하는 방법이다.[5]
비교[편집]
아이피 관리[편집]
네트워크 관리 시스템은 네트워크 장비에 대한 모니터링 기능을, IP관리 시스템은 엔드포인트에 대한 통제 기능을 가지고 있다. 네트워크 관리 시스템은 라우터나 스위치 같은 네트워크 장비의 상태를 확인하고 네트워크상에 장애가 나지 않도록 하는데 목적을 두고 있는데 반해, IP관리 시스템(IPMS)은 PC와 같은 단말(엔드포인트)의 네트워크 연결 상태를 모니터링하고 장애나 보안사고가 나지 않도록 하는데 목적을 두고 있다. 또한, 네트워크 관리 시스템은 네트워크 기기들의 상세한 상태를 모니터링하고 알림을 하는 기능을 주로 제공하고, IP관리 시스템은 현황 모니터링 기능과 더불어 엔드포인트 기기를 통제하는 기능까지 제공하는 차이가 있다.
- 관리 대상
네트워크 관리 시스템과 IP관리 시스템은 우선, 관리하고자 하는 IT자산이 다르다. 네트워크 관리 시스템은 SNMP라 하는 프로토콜이 설정되어 있는 기기에 대한 상태 및 성능을 측정한다. 따라서 대상이 되는 장비는 SNMP Agent가 활성화 되어 있어야 한다. 대부분의 네트워크 장비는 SNMP Agent가 탑재되어 있으며, 네트워크 관리 시스템은 이러한 네트워크 장비들을 모니터링 한다.[6] 네트워크 관리 시스템을 통해서 스위치 포트에 어떤 IP를 가지고 통신하는 장비가 있는지 탐지할 수도 있다. 하지만 이는 주된 관심 대상은 아니다. 반면 IP관리 시스템은 PC와 같은 네트워크에 연결된 엔드포인트이다. 네트워크에 연결되는 엔드포인트들 즉, 단말들의 IP 사용 현황을 모니터링하거나 통제하는 역할을 한다. 따라서 엔트포인트 쪽에 특별히 활성화시켜야 할 에이전트는 없다. IP 프로토콜을 이용하는 모든 기기들을 탐지하고 통제한다. IP관리 시스템의 부 관리대상은 라우터나 스위치같은 네트워크 기기이다. 네트워크 기기들도 IP통신을 하기 때문에, IP관리시스템이 관리하는 범주안에 들어가며, IP관리시스템에 의해 보호될 수 있다. 하지만 네트워크 관리 시스템은이 제공하는 만큼의 네트워크 기기 상태에 대한 상세한 정보를 제공하지는 않는다.
- 관리목적
네트워크 관리 시스템과 IP관리 시스템은 IT자산을 관리하고자 하는 목적 또한 다르다. 네트워크 관리시스템은 네트워크 장비 상태 모니터링, 성능 측정 및 알람, 장애 보고 등 전반적인 네트워크에 연결된 기기들을 확인하며, 주로 라우터, 스위치와 같은 네트워크 장비들의 상태를 모니터링하는데 주된 목적이 있다. 네트워크상에 부하가 걸리거나 문제가 생길 시 빨리 상태를 파악하고 조치를 취하여야 하기때문에, 성능을 주시하고 있다가 문제나 장애가 발생할 시 관리자에게 알람을 주게 된다. 반면 IP관리 시스템은 비인가된 IP 및 단말(엔드포인트) 차단, 네트워크 사용 현황 모니터링, IP 사용자 관리, 신규 IP차단/할당, IP충돌 보호 등 IP관리 시스템은 네트워크에 연결되어 있는 PC와 같은 컴퓨팅 기기들의 네트워크 사용 현황을 모니터링하며 이런 단말(엔드포인트)로 인해 발생할 수 있는 장애나 사고를 막는데 그 사용 목적이 있다. 네트워크 상에 어떤 종류의 단말들이 온라인인지 오프라인인지 알 수 있다. 허가된 사람이나 단말기가 아닌경우에는 차단하고 허가된 사람일 경우는 사용할 수 있도록 한다. IP로 인해 발생하는 주된 장애 중 하나는 IP충돌로 인한 네트워크 사용 마비인데 이러한 장애로 부터 네트워크를 보호한다.[7]
이에스엠[편집]
ESM과 네트워크 관리 시스템을 비교하면 다음과 같다[8]
이에스엠과의 비교 구분 네트워크 관리 시스템 이에스엠 관리대상 네트워크 장비 네트워크 장비, 주요 시스템, 보안장비 관리목표 네트워크의 가용성 확보를 위한 트래픽 관리, 장애 관리 등 조기 위협 요소 탐지 및 대응을 위한 예방 체계 구축 주요특징 트래픽 모니터링에 의한 가용성 확보에 초점, SNMP 프로토콜 기반의 장애 및 성능 관리, 최근 ESM과의 연동사용으로 상호 보완 방식으로 사용되는 경향 네트워크 관리 시스템의 일부 기능이 중복되는 경우가 있으나 관리 관점이 다름, 네트워크 장비, 시스템 보안 장비들의 발생 이벤트간의 연계 분석에 근거한 분석 방법과 그에 따른 적절한 대인기능, 단순 기능 위주의 제공에서 컨텐츠가 포함되는 프로세스 지원이 강조
제품[편집]
- 오픈뷰
HP사의 오픈뷰(OpenView)는 가장 유명한 네트워크 관리 시스템 플랫폼중의 하나이다. 특징은 일반적으로 잘 알려진 통합 네트워크 관리 시스템으로 시스템과 프로토콜에 독립적인 분산형 관리 구조를 지향하고 썬(SUN), HP, 윈도우NT 등 거의 모든 OS를 지원한다. 또한 그래프나 표 등으로 결과를 표시해 줌으로 보기 쉬우며 네트워크 성능의 자동점검과 주기적으로 네트워크 데이터를 수집 및 저장한다.
- 선넷 매니저
선넷 매니저(SunNet Manager)는 분산된 작업그룹들의 관리를 위한 개발 툴을 제공하는 네트워크 관리 시스템으로 자동적으로 시스템과 네트워크를 분석하고 관리자가 볼 수 있도록 모니터링 한다. 그리고 Sun호환 기종에서 네트워크 관리 소프트웨어로서 가장 많이 쓰이며 소규모 랜(LAN)에서 대형 네트워크까지를 포함하는 관리 능력과 다양한 형태의 에이전트 기능, 애플리케이션 프로그램의 개발 기능 등을 제공한다. 사용자가 애플리케이션을 개발 응용할 수 있는 확장성을 고려한 소프트웨어로 구성되어 있다. 특징은 시스템과 OS자원의 통계와 CPU 사용과 가용 메모리와 같은 자원의 통계, 디스크와 파일 시스템의 관리와 NFS나 RPC와 같은 애플리케이션이나 데이터베이스, 네트워크 서비스의 상태 관리 등이 있다.
- 탭스
탭스(TAPS; Traffic Analysis Planning Support System)는 웹 기반 네트워크 분석 및 설계/진단 지원 시스템으로 매우 쉬운 사용자 환경과 보고 기능을 제공하는 네트워크 관리 애플리케이션이다.특징은 웹 브라우저를 이용한 사용자 인터페이스이며 웹 서버가 망관리 시스템 역할을 수행한다. 애플리케이션, 랜, 왠을 통합 관리한다. 자바 기술을 이용한 트래픽이 감소한다. 일정기간 분석이 가능하다.(일간, 주간, 월간, 임의시간대 분석 가능) 임계치에 의한 보고 기능이 있다. 분석 리포트의 편집 기능이 있다. 분석 화면의 로컬 프린트가 가능하다.
- 모나리자
모나리자(MonaLisa)는 랜(LAN), 왠(WAN)으로 구성된 네트워크 장치 및 트래픽에 대한 구성, 장애, 성능 요소의 감시 및 분석 기능을 제공하는 클라이언트-서버 기반의 네트워크 관리 시스템이다.
- 엠알티지
엠알티지(MRTG)는 SNMP 에이전트의 트래픽 정보를 획득하여 관리자에게 그래픽으로 보여주는 도구로서 가장 범용 목적은 네트워크 회선의 이용률을 보고하는 것이다. 또한 엠알티지는 관리자가 원하는 MIB 객체(패킷 손실, 에러와 같은 정보)를 지정하여 트래픽을 분석할 수 있다. 특징은 엠알티지는 GIF 이미지를 포함하여 실제 트래픽량을 생생하게 보여줄 수 있는 HTML문서를 만들어 웹상에서 볼 수 있다. 펄(Perl)과 C를 기본으로 한다. 설정이 쉽고 확장성이 우수하다. 에러 패킷수, 시스템 로드 상황, 모뎀 상황 등의 어떤 SNMP 변수든 쉽게 모니터링 할 수 있다. HTML 리포트는 일간(최근 33시간) / 주간(최근 8일) / 월간(최근 5주) / 연간(최근 13개월) 그래프를 가진다. 트래픽 로그가 일정크기 이상 증가하지 않도록 통합(consolidation) 알고리즘을 사용하여 많은 SNMP 에이전트를 관리할 수 있다.[9]
각주[편집]
- ↑ 네트워크 관리 시스템 위키백과 - https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%EA%B4%80%EB%A6%AC_%EC%8B%9C%EC%8A%A4%ED%85%9C
- ↑ Jian Ren and Tongtong Li, 〈Chapter 12: Network Management〉, 《Michigan State University》
- ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 한국전력공사 전자통신처장 이강수, "企業 데이터 通信網 제어·감시를 위한 - 네트워크 관리 시스템 (NMS)", 전자부품연구원 전자정보센터
- ↑ 12bme, 〈(네트워크) NMS와 TMN〉, 《티스토리》, 2017-08-27
- ↑ 5.00 5.01 5.02 5.03 5.04 5.05 5.06 5.07 5.08 5.09 5.10 5.11 5.12 〈Chapter 11 네트워크관리(NMS)〉, 《아스트리즈닷컴》
- ↑ NMS 정보통신가술용어해설 - http://www.ktword.co.kr/abbr_view.php?m_temp1=1517
- ↑ 엠엘소프트, 〈(비교분석) IP관리와 NMS의 차이〉, 《네이버 블로그》, 2013-08-12
- ↑ NMS 지식덤프 - http://www.jidum.com/jidums/view.do?jidumId=534
- ↑ 다희아빠, 〈NMS〉, 《티스토리》, 2006-11-07
참고자료[편집]
- 네트워크 관리 시스템 위키백과 - https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%EA%B4%80%EB%A6%AC_%EC%8B%9C%EC%8A%A4%ED%85%9C
- NMS 정보통신가술용어해설 - http://www.ktword.co.kr/abbr_view.php?m_temp1=1517
- NMS 지식덤프 - http://www.jidum.com/jidums/view.do?jidumId=534
- Jian Ren and Tongtong Li, 〈Chapter 12: Network Management〉, 《Michigan State University》
- 한국전력공사 전자통신처장 이강수, "企業 데이터 通信網 제어·감시를 위한 - 네트워크 관리 시스템 (NMS)", 전자부품연구원 전자정보센터
- 〈Chapter 11 네트워크관리(NMS)〉, 《아스트리즈닷컴》
- 다희아빠, 〈NMS〉, 《티스토리》, 2006-11-07
- 엠엘소프트, 〈(비교분석) IP관리와 NMS의 차이〉, 《네이버 블로그》, 2013-08-12
- 12bme, 〈(네트워크) NMS와 TMN〉, 《티스토리》, 2017-08-27
같이 보기[편집]