HTB를 통한 대역폭 공유 및 실시간 트래픽 우선 순위 결정, 어떤 시나리오가 더 효과적입니까?


10

인터넷 회선에 일종의 트래픽 관리를 추가하고 싶습니다. 많은 문서를 읽은 후 HFSC가 나에게 너무 복잡하다고 생각합니다 (모든 곡선을 이해하지 못합니다. 정확하지 않을 것입니다) .CBQ는 권장되지 않으며 기본적으로 HTB가 방법입니다. 대부분의 사람들을 위해 가십시오.

우리의 내부 네트워크에는 세 개의 "세그먼트"가 있으며 대역폭을 최소한 (초기) 최소한 동일하게 공유하고 싶습니다. 또한 3 가지 종류의 트래픽 (실시간 트래픽, 표준 트래픽 및 대량 트래픽)에 따라 트래픽의 우선 순위를 지정해야합니다. 대역폭 공유는 실시간 트래픽이 가능할 때마다 항상 프리미엄 트래픽으로 처리되어야한다는 사실만큼 중요하지는 않지만, 다른 트래픽 클래스도 굶주릴 수는 없습니다.

문제는 더 의미가 있고 더 나은 실시간 처리량을 보장하는 것입니다.

  1. 세그먼트 당 하나의 클래스를 작성하십시오. 각 클래스는 동일한 비율을 갖습니다 (우선 순위는 HTB 개발자에 따라 휴가가없는 클래스의 경우 중요하지 않음). 각 클래스에는 우선 순위가 다른 3 개의 우선 순위 레벨에 대해 3 개의 서브 클래스 (리브)가 있습니다. 다른 요금).

  2. 우선 순위 수준 당 하나의 클래스가 있으며 각 클래스마다 다른 비율 (다시 우선 순위는 중요하지 않음)이 있고 각각 세그먼트 당 하나씩 3 개의 하위 클래스가 있습니다. 반면에 실시간 클래스의 3 개는 모두 가장 높은 prio, 가장 낮은 prio를 갖습니다. 수업 등.

다음 ASCII 아트 이미지를 사용하여 더 명확하게 만들려고합니다.

Case 1:

root --+--> Segment A
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment B
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment C
               +--> High Prio
               +--> Normal Prio
               +--> Low Prio

Case 2:

root --+--> High Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Normal Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Low Prio
                +--> Segment A
                +--> Segment B
                +--> Segment C

사례 1 대부분의 사람들이하는 방식처럼 보이지만 HTB 구현 세부 정보를 제대로 읽지 않으면 사례 2의 우선 순위가 더 높아질 수 있습니다.

HTB 매뉴얼에 따르면 클래스가 속도에 도달하면 부모로부터 빌릴 수 있으며 빌릴 때 우선 순위가 높은 클래스는 항상 대역폭이 먼저 제공됩니다. 그러나 낮은 트리 수준에서 사용 가능한 대역폭을 가진 클래스 는 우선 순위에 관계없이 항상 높은 트리 수준의 클래스보다 선호됩니다 .

다음과 같은 상황을 가정 해 보겠습니다. 세그먼트 C가 트래픽을 보내지 않습니다. 세그먼트 A는 가능한 한 빨리 (링크 만 포화시키기에 충분한) 실시간 트래픽 만 전송하고 세그먼트 B는 가능한 한 빨리 (전체 링크 만 포화시키기에 충분한) 대량 트래픽 만 전송합니다. 무슨 일이 일어날 것?

사례 1 :
A-> 높은 Prio 세그먼트와 B-> 낮은 Prio 세그먼트에는 모두 전송할 패킷이 있습니다. 이제 세그먼트 A에서 빌리려고하지만 세그먼트 A가 더 높은 레벨에 있고 세그먼트 B-> 낮은 Prio가 아직 이율에 도달하지 않았으므로이 클래스는 이제 이율에 도달하여 빌리기를 원할 때까지 먼저 제공됩니다. 세그먼트 B. 일단 둘 다 요율에 도달하면 둘 다 다시 같은 레벨에있게됩니다. 이제 세그먼트 A-> 고위 Prio는 세그먼트 A의 비율에 도달 할 때까지 다시 이길 것입니다. 이제 루트에서 빌리려고합니다. 세그먼트 C는 보장 된 트래픽을 사용하지 않기 때문에 트래픽 여유가 충분하지만 세그먼트 B-> 낮은 Prio가 루트 수준에 도달 할 때까지 기다려야합니다. 그런 일이 생기면

사례 2 :
High Prio-> Segment A 및 Low Prio-> Segment B에는 둘 다 보낼 패킷이 있으며 High Prio-> Segment A는 우선 순위가 높을수록 이기게됩니다. 일단 속도에 도달하면 대역폭이 부족한 High Prio에서 빌리려고 시도하지만 더 높은 레벨에 있으면 Low Prio-> Segment B가 다시 그 속도에 도달 할 때까지 기다려야합니다. 둘 다 금리에 도달하고 모두 빌려야하는 경우 High Prio-> Segment A는 High Prio 클래스의 속도에 도달 할 때까지 다시 승리합니다. 그런 일이 발생하면 루트에서 차용을 시도하는데, 다시 충분한 대역폭이 남아 있습니다 (현재 일반 Prio의 모든 대역폭이 사용되지 않음). 낮은 Prio-> 세그먼트 B가 낮은 Prio 클래스와 루트에서 빌리려고 시도합니다. 마지막으로 두 클래스 모두 루트에서 빌리려고 시도하고 우선 순위가 고려되며 High Prio->

실시간 트래픽이 차용 할 수있는 충분한 대역폭이 남아 있지만 대량 트래픽을 기다려야하는 경우가 있기 때문에 두 경우 모두 최적이 아닌 것 같습니다. 그러나 2의 경우 실시간 트래픽이 1의 경우보다 덜 기다려야하는 것처럼 보입니다. 벌크 트래픽 속도에 도달 할 때까지만 기다려야하므로 전체 세그먼트의 속도보다 낮을 가능성이 높습니다. 1) 대기해야하는 속도입니다. 아니면 내가 완전히 틀렸습니까?

우선 순위 qdisc를 사용하여 더 간단한 설정에 대해 생각했습니다. 그러나 우선 순위 대기열은 어떻게 든 제한되지 않으면 기아를 유발한다는 큰 문제가 있습니다. 기아는 허용되지 않습니다. 물론 속도를 제한하고 기아를 피하기 위해 TBF (Token Bucket Filter)를 각 우선 순위 클래스에 넣을 수 있지만 그렇게하면 단일 우선 순위 클래스가 다른 모든 우선 순위 클래스 인 경우에도 링크를 더 이상 포화시킬 수 없습니다 TBF가 비어 있으면이를 방지 할 수 있습니다. 그리고 다른 클래스가 현재 필요하지 않은 클래스가 왜 회선 대역폭의 100 %를 얻지 못합니까?

이 설정에 대한 의견이나 아이디어가 있습니까? 표준 tc qdiscs를 사용하는 것은 너무 어려워 보입니다. 프로그래머로서 간단하게 내 스케줄러를 작성할 수 있다면 그렇게 쉬운 작업이었습니다 (허용되지 않습니다).

답변:


1

htb를 올바르게 이해하면 요율이 "보증"됩니다. 이는 "실시간"트래픽 비율에 대한 아이디어가 있다는 것을 의미합니다 . 이 비율을 초과하는 경우에만 빌릴 것입니다. 여러 클래스를 빌리려면 프리 오가 시작됩니다. 보장 된 요율은 물리적 제한을 합산해야합니다. 그렇지 않으면 너무 번거 롭습니다.

IMHO, 사례 A는 루트 수준에서 우선 순위 또는 속도 제한이 필요하므로 실제로 작동하지 않습니다. 다른 세그먼트의 우선 순위 / 속도는 서로를 알지 못하며 동일하게 처리됩니다.

아마도 당신이 원하는 것은 : 낮고 보통의 prio에 대한 "rate"를 0 또는 그에 가깝게두고 나머지 대역폭에 대해 "ceiling"을 추가하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.