По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Существует множество различных решений для управления Asterisk, основой которых, является FreePBX. К ним относятся - Elastix, PBX in a Flash (PIAF), Trixbox, AsteriskNOW и FreePBX Distro. Однако, с момента первого релиза FreePBX многое изменилось и большинство перечисленных проектов по-просту перестали существовать. Trixbox перестал поддерживать открытое ПО и переориентировался на коммерческую редакцию Trixbox Pro. Elastix и PIAF вообще дружно сменили свой движок с Asterisk на 3CX и для этих продуктов обновлений также больше нет. Кроме того, есть компании, которые до сих пор используют старые не поддерживаемые версии FreePBX и ежедневно испытывают трудности с их работой, а также те, кто установил FreePBX вручную на не поддерживаемые операционные системы.
Единственный продукт, который до сих пор обновляется и поддерживается разработчиком - это сам проект FreePBX и FreePBX Distro. Принимая это во внимание, разработчики FreePBX создали решение, которое позволяет сделать миграцию любой системы на базе FreePBX, (начиная с версии 2.9 до и включая версию 14) на свеженькую FreePBX Distro на базе ОС SNG 7, со всеми настройками и конфигурацией!
Итак, можно мигрировать с:
Elastix;
PBX in A Flash;
AsteriskNOW;
вручную установленного FreePBX (в том числе установленного на не поддерживаемой ОС);
FreePBX Distro
При этом система, с которой производится миграция не требует остановки эксплуатации или перезагрузки, так как инструмент всего лишь считывает конфигурацию с системы "донора" на свежую систему FreePBX Distro.
Как это работает:
Вам нужно будет установить свежую версию свежую версию FreePBX Distro , на которую будет происходить миграция и активировать её;
Запустить на новом сервере с FreePBX Distro скрипт конвертации командой: curl -s https://convert.freepbx.org | bash
Этой командой сервер запросит место (слот) в очереди на конвертацию. Когда слот будет успешно занят сгенерируется ключ, вида 2beb181b-14ed-4f56-a86b-f6e564ba6c43;
После этого, нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Конвертер извлечёт необходимые данные с донора и загрузит их на новый сервер. Этот процесс не окажет никого влияния на донора, не внесёт на нем никаких изменений и не потребует выключения;
Скрипт также будет пробовать стянуть с донора всякие кастомные данные, такие как пользовательские голосовые файлы и данные провиженинга;
Все транки на новом сервере будут выключены, чтобы избежать конфликта с зарегистрированными линиями к провайдеру на старом сервере.
О том, как установить FreePBX читайте в нашей статье
Какие данные будут перенесены на новый сервер:
Внутренние номера (Extensions);
Маршруты (Inbound/Outbound Routes);
Линии к провайдеру (Trunks);
Музыка на ожидании (MoH);
Голосовые меню (IVR);
Группы вызова (Ring Groups);
Очереди (Queues);
Любые другие настройки, являющиеся стандартной частью FreePBX;
Звуковые файлы, включая: загруженную пользователем музыку на ожидании (MoH), записи голосовой почты и приветствия для голосовой почты, а также системные записи (System Recordings)
Какие данные не будут перенесены на новый сервер:
История звонков, то есть Call Data Report (CDR) и таблица Call Event Log (CEL);
Вы можете самостоятельно перенести эти данные на новый сервер, экспортируя их с помощью 'mysqldump' или аналогичной утилиты. Эти данные могут быть очень тяжёлыми, поэтому пользователь сам должен позаботиться об их переносе.
Настройки факса;
Эта часть претерпела огромные изменения с момента первого релиза FreePBX, поэтому придется самостоятельно перенастроить почты пользователей, которым нужен функционал факса.
Кастомные изменения конфигурационных файлов;
То есть всё, что было изменено в файлах вида *_custom.conf, например /etc/asterisk/extensions_custom.conf. Если у вас есть такие настройки, то переносить их на новый сервер нужно будет вручную.
Настройки не FreePBXовых модулей;
Ну например Elastix Call Center Module, Queue Metrics и остальные модули, которые не являются стандартными для FreePBX.
В общем и целом, звучит неплохо, правда? Мы можем безболезненно перенести большинство необходимых данных с неподдерживаемой системы и продолжить работу на новой, получая все актуальные обновления. Процесс миграции не представляется чем-то сверх сложным, так что давайте попробуем?
Процесс миграции
Итак, первое с чего нужно начать - это подготовка нового сервера с FreePBX Distro. Важно устанавливать именно 64-битную версию, поскольку 32-битная больше не поддерживается.
О том как установить FreePBX Distro подробно читайте в нашей статье.
Как только FreePBX Distro будет установлен, его необходимо активировать. Активация требуется для того чтобы сгенерировать криптографический ключ для защиты ваших данных для передачи на сервер конвертации https://convert.freepbx.org.
Данные передаются в зашифрованном виде, чтобы исключить возможность их утечки в случае атаки типа Man-in-the-Middle.
Затем необходимо настроить NAT. FreePBX Distro имеет свой встроенный модуль Firewall, который автоматически настраивает параметры NAT и Firewall через специальный помощник при первом запуске FreePBX.
О том как настраивать Firewall читайте в нашей статье.
После того как сервер с чистым FreePBX Distro настроен, необходимо зарезервировать слот для конвертации.
Это делается с помощью специального скрипта: curl -s https://convert.freepbx.org | bash. Когда Вам предложат ввести reservation ID, просто нажмите 'Enter'.
По окончанию процесса резервации слота, будет сгенерирован уникальный код конвертации вида: 2beb181b-14ed-4f56-a86b-f6e564ba6c43. Его потом нужно будет ввести на доноре.
После этого, новый сервер будет ожидать ответа от донора. Не останавливайте скрипт, нужно чтобы на экране была надпись Waiting for Donor….
Теперь нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Возвращаемся на сервер-донор (Elastix, PIAF и так) с которого мы хотим мигрировать и запускаем тот же самый скрипт: curl -s https://convert.freepbx.org | bash
Когда вас попросят ввести ID, введите то что было сгенерировано при запуске скрипта на новом FreePBX Distro.
Это запускает процедуру экспорта всех данных и настроек с сервера донора и создание сжатого, криптографически защищённого архива с этими данными для отправки на новый сервер.
В зависимости от того, насколько давно был развёрнут старый сервер, существует возможность неудачной обработки команды скрипта, поскольку сервер может не поддерживать обработку TLS сертификатов. Если после запуска скрипта ничего не происходит, попробуйте запустить команду с отключением верификации TLS сертификата: curl --insecure https://convert.freepbx.org | bash
Как только процесс завершится, новый сервер будет иметь все настройки и данные, которые были на сервере доноре. Вы получаете полностью рабочий сервер со свежей версией FreePBX Distro, которая будет получать актуальные обновления софта и безопасности со всеми настройками, которые были на старом сервере!
Мы хотели бы поговорить про Quality of Service (QoS) в VoIP сетях, рассказать что это такое, как это работает, зачем это нужно и как это настраивать. В этой статье мы рассмотрим, какие проблемы мы можем иметь в сети, и как QoS может с ними помочь.
Для успешного функционирования VoIP сетей голосовой трафик (voice traffic) должен иметь приоритет над трафиком с данными (data traffic). Quality of Service можно определить как способность сети предоставить лучший или особый сервис для группы пользователей и приложений за счет других пользователей и приложений.
Звучит как то, что как раз необходимо для голосового трафика – “лучший” сервис необходим для VoIP не из-за больших требований по пропускной способности (VoIP трафик использует маленькую полосу пропускания, по сравнению с другими приложениями), а из-за требований по задержке. В отличие от трафика с данными, время за которое пакет проходит из одного конца сети в другой имеет значение. Если пакет с данными при прохождении через сеть испытал задержку (delay), то файловый сервер получит файл секундой позже или страничка в браузере будет загружаться чуть дольше, и с точки зрения пользователя не произойдет ничего страшного. Однако если голосовой трафик проходит по сети и испытывает задержку, то голоса начинают перекрываться (например, абонент начинает говорить одновременно с другим абонентом) и продолжать разговор становится невозможно.
Чтобы побороть эти проблемы нужно убедиться, что для голосового трафика подходит не только полоса пропускания, но и что голосовой трафик получает первую доступную полосу. Это означает что если бутылочное горлышко (самое узкое место) находится в сети, где маршрутизатор ставит трафик в очередь, то перед тем как его выслать, маршрутизатор будет перемещать голосовой трафик перед трафиком данных, чтобы отправить его в первом доступном интервале. И это как раз задача Quality of Service. QoS, по сути, является не отдельным инструментом, а классом инструментов, направленных на то чтобы дать администратору полный контроль над трафиком внутри сети. Как и когда использовать каждый инструмент QoS зависит от требований к сети от трафика и ее характеристик.
Понимание основных проблем
Перед тем как применять QoS, нужно разораться с тем, какие проблемы мы пытаемся решить. Рассмотрим основные:
Недостаток пропускной способности (Lack of bandwidth) – Множественные потоки голосового трафика и трафика с данными конкурируют за ограниченную полосу пропускания.
Задержка (Delay) – Для того чтобы пакет дошел из пункта отправления в пункт назначения требуется какое-то время. Задержка имеет три формы:
Фиксированная задержка (Fixed delay) – Значение задержки, которое нельзя изменить. Например, требуется определенное время, чтобы пакет добрался до определенной географической локации. Это значение считается фиксированным и QoS не может повлиять на него.
Переменная задержка(Variable delay) – Значения задержки, которые можно изменить. Например, задержка в очереди интерфейса маршрутизатора является переменной, потому что она зависит от того, сколько пакетов находится на данный момент в очереди. На эту задержку можно повлиять поставив голосовые пакеты перед пакетами с данными.
Джиттер (Jitter) – Разница задержек между пакетами. Например, первому пакету разговора потребовалось 100 мс чтобы добраться до точки назначения, в то время как второму потребовалось 110 мс. В этой ситуации джиттер составляет 10 мс.
Потеря пакетов (Packet loss) – пакеты теряются из-за переполненного или ненадежного сетевого подключения.
Очень важно понимать эти проблемы, поскольку они вызывают наложения звука, эхо, потрескивания и разорванные звонки.
Механизм QoS предназначен для того, чтобы обеспечить бесперебойную передачу голоса в течение временных перегрузок в сети. Однако это не волшебная палочка, которая сможет решить все проблемы в сети. Например, если в сети есть недостаток пропускной способности, то при добавлении голосовых пакетов не стоит ожидать что QoS сможет все решить – получится что либо приложения с данными будут работать так медленно, что перестанут быть функциональными, либо голосовой трафик будет испытывать проблемы с качеством.
Цель QoS – обеспечить постоянную пропускную способность для голосового трафика таким образом, чтобы была низкая постоянная задержка с одного конца сети в другой. Чтобы выполнить это требование необходимо иметь настроенные механизмы QoS в каждой точке сети, где существует перегрузка.
Требования к голосовому и видео трафику
Разный тип трафика, который используется в сети, имеет разные требования QoS. В отличие от трафика данных, голосовой трафик считается предсказуемым. В то время как трафик данных может значительно увеличиваться при скачивании или передачи большого объема данных, голосовой трафик остается постоянным для каждого звонка поступающего и покидающего сеть. Фактический объем полосы пропускания, требуемый для голоса сильно зависит от используемого кодека.
Помимо требований к пропускной способности, голосовой трафик имеет следующие дополнительные требования:
Задержка (End-to-end delay) : 150 мс или меньше
Джиттер: 30 мс или меньше
Потеря пакетов: 1% или меньше
Видео трафик имеет такие же требования по задержке, но потребляет большую полосу пропускания. Кроме того ширина полосы пропускания может меняться в зависимости от того, сколько движения происходит в видео (большее количество движений значительно увеличивают необходимую пропускную способность).
Требования к трафику данных
Невозможно подогнать весь трафик данных под одно требование, потому что каждое отдельное приложение имеет свои QoS требования. Приложения данных можно разделить на несколько категорий:
Критически важные приложения (Mission-critical applications) – эти приложения критически важны для организации и требуют выделенной полосы пропускания.
Транзакционные приложения (Transactional applications) – эти приложения обычно взаимодействуют с пользователями и требуют быстрого времени отклика. Например, сотрудник техподдержки может использовать приложение базы данных чтобы получать информацию о абоненте на основе ID предыдущих запросов.
Низкоприоритетные приложения (Best-effort applications) – эти приложения некритичны или некатегоризированы. Это может быть почта, веб и FTP.
“Мусорные ” приложения (Scavenger applications) – это непродуктивные приложения, в которых нет необходимости для работы, но которые поглощают значительные объемы полосы пропускания. Например, это могут быть p2p приложения типа BitTorrent
Каждой из этих категорий приложений можно назначить определенный уровень QoS.
Где и зачем?
На сегодняшний день логирование информации в процессе разработки имеет огромное значение. Сохранение информации в лог-файлы это первоочередная задача для выявления неполадок и слабых мест в работе приложения. Однако, если приложение работает на основе многих сложных процессов здесь не обойтись без эффективного инструмента навигации и анализа по логам. В одной из предыдущих статей мы разбирали такое решение, как ELK Elasticsearch, Logstash, Kibana. В таком сочетании эти программы способны оперативно решать задачи по сбору, хранению, выборке и анализу информации даже в крупных проектах. Это и является их основным назначением. Однако, эти программы также можно использовать по отдельности, поскольку они являются самостоятельными программными продуктами. Как же можно использовать эти приложения в разных сочетаниях, и для чего это нужно? Приступим к разбору.
Самым востребованным инструментом из этой тройки является Elasticsearch. Оно и понятно поисковая система, действующая на основе горизонтального масштабирования (то есть, с возможностью искать данные по запросу пользователя параллельно на множестве серверов) стала очень популярным решением для осуществления поиска не только в логах, но и во множестве данных. При этом данные не обязательно могут быть структурированы, и пользователь с высокой вероятностью получит четкие результаты по запрашиваемому фрагменту текста. При этом широкую популярность данному приложению обеспечивают также широкие возможности по интегрированию с другими программами, множество вариантов конфигурирования, а также подключаемые плагины, работа над которыми ведется как специалистами компании Elastic, так и "народными умельцами"
Альтернативным вариантом использования Elasticsearch является вариант с созданием на основе этого приложения централизованных хранилищ данных, содержащих логи использования с разных устройств. Конечно, в этом случае потребуется визуализация, поэтому наилучшее взаимодействие с Elasticsearch обеспечивает Kibana. Данная связка является наиболее популярной и эффективной, поскольку обе программы разрабатывались специально с прицелом на взаимодействие.
Несомненным плюсом ELK является модульная архитектура. Комбинируя различные модули, можно сконфигурировать систему для выполнения разнородных задач. Так, например, модуль Metricbeat, включенный в систему позволяет оптимально сконфигурировать систему для мониторинга инфраструктуры,решение Heartbeat позволяет осуществлять uptime-мониторинг. Направления Elastic SIEM и Elastic API также существенно расширяют функциональность ELK
Помимо непосредственно разработчиков, комплекс ELK Stack также могут использовать и тестировщики. Конечно, если приложение занимает небольшой объем, то установка ELK вряд ли будет рациональным решением, но, если это будет серьезная объемная программа, тогда тестер сможет быстро выявить проблему и не тратить время разработчика на поиск и анализ. Такая схема работы достаточно популярна и эффективна в некоторых компаниях, разрабатывающих программное обеспечение.
Также доступ к логам программы могут затребовать управленцы - менеджер, курирующий проект, или же представители заказчика. В данном случае анализ логов позволяет выявить, эффективно ли ведется работа над исправлением выявленных ранее неисправностей, и не появилось ли новых багов в процессе исправления старых.
В последнее время развивается использование комплекса ELK в бизнес-процессах для обеспечения эффективного сбора информации, оперативного анализа и принятия решений. Как пример, можно привести огромный супермаркет со множеством касс. Как правило, для наличного расчета на начало рабочего дня в кассе должна быть определенная сумма наличных для выдачи сдачи. Так вот, комплекс ELK применяется для сбора данных о проведенных по кассе операциях, выборки из собранных данных информации об остатках наличных в разных кассах, и анализа информации, после которого специалист, работающий с программой, может принять решение, какая сумма наличных нужна для обеспечения нужд кассиров по выдаче сдачи.
Непрерывный сбор и анализ информации позволяет оценить пики и спады, сравнить информацию с аналогичными показателями за вчерашний день, прошедшие неделю или месяц. По этой причине решение ELK приобретает все большую популярность как инструмент биржевой аналитики. Хотя на текущий момент есть инструменты и получше, однако динамика развития данного решения позволяет думать, что оно вряд ли перестанет быть актуальным и для подобных задач.