IT업무/네트워크관리(NMS)

NMS 개념 - 장애관리 네번째

무늬만엄마 2006. 1. 27. 11:18

네트워크 장애관리에서 가장 중요한 것은 관리정책과 좋은 NMS이다.

 

세번째 얘기에서는 ping response check와 snmp polling을 통한 장애 인지에 대해서 생각해 보았다. 전체 네트워크 장비에 대해 이렇게 일일히 체크를 한다는 것은 사실상 실시간 체크가 어렵다.  그렇다면 실시간으로 상태를 반영할 수 있는 방법이 무엇인가?

 

바로 SNMP Agent가 올려주는 상태에 대한 정보를 직접 받는 것이다.

이것이 잘 알려져 있는 SNMP Trap이라는 것이다. SNMP Trap은 장비가 중요한 장비 자체의 상태 변화를 SNMP Manager에게 알려주는 것인데, 그럼 어떤 경우에 상태를 알려줄 것인가?

 

표준에 의하면 여섯가지의 경우에 Trap을 발생시킨다.

SNMP Cold Start / SNMP Warm Start / SNMP Link Down / SNMP Link Up / SNMP Authentification Failure / SNMP EGP Down 이다.

 

문제는 이 여섯 가지의 경우를 통해서는 장비 CPU가 높아져서 죽기 직전인지, 장비 자체가 죽어버렸는지 등등 알 수 없는 것이 너무나 많다는 사실이다.

네트워크 관리자 입장에서는 알고 싶은 정보가 많기 때문에 업체에서는 Private MIB을 통해 추가적인 정보를 제공한다. Private MIB은 벤더별로 다르므로 벤더에서 제공한 MIB 파일과 문서들을 참조해야 하며, NMS는 이러한 Private MIB에서 제공하는 SNMP Trap 정보를 해석할 수 있는 능력을 가지고 있어야 한다.

 

모든 장비가 이러한 Private MIB을 충분히 제공할 것으로 기대해서는 안된다.

물론 이러한 MIB을 충분히 제공하는 장비들도 있다.

 

문제는 NMS에서 이러한 Private MIB을 어떻게 처리할 것인지 결정해야 하며,

역시 좋은 NMS는 이러한 기능들을 충실히 제공한다.

약간 좋은 NMS는 이러한 기능을 약간(잘 알려진 장비에 대해서만) 제공한다.

당연히 이러한 기능이 없는 NMS도 많이 있다.

여러 가지 기능을 충분히 지원하는 NMS는 가격이 비싸며, 사용하기 어렵다고 느껴진다.

 

여기에서 추가적으로 알아두면 좋은 것이 syslog이다.

대부분의 장비는 자체적으로 log를 메모리에 남기고 있는데,

대부분의 네트워크 관리자들은 이 log를 참조하여 장비 관리를 하고 있다.

그러나, 이 log들은 장비가 리부팅되면 없어져 버리며,

일일이 장비에 login 하여 확인해 보아야 하는 단점이 있다.

수십대의 라우터에 모두 로그인하여 log를 볼 수는 없기에,

대부분의 라우터, 스위치들은 syslog 프로토콜을 이용하여

이 log들을 syslog 서버로 보내는 기능을 제공한다.

 

syslog는 형식이 단순하게 종류, 시간, 장비명(서버명), 로그로 구성되어 있으므로

관리자가 쉽게 인식이 가능하며, 항상 장비에서 보던 형식이므로 친숙하다.

자연스럽게 네트워크 관리에 많이 이용되고 있다.

 

UNIX 시스템의 경우 syslogd라는 데몬이 기본 프로세스로 제공되므로,

장비들로부터 이 syslog들을 받아 로그들을 저장하며, NT는 기본 기능이 아니라 키위 등 syslog를 받아서 저장해 주는 상용 프로그램을 사용해야 한다.

SUN의 경우 /etc/syslog.conf 파일을 이용하여

받게 될 syslog 종류, 저장될 파일명 등에 대한 환경을 설정할 수 있다.

 

장비의 숫자가 많아지거나, debug 모드 등으로 syslog를 받게 되는 경우,

엄청난 log의 양 때문에 관리하기에 부담스러워 질 수 있으며,

특히 FWSM 같은 장비는 firewall log를 syslog로 발생시켜 주는데...

초당 몇백건의 syslog를 처리할 수 있는 프로그램이 별로 없기 때문에

이런 종류의 방화벽을 도입할 때는 관리 툴에 대해 고민을 해보는 것이 좋겠다.

 

============================================================================

 

약간의 여담을 달자면... 벤더들에 대한 불만이 많다. 

웬만하면 규약을 지켜서 만들고, Pravate 아래 구조를 함부로 바꾸지 말며, 문서를 잘 찾을 수 있도록 해 주었으면 좋겠다. 대체 홈페이지에 가도 어느 구석에 이 mib들이 박혀 있으며 뭐에 쓰는 건지 알 수가 없다. 버전이 올라간다고 공지도 없이 MIB Tree 구조를 바꿔버리는데 대책이 없다. 뭐 그나마 SNMP 라도 지원해 주면 고맙기는 하다.