通过HTB共享带宽并确定实时流量的优先级,哪种方案更好?


10

我想在我们的Internet线上添加某种流量管理。在阅读了很多文档之后,我认为HFSC对我来说太复杂了(我不了解所有曲线内容,恐怕我永远都做不到),不建议使用CBQ,基本上HTB是解决问题的方法对于大多数人来说。

我们的内部网络具有三个“网段”,我希望在它们之间或多或少地平均共享带宽(至少在开始时如此)。此外,我必须根据至少三种流量(实时流量,标准流量和批量流量)对流量进行优先级排序。带宽共享并不像在任何可能的情况下始终将实时流量始终视为高级流量这一事实那样重要,但是当然也没有其他流量类别可能会挨饿。

问题是,什么才更有意义,同时又可以保证更好的实时吞吐量:

  1. 为每个细分创建一个类,每个类具有相同的速率(根据HTB开发人员的优先级,对于没有叶子的类,优先级无关紧要),并且每个类都有3个子类(叶子),分别对应3个优先级(优先级不同)和不同的费率)。

  2. 在每个优先级级别上都有一个类别,每个类别具有不同的速率(再次优先级将无关紧要),每个类别都有3个子类别,每个细分市场一个类别,而实时类别中的所有3个类别的最高优先级最高,最低优先级最高课,等等。

我将尝试使用以下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->高优先级和段B->低优先级都有要发送的数据包,因为A->高优先级具有更高的优先级,所以它将始终优先调度,直到达到其速率为止。现在,它尝试从细分受众群A借款,但是由于细分受众群A处于较高水平,并且细分受众群B-> Low Prio尚未达到其利率,因此该类现在被首先使用,直到它也达到利率并希望从细分市场B。一旦两者都达到了各自的水平,则两者都再次处于同一水平,现在细分市场A-> High Prio将再次获胜,直到达到细分市场A的价格。大量的流量备用,因为网段C没有使用其保证的流量),但同样,它必须等待网段B->低优先级也达到根级别。一旦发生这种情况,

情况2:
高优先级->段A和低优先级->段B都有要发送的数据包,高优先级->段A也将获胜,因为它具有更高的优先级。一旦达到其速率,它将尝试从High Prio借用,High Prio具有可用的带宽,但处于较高水平,它必须等待Low Prio-> Segment B再次达到其速率。一旦双方都达到了自己的水平并且都不得不借钱,High Prio-> Segment A将再次获胜,直到达到High Prio类的水平。一旦发生这种情况,它会尝试从根节点借用,而根节点又有足够的带宽可用(正常Prio的所有带宽目前都未使用),但它必须再次等待,直到Low Prio-> Segment B达到速率上限。皮里奥阶级低下,也试图从根源上借钱。最后,这两个类都尝试从根目录借用,优先级已考虑在内,并且High Prio->

两种情况似乎都不尽人意,因为无论哪种方式,实时流量有时都必须等待大量流量,即使还有很多带宽可以借用。但是,在第2种情况下,实时流量似乎要比第1种情况少等待,因为它只需要等到达到大流量速率(这很可能小于整个网段的速率)( 1就是它必须等待的速率)。还是我在这里完全错了?

我考虑过使用优先级qdisc进行更简单的设置。但是优先队列有一个很大的问题,即如果不受某种限制,它们会导致饥饿。饥饿是不可接受的。当然,可以将TBF(令牌桶过滤器)放入每个优先级类别以限制速率,从而避免出现饥饿现象,但是这样做时,即使所有其他优先级类别,单个优先级类别也无法使其自身饱和链接为空时,TBF将阻止这种情况的发生。这也是次优的,因为如果现在没有其他班级需要一个班级,为什么班级不能获得线路带宽的100%?

关于此设置有任何意见或想法吗?使用标准tc qdiscs似乎很难。作为程序员,如果我可以简单地编写自己的调度程序(这是我不允许做的),那么这是一件容易的事。

Answers:


1

如果我正确理解htb,则可以“保证”汇率。这意味着您对“实时”流量的速率想法。只有超过此利率,它才会借用。如果要借几个班级,则应该加价。保证利率应该加起来实际的限额。否则,这太麻烦了。

恕我直言,案例A永远不会真正起作用,因为您需要在根级别具有优先级或速率限制。不同细分市场中的优先级/费率彼此之间一无所知,将被平等地处理。

您可能想要的是:将低和正常Prio的“速率”设置为0或接近零,并为其余带宽添加“天花板”,对于高Prio,您可以保证物理速率的100%。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.