Chciałbym dodać coś w rodzaju zarządzania ruchem do naszej linii internetowej. Po przeczytaniu dużej ilości dokumentacji, myślę, że HFSC jest dla mnie zbyt skomplikowany (nie rozumiem wszystkich krzywych, obawiam się, że nigdy nie uda mi się go dobrze), CBQ nie jest zalecane i zasadniczo HTB jest sposobem na idź dla większości ludzi.
Nasza sieć wewnętrzna ma trzy „segmenty” i chciałbym podzielić mniej więcej równą szerokość pasma między nimi (przynajmniej na początku). Ponadto muszę nadać priorytet ruchowi według co najmniej trzech rodzajów ruchu (ruch w czasie rzeczywistym, ruch standardowy i ruch masowy). Podział pasma nie jest tak ważny, jak fakt, że ruch w czasie rzeczywistym powinien być zawsze traktowany jako ruch premium, gdy tylko jest to możliwe, ale oczywiście żadna inna klasa ruchu nie może także głodować.
Pytanie brzmi: co ma sens, a także gwarantuje lepszą przepustowość w czasie rzeczywistym:
Tworzenie jednej klasy na segment, z których każda ma tę samą szybkość (priorytet nie ma znaczenia dla klas, które nie są liśćmi według twórcy HTB), a każda z tych klas ma trzy podklasy (liście) dla 3 poziomów priorytetów (z różnymi priorytetami i różne stawki).
Posiadanie jednej klasy na każdy poziom priorytetu na górze, każda o innej stawce (znowu priorytet nie będzie miał znaczenia) i każda z 3 podklasami, po jednej na segment, podczas gdy wszystkie 3 w klasie czasu rzeczywistego mają najwyższe, najniższe prio masowo klasa i tak dalej.
Spróbuję to wyjaśnić za pomocą następującego obrazu sztuki 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
Przypadek 1 Wydaje się, że sposób, w jaki większość ludzi by to zrobiła, ale jeśli nie przeczytam poprawnie szczegółów implementacji HTB, Przypadek 2 może zaoferować lepsze ustalanie priorytetów.
Podręcznik HTB mówi, że jeśli klasa osiągnęła swój kurs, może pożyczyć od swojego rodzica, a kiedy pożycza, klasy o wyższym priorytecie zawsze otrzymują najpierw przepustowość. Jednak mówi również, że klasy posiadające przepustowość dostępną na niższym poziomie drzewa są zawsze preferowane niż klasy na wyższym poziomie drzewa, niezależnie od priorytetu .
Załóżmy następującą sytuację: Segment C nie wysyła żadnego ruchu. Segment A wysyła tylko ruch w czasie rzeczywistym tak szybko, jak to możliwe (wystarczające do nasycenia samego linku), a Segment B wysyła tylko ruch masowy tak szybko, jak to możliwe (ponownie, wystarczające do nasycenia samego pełnego linku). Co się stanie?
Przypadek 1:
Zarówno segment A-> High Prio, jak i segment B-> Low Prio mają pakiety do wysłania, ponieważ A-> High Prio ma wyższy priorytet, zawsze będzie ustalany jako pierwszy, aż osiągnie swoją szybkość. Teraz próbuje pożyczyć z Segmentu A, ale ponieważ Segment A jest na wyższym poziomie, a Segment B-> Niskie Prio jeszcze nie osiągnął stopy procentowej, ta klasa jest teraz obsługiwana jako pierwsza, dopóki nie osiągnie stopy procentowej i chce pożyczyć od Segment B. Gdy oba osiągną już swoje stawki, oba znów są na tym samym poziomie, a teraz Segment A-> High Prio znowu wygra, dopóki nie osiągnie stopy w Segmencie A. Teraz próbuje pożyczyć od roota (który ma dużo ruchu, ponieważ segment C nie korzysta z gwarantowanego ruchu), ale znowu musi poczekać, aż segment B-> Low Prio również osiągnie poziom główny. Kiedy to się stanie,
Przypadek 2:
Zarówno High Prio-> Segment A, jak i Low Prio-> Segment B mają pakiety do wysłania, ponownie High Prio-> Segment A wygra, ponieważ ma wyższy priorytet. Gdy osiągnie swoją stopę, próbuje pożyczyć od High Prio, która ma wolne pasmo, ale będąc na wyższym poziomie, musi poczekać, aż Low Prio-> Segment B ponownie osiągnie swoją stopę procentową. Kiedy obaj osiągną stopę procentową i obie będą musieli pożyczyć, High Prio-> Segment A wygra ponownie, dopóki nie osiągnie stopy klasy High Prio. Kiedy to się stanie, próbuje pożyczyć od roota, który ma jeszcze dużo przepustowości (cała przepustowość Normal Prio jest w tej chwili nieużywana), ale musi poczekać, aż Low Prio-> Segment B osiągnie limit szybkości Niska klasa Prio, a także próbuje pożyczyć od roota. Wreszcie obie klasy próbują pożyczyć od roota, priorytet jest brany pod uwagę, a High Prio->
Oba przypadki wydają się nieoptymalne, ponieważ w obu przypadkach ruch w czasie rzeczywistym musi czasami czekać na ruch masowy, mimo że pozostało dużo przepustowości, którą mógłby pożyczyć. Jednak w przypadku 2 wydaje się, że ruch w czasie rzeczywistym musi czekać krócej niż w przypadku 1, ponieważ musi tylko czekać, aż zostanie osiągnięty ruch masowy, który najprawdopodobniej jest mniejszy niż wskaźnik całego segmentu (i w przypadku 1 to jest stawka, na którą musi czekać). A może całkowicie się tutaj mylę?
Myślałem o jeszcze prostszych konfiguracjach, używając priorytetowej kolejki. Ale kolejki priorytetowe mają duży problem, że powodują głód, jeśli nie są w jakiś sposób ograniczone. Głód jest niedopuszczalny. Oczywiście można wstawić TBF (Token Bucket Filter) do każdej klasy priorytetowej, aby ograniczyć szybkość i tym samym uniknąć głodu, ale czyniąc to, pojedyncza klasa priorytetowa nie może nasycić łącza samodzielnie, nawet jeśli wszystkie inne klasy priorytetowe są puste, TBF zapobiegnie temu. Jest to również nieoptymalne, ponieważ dlaczego klasa nie miałaby uzyskać 100% przepustowości linii, skoro żadna inna klasa w tej chwili jej nie potrzebuje?
Wszelkie uwagi lub pomysły dotyczące tej konfiguracji? Wydaje się to takie trudne przy użyciu standardowych qdisc z tc. Jako programista mogłem po prostu napisać własny harmonogram (czego nie wolno mi robić).