Розподіл смуги пропускання для невеликих мереж на основі класів

Максимально продуктивна мережу в основному працює добре Однак, ви можете

виявити, що у вашій мережі існують інші потреби Наприклад, для деяких видів трафіку-пошти зокрема та інших необхідних сервісів, може бути важливо досягти базової пропускної здатності в будь-який момент часу, в той час як для інших сервісів, типу P2P, повинні бути встановлені певні обмеження на споживання пропускної здатності

Для вирішення такого роду вимог або концепцій, дисципліна черги на основі класів (CBQ) пропонує набагато більше можливостей Щоб проілюструвати, як використовується CBQ, ми перейдемо до наступного Наприклад, який опісрается на набір правил з попередніх глав Це невелика локальна мережа, і нам необхідно, щоб користувачі в локальній мережі підключали до заздалегідь встановленому набору сервісів за межами своєї мережі, і крім того, мали доступ до локального web-серверу локальної мережі

Тут, всі черги встановлюються на зовнішньому інтерфейсі виходу в Інтернет Головним чином, цей підхід має сенс, оскільки пропускна здатність буде більш обмежена на зовнішньому інтерфейсі, ніж на локальній мережі Однак, в принципі, розподіл черг і балансування трафіку можуть бути зроблені на будь-якому інтерфейсі

Наступний приклад налаштування включає черги CBQ для загальної пропускної здатності 2Мбіт з шістьма підчерги

altq on $ext_if cbq bandwidth 2Mb queue { main, ftp, udp, web, ssh, icmp } queue main bandwidth 18% cbq(default borrow red)

queue ftp bandwidth 10% cbq(borrow red) queue udp bandwidth 30% cbq(borrow red) queue web bandwidth 20% cbq(borrow red)

queue ssh bandwidth 20% cbq(borrow red) { ssh_interactive, ssh_bulk } queue ssh_interactive priority 7 bandwidth 20%

queue ssh_bulk priority 0 bandwidth 80% queue icmp bandwidth 2% cbq

Підчерги main має 18% пропускної спроможності і визначається як черга за замовчуванням Це означає, що будь-який трафік, який відповідає правилу pass, але явно не призначений в інші черги, потрапляє сюди Ключові слова borrow і red означають, що черга може запозичити пропускну здатність від своєї батьківської черги, в той час коли система буде намагатися уникнути перевантаження, використовуючи алгоритм RED Інші черги, більш-менш дотримуються тієї ж схемою до підчерги ssh, яка сама має дві підчерги з окремими пріоритетами Тут ми спостерігаємо варіації на прикладі пріоритетів ACK Масові передачі SSH, типові для передачі файлів SCP, передаються з ToS вказує пропускну здатність, у той час, як інтерактивний трафік SSH має прапор ToS встановлений в вказівку низькою затримки (low delay), і пропускається перш масових передач Інтерактивний трафік, по всій ймовірності, буде мати менші витрати смуги пропускання і отримає меншу частку пропускної здатності, але, одночасно з цим і великі пільги, оскільки він має більш високий пріоритет Крім того дана схема дозволяє підвищити швидкість передачі файлів SCP, оскільки пакети ACK для передачі SCP будуть поставлені в підчерги з більш високим пріоритетом

Нарешті, ми використовуємо icmp чергу, яка резервує 2% смуги пропускання від верхнього рівня Це гарантує мінімальну пропускну здатність для ICMP трафіку, який відповідає правилу pass, але не відповідає критеріям для призначення в інші черги

Для того, щоб досягти бажаного результату, ми використовуємо правила pass, які вказують який трафік призначається в черзі і їх критерії:

set skip on { lo, $int_if }

pass log quick on $ext_if proto tcp to port ssh queue (ssh_bulk, ssh_interactive) pass in quick on $ext_if proto tcp to port ftp queue ftp

pass in quick on $ext_if proto tcp to port www queue http pass out on $ext_if proto udp queue udp

pass out on $ext_if proto icmp queue icmp

pass out on $ext_if proto tcp from $localnet to port $client_out

Правила для ssh, ftp, www, udp і icmp призначають трафік на відповідні черги Останнє правило пропускає весь інший трафік з локальної мережі направляючи його в чергу main використовувану за замовчуванням

Прості планувальники, які ми розглядали дотепер, можуть бути досить ефективними в деяких установках, однак мережеві адміністратори з високими

вимоги до формування трафіку схильні шукати більшої гнучкості ніж та, яку

дозволяють черзі засновані на пріоритетах або на класах Після тільки що описаного введення в черзі, як би це не звучало, я можу сказати, що є режим з гнучким розподілом пропускної здібності, гарантованими нижніми і верхніми межами смуги пропускання доступною для кожної черги і змінним асигнуванням смуги протягом тривалого часу – і тільки це дозволить почати формування трафіку коли це реально необхідно

Алгоритм черг HFSC (hfsc в термінології pfconf) пропонує всі ці можливості, але за додаткову гнучкість доведеться заплатити: установка буде трохи більш складною, на відміну від інших типів, а налаштування вашої установки (надалі я буду використовувати слово розгортання – пп) для досягнення оптимального результату можуть перетвориться на цікавий процес

Працюючи з тією ж конфігурацією, яку ми використовували раніше, вставимо визначення цієї черги в початок файлу pfconf:

altq on $ext_if bandwidth $ext_bw hfsc queue { main, spamd }

queue main bandwidth 99% priority 7 qlimit 100 hfsc (realtime 20%, linkshare 99%) \

{ q_pri, q_def, q_web, q_dns }

queue q_pri bandwidth 3% priority 7 hfsc (realtime 0, linkshare 3% red )

queue q_def bandwidth 47% priority 1 hfsc (default realtime 30% linkshare 47% red) queue q_web bandwidth 47% priority 1 hfsc (realtime 30% linkshare 47% red)

queue q_dns bandwidth 3% priority 7 qlimit 100 hfsc (realtime (30Kb 3000 12Kb), \ linkshare 3%)

queue spamd bandwidth 0% priority 0 qlimit 300 hfsc (realtime 0, upperlimit 1%, \ linkshare 1%)

Як ви можете бачити, визначення черги HFSC приймає дещо інші параметри, на відміну від простих дисциплін Ми почнемо з цієї, порівняно невеликий ієрархії, шляхом поділу черги верхнього рівня на дві частини На наступному рівні разобем основну чергу на кілька підчерги, кожна з яких має певний пріоритет Всі підчерги мають задане значення  realtime це мінімальна гарантована смуга пропускання виділена черги Опциональная установка upperlimit визначає набір жорстких верхніх меж розподілу смуги пропускання черги Параметр linkshare  встановлює розподіл для черги, яке буде доступне при її перевантаженні тобто, це початок її розподілу в qlimit

У разі виникнення заторів, кожна чергу за замовчуванням має пул з 50 слотів, ліміт черги (qlimit), для збереження пакетів в період коли вони не можуть бути негайно передані У нашому прикладі черги верхнього рівня main і spamd мають великі, ніж задані за замовчуванням, пули встановлені їх qlimit 100 для main і 300 для spamd Значне підвищення розмірів черг означає, що ми трохи знизимо втрату пакетів при досягнення трафіком встановлених лімітів, але це так само означає, що коли формування трафіку відвалюється, збільшується час очікування зєднання, що в кінцевому рахунку повязано з великими розмірами пулів

Ієрархія черзі використовує два знайомих прийому для ефективного використання доступної смуги пропускання:

• Використовуються варіації високого і низького пріоритетів показані в ранніх прикладах з чітим пріоритетом

• Ми підвищили швидкість практично всього іншого трафіку (і, безумовно, web-трафіку, що має в нашому випадку основний пріоритет) шляхом виділення невеликий, але гарантованої честі смуги пропускання для сервісу огляду імен Для черзі q_dns ми встановили значення realtime c лімітом часу – після 3000 мілісекунд значення realtime знижується до 12Кб Це може бути корисно для підвищення швидкості зєднань які передають більшу частину корисного навантаження в початковій фазі

Наступний крок полягає в повязанні новоствореної черги в набір правил Якщо припустити, що у вас вже існує фільтруючий режим, привязка буде напрочуд простий і включає тільки додавання кількох простих правил match:

match out on $ext_if from $air_if:network nat-to ($ext_if) queue (q_def, q_pri) match out on $ext_if from $int_if:network nat-to ($ext_if) queue (q_def, q_pri) match out on $ext_if proto tcp to port { www https } queue (q_web, q_pri) match out on $ext_if proto { tcp udp } to port domain queue (q_dns, q_pri) match out on $ext_if proto icmp queue (q_dns, q_pri)

Тут, правила match ще раз використовують трюк з прискоренням пакетів ACK за рахунок призначення черг з високим і низьким пріоритетом, аналогічно раннім прикладам використовують чисті пріоритети Єдине виняток – коли ми призначаємо трафік на чергу з найнижчим пріоритетом, ми реально не дбаємо про якому б то ні було прискоренні:

pass in log on egress proto tcp to port smtp rdr-to 127001 port spamd queue spamd

Це навмисне уповільнення спамерів на їх шляху до spamd При використанні ієрархічної системи черг, systat так само показує черги і їх трафік у вигляді ієрархії:

2 users Load 022 025 025 Fri Apr 1 16:43:37 2011

QUEUE                  BW         SCH PRIO PKTS   BYTES     DROP_P DROP_B QLEN BORROW  SUSPEN P/S  B/S root_nfe0             20M       hfsc  0        0         0                0      0      0                                                    0     0

main

19M

hfsc 7

0

0

0

0

0

0

0

q_pri

594K

hfsc 7

1360

82284

0

0

0

11

770

q_def

9306K

hfsc

158

15816

0

0

0

02

11

q_web

9306K

hfsc

914

709845

0

0

0

50

61010

q_dns

594K

hfsc 7

196

17494

0

0

0

3

277

spamd

0

hfsc 0

431

24159

0

0

0

2

174

Коренева чергу (root) Вказує приєднання до фізичному інтерфейсу – nfe0 і root_nfe0  в даному випадку main і її підчергиq_pri,  q_def,  q_web  іq_dns відображаються з їх призначеної пропускною здатністю, кількістю байт і числом минулих пакетів КолонкиDROP_P   іDROP_B   показують, відповідно, кількість скинутих пакетів і байт, якщо ми будемо змушені скидати пакети на даному етапі Останні дві колонки показують живе оновлення пакетів в секунду і байт в секунду, відповідно

Повертаючись до глави 5, згадаємо, що, ми встановили мережу з одним шлюзом, а всі сервіси, видимі з поза сконфигурировали на окремій мережі DMZ Таким чином, весь трафік на сервера, як з Інтернет так і з внутрішньої мережі повинен проходити через шлюз Схема мережі показано на малюнку 7-1, і ідентична малюнку 5-2

Використовуючи в якості відправної точки набір правил створений в розділі 5, ми будемо додавати деякі черги для оптимізації наших мережевих ресурсів Фізична і топологічна схема мережі при це не зміниться

Швидше за все, вузьким місцем в даній мережі стане пропускна здатність у сполученні між зовнішнім інтерфейсом шлюзу та Інтернетом в цілому Звичайно, пропускна здатність в інших місцях нашої мережі не нескінченна, проте доступна смуга пропускання на будь-якому інтерфейсі локальної мережі буде меншим обмежуючим фактором ніж пропускна здатність доступна для спілкування із зовнішнім світом Для сервісів, які будуть доступні з наіллучшей продуктивністю ми повинні налаштувати черги з необхідної шириною смуги пропускання надаються бажаному трафіку

У нашому прикладі, що цілком ймовірно, пропускна здатність інтерфейсу DMZ становить 100Мбіт або 1Гбіт, в той час як фактична пропускна здатність для зєднань з боку локальної мережі значно менше Це міркування відображено в наших визначеннях черги, де можна ясно бачити, що фактична пропускна здатність доступна для зовнішнього трафіку є основним обмеженням в установці черги

total_ext = 2Mb total_dmz = 100Mb

altq on $ext_if cbq bandwidth $total_ext queue { ext_main, ext_web, ext_udp, \ ext_mail, ext_ssh }

queue ext_main bandwidth 25% cbq(default borrow red) { ext_hi, ext_lo } queue ext_hi priority 7 bandwidth 20%

queue ext_lo priority 0 bandwidth 80%

queue ext_web bandwidth 25% cbq(borrow red) queue ext_udp bandwidth 20% cbq(borrow red) queue ext_mail bandwidth 30% cbq(borrow red)

altq on $dmz_if cbq bandwidth $total_dmz queue { ext_dmz, dmz_main, dmz_web, \ dmz_udp, dmz_mail }

queue ext_dmz bandwidth $total_ext cbq(borrow red) queue { ext_dmz_web, \ ext_dmz_udp, ext_dmz_mail }

queue ext_dmz_web bandwidth 40% priority 5 queue ext_dmz_udp bandwidth 10% priority 7 queue ext_dmz_mail bandwidth 50% priority 3

queue dmz_main bandwidth 25Mb cbq(default borrow red) queue { dmz_main_hi, \ dmz_main_lo }

queue dmz_main_hi priority 7 bandwidth 20% queue dmz_main_lo priority 0 bandwidth 80% queue dmz_web bandwidth 25Mb cbq(borrow red) queue dmz_udp bandwidth 20Mb cbq(borrow red) queue dmz_mail bandwidth 20Mb cbq(borrow red)

Зверніть увагу, що total_ext визначає розподіл обмеження пропускної здатності для всіх черг яким доступна пропускна здатність для зовнішніх зєднань Для використання нової інфраструктури черг, нам необхідно внести деякі зміни в правила фільтрації Майте на увазі, що будь-який трафік, який ви явно не призначаєте в певну чергу, попдает в черзі за замовчуванням для інтерфейсу Отже, це важливо враховувати при налаштуванні ваших правил фільтрації і визначенні черги актуального трафіку у вашій мережі

Основна частина правил фільтрації, після додавання черг, може виглядати приблизно так:

pass in on $ext_if proto { tcp, udp } to $nameservers port domain \ queue ext_udp

pass in on $int_if proto { tcp, udp } from $localnet to $nameservers \ port domain

pass out on $dmz_if proto { tcp, udp } to $nameservers port domain \ queue ext_dmz_udp

pass out on $dmz_if proto { tcp, udp } from $localnet to $nameservers \ port domain queue dmz_udp

pass in on $ext_if proto tcp to $webserver port $webports queue ext_web pass in on $int_if proto tcp from $localnet to $webserver port $webports

pass out on $dmz_if proto tcp to $webserver port $webports queue ext_dmz_web pass out on $dmz_if proto tcp from $localnet to $webserver port $webports \ queue dmz_web

pass in log on $ext_if proto tcp to $mailserver port smtp

pass in log on $ext_if proto tcp from $localnet to $mailserver port smtp pass in log on $int_if proto tcp from $localnet to $mailserver port $email pass out log on $dmz_if proto tcp to $mailserver port smtp queue ext_mail pass in on $dmz_if from $mailserver to port smtp queue dmz_mail

pass out log on $ext_if proto tcp from $mailserver to port smtp \ queue ext_dmz_mail

Зверніть увагу, що, в черзі буде призначатися тільки трафік, який буде проходити або через інтерфейс DMZ або зовнішній інтерфейс У даній конфігурації, без зовнішнього доступу до внутрішніх сервісів локальної мережі, черги на внутрішньому інтерфейсі не мають великого сенсу, оскільки ймовірно, що частина нашої мережі має менші обмеження на пропускну здатність

Джерело: Книга про PF, by Peter NM Hansteen, Переклад виконав Михайлов Олексій aka iboxjo

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*