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

Зачастую, действия администраторов для улучшения работы основываются на интуиции, в виду недостаточного опыта в данной сфере. Как правило, первым виновником проблем считают оборудование, которое морально «устарело» и отработало свой «эксплуатационный период» при максимальной нагрузке в 10-30%. Исходя из этого ложного мнения, не имея минимального мониторинга показаний этого оборудования, осуществляют приобретение нового дорогостоящего продукта не задумываясь, что причина может быть совсем в другом. Потраченные средства не оправдывают ожиданий, а проблема остается не решенной.

На самом деле, минимальный мониторинг может очень сильно облегчить жизнь и сэкономить бюджет, для этого необходимо потратить лишь немного своего времени.

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

• пропускная способность (скорость) канала для одного разговора 100 кбит/с;
• максимальная задержка (ping) при передаче пакетов должна составлять не более 100-150 миллисекунд;
• джиттер, или отклонение от среднего уровня задержки — не более 20 миллисекунд;
• не более 5% потери пакетов.

Загруженность каналов связи являются важнейшими аспектами при формировании сети. Загрузка сети зависит от предложенной нагрузки и пропускной способности сети.

Предложенная нагрузка – это поток данных, поступающий от пользователей, используемых ими приложений, на вход сети.

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

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

К примеру, рассмотрим предприятие с численностью штата более 50 человек, постоянно использующих доступ в интернет. Сотрудники жалуются на плохую работу внешней, внутризоновой и междугородней связи. Для решения проблемы администратор начинает заниматься мониторингом и исследованием телефонной станции тратя время в пустую. А причина сбоев очевидна и заключается в том, что пропускная способность канала составляет всего 10 мб/с (экономия бюджета) на 50 человек и при этом большая часть работников смотрит онлайн фильмы и расходует трафик для иных личных целей. Казалось бы, догадайся администратор создать Voice Vlan на оборудовании для приоритетности трафика и проблема была бы решена.

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

Первая идея, которая пришла мне в голову — это замена оборудования, так как оно отработало более 5 лет и не обслуживалось. При установке мониторинга сетевого оборудования и снятия показаний Ping, CPU, температуре и ОЗУ, анализ показывал, что оборудование при сроке эксплуатации в 5 лет работает стабильно, нагрузка на процессор более 30-40% не поднимается, пакеты не вылетают, задержки большие отсутствуют. Проблема все еще не устранена. 

Казалось бы, построена карта сети, выстроена топология оборудования, установлен мониторинг, но результата нет.

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

Подводя итог вступительной части, я бы хотел поделиться с Вами своим примером использования доступного всем инструмента Iperf – для поиска узких мест в топологии сети, определения ширины канала; построения и визуализации сети с помощью Algorius Net Viewer.

Рассмотрим карту сети (Рис.1), на которой отображены и поставлены на мониторинг:

1. Станция 1 – ПЭВМ с виртуальной машиной:

• Station_Algorius – предустановленная система мониторинга;
• виртуальных машин с Centos 7 и Asterisk 18.10.0.

2. Станция 2 – ПЭВМ с виртуальной машиной:

• WorkStation – рабочая станция;
• виртуальных машин с Centos 7 и Asterisk 18.10.0.

3. Router_Tplink – домашний Wi-Fi роутер.

4. Iperf_lon.speedtest.clouvider.net – публичный Iperf сервер.

Iperf3 — это программа, которая генерирует TCP и UDP трафик для тестирования пропускной способности сети. Позволяет измерить максимальную пропускную способность сети между сервером и клиентом, провести нагрузочное тестирование канала связи и улучшить производительность сети. Программа состоит из клиентской и серверной части.

В данном примере будет рассмотрен вариант запуска Iperf, в качестве сервера со стороны Asterisk, со стороны системы мониторинга, в качестве клиента. Такой подход обеспечивает возможность получения показаний отправителя (sender) и получателя (receiver) со стороны мониторинга, так как на серверной части присутствует только один показатель.

Начнем с настройки виртуальных машин с Centos 7 и Asterisk 18.10.0, для этого необходимо осуществить следующие действия в строке Centos:

1. Выполним установку расширенного репозитория:
   yum install epel-release
2. Устанавливаем Iperf3:
   yum install iperf3
3. Запускаем Iperf3, как сервер ключом -s:
   Iperf3 –s

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

1. Запуск сервера автоматически при старте системы, работа программы осуществляется, как служба systemd:

— создадим юнит и внесем в него следующие данные: 

nano /etc/systemd/system/iperfd5204.service

Описание содержимого:

• Description — описание юнита;
• After — указывается юнит, после которого может запускаться сервис;
• Type — тип службы; 
• PIDFile — путь к pid файлу, в котором хранится номер процесса;
• ExecStart – команда выполнения при старте сервиса, где указывается запуск iPerf3, -s — в режиме сервера, -р – порт 5204, D – запустить, как службу, -I — указать pid-файл;
• ExecReload — команда для перезапуска службы;
• Restart=always — опция, позволяющая автоматически перезапускать сервис, если он перестанет работать;
• WantedBy=multi-user.target — устанавливает для автозапуска службу в обычном многопользовательском режиме.
• создадим второй юнит и внесем в него измененные данные: nano /etc/systemd/system/iperfd5205.service

Выполнение этого действия необходимо только в том случае, если планируется осуществлять тестирование с нескольких устройств, например, у нас есть несколько разнесенных серверов для тестирования, расположенных в разных точках.  Это позволит нам запустить Iperf3 за раз с нескольких портов: 5204 и 5205. Такой подход позволяет исключить ошибки при проведении запроса теста. Надо не забывать, что со стороны клиента в запросе требуется указывать порт для обращения к серверу:

-c 192.168.0.98 –р 5204

-c 192.168.0.98 –р 5205

• Перезапускаем systemd:

systemctl daemon-reload

• Разрешаем созданные сервисы и ставим их в автозагрузку:

systemctl enable iperfd5204.service

systemctl enable iperfd5205.service

• Запускаем их:

systemctl start iperfd5204.service

systemctl start iperfd5205.service

• Проверяем их статус:

systemctl start iperfd5204.service

systemctl start iperfd5205.service

2. Запуск публичного сервера с множеством портов, такой подход указан на официальном сайте Iperf:

• Создадим пользователя:

adduser iperf -c iperf

• Создадим юнит и внесем в него следующие данные: 

nano /etc/systemd/system/[email protected]

• Перезапускаем systemd:

systemctl daemon—reload

• Активируем Iperf3 при запуске сервера с портами 9200 по 9210:

for p in $(seq 9200 9210); do sudo systemctl enable iperf3-server@$p ; done

• Перезагружаем сервер:

Reload

• Проверяем статус запущенных служб:

systemctl status iperf3-server@*

• Проверяем журнал анализа логов с указанных юнитов:

journalctl -u iperf3-server@*

На этом настройка сервера заканчивается и как запускать Iperf выбирать Вам.

Перейдем к следующему этапу, нам необходимо осуществить запуск теста с ключом клиента. Для этого на ПЭВМ, где у меня установлен Algorius Net Viewer, я создал папку на рабочем столе куда поместил скаченный с официального сайта разработчика Iperf3 (https://iperf.fr/download/windows/iperf-3.1.3-win64.zip).

В Algorius Net Viewer нет встроенного Iperf и тут возникает вопрос, а как нам запустить тест и вывести полученные показания на карту сети. Для этого мы воспользуемся встроенным плагином ‘External’, который позволяет опрашивать устройства, используя внешние утилиты.

В указанном сенсоре нас интересует 3 настройки:

1. Файл – путь до приложения, которое необходимо запустить.
2. Аргумент – это наша команда с ключами запроса:
   с – запуск клиента;
   адрес до сервера;
   -р – опрашиваемый порт;
   -t – время опроса;
   -f – формат отчета;
   g – выводить в Gbit/sec.
3. RegEx – регулярное выражение описывающее необходимый нам показатель до получателя: (\d+|\d+\.\d+\s+Gbits\/sec)\s+receiver .

Для каждого устройства необходимо создавать свой сенсор, по аналогии я создал еще 2 сенсора для опроса второго Asterisk и публичного сервера lon.speedtest.clouvider.net, изменив в шаблоне имя и адрес.

Для получения показаний о статусе Asterisk, загрузки CPU и памяти сервера, я решил использовать вывод запроса команд в строке Linux по SSH:

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

2. В настройках мониторинга воспользуемся плагином SSH.

В указанном плагине нас интересует 2 настройки:

1. Команды:
   • для показаний статусу Asterisk:
   systemctl status asterisk | grep Active: | awk ‘{print $2}’
   • для показаний загрузки CPU:
   asterisk -rx «core show sysinfo» | grep Total.RAM | awk ‘{print $3}’
   • для показаний памяти сервера:
   asterisk -rx «core show sysinfo» | grep Total.RAM | awk ‘{print $3}’
   Все эти команды используют стандартный поиск и вывод требуемых значений.
2. RegEx – регулярное выражение описывающее необходимое нам получаемое значение: .* .

На этом настройка завершена.

На следующем этапе необходимо установить в настройках устройств созданные сенсоры мониторинга. Указать период опроса. Для SSH указать созданный логин и пароль. Сенсоры не привязаны к конкретному устройству и их размещение зависит только от Вашего удобства для понимания.

Теперь рассмотрим финальный результат, который получился.

На карте сети (Рис.16) отображены и поставлены на мониторинг:

1. Станция 1:

• Station_Algorius:
  Показатели мониторинга:
  Ping — показатель целостности соединения;
  Iperf_Speed_Ast_1 – показатель теста Iperf до Asterisk’а 1;
  Iperf_Speed_Ast_2 – показатель теста Iperf до Asterisk’а 2;
  Iperf_Speed_Public – показатель теста Iperf до публичного сервера в интернете.
• Virtual_Asterisk_PBX_1:
  Показатели мониторинга:
  SSH_status – показатель состояния Asterisk;
  Ping — показатель целостности соединения;
  SSH_CPU — показатель состояния СPU;
  SSH — показатель состояния памяти;
  Ping — показатель целостности соединения.

2. Станция 2:

• WorkStation:
  Показатели мониторинга:
  Ping – показатель целостности соединения.
• Virtual_Asterisk_PBX_2:
  Показатели мониторинга:
  SSH_status – показатель состояния Asterisk;
  Ping – показатель целостности соединения;
  SSH_CPU – показатель состояния СPU;
  SSH – показатель состояния памяти;
  Ping – показатель целостности соединения.

3. Router_Tplink:

Показатели мониторинга:
Ping — показатель целостности соединения.

4. Iperf_lon.speedtest.clouvider.net:

Показатели мониторинга:
Ping — показатель целостности соединения.

На рис. 16 мы видим показатели теста Iperf от Virtual_Asterisk_PBX_1, Virtual_Asterisk_PBX_2 и Iperf_lon.speedtest.clouvider.net до Station_Algorius разные. Это связано с тем, что соединение с системой мониторинга осуществляется по различным каналам связи, пропускная способность, которых отличается. Это может быть связано с типом подключения, с максимальной пропускной способностью канала связи, с нагрузкой на сам канал связи.

Рис. 17 — Virtual_Asterisk_PBX_1 со Station_Algorius, расположены на одном ПЭВМ, и они связаны мостом. Их скорость максимальная при таком типе подключения.

Рис. 18 — Virtual_Asterisk_PBX_2 со Station_Algorius связаны Router_Tplink с портом в 100 Мб/с. Стоит отметь, что Station_Algorius подключена к Router_Tplink по WiFi, на указанном участке сети это является узким местом, так как такой тип подключения не позволяет использовать проводной канал в 100 Мб/с от Virtual_Asterisk_PBX_2 до Router_Tplink на 100%.

Рис. 19 — Iperf_lon.speedtest.clouvider.net со Station_Algorius связаны с Router_Tplink через подключение к Интернету, пропускная способностью порта WAN 100Мб/с. Но результат теста показывает, что ширина канала значительно ниже и временами падает до 0. Мы можем сделать вывод, что на участке сети от Station_Algorius до публичного сервера присутствуют узкие места. В данном примере — это может быть связано с ограничением в пропускной способности канала связи, с нагрузкой на канал связи до публичного сервера. На таком участке сети могу возникать проблемы с предоставлением услуг телефонной связи, где пропускная способность является низкой и нестабильной.

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

Спасибо за внимание.