문제
패킷 손실의 소스를 파악하고 이유를 찾는 것은 항상 쉬운 일이 아닙니다. 패킷은 인터넷을 통해 여러 ISP 및 조직이 소유한 여러 네트워크를 통과하며, 링크 상태 및 CPU 부하와 같은 정보를 확인하기 위해 경로상의 모든 라우터에 접근할 수 없습니다. 게다가, 패킷 손실은 네트워크 경로의 어떤 지점에서도 발생할 수 있습니다.
가능한 원인
패킷이 경로를 따라 손실될 수 있는 이유는 여러 가지가 있습니다. 몇 가지 일반적인 원인은 다음과 같습니다:
- ISP 피어링 문제
- 링크 혼잡
- 잘못된 구성 (대역폭 설정 또는 NIC 속도 및 듀플렉스)
- 하드웨어 고장
- 네트워크 장치의 높은 CPU 사용량
- 마이크로버스트 처리
Cato에서 패킷 손실 이해하기
Cato 관리 애플리케이션의 분석 화면을 사용하여 Cato에서의 패킷 손실을 식별하는 것이 좋습니다. 패킷 손실 및 버려짐 그래프는 시간에 따른 패킷 손실을 보여주고 특정 시간대에 집중할 수 있게 해줍니다. 이 그래프들은 패킷 손실이 발생했는지, 그리고 과거에 언제 발생했는지를 식별하는 데 유용합니다. 또한 패킷 손실의 유형을 식별할 수 있습니다: 공급업체 손실 또는 Cato 버려짐.
참고: 분석 그래프에서 가장 작은 데이터 버킷 샘플 크기는 5초입니다. 따라서, 5ms 이내의 마이크로버스트는 표시된 평균값 내에서 정규화되며 분석 그래프에 피크로 표시되지 않습니다.
1. 공급업체 손실
이것은 소켓과 PoP 사이의 패킷 손실의 예입니다. 대부분의 공급업체 패킷 손실은 Cato의 제어 외부에 있는 최종 구간의 네트워크 연결 문제로 인해 발생하지만, Cato와 관련된 문제를 반드시 배제할 수는 없습니다.
Cato가 공급업체 손실을 측정하는 방법
공급업체 손실은 소켓과 PoP 모두에서 주어진 링크에서 전송된 패킷 수와 수신된 패킷 수를 비교하여 측정됩니다.
- 하향 패킷 손실은 PoP에서 전송된 패킷 수와 소켓에서 수신된 패킷 수의 차이를 백분율로 표현한 것입니다.
공식:
- 상향 패킷 손실은 소켓에서 전송된 패킷 수와 PoP에서 수신된 패킷 수의 차이를 백분율로 표현한 것입니다.
공식:
Cato가 공급업체 패킷 손실을 계산하는 방식으로 인해, 즉시 ISP에 모든 책임을 전가할 수 없습니다. 소켓과 ISP 라우터 사이에 패킷 손실에 기여하는 장비가 있거나 ISP의 통제 범위를 넘어 PoP에 더 가까운 네트워크 경로에 문제가 있을 가능성이 있습니다.
2. Cato 버려짐
Cato 버려짐 패킷 손실은 Cato QoS에 의해 발생합니다. QoS 엔진은 링크 혼잡 시 낮은 우선순위 패킷을, 트래픽 버스트 중에는 모든 우선순위에서 패킷을 버리기 시작합니다. 링크에 대한 구성 대역폭과 전체 처리량이 일치할 때 혼잡이 발생합니다. BW 관리 우선 순위가 엄격한 처리량 제한으로 활성화됨되어 있고 해당 우선순위에 맞는 트래픽이 제한에 도달하면 Cato 또한 패킷을 버립니다. Cato 버려짐 패킷 손실은 예상된 행동이며 반드시 문제가 있다는 신호는 아닙니다.
Cato 버려짐 패킷 손실과 관련된 문제는 잘못된 구성으로 인해 발생할 가능성이 높습니다. VoIP와 같은 심각 애플리케이션에는 가장 높은 BW 관리 우선순위를 부여해야 합니다. 혼잡이 발생하면 Cato는 낮은 우선순위의 트래픽을 삭제하지만, 높은 우선순위의 트래픽은 삭제되지 않습니다. 항상 트래픽에 적절한 대역폭 관리 우선순위를 할당해야 합니다.
분석은 패킷 손실에 대한 광범위한 보기를 제공합니다. 그러나 Cato에서 버려진 패킷 손실을 처리하는 경우가 아니라면, 분석만으로는 패킷 손실의 원인이나 발생 위치를 알려줄 수 없습니다.
패킷 손실 문제 해결 방법
1. 패킷 손실 범위 결정
시작할 때, 누가 또는 무엇이 패킷 손실을 경험하는지 알아내는 것이 정말 중요합니다. 사이트의 모든 사용자가 패킷 손실을 경험하는지, 아니면 특정 엔드포인트에만 국한되는지 확인합니까? 패킷 손실이 인터넷에서 발생하는지, WAN에서 발생하는지 확인하세요? 여러 사이트가 패킷 손실로 인해 영향을 받는지, 아니면 단일 사이트만 영향을 받는지 확인하세요? 모든 트래픽이 영향을 받는지 아니면 특정 애플리케이션만 영향을 받는지 확인하세요? 패킷 손실이 지속적인지 아니면 간헐적으로 발생하는지 확인하세요?
위 질문의 답을 알면 관련 CMA 이벤트를 식별하는 데 도움이 되며 문제 해결 과정에서 시간을 절약할 수 있습니다. 사전에 더 많은 세부 정보를 알수록 문제 해결에 집중할 수 있습니다.
2. 사이트 분석 확인 - 패킷 손실 그래프
사이트의 분석 패킷 손실 그래프에 패킷 손실이 표시됩니까? 패킷 손실 및 버려진 패킷을 표시할 수 있는 분석 그래프를 기반으로 다른 권장 사항이 있습니다.
패킷 손실 없음
분석 화면에 패킷 손실이 표시되지 않더라도 패킷 손실이 존재할 수 있습니다. 로컬 네트워크에 문제가 있을 수 있으며, PoP 관련 문제일 수도 있습니다. UI 네트워크 도구를 사용하여 소켓에서 LAN 쪽 IP로 핑을 보내는 것은 근본 원인을 식별하는 좋은 방법이 될 수 있습니다.
패킷 손실
그래프에 패킷 손실이 표시되는 경우 대역폭 구성오류로 인해 발생할 수 있습니다. 아래 대역폭 구성 확인에서 설명한 대로 구성된 대역폭을 확인하세요.
공급업체의 패킷 손실의 경우 트래픽이 급증할 때만 삭제가 발생하는지 확인하세요. 그러한 경우 애플리케이션 분석 페이지를 사용하여 급증을 초래하는 트래픽을 식별하세요. 제한적인 대역폭 관리 프로필에 애플리케이션 트래픽을 할당하여 제한할 수 있습니다.
일반적으로 처리량이 낮지만 급증으로 인해 패킷 손실이 발생하는 경우가 종종 있습니다. ISP의 트래픽 형태 정책과 Cato의 트래픽 형태 정책이 서로 다른 급증성 정책을 가질 수 있습니다. 급증성에 대한 추가 정보는 아래 미세 급증 확인을 참조하십시오
3. 사이트 분석 확인 - 버려진 패킷 그래프
Cato가 버려진 패킷의 경우에도 대역폭 우선순위를 조사해야 합니다. 사이트의 분석 화면에서 우선 순위 분석기를 확인하여 어떤 우선순위가 삭제되었는지 보세요. 우선순위 섹션을 확장하여 해당 우선 순위의 주요 애플리케이션을 확인할 수 있습니다. 패킷 손실이 특정 애플리케이션에만 영향을 미치는 경우 네트워크 규칙에서 해당 애플리케이션의 우선순위를 높여야 할 수도 있습니다. 기억하세요, 카토 QoS는 혼잡이 발생할 때 낮은 우선순위의 패킷을 삭제하도록 설계되어 있으므로, 카토 폐기 패킷 손실이 항상 문제가 되는 것은 아닙니다.
카토 QoS는 큐 내에 발생하는 급증으로 인해 우선순위에 상관없이 모든 패킷을 삭제할 수 있습니다. 이러한 동작은 폭발 관리 특성상 예상되는 것입니다. 우선 순위 분석기 페이지를 사용하여 패킷이 폐기되는 시점과 트래픽 폭발이 동시에 발생하는지 확인할 수 있습니다. 자세한 내용은 소켓 트래픽 우선순위 및 QoS를 참조하세요.
우선 순위 분석기는 분석 화면에서 각 QoS 우선순위에 대한 상향 및 하향 패킷 손실을 표시합니다.
4. (선택 사항) 마지막 마일/경험 모니터링
경험 모니터링 라이선스를 가진 고객은 최종 구간과 애플리케이션 성능 탭을 통해 가능한 패킷 손실 및 패킷 폐기를 확인할 수 있습니다. 데이터는 사이트 네트워크 분석 페이지의 결과와 연관되어 문제의 출처를 더 잘 이해할 수 있습니다.
5. 사이트 분석 확인 - 마지막 마일 패킷 손실
ISP가 문제를 겪고 있는지 평가하기 위해, 분석 화면의 최종 구간 탭을 사용하여 WAN 링크에서 나타나는 지연 시간 변화나 패킷 손실을 확인하세요. 공급업체의 패킷 손실과 달리, 최종 구간 데이터는 인기 있는 웹사이트로의 ICMP 테스트를 기반으로 합니다. 추천사항으로, 핑 가능한 추가 서비스 IP들을 최종 구간 모니터링 페이지에 추가할 수 있습니다. 예를 들어, VoIP 관련 문제가 있다면 SIP 서버 IP를 IP 중 하나로 설정할 수 있습니다.
ISP 관련 패킷 손실이 의심되는 경우, ISP에게 다음 질문을 하세요:
- UDP/443 또는 UDP/1337 (DTLS) 트래픽에 QoS를 적용하고 있습니까?
- PoP IP로 가는 패킷 손실을 초래할 수 있는 UDP 트래픽에 DoS 보호를 적용합니까?
- 포P IP로 가는 경로에 있는 라우터에 혼잡이나 높은 CPU 사용량이 있습니까?
- 구독한 라인 속도를 초과하는 급증을 허용합니까?
6. 대역폭 구성 확인
패킷 손실은 링크 혼잡에 의해 발생할 수 있으며, 각 WAN 링크에 대한 대역폭이 카토 관리 애플리케이션에 올바르게 구성되어 있는 것이 중요합니다. 구성된 대역폭이 사이트 설정에서 ISP가 제공하는 것과 일치하는지 확인하세요. 카토 사이트 라이선스의 조건에 따라 소켓 WAN 인터페이스 대역폭 설정을 구성하세요.
Azure/AWS 환경은 전통적인 대역폭 제한이 없습니다. 대신 vSocket이 지원하는 대역폭을 초과하지 않도록 사이트에 구성된 대역폭은 제한되어야 합니다. Azure의 경우, 21 버전부터 Standard_D8ls_v5 VM 크기는 최대 2Gbps를 지원합니다. AWS에서는 c5n.xlarge 인스턴스 크기가 2Gbps를 초과하는 대역폭을 제공합니다. 사이트에 설정된 대역폭이 지원되는 한계 내에 있어야 최적의 성능을 유지할 수 있습니다.
구성된 대역폭이 ISP가 제공하는 것보다 낮으면, 구성된 대역폭 한계를 초과할 때 카토의 QoS 엔진이 패킷을 삭제할 수 있습니다. 이 경우, 사이트의 분석 처리량 그래프에 사이트에 설정된 대역폭과 동일한 평면선이 나타나고 카토에 의해 삭제된 패킷도 같이 나타납니다.
설정이 올바르게 구성되더라도 ISP 링크가 혼잡하면 동일한 동작이 발생할 수 있습니다. 이러한 동작이 문제를 보장하지는 않지만, 이 상황에서 대역폭이 올바르게 구성되어 있는 것을 확인하는 것이 좋습니다.
구성된 대역폭이 ISP에서 제공하는 것을 초과할 경우, ISP의 대역폭 한도를 초과하면 Cato의 QoS 엔진이 작동하지 않으므로 ISP가 임의로 패킷을 버릴 수 있습니다. 이 경우, 사이트 분석 처리량 그래프에서 활성화된 대역폭 수준 아래에 평탄한 선과 함께 공급업체의 패킷 손실이 표시됩니다.
각 소켓 모델별 소켓 처리량 및 용량 정보는 소켓 데이터 시트에 있으며, 이 문서를 참조하십시오. X1700, X1600 & X1500 소켓 가이드.
7. 소켓 CPU 성능 확인
소켓 웹UI에서 HW 상태 탭을 선택합니다. 이렇게 하면 각 코어의 현재 CPU 사용량이 표시됩니다. 일관된 CPU 사용량이 90%를 초과하면 소켓 성능에 직접적인 영향을 미치고 패킷 손실과 높은 지연 시간을 초래할 수 있습니다. 네트워크에서 패킷 손실이 발생했을 때 지속적인 높은 CPU가 관찰될 경우, 지원팀에 문의하십시오.
8. 사이트 재연결 제외
사이트가 Cato 클라우드로 재연결되는 과정에서 패킷 손실이 발생할 수 있습니다. 패킷 손실이 재연결 이벤트와 관련이 있는지 확인하려면 홈페이지 > 이벤트를 확인하십시오. 이벤트를 하위 유형 = '재연결됨'으로 필터링하십시오.
재연결 이벤트는 연결 해제의 이유를 설명하는 메시지를 표시합니다. 자세한 내용은 재연결 이벤트 이해를 참조하십시오
9. Cato 우회
인터넷에서의 패킷 손실을 해결하려면 Cato 클라우드의 문제를 빠르게 해결하기 위해 소스 또는 목적지를 우회를 설정하십시오. 이를 수행하는 가장 쉬운 방법은 사이트 설정에서 단일 사용자의 IP 주소에 대한 소스 우회를 설정하고 패킷 손실이 계속되는지 확인하는 것입니다. 패킷 손실이 계속되는 경우, 문제는 LAN, 소켓 또는 ISP에 있을 수 있지만 문제는 PoP와 관련이 없을 것입니다.
10. Ping 테스트 실행
패킷 손실의 영향을 받는 소스와 목적지 IP 주소 사이에서 연속적인 핑을 시작합니다. 핑은 추적하기 쉽고 패킷 캡처에서 분석할 수 있습니다. 일부 핑 요청이 목적지에 도착하지 않으면 패킷 손실이 발생할 수 있으며 요청 시간 초과로 표시됩니다
소켓 UI에서도 호스트명이나 IP로 핑 도구를 사용하여 핑을 할 수 있습니다. Cato 또는 WAN 링크를 통해 핑을 보낼 인터페이스를 선택할 수 있습니다. 핑 결과의 패킷 손실이나 높은 지연 시간과 같은 불일치를 찾습니다. Cato를 사용하든 사용하지 않든 패킷 손실이 있다면, ISP 문제일 수 있습니다. 또한 링크 중 하나가 4G/LTE인 경우, 이러한 링크는 패킷 손실에 더 민감함을 기억해야 합니다.
UI는 10개의 핑 요청만 보내므로, 추가 핑이 필요하면 PING 버튼을 다시 클릭해야 합니다.
참고: Ping 테스트는 기본 네트워크 상태를 확인하는 데 좋지만, 핑이 손실되지 않는다고 해서 깨끗한 선을 나타내는 것은 아닙니다.
11. 트레이스라우트 테스트 실행 중
트레이스라우트는 출발지와 목적지 간의 라우터(홉)를 식별하는 데 사용됩니다. 각 홉의 패킷 손실과 지연 시간을 표시합니다.
트레이스라우트는 트레이스라우트 도구를 사용하여 소켓 UI에서 실행할 수 있습니다. 트레이스라우트를 실행하여 소켓과 목적지 사이의 WAN 링크의 모든 홉에서 패킷 손실이나 예기치 않은 높은 지연 시간이 있는지 찾습니다. UI는 각 홉에 대해 하나의 패킷만 전송하고 각 홉의 패킷 손실을 표시합니다. 하나의 패킷만 전송되므로 0% 또는 100% 손실만 볼 수 있습니다.
트레이스라우트 결과 분석
단일 홉의 패킷 손실이 문제의 신호가 아님을 인지해야 합니다. 단일 홉은 라우터에서 ICMP가 활성화되지 않았기 때문에 100% 패킷 손실을 보일 수 있습니다. ICMP 속도 제한으로 인해 문제 없이 100% 미만의 패킷 손실이 발생할 수 있습니다. 하나의 홉에서 약간의 패킷 손실이 발생하고 다음 홉에서 0% 손실이 발생하는 경우, 이는 ICMP 속도 제한 때문일 수 있습니다.
패킷 손실에 실제 문제가 있는 경우, 이는 하나의 홉에서 시작하여 다수의 홉에 걸쳐 계속되며 각 홉에서 패킷 손실을 표시합니다. 경로의 여러 라우터가 패킷 손실에 기여할 수도 있으므로 각 홉에서 패킷 손실량이 다를 수 있습니다. 예를 들어, 경로에는 8개의 홉이 있고 트레이스라우트는 3-7 홉의 패킷 손실을 보여줍니다.
12. 패킷 손실을 감지하기 위해 높은 트래픽 부하 생성
실시간 화면은 현재의 처리량 변화를 감지하여 즉각적인 패킷 손실과 폐기된 패킷을 식별하는 데 도움이 될 수 있습니다. 높은 부하를 시뮬레이션하고 문제 해결 중 높은 수요로 인한 패킷 손실을 재현하기 위해 소켓의 속도 테스트 도구를 사용하세요.
소켓 S 속도 테스트 결과는 Cato 관리 애플리케이션에서 링크에 대해 구성된 대역폭에 가깝게 예상됩니다. DTLS 터널 오버헤드(117바이트)가 처리량을 약간 감소시킬 수 있음을 인지하세요.
테스트는 링크를 포화시키고 네트워크 분석 화면에서 ISP 관련 패킷 손실을 표시할 것입니다. 구성된 링크 대역폭이 ISP에서 제공한 대역폭보다 낮은 경우, 테스트를 실행할 때 패킷이 버려질 것으로 예상됩니다.
직접 속도 테스트
WAN 포트를 통해 직접 속도 테스트를 실행할 때, 상향 결과는 Cato 관리 애플리케이션에 구성된 대역폭 라이선스와 가깝게 나와야 합니다. 소켓은 사이트의 대역폭 라이선스에 따라 상향 직접 속도 테스트에 여전히 QOS를 사용할 것입니다. 반면에, 하향 결과는 로컬 ISP의 전체 용량을 보여줄 것입니다.
13. iPerf를 사용하여 링크를 테스트합니다
소켓 웹UI를 사용하여 iPerf 도구를 사용하여 소켓과 연결된 Cato Cloud의 PoP 간의 라스트 마일 성능 문제를 해결할 수 있습니다. iPerf 클라이언트를 실행 중인 소켓은 연결된 PoP에서 실행 중인 iPerf 서버에 대해 테스트를 수행합니다.
Cato를 통해 소켓 UI의 도구 페이지에서 WAN을 직접 통해 iPerf 테스트를 실행합니다. 프로토콜로 UDP를 선택하고(TCP 흐름 제어를 배제하기 위해) 방향(상향 또는 하향)과 목표 속도를 구성된 대역폭으로 설정합니다. 이 도구는 Cato와 WAN을 통한 처리량이 예상대로인지 확인하는 데 더 효과적입니다. DTLS 터널 오버헤드(117 바이트)는 처리량을 약간 줄일 수 있습니다.
아래 예시에서는 목표 속도를 45Mbps로 설정하고(이는 Cato 관리 애플리케이션에서 구성된 대역폭과 동일) 수신 속도가 예상보다 낮으며 패킷 손실률은 3.7%입니다.
14. 링크 집계(LAG) 링크 점검
패킷 손실과 높은 지연 시간은 소켓과 내부 스위치 간의 링크 집계(LAG) 설정 오류로 인해 발생할 수 있습니다. 이 특정 문제는 네트워크 분석에서 감지할 수 없으며, LAN 내에서 문제를 해결해야 합니다. Cato는 정적 LAG만 지원하며 LAG 피어는 동일한 모드를 지원해야 합니다. LAG 구성 불일치는 패킷 손실을 초래합니다.
추가 문제 해결 정보는 링크 집계(LAG) 링크에서 높은 지연 시간과 패킷 손실 경험에서 확인하세요.
15. 소켓의 링크 속도 점검
공급업체 손실의 가능한 원인은 소켓 링크가 반이중으로 실행되는 것입니다. 이는 패킷이 한 번에 하나의 방향(아웃바운드 또는 인바운드)으로만 이동할 수 있음을 의미하며, 이로 인해 처리량이 크게 줄고 패킷 손실이 발생하게 됩니다. 모든 소켓 링크는 항상 예외 없이 전이중이어야 합니다.
또한 WAN 및 LAN 링크 속도가 사이트에 대해 구성된 대역폭과 동일하거나 그 이상인지 확인하십시오. 링크 속도는 처리량의 제한 요소일 수 있습니다. 예를 들어, 사이트에 구성된 대역폭이 200 Mbps인데 LAN 링크가 100 Mbps 전이중으로만 협상되었다면, 소켓에 연결된 컴퓨터는 100 Mbps 이상의 처리량을 달성할 수 없습니다.
링크 상태를 확인하려면 소켓 UI에 로그인하여 모니터링 페이지에서 링크 상태를 보십시오. 아래 예시는 100 Mbps 반이중 상태의 WAN1 링크를 보여줍니다.
반이중 상태이거나 잘못된 속도로 설정된 링크가 보이면, 소켓의 링크가 연결된 장치의 포트 설정을 확인하세요. 자동 협상을 설정하거나 소켓의 속도 설정과 일치하도록 합니다. 모든 소켓 링크는 기본적으로 자동 협상으로 설정되지만, 네트워크 설정 페이지에서 속도를 강제로 설정할 수 있습니다.
다른 장치의 포트 설정이 올바르면, 이더넷 케이블이 손상될 수 있습니다. 알려진 좋은 케이블로 교체하고 듀플렉스나 속도가 변경되는지 확인하십시오. 그래도 해결되지 않으면, 노트북 컴퓨터나 다른 장치를 소켓의 포트에 연결하고 링크 상태를 점검하세요. 다른 장치에서도 동일하게 하십시오. 소켓의 링크가 예상된 속도와 전이중으로 연결되지만 다른 장치의 링크가 그렇지 않다면, 문제는 다른 장치에 있다는 것을 알 수 있습니다.
16. 중복 IP 점검
네트워크에서 패킷 손실을 유발할 수 있는 소켓 레벨의 또 다른 문제는 중복 IP입니다. 소켓은 일반적으로 구성된 인터페이스 IP 주소와의 IP 충돌을 감지할 수 있습니다. 같은 네트워크의 두 장치에 동일한 IP 주소가 할당되면 IP 충돌이 발생합니다. 이러한 경우 소켓 UI의 모니터링 페이지에서 아래의 오류를 볼 수 있습니다.
정적 IP 주소가 WAN 인터페이스에 구성될 때, 중복된 IP가 감지되지 않을 수 있습니다. 이는 소켓이 IP 충돌을 수동으로 모니터링하기 때문입니다. 소켓이 충돌 중인 IP를 가진 장치에서 ARP를 수신한 경우에만 IP 충돌을 감지합니다.
IP 주소 충돌 문제가 해결되면, 경고가 WebUI에서 사라지는 데 최대 24시간이 걸릴 수 있습니다. 참조 문제가 해결된 후에도 소켓 UI에 보고된 IP 주소 충돌
17. 마이크로 버스트 확인
패킷 손실의 또 다른 잠재적 원인은 마이크로 버스트(버스티니스)입니다. 마이크로 버스트는 매우 짧은 시간 동안 발생하는 패킷 또는 데이터 프레임의 갑작스러운 증가를 특징으로 하며, 일반적으로 몇 마이크로초에서 밀리초까지만 지속됩니다. 마이크로 버스트가 발생하고 링크의 속도 제한을 초과할 경우, 제공업체 (ISP)는 과도한 트래픽을 삭제할 수 있으며, 이는 패킷 손실을 초래합니다.
아래 그래프에서 마이크로 버스트로 인한 일반적인 패킷 손실과 버스티니스 값 설정을 조정한 후의 개선을 볼 수 있습니다.
위 예시에서 버스티니스 수준 값은 기본값인 0.2에서 0.01로 수정되었습니다. 이는 소켓과 PoP가 트래픽에 대해 더 공격적이게 형상을 적용하여 패킷 손실 문제를 해결합니다.
패킷 손실을 완화하기 위한 버스티니스 수준 설정 조정
상향 및 하향 방향으로 적용되는 기본 버스티니스 값은 0.2입니다. 이 값으로, 소켓과 PoP는 패킷을 미디어에 최대한 빠르게 직렬화하여 시간 범위 버킷의 첫 번째 마이크로초에 더 많은 바이트를 전송할 수 있습니다. 이 설정은 직렬화 지연과 전체 지연 시간을 줄여 성능을 최적화합니다.
이 문제 해결 단계의 일환으로, 패킷 손실이 완화될 때까지 버스티니스 수준을 점진적으로 줄여야 합니다. 버스티니스 수준 값을 줄이면, 소켓과 PoP는 트래픽에 더 공격적인 형상을 적용하여 마이크로 버스트를 부드럽게 만듭니다. 구성할 수 있는 가장 낮은 값은 0.001입니다.
버스티니스 수준을 조정하기 위한 모범 사례는 값을 점진적으로 줄이는 것입니다 (예: 0.2에서 0.18로). 값을 줄인 후, 사이트 모니터링 실시간 또는 네트워크 분석 화면에서 패킷 손실을 분석하여 영향을 모니터링하십시오. 사이트 메트릭스는 일반적으로 몇 분 정도 업데이트되는 데 걸린다는 점을 염두에 두십시오. 패킷 손실이 완화될 때까지 버스티니스 값을 계속 줄이십시오.
이 절차로 패킷 손실이 해결되지 않는다면, 이는 마이크로 버스트가 아닌 다른 이유로 인해 발생한 것입니다. 이 경우, 기본 버스티니스 값인 0.2로 복원하고 지원 문의하기 를 통해 추가 지원을 받으십시오.
버스티니스 수준 수정
버스티니스 수준은 상향 및 하향 방향으로 조정할 수 있습니다. 이 설정은 사이트의 모든 WAN 링크에 영향을 줍니다.
구성은 사이트 레벨 또는 계정 레벨에서 적용됩니다. 사이트 레벨의 구성은 계정 레벨보다 우선합니다.
버스티니스 수준을 구성하려면:
- 네비게이션 메뉴에서 자원 > 고급 구성을 선택하여 계정 수준의 설정 또는 사이트 설정 > 고급 구성을 선택하여 사이트 수준의 설정을 하십시오.
- 버스트 하향 값 또는 버스트 상향 값을 선택하십시오.
- 설정을 활성화하고 값을 0.001 - 0.2 범위 내로 조정하세요.
- 적용을 클릭하세요
- 저장을 클릭하세요
참고:
- 버스트네스가 Cato 지원에 의해 사전에 조정된 경우, 기본값 0.2 대신 조정된 값이 표시됩니다
- 버스트네스 값은 소켓 사이트에 대해서만 조정할 수 있습니다
- Cato 관리 애플리케이션에서 가장 작은 데이터 버킷은 5초이며, 마이크로버스트는 가장 작은 데이터 버킷에서 표준화되어 일반적으로 식별하기 어렵습니다.
댓글 0개
댓글을 남기려면 로그인하세요.