성능 관리: 모범 사례 백서

소개

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

배경 정보

용량 계획은 비즈니스 크리티컬 애플리케이션에 대한 성능 또는 가용성에 영향을 미치지 않도록 향후 네트워크 리소스에 대한 요구 사항을 결정하는 프로세스입니다. 용량 계획 영역에서는 네트워크 기준(CPU, 메모리, 버퍼, 수신/송신 패킷 등)이 응답 시간에 영향을 줄 수 있습니다. 따라서 성능 문제가 종종 용량과 연관된다는 점에 유의하십시오. 네트워크에서 이는 일반적으로 네트워크를 통해 전송되기 전에 대기해야 하는 대역폭과 데이터입니다. 음성 애플리케이션의 경우 지연 및 지터와 같은 요인이 음성 통화 품질에 영향을 주므로 이 대기 시간은 사용자에게 거의 확실히 영향을 미칩니다.

성능 관리를 복잡하게 만드는 또 다른 주요 문제는 대기업 및 통신 사업자 네트워크 모두에서 네트워크 가용성이 미션 크리티컬한 사항이지만, 장기적으로 더 많은 비용이 발생할 수 있는 위험으로 단기적인 경제적 이익을 노리는 경향이 있다는 것입니다. 모든 예산 주기 동안 네트워크 관리자와 프로젝트 구현 담당자는 성능과 빠른 구현 사이에서 균형을 찾아야 합니다. 또한 네트워크 관리자는 한정된 시장 기간, 복잡한 기술, 비즈니스 통합, 경쟁 시장, 예기치 않은 다운타임, 전문성 부족, 불충분한 툴 등을 충족하기 위해 신속한 제품 개발 등 여러 과제에 직면해 있습니다.

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

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

• 운영자에게 임박한 성능 저하를 알립니다.

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

• 성능 저하 또는 장애의 원인을 정확하게 파악할 수 있는 툴을 제공합니다.

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

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

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

• 사용자 성능

• 애플리케이션 성능

• 용량 계획

• 사전 예방적 장애 관리

음성 및 비디오와 같은 최신 애플리케이션의 경우 성능이 성공의 핵심 변수이며, 일관된 성능을 달성할 수 없는 경우 서비스가 낮은 값으로 간주되어 실패합니다. 다른 경우에는 사용자가 일시적인 애플리케이션 시간 초과로 인해 생산성 및 사용자 만족도를 떨어뜨릴 수 있는 가변적인 성능만 겪는 경우가 있습니다.

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

주요 성공 요인

주요 성공 요인은 구현 모범 사례에 대한 요구 사항을 식별합니다. 중요한 성공 요인으로 자격을 부여하려면 프로세스 또는 절차를 통해 가용성을 향상시켜야 합니다. 그렇지 않으면 절차를 생략하면 가용성을 저하시켜야 합니다. 또한 중요한 성공 요인은 측정 가능해야 조직이 성공의 범위를 결정할 수 있습니다.

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

다음은 성능 관리의 핵심 성공 요소입니다.

• 네트워크 및 애플리케이션 데이터의 기준을 수집합니다.

• 네트워크 및 애플리케이션에 대해 what-if 분석을 수행합니다.

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

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

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

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

• 사후 대응적 및 장기적 차원에서 용량 문제를 처리할 수 있도록 업그레이드 또는 조정 절차를 설정해야 합니다.

성과 관리 지표

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

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

• 상세하고 측정 가능한 서비스 레벨 목표를 생성합니다.

• 시간이 지남에 따라 이러한 계약이 충족되는 방식에 대한 성공 또는 실패를 보여 주는 차트 또는 그래프로 서비스 레벨 계약에 대한 설명서를 제공합니다.

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

• 기준 및 트렌드에 대한 분석을 검토하는 정기적인 회의를 개최합니다.

• 가상 분석 방법론을 문서화하십시오. 여기에는 해당하는 경우 모델링 및 확인이 포함되어야 합니다.

• 임계값이 초과되면 네트워크 리소스를 늘리는 데 사용되는 방법론에 대한 문서를 개발합니다. 문서화할 항목 중 하나는 추가 WAN 대역폭 및 비용 테이블을 입력하는 데 필요한 시간 줄입니다.

성능 관리 프로세스 흐름

다음 단계는 성능 관리를 위한 고급 프로세스 흐름을 제공합니다.

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

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

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

   3. 성능 SLA 및 메트릭 정의

   4. SLA 정의

2. 성능 측정

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

   2. 가용성 측정

   3. 응답 시간 측정

   4. 측정 정확도

   5. 활용률 측정

   6. 용량 계획

3. 사전 예방적 장애 분석 수행

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

   2. 네트워크 관리 구현

   3. 네트워크 운영 메트릭

운영 네트워크 관리 개념 개발

네트워크에 대한 자세한 성능 및 용량 변수를 정의하기 전에 조직 내에서 네트워크 관리를 위한 전반적인 운영 개념을 살펴봐야 합니다. 이 전체 개념을 정의할 때 네트워크에서 원하는 기능의 정확한 정의를 작성할 수 있는 비즈니스 기반을 제공합니다. 네트워크 관리를 위한 운영 개념을 개발하지 못할 경우, 고객의 요구에 따라 끊임없이 변화하는 목표 또는 목표가 결여될 수 있습니다.

일반적으로 네트워크 관리 프로그램의 시스템 정의 단계의 첫 번째 단계로 네트워크 관리 개념을 생성합니다. 운영 관점에서 전체적인 바람직한 시스템 특성을 설명하는 것이 목적입니다. 이 문서는 네트워크 운영, 엔지니어링, 설계, 기타 비즈니스 부서 및 최종 사용자의 전반적인 비즈니스 목표(정량적이지 않음)를 조정하는 데 사용됩니다. 이 문서의 핵심은 네트워크 관리 및 운영을 위한 장기적인 운영 계획 활동을 구성하는 것입니다. 또한 서비스 수준 계약과 같은 모든 후속 정의 문서의 개발에 대한 지침을 제공합니다. 이러한 초기 정의 집합은 분명히 특정 네트워크 문제의 관리에 지나치게 중점을 둘 수는 없지만, 전체 조직 및 관리해야 하는 비용에 대한 중요성이 강조되는 항목에 초점을 맞출 수 있습니다. 몇 가지 목표는 다음과 같습니다.

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

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

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

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

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

• 사용자의 피드백과 함께 네트워크의 전략적 평가 지원

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

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

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

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

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

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

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

• 전체 트래픽

• 볼륨

• 경로 수

• 가상 회로 수

• 인접 디바이스 수

• 브로드캐스트 도메인

• 디바이스 처리량

• 미디어 용량

네트워크 플래너는 설계의 필수 수명, 설계 수명 동안 필요한 확장 또는 사이트, 신규 사용자 수, 예상되는 트래픽 볼륨 또는 변경을 결정해야 합니다. 이 계획을 통해 제안된 솔루션이 설계 수명 기간 동안의 성장 요구 사항을 충족하도록 보장할 수 있습니다.

솔루션 확장성을 조사하지 않으면 대규모 사후 대응적 설계 변경을 구현해야 할 수도 있습니다. 이러한 설계 변경 사항에는 계층 구조, 미디어 업그레이드 또는 하드웨어 업그레이드가 추가로 포함될 수 있습니다. 주요 하드웨어 구매에 상당히 정확한 예산 주기에 의존하는 조직에서 이러한 변화는 전반적인 성공에 큰 걸림돌이 될 수 있습니다. 가용성 측면에서 볼 때, 네트워크에서 예기치 않은 리소스 제한이 발생하여 비가용성 및 사후 조치 기간이 발생할 수 있습니다.

상호 운용성 및 상호 운용성 테스트는 새로운 솔루션 구축의 성공에 매우 중요한 요소가 될 수 있습니다. 상호 운용성은 다양한 하드웨어 벤더나 네트워크 구현 중 또는 네트워크 구현 후에 서로 조화를 이루어야 하는 다양한 토폴로지 또는 솔루션을 참조할 수 있습니다. 상호 운용성 문제에는 라우팅 또는 전송 문제에 대한 프로토콜 스택을 통해 하드웨어 신호 처리가 포함될 수 있습니다. 상호 운용성 문제는 네트워크 솔루션 마이그레이션 전, 중, 후 발생할 수 있습니다. 상호 운용성 계획에는 마이그레이션 과정에서 발생할 수 있는 여러 디바이스와 토폴로지 문제 간의 연결이 포함되어야 합니다.

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

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

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

• 응답 시간

• 사용률

• 처리량

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

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

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

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

전체 네트워크 관리에 관리 기능이 부족하지 않도록 관리 목표 정의 관리 효율성 목표를 설정하려면 조직의 지원 프로세스 및 관련 네트워크 관리 툴을 이해해야 합니다. 관리 용이성 목표에는 새로운 솔루션이 현재 지원 및 툴 모델에 어떻게 부합하는지, 잠재적인 차이점 또는 새로운 요구 사항에 대한 참조 정보가 포함되어야 합니다. 구축 성공과 가용성 목표 충족을 위해서는 새로운 솔루션을 지원하는 기능이 무엇보다 중요하므로 네트워크 가용성에 매우 중요합니다.

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

성능 SLA 및 메트릭 정의

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

SLA 정의

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

조직이 서비스 레벨을 미리 정의하지 않으면 나중에 식별되는 리소스 요구 사항을 개선하거나 얻기 어려워집니다. 또한 네트워크 지원을 위해 어떤 리소스를 추가할 것인지 이해하기 어려워집니다. 대부분의 경우 이러한 리소스는 문제가 발견된 후에만 적용됩니다.

성능 측정

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

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

• 가용성 측정

• 응답 시간 측정

• 측정 정확도

• 활용률 측정

• 용량 계획

네트워크 기준 데이터 수집

대부분의 기업 인트라넷에는 충분한 대역폭이 있습니다. 그러나 적절한 데이터가 없으면 애플리케이션 성능 저하의 원인이 되는 네트워크 혼잡을 배제할 수 없습니다. 혼잡 또는 오류의 원인 중 하나는 낮은 성능이 간헐적이거나 하루 중 시간에 따라 달라지는지 여부입니다. 이러한 상황의 한 예는 저녁에 늦은 시간에 성능이 충분하지만, 아침 및 최대 업무 시간 동안에는 매우 느릴 때입니다.

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

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

또 다른 전문 기준으로는 애플리케이션 기준(application baseline)이 있으며, 이는 애플리케이션 네트워크 요구 사항을 추정하는 데 유용합니다. 이 정보는 업그레이드 주기에서 청구 및/또는 예산 책정을 위해 사용할 수 있습니다. 응용 프로그램 기준 요소는 응용 프로그램당 기본 서비스 또는 서비스 품질과 관련하여 응용 프로그램 가용성 영역에서 중요할 수도 있습니다. 애플리케이션 기준 정보는 주로 기간별 애플리케이션에서 사용하는 대역폭으로 구성됩니다. 일부 네트워크 관리 애플리케이션은 애플리케이션 성능을 기준화할 수도 있습니다. 트래픽 유형(텔넷 또는 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에 가깝습니다. 인터페이스 오류의 일반적인 원인은 다음과 같습니다.

• 규격 외 배선

• 전기 간섭

• 하드웨어 또는 소프트웨어 오류

더 긴밀한 조사를 위해 낮은 정확도를 사용합니다. 특정 인터페이스에 문제가 발생하며 오류가 허용되는지 확인할 수 있습니다. 이 경우 오류 속도가 허용되지 않는 위치를 반영하려면 이 인터페이스의 정확도 임계값을 조정해야 합니다. 허용되지 않는 오류율이 이전 베이스라인에서 보고되었을 수 있습니다.

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

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

오류율 공식은 일반적으로 퍼센트로 표시됩니다.

오류율 = (SuifInErrors) *100

—

(IfInUcastPkts + (SuqaifInNUcastPkts )

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

정확도 수식은 오류 비율을 사용하여 100에서 빼기(다시 백분율 형식):

정확도 = 100 - (SuqifInErrors) *100

—

(IfInUcastPkts + (SuqaifInNUcastPkts)

이러한 공식은 MIB II 인터페이스(RFC 2233) 일반 카운터의 관점에서 오류 및 정확성을 반영합니다. 결과는 오류와 보고 전송된 총 패킷 수를 비교하는 백분율로 표시됩니다. 정확도를 생성하는 100에서 결과를 뺀 오류 비율입니다. 100%의 정확도는 완벽합니다.

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

활용률 측정

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

활용도는 네트워크 파이프(링크)가 얼마나 가득 찼는지를 결정하는 기본 방법입니다. CPU, 인터페이스, 큐잉 및 기타 시스템 관련 용량 측정치를 측정하여 네트워크 시스템 리소스가 소모되는 정도를 결정합니다.

높은 활용률이 반드시 나쁜 것은 아닙니다. 활용도가 낮으면 예기치 않은 곳에서 트래픽 흐름이 발생할 수 있습니다. 선이 과도하게 사용됨에 따라 효과가 커질 수 있습니다. 초과 사용률은 인터페이스 통과를 위해 대기된 트래픽이 처리할 수 있는 트래픽보다 많을 때 발생합니다. 리소스 사용률이 갑자기 증가하면 장애 상태를 나타낼 수 있습니다.

인터페이스가 혼잡해지면 네트워크 디바이스는 패킷을 대기열에 저장하거나 폐기해야 합니다. 라우터가 패킷을 전체 대기열에 저장하려고 하면 패킷이 삭제됩니다. 트래픽이 빠른 인터페이스에서 느린 인터페이스로 전달되면 삭제된 패킷이 발생합니다. 이는 Q = u / (1-u) 공식에 나와 있습니다. 여기서 u는 활용률이고 Q는 평균 대기열 깊이(임의의 트래픽 가정)입니다. 따라서 링크의 사용률 수준이 높으면 평균 대기열 깊이가 높고, 패킷 크기를 알면 레이턴시가 예측 가능합니다. 일부 네트워크 보고 벤더에서는 더 적은 대역폭을 주문하고 WAN에 더 적은 비용을 지불할 수 있다고 말합니다. 그러나 WAN 링크를 95%의 사용률로 실행할 경우 레이턴시 영향이 나타납니다. 또한 네트워크가 VoIP로 마이그레이션됨에 따라 네트워크 관리자는 정책을 변경하고 WAN 링크를 약 50% 활용하면서 실행해야 할 수도 있습니다.

패킷이 삭제되면 상위 레이어 프로토콜에서 패킷을 강제로 재전송할 수 있습니다. 여러 패킷이 삭제되면 과도한 재시도 트래픽이 발생할 수 있습니다. 이러한 유형의 대응으로 디바이스의 백업이 더 이상 중단될 수 있습니다. 이 문제를 해결하기 위해 다른 수준의 임계값을 설정할 수 있습니다.

네트워크 사용률에 사용되는 기본 측정은 인터페이스 사용률입니다. 측정하는 연결이 반이중 또는 전이중 연결인지 여부에 따라 이 표에 설명된 공식을 사용합니다.

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

공유 LAN 연결은 주로 하프 듀플렉스인 경향이 있습니다. 경합 탐지는 디바이스가 전송하기 전에 수신 대기해야 하기 때문입니다. WAN 연결은 일반적으로 연결이 포인트투포인트이므로 전이중 방식입니다. 두 디바이스 모두 연결을 공유하는 다른 디바이스가 하나만 있다는 것을 알고 있으므로 동시에 송수신과 수신이 가능합니다.

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

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

(IfInOctets + SuqifOutOctets) * 8 * 100

—

(Δ의 초 수) * ifSpeed

전이중 미디어의 경우 사용률 계산이 더 복잡합니다. 예를 들어 전체 T-1 시리얼 연결을 사용하는 경우 회선 속도는 1.544Mbps입니다. 즉, T-1 인터페이스는 1.544Mbps를 수신하고 전송할 수 있으며, 가능한 총 대역폭 3.088Mbps를 제공합니다.

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

max(IfInOctets, (QurifOutOctets) * 8 * 100

—

(Δ의 초 수) * ifSpeed

그러나 이 방법은 값이 낮고 정확한 결과를 제공하는 방향의 사용률을 숨깁니다. 보다 정확한 방법은 다음과 같이 입력 활용률 및 출력 활용률을 별도로 측정하는 것입니다.

입력 활용률 = SupIfInOctets *8 * 100

—

(Δ의 초 수) * ifSpeed

그리고

출력 활용률 = SupIfOutOctets *8 * 100

—

(Δ의 초 수) * ifSpeed

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

용량 계획

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

사전 예방적 장애 분석 수행

능동적인 장애 분석은 성능 관리에 필수적입니다. 성능 관리를 위해 수집되는 것과 동일한 유형의 데이터를 사전 예방적 장애 분석에 사용할 수 있습니다. 그러나 이 데이터의 시기와 사용은 사전 예방적 장애 관리와 성능 관리 간에 다릅니다.

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

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

사전 예방적 장애 관리를 위한 임계값 사용

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

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

두 개의 숫자 데이터 클래스에 대해 두 개의 임계값 클래스가 있습니다. 지속적과 불연속. 연속 임계값은 SNMP 카운터 또는 게이지에 저장된 데이터와 같은 연속 또는 시계열 데이터에 적용됩니다. 이산 임계값은 열거 객체 또는 이산 숫자 데이터에 적용됩니다. Boolean 객체는 두 개의 값을 가진 열거 값입니다. true 또는 false입니다. 이벤트가 한 값에서 다음 값으로 전환됨을 나타내므로 개별 데이터를 이벤트 데이터라고 할 수도 있습니다.

연속 임계값은 시계열 객체가 지정된 임계값에 도달할 때 이벤트를 트리거할 수 있습니다. 객체 값이 임계값을 초과하거나 그 아래로 떨어집니다. 또한 임계값을 따로 설정하는 것도 유용할 수 있습니다. 하이브리드 메커니즘이라고 하는 이 기술은 이 데이터 클래스에서 생성되는 이벤트 수를 줄이는 데 도움이 됩니다. 임계값 메커니즘은 빠르게 변화하는 시계열 데이터에 대한 임계값에 의해 생성되는 이벤트의 양을 줄이는 데 사용됩니다. 이 메커니즘은 시계열 데이터의 모든 임계값 기법과 함께 사용할 수 있습니다.

객체 값을 추적하기 위해 생성되는 경보에 의해 이벤트 볼륨이 감소합니다. 이 경보에 임계값 상승 및 하락 정도가 지정됩니다. 경보는 상승하는 임계값이 넘을 때만 트리거됩니다. 일단 이 임계값을 넘으면, 낙하 임계값이 넘을 때까지 상승 경보가 다시 생성되지 않습니다. 그리고 같은 메커니즘은 상승하는 임계값이 다시 넘을 때까지 임계값을 내리는 것을 방지합니다. 이 메커니즘은 이벤트 볼륨을 크게 줄일 수 있으며 결함이 있는지 확인하기 위해 필요한 정보를 제거하지 않습니다.

시계열 데이터는 카운터로 표현될 수 있습니다. 이 카운터에서는 각 새 데이터 포인트가 이전 데이터 포인트의 합계에 추가되거나, 게이지로 표시되는데, 여기서 데이터는 시간 간격 동안 비율로 표현됩니다. 각 데이터 유형에 적용할 수 있는 두 가지 유형의 연속 임계값이 있습니다. 절대 연속 임계값 및 상대적 연속 임계값. 계기 및 카운터와 관련된 연속 임계값에 절대 연속 임계값을 사용합니다.

네트워크의 임계값을 확인하려면 다음 단계를 수행하십시오.

1. 객체를 선택합니다.

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

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

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

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

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

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

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

네트워크 관리 구현

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

네트워크 운영 메트릭

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

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

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

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

• 각 문제 유형에 대해 종료할 시간 분석

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

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

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

성과 관리 지표

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

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

이 문서는 네트워크 관리를 위한 운영의 공식 개념이거나 필요한 기능 및 목표에 대한 덜 공식적인 설명일 수 있습니다. 그러나 이 문서는 네트워크 관리자가 성공을 측정하는 데 도움이 되어야 합니다.

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

이 전략적 문서는 특정 네트워크 문제의 관리에 너무 좁힐 수는 없지만 예산 문제를 포함한 전체 조직에 중요한 항목에 초점을 맞출 수 있습니다. 예를 들면 다음과 같습니다.

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

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

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

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

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

• 서비스 수준 목표를 문서화하고 세부적이며 측정 가능한 방식으로 문서화했습니다.

서비스 레벨 계약 문서화

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

비즈니스 환경과 네트워크는 기본적으로 동적이므로 SLA는 "살아있는" 문서입니다. 현재 SLA를 측정하는 작업은 내일 더 이상 사용되지 않을 수 있습니다. 사용자가 피드백 루프를 설정하고 해당 정보에 대한 조치를 취할 때만 네트워크 운영에서 조직에 필요한 고가용성 번호를 유지할 수 있습니다.

기준 요소에 대한 변수 목록 생성

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

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

• 사후 대응적 문제는 기록 데이터베이스를 통해 더 신속하게 해결할 수 있습니다.

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

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

기준 및 추세 분석 검토

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

이러한 회의에는 운영 및 계획 담당자가 모두 포함되어야 합니다. 이를 통해 플래너가 베이스라인 및 트렌드 데이터에 대한 운영 분석을 받을 수 있습니다. 또한 일부 계획 분석을 위해 운영 인력을 "반복"합니다.

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

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

What-if 분석 방법론 문서화

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

이 분석 문서에는 주요 질문, 방법론, 데이터 세트 및 구성 파일이 포함되어 있습니다. 요점은 what-if 분석은 문서에 제공된 정보로 다른 사람이 다시 만들 수 있는 실험입니다.

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

이 문서에는 추가 WAN 대역폭과 특정 링크 유형의 대역폭을 늘리는 데 도움이 되는 비용 표가 포함되어 있습니다. 이 정보를 통해 조직은 대역폭을 늘리기 위해 시간과 비용을 절약할 수 있습니다. 공식 문서를 통해 성능 및 용량 전문가는 성능 향상 방법 및 시기, 이러한 작업에 대한 시간 및 비용을 파악할 수 있습니다.

이 문서는 분기별 성과 검토의 일부로 주기적으로 검토하여 최신 상태로 유지되도록 합니다.

요약

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

이러한 시스템의 많은 부분이 결코 달성할 수 없는 이상적인 것으로 보일 수 있지만 현재 각 구성 요소를 사용할 수 있습니다. 또한 이러한 구성 요소를 통합하는 툴도 MicroMuse와 같은 프로그램에 존재합니다. 우리는 그 어느 때보다도 더 현실적인 이 이상을 향해 계속 노력해야 합니다.

관련 정보

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