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

NMS 개념 - 장애관리 다섯번째

무늬만엄마 2006. 6. 5. 18:38

앞서 네트워크에서 장애를 인지하는 방법에 대해 몇 가지 살펴 보았다.

 

1. ping 을 이용한다. => 제일 쉽다. 그러나 정책을 잘 세워야 한다.

 

2. snmp polling 을 이용한다.

 => 다소 쉽다. 표준 MIB이라 불리우는 mib II 정보들을 이용한다.

 => Private mib의 영역으로 가게 되면 난해해진다.

 => 역시 정책이 들어가게 되면 ping의 경우보다 10배는 어려워진다.

 

3. snmp trap을 이용한다.

 => 다소 쉬우나 장애 상황을 분리해 내는 것이 어렵다.

 => 이건 Private mib이 필수 사항이다.

 => 역시 정책도 필수 사항이다.

 => 이 trap은 syslog와는 달리 여러 개의 variable들로 나누어져 올라오므로

     관리자가 받아서 문장으로 만들어 주어야 한다. => 때문에 복잡해질 수 있다.

     이 variable의 갯수나 형식은 정해져 있지 않다.

 

4. syslog를 이용한다.

 => 다소 쉬우나 장애 상황을 분리해 내는 것이 어렵우며, log의 홍수에 빠질 염려가 있다.

 => 장비를 만지는 엔지니어들은 제일 선호하나, 관리자들은 좋아하지 않는다.

 => 그냥 로그다.

 

그러나...

네트워크에서 장애가 발생하는 것을 파악하는 것은 이렇듯 명확하지만은 않다.

최근들어 Application의 비중이 높아지고 장비의 사양이 올라가면서...

장비에 들어가는 OS들도 점점 복잡해졌고 자연히 장비 OS의 버그 때문에 발생하는 장애도 많이

발생하게 되었으니... 이런 것들은 장애라고 인식하기가 그리 쉽지만은 않다.

 

어찌되었건 "빠른 장애인지"라는 요구사항이 어느 정도 총족된다면,

관리자들은 다음 단계를 요구하게 된다.

바로 장애를 예고해 주는 시스템이다.

 

사실... 장애징후를 나타내는 것은 그리 많지 않다.

흔히 볼 수 있는 증상이 장비에서 Major 또는 Alert이라고 정의되는 Log를 발생시킨다거나

장비 또는 카드, 회선의 불량에 의한 회선 에러(CRC, Collision 등)가 쌓이고 있다거나

장비가 죽기 직전 CPU 사용율이 치솟았다거나, 아니면 측정 성능 지표들이 높아졌다거나

L4나 L7 장비의 경우 Session에 흐르는 데이터가 전혀 없다거나 등등의 현상이 있을 수 있는데,

이러한 것들은 Log 쪽을 제외하고는 성능관리 쪽에 더 가깝다.

 

그러나 장애예보라는 면에서 보자면 장애관리에 포함되기도 하므로,

이것도 보는 시각에 따라 장애관리에 포함시키기도 한다.

 

이렇게 장비 성능이 일정 수치를 벗어나면 장애징후로 보는 방법은 크게 두 가지가 있다.

하나는 NMS에서 주기적으로 장비에서의 주요 성능 지표들을 체크하다가 정해진 값을 벗어나느 경우

경보를 올려주는 방법이고, 또 하나는 장비 자체가 스스로 특정 값 이상인 경우 SNMP Trap이나 syslog로 알려주는 경우이다.

전자는 장비가 해당 성능 지표에 대해 값만 제공해 준다면 NMS의 역량에 달려있지만,

Trap의 경우에는 해당 장비에서 그러한 기능을 제공해 주어야만 가능하다.

 

관리자의 입장에서 볼때는 두 가지 경우 모두 가능했으면 하는 경우가 많으므로,

단 두 가지 방법은 데이터를 얻게되는 경로가 다르기 때문에 

이 두 가지 정보를 하나로 통합해 주는 기능이 NMS에서 제공된다면 더욱 좋을 것이다.

 

추가적으로 네트워크 관리자들은 성능 지표가 임계치를 한번 초과한다고 바로 알려주는 것이 아니라 

최소 2회 이상 초과한 경우였으면 좋겠다. 지표에 따라 초과가 아니라 특정 값 미만인 경우,

혹은 특정값 사이를 벗어난 경우 등등 다양한 옵션을 요구하는 경우가 있다.

그리고 CPU인 경우에는 CPU라는 메세지를, 메모리인 경우에는

메모리라는 별도의 메세지를 요구하는 경우도 있다.

또 임계치 경보를 발생시켰더라도 해당 값 아래로 떨어지면 복구용 메세지를 발생시킨다거나,

아니면 한번만 경보를 발생하는 것이 아니라 특정 지표가 계속 임계치를 벗어나는 경우

재경보를 발생시키는 등의 다양한 기능들을 요구하는 경우도 있다.

 

따라서 장비의 사용 상태를 측정하여 경보로 알려주는 예보 시스템을 제대로 구축하기란

그리 쉬운 일이 아니다.