용량 및 성능 관리: 모범 사례 백서
목차
소개
대규모 엔터프라이즈 및 통신 사업자 네트워크 내에서는 높은 네트워크 가용성이 미션 크리티컬 요구 사항입니다. 네트워크 관리자들은 예정된 다운타임, 전문 지식 부족, 툴 부족, 복잡한 기술, 비즈니스 통합, 경쟁 시장 등 가용성이 높아지는 문제에 직면해 있습니다. 용량 및 성능 관리를 통해 네트워크 관리자는 새로운 비즈니스 목표를 달성하고 일관된 네트워크 가용성과 성능을 유지할 수 있습니다.
이 문서에서는 다음 항목에 대해 살펴봅니다.
-
네트워크 내의 위험 및 잠재적 용량 문제를 포함한 일반적인 용량 및 성능 문제
-
What-if 분석, 베이스라인, 트렌드 분석, 예외 관리, QoS 관리를 비롯한 용량 및 성능 관리 모범 사례
-
용량 계획에 사용되는 공통 기술, 툴, MIB 변수 및 임계값을 비롯한 용량 계획 전략을 개발하는 방법
용량 및 성능 관리 개요
용량 계획은 비즈니스 크리티컬 애플리케이션에 성능 또는 가용성이 미치는 영향을 방지하는 데 필요한 네트워크 리소스를 결정하는 프로세스입니다. 성능 관리는 개별 및 전체 서비스에 대한 네트워크 서비스 응답 시간, 일관성 및 품질을 관리하는 관행입니다.
참고: 성능 문제는 일반적으로 용량과 관련이 있습니다. 대역폭 및 데이터는 네트워크를 통해 전송되기 전에 대기열에서 기다려야 하므로 애플리케이션이 느려집니다. 음성 애플리케이션에서 지연 및 지터와 같은 문제는 음성 통화의 품질에 직접적으로 영향을 미친다.
대부분의 조직에서는 이미 용량 관련 정보를 일부 수집하고 있으며, 문제 해결, 변경 계획, 새로운 용량 및 성능 기능 구현을 위해 일관되게 작업하고 있습니다. 그러나 조직에서는 추세 분석 및 가정 분석을 정기적으로 수행하지 않습니다. 가정(What-if) 분석은 네트워크 변화의 영향을 결정하는 프로세스입니다. 트렌드는 네트워크 용량 및 성능 문제의 기준을 수행하고 네트워크 트렌드의 기준을 검토하여 향후 업그레이드 요구 사항을 파악하는 프로세스입니다. 용량 및 성능 관리에는 사용자가 호출하기 전에 문제를 파악하고 해결하는 예외 관리, 네트워크 관리자가 개별 서비스 성능 문제를 계획, 관리, 식별하는 QoS 관리도 포함되어야 합니다. 다음 그림은 용량 및 성능 관리 프로세스를 보여줍니다.
용량 및 성능 관리에도 일반적으로 CPU 및 메모리와 관련된 제한이 있습니다. 다음은 잠재적 우려 사항입니다.
-
CPU
-
백플레인 또는 I/O
-
메모리 및 버퍼
-
인터페이스 및 파이프 크기
-
큐잉, 레이턴시, 지터
-
속도와 거리
-
애플리케이션 특성
용량 계획 및 성능 관리에 대한 일부 언급에서는 "데이터 플레인" 및 "컨트롤 플레인"이라고 합니다. 데이터 평면은 네트워크를 통과하는 데이터와 관련된 용량 및 성능 문제일 뿐이며, 제어 평면은 데이터 평면의 적절한 기능을 유지하는 데 필요한 리소스를 의미합니다. 컨트롤 플레인 기능에는 디바이스의 라우팅, 스패닝 트리, 인터페이스 킵얼라이브 및 SNMP 관리와 같은 서비스 오버헤드가 포함됩니다. 이러한 컨트롤 플레인 요구 사항은 네트워크를 통과하는 트래픽과 마찬가지로 CPU, 메모리, 버퍼링, 대기 및 대역폭을 사용합니다. 컨트롤 플레인 요구 사항 중 다수는 시스템의 전반적인 기능에도 필수적입니다. 필요한 리소스가 없으면 네트워크에 장애가 발생합니다.
CPU
CPU는 일반적으로 모든 네트워크 디바이스의 컨트롤 플레인 및 데이터 플레인 모두에서 사용됩니다. 용량 및 성능 관리에서 디바이스와 네트워크가 항상 작동하기에 충분한 CPU를 갖추고 있는지 확인해야 합니다. CPU가 부족하면 한 디바이스의 리소스가 부족하면 전체 네트워크에 영향을 줄 수 있으므로 네트워크가 붕괴될 수 있습니다. CPU가 부족하면 주 CPU 없이 하드웨어 스위칭이 없을 때 데이터 처리를 기다려야 하므로 레이턴시도 증가할 수 있습니다.
백플레인 또는 I/O
백플레인 또는 I/O는 디바이스가 처리할 수 있는 총 트래픽 양을 의미하며, 일반적으로 BUS 크기 또는 백플레인 기능 측면에서 설명합니다. 백플레인이 부족하면 일반적으로 패킷이 삭제되어 재전송과 추가 트래픽이 발생할 수 있습니다.
메모리
메모리는 데이터 플레인 및 컨트롤 플레인 요구 사항이 있는 또 다른 리소스입니다. 라우팅 테이블, ARP 테이블 및 기타 데이터 구조와 같은 정보에는 메모리가 필요합니다. 장치의 메모리가 부족하면 장치의 일부 작업이 실패할 수 있습니다. 이 작업은 상황에 따라 컨트롤 플레인 프로세스 또는 데이터 플레인 프로세스에 영향을 줄 수 있습니다. 컨트롤 플레인 프로세스가 실패할 경우 전체 네트워크가 저하될 수 있습니다. 예를 들어 라우팅 통합에 추가 메모리가 필요한 경우 이 문제가 발생할 수 있습니다.
인터페이스 및 파이프 크기
인터페이스 및 파이프 크기는 하나의 연결에서 동시에 전송할 수 있는 데이터의 양을 나타냅니다. 이 속도를 연결 속도라고 잘못 부르는 경우가 많지만 데이터가 한 디바이스에서 다른 디바이스로 이동하는 속도는 다릅니다. 실리콘 속도 및 하드웨어 기능은 미디어를 기반으로 가용 대역폭을 결정하는 데 도움이 됩니다. 또한 소프트웨어 메커니즘은 서비스에 대한 특정 대역폭 할당에 맞게 데이터를 "조절"할 수 있습니다. 일반적으로 1.54kpbs에서 155mb 이상의 속도 기능을 가지고 있는 프레임 릴레이 또는 ATM의 통신 사업자 네트워크에서 이를 확인할 수 있습니다. 대역폭 제한이 있는 경우 데이터는 전송 대기열에 추가됩니다. 전송 대기열에는 대기열 내에서 데이터의 우선 순위를 지정하기 위한 서로 다른 소프트웨어 메커니즘이 있을 수 있습니다. 그러나 대기열에 데이터가 있는 경우 데이터를 인터페이스 외부로 전달하려면 먼저 기존 데이터를 기다려야 합니다.
큐잉, 레이턴시, 지터
대기, 대기 시간 및 지터는 성능에도 영향을 줍니다. 다양한 방법으로 성능에 영향을 주도록 전송 큐를 조정할 수 있습니다. 예를 들어 대기열이 큰 경우 데이터는 더 오래 대기합니다. 큐가 작으면 데이터가 삭제됩니다. 이를 taildrop이라고 하며 데이터가 다시 전송되므로 TCP 애플리케이션에서 사용할 수 있습니다. 그러나 음성 및 비디오는 대기열 삭제 또는 대역폭 또는 파이프 크기에 특별히 주의를 기울여야 하는 상당한 대기열 지연 시간에는 제대로 작동하지 않습니다. 디바이스에 패킷을 즉시 전달할 수 있는 충분한 리소스가 없는 경우에도 입력 대기열에 큐 지연이 발생할 수 있습니다. 이는 CPU, 메모리 또는 버퍼 때문일 수 있습니다.
레이턴시는 패킷이 수신된 시간부터 패킷이 전달된 시간까지의 정상적인 처리 시간을 설명합니다. 일반적인 최신 데이터 스위치와 라우터는 리소스 제약 없이 정상적인 조건에서 매우 낮은 레이턴시(< 1ms)를 가집니다. 디지털 신호 프로세서를 사용하여 아날로그 음성 패킷을 변환 및 압축하는 최신 장치는 최대 20ms까지 더 오래 걸릴 수 있습니다.
지터는 음성 및 비디오를 비롯한 스트리밍 애플리케이션의 패킷 간 간격을 설명합니다. 패킷이 서로 다른 패킷 간 간격 타이밍으로 다른 시간에 도착하면 지터가 높아지고 음성 품질이 저하됩니다. 지터는 주로 큐잉 지연(queuing delay)의 요인이다.
속도 및 거리
속도와 거리도 네트워크 성능의 한 요소입니다. Data Networks는 빛의 속도에 따라 일관된 데이터 포워딩 속도를 제공합니다. 이것은 약 100마일/밀리초입니다. 조직에서 국제적으로 클라이언트 서버 애플리케이션을 실행 중인 경우 해당 패킷 전달 지연이 발생할 수 있습니다. 네트워크 성능에 맞게 애플리케이션이 최적화되지 않은 경우 속도와 거리는 애플리케이션 성능에 엄청난 영향을 미칠 수 있습니다.
애플리케이션 특성
애플리케이션 특성은 용량 및 성능에 영향을 미치는 마지막 영역입니다. 작은 윈도우 크기, 애플리케이션 유지보수, 네트워크를 통해 전송되는 데이터 양과 필요한 데이터 양 등의 문제는 많은 환경, 특히 WAN의 애플리케이션 성능에 영향을 미칠 수 있습니다.
용량 및 성능 관리 모범 사례
이 섹션에서는 5가지 주요 용량 및 성능 관리 모범 사례에 대해 자세히 설명합니다.
서비스 수준 관리
서비스 수준 관리는 기타 필요한 용량 및 성능 관리 프로세스를 정의하고 규정합니다. 네트워크 관리자는 용량 계획이 필요하다는 것을 알고 있지만, 예산 책정 및 인력 충원의 제약으로 인해 완전한 솔루션이 불가능합니다. 서비스 수준 관리는 결과물을 정의하고 해당 결과물과 연결된 서비스에 대한 양방향 책임을 생성하여 리소스 문제를 해결하는 데 도움이 되는 검증된 방법론입니다. 다음과 같은 두 가지 방법으로 이를 수행할 수 있습니다.
-
용량 및 성능 관리를 포함하는 서비스에 대해 사용자와 네트워크 조직 간에 서비스 레벨 계약을 생성합니다. 이 서비스에는 서비스 품질을 유지하기 위한 보고서와 권장 사항이 포함됩니다. 그러나 사용자는 서비스 및 필요한 업그레이드에 대한 자금을 마련할 준비가 되어 있어야 합니다.
-
네트워크 조직은 해당 용량 및 성능 관리 서비스를 정의한 다음 사례별로 해당 서비스에 대한 자금 지원 및 업그레이드를 시도합니다.
어떤 경우에도 네트워크 조직은 현재 제공할 수 있는 서비스의 내용과 향후 계획되는 내용이 포함된 용량 계획 및 성능 관리 서비스를 정의함으로써 시작해야 합니다. 완벽한 서비스에는 네트워크 변경 및 애플리케이션 변경에 대한 what-if 분석, 정의된 성능 변수에 대한 기준 설정 및 추세 분석, 정의된 용량 및 성능 변수에 대한 예외 관리, QoS 관리가 포함됩니다.
네트워크 및 애플리케이션 가상 분석
네트워크 및 애플리케이션 what-if 분석을 수행하여 계획된 변경의 결과를 확인합니다. 가정(what-if) 분석 없이 조직은 성공과 전반적인 네트워크 가용성을 변화시키는 데 상당한 위험을 감수합니다. 대부분의 경우, 네트워크 변경으로 인해 많은 시간의 생산 중단 시간을 초래하는 울혈성 붕괴가 발생했습니다. 또한 애플리케이션 도입이 현저히 실패하여 다른 사용자와 애플리케이션에 영향을 미칩니다. 이러한 실패는 많은 네트워크 조직에서 계속되지만 몇 가지 툴과 몇 가지 추가 계획 단계를 통해 완벽하게 예방할 수 있습니다.
일반적으로 고품질 what-if 분석을 수행하려면 몇 가지 새로운 프로세스가 필요합니다. 첫 번째 단계는 모든 변경 사항에 대한 위험 수준을 파악하고 더 높은 위험 변경 사항에 대한 보다 심층적인 what-if 분석이 필요합니다. 위험 수준은 모든 변경 제출에 필요한 필드일 수 있습니다. 더 높은 위험 수준의 변경 시에는 변경 사항에 대한 정의된 what-if 분석이 필요합니다. 네트워크 what-if 분석은 네트워크 변경이 네트워크 사용률 및 네트워크 컨트롤 플레인 리소스 문제에 미치는 영향을 결정합니다. 애플리케이션 가상 분석을 통해 프로젝트 애플리케이션 성공, 대역폭 요구 사항, 네트워크 리소스 문제를 파악할 수 있습니다. 다음 표는 위험 레벨 지정 및 해당 테스트 요구 사항의 예입니다.
| 위험 수준 | 정의 | 변경 계획 권장 사항 |
|---|---|---|
| 1 |
|
|
| 2 |
|
|
| 3 |
|
|
| 4 |
|
|
| 5 |
|
|
what-if 분석이 필요한 위치를 정의하면 서비스를 정의할 수 있습니다.
모델링 툴 또는 프로덕션 환경을 모방한 랩을 사용하여 네트워크 가정 분석을 수행할 수 있습니다. 모델링 툴은 애플리케이션이 디바이스 리소스 문제를 얼마나 잘 이해하는지에 따라 제한되며, 대부분의 네트워크 변경 사항은 새로운 디바이스이므로 애플리케이션이 변경 사항의 영향을 이해하지 못할 수 있습니다. 가장 좋은 방법은 실험실에서 프로덕션 네트워크의 일부 표현을 구축하고 트래픽 생성기를 사용하여 로드 상태에서 원하는 소프트웨어, 기능, 하드웨어 또는 구성을 테스트하는 것입니다. 생산 네트워크에서 랩으로 경로(또는 기타 제어 정보)가 유출되면 랩 환경도 개선됩니다. SNMP, 브로드캐스트, 멀티캐스트, 암호화 또는 압축 트래픽을 비롯한 다양한 트래픽 유형으로 추가 리소스 요구 사항을 테스트합니다. 이러한 모든 방법을 통해 경로 통합, 링크 플래핑, 디바이스 재시작 등 잠재적인 스트레스 상황에서 디바이스 리소스 요구 사항을 분석합니다. 리소스 사용률 문제에는 CPU, 메모리, 백플레인 사용률, 버퍼 및 큐잉과 같은 일반 용량 리소스 영역이 포함됩니다.
또한 새로운 애플리케이션은 가상 분석을 수행하여 애플리케이션 성공 및 대역폭 요건을 결정해야 합니다. 일반적으로 이 분석은 프로토콜 분석기와 WAN 지연 시뮬레이터를 사용하여 거리의 영향을 이해하는 랩 환경에서 수행합니다. 프로덕션 네트워크에 연결된 PC, 허브, WAN 지연 장치 및 랩 라우터만 있으면 됩니다. 테스트 라우터에서 일반 트래픽 셰이핑 또는 속도 제한을 사용하여 트래픽을 제한함으로써 Lab의 대역폭을 시뮬레이션할 수 있습니다. 네트워크 관리자는 애플리케이션 그룹과 연동하여 LAN 및 WAN 환경 모두에서 애플리케이션의 대역폭 요건, 윈도우 문제 및 잠재적 성능 문제를 파악할 수 있습니다.
비즈니스 애플리케이션을 구축하기 전에 애플리케이션 가상 분석을 수행합니다. 이렇게 하지 않으면 애플리케이션 그룹이 성능 저하를 네트워크의 탓으로 돌립니다. 변경 관리 프로세스를 통해 새 구축에 대해 애플리케이션 what-if 분석이 필요할 수 있는 경우, 구축 실패를 방지하고 클라이언트-서버 및 배치 요구 사항 모두에 대한 급격한 대역폭 사용량 증가를 더 잘 이해할 수 있습니다.
기준 요소 지정 및 추세 분석
네트워크 관리자는 용량 문제로 인해 네트워크 가동 중단 시간 또는 성능 문제가 발생하기 전에 네트워크 업그레이드를 계획하고 완료할 수 있습니다. 연속 기간 동안의 리소스 사용률을 비교하거나 데이터베이스에서 시간의 경과에 따라 정보를 축소하고 계획자가 마지막 시간, 일, 주, 월 및 연도에 대한 리소스 사용률 매개변수를 볼 수 있도록 허용합니다. 어떤 경우든 누군가가 매주, 격주로 또는 매월 정보를 검토해야 합니다. 베이스라인과 트렌드의 문제는 대규모 네트워크에서 검토하려면 엄청난 양의 정보가 필요하다는 것입니다.
다음과 같은 여러 방법으로 이 문제를 해결할 수 있습니다.
-
충분한 용량을 구축하고 LAN 환경으로 전환하여 용량이 문제가 되지 않도록 합니다.
-
트렌드 정보를 그룹으로 나누고 중요한 WAN 사이트나 데이터 센터 LAN과 같은 네트워크의 고가용성 또는 중요 영역에 집중합니다.
-
보고 메커니즘은 특별한 주의를 위해 특정 임계값을 초과하는 영역을 강조할 수 있습니다. 중요한 가용성 영역을 먼저 구현할 경우 검토에 필요한 정보의 양을 크게 줄일 수 있습니다.
위의 모든 방법을 사용하더라도 정기적으로 정보를 검토해야 합니다. 기준 설정 및 추세 분석은 사전 대응적 작업이며, 조직에 사후 대응적 지원을 위한 리소스만 있는 경우 개인이 보고서를 읽지 않습니다.
많은 네트워크 관리 솔루션은 용량 리소스 변수에 대한 정보와 그래프를 제공합니다. 안타깝게도 대부분의 사람들은 기존 문제에 대한 사후 대응적 지원에만 이러한 툴을 사용합니다. 이는 베이스라인 설정 및 추세 분석의 목적을 달성하지 못합니다. Cisco 네트워크에 대한 용량 트렌드 정보를 제공하는 데 효과적인 두 가지 툴로는 Concord Network Health 제품과 INS EnterprisePRO 제품이 있습니다. 대부분의 경우 네트워크 조직은 용량 정보를 수집하기 위해 간단한 스크립팅 언어를 실행합니다. 다음은 링크 사용률, CPU 사용률 및 ping 성능에 대해 스크립트를 통해 수집된 몇 가지 예제 보고서입니다. 트렌드에 중요할 수 있는 다른 리소스 변수로는 메모리, 대기열 깊이, 브로드캐스트 볼륨, 버퍼, 프레임 릴레이 혼잡 알림, 백플레인 사용률 등이 있습니다. 링크 사용률 및 CPU 사용률에 대한 자세한 내용은 다음 표를 참조하십시오.
링크 사용률
| 리소스 | Address | 세그먼트 | 평균 사용률(%) | 최대 사용률(%) |
|---|---|---|---|---|
| JTKR01S2 | 10.2.6.1 | 128Kbps | 66.3 | 97.6 |
| JYKR01S0 | 10.2.6.2 | 128Kbps | 66.3 | 97.8 |
| FMCR18S4/4 | 10.2.5.1 | 384Kbps | 51.3 | 109.7 |
| PACR01S3/1 | 10.2.5.2 | 384Kbps | 51.1 | 98.4 |
CPU 사용률
| 리소스 | 폴링 주소 | 평균 사용률(%) | 최대 사용률(%) |
|---|---|---|---|
| FSTR01 | 10.28.142.1 | 60.4 | 80 |
| NERT06 | 10.170.2.1 | 47 | 86 |
| NORR01 | 10.73.200.1 | 47 | 99 |
| RTCR01 | 10.49.136.1 | 42 | 98 |
링크 사용률
| 리소스 | Address | AvResT(mS) 09-09-98 | AvResT(mS) 09-09-98 | AvResT(mS) 09-09-98 | AvResT(mS) 10-01-98 |
|---|---|---|---|---|---|
| ADR01 | 10.190.56.1 | 469.1 | 852.4 | 461.1 | 873.2 |
| ABNR01 | 10.190.52.1 | 486.1 | 869.2 | 489.5 | 880.2 |
| APRR01 | 10.190.54.1 | 490.7 | 883.4 | 485.2 | 892.5 |
| ASAR01 | 10.196.170.1 | 619.6 | 912.3 | 613.5 | 902.2 |
| ASRR01 | 10.196.178.1 | 667.7 | 976.4 | 655.5 | 948.6 |
| ASYR01S | 503.4 | ||||
| AZWRT01 | 10.177.32.1 | 460.1 | 444.7 | ||
| 베즈르01 | 10.195.18.1 | 1023.7 | 1064.6 | 1184 | 1021.9 |
예외 관리
예외 관리는 용량 및 성능 문제를 파악하고 해결하기 위한 유용한 방법입니다. 용량 및 성능 임계값 위반에 대한 알림을 수신하여 즉시 문제를 조사하고 수정하는 것이 좋습니다. 예를 들어, 네트워크 관리자가 라우터의 높은 CPU에 대한 경보를 수신할 수 있습니다. 네트워크 관리자는 라우터에 로그인하여 CPU가 높은 이유를 확인할 수 있습니다. 그런 다음 CPU를 줄이는 몇 가지 교정 컨피그레이션을 수행하거나, 문제의 원인이 되는 트래픽을 차단하는 액세스 목록을 생성할 수 있습니다. 특히 트래픽이 업무에 중요하지 않은 것으로 보일 경우 더욱 그렇습니다.
라우터에서 RMON 컨피그레이션 명령을 사용하거나 SNMP, RMON 또는 Netflow 데이터와 함께 Netsys 서비스 레벨 매니저와 같은 고급 툴을 사용하여 보다 중요한 문제에 대한 예외 관리를 구성할 수 있습니다. 대부분의 네트워크 관리 툴에는 위반 시 임계값과 경보를 설정할 수 있는 기능이 있습니다. 예외 관리 프로세스의 중요한 측면은 거의 실시간에 가까운 문제 알림을 제공하는 것입니다. 그렇지 않으면, 누군가 통지를 받았다는 것을 알아차리기 전에 문제가 사라질 수 있다. 이 작업은 조직에서 일관된 모니터링을 수행하는 경우 NOC 내에서 수행할 수 있습니다. 그렇지 않은 경우 페이저 알림을 사용하는 것이 좋습니다.
다음 컨피그레이션 예에서는 일관성 있게 검토할 수 있는 로그 파일에 라우터 CPU에 대한 상승 및 하강 임계값 알림을 제공합니다. 중요 링크 사용 임계값 위반 또는 기타 SNMP 임계값에 대해 유사한 RMON 명령을 설정할 수 있습니다.
rmon event 1 trap CPUtrap description "CPU Util >75%"rmon event 2 trap CPUtrap description "CPU Util <75%"rmon event 3 trap CPUtrap description "CPU Util >90%"rmon event 4 trap CPUtrap description "CPU Util <90%"rmon alarm 75 lsystem.56.0 10 absolute rising-threshold 75 1 falling-threshold 75 2rmon alarm 90 lsystem.56.0 10 absolute rising-threshold 90 3 falling-threshold 90 4
QoS 관리
서비스 품질 관리에는 네트워크 내에서 특정 트래픽 클래스를 생성하고 모니터링하는 작업이 포함됩니다. 트래픽은 특정 애플리케이션 그룹(트래픽 클래스 내에 정의됨)에 대해 더 일관된 성능을 제공합니다. 트래픽 셰이핑 매개 변수는 특정 트래픽 클래스에 대한 트래픽 셰이핑 및 우선 순위에 상당한 유연성을 제공합니다. 이러한 기능에는 CAR(Committed Access Rate), WRED(Weighted Random Early Detection), 클래스 기반 공정 가중치 대기 등의 기능이 포함됩니다. 트래픽 클래스는 일반적으로 더 중요한 비즈니스 애플리케이션의 성능 SLA 및 음성과 같은 특정 애플리케이션 요구 사항에 따라 생성됩니다. 중요도가 높거나 비즈니스가 아닌 트래픽도 우선순위가 높은 애플리케이션 및 서비스에 영향을 주지 않도록 제어할 것입니다.
트래픽 클래스를 생성하려면 네트워크 사용률, 특정 애플리케이션 요구 사항 및 비즈니스 애플리케이션 우선 순위에 대한 기본적인 이해가 필요합니다. 애플리케이션 요구 사항에는 패킷 크기에 대한 지식, 시간 초과 문제, 지터 요구 사항, 버스트 요구 사항, 배치 요구 사항 및 전반적인 성능 문제가 포함됩니다. 이러한 정보를 바탕으로 네트워크 관리자는 다양한 LAN/WAN 토폴로지에서 보다 일관된 애플리케이션 성능을 제공하는 트래픽 셰이핑 계획 및 구성을 생성할 수 있습니다.
예를 들어 한 조직은 두 주요 사이트 사이에 10메가비트 ATM 연결을 보유하고 있습니다. 대용량 파일 전송으로 인해 링크가 혼잡해지기도 하는데, 이로 인해 온라인 트랜잭션 처리의 성능이 저하되고 음성 품질이 저하되거나 사용할 수 없게 됩니다.
조직은 4개의 서로 다른 트래픽 클래스를 설정했습니다. 음성의 우선 순위가 가장 높았으며, 음성이 예상 트래픽 볼륨 비율보다 높은 경우에도 해당 우선 순위를 유지할 수 있도록 했습니다. 중요 애플리케이션 클래스에는 그 다음으로 높은 우선순위가 부여되었지만 총 링크 크기(예상 음성 대역폭 요건 미만)에서 버스트할 수 없었습니다. 터지면 떨어집니다. 파일 전송 트래픽은 우선 순위가 더 낮고 다른 모든 트래픽은 중간에 맞아야 합니다.
이제 조직은 이 링크에서 QoS 관리를 수행하여 각 클래스에서 얼마나 많은 트래픽을 처리하고 각 클래스 내의 성능을 측정해야 합니다. 조직에서 이를 수행하지 않으면 일부 클래스에 대해 기아가 발생하거나 특정 클래스 내에서 성능 SLA가 충족되지 않을 수 있습니다.
툴 부족으로 인해 QOS 컨피그레이션 관리가 여전히 어려운 작업입니다. 한 가지 방법은 Cisco의 IPM(Internet Performance Manager)을 사용하여 각 트래픽 클래스에 속하는 링크를 통해 서로 다른 트래픽을 전송하는 것입니다. 그런 다음 각 클래스의 성능을 모니터링할 수 있으며 IPM은 추세 분석, 실시간 분석 및 hop-by-hop 분석을 제공하여 문제 영역을 정확히 찾아냅니다. 다른 트래픽은 인터페이스 통계를 기반으로 각 트래픽 클래스 내에서 큐잉 및 삭제된 패킷을 조사하는 것과 같은 보다 수동적인 방법을 계속 사용할 수 있습니다. 일부 조직에서는 이 데이터를 SNMP를 통해 수집하거나 베이스라인 및 트렌드 분석을 위해 데이터베이스로 구문 분석할 수 있습니다. 특정 서비스 또는 애플리케이션의 성능을 확인하기 위해 네트워크 전반에 특정 트래픽 유형을 전송하는 일부 툴도 시장에 있습니다.
능력 정보 수집 및 보고
용량 정보 수집 및 보고는 세 가지 권장 용량 관리 영역과 연계되어야 합니다.
-
What-if 분석 - 네트워크 변화를 중심으로 하며 변화가 환경에 미치는 영향
-
기준 설정 및 추세 분석
-
예외 관리
이러한 각 영역 내에서 정보 수집 계획을 수립합니다. 네트워크 또는 애플리케이션 what-if 분석의 경우 네트워크 환경을 모방하고 디바이스 제어 평면 또는 데이터 평면 내의 잠재적 리소스 문제와 관련된 변화의 영향을 이해하는 도구가 필요합니다. 베이스라인 적용 및 추세 분석의 경우, 현재 리소스 사용률을 보여주는 디바이스 및 링크에 대한 스냅샷이 필요합니다. 그런 다음 시간이 지남에 따라 데이터를 검토하여 잠재적 업그레이드 요구 사항을 파악합니다. 따라서 네트워크 관리자는 용량 또는 성능 문제가 발생하기 전에 업그레이드를 적절히 계획할 수 있습니다. 문제가 발생하면 네트워크 관리자에게 알림이 전달되어 네트워크를 조정하거나 문제를 해결할 수 있습니다.
이 프로세스는 다음 단계로 나눌 수 있습니다.
-
요구 사항 파악
-
프로세스를 정의합니다.
-
용량 영역을 정의합니다.
-
능력 변수를 정의합니다.
-
데이터를 해석합니다.
요구 사항 파악
용량 및 성능 관리 계획을 개발하려면 필요한 정보와 해당 정보의 목적을 이해해야 합니다. 계획을 세 가지 필수 영역으로 분할합니다. what-if 분석, 베이스라인 적용/추세 분석, 예외 관리에 대해 각각 하나씩 제공합니다. 각 영역에서 어떤 리소스와 툴을 사용할 수 있는지, 무엇이 필요한지 파악합니다. 많은 조직에서 툴의 기술과 기능을 고려하지만 툴을 관리하는 데 필요한 사람과 전문성을 고려하지 않기 때문에 툴 구축에 실패하고 있습니다. 필요한 인력과 전문 지식을 계획에 포함시키고 프로세스 개선 이러한 인력에는 네트워크 관리 스테이션을 관리하는 시스템 관리자, 데이터베이스 관리를 지원하는 데이터베이스 관리자, 툴을 사용하고 모니터링하는 교육을 받은 관리자, 정책, 임계값 및 정보 수집 요구 사항을 결정하는 상위 레벨 네트워크 관리자가 포함될 수 있습니다.
프로세스 정의
또한 툴을 성공적으로 일관성 있게 사용할 수 있는 프로세스가 필요합니다. 임계값 위반이 발생할 때 네트워크 관리자가 수행해야 하는 작업이나 네트워크 베이스라인 적용, 트렌드 분석, 업그레이드를 위해 수행해야 할 프로세스를 정의하기 위해 프로세스 개선이 필요할 수 있습니다. 성공적인 용량 계획을 위한 요구 사항 및 리소스를 결정하면 이 방법론을 고려할 수 있습니다. 많은 조직에서는 이러한 유형의 기능을 INS와 같은 네트워크 서비스 조직에 아웃소싱하거나, 서비스를 핵심 역량으로 간주하여 사내에 전문성을 구축합니다.
능력 영역 정의
용량 계획 계획에는 용량 영역에 대한 정의도 포함되어야 합니다. 다음은 공통 용량 계획 전략을 공유할 수 있는 네트워크 영역입니다. 예를 들어 기업 LAN, WAN 현장 사무실, 중요한 WAN 사이트, 전화 접속 액세스 등이 있습니다. 다른 영역을 정의하는 것은 여러 가지 이유로 유용합니다.
-
상이한 영역들은 상이한 임계값들을 가질 수 있다. 예를 들어 LAN 대역폭은 WAN 대역폭보다 훨씬 저렴하므로 사용 임계값은 더 낮아야 합니다.
-
영역마다 다른 MIB 변수를 모니터링해야 할 수 있습니다. 예를 들어 프레임 릴레이의 FECN 및 BEN 카운터는 프레임 릴레이 용량 문제를 이해하는 데 중요합니다.
-
네트워크의 일부 영역을 업그레이드하는 것은 더 어렵거나 시간이 오래 걸릴 수 있습니다. 예를 들어, 국제 회선은 리드 타임이 훨씬 더 길며 그에 상응하는 더 높은 수준의 계획이 필요할 수 있습니다.
능력 변수 정의
다음으로 중요한 영역은 모니터링할 변수와 조치가 필요한 임계값을 정의하는 것입니다. 용량 변수를 정의하는 것은 네트워크 내에서 사용되는 장치 및 미디어에 따라 달라집니다. 일반적으로 CPU, 메모리 및 링크 사용률과 같은 매개 변수는 유용합니다. 그러나 특정 기술이나 요구 사항에 대해서는 다른 영역이 중요할 수 있습니다. 여기에는 대기열 깊이, 성능, 프레임 릴레이 혼잡 알림, 백플레인 사용률, 버퍼 사용률, netflow 통계, 브로드캐스트 볼륨 및 RMON 데이터가 포함될 수 있습니다. 장기적인 계획을 염두에 두되, 성공을 보장할 수 있는 몇 가지 핵심 영역으로만 시작하십시오.
데이터 해석
수집된 데이터를 이해하는 것도 고품질 서비스 제공의 핵심이다. 예를 들어, 많은 조직이 최고 및 평균 활용률 수준을 완전히 이해하지 못하고 있습니다. 다음 다이어그램은 5분 SNMP 수집 간격을 기준으로 한 용량 매개변수 피크(녹색으로 표시됨)를 보여줍니다.
보고된 값이 임계값(빨간색으로 표시됨) 미만이었지만 수집 간격 내에서 임계값(파란색으로 표시됨) 이상의 피크가 발생할 수 있습니다. 이는 수집 간격 동안 조직이 네트워크의 성능 또는 용량에 영향을 주는 피크 값을 경험하고 있을 수 있다는 점에서 중요합니다. 유용하고 과도한 오버헤드를 발생시키지 않는 의미 있는 수집 간격을 신중하게 선택해야 합니다.
또 다른 예는 평균 사용률입니다. 직원이 8시부터 5시까지 사무실에 있을 뿐이지만 평균 활용도가 7X24인 경우 정보가 오해의 소지가 있을 수 있습니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
04-Oct-2005 |
최초 릴리스 |
피드백