Home Система IQM Контроль качества на сетях IP

Авторизация



Рейтинг@Mail.ru Rambler's Top100
Контроль качества на сетях IP PDF Печать E-mail
Автор: Максим   
05.03.2009 16:14

 

Контроль качества на сетях IP.


Максим Краюшин ООО «НетПроб»

m.krayushin@net-probe.ru 

+7 919 968 6404

Сокращенная версия статьи была опубликована в журнале сетевых решений ЛАН за февраль 2008г. Ссылка на статью. 

 

ОГЛАВЛЕНИЕ:

1. Аннотация
2. Введение
3. Философия
4. Быт
5. Продукты и ассоциации
6. Качество и связь
7. Кому и зачем это нужно?
8. Параметры качества
9. Сетевые приложения и классы сервиса
10. Основные моменты формирования политики QoS
11. Управление качеством
12. IP Quality Manager
13. Модели SLA
14. Заключение
15. Справка о компании НетПроб

16. Ссылки на RFC

 

1. Аннотация

Статья ориентирована на широкий круг специалистов и менеджеров, занятых в различных производственных сферах, деятельность которых связана с предоставлением или потреблением услуг сетевых приложений. Рассматривается понятие качества услуг сетевого транспорта, обосновывается необходимость обеспечения и поддержания качества для корректного функционирования сетевых приложений различных типов. Определены основные параметры качества, нормируемые для IP-сетей. Рассмотрены различные типы приложений и их требования к параметрам качества сети. Приведены основные принципы, необходимые для формирования политики дифференцированного обслуживания трафика различных сетевых сервисов. Объяснена необходимость проведения контроля параметров качества на сети. Рассмотрены принципы функционирования и основные требования к системам контроля качества на примере IQM. Приведены основные парадигмы систем контроля качества, используемые операторами связи для обеспечения SLA.

 

2. Введение

Статья демонстрирует возрастающую роль понятия качества телекоммуникационных услуг и его важность в развитии бизнеса, как у потребителей услуг, так и у провайдеров и у разработчиков. Конечно, рассматриваемое понятие является интуитивно очевидным, однако, часто приходится сталкиваться с недооценкой его важности. Так же, в статье приводится общее описание продукта компании NetProbe — IP Quality Manager, позволяющего развернуть систему контроля качества, как на корпоративной сети, так и на сети оператора.


3. Философия

Как в русском так и в английском языках существует несколько смежных значений слова «качество» (quality): с одной стороны это некая философская сущность предмета, а с другой — мера его превосходства относительно других предметов, в частности — товаров. Я решил проверить другие языки: испанский, итальянский, немецкий, французский. В результате поверхностного анализа словарей оказалось, что только в немецком словаре разные понятия этого слова обозначаются по-разному, в то время как в остальных одинаковым словом можно сослаться на различные понятия — как на определяющую предмет сущность, так и на относительное превосходство. Порассуждаем, есть ли в этом какой-либо глубинный смысл. Я не лингвист, но полагаю, что такое совпадение совершенно не случайно появилось одновременно в нескольких языках. Сущность предмета-продукта и его качественно-количественные показатели — неотделимы, поскольку именно они определяют комплексное суммарное представление о нем.


4. Быт

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


5. Продукты и ассоциации

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


6. Качество и связь

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


7. Кому и зачем это нужно?

Теперь мир изменился... В том числе и отношение к телекоммуникационным услугам. Почему? С одной стороны, потому, что повысилась конкуренция на телекоммуникационном рынке, предложение зачастую превышает спрос, клиент получил возможность выбирать, стоимость услуг неукоснительно падает, а операторы постоянно развивают свои магистральные сети — расширяют емкость, расширяют территориальное покрытие. С другой стороны — технология не стоит на месте: появились новые средства и механизмы передачи данных, их защиты. Но самое главное в том, что сети, построенные на базе IP, больше не являются сетями передачи исключительно данных, теперь они образуют единую инфокоммуникационную среду, как для предприятий, так и для отдельных потребителей. Среду, способную служить транспортом для совершенно разных сервисов с совершенно различными, а иногда даже и противоречащими требованиями к сети: передача данных, видео, голоса, сетевые игры, одноранговые сети, различные приложения, отвечающие за поддержание жизненного цикла предприятия — OSS, BSS, что угодно! И все эти приложения требуют своего качества от транспортной среды. Кому сейчас нужен Интернет без связанности с Google, Yandex, wiki, без Skype? Кому нужна корпоративная защищенная сеть без гарантий по пропуску трафика реального времени, видео? В таких условиях уже нужно четко понимать, какие требования к качеству продукта есть у клиента с одной стороны и что именно может предложить оператор — с другой. Теперь понятно, что в первую очередь изменилось качество IP сетей в смысле их сущности.


Было перечислено множество стимулирующих факторов, возникших по разные стороны баррикад:

  • со стороны потребителей телеком-услуг это необходимость развития эффективности собственного бизнеса за счет внедрения новых сервисов и систем его поддержки, обеспечения надежного и безопасного функционирования IT-систем; экономии средств за счет конвергенции существующей сетевой инфраструктуры; возможности выбора провайдера телекоммуникационных услуг и, как следствие, необходимости сопоставления предлагаемых продуктов с точки зрения цена-качество

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

  • производители телекоммуникационного оборудования и ПО, систем поддержки телекоммуникационной инфраструктуры и бизнеса – вместе с операторами заинтересованы в повышении собственной доходности за счет качественного развития своей продукции

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


8. Параметры качества

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

  • Потеря IP пакетов (процент потерь, packet loss). Это отношение количества отправленных, но не дошедших до адресата пакетов к общему числу отправленных пакетов, которые были переданы по сети в заданном направлении. При измерениях, процент потерь усредняется на заданном фиксированном промежутке времени.

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

  • Круговая задержка (RTD — round-trip delay time, RTT — round-trip time, RTL — round-trip latency). Это время, которое потребуется для прохождения пакета из одной точки сети в другую и обратно — до получения ответного пакета. Так же определяются задержки одностороннего прохождения, однако они редко используются на практике в связи со сложностями их измерения. Измерения производятся на заданном промежутке времени, при этом фиксируются максимальная, минимальная и средняя задержка за период.

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

  • Вариация задержки (Jitter, IPDV — IP Packet Delay Variation, PDV — packet delay variation). Параметр определяется в RFC 3393 как разница сквозных задержек прохождения двух пакетов. Обозначив 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 сети. В идеальном случае, вариации должны быть равны нулю, то есть скорость доставки пакетов не должна изменяться. Однако, в силу неоднородности сетевого потока, проходящего через узлы сети, а так же вследствие действия механизмов дифференцированного обслуживания сетевого трафика вариации не являются нулевыми. Вполне естественно ожидать, что PDV будет расти в моменты перегрузок на интерфейсах сетевых устройств.

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


9. Сетевые приложения и классы сервиса

Перечисленные выше параметры называются параметрами качества IP сети. Сетевые сервисы в разной степени чувствительны к изменениям этих параметров.

Для примера приведем оценку требований к параметрам качества со стороны разных групп сетевых служб:


Приложения

___________

Требования

Голосовые интерактив

Видео интерактив (конференции)

Видео неинтерактив

Бизнес-критические (БД, OSS, BSS)

Управление сетью

Передача данных

Чувствительность к потерям

низкая

высокая

Высокая или средняя

Средняя или высокая

средняя

средняя

Чувствительность к задержкам

высокая

средняя

низкая

низкая

Низкая или средняя

низкая

Чувствительность к PDV

высокая

средняя

средняя

низкая

низкая

низкая

Требования к полосе

Средние или низкие

высокие

Высокие или средние

Средние или низкие

низкие

Высокие или средние

Важность приложения

высокая

высокая

низкая

высокая

высокая

средняя


Следует понимать, что строка «важность приложения» представляет собой усредненную субъективную оценку и может меняться в зависимости от специфики деятельности организации.

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

 

10. Основные моменты формирования политики QoS

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


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


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


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


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

  1. Traffic Conditioningосуществление классификации трафика в соответствие с заданными критериями. Способы такого приведения описываются в TCA (Traffic Conditioning Agreement – Соглашение о кондиционировании трафика).

  2. Выделение полосы – позволяет определить максимальную (но не гарантированную!) полосу для каждого класса. Гарантируется только, что трафик данного класса не превысит максимальную полосу. Трафик, превысивший определенную полосу, будет обслужен в соответствии с соглашением TCA. Сумма полос, выделенных для каждого класса, может превышать значение физически доступной полосы.


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

  1. Выделение полосы, гарантированной в моменты перегрузок для трафика реального времени, критичного к PDV, в очереди с минимальными задержками (LLQ — low latency queue). Это своеобразная «очередь без очереди», которая обслуживается тут же, как только в нее попадает хотя бы один пакет, тем самым минимизируя вариацию задержки для обслуживаемого класса. С другой стороны, длина этой очереди не может быть большой, так как в этом случае вариация может увеличиваться выше порога приемлемости на приемном конце, что эквивалентно потерям пакетов. Поэтому, при появлении большого количества запросов на обслуживание в LLQ гораздо дешевле сбросить лишние пакеты.

  2. Выделение полосы, гарантированной в моменты перегрузок для приоритетных классов. Сумма полос, выделенных на выходе для каждой из организуемых очередей не должна превосходить 75-80% от общей полосы. Это ограничение говорит о невозможности осуществления обслуживания потока с гарантированными параметрами, при загрузке, превышающей этот порог.

  3. В случае, если в одну (не LLQ!) очередь попадает более одного типа трафика, необходимо использовать механизм раннего обнаружения возникновения затора и упреждающего сброса пакетов (WRED — weighted random early detection). Этот механизм позволяет затормозить «разгон» TCP-сессий и избежать перегрузки интерфейса.

  4. Неприоритетный трафик должен передаваться в режиме best effort, то есть при наличии свободной емкости. Он должен вытесняться более приоритетными классами в моменты возникновения перегрузок. В зависимости от профиля трафика, доля выделенной полосы для best effort может меняться, однако, в большинстве случаев, этому классу либо не следует гарантировать вообще ничего, либо можно предоставить небольшую гарантированную долю от общей пропускной полосы.

  5. Для Network Management отдельно выделяется небольшая гарантированная полоса, управление должно быть доступно вне зависимости от наличия затора на интерфейсе.


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


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


11. Управление качеством

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

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


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


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

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

  • Как понять, что что-то начинает угрожать сетевым сервисам?

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


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

Традиционный подход в реализации подобных систем заключается в расстановке сетевых проб (на базе «теневых маршрутизаторов»), проведении тестов между пробами, сбора данных о проведенных измерениях и передаче их в центральную систему статистики и анализа. Система статистики и анализа отвечает за обработку и представление данных, представляет необходимый функционал для определения принципов политики контроля качества (классы, зоны, параметры, пороги, действия), определения перечня агентов со всеми рабочими параметрами и тестов, должна иметь интерфейсы во внешние системы управления для передачи параметров, статистики или просто для сигнализации об инцидентах нарушения. Рассмотрим подробнее на примере продукта компании НетПроб — IP Quality Manager.


12. IP Quality Manager

IP Quality Manager (IQM) — аппаратно-программный комплекс, он позволяет получать информацию о сквозных параметрах качества с учетом классов сервиса и зональных признаков, поддерживаемых сетью.

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

В качестве пробы может быть использована любая x86-совместимая платформа под управлением OS Linux, требования к аппаратной платформе – минимальны: память от 512М, свободное дисковое пространство – от 1Г. Это может быть безвентиляторный “тонкий клиент” с флэшовой памятью, настольный PC, возможно использование сетевого сервера совместно с другими сетевыми службами. Несмотря на то, что вполне возможно совместное использование аппаратной платформы как для запуска агентов, проводящих измерения параметров качества, так и для представления других сервисов, следует понимать, что точность измерений на загруженном устройстве, работающем на грани возможностей своих аппаратных ресурсов будет ухудшаться по сравнению с выделенным сервером. Такие измерения могут носить лишь оценочный характер. В этом плане более выигрышным выглядит эксклюзивное использование аппаратных ресурсов для функции измерения.

Контроль качества включает в себя анализ следующих параметров: потери IP пакетов, круговой задержки IP пакетов, вариации задержки IP пакетов. Измерение этих параметров может производиться в разных классах сервиса, например: standard, premium и real-time. Возможен учет зональной структуры сети, что часто используется операторами при предоставлении услуг IP VPN.


На рисунке проиллюстрированы основные компоненты системы IQM.

Технически, комплекс IP Quality Manager состоит из следующих базовых элементов:

Агенты измерения параметров качества – программно-аппаратные системы, работающие на теневых маршрутизаторах и производящие автоматизированные замеры параметров качества между собой по собственным, либо стандартным протоколам. Агенты могут инициировать тестовые сеансы, а так же принимать запросы от других агентов на произведение замеров. Кроме того, в качестве сопряженного агента возможно использование пассивного устройства с запущенными службами ICMP или UDP/TCP Echo. В роли пассивных агентов могут выступать маршрутизаторы, серверы, специализированные устройства. Агенты не производят сложной обработки измеренных параметров, они передают их в практически исходном виде в ядро IQM — систему анализа статистики.

Система анализа статистики IQM, программная система, расположенная в сетевой инфраструктуре пользователя комплекса, реализует логику обработки и хранения статистических данных. Ядро получает и обрабатывает первичные данные по качеству от агентов, агрегирует их, преобразует в оптимальную для хранения форму, сохраняет в базе данных. Проводит анализ нарушений, в случае их возникновения нарушений возможен вызов внешних сценариев для их выполнения. Это позволяет реализовать функционал отправки сигналов тревоги с информацией о факте нарушения в центральную систему управления посредством SNMP trap либо syslog-сообщений, или отправки сообщений на электронную почту или SMS. Так же возможна реализация автоматической обратной связи с сетевыми устройствами.

Интерфейс статистики IQM – информационная система с графическим интерфейсом, построенным на базе Web, позволяет просматривать полученную и обработанную ядром информацию по параметрам качества. Возможна как автоматизированная генерация отчетов на регулярной основе (например, отчеты за месяц) так и подготовка отчета по требованию. Кроме просмотра статистики посредством прямых запросов, интерфейс поддерживает функционал «доски здоровья» - это страница, отображающая суммарную информацию о нарушениях. В случае если за определенное временное окно фиксируется факт нарушения — загорается сигнал тревоги, и оператор, увидев его, может перейти на страницу детальной статистики для проведения анализа возникшей проблемы.

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


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


13. Модели SLA

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


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


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


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


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


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

 

 

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

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

 

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

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

 

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

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


14. Заключение

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

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


15. Справка о компании НетПроб

Компания ООО «НетПроб» («Network Probe») организована в августе 2008 года группой специалистов, принимавших непосредственное участие в проектировании, строительстве и эксплуатации сетей таких компаний, как Sprint/Глобал Один/Эквант, ТТК, РТКомм.Ру. Основные услуги и направления деятельности «Нет Проб» – разработка и внедрение систем анализа потоков трафика, систем управления и мониторинга мультисервисных сетей, проектирование, строительство IP/MPLS сетей, аутсорсинг технической эксплуатации сетей, системная интеграция.

 

16.Ссылки на RFC

  1. Request for Comments: 3393. IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).

  2. Request for Comments: 3550. RTP: A Transport Protocol for Real-Time Applications.

  3. Request for Comments: 4594. Configuration Guidelines for DiffServ Service Classes.

 

Публикация статьи или ее фрагментов без разрешения автора запрещены.

 

 

Обновлено 18.11.2010 14:38
 
Copyright © 2024 Net-Probe LLC. Все права защищены.