Глава 4. Scheduling: различия между версиями
м (→Delay buffers) |
м (→Drop profiles) |
||
Строка 125: | Строка 125: | ||
== Drop profiles == | == Drop profiles == | ||
- '''RED drop profiles''' - как отрасывать трафик, когда возникает запор. Работает напрямую с буфферами, берет трафик, который | - '''RED drop profiles''' - как отрасывать трафик, когда возникает запор. Работает напрямую с буфферами, берет трафик, который поместился в буффер. | ||
Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress). | Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress). | ||
Строка 133: | Строка 133: | ||
'''fullness''': наполненность буффера. | '''fullness''': наполненность буффера. | ||
'''drop probability''': вероятность, что пакет | '''drop probability''': вероятность, что пакет будет отброшен. | ||
По сути | Для drop-profile задаём значения для этих двух параметров. | ||
По сути получается линия на графике, где соотносятся fullness (%) и drop probability (%). | |||
'''How it works''': | '''How it works''': | ||
#Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100. | |||
#Числа нанесены на график отношения fullness и drop probability (по оси fullness). | |||
#Когда случайный номер выше линии, пакет передается. | |||
#Когда случайный номер ниже линии, пакет дропается. | |||
Чтобы сделать более тонкую обработку трафика, рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять каждый к разному типу трафика. | |||
Такой подход является более взшешанным (weighted RED = '''WRED'''). | |||
Такой подход является более взшешанным (weighted RED = WRED). | |||
Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем effective maximum buffer size. | Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем effective maximum buffer size. | ||
Если для очереди назначен менее агрессивный drop profile, то она полностью будет использовать буффер. Если используем более агрессивный, то буффер не будет заполняться до конца | Если для очереди назначен менее агрессивный drop profile, то она полностью будет использовать буффер - такой drop-profile хорошо использовать до более приоритетного трафика. Если используем более агрессивный, то буффер не будет заполняться до конца - подобное поведение свойственно менее приоритетному трафику. | ||
'''Config options''' | '''Config options''' |
Версия 19:50, 19 января 2017
About
С помощью классификатора определили трафик в разные очереди, теперь нужно как-то трафик обрабатывать. Этим процессом как раз занимается scheduler:
- Порядок передачи пакетов
- Скорость передачи пакетов
- Кол-во пакетов, которое можно забуфферизировать
- Разный способа обработки пакетов в случае заторов на сети.
Разная обработка трафика на основании loss-priority.
- Классификация или полисер назначили PLP
- PLP соответствует scheduling traffic profile
- Traffic profile соответствует drop profile
- Drop profile определяет вероятность отброса трафика
Port-based queues
Каждый порт может содержать 4-8 очереди.
Одной очереди может быть назначено более одного forwarding class.
PQ-DWRR: priority queue deficit round-robin: механизм для выбора очереди и последующей передачи пакета. Priority - очереди обслуживаются в порядке, сконфигурированном для очередей.
WRED: Weighted random early detection: механизм для отброса пакетов. Основан на сконфигурированных параметрах: fw-class, PLP. С помощью него можно избежать и контролировать заторы.
Scheduling components
Transmission rate
- Transmission rate - кол-во пропускной способности от интерфейса, выделенной этой очереди. Похоже на CIR.
Очередь может превышать tranmission rate, если есть неиспользуемая полоса. Тут также используется терминология in-profile, out-of-profile, смысл такой же как и для CIR.
edit class-of-service schedule schedule-name transmit-rate (rate | percent | remainder) exact | rate-limit
remainder - заполнение оставшегося буфера.
exact - буферизирует трафик, который превысил transm rate.
rate-limit - дропает трафик, который превысил transm rate.
no settings - очередь может превысить transm rate, если есть неиспользуемая полоса.
Есть значения по умолчанию. Так как по умолчанию в джуне созданы 2 fw-class (best-effort (0) и network-control (3)), то дефолтные параметры есть только для этих очередей.
Для best-effort - 95, для netw-control - 5.
Unusable bandwidth
В случае, когда у нас сформированы 2 очереди и trasm-rate между ними делится 50/20%, в таком случае получаем неиспользуемую полосу 30%.
Эта неиспользуемая полоса будет использоваться только очередями, у которых есть превышение transm-rate.
Scheduler будет делить неиспользуемую полосу между подходящими очередями.
Чтобы исключить очередь, используем exact или rate-limit в настройке.
Queue priority
- Priority - приоритет среди других очередей. Во времена запоров приоритетом определяется в каком порядке будут обрабатываться очереди.
Значения:
- Low
- Medium-low
- Medium-high
- High
- Strict-high - traffic always in-profile. Пакеты в этой очереди всегда в первую очередь используют необходимую полосу.
Остальные очереди передают трафик в порядке убывания приоритета от high к low.
Трафик в in-profile (по transmission rate) low priority, будет обрабатывается до трафика out-profile strict priority.
То есть сначала вне зависимости обрабатывается трафик в in-profile, только потом out-profile.
Strict-priority - опсана! она может сожрать всю полосу и остальные очереди могут "голодать". Но High-prioroty делит полосу с Strict.
Чтобы не происходило голодания, мы можем: 1. также важным очередям назначать High-priotity. 2. для strict-priority задавать в transm-rate rate-limit.
Разрешается задавать 1 Strict-priority на 1 интерфейс.
edit class-of-service schedule schedule-name priority ...
Дефолтные значения для дефолтных fw-class: best-effort - low, network-control - low.
Delay buffers
- Delay buffers - кол-во данных, кот можно хранить.
larger buffer = many packet stores = large supported latency.
Buffer size - это параметр, определяющийся размер буфера интерфейса и также зависит от платформы.
edit class-of-service schedule schedule-name buffer-size percent | temporal | remainder
percentage: буфер "эластичный", когда очередь начинает использовать бОльшую полосу, чем ей было выделено изначально (transm-rate), буфер будет автоматически увеличиваться.
effective delay buffer (ms) = buffer size (%) * max port buffer size (ms) effective delay buffer (s) * interf bandwidth (Mbps) / 8 = buffer size (MB) [используется для конвертации в Мбайты]
Пример:
100 ms - max buffer size 1GB ports для очереди 0 - задаем percentage = 30%: effective delay buffer = 30 ms, buffer size = 0,03 s * 1000 Mbps /8 = 3,75 MB для очереди 1 - задаем percentage = 45%: effective delay buffer = 45 ms, buffer size = 0,045 s * 1000 Mbps /8 = 5.625 MB
temporal: для задания размера такого буфера используются мс. Буфер не эластичный, имеет строгий верхний лимит и дропает весь трафик, превышающий этот лимит. Для вычисления оптимального размера буфера используется значение transmission-rate.
buffer size (MB) = max buffer size (s) * transmit rate (Mbps) / 8 buffer size (MB) = max buffer size (s) * [interface bandw (Mbps) * transmit rate (%)] / 8
Пример:
100 ms - max buffer size 1GB ports для очереди 2 - задаем transmission rate = 100 Mbps (10%): buffer size = 0,1 * 100 Mbps / 8 = 1,25 MB для очереди 2 - задаем transm rate = 10% : buffer size = 0,1 * 1000 Mbps * 0.1 / 8 = 1,25 MB для очереди 3 - задаем transmission rate = 300 Mbps (30%): buffer size = 0,1 * 300 Mbps / 8 = 3,75 MB для очереди 3 - задаем transm rate = 30% : buffer size = 0,1 * 1000 Mbps * 0.3 / 8 = 3,75 MB
remainder: использует все не занятое другими очередями пространство.
Когда мы выставляем buffer size и transm rate в процентном соотношении, хорошей практикой считается выставлять пропорциональные (равные) значения, но это не обязательно вообще.
В обоих случаях размер буффера будет увеличиваться при увеличении transm rate.
Default scheduler settings: Для best-effort - 95, для netw-control - 5, что равно дефолтным значениям transm-rate.
Drop profiles
- RED drop profiles - как отрасывать трафик, когда возникает запор. Работает напрямую с буфферами, берет трафик, который поместился в буффер.
Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress).
Параметры:
fullness: наполненность буффера.
drop probability: вероятность, что пакет будет отброшен.
Для drop-profile задаём значения для этих двух параметров. По сути получается линия на графике, где соотносятся fullness (%) и drop probability (%).
How it works:
- Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100.
- Числа нанесены на график отношения fullness и drop probability (по оси fullness).
- Когда случайный номер выше линии, пакет передается.
- Когда случайный номер ниже линии, пакет дропается.
Чтобы сделать более тонкую обработку трафика, рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять каждый к разному типу трафика.
Такой подход является более взшешанным (weighted RED = WRED).
Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем effective maximum buffer size.
Если для очереди назначен менее агрессивный drop profile, то она полностью будет использовать буффер - такой drop-profile хорошо использовать до более приоритетного трафика. Если используем более агрессивный, то буффер не будет заполняться до конца - подобное поведение свойственно менее приоритетному трафику.
Config options
Помимо drop probability и fullness при конфигурации следует учитывать, что эти параметры могут задаваться:
segmented: график строится по указанным в конфигурации значениям. Особенность: так как график будет выглядить как лесенка, то на разных промежутках, при разных значениях fullness, мы будем иметь одно и то же значение drop probability.
Пример конфига:
set class-of-service drop-profiles segmented fill-level 25 drop-probability 25 set class-of-service drop-profiles segmented fill-level 50 drop-probability 50 set class-of-service drop-profiles segmented fill-level 75 drop-probability 75 set class-of-service drop-profiles segmented fill-level 95 drop-probability 100
interpolated:
Представляет собой гладкий график, постепенно возвышающийся.
Строится автоматически, состоит из 64 координат, включая координаты, которые мы задали для построения кривой.
Пример конфига:
set class-of-service drop-profiles interpolated interpolate fill-level [50 75] drop-probability [25 50]
Default settings
fill-level 0 drop-probability 0 fill-level 100 drop-probability 100
Вообще дефолтная настройка смысла не имеет, так как начинает отбрасывать пакеты только при полной загруженности буффера, что и без того происходит! )
Apply drop profile
Помимо того что drop profile нужно создать, для его работы его нужно прикрепить к какой-нибудь очереди.
Одной очереди может быть применено более 1 drop profile для разных типов трафика.
Также drop profile придает значение для PLP. До этого PLP было просто меткой, прикрепленной к пакету.
Также drop profile может быть назначен по protocol-specific: non-TCP, TCP, all traffic.
Drop profile map options
loss-priority: low, medium-low, medium-high, high. any
protocol: tcp, non-tcp, any
drop profile: desired drop-profile.
edit class-of-service schedule schedule-name drop-profile-map loss-priority ... protocol ... drop-profile ...
По сути здесь выцепляется трафик из определенного forwarding-class, с определенным PLP, опеределнного протокола и к нему применяется определенный drop-profile.
Default scheduler settings
edit class-of-service schedule schedule-name drop-profile-map loss-priority any protocol any drop-profile terminal
set class-of-service drop-profiles terminal fill-level 100 drop-probability 100
Scheduler configuration
1. Configure scheduler, including drop profile
a Transmission rate
b Queue priority
c Delay buffers
d Drop profile
e Drop profile maps
2. Configure scheduler map
Schedulers придуманы, чтобы определенным образом управлять определенным трафиком. Сами по себе schedulers ничего не делают, нужна привязка. Scheduler-map как бы линк между forw-class и scheduler.
3. Apply scheduler map to an interface.
Будет работать в outbound направлении. Для port-level queueing вешается на физический интерфейс.
Пример:
scheduler
set class-of-service drop-profiles relaxed interpolate fill-level [75 90 100] drop-probability [0 75 100] set class-of-service drop-profiles aggressive interpolate fill-level [50 75 90 100] drop-probability [0 50 75 100]
set class-of-service schedulers sch-be transmit-rate percent 70 set class-of-service schedulers sch-be buffer-size percent 70 set class-of-service schedulers sch-be priority low set class-of-service schedulers sch-be drop-profile-map loss-priority high protocol any drop-profile aggressive set class-of-service schedulers sch-be drop-profile-map loss-priority low protocol any drop-profile relaxed
set class-of-service schedulers sch-pri transmit-rate percent 30 set class-of-service schedulers sch-pri buffer-size percent 30 set class-of-service schedulers sch-pri priority high
scheduler map
set class-of-service scheduler-maps sched-map-example forwarding-class best-effort-data scheduler sch-be set class-of-service scheduler-maps sched-map-example forwarding-class priority-data scheduler sch-pri
apply to an interface
set class-of-service interfaces ge-0/0/0 scheduler-map sched-map-example