По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, друг! Если ты читаешь эту статью, то скорее всего столкнулся с ошибкой VT-x/AMD-V hardware acceleration is not available on your system когда пробовал создать виртуальную машину в Virtual Box, или такой ошибкой при работе с VMWare: This host supports Intel VT-x, but Intel VT-x is disabled или чем-то похожим при работе с другой средой виртуализации. Продолжай читать и ты обязательно найдёшь причину!
Для начала, позволь вкратце объяснить, что такое VT-x и AMD-V.
VT-x – это технология, разработанная компанией Intel в 2005 году, которая позволила процеcсорам (CPU) данного производителя поддерживать аппаратную виртуализацию. Грубо говоря, появилась возможность имея один компьютер, создать другой внутри него и даже с другой операционной системой!
AMD-V - это технология аппаратной виртуализации от компании AMD. Первые процессоры от производителя AMD появились на рынке годом позже, в 2006 году.
Итак, теперь вот тебе топ 3 причин, по которым ты мог встретить вышеупомянутые ошибки:
Процессор твоего "комплюктера" попросту не поддерживает технологии виртуализации VT-x/AMD-V.
Возможно ты являешься обладателем очень старого или наоборот крайне специфичного девайса, CPU которого просто не умеет в виртуализацию. В таком случае, ты не сможешь устранить те ошибки и запустить виртуалку в любой среде виртуализации. Но не огорчайся, есть масса способов покрутить виртуалки, например, воспользоваться услугами VDS/VPS хостера!
VT-x/AMD-V отключила Hyper-V.
Hyper-V это проприетарная технология виртуализации от Microsoft, которая по умолчанию вырубает поддержку VT-x/AMD-V, чтобы избежать конфликтов. Короче придётся выбирать между Hyper-V и другой конфликтующей средой виртуализации.
Технология VT-x или AMD-V просто выключены и их нужно включить.
По умолчанию, поддержка виртуализации выключена в BIOS и чтобы победить ошибки из начала статьи и, наконец запустить заветную виртуалку, тебе нужно просто зайти в BIOS и включить VT-x/AMD-V!
В зависимости от производителя твоего компьютера, может быть несколько вариантов перехода в BIOS. Обычно, тебе нужно просто перезагрузить компьютер и дождаться на экране надписи: Press to enter BIOS, а вот какая-то кнопка может быть разной.
Вот тебе несколько примеров для разных производителей:
Asus, Lenovo, DELL
Как правило просят нажать F2
Перейти на вкладку Advanced, выбрать Virtualization Technology и нажать Enter
Сменить состояние строки с Disabled на Enabled после чего нажать F10, чтобы сохранить изменения и перезагрузить компьютер
Acer, HP
Как правило просят нажать F2 ну или F1 или же CTRL+ALT+ESC или F10
Нажать на правую стрелку и перейти на вкладку System Configuration, выбрать Virtualization Technology и нажать Enter
Сменить состояние строки с Disabled на Enabled после чего нажать F10, чтобы сохранить изменения и перезагрузить компьютер
Компьютеры с процессорами AMD
Как правило просят нажать F2
Выбрать вкладку Advanced затем CPU Configuration, после чего выбрать SVM Mode и нажать Enter
Сменить состояние строки с Disabled на Enabled после чего нажать F10, чтобы сохранить изменения и перезагрузить компьютер
Сейчас мы докажем, что в FreePBX можно записать вообще всё.
Мы уже рассказывали про логику записи звонка и том на каких фазах мы можем её контролировать. Однако, стандартный функционал записи ограничивается модулем, в рамках которого мы хотим начать запись. Например, если мы включаем запись на внутреннем номере (Extension), то услышим только часть звонка, которая началась, когда абонент данного номера снял трубку.
Но что, если мы хотим записать ещё и ту часть звонка, которая была до этого? Например, как звонящий терпеливо выбирал опции нашего IVR и какие комментарии при этом отпускал? :)
Для этого в FreePBX существует специальный модуль - Call Recording, который позволяет принудительно включить или отключить автоматическую запись звонка на определенном его этапе. Любые другие опции записи, которые были включены до этого, при этом будут проигнорированы. Но самое главное, что записи звонков, сделанные через этот модуль, будут содержать все голосовые приветствия (Announcement), музыку на ожидании (Music On Hold) и другие сообщения, которые проигрывает наша IP-АТС каждому позвонившему абоненту.
Множество модулей во FreePBX, таких как модуль очередей (Queues), входящей маршрутизации (Inbound Routes), групп вызова (Ring Group), позволяют управлять записью звонка напрямую. Для этого в них есть специальные опции – Call Recording, которые можно при необходимости активировать.
Модуль, о котором мы говорим в этой статье, позволяет настроить принудительное начало записи звонка ещё до того, как он отправится на какое-нибудь направление, которое не имеет опции записи. Например на Page группу или IVR.
Настройка
Перед установкой, проверьте какая версия модуля callrecording у вас установлена. Для этого в консоли введите команду: fwconsole ma list | grep callre. Версия модуля должна быть 14.0.5 и выше, поскольку в более ранних версиях, обнаружен баг (FREEPBX-18899 (https://issues.freepbx.org/browse/FREEPBX-18899)) и функционал полной записи работать не будет :(. Если установлена более ранняя версия, то сделайте обновление данного модуля
После этого переходим во вкладку Settins - Advanced Settings и в разделе Call Recording ищем новую опцию, которая должна появиться - Call Recording Option, её значение устанавливаем в No и только после этого переходим к следующему шагу
Для настройки открываем Applications → Call Recording и нажимаем Add Call Recording:
Перед нами открывается меню добавления нового правила записи звонков:
Как видите всё достаточно просто:
Description - Описание данного правила;
Call Recording Mode - Логика записи, подробно описана в нашей статье;
Force и Never заменяют друг друга и имеют высший приоритет чем Yes и No
Yes и No имеют одинаковый приоритет
Когда один и больше Yes или No встречается в call flow, в приоритете всегда будет первое значение.
Последующие опции Yes или No не переопределяют первую.
Force и Never будут всегда переопределять опции, которые установлены ранее.
Force и Never будут всегда заменять друг друга. Например если сначала был установлен Force, а потом встречается Never, то в приоритете будет Never
Force и Never будут всегда заменять предустановленные опции Yes и No
Yes и No никогда не заменять Force и Never
Don’t Care не будет изменять предыдущую опцию.
Destination - Указывает направление куда необходимо отправить звонок после того, как была включена или же отключена запись.
Применение
Давайте представим себе, что у нас есть входящий маршрут (Main_Route), звонки с которого отправляются в IVR (Main_IVR). Но мы хотим слышать что говорит звонящий, находясь в меню IVR и слушая голосовое сообщение, например для последующего анализа и оценки его реакции.
Для этого, мы создадим Call Recording (For_IVR_Recordings), которое будет включать запись и отправлять звонок на тот же самый IVR, а сам Call Recording – повесим на входящий маршрут:
Готово! Теперь мы получим запись звонка, которая будет содержать часть, где звонящий находится в IVR и слушает его сообщение, и, возможно даёт какие-нибудь комментарии. Остальная часть записи будет зависеть от того, какие опции настроены в IVR.
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.