Я хотів би додати якесь управління трафіком до нашої лінії в Інтернеті. Прочитавши багато документації, я думаю, що HFSC для мене занадто складний (я не розумію всіх кривих речей, боюся, що ніколи не виправлюсь), CBQ не рекомендується, і в основному HTB - це спосіб йти для більшості людей.
Наша внутрішня мережа має три "сегменти", і я хотів би поділити пропускну здатність більш-менш однаково між ними (принаймні на початку). Далі я повинен розставити пріоритет руху за принаймні трьома видами трафіку (трафік у режимі реального часу, стандартний та масовий трафік). Спільна пропускна здатність не так важлива, як той факт, що трафік у реальному часі завжди слід розглядати як преміальний трафік, коли це можливо, але, звичайно, жоден інший клас трафіку також не може голодувати.
Питання в тому, що має більше сенсу, а також гарантує кращу пропускну здатність у режимі реального часу:
Створення одного класу на сегмент, кожен з яких має однакову швидкість (пріоритет не має значення для класів, які не залишаються листям відповідно до розробника HTB), і кожен з цих класів має три підкласи (листя) для трьох рівнів пріоритетності (з різними пріоритетами і різні ставки).
Маючи один клас на рівні пріоритету зверху, кожен має різну швидкість (знову пріоритет не має значення) і кожен має 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-> High Prio і B-> Low Prio є пакети для надсилання, оскільки A-> High Prio має більш високий пріоритет, він завжди буде запланований першим, поки він не досягне своєї швидкості. Тепер він намагається запозичити сегмент A, але оскільки сегмент A знаходиться на більш високому рівні, а сегмент B-> низький пріо ще не досяг своєї ставки, цей клас зараз обслуговується першим, поки він також не потрапить у ставку і хоче взяти позику у Сегмент B. Після того, як обидва досягли своїх ставок, обидва знову на одному рівні, і тепер сегмент A-> Високе Прио збирається знову виграти, поки не потрапить на швидкість сегмента А. Тепер він намагається запозичити корінь (який має достатньо запасу трафіку, оскільки сегмент C не використовує жодного гарантованого трафіку), але знову ж таки, йому доведеться дочекатися, коли сегмент B-> Low Prio також досягне кореневого рівня. Як тільки це станеться,
Випадок 2:
Обидва Високі Пріо-> Сегмент А та Низький Прио-> Сегмент В мають пакети для надсилання, знову ж таки Високий Прио-> Сегмент А збирається виграти, оскільки він має більший пріоритет. Як тільки він досягає своєї швидкості, він намагається запозичити у High Prio, який має пропускну здатність пропускної здатності, але, перебуваючи на більш високому рівні, йому доведеться знову чекати низького рівня Prio-> сегмент B, щоб також досягти його швидкості. Після того, як обидва досягли свого курсу і обом доводиться позичати, High Prio-> сегмент A знову виграє, поки не потрапить на курс класу High Prio. Як тільки це станеться, він намагається запозичити корінь, у якого знову залишилось велику пропускну здатність (вся пропускна здатність Normal Prio наразі не використовується), але йому доведеться зачекати ще раз, поки Low Prio-> сегмент B не досягне межі швидкості Клас низького рівня і також намагається запозичити у root. Нарешті обидва класи намагаються запозичити з кореня, враховується пріоритет, а Високий Пріо->
Обидва випадки здаються неоптимальними, оскільки в будь-якому випадку трафіку в режимі реального часу іноді доводиться чекати масового трафіку, навіть незважаючи на те, що в ньому є достатня кількість пропускної здатності. Однак у випадку 2 здається, що трафіку в режимі реального часу доводиться чекати менше, ніж у випадку 1, оскільки йому залишається лише чекати, поки буде досягнуто об'ємний трафік, який, швидше за все, менший, ніж швидкість цілого сегмента (і у випадку 1 - це швидкість, яку він повинен чекати). Або я тут абсолютно помиляюся?
Я подумав про ще більш прості налаштування, використовуючи пріоритетний qdisc. Але пріоритетні черги мають велику проблему, що вони викликають голодування, якщо вони якимось чином не обмежені. Голодування не прийнятне. Звичайно, можна помістити TBF (Token Bucket Filter) у кожен клас пріоритетів, щоб обмежити швидкість і, таким чином, уникнути голоду, але при цьому один клас пріоритетів більше не може насичувати посилання, навіть якщо всі інші класи пріоритетів порожні, TBF запобіжить цьому. І це також є неоптимальним, адже чому б клас не отримав 100% пропускної здатності лінії, якщо жоден інший клас на даний момент не потребує?
Якісь коментарі чи ідеї щодо цієї установки? Здається, це важко зробити за допомогою стандартних tc qdiscs. Як програміст це було таким легким завданням, якщо я міг просто написати власний планувальник (що мені не дозволяється робити).