Под знаком качества

Под знаком качества

Владимир Долгов, системный инженер, Cisco Systems

Построение корпоративных сетей с интеграцией услуг на базе протокола IP сегодня является вполне решаемой задачей. Рынок предлагает все необходимое оборудование, которое может обеспечить передачу данных, голоса, видео - любых видов трафика - в рамках единой сети IP. Но то, что задача выполнима, еще не означает ее абсолютной простоты. Интеграция услуг в IP-сетях стала возможна за счет того, что в них появились ранее не присущие IP механизмы поддержки качества обслуживания. В силу того, что эти механизмы привиты "извне", причем относительно недавно, представление о том, как они работают и как эффективно их использовать, еще не является широко распространенным. Между тем, внедряя в своем окружении приложения, требующие QoS, такие, как, например, IP-телефония, необходимо ответственно подходить к вопросам системной политики в отношении приоритетов качества обслуживания. Попробуем рассмотреть эту проблему вплотную на примере архитектуры Cisco AVVID.

В порядке очереди

Системная политика в отношении качества обслуживания определяется путем решения трех базовых задач: определения приоритетов различных видов трафика, организации очередей обслуживания и определения требуемой в свете двух предыдущих пунктов полосы пропускания. Сами приоритеты могут задаваться на нескольких уровнях. На МАС-уровне в сетях, поддерживающих качество обслуживания согласно стандарту 802.1Q/p, можно задать фреймам класс обслуживания CoS (приоритет, присваиваемый конкретному порту). На третьем уровне пакет IP может содержать информацию о приоритете IP (IP Precedence) и информацию DiffServe. Код DiffServe определяет, как каждый узел сети должен "относиться" к пакету EF (Expedited Forwarding), и означает непременную пересылку. AF (Assured Forvarding) подразумевает пересылку с некоторой степенью гарантии (и подразделяется на 4 класса, внутри каждого определены три степени сброса пакетов, 1-меньшая), а Best Effort означает, что система будет стараться переслать пакет, но без каких-либо гарантий.

Комбинация трех приоритетов - порта (пользователя) и типа трафика определяет итоговый приоритет обслуживания. Очевидно, что комбинаций может быть очень много, и важно выбрать правильную. Типичными приоритетами в архитектуре AVVID, например, являются для VoIP (собственно голосовых пакетов) CoS - 5, IP Precedence - 5 DSCP - EF, а для управляющий трафика VoIP - 3, 3, AF31. В свою очередь, для видеотрафика устанавливаются параметры CoS - 4, DSCP - AF41 для видеоконференций, и для потокового видео 1 и AF13 соответственно. Потоки данных получают CoS и IP Precedence от 0 до 2, а по DSCP они попадают в низшую категорию. Разумеется, по обстановке приоритеты можно задать и несколько другими.

После того, как мы задали все приоритеты, надо определить, как же "строить" потоки данных в очередь. Можно выделить три базовых метода организации очередей. Первый тип, PQ (Priority Queueing), реализует самую простую схему: пакеты в зависимости от их приоритета выстраиваются в несколько очередей. Первой обслуживается очередь с самым высоким приоритетом, за ней следует следующая по списку и так далее. Очевидно, что при таком подходе вероятность того, что очередь с самым низким приоритетом не будет обслуживаться в течение длительного времени, очень велика, поскольку к тому времени, как подойдет ее черед, могут успеть восстановиться очереди с более высоким приоритетом. К тому же логика приоритезации задается статически. Преимущество такого подхода - гарантированная передача трафика с самым высоким приоритетом.

Более интеллектуальный подход демонстрирует очередь типа CQ (Custom Queing). В этом случае каждая очередь получает свою долю полосы пропускания, а обслуживание очередей происходит циклически. Во время каждого цикла очередь использует свою долю полосы, чтобы "отстреляться". Если полоса, выделяемая под очередь, достаточно широкая, то очередь может быть обслужена целиком за один цикл. В противном случае часть ее останется дожидаться следующего цикла. Очевидно, что есть вероятность того, что очереди с низким приоритетом и небольшой долей полосы пропускания не будут успевать обслуживаться в течение каждого цикла, то есть потеря пакетов будет очень велика. Более того, если поток пакетов с высоким приоритетом будет очень большим, то вероятны задержки и в его обслуживании. Также к недостаткам этого подхода является статическая приоритезация. Третий, еще более интеллектуальный подход WFQ (Weight Fair Queing) в чем-то схож с CQ. В нем так же циклично обслуживаются очереди с выделенными под них полосами пропускания. Отличия заключаются в том, что трафик, передаваемый небольшими порциями, обслуживается на постоянной основе в рамках некоторой полосы пропускания, а остальной трафик делит между собой оставшиеся ресурсы. При этом, если в каком-то цикле одна (или более) очередей пуста, ее полоса пропускания пропорционально перераспределяется между остальными очередями. Таким образом решаются проблемы с нехваткой времени на обслуживание очередей, а полоса пропускания перераспределяется динамически.

Помимо базовых существуют и гибридные типы очередей. Сочетание PQ и WFQ называется IP RTP Priority. Принцип этого подхода заключается в том, что у нас выделяется приоритетный трафик, который обслуживается первым. А после того как очередь опустеет, оставшийся трафик обслуживается по механизму WFQ. Комбинация CQ и WFQ называется CBWFQ (Class-Based Weight Fair Queueing). Мы выделяем отдельные классы трафика, как в CQ, и точно так же резервируем под них часть полосы пропускания. Неклассифицированный трафик обслуживается по механизму WFQ. И, наконец, самым всеобъемлющим подходом в организации очередей является комбинация всех трех базовых типов. Это сочетание может быть описано неудобочитаемой аббревиатурой PQCBWFQ, но более обиходным является название LLQ (Low Latency Queueing). Механизм LLQ включает в себя выделение приоритетных очередей, как в PQ, и обслуживание остальных по принципу CBWFQ. Возможности оптимального обслуживания очередей в LLQ этим, правда, не ограничиваются. Можно также оптимизировать их обработку на Уровне 2. Поскольку трафик из очередей уровня PQ отличается небольшим размером пакетов, а для остального трафика характерен больший размер, есть вероятность, что в выходном буфере большие пакеты будут долго дожидаться своей очереди. Для того чтобы не создавать дополнительного узкого места, эти пакеты "нарезаются" на фрагменты, которые "выстреливаются", чередуясь с маленькими пакетами. Этот механизм схож с тем, что применяется в Voice over Frame Relay, и во многом на нем базируется. Также можно оптимизировать механизм сброса "хвостов" очередей (когда задержка в обслуживании переходит разумный предел и очередь уже не помещается в буфер). Это реализуется (не только, кстати, в LLQ, но и в CBWFQ) при помощи механизма WRED (Weighted Random Early Detection). Несмотря на звучание этой аббревиатуры на русском языке, механизм приносит пользу. Суть WRED в том, что если в рамках одной очереди у нас также есть разница в приоритетах пакетов, то, как только начинают появляться признаки того, что предел буфера будет

достигнут, из очереди удаляются пакеты с наименьшим приоритетом. Таким образом "цена" потерь при сбросе снижается.

В архитектуре AVVID в зависимости от ситуации можно эффективно использовать подходы разной сложности. Что и как использовать, зависит от ситуации и является вопросом планирования.

Вопросы планирования

Рассматривая различные схемы организации очередей, мы отметили, что в некоторых случаях в той или иной степени вероятно возникновение "узких" мест. Главная задача планирования системной политики - избежать их возникновения на всех участках сети.

Может показаться, что поддержка QoS нужна только там, где нам приходится экономить полосу пропускания. Это заблуждение, даже если не вспоминать один из "сетевых" законов Паркинсона (любых ресурсов рано или поздно становится недостаточно). Проблемы могут возникнуть даже в ядре сети, поскольку выходные буферы центральных устройств могут оказаться заполненными на 100%, что, в свою очередь, приведет к сбросу пакетов на входе. Если поддерживается организация множественных очередей, то этого можно избежать. В сети с интеграцией услуг на базе IP мы должны обеспечить поддержку QoS на всех уровнях.

Если рассмотреть стандартный пример корпоративной сети (головной офис, соединенный по глобальным каналам с одними или несколькими филиалами), то можно определить требования к QoS. На уровне рабочих групп, как в центральном, так и удаленных офисах, мы должны обеспечить поддержку CoS на уровне 2. Это касается как коммутаторов, так и такого оборудования, как IP-телефоны. В архитектуре AVVID IP-телефоны могут выполнять роль мини-коммутаторов, пропуская через себя трафик от рабочих станций. Таким образом, одно рабочее место может использовать только одну информационную розетку (очевидно, что, при практически повсеместном переходе на 100-мегабитные соединения на уровне рабочих мест, это вполне оправдано). На этом уровне мы должны обеспечить, чтобы приложения, выполняющиеся на ПК, не порождали в сети трафик с высоким приоритетом. Эту задачу может выполнить IP-телефон. В том случае, если мы используем программно реализованный IP-телефон, или же ПК просто подсоединены непосредственно в сеть, задача администратора состоит в проверке того, что ни одно приложение не генерирует пакеты с высоким приоритетом.

На уровне ядра сети мы должны обеспечить уже поддержку политики QoS на уровне 3, поддерживая множественные очереди и выделяя голосовой трафик в PQ. Очереди потоков данных должны обрабатываться с применением WRED. На уровне магистрали глобальной сети, нам необходимо поддерживать LLQ, фрагментацию пакетов и обеспечить контроль за использованием полосы пропускания. В частности, надо следить, чтобы в магистраль не попадали "несанкционированные" голосовые приложения, иначе существующая схема поддержки QoS не справится с дополнительной нагрузкой. Нет нужды говорить, что политика приоритезации должна быть единой и согласованной на всех участках сети.

После того, как мы разобрались с системной политикой, необходимо оценить требуемые для функционирвания приложений ресурсы. Иными словами, требуется подсчитать, сколько каждый вид трафика потребует полосы пропускания. Методика достаточно проста, это, как говорится табличные данные, но надо помнить о всех накладных расходах. Если мы говорим, например, о VoIP, то мы, помимо определяемых компрессией килобит в секунду, должны учесть и накладные расходы на заголовки IP, и накладные расходы на заголовки фреймов и/или ячеек.

Очевидно, что один и тот же поток, проходя по локальной сети и по глобальным каналам, будет использовать разную абсолютную полосу пропускания. Также надо не забывать про то, что передача голоса или видео подразумевает и передачу контрольной/управляющей информации. Мы учли это в приоритезации и учитываем в оценке пропускной способности.

Общая требуемая полоса пропускания рассчитывается как 4/3 от совокупной минимальной полосы для всех видов трафика. Лишняя треть будет израсходована на потоки данных управления сетью (протоколы маршрутизации и тому подобное), а также будет использована как запас на вероятные пиковые ситуации.

Завершив полный цикл - приоритезация трафика, определение политики QoS и итоговое планирование требуемых ресурсов, - мы можем приступить к построению сети и разворачивания в ней всех требуемых сервисов. Разумеется, реальное поведение трафика может отличаться от расчетного, но, поскольку в наших руках находится достаточно гибкий механизм адаптации системной политики к поведению трафика в сети, она может быть приведена в соответствие с реальными условиями.

Заключение

Как видим, сама по себе поддержка оборудованием качества обслуживания еще не гарантирует успешную работу приложений, требующих QoS. (В неумелых руках механизмы QoS могут даже ухудшить ситуацию.) При организации системной политики в отношении приоритетов обслуживания очень важно иметь возможность контролировать ее корректное выполнение на всех уровнях - от ядра до периферии сети. Только в этом случае можно по-настоящему эффективно использовать сети с интеграцией услуг на базе IP. В связи с этим, надо очень ответственно подходить к выбору платформы для развертывания сервисов IP.