* about Network..

RMON

Network의 효율적 이용을 위해서 현재의 Network 상태를 측정하고 과거의 기록을 토대로 앞으로의 Network 문제를 사전에 예견하고 제거하기 위해서 유용하게 이용되는 것이 RMON(Remote network-MONitoring)이다. 중앙에서 원거리 지역의 local Network의 전체 이용현황을 적은 대역폭으로 쉽게 알수 있게 해준다.

기존의 SNMP MIB들이 대리인(Agent)이 탑재된 장비 자신의 처리 결과만을 보유하고 있는 데 반해서 RMON agent는 한 세그먼트 전체에서 발생하는 트래픽을 파악하게 해준다. 즉 전체 발생 트래픽, segment에 연결된 각 호스트의 트래픽, 호스트들 간의 트래픽 발생현황을 알려준다.

이런 처리를 위해서 RMON agent는 전체 통계 데이타, 이력 데이타(history), HOST 관련 데이타, HOST MATRIX와 사전에 문제 예측 및 제거를 위해서 특정 패킷을 필터링하는 기능과 임계치를 설정해서 이에 도달하면 자동으로 알려주는 경보기능 및 사건 발생 기능을 보유하고 있어야 한다.

Network에서 발생한 트래픽 모두를 관찰하고자해서 나온 것이 Network Moniotor다. 또는 분석기(analayzer), Probe라고 부른다. 이글에서는 SNMP에서와의 혼동을 막기위해서 대리인(agent)라고 칭한다. 실제는 probe라는 말을 많이 쓴다. Network 데이타를 수집하는 Agent는 보통 단독 장비로 또는 W/S, PC/나 hub, switch등의 장비에 탑재하는 경우가 있다.단독 장비는 모든 트래픽을 분석할 수 있으나 별도로 구입해야하므로 비용이 문제고 기존장비에 탑재된 경우는 비용절감 효과는 있으나 장비고유의 업무처리 때문에 트래픽을 정확하게 분석할 수 없는 단점이 있다

RMON이 정의되어있는 RFC1757(구rfc1271)는 주로 RMON MIB에 집중되어 있다.이 문서는 기본적으로 SNMP를 기반으로 한 RMON 대리인과 RMON 관리자간의 각종 절차를 담고 있다. 즉 대리인이 관리자의 요청에 의해서 어떻게 데이타를 채집하고 그리고 그 데이타를 보관하고 어떻게 삭제하는 가에 관한 것이다.

RMON이 갖추어야할 기본적인 목표를 다음과 같이 제시하고 있다.

1) Offline 동작
관리자와 RMON 대리인간의 통신에 여향을 받지 않고 대리인은 해당 세그먼트의 성능, 구성 정보등을 축적하고 관리할 수 있어야한다.

2) Proactive Monitoring
대리인에 주어진 자원에 따라 Network를 진단하고 성능 자료의 이력 관리를 통해서 장애 및 장애에 대한 기록을 관리자에게 보고할수 있어야 한다.

3) 문제 탐지 및 보고
관리자가 특정 상태 - error , 특정 패킷 -에 대한 보고를 명령하면 이를 계속 감시하다가 탐지되면 이 사건을 기록하고 관리자에게 통보할수 있어야 한다.

4) 부가 가치 자료
수집한 자료에 의미있는 가치를 부여할 수 있어야 한다. 즉 가장 많은 트래픽과 에러를 발생시키는 호스트들을 집중 관찰함으로써 문제해결에 대한 세밀한 정보를 관리자에게 줄 수 있다.

5) 복수의 관리자
여러 관리자가 보내는 명령을 모두 수용해야 한다. 이때 대리인의 시스템 용랑에 따라서 즉 메보리 부족등으로 관리자 명령대로 수행을 못하거나 거절하는 경우가 발생할 수도 있다.

RMON 표준에는 관리자가 데이타 수집 명령을 내리지 않았을 때 , 즉 RMON Agent가 동작을 시작하면서 필요한 정보를 수집할 것인지에 대한 기준은 없다. 단지 구현하는 사람의 임의로 정해놓고 있다. 그래서 실제로 어떤 RMON Agent는 관리자가 일정한 데이타의 수집을 요청하지 않으면 전혀 데이타를 수집하지 않는 것도 있다. 대부분은 기본적으로 status , history, host, host matrix 정도의 데이타는 Agent가 스스로 데이타를 수집하기 시작한다.이때는 이 테이블 열(row)의 소유자 ,즉 만든 관리자는 "monitor"라는 이름으로 시작해서 구별할 것을 권장하고 있다.

RFC1757에는 9개의 MIB Group이 정의되어있다. 그러나 구현하는 것은 구현자 임의로 선택할 수 있다. 그러나 한 그룹을 구현하려면 그 그룹내에 있는 모든 객체를 구현해야만 한다. 즉 Host Group를 구현하면 반드시 HostControlTable, HostTable, HostTimeTable 모두를 반드시 구현해야 한다.

그리고 RMON MIB를 구현하기 위해서는 <그림1>의 system과 interface 그룹은 반드시 구현되어야 한다. 이는 RMON MIB에서 두 GROUP에 있는 객체를 이용하고 있기 때문이다. 또한 RMON MIB 각각의 그룹들은 서로 관련이 있는 경우가 많다. 그래서 하나의 그룹을 구현하면 반드시 다른 그룹도 구현해야 한다. HISTORY 그룹은 반드시 statistics 그룹의 구현이 필수다.

RMON MIB 그룹은 모두 테이블 형태다. 대부분의 그룹은 해당하는 객체들을 생성하는 데 필요한 각종 자료 - history 시간 간격, host 그룹의 HOST 수, 자료의 생성자(소유자) 등- 를 가지고 있는 관리(control) 테이블과 실제 필요한 자료를 수집하는 테이블로 구성되어있다. 관리 테이블에는 단순하게 크기를 제한하거나 수집할 자료의 interface를 지시하는 이외에 이 테이블을 포함해서 자료 테이블을 만들고 삭제하게 할 수 있는 "상태(status)" 객체가 정의되어있다.

이 상태 객체를 변경함으로써 테이블의 생성 , 자료 수집, 삭제가 이루어진다. 이 객체가 생성중(underCreation(3)) 상태이면 대부분의 자료 테이블은 완전한 자료가 아니다. 한편 대부분의 관리 테이블은 상태객체가 "valid(1)" 상태이면 관리 테이블의 자료를 수정할 수 없다. 이는 이미 설정된 관리값으로 자료 테이블이 형성된 다음이므로 수정하는 대신에 삭제하고 재설정 또는 생성중 상태로 먼저 수정하고 설정해야 한다.

복수의 관리자에게 대리인이 응답하므로 대리인은 많은 시스템 자원이 필효하게 된다. 복수관리자의 요청을 시스템 자원의 부족으로 거절하는 경우가 생길 수가 있다. 이러한 경우등을 방지하기 위해서는 주관리자가 각 그룹이에 설정될 수 있는 테이블의 열(ROW) 등을 제한하거나 관리자가 불필요하게 설정해 놓은 자원은 스스로 삭제하는 것이 필요하다. 물론 대부분의 대리인은 지나치게 많은 자원이 소모되면 일정한 규칙을 정해놓고 테이블의 열울 삭제한다. 이에 대한 명확한 표준은 없다.

1) 통계(Statistics)
한 세그먼트내에서 발생한 패키/바이트 수, Broadcat/Multicast 수, 충돌(collision) 수 및 패킷 길이별 수 그리고 각종 에러(프래그먼트, CRCAlinment , jabber, 길이미달, 길이초과)에 대한 통계를 제공한다.

2) 이력(History)
관리자가 설정한 시간 간격내에 발생한 각종 트래픽 및 에러에 대한 정보를 제공한다. 기본적으로 단기/장기적으로 간격을 설정가능하고 1~3600초를 간격으로 제한다. 이 자료를 통해 시간대별 이용현황 및 다른 세그먼트와 비교가 가능하다.

3) 경보(Alarm)
주기적으로 특정한 값을 체크하여 기준치(임계치)에 도달하면 관리자에 보고하고 대리인 자신이 기록할 보유하고 있다. 기준치는 절대값및 상대값으로 정할수 있고 계속적인 경보발생을 막기 위해서 상/하한치를 설정해서 넘나드는 경우에만 경보를 발생하게 한다.

4) Host
세그먼트에 연결된 각 장비가 발생시킨 트래픽 , 에러수를 호스크별로 관리한다.

5) 상위 N개의 Host(HostTopN)
위 호스트 테이블에 발견된 호스트 중에서 일정시간 동안 가장 많은 트래픽을 발생시킨 호스트를 찾는다. 관리자는 원하는 종류의 자료(IN/OUT 패킷, 바이트, outErrors, broad/mutiCast 패킷)와 시간 간격 및 원하는 호스트의 갯수를 설정해서 정보를 얻을 수 있다.

6) 트래픽 매트릭스(Matrix)
Datalink layer, 즉 MAC ADDRESS를 기준으로 두 호스트간에 발생한 트래픽 및 에러에 대한 정보를 수집한다. 이 정보를 이용해서 특정 호스트에 가장 많은 이용자가 누구인지를 어느 정도는 알수 있다. 다른 세그먼트에 있는 호스트가 가장 많이 이용했다면 이것은 주로 라우터를 거치므로 실제 이용자는 알 수가 없다.

7) 필터(Filter)
관리자가 특정한 패킷의 동향을 감시하기 위해서 이용한다. 이를 이용해서 트정 패킷의 발생여부를 알 수 있고 경보와 사건(event) 기능을 이용해서 한계치 이상 발생시에 알 수가 있다.

8) 패킷 수집(Packet Capture)
세그먼트에 발생한 패킷을 수집해서 관리자가 분석할 수 있도록 한다. 관리자는 패킷의 전부 또는 일정한 길이만 보관하고 읽어올수 있도록 설정이 가능하다.

9) 사건(Event)
일저한 사건이 발생하면 그 기록을 보관하고 관리자에게 경고(trap) 메세지를 보낸다. 트랩발생 및 기록 보관은 선택적이다. 경보(alarm)와 연관되어서 사건이 발생하면 사건기록 및 트랩 발생은 관리자가 사전에 설정 가능하다.

1) 트래픽 동향분석
통계, 이력, 호스트, 호스트 메트릭스 그룹들을 통해서 얻은 정보를 바탕으로 특정 세그먼트나 특정 장비에 대한 각종 정보를 알수있다. 에러가 발생하는 상황이나 특정 시간대의 트래픽 분석 , 트래픽의 증가 속도등을 측정할 수 있다.

2) 주요 장비에 대한 트래픽 분석
특히 중요한 파일/프린터/메일 서버등에 발생하는 트래픽을 분석 가능하다. 물론 이런 장비는 독자적인 관리 기능을 갖추고 있으나 이 장비의 본래 기능은 아니다. rmon을 통하여 얼마나 많은 접근이 이루어지고 , 어느 호스트가 가장 많이 이용하는가를 알 수 있다. 이것을 서버가 직접 관리하면 많은 부하가 발생한다. 또 어느 시간대에 집중적으로 접근이 발생하는 지를 알 수 있다.

3) 사전 문제 발생 제거
에러나 collision등 Network 성능에 영향을 미칠수 있는 자료를 사전에 체크하여 문제가 발생하기 전에 조치를 취할 수 있게 한다.경보 및 사건 기능을 이용하여 한계치를 위험 수위별로 설정해서 관리하면 많은 도움이 된다.

4) Network 구성 변경 자료
통계 자료를 이용해서 Network의 이용효율을 측정해서 재배치하거나 또는 메트릭스와 HostTopN을 통하여 특정한 흐스트간의 사용빈도와 가장 트래픽이 심한 서버와 같은 host를 스위치같은 장비를 통해서 분리해서 동일한 사용간을 한 그룹으로 만들어서 대여폭을 높일수 있다. WAN 대역폭 등을 계산해서 회선 교환 및 증설을 검토할 수 있다.

5) 미지원 SNMP 장비에 대한 자료 이용
기존에는 SNMP를 지원하지 않는 장비에서 발생한 트래픽을 관찰할 방법이 별로 없었다. RMON은 OSI 데이타링크 레이어를 관리하기 때문에 상위프로토콜과는 무관하다. 그래서 망관리에 대한 기능이 없던 PC등이나 ip가 아닌 ipx등의 장비에 대한 트래픽도 충분히 관찰이 가능하다.

기존에 발표된 RMON으로는 한 세그먼트에 대한 트래픽을 감시하는 데는 적합했다. 그러나 RMON은 MAC 게층까지만 분석이 가능하므로 어떤 프로토콜이 사용되는 지 그리고 어떤 애플리케이션이 Network에 영향을 주는 지는 거의 알수가 없었다. 결국 이런 점을 보완하기 위해서 등장한 것이 RMON2이다. RMON2는 최근에 표준으로 완성되어서 정식 문서로 배포되었다(RFC2021, RFC2074).

RMON2에 추가된 것은 프로토콜별 분포현황 , Network 계층 즉 IP, IPX, DECnet, AppleTalk 등의 호스트별 트래픽을 수집한다. Network 계층의 호스트간의 트래픽을 수집함으로써 애플리케이션, 웹서버와 같은 호스트에 가장 많은 트래픽을 발생시키는 호스트를 찾을 수도 있게 되었다. 그리고 애플리케이션 계층 차원에서 호스트별 트래픽을 감시 및 호스트간 트래픽을 관찰할 수 있다. 그이외에 많은 기능이 추가되었으나 자세한 설명은 RFC를 참조하면 된다.

RMON2가 발표되어서 Network 관리자는 이제 OSI 7 레이어 모두를 관찰할 수 있게 되었다. 그러나 이 모두를 구현하자면 대리인의 시스템 자원이 충분해야하고 성능이 대단해야 한다. 결국은 비용이 문제다. 이 모든 기능을 갖추려면 단독장비로 구성해야 한다. 그러나 요즘 Network 구성이 스위치를 이용해서 세그먼트를 분리하는 방향으로 나아가고 있다. 이때 스위치의 각 포트당 하나의 세그먼트가 되는 데 여기에 하나씩 RMON 대리인을 장착하기에는 비용이 문제다. 이를 해결하기 위해서 대부분의 스위치 장비가 RMON을 탑재하고 있으나 RMON과 RMON2의 모든 기능을 지원하기에는 스위치 본래의 기능에 악영향을 줄 수가 있다. 그래서 대부분 일부분만 지원할 수 밖에 없다.현재 대안으로 나온 것이 스위치의 각 PORT에 연결된 허브에 RMON을 탑재해서 해결하는 방안이다. HUB는 특별한 기능이 없어서 어느 정도는 가능하다.

출처 - http://www.hicore.com/