О событиях первого дня конференции написано здесь.
Вот и настал второй день конференции, знакомые лица, уже почти домашняя атмосфера, народ по кучкам, все общаются, кушают сытные бутерброды с чаем, печенки с кофе, в общем день обещает быть приятным и полезным.
Так и вышло! Второй день оказался еще более насыщенным.
Открыл конференцию Василий Довгошей, спикер от широко известной компании Битрикс24. Вопросы, которые были освещены спикером:
- CRM без интеграции с телефонией бесполезна
- Интеграция с CRM Битрикс24 доступна по REST API
Из основного, что хотелось бы выделить, новый API, который по заявлениям выступающего позволит реализовывать гораздо больше возможностей в части интеграции с телефонией, в сравнении с тем, что было раньше. Без плагинов, без мучений с разными версиями браузера... Со слов спикера одни плюсы, ну будем надеяться, что все именно так. И самое, что интересное, новое API позволит абонентам на АТС так и оставаться полноценными абонентами АТС со всеми вытекающими.
Игорь Гончароский рассказал об архитектуре asterisk, низкоуровневых нововведениях (bridge, стасис). Информация очень полезная для разработки собственных модулей. Гуманитарии спали, инженеры оживились.
С удовольствием послушали представителей компании Callforce. Они презентовали свою систему, в чем-то опережающую Российский рынок по своему функционалу (информация воспринимается двояко, так как презентация рассказывает о чём-то из области фантастики, хотя их разработки на самом деле работают). Возможно это единственная компания, специалисты которой связали такие тенденции IT сферы как ИИ + bigdata и телефония. Рады за ребят, молодцы!
Спикер от компании Sipteco поведал об опыте построения облачных АТС для операторов связи. Темами доклада были:
- Использование Asterisk под большими нагрузками
- Особенности архитектуры для Saas услуги
- Использование Asterisk в виртуальной машине.
В очередной раз убеждаемся в существовании общего информационного пространства - ничего нового, в качестве контейнеров для серверов телефонии используется виртуализация KVM (виртуальные машины).
Используется opensip в качестве sip прокси. По завершению доклада задавали много вопросов про СОРМ. Говорят, с этого года виртуальные АТС также надо закрывать СОРМом. На деле же, что скорее всего, закрывать нужно узел как и прежде, а уж что там за АТС не принципиально.
Представитель от Вокслинк рассказал про интеграцию системы телефонии с телеграмм. Очень удобно с точки зрения получения нотификаций, статистики, даже записанных разговоров. Мобильный телефон всегда в руках - на это сделана большая ставка. Телеграмм используется как панель управления сервером телефонии для супервайзера, оператора, администратора.
Один из спикеров конференции выступил с темой доклада про кластер. Основные тезисы его выступления:
- Принцип и методология построения кластера. Компоненты решения.
- Ключевые ошибки при построении решения и как их избежать
От желания поделиться опытом и ответить на вопросы слушателей вместо спикера, в процессе доклада по кластеризации, невозможно было усидеть на месте. С одной стороны приятно, что, сообщество поднимает темы надежности к обсуждению и предлагает решения. С другой презентуемые - решения сильно отстают от мировых тенденций, в результате не покрывают полного спектра ситуаций и кейсов, которые можно закрывать более универсальными, более современными и более удобными продуктами. В частности, со ссылкой на базу знаний Вокслинк, спикер рассказал о применении технологии распределенного сетевого блочного устройства drbd в связки с сервисом кластеризации heartbeat в системах телефонии высокой доступности.
Специалисты компании Файбекс прошли огромный путь в создании систем высокой доступности на базе кластера серверов телефонии, испытав всевозможные архитектуры и наработав бесценный опыт. Именно поэтому, в блоке 'вопрос-ответ' после доклада, выступил наш ведущий специалист Захаров Антон с рядом предложений и рекомендаций.
- не синхронизировать ни бинарные файлы сервисов, ни модули астериск через сетевое блочное устройство (DRBD). Во-первых, в качестве сервера могут использоваться разные архитектуры, а следовательно и разная оптимизация при сборке. Во-вторых, всегда будет возможность выкатить новую версию дистибутива на резервный узел для опытной эксплуатации в боевой среде.
- не синхронизировать записи разговоров через DRBD. Ну, или синхронизировать, но только один день (или одну неделю), а после переносить записи в архив на СХД, подключенное по nfs или samba. Сервера телефонии всё чаще устанавливаются на виртуальные сервера, где дисковая подсистема строится на быстрых дисках SSD малой ёмкостью, которые также включены в RAID. Хранение записей разговоров на двух серверах, каждый из которых содержит RAID - это чрезмерная избыточность, предъявляющая завышенные требования к ёмкости дисков самих гипервизоров. Поэтому мы рекомендуем основной архив записей разговоров хранить именно на выделенной СХД, а на самих серверах, том же DRBD хранить небольшой объём архива.
- не синхронизировать журналы серверов телефонии. Имея историю событий на том сервере, где произошли эти события, позволяет инженерам анализировать неисправность в тот момент, когда система телефонии работает у заказчика. Упреждая вопрос про fail2ban, который получает информацию из логов: fail2ban хранит список заблокированных адресов в sqlite, который также можно синхронизировать. Нет необходимости синхронизировать логи с попытками подбора паролей, чтобы на каждом узле fail2ban анализировать эти логи и составлять свой список IP адресов со злонамеренными подключениями, достаточно синхронизировать этот список между узлами.
- Safe_asterisk лучше не использовать, т.е. сервис кластеризации может сам осуществлять restart + отсутствие safe_asterisk позволит сервису кластеризации получать актуальное состояние процесса именно asterisk, а не safe_asterisk.
- Самое главное, вместо heartbeat использовать coresync. Данный сервис кластеризации добавляет много фишек, такие как проверка доступности сети, создание маршрутов до подсетей через шлюз с указанием источника подключения и многое другое. Таким образом есть возможность использовать кластер в сетях, где требуется регистрировать абонентов по нескольким сетевым интерфейсам сервера телефонии (сохраняя при этом опцию на астериске bindaddr=0.0.0.0)
- Не использовать отдельную репликацию баз данных mysql, если базу данных можно вынести на DRBD. Это исключит еще один канал связи между серверами и позволит избежать ошибок репликации (разъезжаются индексы, где-то заканчивается место и падает сервис СУБД и многие другие причины).
Здесь, в открытом доступе, представлена более подробная информация о кластеризации, приглашаем всех, кому интересна данная тема.
В заключительном челлендже выиграли приз от Voip-shop, успев ответить на один из простецких вопросов: «зачем используются порты 4000-4999». А также являлись автором вопроса: «Зачем используется параметр nonce в заголовках SIP пакета?» (Это один из наших вопросов на собеседовании). А вы знаете?
Поводя итоги, хотелось бы во-первых поблагодарить организаторов за очередную качественную конференцию, ну и пожелать что бы в следующем году было еще больше качественных докладов, сильных и толковых спикеров, актуальных тем, требующих освещения для всего сообщества.
Ну и во-вторых, в следующим году, также рассчитываем выступить с докладом, надеемся, что организаторы поддержат в этом вопросе, а тема будет полезной и подтолкнет сообщество Asterisk на шаг вперед.
Комментарии (2)