Аудит пропускной способности распределённой сети

Вы – ИТ-менеджер крупной компании, отвечающий за работу распределённой корпоративной сети. В центре сети (например, в центральном офисе) расположен ЦОД, доступ к которому из удалённых офисов осуществляется по арендуемым каналам связи. Для управления такой сетью необходимо решить, как минимум, три задачи:
- Организовать постоянный контроль доступности каналов связи (availability). Если какой-то канал упадёт, вы сможете узнать об этом до того, как пользователи обратятся в Service Desk. Кроме того, неплохо знать, соблюдают ли NSP (Network Service Providers, Провайдеры Сетевых Услуг) свои обязательства по доступности каналов связи.
Эта задача сравнительно несложная. Для её решения можно использовать любую систему мониторинга, которая из центра по ICMP будет пинговать оборудование удалённых офисов.
Примечание. Обычно в SLA с провайдерами сетевых услуг (NSP, Network Service Provider) сформулированы требования только к доступности и физической скорости арендуемых каналов. Физическая скорость постоянна. Поэтому единственное, что можно проверять, это доступность каналов.
- Организовать постоянный контроль качества передачи данных по каналам связи (jitter, delay, packet loss). Контроль необходим для быстрой диагностики корневых причин инцидентов (жалоб пользователей), в частности, для определения, виновата ли в них сеть.
Это несколько более сложная задача, и её можно решать разными способами:
- Если каналообразующее оборудование поддерживает технологию IP SLA (например, оборудование Cisco Systems), лучшим способом является внедрение системы мониторинга, поддерживающей данную технологию; см. Паспорт качества IP-канала.
- Если используется оборудование, не поддерживающее IP SLA , то есть несколько путей: установить в сети специальные аппаратные зонды (самый правильный, но и самый дорогой вариант); ограничиться мониторингом качества работы каналообразующего оборудования, например, утилизации портов, числа ошибок и т.п. (на безрыбье и рак рыба); внедрить Нагрузочный Мониторинг Сети, см. Виновата сеть? Нагрузочный Мониторинг Сети.
- Периодически проводить аудит пропускной способности каналов связи на уровне TCP. Такой аудит необходим для контроля качества услуг NSP. Вас интересует пропускная способность на уровне TCP, т.к. большинство критически важных бизнес-приложений работает именно по TCP. При этом вам требуется достоверная информация, полученная на основе большого числа измерений (представительной выборки). Это позволит при разговоре с NSP аргументировано обосновывать свои претензии.
В статье мы рассмотрим, как эта задача решается методом Нагрузочного Мониторинга Сети, поддерживаемого (в разной степени) всеми продуктами семейства ProLAN SLA-ON (Администратор, Аналитик, Эксперт), в том числе бесплатным продуктом QuTester Plus.
Примечание. Решение не сертифицировано, поэтому полученные с его помощью результаты при разрешении юридических споров правовой силы не имеют.
Почему не Iperf или Chariot?
Для измерения пропускной способности сети часто используют утилиты типа Iperf, Chariot и т.п. Они идеально подходят для разовых измерений пропускной способности сети, например, на этапе её пуско-наладки (или приёмки-сдачи), но неприменимы для проведения аудита. Это объясняется, как минимум, тремя причинами:
- При проведении аудита наиболее интересна пропускная способность сети в рабочее время. Именно в это время опорная сеть провайдера наиболее загружена, и её пропускная способность может снижаться. Но именно в это время сеть наиболее активно используется внутренними пользователями. Поэтому, если вы будете измерять пропускную способность сети с помощью Iperf или Chariot в рабочее время, то, во-первых, результаты измерений будут очень не точны, во-вторых, это негативно отразится на работе пользователей.
- Для получения репрезентативной выборки каждый канал нужно измерить не менее 50 раз. Чем больше измерений, тем достовернее результат. Выполнять измерения вручную – очень трудоёмкая задача. Можно написать скрипт, который будет запускать тестирование автоматически. Но это не такая простая задача. Скрипт должен уметь анализировать готовность сервера, перезапускаться при сбоях и многое другое.
- Кроме того, если выяснится, что пропускная способность арендуемых каналов хуже ожиданий, и вы захотите предъявить аргументированные претензии NSP, вам потребуется привязать результаты всех измерений ко времени. Только в этом случае NSP сможет сопоставить результаты ваших измерений с данными своей системы мониторинга, только так он сможет определить, «кто виноват», и попытаться устранить узкое место. При использовании Iperf и Chariot привязку ко времени нужно делать вручную. Это сложно, трудоёмко и велика вероятность ошибки.
Примечание. Юридических претензий к NSP вы предъявить, скорее всего, не сможете, т.к. для этого необходимо, во-первых, чтобы измеритель был сертифицирован, во-вторых, чтобы в SLA были прописаны гарантии на пропускную способность каналов на уровне TCP, что очень маловероятно.
Поэтому для проведения аудита пропускной способности сети нужны другие решения. Примером такого решения является Нагрузочный Мониторинг Сети компании ProLAN. Это измерение эффективной пропускной способности сети (network throughput), выполняемое методом Управляемой Генерации TCP-трафика с заданными параметрами.
Как это работает

Рисунок 1. Архитектура решения для Нагрузочного Мониторинга Сети
В ЦОДе устанавливается система мониторинга, включающая Зонд (их может быть несколько) и консоль управления. В удалённых офисах устанавливаются ответчики под Windows или Linux. Для проведения Нагрузочного Мониторинга Сети используется Тест пропускной способности сети на уровне TCP, входящий в состав всех продуктов семейства ProLAN SLA-ON (Администратор, Аналитик, Эксперт), в том числе в состав бесплатного продукта QuTester Plus.
Тест пропускной способности сети на уровне TCP – это VB-скрипт, выполняемый на Зонде. Зонд – компьютер под управлением любой версии Windows, на котором выполняется служба SLA-ON Probe. Работа Теста основана на генерации UDP и TCP-Трафика между Зондом и Ответчиками. UDP используется только для мониторинга доступности Ответчиков: Зонд с заданной периодичностью пингует Ответчики по UDP. Для нагрузки каналов и измерения их пропускной способности используется TCP. Ответчик – это служба Linux или Windows, которая может работать на серверах или встраиваться в активное