⑦ 네트워크 모니터링

Special Issue - I T 비용 절감 방안과 위험 요소

“네트워크 관리의 기본은 네트워크 모니터링”

시스템이 고장날 때 통보를 받을 수 있게 하는 일을 조직에서 네트워크 관리의 최우선으로 생각하는 경우가 많으며 이는 충분히 그럴만한 이유가 있다. 조직의 규모가 크든 작든 애플리케이션, 프로세서 및 네트워크 스위치와 라우터가 가는 방향을 모니터링하는 것은 네트워크 관리의 기본이다. <편집자>

네트워크 관리를 어디서 시작해야 할지 알기란 쉬운 일이 아니다. 이 용어는 복잡하고 값비싸다는 이유로 비난을 받아 왔다. 사태를 더욱 악화시키는 것은 이것이 일관성 있게 적용되지 않는다는 점이다. 진정한 네트워크 관리란 네트워크, 시스템 및 애플리케이션 관리를 하나로 일관성 있게 할 수 있는 것이어야 한다.
관리라는 말 자체도 부담스러운 단어다. ‘네트워크 관리’가 의미하는 바를 체계적이고 눈에 볼 수 있는 형태로 보여주기 위해 자주 사용되는 모델로 FCAPS(Fault, Configu ration, Accounting, Performance, Security)가 있다. 이것은 베스트 프랙티스 규정이자 ISO 9000 인증의 일부인 ITIL(IT Infrastructure Library)과 함께 IT의 모든 것을 관리하는 부분과 프로세스를 정의한다.
하지만 이 짧은 여행에서 우리는 기본에 충실하려 하며, 그 기본이란 곧 무엇인가가 작동을 멈출 때 곧바로 밝혀낼 수 있는 방법을 말한다.
점검, 로깅 및 통보(checking, logging, notifying) 프로세스는 보통 핑(Ping)과 SNMP를 이용해 수행된다. 서비스가 가동되는지 여부를 파악할 수 있는 전용 제품들도 있고, 장비가 여전히 작동하는지를 확인하기 위해 그 장비로 텔넷을 실행시키는 등의 좋은 방법들도 있지만, 거의 모든 네트워크 관리 툴에 의해 공유되고 폭넓게 채택 및 사용 가능한 방식은 핑과 SNMP다.
스크립팅에 익숙하다면 무료든 아니든 어떠한 추가 네트워크 관리 툴이 없이도 핑을 실행하거나 자신의 SNMP를 실행할 수 있다. 핑은 아미가를 포함한 모든 운영시스템에서 실행이 가능하며 SNMP는 유비쿼터스에 가깝다.
SNMP는 점심으로 무엇을 먹었는지를 제외한 모든 것에 대한 방대한 정보를 제공한다. SNMP의 세부 사항들과 그 데이터 스트럭처인 MIB에 대해서는 언급하지 않겠지만, 에러와 CPU 사이클, OS 버전에 이르는 트래픽을 발견할 수 있으며, BLT의 LDL도 그러할 것이다.
SNMP가 보안 구멍이란 말을 들었고 이것을 켜는 것이 걱정된다면 두 가지 선택의 길이 있다. 안전하게 하고 싶으면 SNMP를 꺼두고 핑과 SSH를 이용해 스위치와 서버로 연결을 할 수 있다. 하지만 그보다 우리는 SNMP를 틀림없이 켜두는 쪽을 선호하고 있다.
99.99%의 이행률을 보이고 있는 SNMPv1이 네트워크에서 커뮤니티 스트링(Community String)을 클리어 텍스트로 보내는 것은 사실이지만 텔넷과 FTP 또한 이렇게 하기는 마찬가지다. 그러나 여기에 변명의 여지는 없으며, 가능한 한 언제나 SSH나 보안 FTP와 같은 방안을 이용해야 한다.
SNMPv3는 클리어 텍스트 커뮤니티의 단점을 해결함으로써 보안 네트워크 관리 프로토콜이 되긴 했지만, 이것은 대부분의 네트워크에서 현재 처리하지 못하는 프로토콜이다. SNMPv3에서 보안을 관리할 수 있게 하려면 다소 많은 이동을 해야 하며 제대로 하기 이해서는 시간과 제품(즉, 돈)이 필요하다.

간단하게 유지하기
보다 실행 가능한 것으로 SNMPv1을 이용하면서 네트워크를 보호할 수 있는 몇 가지 간단한 단계가 있다.
SNMPv1이 처음 보안 문제가 발생했을 때 언론에서는 겁나는 소식들을 떠들어 댔지만 대부분의 손상된 시스템에 SNMP 문제를 해결해주는 최신 패치가 없었다는 사실과 이들이 업체측의 디폴트 커뮤니티 스트링을 사용하고 있었다는 사실은 언급하지 않았다.
SNMP 설명서에는 읽기 커뮤니티 스트링을 퍼블릭(Public)으로, 쓰기 스트링을 프라이빗(Private)이라고 종종 부르고 있다. 그리고 많은 업체들의 디폴트 커뮤니티 스트링의 이름도 또한 정확히 이렇게 되어 있다. 위험을 더욱 가중시키는 것은 많은 신출내기 관리자들이 설명서를 읽고 나서 퍼블릭/프라이빗을 실질적인 스트링의 이름으로 해야 한다고 생각하는 것이다. 따라서 공격자는 네트워크 스캔을 통해 얼마간의 퍼블릭/프라이빗 액세스가 가능한 장비를 발견할 수 있으리라고 생각하는 게 당연하다. 물론 이것은 SNMP의 오류가 아니라 인간의 실수로 인한 문제다.
그리고 다소 복잡하긴 하지만 훨씬 안전하게 하기 위해서는 전략에 SNMP와 관리 트래픽만을 전달하는 관리 플레인을 만드는 것을 포함시키는 방법이 있다. 관리 네트워크를 생산 데이터 네트워크와 분리시킴으로써 액세스는 특정 네트워크로 제한될 수 있으며, 이러한 작업은 가상랜이나 별도의 NIC을 이용해 수행할 수 있다.

비용 효율적인 모니터링
SNMP는 폭넓은 가용성으로 인해 예산이 충분치 못한 조직에 이상적인 모니터링 방안이 되고 있다. 윈도와 웹 서버에서부터 스위치 및 소스 코드에 이르는 모든 것에서 SNMP가 지원이 된다. 게다가 여러 가지 좋은 툴들이 무료나 적당한 가격으로 사용이 가능하다. 예를 들어 윈도 자원 키트로는 명령어 라인 SNMPutil과 SNMPmon 유틸리티가 있는데, 이들은 네트워크 장비와 다른 서버들의 SNMP 변종들을 가질 수 있게 해주며, SNMPmon은 일정 기간 동안의 결과를 실제로 로깅할 수도 있다.
리눅스와 유닉스의 경우 SNMP 유틸리티는 매우 많다. 소스포지닷넷(SourceForge.net)과 심플웹닷오알지(Simple Web.org)는 SNMP 툴에 대해서는 전문적으로, 네트워크 관리에 대해서 일반적으로 살펴보기 좋은 곳들이다. 두 사이트 모두에서 리눅스가 지배적이지만 유닉스와 윈도 네트워크 관리 애플리케이션도 부족함이 없다.
처음으로 돌리게 될 툴들 가운데 하나는 MRTG(Multi Router Traffic Grapher)가 될 것이다. MRTG는 가장 풍부한 사양의 무료 네트워크 모니터링 소프트웨어라고 할 수는 없지만, 널리 배치돼 있으며 활발한 지원 기반으로 인해 NSM 초보자들이 시작하기 좋은 툴이다. 이것은 윈도 98을 비롯해 모든 플랫폼에서 돌아가며 대부분의 초보자들이 한 시간 내에 SNMP를 통한 네트워크 장비 모니터링을 시작할 수가 있다.
또 하나의 소중한 무료 네트워크 모니터링 툴로 빅 브라더(Big Brother)가 있는데, 이것은 현재는 퀘스트 소프트웨어(Quest Software) 소유다. MRTG와 마찬가지로 빅 브라더 또한 널리 배치돼 있으며 활발한 사용자 커뮤니티 지원도 함께 하고 있다. 퀘스트는 전담 지원이 있는 상용 버전을 만들고 있지만 빅 브라더의 무료 버전과 그 지원 네트워크도 두고 있다.
상용 제품이 보다 편안한 조직에게는 아이피스위치(Ipswitch)의 와츠업 골드(WhatsUp Gold), 솔라윈즈닷넷(SolarWinds.Net)의 네트워크 매니지먼트 툴셋(Network Management Toolset), 그리고 네온 소프트웨어(Neon Software)의 사이버게이지(CyberGauge) 등이 저렴하면서 중요한 기능들을 제공해준다.

소규모 환경에서의 유의점
소규모 환경에서 전술적인 네트워크 모니터링을 배치할 때는 다음 사항을 염두에 두라.
우선 복합 자동 탐색이나 자동 탐색에 시간을 낭비하지 말라. 5~10개 라우터나 몇 백 개의 노드가 있다면 네트워크 자산을 주동으로 인벤토리하는 편이 더 낫다. 물론 네트워크가 얼마나 자주 바뀌는지를 살펴보되 정확한 CSV를 자신있게 엑스포팅할 수 있다면 이것이 훨씬 더 나은 선택이다.
그 이유는 자동 탐색 프로세스는 제품의 가격이나 복잡성에 상관없이 보통 정확도가 90~95%에 불과하며, 이는 곧 그 결과물들을 감사해야 한다는 의미다. 따라서 제품들을 비교할 때 자동탐색 기능이 없는 게 있다고 하더라도 탐색 엔진이 없는 게 큰 문제는 아니라는 사실을 명심해야 한다.
그렇다면 정말 중요한 것들은 무엇일까?

>> 모니터링 시스템의 인터페이스.
당신이 유일하게 시스템을 다루는 사람이라면 개인적 선호도에 따르는 게 좋다. 하지만 모니터링이 중앙 운영팀에 의해 처리되고 있거나, 혹은 비기술 인력이 사용자 지원과 네트워크 상태 모니터링 작업에 함께 하고 있다면, 무미건조한 CLI는 맞지 않을 것이다. GUI는 학습이 더 쉬우며 특히 모니터가 드물게 이용될 경우에는 더욱 그러하다. 그리고 GUI는 보다 유연하고 생산적일 수 있게 해주기도 한다. GUI는 완벽하지 않으며 모든 애플리케이션의 경계를 넘나들지도 못하지만, 분명치 않은 문제에 대한 부담도 훨씬 적다.

>> 일이 잘못됐을 때 제품이 경보를 어떻게 보내는가.
여기에는 두 가지가 있는데, 하나는 통보받을 수 있는 방식이고, 다른 하나는 무언가 잘못됐을 때만 통보를 하는 소프트웨어의 정교함이다. 두 번째를 우선으로 생각하라.
모니터링되는 노드 수가 많은 대형 네트워크에는 많은 경보들이 있게 되며, 부하조절이 되는 서버가 오프라인 되는 것과 같이 크게 중요하지 않은 것들도 많다. 물론 누군가는 걱정이 되겠지만 이런 경보 때문에 점심시간을 날릴 필요까지 있을까? 그렇지는 않을 것이다. 이런 정도의 정밀성을 갖추기 위해서는 네트워크 모니터링 툴이 무엇이 정상인지, 그리고 뭔가가 잘못됐을 때가 언제인지를 파악함으로써 영향을 받는 장비가 하는 전체적인 서비스에서 맡은 역할이나 장소에 따라 중요도를 측정할 수 있어야 한다.
이러한 구분은 네트워킹 소프트웨어로서는 생각보다 어려우며 인간과 같은 판단을 하기 위해서는 다소 비싼 소프트웨어가 필요하다. 네트워크 서비스가 복잡하지 않다면 이벤트 중복방지와 다운스트림 억압 및 근본원인 분석 등의 기능들은 필요치 않을 것이다.

통보 기능
보다 실질적으로 고려해야 할 것은 제품이 어떤 종류의 통보를 지원하느냐다. 이메일 전송은 중요하며, 대부분의 툴들이 지원하고 있다. 호출기 전송 또한 널리 지원되고는 있지만 보다 문제의 소지가 많다. 일부 제품들은 연결된 모뎀을 이용해 전화 번호를 돌려야만 호출을 보낼 수 있게 돼 있다.
보다 나은 제품들은 비퍼 사업자가 필요로 하는 상호작동을 이해하는 테스트된 스크립트를 제공하기도 한다. 통보 수단으로 SMS를 사용하고 호출기를 버리는 데 관심이 있다면 SMS를 지원하는 소프트웨어를 골라 보라. 이는 상용 제품에서 보다 일반적으로 지원되고 있다.
또한 문제의 엄중성을 기반으로 색상이 바뀌고 이에 관련된 사운드나 WAV 파일이 있는 아이콘을 선택할 수도 있다. 더 나은 제품들은 외부 스크립트나 프로그램의 실행을 지원하기도 하는데, 예를 들어 퍼프몬(PerfMon)을 띄우고 CPU 성능을 캡처하기 시작한다.
경보 프로세스를 관리하는 일은 초대형 네트워크 관리 제품에서와, 많은 사람들이 24시간 통보를 필요로 할 때 더 어려워진다. 그러나 소규모 이행에서는 통보용으로 취할 수 있는 여러 가지 경로를 설정할 수 있는 능력이 중요하다. 예를 들어 웹 서버가 응답에 실패했을 때 ‘Stars and Stripes Forever’가 나오는 WAV 파일과 이메일을 받고 싶을 수도 있다.
하지만 사이트에 있지 않을 경우, 업무상 중요한 사람과의 식사 자리에 있을 때는 어떻게 해야 할까? 네트워크 모니터링 툴에는 ‘존 필립 소사가 사무실에 있는 모든 사람에게 도움을 요청한 후에도 웹 서버가 여전히 정상 가동 되지 않을 경우에는 따끈따끈한 프렌치 프라이가 도착하는 때에 맞춰 호출기 진동 댄스를 시작하라’는 식의 트리거가 있어야 한다. 이것을 필수 항목에 추가하라.