Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지 내용
 

애플리케이션 체감 품질

AppQoE(Application Quality of Experience)

애플리케이션 QoE(Quality of Experience) 소개

클라우드 컴퓨팅, 모빌리티 및 웹 기반 애플리케이션이 끊임없이 성장함에 따라 네트워크는 애플리케이션 수준에서 트래픽을 식별 및 제어하고 각 애플리케이션 유형을 개별적으로 처리하여 사용자에게 QoE(Qualityof Experience)를 제공해야 합니다. AppQoE(애플리케이션별 QoE)를 보장하려면 성능이나 가용성을 손상시키지 않으면서 애플리케이션 트래픽의 우선순위를 효과적으로 지정하고, 분리하고, 라우팅해야 합니다.

AppQoE는 AppID(애플리케이션 식별) 및 APBR(고급 정책 기반 라우팅)이라는 두 가지 애플리케이션 보안 서비스의 기능을 활용(또는 채용)합니다. AppID를 사용하여 네트워크에서 특정 애플리케이션을 식별하고, 고급 정책 기반 라우팅(APBR)을 사용하여 APBR 규칙에 따라 애플리케이션 트래픽이 전송되는 라우팅 인스턴스에 SLA 프로필을 연결하여 특정 트래픽에 대한 경로를 지정합니다.

소프트웨어 정의 WAN(SD-WAN)의 중요한 요구 사항 중 하나는 언더레이 네트워크 경로의 품질을 측정하고 그 결과에 따라 각 패킷의 전달에 사용할 최적의 경로를 결정하는 것입니다. AppQoE는 비즈니스 크리티컬 애플리케이션의 성능을 모니터링하고, 점수에 따라 SLA(서비스 수준 계약)에 지정된 성능 요구 사항을 충족하기 위해 해당 애플리케이션 트래픽에 가장 적합한 링크를 선택합니다.

APBR 구성에 SLA 규칙이 있으면 AppQoE 기능이 트리거됩니다. 사용 가능한 SLA 프로필이 없는 경우 APBR은 AppQoE를 트리거하지 않고 작동합니다.

지원되는 사용 사례

CSO(Contrail Service Orchestration)를 사용하여 AppQoE를 최적으로 구성할 수 있습니다. CSO를 사용하여 주니퍼 네트웍스 Contrail SD-WAN 솔루션에 대한 AppQoE를 구성하는 것이 좋습니다. 자세한 내용은 Application Quality of Experience Overview(애플리케이션 경험 품질 개요 ) 및 Configure and Monitor Application Quality of Experience(애플리케이션 경험 품질 구성 및 모니터링)를 참조하십시오.

지원되는 구성 옵션

AppQoE는 SD-WAN 구축 시 허브 앤 스포크 토폴로지와 풀 메시 토폴로지 모두에서 지원됩니다.

두 Junos OS 방화벽 엔드포인트(북엔드) 간에 AppQoE를 구성할 수 있으며 두 방화벽 모두 동일한 버전의 Junos OS 이미지를 가지고 있어야 합니다.

애플리케이션 경험 품질(Quality of Experience)의 이점

  • 애플리케이션 트래픽의 실시간 모니터링을 통해 일관되고 예측 가능한 서비스 수준을 제공함으로써 비용 효율적인 QoE를 실현할 수 있습니다.

  • 특정 트래픽(예: 비디오 트래픽) 전달에 대해 보장된 SLA를 제공하여 고객 유지율과 만족도를 높입니다. AppQoE는 승인된 트래픽이 사용자에게 최상의 경험 품질을 보장하는 데 필요한 적절한 우선 순위와 대역폭을 받도록 보장합니다.

제한

보안 디바이스에서 AppQoE를 구현하려면 다음과 같은 제약이 있습니다.

  • 서로 다른 인터페이스를 통해 목적지에 도달하는 모든 다양한 경로는 동일한 기본 설정, 가중치 및 구성된 메트릭을 가져야 합니다. 모든 경로는 대상에 대한 ECMP 경로로 추가되어야 하며 동일한 포워딩 테이블의 일부여야 합니다.

  • AppQoE SLA 서비스는 두 보안 디바이스 간에만 지원됩니다. 엔드포인트(북엔드)는 지원됩니다. 엔드투엔드 AppQoE SLA 서비스는 지원되지 않습니다.

  • AppQoE는 모든 인터페이스가 동일한 영역의 일부인 경우에만 적용할 수 있습니다.

  • AppQoE는 역방향 트래픽에 적용할 수 없습니다.

  • AppQoE는 세션의 대상 변경에 영향을 주지 않습니다.

  • AppQoE는 IPv6/UDP 프로브 캡슐화, GRES, 섀시 클러스터(ISSU, 고가용성, 듀얼 CPE 고가용성, Z-모드 고가용성) 및 논리적 시스템을 지원하지 않습니다.

  • AppQoE는 선호 경로 선택을 지원하지 않으며 전송 가상 라우팅 및 포워딩(VRF)은 지원되지 않습니다.

  • AppQoE는 IPv6 데이터 패킷에 대한 패시브 프로빙을 지원하지 않습니다.

  • UDP 대상 포트 36000의 UDP 패킷을 삭제하기 위해 비 WAN 인터페이스에서 입력 방화벽 필터가 필요합니다.

애플리케이션 QoS(Quality of Experience)는 어떻게 작동합니까?

AppQoE는 AppID 및 APBR 기능을 활용하여 특정 애플리케이션/애플리케이션 그룹을 식별하고 APBR 규칙에 따라 애플리케이션 트래픽이 전송되는 라우팅 인스턴스에 SLA 프로필을 연결하여 특정 트래픽에 대한 경로를 지정합니다.

AppQoE는 애플리케이션의 성능을 모니터링하고, 점수에 따라 SLA(서비스 수준 계약)에 지정된 성능 요구 사항을 충족하기 위해 해당 애플리케이션 트래픽에 가장 적합한 링크를 선택합니다.

응용 프로그램 또는 응용 프로그램 그룹 식별

다음 단계는 응용 프로그램 또는 응용 프로그램 그룹을 식별하는 데 포함됩니다.

  1. Junos OS 애플리케이션 식별을 통해 애플리케이션을 식별하고, 애플리케이션이 식별되면 해당 정보가 ASC(애플리케이션 시스템 캐시)에 저장됩니다.

  2. APBR은 패킷을 기반으로 평가하여 세션이 애플리케이션 기반 라우팅(고급 정책 기반 라우팅)의 후보인지 판단합니다. 새 세션의 첫 번째 패킷이고 트래픽이 애플리케이션 기반 라우팅에 대해 플래그가 지정되지 않은 경우, 대상에 대한 정상적인 처리(비 APBR 경로)를 거칩니다.

  3. 세션에 애플리케이션 기반 라우팅이 필요한 경우 APBR은 ASC 모듈을 쿼리하여 애플리케이션 속성(IP 주소, 대상 포트, 프로토콜 유형 및 서비스)을 가져옵니다.

  4. ASC에서 애플리케이션이 발견되면 APBR 프로필에서 일치하는 규칙에 대해 트래픽이 추가로 처리됩니다.

    • 일치하는 규칙이 발견되면 트래픽은 경로 조회를 위해 지정된 라우팅 인스턴스로 리디렉션됩니다.

      • AppQoE는 세션에 대해 SLA가 활성화되어 있는지 확인합니다. 세션이 SLA 측정의 후보인 경우 AppQoE는 성능 측정을 위한 능동 및 수동 프로브를 시작합니다.

      • APBR 규칙에서 세션에 대해 SLA가 활성화되지 않은 경우 AppQoE는 해당 세션을 무시하고 APBR의 기본 동작이 해당 세션에 적용됩니다. 즉, 트래픽은 대상에 대해 지정된 라우팅 인스턴스를 통해 라우팅됩니다.

    • 의 애플리케이션이 ASC에서 발견되지 않으면 APBR은 흐름의 심층 검사를 요청합니다. 즉, 애플리케이션 서명 패키지가 설치되고 세션에 대한 애플리케이션 식별이 활성화되어 APBR 처리를 위해 후속 세션에서 사용할 ASC를 채울 수 있습니다(2단계 참조).

응용 프로그램 또는 응용 프로그램 그룹에 대한 경로 지정

다음 단계는 AppQoE가 SLA 규칙에 따라 애플리케이션 트래픽의 경로를 지정하는 방법을 요약합니다.

  1. APBR은 애플리케이션 세부 정보를 사용하여 APBR 프로필(애플리케이션 프로필)에서 일치하는 규칙을 찾습니다. 애플리케이션 및 애플리케이션 그룹과 일치하는 트래픽은 라우팅 인스턴스에 지정된 대로 정적 경로 및 다음 홉 주소로 전달됩니다.

  2. APBR 프로필에 첨부된 SLA 규칙은 SLA를 측정하고 SLA 위반 발생 여부를 식별하는 데 필요한 매개 변수를 지정합니다.

  3. 애플리케이션 트래픽은 활성 프로빙을 사용하여 측정된 오버레이 링크의 SLA 메트릭을 기반으로 특정 오버레이 링크에 할당됩니다.

  4. SLA 위반은 라이브 애플리케이션/애플리케이션 그룹 트래픽의 수동 검색을 통해 결정됩니다. 애플리케이션/애플리케이션 그룹에 가장 적합한 경로/오버레이 링크는 경로 선택 알고리즘을 통해 결정됩니다.

애플리케이션 트래픽 경로 선택

다음 단계는 소스에서 대상으로 데이터 트래픽을 라우팅하기 위해, 특히 최적의 경로를 선택하기 위해 수행됩니다.

  • 플로우의 첫 번째 데이터 패킷(첫 번째 경로)에서 애플리케이션이 이미 알려진 경우(ASC 조회에서) 애플리케이션에 가장 적합한 경로가 데이터베이스에서 검색됩니다. 응용 프로그램을 알 수 없거나 ASC 조회에서 새로운 응용 프로그램인 경우 임의의 경로 또는 기본 경로가 선택됩니다. 이 경로는 전체 세션에 대해 계속됩니다. 나중에 DPI에서 애플리케이션을 검색한 후 데이터베이스는 애플리케이션에 가장 적합한 경로로 업데이트됩니다.

  • 플로우(빠른 경로)의 나머지 데이터 패킷에 대해 애플리케이션이 처음에 알려지지 않은 경우 특정 세션은 동일한 경로에서 계속됩니다. 애플리케이션이 처음에 알려진 경우 AppQoE는 애플리케이션 트래픽에 가장 적합한 경로를 선택합니다.

새 애플리케이션이 감지되면 경로 선택 메커니즘은 모든 SLA 메트릭을 충족하는 경로를 찾으려고 시도합니다. 이러한 경로가 없으면 차선 경로(충족된 메트릭 수 기준)가 사용됩니다. 메트릭을 충족하는 경로가 두 개 이상 있는 경우 사용 가능한 경로 중에서 임의의 경로가 선택됩니다. 프로필 구성에 따라 메트릭 중 하나가 위반되거나 요구 사항을 충족하는 메트릭이 없을 때 SLA 위반이 감지됩니다.

애플리케이션 경험 품질(Quality of Experience)이 애플리케이션 성능을 측정하는 방법

응용 프로그램 성능은 다음 지표에 의해 결정됩니다.

  • Latency(지연) - 커버해야 하는 미디어 길이 및 거리에 따라 미디어가 이동하는 데 물리적으로 필요한 시간입니다

  • RTT— 출발지에서 목적지로 또는 그 반대로 이동하는 데 필요한 왕복 시간입니다.

  • 패킷 손실—패킷 손실은 호스트가 전송한 패킷 100개당 손실된 패킷 수를 반영합니다.

  • 지터—지터는 패킷 간 지연 시간의 차이입니다. 링크의 성능을 평가하기 위해 수신 지터, 송신 지터 및 양방향 지터를 지정할 수 있습니다.

AppQoE는 각 링크에서 RTT, 지터 및 패킷 손실을 모니터링하고, 기본 링크의 성능이 SLA에서 지정한 허용 수준보다 낮으면 점수를 기반으로 애플리케이션을 대체 경로로 원활하게 전환합니다. 애플리케이션 성능의 측정 및 모니터링은 SLA 위반을 감지하고 특정 애플리케이션에 대한 대체 경로를 선택하는 능동 및 수동 프로브를 사용하여 수행됩니다.

AppQoE는 애플리케이션 트래픽을 지속적으로 모니터링하고 다음과 같은 방법으로 네트워크 또는 디바이스 문제를 식별하여 실시간 데이터를 수집합니다.

  • 구성된 모든 오버레이 링크의 성능 모니터링.

  • 패시브 프로브(애플리케이션 데이터 경로와 인라인) 및 액티브 프로브(특정 애플리케이션에 대한 종합 프로브)를 사용하여 애플리케이션 또는 애플리케이션 그룹의 트래픽 성능 모니터링.

  • 분석을 위해 수집된 모든 성능 메트릭 또는 메타데이터를 로그 수집기로 보냅니다.

  • 지정된 애플리케이션을 특정 성능 메트릭과 비교하고 SLA 위반 시 애플리케이션 트래픽 경로를 동적으로 변경합니다.

  • 특정 애플리케이션 또는 애플리케이션 그룹에 대해 유연한 SLA 메트릭 구성을 지원합니다.

AppQoE는 여러 WAN 링크에서 애플리케이션 SLA를 측정하고 애플리케이션 트래픽을 사용 가능한 링크 사이의 경로, 즉 SLA 요구 사항에 가장 잘 부합하는 경로에 매핑합니다.

액티브 및 패시브 프로브를 사용한 애플리케이션 성능 측정

능동 및 수동 프로브 측정은 네트워크의 엔드 투 엔드 분석에 사용되는 두 가지 접근 방식입니다.

  • 액티브 프로브—액티브 프로브는 애플리케이션의 서비스 품질을 측정하여 네트워크 성능에 대한 엔드 투 엔드 측정을 제공합니다.

    활성 프로빙에서 사용자 지정 패킷은 모든 여러 경로의 스포크 포인트와 허브 포인트 간에 전송되며 설치된 프로브 포인트 간에 RTT, 지연 시간, 지터 및 패킷 손실이 측정됩니다. 액티브 프로브는 모든 액티브 및 패시브 링크에서 주기적으로 전송됩니다. 구성된 수의 샘플이 수집되고 이러한 각 애플리케이션의 프로브 경로에 대한 실행 평균이 측정됩니다. 애플리케이션 트래픽에 대한 위반이 감지되면 SLA를 충족하는 최상의 링크를 결정하기 위해 프로브 메트릭을 평가합니다.

  • 패시브 프로브 - 패시브 프로브는 네트워크 내의 링크에 설치되며, 프로브는 해당 링크를 통해 흐르는 모든 트래픽을 모니터링합니다.

    패시브 프로빙(Passive Probring)은 실시간 데이터 트래픽에서 링크의 SLA 위반을 모니터링합니다. 패시브 프로브에서 실제 데이터 패킷은 디바이스 북엔드 포인트 간의 라이브 트래픽에서 IP/UDP 프로브 헤더에 캡슐화됩니다. 프로빙은 프로브 설치 지점 간의 RTT, 지터 및 패킷 손실을 측정하여 서비스 품질을 계산합니다.

    애플리케이션에 대해 위반이 감지되면 합성 프로브 메트릭을 평가하여 SLA를 충족하는 최상의 링크를 결정합니다.

    메모:

    링크 또는 경로가 수동 프로브에 의해 다운되었는지 감지하려면 SLA 위반을 트리거하기 위해 지정된 세션의 샘플링 기간에 최소 3개의 프로브 요청과 100% 패킷 손실이 발생해야 합니다.
    메모:

    디바이스가 섀시 클러스터 모드에서 작동 중일 때 트래픽이 전달되는 보조 노드(노드 1)가 재부팅되면 보조 노드 링크 간 애플리케이션 트래픽의 다중 스위칭이 발생합니다. 이는 기본 노드(노드 0)에서 사용 가능한 링크의 활성 프로브 SLA 경로 점수가 보조 노드 링크에 비해 낮을 때 발생합니다. 이 동작은 보조 노드의 모든 링크에서 100% 패킷 손실이 있음을 나타내는 AppQoE 활성 프로브 SLA 경로 점수 결과를 사용할 수 있을 때까지 계속됩니다.

액티브 및 패시브 프로브 매개 변수를 사용하여 SLA 규칙을 구성하고 APBR 프로파일과 SLA 규칙을 연결할 수 있습니다. APBR 프로필에는 APBR 규칙도 포함되어 있습니다. 규칙은 하나 이상의 애플리케이션 또는 애플리케이션 그룹과 연결되며 규칙과 일치하는 트래픽은 라우팅 인스턴스로 리디렉션됩니다

AppQoE는 애플리케이션의 모든 프로브 경로에 대한 프로브 요청을 트리거합니다. 능동 및 수동 프로브는 네트워크에서 장애 또는 혼잡 영역이나 지점을 모니터링합니다.

AppQoE는 액티브 및 패시브 프로브를 사용하여 학습된 애플리케이션에 대한 트래픽 클래스 통계를 수집하고 다음 작업을 수행합니다.

  1. SLA에 대한 성능 측정 - 프로브에서 제공하는 실시간 메트릭은 애플리케이션의 SLA에 따라 서비스 품질을 스코어링하고 애플리케이션 경로가 SLA 요구 사항을 충족하지 않는지 여부를 확인하는 데 사용됩니다. 즉, 애플리케이션에 대해 위반이 감지되면 합성 프로브 메트릭을 평가하여 SLA를 충족하는 애플리케이션 트래픽에 대한 최상의 대체 링크를 결정합니다.

  2. Reroute traffic(트래픽 경로 재지정) - 두 링크 사이의 애플리케이션 트래픽을 스위치합니다. 즉, 한 링크에 성능 문제가 있을 때 동일한 세션 동안 트래픽이 다른 링크로 라우팅됩니다.

메모:

여러 링크를 통해 애플리케이션의 트래픽에 도달할 수 있는 경우 도달 가능한 모든 경로를 오버레이 경로로 구성하고 오버레이 경로를 애플리케이션의 SLA 규칙에 연결해야 합니다.

애플리케이션 트래픽을 대체 경로로 전환

SLA 위반 중에 애플리케이션 트래픽을 다른 경로(디바이스에 로컬)로 스위칭하는 것을 활성화하거나 비활성화할 수 있습니다. 로컬 경로 전환이 활성화되면 애플리케이션 트래픽을 대체 경로로 전환할 수 있으며 SLA 모니터링 및 보고 기능도 사용할 수 있습니다. SLA 규칙 구성에서 애플리케이션 트래픽을 대체 경로로 스위칭하는 옵션이 비활성화되어 있어도 AppQoE는 애플리케이션 트래픽을 새 경로로 스위칭하는 등의 방법으로 SLA 위반을 해결합니다.

로컬 경로 전환이 비활성화되면 SLA 모니터링 및 보고 기능만 사용할 수 있으며 SLA 위반으로 인한 애플리케이션 트래픽의 전환은 해제됩니다.

애플리케이션 트래픽이 대체 경로로 전환되면 SLA 위반 시 애플리케이션 트래픽을 다른 경로로 다시 전환할 수 없는 짧은 기간이 있습니다. 이 기간은 링크 전반에서 트래픽의 플래핑을 방지하는 데 도움이 됩니다.

AppQoE 구성 제한 이해

AppQoE는 애플리케이션별 SLA 규칙을 구성할 때 오버레이 경로, 메트릭 프로필, 프로브 매개 변수 및 프로필별 SLA 규칙에 대한 구성 제한을 적용하고 SLA 규칙을 APBR 프로필에 연결합니다.

허용된 제한보다 더 많은 매개 변수를 구성하면 구성을 커밋할 때 오류 메시지가 표시됩니다.

오류 메시지의 예는 다음과 같습니다.

구성 제한의 값은 지원되는 정확한 수를 반영하지 않을 수 있습니다. 숫자는 지원되는 장치마다 다를 수 있습니다

링크 기본 설정 및 우선 순위에 따른 애플리케이션 경로 선택

소프트웨어 정의 WAN(SD-WAN)의 중요한 요구 사항 중 하나는 언더레이 네트워크 경로의 품질을 측정하고 그 결과에 따라 각 패킷의 전달에 사용할 최적의 경로를 결정하는 것입니다.

SLA 요구 사항을 충족하는 여러 경로를 사용할 수 있는 경우 링크 우선 순위 및 링크 유형에 따라 애플리케이션 경로를 선택하도록 AppQoE(Application-Specific Quality of Experience)를 구성할 수 있습니다.

MPLS 또는 인터넷 링크를 선호 경로로 선택하고, 1에서 255 사이의 우선 순위를 할당할 수 있으며, 값이 낮을수록 선호되는 링크를 나타냅니다. 값 1은 가장 높은 우선 순위를 나타냅니다. 여러 경로를 사용할 수 있는 경우 우선 순위가 가장 높은 경로가 선택됩니다.

예를 들어, VoIP 트래픽에 대해 MPLS 경로를 선택한 경우 지터 또는 패킷 손실로 인해 통화 중에 품질 저하가 발생하면 패킷은 SLA 요구 사항을 충족하는 다른 경로(인터넷)를 통해 전송됩니다. 이제 애플리케이션 트래픽이 인터넷 경로를 통해 전송되며, 인터넷 경로의 품질이 저하되면 경로가 MPLS로 다시 전환됩니다.

고급 정책 기반 라우팅(APBR) 규칙에서 각 언더레이 인터페이스의 링크 우선순위와 링크 유형을 구성할 수 있으며, 해당 오버레이에 의해 동일한 매개변수가 상속됩니다. 이 경우 언더레이 인터페이스는 오버레이에 대한 라우팅 토폴로지의 최종 발신 인터페이스입니다.

예를 들어 네트워크 인프라에서 언더레이가 4세대(4G) LTE 연결인 경우 다이얼러 인터페이스를 AppQoE의 언더레이 인터페이스로 구성할 수 있습니다. 마찬가지로 언더레이가 DSL 연결인 경우 해당 PPPoE(Point-to-Point Protocol over Ethernet) 인터페이스를 AppQoE의 언더레이 인터페이스로 구성할 수 있습니다.

AppQoE 경로 선택 메커니즘은 사용자 지정 링크 태그 구성, 기본 태그의 우선 순위가 높은 링크로 애플리케이션 트래픽 스위치, 비 SLA 메트릭 기반 구축 및 오버레이 인터페이스 속성 기본 설정 기능을 통해 향상되었습니다.

애플리케이션 경로 기본 설정 및 우선 순위의 이점

  • 애플리케이션 트래픽에 가장 적합한 경로를 선택할 수 있는 유연성을 제공합니다.

  • SLA 요구 사항(지연 시간 및 지터)을 충족하면서 비용 효율적인 연결 옵션을 통해 애플리케이션 트래픽을 라우팅할 수 있습니다.

  • 선택한 애플리케이션 경로의 품질이 저하되는 경우 동적 경로 전환을 지원합니다.

경로 선택 메커니즘

애플리케이션 트래픽은 다음과 같이 링크 기본 설정에 따라 별도의 링크를 통해 라우팅됩니다.

  • AppQoE 경로 선택 메커니즘에는 SLA 요구 사항을 충족하는 특정 대상에 대한 최적의 경로 목록이 포함됩니다. 이 목록에서 AppQoE는 사용자가 구성한 링크 기본 설정과 일치하는 경로를 선택합니다.

  • 이러한 경로를 여러 개 사용할 수 있는 경우 모든 경로 중에서 우선 순위가 가장 높은 경로가 선택됩니다.

  • 우선순위 또는 링크 유형 기본 설정이 구성되지 않은 경우 임의 경로 또는 기본 경로가 선택됩니다.

  • SLA 요구 사항을 충족하는 링크를 사용할 수 없는 경우 엄격한 선호도가 구성된 경우 가장 높은 SLA 점수 및 링크 유형 기본 설정 측면에서 사용 가능한 최상의 링크가 선택됩니다.

  • SLA 요구 사항을 충족하는 여러 링크를 사용할 수 있는 경우 우선 순위가 가장 높은 링크가 선택됩니다.

컨피그레이션 예는 액티브/액티브 모드에서 LTE 백업으로 WAN 링크 구성을 참조하십시오.

AppQoE에 대한 시스템 로그 메시지

애플리케이션 수준 로깅은 세션 수준에서 생성된 많은 수의 시스템 로그 메시지를 처리하는 동안 CSO 또는 로그 수집기 디바이스에 미치는 영향을 줄이기 위해 도입되었습니다. 보안 디바이스는 세션 수준 정보를 유지하고 세션 수준에 대한 시스템 로그 메시지를 제공합니다. 애플리케이션 수준 로깅이 세션 수준 로깅을 대체함에 따라 보안 디바이스의 오버헤드가 감소하고 AppQoE 로그 처리량이 증가합니다.

AppQoE는 다음과 같은 시스템 로그 메시지를 보냅니다.

  • APPQOE_SLA_METRIC_VIOLATION: 세션에 대한 위반이 감지되고 새 링크로 이동한 결과 세션의 경로가 확인된 경우.

  • APPQOE_BEST_PATH_SELECTED: 세션이 데이터 트래픽 경로를 전환하는 경우입니다.

응용 프로그램 수준 로깅을 사용하면 모든 세션 수준 로그가 응용 프로그램 수준에서 지원됩니다. 실시간 프로브 전송, SLA 메트릭 측정, 위반 탐지, 경로 전환의 AppQoE 기능은 세션 수준에서 계속됩니다. 그러나 애플리케이션 수준 요약 기능의 일부로, 데이터 경로 세션은 SLA 메트릭, 위반 정보 및 AppQoE 데이터베이스에 대한 경로 스위치를 알립니다. 이렇게 datapath에서 수신된 정보는 애플리케이션 수준에서 집계된 다음 시스템 로그 형태로 수집기 디바이스로 전송됩니다.

표 1 은 지원되는 새로운 애플리케이션 수준 로그의 세부 정보를 제공합니다.

표 1: 응용 프로그램 수준 로그 메시지

시스템 로그 메시지

묘사

APPQOE_APP_SLA_METRIC_VIOLATION

  • 이 시스템 로그 메시지는 애플리케이션이 처음 위반될 때 생성됩니다.

  • SLA 메트릭은 데이터 경로의 각 애플리케이션 세션에 대해 측정됩니다. SLA 위반 메트릭은 계속해서 세션 수준에서만 측정됩니다. 그러나 SLA 위반과 관련된 메트릭 또는 데이터는 SLA를 위반할 때 해당 애플리케이션의 모든 데이터 세션에서 AppQoE 데이터베이스로 전송됩니다.

  • 이중 CPE의 경우 애플리케이션에 대해 활성화된 노드가 APPQOE_APP_SLA_METRIC_VIOLATION 보고서를 생성합니다.

APPQOE_APP_BEST_PATH_SELECTED

  • 이 시스템 로그 메시지는 애플리케이션이 경로 전환을 통과할 때 생성됩니다. 이 로그 보고서는 자체 복구로 인해 발생한 위반을 지우기 위해서도 생성됩니다(링크가 변경되기 전에 SLA 위반이 자체적으로 지워지는 경우)

  • 애플리케이션 수준 로깅의 경우, 애플리케이션 또는 링크가 대체 경로로 전환되면 AppQoE는 수집기 디바이스에 로그 메시지 APPQOE_APP_BEST_PATH_SELECTED 보냅니다.

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

  • 이 시스템 로그 메시지는 패시브 프로브 SLA 메트릭 데이터에 대해 생성됩니다. 이 메시지는 수집된 샘플 수가 SLA 내보내기 계수를 충족하면 생성됩니다.

  • 애플리케이션 수준 로깅의 지원으로 각 프로브 후보 세션은 AppQoE로 정보를 전송하고, 여기서 메트릭은 수집기로 전송되기 전에 집계되고 평균화됩니다. 따라서 응용 프로그램 수준에서 집계된 수동 SLA 보고서에는 모든 응용 프로그램 데이터 세션의 평균 데이터가 포함됩니다.

애플리케이션 수준 로깅을 수행하면 다음과 같은 AppQoE 기능 변경 사항이 도입됩니다.

  • 액티브 프로브는 실시간 RTT 및 지터 값만 유지하고 사용합니다. 패킷 손실의 경우, 패킷 손실은 창의 끝에서만 계산할 수 있으므로 이전 세션의 원인을 나타냅니다.

  • 구성 커밋 동안 활성 프로브는 모든 항목에 대해 RTT 및 지터 값을 가장 높은 32비트 값으로 설정합니다.

  • 활성 프로브는 메트릭의 적절한 실시간 값을 사용할 수 있을 때까지 이전 세션의 값을 유지합니다.

  • 활성 프로빙에서 100% 패킷 손실이 발생하면 다른 모든 메트릭은 가장 높은 32비트 값으로 설정됩니다.

RTT 및 지터에 대한 잘못된 값 보고

RTT 및 지터에 대한 데이터를 사용할 수 없는 경우 잘못된 값 0xFFFFFFFF로 전송된 로그 메시지는 로그 수집기에서 무시할 수 있습니다. 표 2 는 잘못된 RTT 및 지터가 전송될 때 가능한 몇 가지 시나리오를 제공합니다.

표 2: RTT 및 지터에 대한 잘못된 데이터의 영향을 받는 애플리케이션 수준 로그 메시지

시나리오

영향을 받는 시스템 로그

100% 패킷 손실:

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

APPQOE_APP_SLA_METRIC_VIOLATION

0보다 크고 100% 미만인 패킷 손실:

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

APPQOE_APP_SLA_METRIC_VIOLATION

패킷 손실 없음

APPQOE_APP_SLA_METRIC_VIOLATION

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

AppQoE 로깅 비활성화

기본적으로 AppQoE 로그 유형은 시스템 로그로 설정됩니다. AppQoE를 비활성화하려면 다음 구성에서 log-type을 disabled로 구성합니다.

  1. AppQoE 로깅 사용 안 함
  2. AppQoE 로깅 사용

유입 트래픽의 DSCP 비트를 기반으로 하는 AppQoE(Application Quality of Experience)

AppQoE는 DSCP 값을 기준으로 수신 트래픽에 대한 SLA 기반 경로 선택을 지원합니다. AppQoE는 애플리케이션 서명이나 DSCP 값 또는 애플리케이션 ID와 DSCP 값의 조합을 기반으로 애플리케이션 트래픽에 가장 적합한 링크를 선택합니다.

APBR의 DSCP 지원

APBR 규칙에서 DSCP와 동적 애플리케이션을 모두 구성할 때 트래픽이 규칙에 지정된 모든 기준과 일치하면 규칙이 일치하는 것으로 간주됩니다. APBR 규칙에 여러 DSCP 값이 있는 경우 하나의 기준이 일치하면 일치하는 것으로 간주됩니다.

APBR 프로필은 여러 규칙을 포함할 수 있으며, 각 규칙에는 다양한 일치 조건이 있습니다.

APBR 프로필에 여러 APBR 규칙이 있는 경우 규칙 조회는 다음과 같은 우선 순위 순서를 사용합니다.

  1. DSCP + 동적 응용 프로그램을 사용한 규칙

  2. 동적 적용이 있는 규칙

  3. DSCP 값이 있는 규칙

네트워크 서비스 Orchestrator는 외부 서비스 기능에서 애플리케이션을 DSCP 값에 매핑할 수 있으며, DSCP를 원하는 SLA 프로파일에 매핑하기 위해 게이트웨이 라우터에서 동일한 값이 프로비저닝됩니다.

그림 1은 AppQoE가 게이트웨이 라우터 사용 사례에서 DSCP 값 및 애플리케이션 서명을 기반으로 수신 트래픽에 대한 SLA 기반 경로 선택을 수행하는 시나리오를 보여줍니다.

그림 1: DSCP 값 및 애플리케이션을 Network traffic flow diagram showing Virtual Routing and Forwarding and Application-Based Policy Routing. Traffic is routed based on application rules, DSCP values, and SLA criteria using AppQoE. Paths 1 and 2 represent different routing options. 기반으로 한 트래픽 경로 선택

DSCP 값을 기반으로 하는 트래픽의 경우, AppQoE는 다음과 같이 작동합니다.

  • LAN에서 게이트웨이 라우터로 들어오는 모든 트래픽은 애플리케이션 식별을 거칩니다. DPI가 애플리케이션을 식별할 때까지 시스템은 트래픽 스트림을 기본 포워딩 가상 라우팅 및 포워딩(VRF) 인스턴스로 전달합니다. VRF에는 연결된 발신 인터페이스가 포함되어 있습니다.

  • Junos OS 애플리케이션 식별을 통해 애플리케이션을 식별하고, 애플리케이션이 식별되면 해당 정보가 ASC(애플리케이션 시스템 캐시)에 저장됩니다.

  • 시스템은 DPI 분류 또는 ASC에서 사용할 수 있는 애플리케이션 정보가 있는지 계속 확인합니다.

  • APBR 메커니즘은 잘 알려진 애플리케이션, 서명 및 DSCP 값을 기반으로 세션을 분류하고 정책을 사용하여 애플리케이션에 가장 적합한 경로를 식별합니다. APBR 정책은 애플리케이션 트래픽을 특정 VRF에 매핑합니다.

  • APBR 구성에 SLA 규칙이 있으면 AppQoE 기능이 트리거됩니다. AppQoE는 애플리케이션 또는 DSCP 값을 기반으로 트래픽에 대한 SLA 기반 경로 선택을 수행합니다.

단일 DSCP에는 여러 애플리케이션 범주가 번들로 포함되어 있습니다. 다양한 애플리케이션 범주에는 개별 트래픽 패턴이 있습니다. 이런 시나리오에서 패시브 프로브를 사용하여 위반을 탐지하고 이를 모든 세션에 적용하면 오탐 및 오탐이 발생할 수 있습니다. 해결 방법으로 DSCP 기반 SLA 규칙을 구성한 경우 수동 검색을 사용하지 마십시오. 트래픽이 전달되는 대상 경로 그룹에 대해 활성 프로브를 사용할 수 있습니다.

제한

디바이스에서 DSCP 기반 규칙이 섀시 클러스터 모드인 AppQoE 구축에는 다음과 같은 제한 사항이 있습니다.

  • 애플리케이션 식별이 완료되기 전에 규칙 일치가 완료되고 AppQoE가 세션을 다른 노드로 이동하면 애플리케이션 식별이 완료되지 않습니다. 이 조건은 DSCP 기반 규칙이 구성될 때 발생합니다.

  • 2개의 APBR 규칙(1) DSCP 값 2) DSCP 및 동적 애플리케이션 모두를 사용하여 구성하고, 두 규칙 모두에 동일한 DSCP 값을 할당한 경우, 첫 번째 패킷을 수신하면 APBR은 DSCP 규칙과 일치합니다. 다른 노드에서 최상의 경로가 식별되면 세션이 다른 노드로 이동됩니다. 이 시나리오에서 애플리케이션 세션은 APP+DSCP 규칙이 아닌 DSCP 규칙과 일치합니다.

AppQoE에 대한 APBR 정책

AppQoE는 향상된 APBR을 활용하고 APBR이 전송한 애플리케이션 트래픽에 가장 적합한 링크를 선택하여 SLA에 지정된 성능 요구 사항을 충족합니다. AppQoE는 APBR에서 제공하는 세분화된 규칙 매칭 기능을 활용하여 애플리케이션 트래픽에 기반한 QoE(quality of experience)를 제공합니다.

예를 들어, 트러스트 존에 도착하는 Telnet 및 HTTPS 트래픽을 사용 가능한 최상의 링크를 통해 특정 디바이스나 인터페이스로 전달하려고 합니다. 트래픽이 트러스트 존에 도착하면 APBR은 APBR 정책에 정의된 소스 주소, 목적지 주소 및 애플리케이션과 일치하는 기준과 트래픽을 일치시킵니다. 트래픽이 정책과 일치하는 경우 해당 APBR 프로필이 적용됩니다.

APBR은 애플리케이션 세부 정보를 사용하여 프로필에서 일치하는 규칙을 찾습니다. 일치하는 규칙이 발견되면 트래픽은 규칙에 정의된 대로 지정된 라우팅 인스턴스로 리디렉션됩니다.

액티브-액티브 구축을 통한 AppQoE 멀티호밍

AppQoE는 액티브-액티브 구축을 통해 멀티호밍을 지원하도록 향상되었습니다. 이전에는 AppQoE가 액티브-스탠바이 구축을 통한 멀티호밍을 지원했습니다.

액티브-액티브 배포에서 스포크 디바이스는 여러 허브 디바이스에 연결됩니다. 허브 디바이스에 대한 링크가 SLA 요구 사항을 충족하는 경우 애플리케이션 트래픽은 허브 디바이스 중 하나를 통과할 수 있습니다. SLA 위반 또는 활성 허브 장치가 응답하지 않는 경우 애플리케이션 트래픽이 허브 장치 간에 원활하게 전환될 수 있습니다

그림 1 은 메시 토폴로지를 보여줍니다. 이 토폴로지에서 엔드포인트는 둘 이상의 노드를 통해 도달할 수 있습니다.

그림 2: 샘플 메시 토폴로지 Network topology diagram showing departments connected via Spoke 1 with vSRX and NFX devices to ISPs. Hubs use SRX devices for security and routing, connecting to the internet. CSO manages network with BGP; green lines are primary, orange are backup, gray are BGP connections.

액티브-액티브 모드에서 멀티호밍을 활성화하려면 디바이스가 여러 개의 equal-cost BGP 경로를 선택하여 주어진 목적지에 도달할 수 있도록 BGP multipath를 구성해야 합니다.

BGP multipath를 활성화하면 디바이스는 여러 개의 equal-cost BGP 경로를 선택하여 주어진 목적지에 도달하는 것이며 이러한 모든 경로는 포워딩 테이블에 설치됩니다. AppQoE는 경로 조회를 완료하고 해당 오버레이 링크와 함께 다음 홉 경로 세부 정보를 가져옵니다. AppQoE는 구성된 대상 경로 그룹에서 overlay-link 속성을 획득합니다.

애플리케이션의 SLA 요구 사항 및 링크 기본 설정에 따라 AppQoE는 해당 대상 경로 그룹의 모든 링크 중에서 최상의 링크를 결정합니다. SLA 위반의 경우 SLA 점수 및 링크 기본 설정에 따라 AppQoE는 해당 링크를 통해 엔드포인트에 도달할 수 있는 경우 구성된 모든 destination-path-group에서 대체 링크를 선택합니다.

BGP multipath 구성에 대한 자세한 내용은 예: BGP multipath 구성을 참조하십시오.

제한

특정 시나리오에서 경로에 대한 다음 홉 ID가 변경되면 SLA 요구 사항을 충족하는 다른 링크를 사용할 수 있더라도 기존 세션이 SLA 위반 링크에 남아 있습니다. 그러나 새 세션은 이 경우 영향을 받지 않으며 SLA 요구 사항을 충족하는 링크를 통해 라우팅됩니다.

SaaS 애플리케이션 지원

SaaS(Software as a Service) 애플리케이션에 대한 애플리케이션 체감 품질(AppQoE) 지원을 확대했습니다.

AppQoE는 언더레이, GRE, IPsec 또는 GRE를 통한 MPLS와 같은 사용 가능한 WAN 링크에서 SLA(서비스 수준 계약) 측정을 수행합니다. 그런 다음 SLA를 가장 잘 준수하는 링크를 통해 SaaS 애플리케이션 데이터를 전송하여 일관된 서비스를 제공합니다.

IPv6 트래픽 지원

  • AppQoE 구성에서 IPv6 주소를 사용할 수 있습니다. 지원에는 다음이 포함됩니다.

    • 오버레이 경로 구성의 IPv6 주소
    • IPv6 주소를 소스 및 대상 주소로 사용하는 활성 프로빙 세션.
    • 클라이언트 측의 IPv4 및 IPv6 트래픽
    • LAN 측에서 IPv4 및 IPv6의 이중 스택
    • SaaS(Software as a Service) 프로빙을 위한 LAN 측의 IPv6 주소입니다.

      SaaS 프로빙의 경우, IPv4 및 IPv6 상호 운용성을 위해 수신 인터페이스에 IPv4 및 IPv6 주소를 모두 구성해야 합니다.

추가 플랫폼 정보

AppQoE 기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.

다음 표를 사용하여 플랫폼에 대한 플랫폼별 동작을 검토할 수 있습니다.

플랫폼

다름

SRX 시리즈

 SRX300, SRX320, SRX345, SRX340, SRX550M, vSRX에는 Spoke 디바이스 구성을 권장합니다.

SRX 시리즈

 허브 장치 구성은 SRX1500, SRX4100 및 SRX4200에 권장됩니다.

SRX 시리즈

 SRX4600에서 AppQoE는 GRE에 대한 CoS를 지원하지 않고, 단기 세션에서는 패시브 프로브 세부 정보를 사용하지 못할 수 있으며, 섀시 클러스터 모드일 때 Z 모드 트래픽 처리의 보조 노드에서 세션 상태 동기화가 실패할 수 있습니다.

관련 설명서

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

석방
묘사
21.4R1
AppQoE 구성의 오버레이 및 언더레이 네트워크에 IPv4 및 IPv6의 이중 스택을 사용할 수 있습니다.
21.3R1 시리즈
AppQoE 구성에서 IPv6 주소를 사용할 수 있습니다. Junos OS 릴리스 20.4R1부터 주니퍼는 SaaS(Software as a Service) 애플리케이션에 대한 애플리케이션 경험 품질(AppQoE) 지원을 확장했습니다.
21.2R1 시리즈
AppQoE 경로 선택 메커니즘은 사용자 지정 링크 태그 구성으로 향상되었습니다.
20.4R1
SaaS(Software as a Service) 애플리케이션에 대한 애플리케이션 체감 품질(AppQoE) 지원을 확대했습니다.
20.2R1 시리즈
AppQoE는 기존의 액티브-스탠바이 구축뿐만 아니라 액티브-액티브 구축을 통해 멀티호밍을 지원하도록 향상되었습니다.
20.1R1 시리즈
AppQoE는 향상된 APBR 기능을 활용하여 애플리케이션 트래픽에 가장 적합한 링크를 선택합니다.
19.4R1
AppQoE는 DSCP 값을 기준으로 수신 트래픽에 대한 SLA 기반 경로 선택을 지원합니다.
19.2R1 시리즈
AppQoE에서 애플리케이션 수준 로깅에 대한 지원을 사용할 수 있습니다.
19.1R1 시리즈
AppQoE는 디바이스가 섀시 클러스터 모드에서 작동할 때 SRX4100 및 SRX4200 디바이스에서 지원됩니다. . 액티브/액티브 및 액티브/패시브 모드 모두에서 작동하도록 디바이스를 구성하고 SD-WAN 구축에서 디바이스를 스포크 디바이스로 배포할 수 있습니다.
19.1R1 시리즈
AppQoE는 오버레이 경로, 메트릭 프로필, 프로브 매개 변수 및 프로필당 SLA 규칙에 대한 구성 제한을 적용합니다.
18.4R1 시리즈
여러 SLA 준수 경로를 사용할 수 있는 경우 링크 우선 순위 및 유형에 따라 애플리케이션 경로를 선택하도록 AppQoE를 구성할 수 있습니다.
18.3R1 시리즈
링크 또는 경로가 수동 프로브에 의해 다운되었는지 감지하려면 SLA 위반을 트리거하기 위해 주어진 세션의 샘플링 기간에 최소 3개의 프로브 요청과 100% 패킷 손실이 발생해야 합니다.