Не так уж много времени прошло с тех пор, когда оператор связи предлагал свои услуги без определения их параметров качества, разве что с клиентом оговаривалась емкость канала. Более того, в порядке вещей было предложение канала с нулевым значением минимальной гарантированной скорости передачи данных (Commited Information Rate, CIR), т.е. предоставление пропускной способности по остаточному признаку и без гарантий ее наличия.

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

Но самое главное, сети на базе IP теперь доставляют не только данные, но и служат транспортом для самых разных сервисов с различными, а иногда и противоречивыми требованиями к сети: данные, видео, голос, сетевые игры, одноранговые коммуникации, разнообразные бизнес-приложения и т.д. И все эти приложения требуют от транспортной среды обеспечения заявленных параметров качества. В таких условиях нужно четко понимать, какие требования к качеству транспорта IP выдвигает клиент и что именно может предложить оператор. Назначение сетей IP изменилось, а это влечет за собой иное отношение к ним.

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

СОВРЕМЕННЫЕ ТРЕБОВАНИЯ К КАЧЕСТВУ В СЕТЯХ IP

С точки зрения сети IP, по которой осуществляется транспорт сетевых сервисов, качество транспортной среды определяется несколькими параметрами:

  • скорость подключения к магистральной сети;
  • потеря пакетов IP (процент потерь, Рacket Loss);
  • круговая задержка (Round-Trip Delay, RTD; Round-Trip Time RTT; Round-Trip Latency, RTL);
  • вариация задержки (Jitter; IP Packet Delay Variation, IPDV; Рacket Delay Variation, PDV).

Эти параметры общеизвестны, некоторых пояснений требует, пожалуй, только последний. Вариация задержки определяется в RFC 3393 как разница сквозных задержек прохождения двух пакетов (см. Рисунок 1). Если R — время отправки пакета, а S — время его доставки, то значение PDV для пакетов с номерами i и j будет рассчитываться так:

Di,j = (Rj — Ri) — (Sj — Si) = (Rj — Sj) — (Ri — Si).

В RFC 3550 определен метод инкрементального расчета вариации для серии пакетов:

Ji = Ji-1 + (|Di-1,i| — Ji-1)/16

При измерении берутся средние значения PDV за заданный промежуток времени.

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

Сетевые сервисы в разной степени чувствительны к изменениям этих параметров. Последние начинают ухудшаться в периоды перегрузок в сети (когда количество передаваемых пакетов приближается или превышает предельное значение для данного интерфейса/канала), в итоге страдают все сетевые приложения, включая приложения высокой важности.

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

ОСНОВЫ ФОРМИРОВАНИЯ ПОЛИТИКИ QOS

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

Сетевые приложения со сходными требованиями к параметрам качества объединяются в группы — классы обслуживания (Classes of Service, CoS). Трафик каждой группы приложений специальным образом маркируется на узлах поблизости от источника трафика. Для маркировки используются специальные поля в заголовках пакетов IP и/или кадров Ethernet. Этот процесс называется классификацией трафика (Classification and marking).

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

Механизмы обслуживания трафика на входном и выходном интерфейсах различаются — прежде всего, из-за трудностей организации очереди (queue) на входном интерфейсе сети. Это приводит к невозможности распределения трафика по приоритетам, т. е. нельзя гарантировать определенную пропускную способность классам сервиса на входе. Таким образом, обслуживание трафика на входных интерфейсах определяется следующими задачами:

  • Traffic Conditioning предусматривает классификацию трафика в соответствии с заданными критериями. Ее принципы описываются в соглашении о кондиционировании трафика (Traffic Conditioning Agreement, TCA);
  • выделение пропускной способности определяет максимальную (но не гарантированную!) полосу для каждого класса. Это значение ограничивает максимальный объем передаваемого трафика данного класса, трафик сверх установленного объема будет обслуживаться в соответствии с соглашением TCA. Сумма полос, выделенных для каждого класса, может превышать значение физически доступной полосы.

На выходе сети создание очередей (queue) вполне возможно, в таком случае трафик будет обслуживаться в соответствии с его приоритетом:

  • выделение гарантированной пропускной способности в моменты перегрузок для трафика реального времени путем помещения пакетов в очередь с минимальными задержками (Low Latency Queue, LLQ). Это своеобразная «очередь для тех, кто без очереди». Тем самым минимизируется вариация задержки для обслуживаемого класса. Длина этой очереди не должна быть большой, так как вариация может вырасти выше приемлемого порога на принимающем конце, что эквивалентно потерям пакетов. Иначе говоря, при большом числе запросов на обслуживание в LLQ лишние пакеты придется сбрасывать;
  • выделение гарантированной пропускной способности в моменты перегрузок для приоритетных классов. Сумма полос для каждой очереди не должна превосходить 75-80% от общей пропускной способности порта на выходе. Это ограничение является следствием невозможности обслуживания потока с гарантированными параметрами, когда загрузка приближается к 100% от реальной возможности интерфейса/канала;
  • если в одну очередь (не LLQ!) попадает более одного вида трафика, необходимо использовать механизм раннего обнаружения возникновения затора и упреждающего сброса пакетов (Weighted Random Early Detection, WRED). Этот механизм позволяет затормозить «разгон» cеансов TCP и избежать перегрузки интерфейса;
  • неприоритетный трафик обслуживается по мере возможности (best effort), т. е. при наличии свободной емкости. Он неминуемо вытесняется классами с большим приоритетом в моменты перегрузок. В зависимости от профиля трафика, доля выделенной для него пропускной способности может меняться, однако чаще всего этому классу либо ничего не гарантируется, либо выделяется небольшая доля от общей пропускной способности;
  • трафику управления сетью (Network Management) предоставляется отдельная небольшая гарантированная полоса, поскольку управление должно осуществляться вне зависимости от наличия затора на интерфейсе.

Если какие-либо сегменты корпоративной сети IP арендуются у оператора связи, что бывает в подавляющем большинстве случаев, то необходимо обеспечить взаимное отображение классов, принятые в корпоративной сети, в классы сервиса, поддерживаемые оператором. Аналогичная задача возникает в случае межоператорского взаимодействия.

Разработка универсальной услуги или проектирование корпоративной сети, способной удовлетворить самым разным требованиям, выдвигаемым со стороны корпоративных систем ИТ — задача далеко не тривиальная, каждый случай нуждается в особом профессиональном подходе.

УПРАВЛЕНИЕ КАЧЕСТВОМ

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

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

Описанная ситуация ставит перед нами ряд вопросов, не решаемых настройкой QoS:

  • как быть уверенным, что параметры качества всей сети удовлетворяют установленным требованиям?
  • как понять, что сеть готова поддержать критические для бизнеса приложения?
  • как убедиться в произвольный момент времени, что декларированные оператором параметры находятся в норме и не ухудшились с момента приема услуги?
  • как понять, что сетевым сервисам что-то угрожает?
  • в случае выхода какого-либо из параметров за установленные пределы, как выяснить причину происшедшего? Действительно ли виной тому нехватка пропускной способности?
  • на каком из участков сети возникла проблема, в чьей зоне ответственности она находится, что надо делать и кому?

Для управления качеством нужно обладать информацией об историческом и текущем положении дел в сети. Совершенно очевидно, что без полноценной системы мониторинга не обойтись. Система мониторинга и управления сетью — тема для отдельного обсуждения, мы же поговорим о ее малой и незаслуженно забываемой части — о системе контроля параметров качества в сети IP (см. также врезку «Менеджер качества IP»). Каким образом строятся подобные системы? Как осуществляется сбор информации? Как происходит привязка полученных измерений к политике дифференцированного обслуживания сети?

Для сбора данных применяется традиционный подход – на узлах сети размещаются специализированные сетевые устройства — зонды (probe), на которых запускается программный агент. Агенты в автоматическом режиме периодически рассылают друг другу тестовые пакеты и измеряют параметры их доставки: потери, задержки, вариации задержки. Полученная информация передается на более высокий уровень — в систему обработки и анализа статистики. Использование зондов на ключевых узлах сети позволяет не только фиксировать сквозные параметры, но и производить измерения на определенных участках, что в дальнейшем облегчает процесс локализации проблемы. Таким образом можно осуществлять мониторинг и управление качеством на одном из самых проблемных участков сети — на последней миле.

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

Контроль качества включает в себя автоматическое измерение и анализ следующих параметров: потери пакетов IP, круговая задержка пакетов IP, вариация задержки пакетов IP. Измерение этих параметров должно выполняться в разных классах сервиса. Сквозную пропускную способность между агентами целесообразно измерять не в автоматическом режиме, а по требованию оператора системы.

Технически весь комплекс состоит из следующих базовых элементов (см. Рисунок 2):

  • агенты измерения параметров качества – программно-аппаратные системы, размещаемые на узлах сети. Агенты осуществляют автоматизированные замеры параметров качества по собственным либо стандартным протоколам. Кроме того, возможно использование пассивного устройства с активированными службами ICMP или UDP/TCP Echo. В роли пассивных агентов могут выступать маршрутизаторы, серверы и специализированные устройства. Агенты не занимаются сложной обработкой измеренных параметров, а передают их в систему анализа статистики;
  • система анализа статистики — программная система, которая реализует логику обработки и хранения статистических данных. Ядро получает от агентов и обрабатывает первичные данные о качестве, агрегирует их, преобразует в оптимальную для хранения форму и сохраняет в базе данных. При выявлении нарушений возможен вызов внешних сценариев. Так, сигналы тревоги с информацией о факте нарушения можно отправлять в центральную систему управления посредством SNMP trap, Syslog, электронной почты или SMS. Возможна реализация автоматической обратной связи с сетевыми устройствами;
  • интерфейс статистики – информационная система с графическим интерфейсом на базе Web или GUI позволяет просматривать полученную и обработанную ядром информацию о параметрах качества. Отчеты могут как генерироваться автоматизированно на регулярной основе (например, отчеты за месяц), так и подготавливаться по требованию. Кроме просмотра статистики посредством прямых запросов, весьма полезен функционал «доски здоровья» — интерфейс, где отображается интегральная информация о нарушениях. При фиксации факта нарушения, загорается сигнал тревоги, и оператор, перейдя на страницу детальной статистики, может проанализировать возникшую проблему;
  • система управления – система конфигурации с графическим интерфейсом, позволяющая описать политику качества сети посредством определения классов сервиса, параметров, норм и действий, необходимых в случае нарушения последних. Кроме того, с ее помощью можно осуществлять конфигурацию агентов и тестов.

МОДЕЛИ SLA

Как можно видеть, вопрос обеспечения качественного функционирования сети чрезвычайно важен; для этого необходим комплекс технических мер по реализации политики обслуживания сети, а также система контроля и управления качеством. Но что делать, если специфика деятельности компании далека от ИТ? Нужно ли набирать штат специалистов, отвечающих за эксплуатацию и поддержку сетевой инфраструктуры предприятия?

Как всегда, из рассматриваемой ситуации есть, по крайней мере, два выхода. Первый — делать все собственными силами. Он потребует участия квалифицированного персонала — либо путем прямого найма, либо в результате привлечения сетевых специалистов из сторонней компании, когда вся сетевая инфраструктура, оснащенная системами управления и мониторинга, оказывается в зоне ответственности последней. Второй способ — отдать вопросы управления качеством на откуп оператору, предоставляющему услуги связи. В таком случае придется приобрести и услугу управления оборудованием, поскольку ни один оператор не станет отвечать за качественное функционирование корпоративной сети, если конфигурация оборудования находится вне его контроля. Рассмотрим, что обычно предлагает оператор своему клиенту.

Оператор предложит заключить соглашение об уровне сервиса (Service Level Agreement, SLA). Этот договор означает не что иное, как гарантию соответствия продаваемого продукта заявленным характеристикам, и подразумевает ответственность продавца перед покупателем. В сфере телекоммуникаций, во всяком случае, на российском рынке телекоммуникационных услуг, он понимается несколько расплывчато. Зачастую SLA представляет собой всего лишь шильдик, призванный завлечь покупателя. Нередко при продаже услуг связи SLA заключается при полном отсутствии технических возможностей мониторинга как со стороны клиента, так и со стороны оператора. Оператор не в состоянии отследить проблему у клиента, а клиент ничего не докажет оператору, например, после неудачной попытки проведения видеоконференц-связи.

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

SLA для магистрали. Магистральный SLA подразумевает контроль параметров качества в ядре сети оператора между пограничными маршрутизаторами его сети. За каждым пограничным маршрутизатором устанавливается агент (см. Рисунок 3). Между агентами осуществляется измерение параметров качества. Контролироваться могут как базовые параметры качества, так и параметры качества сетевых сервисов. Клиентам предоставляется доступ к данным измерений между теми пограничными маршрутизаторами, к которым подключены клиентские маршрутизаторы. Этот уровень SLA не включает контроль последних миль и клиентских маршрутизаторов.

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

SLA с контролем доступности последних миль. В этом случае к магистральному уровню SLA добавляется проверка доступности последних миль (см. Рисунок 4). Параметры качества контролируются между агентами, установленными за пограничными маршрутизаторами, и пассивными агентами в корпоративной сети клиента с использованием эхо-сервисов ICMP или UDP/TCP. На этом уровне осуществляется только контроль доступности устройств на площадке клиента, но не контроль качества сервисов. Хотя данный вид SLA позволяет следить за параметрами качества прохождения трафика по последней миле, эти параметры не могут считаться достоверными и рассматриваются исключительно как оценочные, так как связанный агент может вносить существенные погрешности в результаты тестов. При такой схеме вариация задержки не контролируется. Клиент видит и качество продвижения трафика на магистрали, и доступность своих последних миль, однако этот уровень не предоставляет полной и достоверной информации о параметрах качества на всех участках сети.

Управляемое SLA. Данный вид SLA подразумевает сквозной контроль параметров качества на любых участках корпоративной сети (см. Рисунок 5). Зонды размещаются на узлах сети, наиболее критичных с точки зрения прохождения трафика приложений. Контролю подлежит как доступность линий передачи, так и параметры качества сервиса. Тесты в корпоративной сети могут выполняться произвольным образом с любой топологией связности — в зависимости от пожеланий клиента. Клиент может получить услугу управления качеством на любых участках своей сети, чем обеспечивается охват и детализация наиболее критичных ее фрагментов. Следует иметь в виду, что в рассматриваемой модели SLA договор будет заключаться для каждой пары точек.

Этот уровень SLA используется в сочетании с первыми двумя — контролем качества магистрали и контролем доступности последних миль. Управляемое SLA предоставляет наиболее полную и достоверную информацию о параметрах качества прохождения трафика в корпоративной сети: клиент получает достоверную информацию о параметрах качества на необходимых ему участках сети, на всех его последних милях, а также на магистрали. Предельные значения параметров качества для сквозных измерений подбираются для каждого направления в отдельности.

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

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

ЗАКЛЮЧЕНИЕ

В условиях многообразия сетевых сервисов качество обслуживания имеет большое значение, причем у каждого сервиса свои требования к параметрам качества. Однако, насколько мне известно, ни один из операторов, действующих на территории России, пока не предлагает SLA ни одного из перечисленных типов в качестве стандартного договора. Реализации SLA первого и второго типов имеются, однако они не серийные, требуют специального решения и заключаются в основном с VIP-клиентами. Кроме того, на текущий момент мне не известно ни одной реализаций SLA третьего типа — единственно необходимого для управления качеством.

Максим Краюшин — руководитель направления, компания «НетПроб». С ним можно связаться по адресу: m.krayushin@net-probe.ru.

Менеджер качества IP

Функционал системы контроля качества, описанный в данной статье, реализует, например, аппаратно-программный комплекс IP Quality Manager (IQM) компании «НетПроб». Это решение позволяет получать информацию о сквозных параметрах качества с учетом классов сервиса и поддерживаемых сетью зональных признаков. Контроль качества включает в себя анализ следующих параметров: потери пакетов IP, круговые задержки пакетов IP, вариации задержки пакетов IP.

В качестве зонда пригодна любая x86-совместимая платформа под управлением ОС Linux. Это может быть безвентиляторный «тонкий клиент» с флэш-памятью или настольный ПК. Кроме того, возможно применение сетевого сервера совместно с другими сетевыми службами. Система IQM интегрируется с системами управления и статистики других разработчиков, например, с системой Lancelot компании Avalon Net.

Рисунок 1. Вариация задержки возникает вследствие разновременной доставки пакетов.

Рисунок 2. Основные компоненты системы контроля параметров качества.

Рисунок 3. В модели магистрального SLA зонды с работающими на них агентами размещены на узлах сети оператора, что позволяет измерить параметры качества ядра сети.

Рисунок 4. Модель магистрального SLA с контролем доступности последних миль предусматривает тестирование доступности устройств, расположенных на клиентской площадке за последней милей.

Рисунок 5. В модели управляемого SLA зонды с работающими на них агентами размещаются как на узлах сети оператора, так и на узлах сети клиента для контроля параметров качества магистрали, линий доступа и сквозных параметров по выбранным направлениям (в приведенном примере осуществляется контроль параметров качества между локальной сетью и демилитаризованной зоной).