| Рубрикатор |  |
 |
| Статьи |  |
ИКС № 2 2007 | |
|
| Л.И. БУЛГАК | 01 февраля 2007 |
Дежурный по услугам Мониторинг SLA
С ростом разнообразия и сложности сервисов, предоставляемых в сетях VPN, оператор уже не может ограничиться просто контролем возможности передачи трафика и должен поддерживать на надлежащем уровне качество передачи. Решение этой проблемы обеспечивают OSS-системы, осуществляющие мониторинг уровня обслуживания заказчиков (SLA-мониторинг). Каким требованиям должна отвечать подобная система? Компания РТКОММ, пребывающая в состоянии выбора оптимального решения SLA-мониторинга, делится своими соображениями относительно критериев выбора.
Доступность услуги и деградация сервиса
Интеграция различных приложений в единой, безопасной, проверенной и протестированной сети VPN позволяет корпоративным заказчикам эффективно и с высоким качеством использовать одну линию доступа для телефонии и видеоконференций, работы с приложениями корпоративных информационных систем типа клиент–сервер, электронной почты и работы с вебсерверами. Обратная сторона интеграции – высокая зависимость бизнеса заказчика от обеспечиваемой оператором транспортировки трафика между офисами (мониторинг наложенных сервисов оставим за рамками этой статьи). Более того, на практике возникают ситуации, когда, несмотря на имеющуюся возможность передавать трафик (т.е. доступность услуги), заказчик не может использовать то или иное приложение из-за низкого качества передачи трафика оператором. В таких случаях принято говорить о деградации предоставляемого оператором сервиса. Соответственно, в требованиях заказчиков к услугам оператора связи все чаще на первое место выходит не просто передача разнородного трафика, а предоставление сервиса нужного качества. И оператору требуются механизмы, позволяющие обеспечивать качество передачи трафика, отслеживать его уровень и представлять результаты своей работы заказчикам.
С точки зрения заказчика идеальным было бы просто перечислить в соглашении об уровне обслуживания (SLA) приложения, работоспособность которых гарантируется оператором. Однако для оператора, который обеспечивает всего лишь транспортировку трафика, такая постановка вопроса зачастую неприемлема – не все составляющие, влияющие на работоспособность приложения, находятся в зоне его ответственности. Попробуем определить, какие показатели могут быть включены в SLA и понятны как оператору (с точки зрения измерения), так и заказчику (с точки зрения их влияния на приложения).
Конвергируем и... дифференцируем
Разные приложения (голос, видео и критически важные данные) предъявляют разные, причем весьма жесткие, требования к сетевой инфраструктуре и качеству передачи трафика. Последнее, в свою очередь, определяется тремя параметрами: процентом потерянных пакетов, задержкой и колебаниями задержки.
Приложения по-разному реагируют на изменение параметров качества передачи. Например, приложения, обеспечивающие передачу голоса, требовательны ко всем трем параметрам; приложения, работающие с потоковым видео, требовательны к потерям пакетов и задержкам; транзакционные приложения чувствительны в основном к потерям пакетов и т.д.
Чтобы в мультисервисной сети передаваемый трафик не терял в качестве, обслуживать его нужно дифференцированно, и для разных видов трафика – голоса, интерактивного видео и критически важных данных – необходимо назначить разные приоритеты.
В качестве примера рассмотрим услугу РТКОММ «Вир туальная частная сеть MPLS IP VPN». На сети выделяются три вида трафика, каждому из которых может назначаться приоритет:
- real-time – трафик интерактивного голосового и видеообмена, чувствительный к задержкам и колебаниям задержки;
- business critical – трафик корпоративных информационных систем, чувствительный к потерям пакетов;
- best-effort – традиционный интернет6трафик и электронная почта.
Качество услуги по передаче трафика (интерфейс мультисервисной сети, принадлежащий VPN) может определяться следующими параметрами, которые влияют на работоспособность приложений и доступны для измерения оператором:
- состоянием порта, на котором предоставляется услуга;
- загрузкой доступной полосы для каждого вида трафика, заказанного на порте;
- параметрами качества передачи для каждого вида трафика, заказанного на порте.
Наиболее сложным в реализации и наименее проработанным остается вопрос измерения параметров качества передачи трафика.
Интегрируем сложность и точность
При измерении параметров качества трафика требуется найти оптимальное сочетание сложности измерений и точности получаемых показателей, характеризующих работу приложений заказчика.
Для проведения измерений предпочтительнее пользоваться тестовым (синтетическим) трафиком, поскольку он предсказуем и непрерывен, а судить о параметрах качества передачи трафика реальных приложений заказчика позволяет реализация технологии обеспечения QoS (Quality of Service) на MPLS-сетях. Так, на сети РТКОММ параметры качества измеряются с помощью решения Cisco IOS – Service Assurance Agent, которое позволяет выполнять периодические замеры различных параметров качества посылкой тестовых пакетов определенного вида на заданный IP-адрес, накапливатьстатистику по характеристикам прохождения тестовых пакетов и вычислять синтетические параметры на основе собранных данных.
На крупных MPLS-сетях наибольшее распространение получила модель обслуживания трафика с дифференциацией услуг – DiffServ (Differentiated Services). В DiffServ объединяются классификационные признаки трафика различных приложений, а информация о типе трафика передается в IP-пакетах посредством маркировки полей пакета. Пакеты классифицируются и маркируются так, чтобы они могли получить определенный режим обработки на каждом узле по всему пути следования. При этом сложные операции классификации, маркировки, определения правил обслуживания и формирования трафика необходимо выполнять только на границах сети. Сетевые ресурсы выделяются для потоков трафика на основе правил обслуживания, которые определяют, каким образом трафик маркируется и кондиционируется (приводится к определенному виду) при входе в сеть, поддерживающую DiffServ, а также то, как этот трафик обрабатывается внутри данной сети. Таким образом, трафик всех приложений (в том числе тестовый), отнесенный к определенному типу, поддерживаемому MPLS-сетью оператора, получает одинаковый режим обслуживания. То есть количество необходимых измерений определяется количеством направлений (точек, между которыми проводятся измерения) и не зависит от количества VPN на сети оператора.
Оценки соответствия измерений, проводимых с использованием тестового трафика, и реального состояния сети показывают, что корреляция полученных значений возможна при интенсивности тестового трафика в объеме 1–5% от реального.
Предоставление услуги IP VPN на крупной мультисервисной сети, как правило, предполагает подключение через сети городского уровня региональных провайдеров связи. Проведение измерений на нескольких участках (магистральная сеть и сеть доступа) позволит оператору разграничить зоны ответственности и уменьшить количество измерений на магистральном уровне. Однако такая схема измерений не всегда согласуется с интересами клиента, для которого важно качество передачи трафика между абонентскими устройствами.
После того как определены общие принципы измерения, необходимо выбрать инструмент, который будет осуществлять сбор данных, их обработку и хранение, а также представит полученные измерения в понятном, удобном для просмотра виде.
Остановка по требованию
По результатам проведенных исследований предлагаемых целым рядом вендоров продуктов попробуем сформулировать требования к системам SLA-мониторинга. Кроме стандартных качеств систем такого уровня – надежности, масштабируемости и разграничения прав доступа, есть специфичные требования, которые можно условно разделить на три группы: работа с источниками данных, обработка данных, визуализация данных.
В области работы с источниками данных наименее проработан вопрос управления агентами, генерирующими тестовый трафик. Эту задачу должна решить подсистема, отслеживающая корректность используемых агентов, а при изменении конфигурации сети осуществляющая их конфигурирование в соответствии с установленными правилами. Кроме сбора перечисленных параметров качества передачи трафика, необходимо получать данные о состоянии сервиса от других систем (Fault Management, Performance Management), обрабатывать их и представлять интегральные отчеты о качестве услуги заказчику. А возможность расширить спектр собираемых данных (например, анализ CDR для VoIP-приложений) позволит оператору перейти в дальнейшем к заключению соглашений, включающих гарантии работоспособности наложенных сервисов.
В области обработки данных можно выделить две важные задачи: возможность задавать несколько пороговых значений при вычислении параметров качества (чтобы проактивно реагировать на деградацию сервисов на сети до превышения критических значений); возможность вычисления интегральной характеристики сервиса между двумя устройствами заказчика по результатам измерений на нескольких сетевых участках (чтобы включать в соглашение сквозные характеристики качества, наиболее интересные заказчикам).
В области визуализации данных должно обеспечиваться отображение интегральной характеристики уровня сервиса и иерархическая навигация по уровням детализации для облегчения поиска и локализации деградации сервисов при наличии большого количества клиентов и/или подключений. Также необходима гибкая настройка отчетов с выводом детализированной информации о поставляемых услугах, что позволит использовать систему как клиентский портал, предоставляющий документированную информацию об уровне качества услуг в рамках заключенных соглашений.
***
Внедрение оператором системы, обеспечивающей мониторинг качества предоставления услуг, дает заказчикам возможность непрерывного ведения бизнеса с полным контролем над качеством передачи трафика и, соответственно, повышает их удовлетворенность и лояльность. Вопрос лишь в том, чтобы правильно выбрать соответствующую систему. Особое внимание следует обратить на возможности системы в отношении сбора данных о параметрах сервиса, включая данные от других систем, а также в отношении вычисления интегральных характеристик сервиса и отображения наиболее значимых параметров, что позволит ориентироваться в больших объемах данных и иметь актуальную информацию о качестве услуги в целом.
Установка отдельных промышленных OSS/BSS-решений рассматривается сегодня операторами, как правило, в рамках комплексной модернизации информационных систем. Однако неслучайно в таких программах очередь приоритетов возглавляют системы мониторинга состояния сети и параметров услуг – наиболее очевидный инструмент повышения эффективности операторского бизнеса. И если в мониторинге сети, как показывает операторский опыт, можно смело опереться на уже существующие решения вендоров, то в задаче SLA-мониторинга поставщик услуг видит нерешенные вопросы. Готовы ли вендоры принять вызов?
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3
