По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 1974 года («Формальные требования к виртуализируемым архитектурам третьего поколения» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешная виртуализация должна обеспечивать такую среду, которая:
Эквивалента физическому компьютеру, поэтому доступ программного обеспечения к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
Обеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
По возможности эффективно выполняет операции непосредственно на базовых аппаратных ресурсах, включая ЦП.
Виртуализация позволяет разделить физические ресурсы вычислений, памяти, сети и хранилища («основополагающая четверка») между несколькими объектами. Каждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. Грамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой связи между средами. Виртуализация также позволяет создавать и запускать новые виртуальные машины почти мгновенно, а затем удалять их, когда они перестанут быть необходимыми.
Для больших приложений, поддерживающих постоянно меняющиеся бизнес-требования, возможность быстрого вертикального масштабирования с повышением или понижением производительности может означать разницу между успехом и неудачей. Адаптивность, которую предлагает виртуализация, позволяет скриптам добавлять или удалять виртуальные машины за считанные секунды, а не недели, которые могут потребоваться для покупки, подготовки и развертывания физического сервера.
Как работает виртуализация?
В невиртуальных условиях, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начиная с Кольца 0 (Ring 0) по Кольцо 3).
Как правило, только ядро операционной системы хоста имеет какой-либо шанс получить доступ к инструкциям, хранящимся в кольце под номером 0. Однако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызывая больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправлял запросы на такие ресурсы, как память и хранилище, на виртуализированные системы, эквивалентные им.
При работе в аппаратной среде без виртуализации SVM или VT-x все это выполняется с помощью процесса, известного как ловушка, эмуляция и двоичная трансляция. На виртуализированном оборудовании такие запросы, как правило, перехватываются гипервизором, адаптируются к виртуальной среде и возвращаются в виртуальную машину.
Простое добавление нового программного уровня для обеспечения такого уровня организации взаимодействия приведет к значительной задержке практически во всех аспектах производительности системы. Одним из успешных решений было решение ввести новый набор инструкций в ЦП, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позволяет гостевой ОС работать без какого-либо влияния на другие несвязанные операции.
На самом деле, при правильной реализации виртуализация позволяет большинству программных кодов работать как обычно, без каких-либо перехватов.
Несмотря на то, что эмуляция часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. В то время как виртуализация стремится разделить существующие аппаратные ресурсы между несколькими пользователями, эмуляция ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. Для этого требуется программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.
Эмуляция может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.
Согласно сложившимся представлениям, существует два класса гипервизоров: Type-1 и Type-2.
Bare-metal гипервизоры (исполняемые на «голом железе») (Type-1), загружаются как операционная система машины и – иногда через основную привилегированную виртуальную машину – сохраняют полный контроль над аппаратным обеспечением хоста, запуская каждую гостевую ОС как системный процесс. XenServer и VMWare ESXi – яркие примеры современных гипервизоров Type-1. В последнее время использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хотя раньше оно использовалось только для описания систем Type-1. Первоначально более общим термином, охватывающим все типы систем, был «Мониторы виртуальных машин». То, в какой степени люди используют термин «мониторы виртуальных машин» все это время, наводит меня на мысль, что они подразумевают «гипервизор» во всех его интерпретациях.
Гипервизоры, размещенные на виртуальном узле (Type-2) сами по себе являются просто процессами, работающими поверх обычного стека операционной системы. Гипервизоры Type-2 (включая VirtualBox и, в некотором роде, KVM) отделяют системные ресурсы хоста для гостевых операционных систем, создавая иллюзию частной аппаратной среды.
Виртуализация: паравиртуализация или аппаратная виртуализация
Виртуальные машины полностью виртуализированы. Иными словами, они думают, что они обычные развертывания операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. Поскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ОС, то они могут работать с готовыми немодифицированными программными стеками. Однако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмуляции занимало дополнительное время и циклы.
В случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хотя бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Эта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. На первых порах это позволяло гипервизорам PV достигать более высокой производительности для операций, требующих подключения к аппаратным компонентам.
Тем не менее, для того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ЦП, которая позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, связанное с ловушкой и эмуляцией, и в полной мере воспользоваться преимуществами аппаратных расширений и немодифицированных операций ядра программного обеспечения.
Также значительно повысить производительность виртуализации может последняя технология Intel – таблицы расширенных страниц (EPT – Extended Page Tables).
В связи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.
Аппаратная совместимость
Как минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ЦП хоста. Именно поэтому вы должны убедиться, что на вашем сервере есть все, что вам необходимо для задачи, которую вы собираетесь ему дать. Большая часть того, что вам нужно знать, храниться в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. Однако вам нужно знать, то искать, потому что флагов будет очень много.
Запустите эту команду, чтобы посмотреть, что у вас под капотом:
$ grep flags /proc/cpuinfo
Контейнерная виртуализация
Как мы уже видели ранее, виртуальная машина гипервизора – это полноценная операционная система, чья связь с аппаратными ресурсами «основополагающей четверки» полностью виртуализирована – она думает, что работает на собственном компьютере.
Гипервизор устанавливает виртуальную машину из того же ISO-образа, который вы загружаете и используете для установки операционной системы непосредственно на пустой физический жесткий диск.
Контейнер в свою очередь фактически представляет собой приложение, запускаемое из скриптообразного шаблона, которое считает себя операционной системой. В контейнерных технологиях, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые зависят от ядра хоста и представления аппаратных ресурсов «основополагающей четверки» (т.е. ЦП, ОЗУ, сеть и хранилище) для всего, то они делают.
Конечно, с учетом того, что контейнеры фактически являются изолированными расширениями ядра хоста, виртуализация Windows (или более старых или новых версий Linux с несовместимыми версиями libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Но эта технология обеспечивает невероятно простые и универсальные вычислительные возможности.
Перемещение
Модель виртуализации также позволяет использовать широкий спектр операций перемещения, копирования и клонирования даже из действующих систем (V2V). Поскольку программные ресурсы, определяющие виртуальную машину и управляющие ею, очень легко идентифицировать, то обычно не требуется очень много усилий для дублирования целых серверных сред в нескольких местах и для разных целей.
Иногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Большинство платформ предлагают единую операцию командной строки для перемещения гостей между хостами.
Перемещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.
Графический интерфейс администратора IP – АТС Asterisk – FreePBX, насчитывает огромное количество опций настройки, вариантов маршрутизации, подключения различного оборудования, начиная от телефонных аппаратов и заканчивая шлюзами. Задумались о внедрении Asterisk? В статье мы опишем базовую настройку тринадцатой версии FreePBX сразу после установки дистрибутива FreePBX.
Пошаговое видео
Подключение к FreePBX
Чтобы подключиться к графическому интерфейсу FreePBX, нужно ввести IP – адрес Asterisk, который вы указали на этапе установки. Если вы забыли, какой IP – адрес указали, то подключите монитор и клавиатуру к вашему серверу, а затем введите данные для пользователя root, как показано ниже:
При подключении, вам будет указан IP – адрес вашего сервера. Если версия вашего дистрибутива отличается, и вы не увидели аналогичного вывода, укажите следующую команду:
[root@localhost ~]# ifconfig
Вывод команды позволит вам увидеть все доступные интерфейсы и их IP – адреса.
Активация и пароль администратора
Подключившись к FreePBX 13 через интернет – браузер вам будет сразу предложено создать учетную запись администратора указав логин, пароль и адрес электронной почты администратора системы. После успешного создания, выберите на главной страницу пункт FreePBX Administration
и укажите созданные параметры:
Сразу после подключение, перейдите во вкладку Admin → System Admin и нажмите кнопку Activation
Далее нажмите кнопку Activate
После этого, следуйте инструкциям инсталлятора. Необходимо будет указать адрес электронной почты, пароль, номер телефона и местоположение вашего сервера.
Настройки SIP
Модуль SIP Settings это графическая визуализация настроек в файле /etc/asterisk/sip_nat.conf. Здесь, с помощью графического интерфейса можно настроить важнейшие параметры, такие как настройки NAT, внешний IP – адрес и настройки кодеков. Чтобы перейти к настройке нажмите на вкладку Settings, а далее Asterisk Sip Settings.
Allow Anonymous inbound SIP Calls
Данная опция позволяет разрешить, или запретить входящие звонки с неизвестных номеров. Мы советуем запрещать данный вид звонков, так как потенциально, разрешенные анонимные звонки могут стать лазейкой для злоумышленников.
Local Networks
Введите локальные (находящиеся внутри вашей сети) адреса подсетей, которым Asterisk будет доверять. Например, 192.168.2.0/255.255.255.0
RTP Ranges
Укажите диапазон RTP портов. Рекомендуем все оставлять по умолчанию.
Strict RTP
Когда между двумя устройствами устанавливается RTP поток, то назначаются адреса источника и назначения. При включенной данной опции, все пакеты приходящие с другого IP – адреса буду отброшены. Мы рекомендуем не выключать данную опцию.
Codecs
Галочкой отметьте нужные кодеки.
Положение кодеков указывает их приоритет. Например, на скриншоте ниже приоритет отдан g.711 u-law, затем g.711 a-law, gsm и так далее. Более подробно про телефонные кодеки использующиеся в VoIP сетях вы можете прочитать в наших прошлых статях.
Настройка NAT в FreePBX
В большинстве случаев, если администратор обнаруживает проблему односторонней слышимости, или то, что звонки обрываются спустя несколько секунд разговора – проблема в NAT. Вот что нужно сделать, чтобы избавиться от этой проблемы: в настройка модуля Asterisk SIP Settings , переходим во вкладку Chan SIP Settings и отмечаем следующее:
NAT - yes
IP Configuration - Static IP
Override External IP - введите ваш внешний IP - адрес
Reinvite Behavior - No
Обязательно укажите в настройках Local Networks в предыдущей вкладке вашу локальную подсеть. Помимо этого, пробросьте на вашем маршрутизаторе порт 5060 и диапазон портов из параметра RTP Ranges, по умолчанию равный 10000-20000
Настройка сетевых параметров FreePBX
Есть три важных пункта данной настройки:
Настроить статический IP – адрес для сервера
Настроить DNS
Настроить временную зону
Перейдем к настройке IP. Для этого, перейдите во вкладку Admin → System Admin→ Network Settings
Здесь мы настраиваем следующие опции:
Network Interface - сетевой интерфейс, то есть конкретная сетевая карта (NIC)
IP Assignment - выберите Static чтобы настроить статический IP - адрес
Static IP - введите IP – адрес сервера
Netmask - маска сети
Gateway - шлюз по умолчанию
Start Automatically - старт при загрузке сервера
Далее, переходим к настройке DNS. Для этого переходим в боковом меню навигации к пункту DNS. Здесь просто указываем адрес DNS сервера, например 8.8.8.8:
Идем дальше. Теперь настроим временную зону, перейдя в боковом меню навигации в пункт Time Zone. В данном примере, наш сервер располагается в Москве:
Настроим уведомления нашего сервера Asterisk, при таких сбоях, как например малое дисковое пространство или сбой в работе RAID массива:
Производим настройку следующих опций:
From Address - адрес электронной почты, который АТС будет указывать как адрес отправителя при формировании письма
Storage Notifications - почта для уведомлений о проблемах с хранением данных (сбой RAID или нехватка места на дисках)
Intrusion Detection Notifications IP - почта для уведомлений о вторжениях или попытках взлома сервера
Конфигурация системы безопасности
В Asterisk встроена система обнаружения вторжений – Fail2Ban. Для настройки системы перейдите во вкладку Admin → System Admin→ Intrusion Detection
Система гибкая, и , порой реагирует когда не нужно :) Поэтому, советуем заранее вносить в Whitelist перечень нужных IP – адресов, таких как IP SIP – прокси, адреса шлюзов, например FXS. Порой, бывает так, что в бан попадает IP – адрес FXS шлюза, к которому подключены все офисные аналоговые телефоны.
Status - мы рекомендуем всегда контролировать состояние Fail2Ban, чтобы статус был running
Intrusion Detection - в данном пункте можно остановить и перезапустить службу.
Ban Time - время в секундах, которое IP – адрес будет находиться в статусе блокировки
Max Retry - количество попыток подключения к АТС, которое пользователь может осуществить в течение Find Time.
Find Time - время, в течение которого у пользователя есть Max Retry попыток подключения к системе.
E-mail: - адрес электронной почты, на которую будут отправляться уведомления о внесении нового IP – адреса в бан.
Whitelist - список заранее внесенных IP – адресов, которым доверяет администратор.
Настройка внутренних номеров
Для настройки телефонных аппаратов и создания внутренних номеров перейдите во вкладку Applications → Extensions. Процесс создания внутренних номеров (Extension) мы описали в статье по ссылке ниже:
Создание Extensions
Настройка SIP - транка
Подключение к провайдеру является важнейшим этапом в настройке вашего сервера IP - АТС Asterisk. Именно настройки провайдера, позволят нашим пользователям совершать исходящие, и принимать входящие вызовы. Для настройки SIP – транка перейдите во вкладку Connectivity → Trunks. Процесс создания SIP - транка подробно расписан в статье по ссылке ниже:
Создание SIP - транка
Настройка маршрутизации
После того, как мы настроили внутренние номера и SIP – транки для подключения к провайдеру, нам необходимо настроить маршрутизацию вызова. В рамках данной настройки, мы будем учить наш сервер Asterisk как обрабатывать входящий и исходящие вызовы. Connectivity → Inbound/Outbound Routes. Данный процесс мы подробно описали в статье по ссылке ниже:
Настройка маршрутизации вызовов
Настройка голосового меню
Так как наш Астериск будет установлен в небольшой компании, мы планируем сделать голосовое меню, в котором будем помогать пользователям быстрее связаться с нужным человеком. Настройка голосового меню (IVR), регламентируется в модуле IVR, консоль конфигурации которого располагается во вкладке Applications → IVR. Настройку вы можете найти по ссылке ниже::
Настройка IVR
Сегодня хотим рассказать про любопытный параметр, который связан с настройкой RTP – потоков в IP – АТС Asterisk. Если Вас не устраивает сброс вызова после 5 минут удержания (режим hold) или сброс через 30 секунд при полном отсутствии RTP/RTCP – у нас есть решение. Настройку осуществим с помощью графического интерфейса FreePBX 13.
Решение проблемы
Поведение, о котором мы рассказали выше, происходит из – за двух параметров: RTP Timeout и RTP Hold Timeout. По умолчанию, первый равен 30, а второй равен 300 (в секундах). Первый параметр полезен: например, если у вас есть телефонный аппарат, который подключен за NAT, и во время конференции он «отвалится» (пропадет интернет соединение, потеря питания и так далее), то через 30 секунд его сессия будет терминирована автоматически. Второй параметр отвечает за терминирование вызова, который поставлен на удержание. Предположим, что «забывчивый» оператор поставил клиента на удержание на одной из линий и забыл про него. Телефон клиента не дал корректный сигнал отбоя и сессия подвисла. Это занимает соответствующие DSP/CPU ресурсы сервера, и имеет эффект накопления, по итогам которого, могут начаться перебои в связи.
Данные параметры можно легко «подкрутить». Переходим в раздел Settings → Asterisk SIP Settings. Во вкладке Chan SIP Settings находим сегмент настроек под названием MEDIA & RTP Settings и правим указанные ниже на скриншоте параметры, согласно своим требованиям: