Часто причиной плохого качества обслуживания посетителей фронт-офиса являются сбои в работе бизнес-приложений, являющиеся, в свою очередь, следствием плохой работы сети (в частности, низким качеством услуг ISP, NSP). Чтобы в этом убедиться или, наоборот, «реабилитировать» сеть, нужно контролировать качество её работы и уметь аргументировано предъявить претензии провайдеру сетевых услуг.
Существует множество технологий решения этой задачи. В данной статье я расскажу о технологии Нагрузочного Мониторинга Сети. Эта технология (наряду с другими технологиями, в частности, Cisco IP SLA) поддерживается всеми продуктами ProLAN, и прозрачно интегрируется с решениями: Кнопка Помощи ITSM, Кнопка Лояльности, Пятый Уровень, Терминал Обратной Связи и другими. Данная технология может использоваться для мониторинга любых сетей. Однако наибольшую ценность она представляет для мониторинга сетей, в которых каналообразующее оборудование не поддерживает технологию IP SLA.
Нагрузочный Мониторинг Сети – это регулярное измерение эффективной пропускной способности сети (network throughput), выполняемое методом генерации в сеть TCP-трафика с заданными параметрами и измерении фактически переданного/принятого объёма данных.
Используйте Нагрузочный Мониторинг Сети для решения следующих задач:
Отличие Нагрузочного Мониторинга Сети от тестирования сети с помощью Iperf, pathrate, chariot и других подобных средств в том, что Нагрузочный Мониторинг позволяет не только измерять пропускную способность сети, но и является важным элементом системы управления качеством предоставления ИТ-Услуг (Service Level Management). С технической точки зрения это означает следующее:
В линейке решений ProLAN Нагрузочный Мониторинг Сети является связующим звеном между решениями Кнопка Помощи ITSM и Пятый Уровень, контролирующими удовлетворённость пользователей ИТ-Сервисов и производительность бизнес- приложений, и системами управления здоровьем ИТ-Инфраструктуры ProLAN: Администратор, ProLAN: Аналитик; ProLAN: Эксперт. Приобретая любой из этих продуктов, вы сможете проводить Нагрузочный Мониторинг Сети.
Для проведения Нагрузочного Мониторинга Сети используется Тест пропускной способности сети на уровне TCP, входящий в состав всех продуктов семейства ProLAN SLA-ON (Администратор, Аналитик, Эксперт), в том числе в состав бесплатного продукта QuTester Plus.
Тест пропускной способности сети на уровне TCP – это VB-скрипт, выполняемый на Зонде. Зонд – компьютер, работающий под управлением любой версии MS Windows, на котором выполняется служба MS Windows SLA-ON Probe. Работа Теста основана на генерации TCP-Трафика между Зондом и Ответчиками, и измерении объёма передаваемых и принимаемых данных. Ответчик – это служба Linux или Windows, которая может работать на серверах или встраиваться в активное оборудование.
SLA-ON Probe входит в состав любого продукта семейства ProLAN SLA-ON (Администратор, Аналитик, Эксперт), но может использоваться и в составе любой системы управления, поддерживающей SNMP, т.к. позволяет экспортировать результаты измерений (пропускную способность и другие метрики) по SNMP. Для этого SLA-ON Probe поддерживает private MIB ProLAN.
| № | Характеристика | Описание |
|---|---|---|
| 1 | READ (Mbps, %) | Пропускная способность сети при передаче данных от Ответчика к Зонду. Во всех случаях одновременно измеряется абсолютная и относительная (относительно установленного значения) пропускная способность. |
| 2 | WRITE (Mbps, %) | Пропускная способность сети при передаче данных от Зонда к Ответчику. |
| 3 | RD-WR (Mbps, %) | Пропускная способность сети при встречной передаче данных между Зондом и Ответчиком. |
| 4 | TOTAL (Mbps, %) | Общая пропускная способность сети при одновременной передаче данных между Зондом и несколькими Ответчиками. В зависимости от направления передачи данных может быть: TOTAL READ, TOTAL WRITE, TOTAL RD-WR. |
| 5 | AVERAGE (Mbps, %) | Средняя пропускная способность сети при поочерёдной передаче данных между Зондом и несколькими Ответчиками. В зависимости от направления передачи данных может быть: AVERAGE READ, AVERAGE WRITE, AVERAGE RD-WR. |
| 6 | Responder Availability (%) | Доступность Ответчиков по UDP. Проверка доступности Ответчиков может быть отключена. |
| 7 | TCP Link Availability (%) | Доступность TCP-канала. TCP-канал считается недоступным, когда при доступности Ответчика UDP с ним невозможно установить связь по TCP и во время передачи данных происходит разрыв связи между Ответчиком и Зондом. |
Поскольку тестовый трафик может оказывать негативное влияние на работу пользователей сети, в Тесте пропускной способности сети на уровне TCP предусмотрена возможность автоматического управления генерацией трафика в зависимости от активности внутренних пользователей. Поясним это на примере.
Предположим, тестируется канал связи, подключённый к 6-му порту маршрутизатора; см. Рисунок 2. При этом Зонд подключён к 1-му порту, а пользователи – к 3-му и 4-му портам. Предположим, Тест пропускной способности сети должен с 9-00 до 20-00 каждый час передавать 1 Мбайт данных от Ответчика к Зонду.
Если управление генерацией трафика включено, тест начнёт генерацию трафика только в том случае, если утилизация портов 3 и 4 будет меньше определённого значения, например, 5%. Если в то время, когда должна начаться генерация трафика, это условие не выполняется, то Тест не начнёт генерацию, а будет ждать определённое время. Если он так и не дождётся снижения утилизации до 5%, то генерация будет отложена следующего часа. Начав генерацию трафика, Тест продолжает контролировать утилизацию портов 3, 4, и если она окажется выше 5%, то прекратит генерацию, зафиксирует конфликт, и аннулирует результаты данного измерения. Условия, разрешающие/запрещающие генерацию трафика могут быть различными (не только утилизация портов). Режим управления генерацией трафика можно отключить.
Управление генерацией трафика позволяет, с одной стороны, автоматизировать измерение пропускной способности сети, с другой стороны, проводить замеры только в периоды низкой активности пользователей. Это обеспечивает высокую репрезентативность и достоверность получаемых результатов.
Здоровье сети характеризуется множеством метрик – утилизация, ошибки, джиттер, число потерянных пакетов и т.д. Значения этих метрик влияют на пропускную способность сети, поэтому выход любой из них за допустимый диапазон значений вызывает снижение пропускной способности сети. Таким образом, чтобы узнавать о проблемах до того, как они скажутся на работе пользователей, достаточно контролировать пропускную способность сети, что дешевле, проще и удобнее, чем контролировать множество «сырых» метрик.
Жалобы пользователей, фиксируемые Кнопкой Помощи ITSM, и производительность сети, измеряемая в рамках Нагрузочного Мониторинга Сети, всегда привязаны к единой временной шкале. Поэтому, чтобы реабилитировать сеть, достаточно убедиться, что в момент жалобы пользователя (нажатия им «красной кнопки») пропускная способность сети была нормальной.
