Наши публикации
27.02.2007

Дежурный по услугам Мониторинг SLA

Доступность услуги и деградация сервиса

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

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

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

Конвергируем и... дифференцируем

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

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

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

В качестве примера рассмотрим услугу РТКОММ «Виртуальная частная сеть MPLS IP VPN». На сети выделяется три типа трафика, каждый со своим приоритетом:

  • real-time -- трафик интерактивного голосового и видеообмена, критичный к задержкам и колебаниям задержки;
  • business critical -- трафик корпоративных информационных систем, критичный к потерям пакетов;
  • best-effort -- традиционный интернет-трафик и электронная почта.

В зависимости от своих потребностей заказчик может получить на граничном маршрутизаторе РТКОММ клиентские порты с различными типовыми профилями, отличающимися соотношением трафика разных типов (см. таблицу):

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

  • состояние порта, на котором предоставляется услуга;
  • загрузка доступной полосы для каждого типа трафика, заказанного на порте;
  • измерение параметров качества передачи для каждого типа трафика, заказанного на порте.

Мониторинг состояния порта уже достаточно длительное время успешно осуществляется системами класса Fault Management. Не менее успешно системами класса Performance Management решаются задачи измерения параметров загрузки доступной полосы, в том числе и с разделением по типам трафика.

Наиболее сложным в реализации и наименее проработанным остается вопрос измерения параметров качества передачи трафика.

Интегрируем сложность и точность

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

Для проведения измерений предпочтительнее пользоваться тестовым (синтетическим) трафиком -- в силу его предсказуемости и непрерывности, а реализация технологии обеспечения 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-приложений) позволит оператору перейти в дальнейшем к заключению соглашений, включающих гарантии работоспособности наложенных сервисов.

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

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

* * *

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

Возврат к списку