NMS 개념 - 장애관리 세번째

앞에서 네트워크 관리자의 역할은 네트워크가 원활하게 동작하게 하는 것이라고 정의를 내렸다.

그 첫번째 목표가 "네트워크 장애 시간의 최소화" 이며 이를 위해 장애 감지 시스템을 만드는 것이라고 설명을 했다.

그럼 이제 "장애"란 무엇인가를 생각해 보기로 하자.

 

앞에서 ping 와 snmp polling을 가지고 구축한 장애감지 시스템을 상기해 보면, ping 하나만 보더라고, ping 응답이 어떠냐를 가지고 꽤 여러 가지의 정책을 결정해야 함을 볼 수 있었다.

 

과거에도 그렇고 현재에도 그렇고 네트워크 장애는 ping 또는 관리 프로토콜인 snmp 응답 상태에 따라 판단하는 것이 대세이다.

 

그러나, 네트워크 환경이 바뀌고 사용 형태가 달라지면서 장애에 대한 정의는 여러 가지로 다양하게 바뀌고 있다.

 

최근 사용되는 어플리케이션은 대부분 네트워크 위에서 동작한다.

먼저 물리적으로는 연결되어 있는 상태에서 특정 어플리케이션이 동작하고 있는데 이 어플리케이션이 동작하지 않는 경우이다. 이 경우 어플리케이션을 사용하고 있는 사용자는 네트워크가 안된다는 불평을 늘어놓게 된다.

 

이 어플리케이션이 동작하지 않는 이유는 과연 무엇일까?

어플리케이션 문제(버그), 사용자 PC 문제(맛이 간 OS), 랜카드불량, 회선속도(다른 트래픽이 많아 드랍됨), 연결장비 문제(라우터나 스위치에 부하가 발생 또는 에러가 발생 또는 설정에 문제), 어플리케이션 서버 프로그램 문제, 서버 문제, DB 문제, 혹시 WEB 어플리케이션이라면 웹서버 문제.... 등등.  우리가 이 어플리케이션의 장애 원인을 밝혀 내기 위해서는 위와 같은 부분을 모두 체크해 봐양 하는 것이다.

 

그럼 네트워크 관리자가 저 위에 것을 다 확인해 봐야 하는가?

뭐.. 그건 아니다. 랜카드 불량이나 연결장비 문제, 그리고 회선속도 등에 대해서만 책임 관리를 하는 것이 일반적이고, 웬만한 수준의 회사에서는 네트워크 관리자에게 이 이상을 요구하지도 않는다. 아주 소규모 회사라면 저 위의 것을 모두 체크해야 하는 경우도 있을 수는 있겠다.

 

그러나, 네트워크 관리자가 랜카드 불량 정도의 물리적인 단절은 ping이나 snmp로 쉽게 확인할 수 있지만 그 외에 장비에서 일어나는 다양한 문제, 회선속도 저하 등에 대해서는 어떻게 알 수 있을까?