Control of IP networks quality parameters (Russian article) |
Written by Максим | ||||||||||||||||||||||||||||||||||||||||||
Thursday, 05 March 2009 16:14 | ||||||||||||||||||||||||||||||||||||||||||
Контроль качества на сетях IP. Максим Краюшин ООО «НетПроб» +7 919 968 6404 Сокращенная версия статьи была опубликована в журнале сетевых решений ЛАН за февраль 2008г. Ссылка на статью.
ОГЛАВЛЕНИЕ: 1. Аннотация
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 сетей в смысле их сущности. Было перечислено множество стимулирующих факторов, возникших по разные стороны баррикад:
Кто является основной движущей силой в этой цепочке — вопрос о курице и яйце. Понятно, что в данном случае речь идет о синергии — процессе, определяющем обоюдное развитие в условиях и симбиоза и конкуренции. Главное в том, что качество теперь играет важнейшую роль в развитии рынка телекоммуникаций, и попытка пренебречь им — была бы слишком дорогой роскошью. 8. Параметры качестваС точки зрения IP сети, предоставляющей сетевым сервисам услуги транспорта, нормируются несколько параметров, определяющих качество транспортной среды:
Потери пакетов могут появляться за счет искажений пакетов, возникающих при их доставке или за счет перегрузок на линиях передачи и сетевых устройствах, приводящих к их отбрасыванию.
Задержка распространения пакета по сети определяется множеством факторов: временем формирования пакета на станции-отправителе, задержкой передачи между узлами сети, задержкой коммутации-маршрутизации, временем, требуемым на обработку пакета на приемной станции.
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 сети. Сетевые сервисы в разной степени чувствительны к изменениям этих параметров. Для примера приведем оценку требований к параметрам качества со стороны разных групп сетевых служб:
Следует понимать, что строка «важность приложения» представляет собой усредненную субъективную оценку и может меняться в зависимости от специфики деятельности организации. Как видно из описаний параметров, все они начинают ухудшаться в моменты перегрузок на каналах и сетевых интерфейсах (т.е. в моменты времени, когда скорость запросов на обслуживание потока приближается или превышает предельное значение, ограниченное возможностями интерфейса/канала), при этом начинают страдать все сетевые приложения, включая приложения высокой важности. Для того, чтобы критически важные сетевые сервисы не страдали в моменты перегрузок, на протяжении всего транзитного участка должна быть реализована политика дифференцированного обслуживания трафика сетевых сервисов – QoS. QoS представляет собой набор методов, позволяющий управлять перечисленными выше параметрами качества и распределять полосу пропускания в моменты перегрузок таким образом, чтобы обеспечить выживание критических сервисов за счет вытеснения трафика менее важных сетевых приложений.
10. Основные моменты формирования политики QoSМетодология построения модели QoS и ее реализации на сети выходит за рамки данной статьи. Однако, полагаю, следует коснуться основных принципов построения сети с поддержкой QoS. Сетевые приложения со сходными требованиями к параметрам качества объединяются в группы — классы CoS (Classes of Service – классы обслуживания). Трафик каждой из групп приложений специальным образом маркируется на участках сети, максимально приближенных к источнику трафика. Для маркировки используются специальные поля в заголовках IP-пакетов и/или кадров Ethernet. Этот процесс называется классификацией трафика (Classification and marking). Производится анализ распределения имеющейся полосы между сформулированными классами, на его основе формируется профиль трафика, определяющий какому классу какую часть полосы и с какими параметрами следует предоставить в момент перегрузки. Этот процесс называется профилированием трафика. Определяются участки сети, на которых вероятно возникновение перегрузки. Конфигурация политик обслуживания осуществляется именно на этих узлах. Следует различать механизмы обслуживания трафика, доступные на входном интерфейсе и на выходном. Различие заключается в трудностяхорганизации очереди (queue), на входном интерфейсе сети, это приводит к практической невозможности проведения приоритезации трафика,то есть невозможности гарантирования полосы классам сервиса на входе. Таким образом, обслуживание трафика на входных интерфейсах определяется следующими задачами:
На выходе сети, напротив, существует возможность создания очередей (queue), которые позволят проводить приоритетное обслуживание трафика в различных очередях:
Если какие-либо фрагменты корпоративной IP сети являются арендованными у оператора связи, что имеет место в подавляющем большинстве случаев, либо имеет место межоператорское взаимодействие по IP, то возникает задача взаимного отображения классов, имеющихся на корпоративной сети в классы сервиса, поддерживаемые оператором. Разработка универсальной услуги или дизайн корпоративной сети, способной удовлетворить самым разным требованиям, выдвигаемым со стороны корпоративных IT систем — задача совершенно нетривиальная и требует вмешательства специалистов для индивидуального рассмотрения в каждом случае. 11. Управление качествомРеализация политики дифференцированного обслуживания на корпоративной сети далеко не достаточная мера для защиты критически важных приложений корпоративной сети. QoS будет успешно работать в моменты близкие к перегрузкам, это важно и нужно для корпоративной сети, однако, недостаточно. Например, нередки случаи, когда неожиданно качественные параметры почему-то ухудшаются. Сетевой администратор сбивается с ног, чтобы выяснить причину, обращается к оператору за поддержкой. Ответ оператора может оказаться в духе: «покупайте у нас дополнительную полосу», что весьма «конструктивно», с точки зрения оператора, но не очевидно для его клиента. Возникает патовая ситуация: денег на расширение полосы не запланировано, проблема не решается, причины ее не выяснены, что делать — непонятно. В конце концов, может выясниться, что причиной ухудшения качества сети оказался всего-навсего «звенящий» интерфейс на одном из узлов сети. Из описанной ситуации сразу вытекает ряд вопросов, не решаемых настройкой QoS:
Будущее неизвестно... когда неизвестно прошлое и настоящее. Чтобы управлять качеством, нужно обладать информацией об историческом и текущем положении дел на сети. Совершенно очевидно, что без полноценной системы мониторинга здесь не обойтись. Система сетевого мониторинга и управления — тема для отдельного обсуждения, здесь мы поговорим лишь о ее малой части, о которой обычно забывают — системе контроля параметров качества на IP-сети. Каким образом строятся подобные системы? Как осуществляется сбор информации? Как происходит привязка полученных измерений к политике дифференцированного обслуживания принятой на сети? Традиционный подход в реализации подобных систем заключается в расстановке сетевых проб (на базе «теневых маршрутизаторов»), проведении тестов между пробами, сбора данных о проведенных измерениях и передаче их в центральную систему статистики и анализа. Система статистики и анализа отвечает за обработку и представление данных, представляет необходимый функционал для определения принципов политики контроля качества (классы, зоны, параметры, пороги, действия), определения перечня агентов со всеми рабочими параметрами и тестов, должна иметь интерфейсы во внешние системы управления для передачи параметров, статистики или просто для сигнализации об инцидентах нарушения. Рассмотрим подробнее на примере продукта компании НетПроб — IP Quality Manager. 12. IP Quality ManagerIP 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
Публикация статьи или ее фрагментов без разрешения автора запрещены.
|
||||||||||||||||||||||||||||||||||||||||||
Last Updated on Thursday, 18 November 2010 14:38 |