NMS 개념 - 장애관리 세번째

앞에 두 개의 글에서 NMS의 중요한 기능 중에 하나는 장애를 자동으로 인지하고자 하는 것이고,

그러자면 장애를 판단하는 기준(정책)이 매우 중요하다 라는 것을 장황하게 설명해 보았다.

 

그렇다면 장애여부를 판단하는 기준을 어느 정도의 주기로 적용하면 좋을 것인지 살펴보자.

우리가 운영하는 네트워크에서는 icmp ping 또는 snmp polling 시 timeout을 1.0에 retry 3회 시에도 반응이 없으면 장애로 보기로 정책을 세웠다.

 

우리의 네트워크에는 장비가 10개 있다.

그럼 장비에 ping 또는 snmp request를 1분에 한번씩 보내보자.

10개를 죽 돌면서 ping을 해보고 상태를 반영하고 또 1분 후에 같은 일을 반복 수행한다.

별로 문제가 없어 보인다.

 

갑돌이네 네트워크에는 장비가 100개 있다.

역시 장비에 ping 또는 snmp request를 1분에 한번씩 보내보자.

이번에는 100개를 돌면서 같은 일을 한다. 근데 문제가 생겼다.

1분이 지났는데... 아직 100개의 장비 리스트의 끝까지 다 못갔다.

그럼 둘 중에 하나를 선택해야 한다.

1-뒤에 거는 무시한다.

2-걍 뒤에서 계속 진행하고 다 끝난다음 다시 시작하는 걸 생각해 본다.

조금 골치 아파진다.

프로그램을 수정하기는 어려우니 상태 확인 주기를 늘린다.

한 5분쯤으로 해보자. 잘 되는 거 같다.

 

을순이네 네트워크에는 장비가 1000개 있다.

역시 장비에 ping 또는 snmp request를 1분에 한번씩 보내보자.

이번에는 1000개를 돌면서 같은 일을 한다. 역시 같은 문제가 생겼다.

1분이 지났는데... 아직 100개 끝까지 다 못갔다.

그럼 둘 중에 하나를 선택해야 한다.

1-뒤에 거는 무시한다.

2-걍 뒤에서 계속 진행하고 다 끝난 다음 다시 시작하는 걸 생각해 본다.

조금 더 골치 아파진다. 반영주기를 10분으로 늘렸다.

같은 문제가 생긴다. 게다가 장애 반영이 너무 늦어진다.

장애가 나거나 복구된 것을 10분 주기로 알 수 있다.

결국 프로그램은 수정되어야 한다.

한 번에 리스트를 10개로 분할해서 돌린다.

1000개를 100개씩 나누어서 열심히 상태를 체크한다. 3분이면 된다. 다행이다.

 

병철이네 네트워크에는 장비가 10000개 있다.

위에서 문제를 해결한 프로그램이 있으니 10개로 나누어서 돌린다.

한번에 1000개씩 리스트를 나누어서 체크한다.

저런.. 잘 안된다. 반영주기를 10분으로 늘렸다.

같은 문제가 생긴다. 게다가 장애 반영이 너무 늦어진다.

프로그램은 또 수정되어야 한다.

한 번에 리스트를 100개로 분할해서 돌린다.

10000개를 100개씩 나누어서 열심히 상태를 체크한다. 3분이면 된다.

근데 프로세스가 한꺼번에 100개가 뜨고 시스템에 부하가 걸린다.

 

근데 10000대의 장비가 다 중요하지 않댄다.

그럼 중요한 거 100개는 1분으로 하고, 나머지는 걍 10분으로 했으면 좋겠다.

근데.. 아주 아주 중요한 장비 5개를 특별히 10초 정도로 관리 했으면 좋겠다.

물론 실시간이면 제일 좋겠지만 특별히 10초 정도도 괜찮겠다.

 

저런... 프로그램이 대폭 수정되어야 한다.

우리의 NMS는 특정 장비 또는 그룹 별로 상태 확인 주기를 다르게 줄 수 있어야 하고,

상태 확인 프로그램은 이 설정내용에 딸 가변적으로 동작해야 하며,

장비 갯수를 알아서 판단해서 10개로 쪼갤 것인지 1000개로 쪼갤 것인지를 결정해야 한다.

 

얼핏 보면 인공지능 프로그램 같다.

그러나 여기서도 반드시 인풋이 있다.

1. 내가 관리해야 하는 대상과 갯수가 정해져 있다.

2. 상태반영 주기를 정의해야 한다.

 

따라서 관리자는 이러한 정책을 정하고 NMS에 반영할 수 있어야 한다.

이러한 정책들을 입력하고 설정하는 화면이 프로그램에 추가된다.

 

네트워크가 커질수록 관리대상의 종류와 중요도가 달라질 수록 이러한 설정 메뉴들은 점점 추가되며,

프로그램은 점점 복잡해 질 것이다.