Управление QoS

дает возможность задавать политики QoS и определять их цели. Общая методика включает в себя приведенные ниже действия.

Этап 1: Установить в сети устройства типа датчиков RMON. Это позволит определить типовые параметры передачи данных по сети. Кроме того, необходимо установить приложения, требующие использования функций QoS (обычно требования приложений представляют собой время отклика).

Этап 2: После того, как будут получены параметры передачи данных по сети и выбраны приложения, требующие повышения QoS, следует настроить соответствующие механизмы QoS.

Этап 3: Оценить результаты путем тестирования откликов от выбранных приложений, чтобы определить, достигнуты ли нужные показатели QoS.

Для упрощения внедрения QoS можно использовать менеджер политик Cisco (Quality of Service Policy Manager — QPM) и менеджер устройств Cisco (Quality of Service Device Manager — QDM). Для тестирования полученного уровня обслуживания можно воспользоваться менеджером производительности сети Cisco (Internetwork Performance Monitor — IPM).

Следует исходить из того, что в постоянно меняющейся сетевой среде обеспечение QoS не является единичным действием, а является постоянной и существенной частью сетевого проекта.

Уровни сквозного QoS

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

В гетерогенных сетях предоставляются описанные ниже три основных уровня сквозного QoS (рис. 59.2).

• Обслуживание с негарантированной доставкой. Также называется службой без QoS. Простейшее соединение без каких-либо гарантий доставки. Важнейшим признаком такого обслуживания является использование очередей типа "первым вошел — первым вышел" (first in — first out — FIFO), в которых отсутствует дифференциация потоков.

•          Дифференцированное обслуживание. Также называется гибким QoS. При его использовании некоторые виды данных обрабатываются лучше, чем остальные (быстрее обрабатываются, больше средняя полоса пропускания, ниже средний уровень потерь). Однако это лишь статистическая оценка, без жестких и четких гарантий. Этот вид обслуживания обеспечивается путем классификации потоков данных и использования таких средств QoS, как установка очередностей PQ, CQ, WFQ, и WRED (все они описываются далее в настоящей главе).

•          Гарантированное обслуживание. Также называется жестким QoS. Полное резервирование сетевых ресурсов для конкретных типов данных. Обеспечивается с помощью таких средств QoS, как протокол резервирования ресурсов (Resource Reservation Protocol — RSVP) и установка очередности CBWFQ (описываются далее в настоящей главе).

Выбор типа обслуживания зависит от описанных ниже факторов.

•          Тип используемого приложения или проблемы, которые нужно решить пользователю. Каждый из трех типов обслуживания подходит для определенных приложений. Это не означает, что пользователь должен переходить на дифференцированное, а затем на гарантированное обслуживание (хотя, возможно, многие пользователи именно так впоследствии и сделают). Ему вполне может подойти дифференцированное обслуживание или даже негарантированная доставка — все зависит от требований, выдвигаемых приложениями пользователя.

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

•          Стоимость реализации и распространения гарантированного обслуживания, скорее всего, будет выше стоимости внедрения дифференцированного обслуживания.

Интерфейс командной строки модульного качества обслуживания QoS

Интерфейс командной строки (Command-Line Interface — CLI) модульного QoS Cisco определяет на маршрутизаторе новую конфигурацию основанного на CLI модульного QoS. Эта новая структура для задания политик QoS группирует элементы конфигурации QoS в три отдельных модуля: определение класса потока данных, задание политики и применение политики.

В CLI-модели модульного QoS политики QoS могут быть сконфигурированы на маршрутизаторе в три этапа, по одному на каждый модуль новой модели интерфейса CLI.

1.        Определение класса для потока данных: конфигурирование политики классификации потоков. Это осуществляется с помощью команды конфигурирования class map.

2.        Задание политики: конфигурирование политик для различных определенных классов потоков данных. Для этого используется команда конфигурирования policy map.

Различные архитектуры QoS

Для облегчения реализации QoS в IP-сети группа IETF (Internet Engineering Task Force) разработала две модели: модель интегрированных служб (Integrated Services — IntServ) и модель дифференцированных служб (Differentiated Services — DiffServ или DS). Модель IntServ следует модели сигнализируемого QoS, в котором конечный узел сообщает сети о своих потребностях в QoS. Модель DiffServ работает на основе provisioned модели QoS, в которой сетевые элементы конфигурируются для обслуживания различных классов данных с разными требованиями к QoS. Программное обеспечение IOS Cisco поддерживает обе модели: как IntServ, так и DiffServ QoS.

Модель IntServ обеспечивает всеобъемлющее сквозное решение проблемы QoS путем сквозной сигнализации, поддержки состояния Спя каждого потока и резервирования протокола RSVP) и управление допуском к каждому сетевому элементу. С другой стороны, модель DiffServ удовлетворяет потребность в относительно простых, хотя и не слишком строгих методах обеспечения QoS путем причисления потоков данных к различным классам обслуживания (CoS) и применения к этим классам параметров QoS. Для этого пакеты подразделяются на классы путем задания типа обслуживания (type-of-service — ToS) в соответствующем байте IP-заголовка.

Архитектура интегрированных служб

3. Применение политики: включение использования политики на интерфейсе. Для этого используется команда конфигурирования service policy.

Рис. 59.2. Три уровня сквозного QoS: негарантированная доставка, дифференцированное обслуживание и гарантированное обслуживание

Цяя сигнализации и резервирования ресурсов, которое обеспечивает требуемое качество обслуживания QoS каждого потока в сети, модель IntServ использует протокол резервирования ресурсов RSVP. Обычно пакеты, проходящие по сети, идентифицируются на основе принадлежности к определенному потоку с использованием пяти полей в IP-заголовке: IP-адрес источника, IP-адрес получателя, поле протокола IP, а также порты источника и получателя. Отдельный поток состоит из пакетов, передаваемых от приложения станции-отправителя приложению станции получателя. Пакеты, принадлежащие к одному и тому же потоку, имеют одни и те же значения в пяти полях потока IP-заголовка. С помощью протокола RSVP могут быть запрошены два типа обслуживания ToS (предполагается, что все сетевые устройства на маршруте от отправителя к получателю поддерживают протокол RSVP). Первый тип представляет собой строгую гарантирующую службу, которая задает четкие границы сквозной задержки и гарантированную полосу пропускания для потоков данных, удовлетворяющих спецификациям резервирования ресурсов. Второй тип обслуживания представляет собой службу, управляющую нагрузкой, которая гарантирует, что поток с зарезервированными ресурсами на пути к получателю будет иметь минимальное вмешательство со стороны потоков данных негарантированной доставки.

Архитектура дифференцированных служб

Модель DiffServ обеспечивает дифференцированное качество обслуживания QoS различным типам данных приложений путем отнесения потоков данных к различным классам обслуживания.

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

Архитектура модели DiffServ задает стандартные комбинации битов в байте DiffServ и для каждой из них определяет свой способ пересылки, называемый стратегией на отдельном переходе (per-hop behavior). Обработка по принципу негарантированной доставки, которая используется в настоящее время в Internet, является одним из возможных способов пересылки данных.

Архитектура DiffServ обеспечивает структуру, в которой провайдеры служб могут предложить своим клиентам ряд сетевых служб, дифференцированных по уровню производительности. Пользователь может выбрать требуемый ему уровень производительности для отдельных пакетов; для этого достаточно установить в пакете соответствующее значение поля кодовой точки дифференцированных служб (Differentiated Services Code Point – DSCP).

Байт дифференцированных служб

IP-очередность при отбрасывании использует три бита очередности в поле ToS заголовка протокола IPv4 для задания класса обслуживания каждому пакету.

Группа дифференцированных служб при IETF стандартизовала использование 6 битов байта ToS IP-заголовка для кодовой точки DSCP. Младшие 2 бита в настоящее время не используются (currently unused — CU). Кодовая точка DSCP представляет собой расширение 3-х битов, используемых IP-очередностью.

Аналогично IP-очередности при отбрасывании использование кодовой точки DSCP обеспечивает дифференцированное обслуживание соответствующим образом помеченным пакетам. При стандартизации поля DSCP байт ToS был переименован в байт дифференцированных служб (DS byte). 6-битовый шаблон для кодовой точки (DSCP) в DS-байте, определенный в RFC 2474, показан на рис. 59.3.

Рис. 59.3. Кодовая точка DSCP, определенная в RFC 2474

Классификация: идентификация потоков

Для того, чтобы предоставить некоторым потокам повышенный приоритет, их необходимо идентифицировать и (при желании) пометить (снабдить меткой). Эти две задачи обычно называют классификацией (classification).

Исторически сложилось так, что идентификация осуществлялась с использованием списков управления доступом (access control list — ACL). Списки ACL идентифицируют потоки данных для таких механизмов управления переполнением, как PQ-очередность и CQ-очередность. Поскольку очередности PQ и CQ устанавливаются на маршрутизаторах только в рамках одного перехода (т.е. приоритеты качества обслуживания QoS относятся лишь к данному маршрутизатору и не передаются следующим на маршруте маршрутизаторам), идентификация пакета используется только на одном маршрутизаторе. В некоторых случаях классификация CBWFQ также относится только к одному маршрутизатору. Такой подход противоположен установке битов IP-очередности.

Для установки очередности, основанной на классификации по расширенным спискам доступа, могут быть использованы такие функции, как маршрутизация, основанная на политиках и согласованная скорость передачи CAR. Это обеспечивает значительную гибкость при назначении очередности, в частности ее назначение в зависимости от приложения или пользователя, от подсети получателя или отправителя и т.д. Обычно эти функции применяются как можно ближе к границе сети (или административного домена), с тем чтобы каждый последующий сетевой элемент мог предоставить службу, основанную на определенной ранее политике.

Для более подробной идентификации потоков данных используется основанное на типе сети распознавание приложения (Network-based application recognition — NBAR). Например, могут быть идентифицированы адреса URL в пакете протокола HTTP. Как только пакет идентифицирован, он может быть помечен путем задания ему приоритета.

Задание политики QoS и основанная на политике маршрутизация

Основанная на политике маршрутизация IOS Cisco (Cisco IOS Policy-Based Routing — PBR) позволяет классифицировать потоки данных на основе критериев расширенных списков доступа, установить биты очередности протокола IP и даже направить эти потоки по маршрутам, выбранным в результате перераспределения потоков, которое может потребоваться для обеспечения требуемого QoS при передаче данных по сети. Путем установки уровней очередности для входных потоков данных и использования их вместе с механизмами очередности, описанными выше в настоящей главе, можно создать дифференцированную службу. Эти механизмы предоставляют мощные, простые и гибкие варианты реализации политик QoS в сети пользователя.

При использовании основанной на политике маршрутизации происходит преобразование маршрутов для того, чтобы они удовлетворяли определенным критериям потоков. После того, как удовлетворены требования списков доступа, а происходит установка битов очередности.

Следует разделять возможность установки IP-очередности и первичную способность маршрутизации PBR маршрутизировать пакеты на основе сконфигурированных политик. Некоторые приложения или потоки данных могут использовать в разных ситуациях конкретные типы QoS-маршрутизации, например, передавать в течение короткого времени информацию фондовой биржи в корпоративный офис по более дорогостоящему, но имеющему большую полосу пропускания каналу и одновременно продолжая передавать обычные данные приложений, такие как сообщения электронной почты, по недорогим каналам с небольшой полосой пропускания. Маршрутизация PBR может быть использована для направления пакетов по маршрутам, отличающимся от тех, которые были выбраны протоколами маршрутизации. Она предоставляет более гибкие средства маршрутизации пакетов, дополняя существующие механизмы протоколов маршрутизации.

Использование преобразования маршрутов также дает возможность идентифицировать пакеты на основе атрибутов протокола граничного шлюза (Border Gateway Protocol — BGP), таких как списки сообществ и маршруты автономных систем AS Такая идентификация известна как распространение политики QoS при посредстве протокола граничного шлюза (QoS policy propagation via Border Gateway Protocol).

Согласованная скорость передачи CAR: установка IP-очередности

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

Имеет место некоторая путаница при использовании CAR для установки битов IP-очередности. Ниже сделана попытка внести ясность в этот вопрос. Как показано далее в настоящей главе, маршрутизация CAR (что видно из ее названия) используется для передачи потоков данных с согласованной скоростью передачи (committed access rate). Это делается с помощью контейнера маркеров (token bucket). Контейнер маркеров содержит маркеры, каждый из которых соответствует одному байту данных (1 маркер = 1 байт). Контейнер заполняется маркерами со скоростью, сконфигурированной пользователем. Когда поступают пакеты для последующей отправки, система просматривает содержимое контейнера на предмет наличия в нем маркеров. Если количество маркеров в контейнере соответствует размеру пакетов, то маркеры удаляются и пакет передается (в этом случае говорят, что пакет соответствует условиям [conformsJ). Если количество маркеров в контейнере меньше размера пакета, то он отбрасывается (в этом случае говорят, что пакет является избыточным — exceeds).

При использовании CAR-реализации в операционной системе IOS Cisco кроме передачи пакета или отбрасывания его имеется много других возможных вариантов действий. Одним из таких вариантов является установка битов IP-очередности. Если обе операции — "conform" и " exceed" указывают на необходимость установки одних и тех же значений битов очередности, то выполняется уже не функция выбора политики, а просто используется метод установки битов IP-очередности.

На рис. 59.4. показан процесс принятия решения о согласованной скорости передачи. Любой пакет, находящийся ниже этой скорости передачи, соответствует заданным условиям. Пакеты, находящиеся выше скорости передачи, являются избыточными. В приведенном примере предписываемое действие для обоих случаев состоит в установке set prec = 5. В этом случае скорость передачи не имеет значения, а функция CAR просто используется для установки битов очередности.

Puc. 59.4. Принятие решения о согласованной скорости передачи.

При установке IP-очередности на узле или в сети пользователя эта установка может использоваться по желанию пользователя; однако она может быть изменена политикой, определенной в сети. IP-очередность позволяет установить классы обслуживания с использованием уже существующих в сети механизмов задания очередности (например, WFQ или WRED), без внесения изменений в уже существующие приложения или сложные требования сети. Следует отметить, что этот подход может быть легко распространен на протокол IPv6 путем использования поля приоритета (Priority field).

Для решения этой задачи программное обеспечение IOS Cisco использует преимущества сквозной природы протокола IP путем наложения зависящей от технологии 2-го уровня QoS-сигнализации на методы 3-го уровня IP-сигнализации QoS протокола RSVP и IP-очередности.

Платформа Cisco 7500

Программное обеспечение IOS Cisco также обеспечивает распределенную согласованную скорость доступа (Distributed Committed Access Rate — D-CAR) на процессорах универсального интерфейса (Versatile Interface Processor — VIP) платформы 7500. Функция D-CAR может быть использована для установки битов IP-очередности точно таким же образом, как и функция CAR. Она может также поместить пакеты в группы QoS, которые используются в основанной на классах очередности D-WFQ, а также для задания политики в D-CAR.

NBAR: динамическая идентификация потоков

Новейшим методом классификации, разработанным корпорацией Cisco, является распознавание приложений на основе типа сети (Network-Based Application Recognition — NBAR) Строго говоря, в настоящее время метод NBAR является только инструментом идентификации, однако в настоящем изложении он будет рассматриваться как метод классификации. Как и во всяком механизме классификации, наиболее сложной частью является идентификация потоков данных. Маркировка пакетов относительно проста. Функция NBAR переносит идентификацию (которая является частью классификации) на другой уровень. При более глубоком анализе содержимого пакета идентификация может быть выполнена, например, по адресу URL или по типу MIME HTTP-пакета. Эта возможность становится существенной по мере того, как все большее количество приложений начинает базироваться на Web-тсхнологиях.

В этом случае возникает необходимость различать заказ на передачу данных и обычную Web-навигацию. Кроме того, функция NBAR может идентифицировать различные приложения используя виртуальные порты. NBAR делает это, просматривая управляющие пакеты с целью определения портов, на которые приложение решает отправить данные.

NBAR имеет две представляющие большой интерес дополнительные функции, которые делают ее исключительно ценной. Одна из них состоит в способности NBAR определить используемый протокол. Это позволяет ей упорядочивать на интерфейсе данные различных протоколов. Функция NBAR составляет список протоколов, которые она может идентифицировать, и предоставляет статистику по каждому из них. Второй функцией является использование модуля языкового описания пакета (Packet Description Language Module — PDLM), который позволяет легко добавлять дополнительные протоколы к имеющемуся у NBAR списку идентифицируемых протоколов. Эти модули создаются и загружаются во флэш-память, которая, в свою очередь, загружается в RAM. Использование модулей PDLM позволяет добавлять к этому списку идентифицируемых протоколов дополнительные протоколы без замены версии IOS на более позднюю и без перезагрузки маршрутизатора.

Внимание!

Хотя NBAR лишь идентифицирует пакеты, они могут быть также и помечены с помощью установки битов IP-очередности.

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100