성능 관리: 모범 사례 백서

소개

성능 관리에는 네트워크 서비스 응답 시간의 최적화와 개별 및 전체 네트워크 서비스의 일관성 및 품질 관리가 포함됩니다. 가장 중요한 서비스는 사용자/애플리케이션 응답 시간을 측정할 필요성입니다. 대부분의 사용자에게 응답 시간은 중요한 성능 성공 요인입니다. 이 변수는 사용자와 애플리케이션 관리자 모두의 네트워크 성공에 대한 인식을 형성합니다.

배경 정보

용량 계획은 비즈니스 크리티컬 애플리케이션에 성능 또는 가용성이 미치는 영향을 방지하기 위해 미래의 네트워크 리소스에 대한 요구 사항을 결정하는 프로세스입니다. 용량 계획 영역에서 네트워크 베이스라인(CPU, 메모리, 버퍼, 입출력 옥텟 등)은 응답 시간에 영향을 줄 수 있습니다. 따라서 성능 문제는 용량과 관련이 있는 경우가 많습니다. 네트워크에서 이는 일반적으로 네트워크를 통해 전송되기 전에 대기열에서 기다려야 하는 대역폭 및 데이터입니다. 음성 애플리케이션에서는 지연 및 지터와 같은 요인이 음성 통화의 품질에 영향을 주기 때문에 이러한 대기 시간이 사용자에게 거의 확실히 영향을 미칩니다.

성능 관리를 복잡하게 만드는 또 다른 주요 문제는 높은 네트워크 가용성이 대기업 및 통신 사업자 네트워크 모두에 미션 크리티컬하지만 장기적으로 더 높은 비용을 감수하면서 단기간의 경제적 이익을 추구하는 경향이 있다는 것입니다. 모든 예산 주기 동안 네트워크 관리자와 프로젝트 구현 담당자는 성능과 빠른 구현 사이에서 균형을 찾는 데 어려움을 겪고 있습니다. 또한 네트워크 관리자는 좁은 시장 창, 복잡한 기술, 비즈니스 통합, 경쟁 시장, 예정에 없던 다운타임, 전문 지식 부족, 부족한 툴 등을 충족하기 위해 신속한 제품 개발 등의 과제에 직면하게 됩니다.

이러한 과제에 비추어 볼 때, 네트워크 관리 프레임워크에서 성능은 어떻게 적합합니까? 이상적인 네트워크 관리 시스템의 주요 기능은 네트워크의 운영 기능을 최적화하는 것입니다. 이를 네트워크 관리의 궁극적인 목표로 받아들이면 네트워크 관리의 핵심은 네트워크 운영을 최고의 성능으로 유지하는 것입니다.

이상적인 네트워크 관리 시스템에는 다음과 같은 기본 작업이 포함됩니다.

• 운영자에게 성능 저하가 임박했음을 알립니다.

• 성능 저하 또는 장애 발생 시 편리한 대체 라우팅 및 해결 방법을 제공합니다.

• 성능 저하 또는 장애의 원인을 정확히 찾아낼 수 있는 툴을 제공합니다.

• 네트워크 복원력 및 존속성을 위한 주 스테이션 역할을 합니다.

• 실시간으로 성능을 전달합니다.

이상적인 시스템에 대한 이 정의에 따르면 성능 관리는 네트워크 관리에 필수적입니다. 이러한 성능 관리 문제는 매우 중요합니다.

• 사용자 성능

• 애플리케이션 성능

• 용량 계획

• 사전 대응적 결함 관리

음성 및 비디오와 같은 최신 애플리케이션의 경우 성능이 성공의 핵심 변수이며 일관된 성능을 달성할 수 없는 경우 서비스가 낮은 가치로 간주되어 실패합니다. 경우에 따라 사용자는 간헐적인 애플리케이션 시간 초과로 인해 생산성과 사용자 만족도가 저하되는 다양한 성능을 겪게 됩니다.

이 문서에서는 중요한 성공 요인, 핵심 성과 지표, 성과 관리를 위한 상위 레벨 프로세스 맵 등 가장 중요한 성과 관리 문제를 자세히 설명합니다. 또한 가용성, 응답 시간, 정확성, 활용도, 용량 계획 등의 개념을 설명하고 성능 관리 및 이상적인 네트워크 관리 시스템에서 사전 대응적 오류 분석의 역할에 대해 간단히 설명합니다.

주요 성공 요인

주요 성공 요인은 구현 모범 사례에 대한 요구 사항을 식별합니다. 중요한 성공 요인으로 적합하려면 프로세스 또는 프로시저가 가용성을 향상시키거나 프로시저가 없으면 가용성이 저하되어야 합니다. 또한, 중요한 성공 요인은 측정 가능해야 조직에서 성공 범위를 결정할 수 있습니다.

참고: 자세한 내용은 성과 관리 지표를 참조하십시오.

다음은 성능 관리를 위한 중요한 성공 요소입니다.

• 네트워크 및 애플리케이션 데이터 모두에 대한 기준을 수집합니다.

• 네트워크 및 애플리케이션에 대한 가상 분석을 수행합니다.

• 용량 문제에 대한 예외 보고를 수행합니다.

• 모든 제안 또는 잠재적 네트워크 관리 서비스에 대한 네트워크 관리 오버헤드를 확인합니다.

• 용량 정보를 분석합니다.

• 네트워크 및 애플리케이션, 기준 및 예외 사항에 대한 용량 정보를 정기적으로 검토합니다.

• 업그레이드 또는 튜닝 절차를 설정하여 사후 대응적 및 장기적으로 용량 문제를 처리합니다.

성과 관리 지표

성과 지표는 조직이 중요한 성공 요인을 측정할 수 있는 메커니즘을 제공합니다. 성과 계획에 대한 성과 지표는 다음과 같습니다.

• 네트워크 관리 비즈니스 목표를 문서화합니다. 이는 네트워크 관리를 위한 공식적인 운영 개념이거나 필요한 기능 및 목표에 대한 덜 공식적인 설명이 될 수 있습니다.

• 상세하고 측정 가능한 서비스 수준 목표를 만듭니다.

• 서비스 레벨 계약에 대한 문서를 차트와 그래프로 제공하여 시간이 지남에 따라 이러한 계약이 어떻게 충족되는지 여부를 보여줍니다.

• 폴링 간격, 발생한 네트워크 관리 오버헤드, 가능한 트리거 임계값, 변수가 트랩에 대한 트리거로 사용되는지 여부, 각 변수에 대해 사용된 추세 분석 등 기준 요소에 대한 변수 목록을 수집합니다.

• 기본 및 추세 분석을 검토하는 정기 미팅을 갖습니다.

• what-if 분석 방법론이 문서화되었습니다. 여기에는 모델링과 검증이 포함되어야 합니다(해당하는 경우).

• 임계값이 초과되면 네트워크 리소스를 늘리는 데 사용된 방법론에 대한 문서를 개발하십시오. 문서화할 한 가지 항목은 추가 WAN 대역폭 및 비용 표를 입력하는 데 필요한 타임라인입니다.

성능 관리 프로세스 흐름

다음 단계에서는 성능 관리를 위한 대략적인 프로세스 흐름을 제공합니다.

1. 운영에 대한 네트워크 관리 개념 개발

   1. 필요한 기능을 정의합니다. 서비스, 확장성 및 가용성 목표

   2. 가용성 및 네트워크 관리 목표 정의

   3. 성능 SLA 및 메트릭 정의

   4. SLA 정의

2. 성과 측정

   1. 네트워크 기본 데이터 수집

   2. 가용성 측정

   3. 응답 시간 측정

   4. 정확도 측정

   5. 측정 사용률

   6. 용량 계획

3. 사전 대응적 결함 분석 수행

   1. 사전 대응적 장애 관리를 위한 임계값 사용

   2. 네트워크 관리 구현

   3. 네트워크 운영 메트릭

운영에 대한 네트워크 관리 개념 개발

네트워크에 대한 자세한 성능 및 용량 변수를 정의하기 전에 조직 내 네트워크 관리에 대한 전반적인 운영 개념을 살펴봐야 합니다. 이 전반적인 개념을 정의하면 네트워크에서 원하는 기능의 정확한 정의를 구축할 수 있는 비즈니스 기반을 제공합니다. 네트워크 관리를 위한 운영 개념을 개발하지 못하면 고객 요구로 인해 끊임없이 변화하는 목표나 목표가 부족해질 수 있습니다.

일반적으로 네트워크 관리 프로그램의 시스템 정의 단계의 첫 번째 단계로 네트워크 관리 운영 개념을 생성합니다. 운영 측면에서 원하는 시스템 특성을 전체적으로 설명하는 데 목적이 있습니다. 이 문서는 네트워크 운영, 엔지니어링, 설계, 기타 비즈니스 유닛 및 최종 사용자의 전반적인 비즈니스(비정량적) 목표를 조정하는 데 사용됩니다. 이 문서에서는 네트워크 관리 및 운영을 위한 광범위한 운영 계획 활동을 구성하는 데 중점을 둡니다. 또한 SLA(Service Level Agreement)와 같은 모든 후속 정의 문서 개발에 대한 지침을 제공합니다. 이러한 초기 정의 집합은 특정 네트워크 문제의 관리에 너무 집중해서는 안 되며, 전체 조직에 대한 중요성 및 관리해야 하는 비용과의 관계를 강조하는 항목에 집중해야 합니다. 몇 가지 목표는 다음과 같습니다.

• 네트워크 인프라를 효율적으로 사용하는 데 필수적인 특성을 파악합니다.

• 네트워크가 지원하는 서비스/애플리케이션을 식별합니다.

• 엔드 투 엔드 서비스 관리를 시작합니다.

• 전반적인 서비스를 개선하기 위해 성과 기반 메트릭을 시작합니다.

• 성과 관리 정보를 수집하고 배포합니다.

• 사용자의 피드백을 통해 네트워크의 전략적 평가를 지원합니다.

다시 말해, 운영의 네트워크 관리 개념은 전반적인 조직 목표와 이러한 목표를 달성하기 위한 여러분의 철학에 중점을 두어야 합니다. 주요 구성 요소는 임무, 임무 목표, 시스템 목표, 조직 참여 및 전반적인 운영 철학에 대한 상위 레벨 정의로 구성됩니다.

네트워크 관리자는 사용자의 성능 기대치를 일관되지 않게 통합할 수 있는 위치에 있습니다. 예를 들어, 네트워크의 기본 요구 사항이 한 위치에서 다른 위치로 대용량 파일을 전송하는 것이라면, 대화형 사용자의 응답 시간을 줄이고 처리량을 높이고자 할 것입니다. 다양한 문제를 고려하지 않는 한 성과에 대한 관점을 제한하지 않도록 주의하십시오. 예를 들어, 네트워크를 테스트할 때 사용되는 로드 레벨을 확인합니다. 로드는 종종 매우 작은 패킷과 매우 큰 패킷의 처리량을 기반으로 합니다. 이러한 성능 테스트 중 하나에서 매우 긍정적인 결과가 나올 수 있지만, 네트워크 트래픽 로드를 기준으로 테스트에서 실제 성능 결과가 나오지 않을 수 있습니다. 가능한 많은 워크로드 조건에서 네트워크 성능을 살펴보고 성능을 문서화하십시오.

또한 많은 네트워크 관리 조직에서 장치 고장에 대해 기술자에게 알리는 효과적인 알람 기술을 보유하고 있지만, 엔드 투 엔드 애플리케이션 성능을 위한 평가 프로세스를 정의하고 구현하기가 훨씬 더 어렵습니다. 따라서 NOC(Network Operations Center)는 다운된 라우터나 스위치에 신속하게 대응할 수 있지만, 네트워크 성능을 저하시키고 사용자 인식에 영향을 줄 수 있는 네트워크 상태는 그 인식이 나빠질 때까지 쉽게 알 수 없게 될 수 있습니다. 그러나 이 두 번째 프로세스는 어렵더라도 비즈니스 조직과 네트워크 관리 모두에게 막대한 혜택을 제공할 수 있습니다.

마지막으로, 네트워크 성능에 대한 비현실적인 기대를 유발하지 않도록 해야 합니다. 일반적으로 네트워킹 프로토콜이나 애플리케이션의 세부 사항을 오해할 때 비현실적인 기대치가 생성됩니다. 종종 성능이 떨어지는 것은 네트워크의 결함이 아니라 애플리케이션 설계가 제대로 이루어지지 않았기 때문입니다. 애플리케이션 성능을 문서화하고 측정하는 유일한 방법은 애플리케이션 설치 전에 네트워크 성능의 기준을 마련하는 것입니다.

필요한 기능을 정의합니다. 서비스, 확장성 및 가용성 목표

성능 관리, 연속 용량 계획 및 네트워크 설계의 첫 번째 단계는 필요한 기능 및/또는 서비스를 정의하는 것입니다. 이 단계에서는 애플리케이션, 기본 트래픽 흐름, 사용자 및 사이트 수, 필요한 네트워크 서비스를 이해해야 합니다. 이 정보의 첫 번째 활용은 조직의 목표에 대한 적용의 중요도를 결정하는 것이다. 또한 대역폭, 인터페이스, 연결, 컨피그레이션 및 물리적 디바이스 요구 사항을 파악하기 위해 논리적 설계에 사용할 지식 기반을 생성하기 위해 이 정보를 적용할 수 있습니다. 이 초기 단계를 통해 네트워크 설계자는 네트워크의 모델을 생성할 수 있습니다.

네트워크 엔지니어가 미래의 성장 요구 사항을 충족하는 네트워크를 설계하고 제안된 설계에서 네트워크의 성장이나 확장으로 인한 리소스 제약을 겪지 않도록 하기 위해 솔루션 확장성 목표를 설정합니다. 리소스 제약에는 다음이 포함될 수 있습니다.

• 전체 트래픽

• 볼륨

• 경로 수

• 가상 회로 수

• 네이버 수

• 브로드캐스트 도메인

• 장치 처리량

• 미디어 용량

네트워크 플래너는 설계 수명, 설계 수명 동안 필요한 예상 확장 또는 사이트, 신규 사용자 수, 예상 트래픽 양 또는 변경 사항을 결정해야 합니다. 이 계획은 제안된 솔루션이 설계 수명 동안 성장 요구 사항을 충족하도록 하는 데 도움이 됩니다.

솔루션 확장성을 조사하지 않을 경우, 주요 사후 대응적 설계 변경을 구현해야 할 수 있습니다. 이 설계 변경에는 추가 계층 구조, 미디어 업그레이드 또는 하드웨어 업그레이드가 포함될 수 있습니다. 대규모 하드웨어 구매에 상당히 정확한 예산 주기를 사용하는 조직에서는 이러한 변경이 전반적인 성공에 큰 걸림돌이 될 수 있습니다. 가용성의 관점에서 네트워크는 예기치 않은 리소스 제한을 경험할 수 있습니다. 이로 인해 가용성이 없거나 사후 조치가 취해지는 상황이 발생할 수 있습니다.

상호 운용성 및 상호 운용성 테스트는 새로운 솔루션 구축의 성공에 매우 중요한 역할을 할 수 있습니다. 상호운용성이란 서로 다른 하드웨어 공급업체 또는 네트워크 구현 중 또는 후에 서로 맞물려야 하는 서로 다른 토폴로지 또는 솔루션을 의미할 수 있습니다. 상호 운용성 문제에는 프로토콜 스택을 통해 라우팅 또는 전송 문제로 신호를 보내는 하드웨어가 포함될 수 있습니다. 네트워크 솔루션을 마이그레이션하기 전, 마이그레이션하는 동안 또는 마이그레이션한 후에 상호 운용성 문제가 발생할 수 있습니다. 상호 운용성 계획에는 서로 다른 디바이스 간의 연결 및 마이그레이션 중에 발생할 수 있는 토폴로지 문제가 포함되어야 합니다.

솔루션 비교는 다른 솔루션 요구 사항 관행과 관련하여 다른 잠재적 설계를 비교하는 관행입니다. 이러한 관행은 솔루션이 특정 환경에 가장 적합하고 개인적인 편견이 설계 프로세스를 좌우하지 않도록 하는 데 도움이 됩니다. 비교에는 비용, 복원력, 가용성, 위험, 상호운용성, 관리성, 확장성, 성능 등의 다양한 요인이 포함될 수 있습니다. 이러한 모든 기능은 설계가 구현되면 전체 네트워크 가용성에 큰 영향을 미칠 수 있습니다. 미디어, 계층 구조, 이중화, 라우팅 프로토콜 및 유사한 기능도 비교할 수 있습니다. 솔루션 비교를 요약하기 위해 X축에 요인과 Y축 도움말에 잠재적 솔루션을 포함하는 차트를 만듭니다. 랩 환경에서 세부적인 솔루션 비교는 서로 다른 비교 요소와 관련하여 새로운 솔루션과 기능을 객관적으로 조사하는 데도 도움이 됩니다.

네트워크 관리 운영 개념의 일환으로 모든 사용자가 이해할 수 있는 방식으로 네트워크 및 지원 서비스의 목표를 정의하는 것이 중요합니다. 운영 개념의 개발에 따르는 활동은 해당 문서의 품질에 크게 영향을 받습니다.

다음은 표준 성능 목표입니다.

• 응답 시간

• 사용률

• 처리량

• 용량(최대 처리량 속도)

이러한 측정은 단순한 LAN의 경우 사소한 것일 수 있지만, 스위치드 캠퍼스 네트워크 또는 멀티벤더 엔터프라이즈 네트워크에서는 매우 어려울 수 있습니다. 운영 계획에 대한 잘 짜여진 개념을 사용할 때 각 성과 목표는 측정 가능한 방법으로 정의됩니다. 예를 들어 애플리케이션 "x"에 대한 최소 응답 시간은 최대 업무 시간 동안 500Ms 이하입니다. 이는 변수를 식별하기 위한 정보, 변수를 측정하는 방법, 네트워크 관리 애플리케이션이 집중해야 하는 기간을 정의합니다.

가용성 및 네트워크 관리 목표 정의

가용성 목표는 네트워크 서비스에 대한 서비스 수준 또는 서비스 수준 요구 사항을 정의합니다. 따라서 솔루션이 최종 가용성 요구 사항을 충족할 수 있습니다. 특정 조직에 대해 서로 다른 서비스 클래스를 정의하고 가용성 요구 사항에 적합한 각 클래스에 대한 네트워크 요구 사항을 자세히 설명합니다. 네트워크의 영역마다 다른 수준의 가용성도 필요할 수 있습니다. 가용성 목표가 높을수록 이중화 및 지원 절차가 강화되어야 할 수 있습니다. 특정 네트워크 서비스에 대한 가용성 목표를 정의하고 가용성을 측정할 때 네트워크 조직은 예상 SLA를 달성하는 데 필요한 구성 요소 및 서비스 수준을 이해할 수 있습니다.

전반적인 네트워크 관리에 관리 기능이 부족하지 않도록 관리 용이성 목표를 정의합니다. 관리 용이성 목표를 설정하려면 조직의 지원 프로세스 및 관련 네트워크 관리 툴을 이해해야 합니다. 관리 용이성 목표에는 현재의 지원 및 툴 모델에 새로운 솔루션이 어떻게 적합한지, 그리고 잠재적 차이점이나 새로운 요구 사항에 대한 언급이 포함되어야 합니다. 이는 새로운 솔루션을 지원할 수 있는 역량이 구축 성공과 가용성 목표 충족에 가장 중요하기 때문에 네트워크 가용성에 매우 중요합니다.

관리 용이성 목표에서는 잠재적 네트워크 지원에 필요한 모든 중요한 MIB 또는 네트워크 툴 정보, 새로운 네트워크 서비스 지원에 필요한 교육, 새로운 서비스에 대한 직원 채용 모델 및 기타 지원 요구 사항을 밝혀야 합니다. 구축 전에는 이러한 정보를 파악할 수 없는 경우가 많으며, 새로운 네트워크 설계를 지원하기 위해 할당된 리소스가 부족하여 전반적인 가용성이 저하되는 경우가 많습니다.

성능 SLA 및 메트릭 정의

성능 SLA와 메트릭을 통해 새로운 네트워크 솔루션의 성능을 정의하고 측정하여 성능 요구 사항을 충족할 수 있습니다. 제안된 솔루션의 성능은 성능 모니터링 툴 또는 제안된 네트워크 인프라 전체에서 간단한 ping으로 측정할 수 있습니다. 성능 SLA에는 평균 예상 트래픽 볼륨, 최대 트래픽 볼륨, 평균 응답 시간, 허용되는 최대 응답 시간이 포함되어야 합니다. 이 정보는 나중에 솔루션 검증 섹션에서 사용할 수 있으며, 궁극적으로 네트워크의 필요한 성능 및 가용성을 확인하는 데 도움이 됩니다.

SLA 정의

네트워크 설계의 중요한 측면은 사용자 또는 고객을 위한 서비스를 정의할 때입니다. 기업은 이러한 서비스 수준 계약을 서비스 공급업체는 서비스 수준 관리라고 부르지만, 서비스 수준 관리에는 일반적으로 문제 유형 및 심각도와 헬프 데스크 책임에 대한 정의가 포함됩니다. 여기에는 각 계층 지원 수준에서 에스컬레이션 경로 및 에스컬레이션 전 시간, 문제에 대한 작업 시작 시간, 우선 순위에 따라 대상을 닫는 시간 등이 포함됩니다. 용량 계획, 사전 대응적 장애 관리, 변경 관리 알림, 임계값, 업그레이드 기준, 하드웨어 교체 영역에서 제공되는 서비스도 중요한 요인입니다.

서비스 수준을 미리 정의하지 않으면 나중에 파악되는 리소스 요구 사항을 개선하거나 확보하기가 어려워집니다. 또한 네트워크를 지원하기 위해 어떤 리소스를 추가해야 하는지 파악하기가 어려워집니다. 많은 경우 이러한 리소스는 문제가 발견된 후에만 적용됩니다.

성과 측정

성능 관리는 고유한 성능 영역의 구성과 측정을 통합하는 포괄적 용어입니다. 이 섹션에서는 다음 6가지 성능 관리 개념에 대해 설명합니다.

• 네트워크 기본 데이터 수집

• 가용성 측정

• 응답 시간 측정

• 정확도 측정

• 측정 사용률

• 용량 계획

네트워크 기본 데이터 수집

대부분의 기업 인트라넷은 충분한 대역폭을 가지고 있습니다. 그러나 적절한 데이터가 없으면 애플리케이션 성능 저하의 원인이 되는 네트워크 혼잡을 배제할 수 없을 수도 있습니다. 혼잡이나 오류의 단서는 성능 저하가 간헐적이거나 시간대에 따라 달라지는 경우입니다. 이러한 상황의 예로는 저녁 늦게 성능이 충분하지만 아침 및 피크 업무 시간에는 매우 느리다는 것을 들 수 있습니다.

운영의 네트워크 관리 개념을 정의하고 필요한 구현 데이터를 정의한 후에는 시간이 지남에 따라 이 데이터를 수집해야 합니다. 이 컬렉션 유형은 네트워크 베이스라인의 기초가 됩니다.

새 솔루션(애플리케이션 또는 IOS 변경) 구축 이전 및 구축 이후에 현재 네트워크의 기준을 적용하여 새 솔루션에 대해 설정된 기대치를 측정합니다. 이 기준을 통해 솔루션이 성능 및 가용성 목표와 벤치마크 용량을 충족하는지 확인할 수 있습니다. 일반적인 라우터/스위치 기본 보고서에는 CPU, 메모리, 버퍼 관리, 링크/미디어 활용 및 처리량과 관련된 용량 문제가 포함됩니다. 운영 개념에 정의된 목표에 따라 다른 유형의 베이스라인 데이터도 포함할 수 있습니다. 예를 들어, 가용성 기준선은 네트워크 환경의 안정성/가용성이 향상됨을 보여줍니다. 솔루션 요구 사항을 검증하기 위해 기존 환경과 신규 환경을 기준 비교합니다.

애플리케이션 네트워크 요구 사항을 트렌드할 때 유용한 애플리케이션 베이스라인도 특수한 기준을 제시합니다. 이 정보는 업그레이드 주기에서 청구 및/또는 예산 책정 용도로 사용할 수 있습니다. 애플리케이션 베이스라인은 또한 선호하는 서비스 또는 애플리케이션당 서비스 품질과 관련하여 애플리케이션 가용성의 영역에서 중요할 수 있습니다. 애플리케이션 기본 정보는 주로 기간당 애플리케이션에서 사용하는 대역폭으로 구성됩니다. 일부 네트워크 관리 애플리케이션은 애플리케이션 성능의 기준도 정할 수 있습니다. 트래픽 유형(텔넷 또는 FTP)의 분석도 계획에 중요합니다. 일부 조직에서는 상위 토커를 위해 네트워크의 더 중요한 리소스 제한 영역을 모니터링합니다. 네트워크 관리자는 이 정보를 사용하여 네트워크를 예산 책정, 계획 또는 조정할 수 있습니다. 네트워크를 조정할 때 네트워크 서비스 또는 애플리케이션에 대한 서비스 품질 또는 대기열 매개변수를 수정할 수 있습니다.

가용성 측정

네트워크 관리자가 사용하는 주요 메트릭 중 하나는 가용성입니다. 가용성은 사용자가 네트워크 시스템 또는 애플리케이션을 사용할 수 있는 시간의 측정치입니다. 네트워크 관점에서 가용성은 네트워크의 개별 구성 요소의 신뢰성을 나타냅니다.

예를 들어 가용성을 측정하기 위해 헬프 데스크 전화 통화를 관리되는 디바이스에서 수집된 통계와 조정할 수 있습니다. 그러나 가용성 툴이 모든 실패 이유를 확인할 수는 없습니다.

가용성을 측정할 때 고려해야 할 또 다른 요소는 네트워크 이중화입니다. 이중화 손실은 전체 네트워크 장애가 아닌 서비스 저하를 나타냅니다. 그 결과 응답 시간이 느려지고 삭제된 패킷으로 인한 데이터 손실이 발생할 수 있습니다. 활용도와 응답시간 등 다른 성과측정 영역에서도 결과가 나타날 가능성이 있다.

마지막으로, SLA를 준수하는 경우 예약된 중단을 고려해야 합니다. 이러한 중단은 이동, 추가 및 변경, 공장 가동 중단 또는 보고하지 않을 수 있는 기타 이벤트의 결과일 수 있습니다. 이는 어려운 작업일 뿐만 아니라 수작업 작업일 수도 있다.

응답 시간 측정

네트워크 응답 시간은 트래픽이 두 지점 사이를 이동하는 데 필요한 시간입니다. 기본 비교를 통해 표시되거나 임계값을 초과하는 일반적인 응답 시간보다 느린 응답 시간은 정체 또는 네트워크 장애를 나타낼 수 있습니다.

응답 시간은 고객 네트워크 사용을 측정하는 가장 좋은 기준이며 네트워크의 효율성을 측정하는 데 도움이 될 수 있습니다. 반응이 느린 원인이 무엇이든지 간에, 사용자는 지연된 트래픽 때문에 좌절하게 됩니다. 분산형 네트워크에서 응답 시간에 영향을 주는 요인은 다음과 같습니다.

• 네트워크 혼잡

• 대상에 대한 바람직한 경로 미만(또는 경로 없음)

• 전력이 부족한 네트워크 장치

• 브로드캐스트 스톰과 같은 네트워크 결함

• 노이즈 또는 CRC 오류

QoS 관련 대기를 사용하는 네트워크에서는 올바른 유형의 트래픽이 예상대로 네트워크를 통해 이동하는지 확인하기 위해 응답 시간 측정이 중요합니다. 예를 들어, IP 네트워크를 통해 음성 트래픽을 구현할 때 음성 패킷이 적시에 일정한 속도로 전달되어야 우수한 음성 품질을 유지할 수 있습니다. 사용자에게 표시되는 트래픽의 응답 시간을 측정하기 위해 음성 트래픽으로 분류된 트래픽을 생성할 수 있습니다.

애플리케이션 서버와 네트워크 관리자 간의 충돌을 해결하기 위해 응답 시간을 측정할 수 있습니다. 네트워크 관리자는 애플리케이션 또는 서버가 느리게 보일 경우 종종 유죄로 추정됩니다. 네트워크 관리자는 네트워크가 문제가 아니라는 것을 증명해야 합니다. 응답 시간 데이터 수집은 네트워크가 애플리케이션 문제의 원인임을 입증하거나 반박할 수 있는 명백한 수단을 제공합니다.

가능한 경우 사용자에게 표시되는 응답 시간을 측정해야 합니다. 사용자는 Enter 키를 누르거나 버튼을 클릭할 때부터 화면이 표시될 때까지의 시간을 응답이라고 인식합니다. 이 경과 시간은 각 네트워크 디바이스, 사용자 워크스테이션 및 목적지 서버가 트래픽을 처리하는 데 필요한 시간을 포함합니다.

안타깝게도 이 수준에서의 측정은 사용자 수와 도구 부족으로 인해 거의 불가능하다. 또한 사용자 및 서버 응답 시간을 통합할 경우 향후 네트워크 확장 또는 네트워크 문제 해결을 결정할 때 거의 도움이 되지 않습니다.

네트워크 디바이스 및 서버를 사용하여 응답 시간을 측정할 수 있습니다. 상위 레이어에서 처리할 때 시스템에 유입되는 지연을 고려하지 않지만 ICMP와 같은 도구를 사용하여 트랜잭션을 측정할 수도 있습니다. 이러한 접근 방식은 네트워크 성능 지식의 문제를 해결합니다.

간소화된 수준에서 응답 시간을 측정하기 위해 네트워크 관리 스테이션에서 네트워크의 주요 지점(예: 메인프레임 인터페이스, 서비스 공급자 연결의 엔드포인트 또는 키 사용자 IP 주소)으로 ping에 응답하는 시간을 설정할 수 있습니다. 이 방법의 문제는 그것이 그들의 기계와 목적지 기계 사이의 응답 시간에 대한 사용자 인식을 정확하게 반영하지 않는다는 것입니다. 단순히 네트워크 관리 스테이션 관점에서 정보를 수집하고 응답 시간을 보고합니다. 이 방법은 또한 네트워크 전체에서 홉별로 응답 시간 문제를 마스킹합니다.

서버 중심 폴링의 대안은 측정을 위해 시뮬레이트할 소스와 대상에 더 가깝게 작업량을 분산하는 것입니다. 분산 네트워크 관리 폴러를 사용하고 Cisco IOS SAA(Service Assurance Agent) 기능을 구현합니다. 라우터와 대상 디바이스(예: 서버 또는 다른 라우터) 간의 응답 시간을 측정하기 위해 라우터에서 SAA를 활성화할 수 있습니다. 또한 TCP 또는 UDP 포트를 지정할 수 있습니다. 이 포트는 시뮬레이션하는 트래픽과 동일한 방식으로 트래픽을 전달 및 안내하도록 강제합니다.

다중 서비스 네트워크에 음성, 비디오 및 데이터가 통합됨에 따라 고객은 네트워크에서 QoS 우선순위 지정을 구현합니다. 서로 다른 애플리케이션이 서로 다른 우선순위를 받기 때문에 간단한 ICMP 또는 UDP 측정은 응답 시간을 정확하게 반영하지 못합니다. 또한 태그 스위칭의 경우 트래픽 라우팅은 특정 패킷에 포함된 애플리케이션 유형에 따라 달라질 수 있습니다. 따라서 ICMP ping은 각 라우터가 처리하는 우선 순위가 다를 수 있으며 효율성이 떨어지는 다른 경로를 받을 수 있습니다.

이 경우 응답 시간을 측정하는 유일한 방법은 특정 애플리케이션 또는 관련 기술과 유사한 트래픽을 생성하는 것입니다. 이렇게 하면 네트워크 디바이스에서 실제 트래픽과 마찬가지로 트래픽을 처리해야 합니다. SAA를 사용하거나 타사 애플리케이션 인식 프로브를 사용하여 이 수준을 달성할 수 있습니다.

정확도 측정

정확도는 오류가 발생하지 않는 인터페이스 트래픽의 측정값이며 일정 기간 동안의 총 패킷 속도와 성공률을 비교하는 백분율로 나타낼 수 있습니다. 먼저 오류 비율을 측정해야 합니다. 예를 들어, 100개 패킷 중 2개에서 오류가 발생할 경우 오류율은 2%이고 정확도는 98%입니다.

초기의 네트워크 기술, 특히 광범위한 영역에서 일정 수준의 오류가 허용되었습니다. 그러나 고속 네트워크와 현재 WAN 서비스를 사용할 경우, 전송 정확도가 상당히 높아지고, 실제 문제가 없는 한 오류율은 0에 가깝습니다. 인터페이스 오류의 몇 가지 일반적인 원인은 다음과 같습니다.

• 규격 외 배선

• 전기 방해

• 결함이 있는 하드웨어 또는 소프트웨어

정확도가 낮아져 더 면밀한 조사가 이루어집니다. 특정 인터페이스에 문제가 있음을 발견하고 오류를 허용할 수 있다고 결정할 수 있습니다. 이 경우 오류 비율이 허용되지 않는 위치를 반영하려면 이 인터페이스에 대한 정확도 임계값을 조정해야 합니다. 허용할 수 없는 오류 비율은 이전 기준에서 보고되었을 수 있습니다.

이 표에 설명된 변수는 정확도 및 오류율 공식에 사용됩니다.

표기법	설명
ΔifIn오류	snmp ifInErrors 객체를 수집하는 두 폴링 주기의 델타(또는 차이). 이는 오류가 있는 인바운드 패킷의 수를 나타냅니다.
ΔifInUcast패킷	인바운드 유니캐스트 패킷의 수를 나타내는 snmp ifInUcastPkts 개체를 수집하는 두 폴링 주기 간의 델타입니다.
ΔifInNUcastPkt	snmp ifInNUcastPkts 객체를 수집하는 두 폴링 주기 간의 델타입니다. 이는 인바운드 비 유니캐스트 패킷(멀티캐스트 및 브로드캐스트)의 수를 나타냅니다.

오류 비율 공식은 일반적으로 백분율로 표시됩니다.

오류 비율 = (ΔifInErrors) *100

-------------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts )

아웃바운드 오류는 오류율 및 정확도 공식에서 고려되지 않습니다. 디바이스가 오류가 있는 패킷을 네트워크에 의도적으로 배치해서는 안 되며, 아웃바운드 인터페이스 오류율이 증가해서는 안 되기 때문입니다. 따라서 인바운드 트래픽과 오류가 인터페이스 오류와 정확성에 대한 유일한 측정치입니다.

정확도 공식은 오차율을 가져와서 100에서 뺍니다(다시 백분율 형식).

정확도 = 100 - (ΔifInErrors) *100

-----------------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts))

이러한 수식은 MIB II 인터페이스(RFC 2233) 일반 카운터의 관점에서 오류와 정확성을 반영합니다. 이 결과는 오류를 보고 보낸 총 패킷과 비교하는 백분율로 표시됩니다. 결과의 오류율은 100에서 차감되어 정확률이 산출됩니다. 정확도 100%는 완벽합니다.

MIB II 변수는 카운터로 저장되므로 두 개의 폴링 주기를 취하고 둘 사이의 차이를 계산해야 합니다(따라서 방정식에 사용되는 델타).

측정 사용률

활용률은 시간에 따른 특정 리소스의 사용을 측정합니다. 이 측정값은 일반적으로 리소스의 사용량을 최대 운영 용량과 비교하는 백분율 형식으로 표시됩니다. 활용 측정을 통해 네트워크 전체의 혼잡(또는 잠재적인 혼잡)을 식별할 수 있습니다. 활용도가 낮은 리소스를 식별할 수도 있습니다.

활용은 네트워크 파이프(링크)의 전체 용량을 결정하는 기본 측정값입니다. 네트워크 시스템 리소스가 소비되는 범위를 확인하기 위해 CPU, 인터페이스, 대기 및 기타 시스템 관련 용량 측정을 측정합니다.

높은 활용도가 반드시 나쁜 것만은 아닙니다. 사용률이 낮으면 예기치 않은 위치의 트래픽 흐름을 나타낼 수 있습니다. 선이 과용되면서 그 효과는 엄청날 수 있다. 초과 사용률은 인터페이스를 통과하기 위해 대기열에 있는 트래픽이 처리할 수 있는 것보다 많을 때 발생합니다. 리소스 사용률이 갑자기 증가하면 결함 조건이 나타날 수 있습니다.

인터페이스가 혼잡해지면 네트워크 디바이스는 패킷을 큐에 저장하거나 버려야 합니다. 라우터가 패킷을 전체 대기열에 저장하려고 시도하면 패킷이 삭제됩니다. 고속 인터페이스에서 저속 인터페이스로 트래픽이 전달될 때 삭제된 패킷이 발생합니다. 이는 Q = u / (1-u)의 공식에 표시되며 여기서 u는 사용률이고 Q는 평균 대기열 깊이(임의 트래픽으로 가정됨)입니다. 따라서 링크의 사용률이 높으면 평균 대기열 깊이가 높아지며, 패킷 크기를 알고 있는 경우 지연 시간을 예측할 수 있습니다. 일부 네트워크 보고 공급업체는 주문하는 대역폭이 줄어들고 WAN에 대한 비용이 줄어들 수 있다고 말합니다. 그러나 WAN 링크를 95% 사용률로 실행하면 지연 시간이 나타납니다. 또한 네트워크가 VoIP로 마이그레이션됨에 따라 네트워크 관리자가 정책을 변경하고 WAN 링크를 약 50% 사용률로 실행해야 할 수도 있습니다.

패킷이 삭제되면 상위 계층 프로토콜에서 패킷을 강제로 재전송할 수 있습니다. 여러 패킷이 삭제되면 과도한 재시도 트래픽이 발생할 수 있습니다. 이러한 유형의 반응으로 인해 디바이스의 백업이 더 지연될 수 있습니다. 이 문제를 해결하려면 임계값의 정도를 다르게 설정할 수 있습니다.

네트워크 사용률에 사용되는 기본 측정값은 인터페이스 사용률입니다. 측정하는 연결이 반이중인지 전이중인지를 기준으로 이 표에 설명된 공식을 사용합니다.

표기법	설명
ΔifInOctets	snmp ifInOctets 개체를 수집하는 두 폴링 주기 간의 델타(또는 차이). 이는 트래픽의 인바운드 옥텟 수를 나타냅니다.
ΔifOutOctets	트래픽의 아웃바운드 옥텟 수를 나타내는 snmp ifOutOctets 객체를 수집하는 두 폴링 주기 간의 델타입니다.
if속도	snmp ifSpeed 객체에 보고된 인터페이스의 속도. ifSpeed는 WAN 인터페이스의 속도를 정확하게 반영하지 않을 수 있습니다.

공유 LAN 연결은 주로 하프 듀플렉스(half-duplex) 경향이 있습니다. 경합 탐지를 수행하려면 디바이스가 전송되기 전에 수신해야 하기 때문입니다. WAN 연결은 포인트-투-포인트 연결이므로 일반적으로 풀 듀플렉스(full duplex)입니다. 두 디바이스는 연결을 공유하는 다른 디바이스가 하나뿐이라는 것을 알기 때문에 동시에 송수신이 가능합니다.

MIB II 변수는 카운터로 저장되므로 두 개의 폴링 주기를 취하고 둘 사이의 차이를 계산해야 합니다(따라서 방정식에 사용되는 델타).

반이중 미디어의 경우 인터페이스 사용률에 다음 공식을 사용합니다.

(ΔifInOctets + ΔifOutOctets) * 8 * 100

----------------------------------------------------

(초 단위: Δ) * ifSpeed

전이중 미디어의 경우 사용률 계산이 더 복잡합니다. 예를 들어, T-1 직렬 연결을 풀 경우 회선 속도는 1.544Mbps입니다. 즉, T-1 인터페이스는 3.088Mbps의 결합 가능한 대역폭에 대해 1.544Mbps를 수신하고 전송할 수 있습니다.

전이중 연결에 대한 인터페이스 대역폭을 계산할 때 입력 및 출력 값 중 큰 값을 가져와 사용률을 생성하는 다음 공식을 사용할 수 있습니다.

max(ΔifInOctets, (ΔifOutOctets) * 8 * 100

-----------------------------------------

(초 단위: Δ) * ifSpeed

그러나 이 방법은 값이 더 작은 방향의 활용을 숨기고 덜 정확한 결과를 제공한다. 보다 정확한 방법은 다음과 같이 입력 사용률과 출력 사용률을 각각 측정하는 것입니다.

입력 사용률 = ΔifInOctets *8 * 100

-------------------------------------

(초 단위: Δ) * ifSpeed

및

출력 사용률 = ΔifOutOctets *8 * 100

------------------------------------

(초 단위: Δ) * ifSpeed

이러한 공식은 다소 간단하지만 특정 프로토콜과 관련된 오버헤드를 고려하지 않습니다. 각 프로토콜의 고유한 측면을 처리하기 위해 더 정확한 공식이 존재한다. 예를 들어, RFC 1757에는 패킷 오버헤드를 고려한 이더넷 활용 공식이 포함되어 있습니다. 그러나 고가용성 팀은 여기에 제시된 일반 공식을 대부분의 경우 LAN 및 WAN 인터페이스 모두에서 안정적으로 사용할 수 있다는 사실을 발견했습니다.

용량 계획

앞서 설명한 것처럼 용량 계획은 비즈니스 크리티컬 애플리케이션에 성능 또는 가용성이 미치는 영향을 방지하기 위해 미래의 네트워크 리소스 요구 사항을 결정하는 프로세스입니다. 용량 및 성능 관리를 참조하십시오. 이 주제에 대한 자세한 내용은 Best Practices 백서를 참조하십시오.

사전 대응적 결함 분석 수행

사전 대응적 결함 분석은 성능 관리에 필수적입니다. 성능 관리를 위해 수집된 동일한 유형의 데이터를 사전 대응적 오류 분석에 사용할 수 있습니다. 그러나 사전 대응적 장애 관리와 성능 관리는 이 데이터의 사용 시기와 용도가 다릅니다.

사전 대응적 장애 관리는 이상적인 네트워크 관리 시스템이 사용자가 결정한 목표를 달성할 수 있는 방법입니다. 성과 관리와의 관계는 사용하는 기준 및 데이터 변수를 통해 이루어집니다. 사전 대응적 장애 관리 기능은 맞춤화된 이벤트, 이벤트 상관관계 엔진, 장애 발권 및 기본 데이터의 통계 분석을 통합하여 이상적이고 효과적인 네트워크 관리 시스템에서 장애, 성능 및 변경 관리를 통합합니다.

성능 데이터 폴링이 일반적으로 10분, 15분 또는 30분마다 수행되는 경우, 결함 상태를 인식하는 시간이 훨씬 짧아야 합니다. 사전 대응적 결함 관리 방법 중 하나는 RMON 경보 및 이벤트 그룹을 사용하는 것입니다. 외부 디바이스에서 폴링하지 않는 디바이스에 임계값을 설정하여 임계값이 훨씬 짧아지도록 할 수 있습니다. 이 문서에서는 다루지 않는 또 다른 방법은 관리자의 데이터를 취합하여 로컬 수준에서 폴링할 수 있도록 하는 분산 관리 시스템을 사용하는 것입니다.

사전 대응적 장애 관리를 위한 임계값 사용

임계값은 특정 데이터 스트림에서 관심 지점을 정의하고 임계값이 트리거될 때 이벤트를 생성하는 프로세스입니다. 네트워크 성능 데이터를 사용하여 이러한 임계값을 설정합니다.

임계값의 유형은 여러 가지가 있으며, 그중 일부는 특정 데이터 유형에 더 적합합니다. 임계값은 숫자 데이터에만 적용할 수 있으므로 텍스트 데이터를 개별 숫자 값으로 변환합니다. 개체에 사용할 수 있는 모든 텍스트 문자열을 알지 못하는 경우에도 "흥미로운" 문자열을 열거하고 다른 모든 문자열을 설정된 값에 할당할 수 있습니다.

두 개의 숫자 데이터 클래스에 대한 두 가지 임계값 클래스가 있습니다. 연속 및 개별. 연속 임계값은 SNMP 카운터 또는 게이지에 저장된 데이터와 같은 연속 또는 시계열 데이터에 적용됩니다. 불연속 임계값은 열거 객체 또는 불연속 숫자 데이터에 적용됩니다. 부울 객체는 두 개의 값으로 열거되는 값입니다. 참 또는 거짓. 이산형 데이터는 이벤트가 한 값에서 다음 값으로의 전환을 나타내기 때문에 이벤트 데이터라고도 할 수 있다.

연속 임계값은 시계열 객체가 임계값의 지정된 값을 초과할 때 이벤트를 트리거할 수 있습니다. 개체 값이 임계값을 초과하거나 임계값 아래로 떨어집니다. 상승 임계값과 하강 임계값을 따로 설정하는 것도 유용할 수 있다. 히스테리시스 메커니즘으로 알려진 이 기술은 이 데이터 클래스에서 발생하는 이벤트의 수를 줄이는 데 도움이 됩니다. 히스테리시스 메커니즘은 빠르게 변하는 시계열 데이터에 대한 임계값에 의해 생성되는 이벤트의 볼륨을 감소시키도록 작동한다. 이 메커니즘은 시계열 데이터에 대한 임의의 임계 기법과 함께 사용될 수 있다.

이벤트의 볼륨은 객체의 값을 추적하기 위해 생성되는 경보에 의해 감소됩니다. 이 경보에 상승 및 하강 임계값이 할당됩니다. 경보는 상승 임계값이 초과된 경우에만 트리거됩니다. 일단 이 임계값이 초과되면, 상승 경보는 하강 임계값이 초과될 때까지 다시 생성되지 않는다. 그리고 동일한 메커니즘이 상승 임계값이 다시 넘어갈 때까지 하강 임계값의 발생을 방지한다. 이 메커니즘은 이벤트의 볼륨을 크게 줄일 수 있으며 결함이 있는지 확인하기 위해 필요한 정보를 제거하지는 않습니다.

시계열 데이터는 각 새 데이터 포인트가 이전 데이터 포인트의 합에 추가되는 카운터로 또는 데이터가 시간 간격에 따른 속도로 표시되는 게이지로 표시될 수 있습니다. 각 데이터 유형에 적용할 수 있는 두 가지 유형의 연속 임계값이 있습니다. 절대 연속 임계값 및 상대 연속 임계값. 게이지와 함께 절대 연속 임계값을 사용하고 카운터와 함께 상대 연속 임계값을 사용합니다.

네트워크의 임계값을 결정하려면 다음 단계를 완료하십시오.

1. 객체를 선택합니다.

2. 디바이스 및 인터페이스를 선택합니다.

3. 각 객체 또는 객체/인터페이스 유형에 대한 임계값을 결정합니다.

4. 각 임계값에 의해 생성된 이벤트의 심각도를 결정합니다.

어떤 객체(어떤 디바이스 및 인터페이스)에 어떤 임계값을 사용할지 결정하려면 상당한 양의 작업이 필요합니다. 다행히도 성능 데이터의 기준점을 수집했다면 이미 상당한 양의 작업을 수행했습니다. 또한 NSA와 HAS(High Availability Service) 프로그램은 개체를 설정하고 범위를 생성하는 데 도움이 되는 권장 사항을 제공할 수 있습니다. 그러나 이러한 권장 사항을 특정 네트워크에 맞게 조정해야 합니다.

네트워크에 대한 성능 데이터를 수집했으므로 HAS 프로그램은 인터페이스를 범주별로 그룹화할 것을 권장합니다. 이렇게 하면 각 카테고리의 미디어 유형에 대한 임계값을 해당 디바이스의 각 디바이스 및 객체에 대해 결정하지 않고 결정해야 할 수 있으므로 임계값 설정이 간소화됩니다. 예를 들어 이더넷 및 FDDI 네트워크에 대해 서로 다른 임계값을 설정하고자 할 수 있습니다. 일반적으로 공유 이더넷 세그먼트보다 활용률이 100%에 가까운 FDDI 네트워크를 실행할 수 있다고 생각합니다. 그러나 전이중 이더넷은 충돌의 영향을 받지 않기 때문에 사용률이 100%에 훨씬 가깝게 실행될 수 있습니다. 충돌을 절대 볼 수 없으므로 전이중 링크에 대해 충돌에 대한 임계값을 매우 낮게 설정할 수 있습니다.

또한 인터페이스 중요도와 임계값 유형의 범주/심각도의 조합을 고려할 수 있습니다. 이러한 요소를 사용하여 이벤트의 우선순위를 설정하고, 따라서 이벤트의 중요성과 네트워크 운영 직원의 주의를 설정합니다.

네트워크 디바이스 및 인터페이스의 그룹화 및 분류는 아무리 강조해도 지나치지 않습니다. 더 많이 그룹화하고 분류할 수 있을수록 임계값 이벤트를 네트워크 관리 플랫폼에 더 쉽게 통합할 수 있습니다. 이 정보에 대한 기본 리소스로 베이스라인을 사용합니다. 용량 및 성능 관리를 참조하십시오. Best Practices 백서를 참조하십시오.

네트워크 관리 구현

조직에는 정의된 임계값을 탐지하고 지정된 기간의 값을 보고할 수 있는 네트워크 관리 시스템이 구현되어야 합니다. 매일 검토할 수 있도록 로그 파일에 임계값 메시지를 보관할 수 있는 RMON 네트워크 관리 시스템을 사용하거나, 지정된 매개변수에 대한 임계값 예외를 검색할 수 있도록 하는 보다 완벽한 데이터베이스 솔루션을 사용합니다. 이 정보는 네트워크 운영 직원과 관리자가 지속적으로 사용할 수 있어야 합니다. 네트워크 관리 구현에는 소프트웨어/하드웨어 크래시 또는 역추적, 인터페이스 신뢰성, CPU, 링크 사용률, 대기열 또는 버퍼 누락, 브로드캐스트 볼륨, 캐리어 전환, 인터페이스 재설정을 탐지하는 기능이 포함되어야 합니다.

네트워크 운영 메트릭

성능 관리와 중복되는 사전 대응적 장애 관리의 최종 영역은 네트워크 운영 메트릭입니다. 이러한 메트릭은 결함 관리 프로세스 개선에 유용한 데이터를 제공합니다. 최소한 이러한 메트릭은 지정된 기간 동안 발생한 모든 문제의 분석을 포함해야 합니다. 분류 내용에는 다음과 같은 정보가 포함되어야 합니다.

• 통화 우선순위에 의해 발생한 문제 수

• 각 우선 순위에서 마감 최소, 최대 및 평균 시간

• 문제 유형별 문제 분석(하드웨어, 소프트웨어 충돌, 구성, 전원, 사용자 오류)

• 각 문제 유형에 대한 마감 시간 분석

• 가용성 그룹 또는 SLA별 가용성

• SLA 요구 사항을 충족하거나 충족하지 못한 빈도

헬프 데스크에는 메트릭 또는 보고서를 생성할 수 있는 보고 시스템이 있는 경우가 많습니다. 이 데이터를 수집하는 또 다른 방법은 가용성 모니터링 툴을 사용하는 것입니다. 전체 메트릭스는 월별로 이용 가능해야 합니다. 누락된 서비스 수준 계약 요구 사항을 개선하거나 특정 문제 유형의 처리 방법을 개선하기 위해 논의를 기반으로 한 프로세스 개선을 구현해야 합니다.

성과 관리 지표

성과 지표는 조직이 중요한 성공 요인을 측정하는 메커니즘을 제공합니다.

네트워크 관리 비즈니스 목표 문서화

이 문서는 네트워크 관리를 위한 운영의 공식 개념이거나 필요한 기능 및 목표에 대한 덜 공식적인 설명이 될 수 있습니다. 그러나 이 문서는 네트워크 관리자가 성공 여부를 평가하는 데 도움이 됩니다.

이 문서는 조직 네트워크 관리 전략이며 네트워크 운영, 엔지니어링, 설계, 기타 비즈니스 유닛 및 최종 사용자의 전반적인 비즈니스(비정량적) 목표를 조정해야 합니다. 이 점을 통해 조직에서는 예산 책정 프로세스를 포함하여 네트워크 관리 및 운영을 위한 장거리 계획 활동을 구성할 수 있습니다. 또한 SLA와 같은 네트워크 관리 목표를 달성하는 데 필요한 툴 및 통합 경로에 대한 지침을 제공합니다.

이 전략 문서는 특정 네트워크 문제의 관리에 너무 한정되어 있을 수 없으며 예산 문제를 포함하여 조직 전반에 중요한 항목에 중점을 둡니다. 예를 들면 다음과 같습니다.

• 달성 가능한 목표를 가진 포괄적인 계획을 수립합니다.

• 네트워크 지원이 필요한 각 비즈니스 서비스/애플리케이션을 파악합니다.

• 서비스 측정에 필요한 성능 기반 메트릭을 식별합니다.

• 성능 측정 단위 데이터의 수집 및 배포를 계획합니다.

• 네트워크 평가 및 사용자 피드백에 필요한 지원을 식별합니다.

• 문서화되고 상세하며 측정 가능한 서비스 수준 목표를 보유하고 있습니다.

서비스 레벨 계약 문서화

SLA를 올바르게 문서화하려면 서비스 수준 목표 메트릭을 완전히 정의해야 합니다. 이 문서는 사용자가 평가할 때 사용할 수 있어야 합니다. 네트워크 관리 조직이 서비스 계약 수준을 유지하는 데 필요한 변수를 지속적으로 측정할 수 있도록 피드백 루프를 제공합니다.

SLA는 비즈니스 환경과 네트워크가 기본적으로 동적이기 때문에 "살아있는" 문서입니다. 현재 SLA를 측정하기 위해 작동하는 것은 내일이면 단종될 수 있습니다. 사용자가 피드백 루프를 시작하고 해당 정보에 대한 작업을 수행해야 네트워크 운영에서 조직이 요구하는 고가용성 수치를 유지할 수 있습니다.

기준 요소에 대한 변수 목록 만들기

이 목록에는 폴링 간격, 발생한 네트워크 관리 오버헤드, 가능한 트리거 임계값, 변수가 트랩에 대한 트리거로 사용되는지 여부, 각 변수에 대해 사용된 추세 분석 등의 항목이 포함됩니다.

이러한 변수는 위에서 언급한 서비스 수준 목표에 필요한 메트릭에 제한되지 않습니다. 최소한 다음 변수를 포함해야 합니다. 라우터 상태, 스위치 상태, 라우팅 정보, 기술별 데이터, 활용도 및 지연 이러한 변수는 정기적으로 폴링되고 데이터베이스에 저장됩니다. 그런 다음 이 데이터에 대해 보고서를 생성할 수 있습니다. 이러한 보고서는 다음과 같은 방법으로 네트워크 관리 운영 및 계획 직원을 지원할 수 있습니다.

• 사후 대처 문제는 기록 데이터베이스를 사용하여 더 빨리 해결할 수 있습니다.

• 성능 보고 및 용량 계획에는 이러한 유형의 데이터가 필요합니다.

• 서비스 수준 목표를 기준으로 측정할 수 있습니다.

Baseline 및 Trends 분석 검토

네트워크 관리 담당자는 정기적으로 특정 보고서를 검토하기 위한 회의를 수행해야 합니다. 이를 통해 추가적인 피드백은 물론 네트워크의 잠재적 문제에 대한 사전 대응적 접근 방식도 제공합니다.

이러한 회의에는 운영 및 계획 담당자가 모두 포함되어야 합니다. 이를 통해 계획자가 기준 및 추세 데이터에 대한 운영 분석을 받을 수 있습니다. 또한 계획 분석에 있어 운영 인력을 "루프"에 넣기도 합니다.

이러한 회의에 포함할 또 다른 유형의 항목은 서비스 수준 목표입니다. 목표 임계값에 도달할 경우 네트워크 관리 담당자는 목표 누락을 방지하기 위해 조치를 취할 수 있으며, 경우에 따라 이 데이터를 부분 예산 정당화로 사용할 수 있습니다. 적절한 조치를 취하지 않을 경우 서비스 수준 목표를 위반할 위치를 데이터에 표시할 수 있습니다. 또한 이러한 목표가 비즈니스 서비스 및 애플리케이션에 의해 식별되었기 때문에 재정적 기반에서 타당성을 입증하기가 더 쉽습니다.

이러한 검토를 2주마다 수행하고 6주에서 12주마다 더욱 철저한 분석 회의를 개최합니다. 이러한 회의를 통해 단기 및 장기 문제를 모두 해결할 수 있습니다.

가상 분석 방법론 문서화

가정(what-if) 분석에는 솔루션 모델링 및 검증이 포함됩니다. 네트워크에 새 솔루션을 추가하기 전에(새 애플리케이션 또는 Cisco IOS 릴리스의 변경) 몇 가지 대체 방법을 문서화하십시오.

이 분석에 대한 문서에는 주요 질문, 방법론, 데이터 세트 및 컨피그레이션 파일이 포함되어 있습니다. 핵심은 what-if 분석은 그 문서에 제공된 정보로 다른 사람이 재창조할 수 있어야 한다는 실험이라는 점이다.

네트워크 성능 향상에 사용된 방법론 문서화

이 문서에는 특정 유형의 링크에 대한 대역폭을 늘리는 데 도움이 되는 추가 WAN 대역폭 및 비용 표가 포함되어 있습니다. 이 정보는 조직이 대역폭을 늘리는 데 드는 시간과 비용을 파악하는 데 도움이 됩니다. 공식적인 문서를 통해 성능 및 용량 전문가가 성능을 높일 방법과 시기, 그러한 노력에 소요되는 시간 및 비용을 파악할 수 있습니다.

분기별 성과 검토의 일환으로 이 문서를 정기적으로 검토하여 최신 상태로 유지하십시오.

요약

이상적인 네트워크 관리 시스템의 목표를 달성하기 위한 유일한 방법은 성능 관리의 구성 요소를 시스템에 능동적으로 통합하는 것입니다. 이 목표에는 임계값이 초과될 때 알림 시스템에 연결된 가용성 및 응답 시간 메트릭을 사용하는 것이 포함되어야 합니다. 용량 계획 시 용량 할당 및 예외 보고를 위한 경험적 모델에 대한 링크가 포함된 베이스라인을 사용해야 합니다. 이 모델에는 실시간으로 모델을 업데이트하고 소프트웨어 시뮬레이션을 통해 계획 및 문제 해결 수준을 모두 제공할 수 있는 내장 모델링 또는 시뮬레이션 엔진이 있을 수 있습니다.

이 시스템의 대부분은 결코 달성할 수 없는 불가능한 이상적인 것처럼 보일 수 있지만, 각 구성 요소는 현재 사용 가능합니다. 또한 이러한 구성 요소를 통합하는 도구도 MicroMuse와 같은 프로그램에 있습니다. 그 어느 때보다 현실적인 이 이상을 향해 계속 나아가야 한다.

관련 정보

• 고가용성 기술 백서
• 용량 및 성능 관리 백서
• 기술 지원 및 문서 − Cisco Systems