По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Существует несколько факторов, которые следует учитывать при реализации решения SD-WAN. Одним из них является мониторинг сети. В этом посте мы рассмотрим некоторые проблемы SD-WAN и то, как мониторинг сети может помочь их преодолеть.
Исправление пути и аварийное переключение
Одним из преимуществ SD-WAN является исправление пути и автоматическое аварийное переключение. Эта функция доступна, когда маршрутизатор имеет несколько соединений, таких как MPLS, широкополосное соединение или LTE. В этом сценарии трафик можно направлять по разным линиям, что повышает надежность и качество. Например, если канал испытывает большие задержки или потерю пакетов, маршрутизатор может отправлять трафик через другой канал. Некоторые решения SD-WAN даже дублируют пакеты по двум каналам, увеличивая вероятность того, что трафик достигнет другого конца.
Эти изменения трафика могут оказать немедленное положительное влияние, но могут отрицательно повлиять на сквозную производительность. Например, маршрутизатор может маршрутизировать трафик через канал с более низкой скоростью, замедляя соединение. В случае дублирования пакетов общая полоса пропускания, доступная пользователям, уменьшается. В результате приложения могут работать медленнее, чем до корректирующего действия, которое заставляет пользователей жаловаться. Устранение проблем такого рода очень сложно без правильной информации.
Сквозные сетевые тесты
Сквозные сетевые тесты (end-to-end) предоставляют полезные данные для устранения проблем, подобных той, что проиллюстрирована ранее. Для наиболее важных служб и приложений, используемых в удаленном филиале, инструмент сетевого мониторинга должен собирать следующие показатели:
Задержка и потеря пакетов на удаленном сервере приложений (пинг по протоколу ICMP или TCP)
Джиттер для голосовой и видеосвязи (UDP iperf)
Количество сетевых скачков и изменений пути (traceroute / tracepath)
Пропускная способность для других сайтов WAN и для Интернета (iperf, NDT и speedtest)
Решения SD-WAN могут сообщать о некоторых из этих метрик, но они либо пассивны, либо учитывают только ограниченную часть сети. Обычно это последняя миля, где работают устройства SD-WAN.
Инструмент мониторинга сети для SD-WAN учитывает весь сквозной процесс от уровня пользователя до пункта назначения на дальнем конце. Такое решение для мониторинга опирается на активные агенты сетевого мониторинга, которые устанавливаются на периферии как в виде физического, так и виртуального устройства. Сквозные сетевые тесты выполняются непрерывно, а результаты извлекаются в режиме реального времени и сохраняются для исторического просмотра.
Мониторинг взаимодействия с конечным пользователем
Мониторинг взаимодействия с конечным пользователем является еще одним ключевым элементом решения для мониторинга SD-WAN. Существует множество способов получения опыта конечного пользователя и множество инструментов на рынке, нацеленных на это. Как правило, мониторинг взаимодействия с конечным пользователем включает в себя статистику и показатели уровня приложения, такие как:
Время разрешения DNS
Время загрузки HTTP
Средняя оценка мнения (MOS) для VoIP
Показатели производительности WiFi
Когда данные о производительности, генерируемые активным агентом мониторинга, соединяются с пассивными данными, полученными устройством SD-WAN, это дает четкое представление о производительности сети. Активные данные полезны для сбора упреждающих предупреждений и устранения неполадок при проблемах производительности в режиме реального времени. Пассивные данные используются, чтобы дать четкое представление о том, как полоса пропускания используется пользователями («ведущими участниками») и приложениями («наиболее эффективными приложениями»), и при необходимости обновлять конфигурацию сети. Сочетание этих двух технологий приводит к уменьшению времени разрешения проблем сети и приложений, повышению производительности и удовлетворенности пользователей.
Если ты используешь модуль EndPoint Manager, о котором мы рассказывали в нашей предыдущей статье, или же другое решение auto-provisioning для автоматической настройки телефонных аппаратов на FreePBX, то эта статья для тебя!
В ней мы покажем универсальный способ для поиска и устранения проблем, которые могут возникнуть в процессе работы с решениями auto-provisioning, таких как EPM.
Как ты уже знаешь, принцип auto-provisioning заключается в том, что телефонный аппарат обращается на сервер, на котором для него уже подготовлен конфигурационный файл. Затем он скачивает его, применяет настройки и становится готовым к работе.
Сервер может работать по протоколам TFTP, FTP, HTTP и др. в зависимости от выбранного режима и протоколов, которые поддерживает аппарат.
Давайте рассмотрим типовую проблему, с которой мы можем столкнуться, при автоматической настройке телефонных аппаратов с помощью auto-provisioning на примере модуля EPM
Кейс
Допустим, мы сделали глобальные настройки для сервера TFTP и создали типовой шаблон для телефона Yealink SIP-T28P. Теперь мы пробуем назначить этот шаблон конкретному телефонному аппарату. Для этого, либо через модуль Extension, либо через Extension Mapping в самом EPM мы привязываем созданный шаблон к телефону по его MAC-адресу. Затем перезагружаем телефон и обнаруживаем что … он не получает настройки.
Для начала, проверим логи TFTP сервера и выясним, посылает ли телефонный аппарат какие-либо запросы. Для этого откроем CLI нашего сервера и дадим такую команду:
tail -f var/log/asterisk/messages | grep tftp
После того, как мы введём эту команду, мы будем в реальном времени получать записи из лога messages, относящиеся к сервису tftp.
Скорее всего, мы увидим там что-то типа:
Где:
192.168.2.57 - IP адрес телефонного аппарата;
1111ссссdddd.cfg - Конфигурационный файл, который телефонный аппарат запрашивает с сервера. 1111ссссdddd - MAC адрес телефонного аппарата;
Сообщение RRQ from 192.168.2.57 filename 1111ccccdddd.cfg означает, что телефон запрашивает с tftp сервера свой конфигурационный файл, а сообщение sending NAK (1, File not found) to 192.168.2.57 означает ответ сервера о том, что файл с таким именем не найден.
Давайте теперь проверим директорию tftpboot, где EPM хранит конфигурационный файлы для телефонов и проверим, есть ли там файл с именем 1111ccccdddd.cfg. Для этого в CLI даём такие команды:
cd /tftpboot
ls -la | grep 1111ccccdddd
Скорее всего, мы получим пустой вывод, а значит такого файла нет. В этом случае нужно ещё раз проверить, что телефон корректно привязан по MAC адресу к нужному шаблону через модуль Extension или Extension Mapping.
После чего, ещё раз проверьте директорию tftpboot на предмет конфигурационного файла своего телефонного аппарата по MAC адресу:
В данной статье мы посмотрим, что такое статические и динамические библиотеки. Местоположение библиотек по умолчанию. Определение используемых библиотек. Загрузка библиотек.
Библиотеки это набор функций, которые могут использоваться в различных программах. Библиотеки могут быть статические (библиотека привязывается к определенной программе или софт содержит данную библиотеку в своем теле.) и динамическими (библиотеки грузятся в оперативную память и используются). Плюсы первого варианта нет проблемы совместимости, т. к. софт уже в себе содержит библиотеку, библиотека всегда с собой. Но при этом программы становятся большие по размеры и т.к каждая может загружать свои библиотеки, а иногда и одинаковые. Второй вариант значительно лучше, сами программы по своему размеру меньше. Библиотека загружается один раз в оперативку. И следующая программа, которой необходимы такие же функции, берет и использует эти данные.
По умолчанию библиотеки в Linux находятся в двух папках. Это корневая папка /lib в ней находятся библиотеки, которые используют программы, расположенные в корневой папке /bin.
И есть вторая папка /usr/lib. В ней находятся библиотеки, которые используют программы расположенные /usr/bin. Пути к библиотекам указаны файле /etc/ld.so.conf. Данный файл можно просмотреть стандартным способом, через утилиту cat.
Видим, что написано включить все библиотеки, которые расположены по пути, указанном в файле. Те которые оканчиваются на .conf. Он просто включает в себя все настройки, которые находятся в конфигурационных файлах, в данной директории. Переходим в данную директорию.
В данной директории мы можем видеть 2 файла конфигурации, в зависимости от версии и наполнения операционной системы их может быть и больше. Ну и соответственно в конфигурационных файлах находятся пути к директориям, где лежат необходимые для работы библиотеки. Если мы ставим какое, то свое программное обеспечение, которому необходимы дополнительные библиотеки, не идущие в составе дистрибутива linux, то в данной директории может создаться свой конфигурационный файл. Например: если мы используем систему виртуализации VMware, то к каждой VM устанавливаем VMware tools то данное программное обеспечение создаст свой конфигурационный файл с путями для своих библиотек.
Переходим в директорию cd /etc/ и отсортируем так, чтобы в результатах все, что содержит ld.
ls | grep ld.
Получим следующее:
Видим 3 основных конфигурационных файла. ld.so.conf - это файл конфигурации в котором написано откуда брать дополнительные библиотеки. Директория ls.so.conf.d в которой находятся дополнительные конфигурационные файлы и ld.so.cache это кэш библиотек. Он у нас выстраивается каждый раз для того, чтобы программы при необходимости при запросе библиотек не копались в файлах, а сразу брали из загруженного в оперативную память кэша. Т.е. если мы вносим какие-то изменения в файл конфигурации, добавляем какие-то конфигурационные файлы нам необходимо обновить этот кэш. Кэш обновляется командой ldconfig. Этого, собственно, достаточно, чтобы прогрузить все библиотеки в кэш.
Давайте посмотрим, как, определить какими библиотеками пользуется какая программа.
Для этого мы будем использовать команду ldd и путь к бинарному файлу. Например: Программа ls которая используется для вывода списка файлов в каталоге. Она находится в каталоге /bin/ls.
В результате получим мы следующее:
Мы видим, какие so использует данная программа и соответственно ссылки на них, где они расположены, собственно, so - это наши библиотеки в данном случае.
Возможно добавление библиотек вручную, это может потребоваться если мы ставим совершенно стороннее программное обеспечение, которое очень трудно взаимодействует с Linux или устаревшее. Т.е. которое само не может создать конфигурационный файл и разнести библиотеки в системные директории Linux. Если мы хотим сделать это вручную, тогда нам необходим тот самый файл /etc/ld.so.conf. В данный файл мы можем дописать путь к файлу конфигурации библиотек тех, которые нам нужны. Либо есть более легкий вариант с использованием переменной export LD_LIBRARY_PATH и указать путь к тем особенным библиотекам, которые будет использовать наша "особенная" программа. Обычно все стороннее программное обеспечение устанавливается в папку /opt. Итоговый вариант будет выглядеть как: export LD_LIBRARY_PATH=/opt/soft/lib и когда пройдет экспорт, у нас попробует погрузится из этого пути библиотека, но перед этим необходимо не забыть сделать ldconfig.