По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет рассмотрен самый быстрый и удобный способ создания нового экстеншена на FreePBX 13 и последующей регистрацией его на SIP-телефоне Yealink SIP-T21P E2.
Пошаговое видео
Настройка
Интерфейс серьезно изменился по сравнению с предыдущей версией, в частности, теперь есть разбивка по типам экстеншенов, и, главное – появился инструмент быстрого создания экстеншенов.
Как видно на скриншоте выше, теперь есть следующие поля:
All Extensions
Custom Extensions
DAHDi Extenstions и пр. типы экстеншенов – PJSIP, CHANSIP и т.д.
Ниже находится кнопка добавления экстеншена и, самое важное, кнопка быстрого добавления экстеншена (Quick Create Extension). При нажатии на неё появится окно быстрого добавления (скриншот ниже).
Как видно, первые несколько полей, которые должны быть заполнены:
Type – для наших целей выбираем Chan_SIP
Extension Number – соответственно номер экстеншена в соответствии с планом нумерации
Display Name – имя экстеншена, которое будет отображаться на экстеншене
Outbound Caller ID – данное поле оставляем пустым, опция форсированной установки требуемого Caller ID при исходящем вызове. Если поле оставить пустым, то будет устанавливаться Caller ID указанный в настройках транка.
Email Address – электронный почтовый адрес, если его указать, то может пригодиться при последующей настройке факса.
Далее необходимо нажать Next и появляется окно со вторым шагом настройки:
Здесь предлагаются следующие настройки:
Find Me / Follow Me – опция FMDM позволяет перенаправить звонок с данного экстеншена на другое направление, к примеру экстеншен звонит 7 секунд, а после начинает звонить мобильный телефон сотрудника. Возможны различные сценарии.
Create User Manager User – данную опцию можно включить для автоматического создания пользователя, проассоциированного с этим экстеншеном, но так же просто его создать после в опциях экстеншена
Enable Voicemail – активировать голосовую почту для экстеншена и обозначить пароль (PIN) для голосовой почты
Если перейти обратно в Applications – Extensions, и выбрать поле All Extensions или CHAN_SIP, выбрать экстеншен, который был создан нами в предыдущем шаге и нажать на кнопку редактирования, то появится следующее окно:
Как видно, здесь указаны такие параметры как:
Используемая технология и её порт (в случае CHAN_SIP) – 5061
Имя экстеншена
Автоматически сгенерированный пароль
Настройки User Manager – на скриншоте был создан пользователь test, подключенный к экстеншену 6996 и пароль для него.
На этом настройка экстеншена закончена – необходимо скопировать пароль для экстеншена в буфер обмена, нажать кнопку Submit и затем Apply Config.
Настройка Yealink SIP-T21P E2
Переходим к настройке телефона Yealink SIP-T21P E2:
Необходимо попасть на веб-интерфейс телефона, для чего нужно ввести его адрес (к примеру, 192.168.1.5) и далее появится окно авторизации :
После логина, необходимо нажать на кнопку «Аккаунт»
Далее необходимо отметить опцию «Аккаунт» → «Включено», ввести лейбл (ярлык), отображаемое имя и имя регистрации (номер экстеншена). Имя пользователя можно оставить пустым, а можно продублировать значение «Имя регистрации». В качестве пароля используем автоматически сгенерированную строку Secret, которую вставляем в это поле.
После этого обозначается адрес SIP-сервера и порт (в нашем случае - 5061).
На этом настройка заканчивается, необходимо нажать «Сохранить» и телефон должен зарегистрироваться и начать работать.
Виртуальные сети - это, в простейшем виде, создание логических топологий, построенных на основе физической топологии. Эти логические топологии часто называют виртуальными топологиями - отсюда и концепция виртуализации сети. Эти топологии могут состоять из одного виртуального канала в более крупной сети, называемого туннелем, или набора виртуальных каналов, которые кажутся полной сетью поверх физической сети, называемой наложением.
Этот раздел лекций начнется с обсуждения того, почему создаются и используются виртуальные топологии, проиллюстрированные двумя примерами использования. Во втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. Далее будут рассмотрены два примера технологий виртуализации: сегментная маршрутизация (segment routing-SR) и программно - определяемые глобальные сети (Software-Defined Wide Area Networks- SD-WAN).
Понимание виртуальных сетей
Виртуализация усложняет проектирование протоколов, сетей и устранение неполадок, так зачем же виртуализировать? Причины, как правило, сводятся к разделению нескольких потоков трафика в одной физической сети. Это может показаться подозрительно похожим на другую форму мультиплексирования, потому что это еще одна форма мультиплексирования. Основные различия между рассмотренными до сих пор формами мультиплексирования и виртуализацией заключаются в следующем:
Позволяет нескольким плоскостям управления работать с различными наборами информации о достижимости в рамках одной физической топологии;
Позволяет нескольким наборам достижимых пунктов назначения работать в одной физической топологии без взаимодействия друг с другом;
Рассмотренные до этого момента методы мультиплексирования были сосредоточены на том, чтобы позволить нескольким устройствам использовать одну физическую сеть (или набор проводов), позволяя каждому устройству взаимодействовать с любым другим устройством (при условии, что они знают друг о друге с точки зрения достижимости). Виртуализация направлена на разбиение одной физической сети на несколько доменов достижимости, где каждое устройство в домене достижимости может взаимодействовать с любым другим устройством в том же домене достижимости, но устройства не могут связываться между доменами достижимости (если нет какой-либо точки соединения между достижимостью домены).
На рисунке 1 показана сеть с виртуальной топологией, расположенной поверх физической топологии.
На рисунке 1 виртуальная топология была создана поверх физической сети, с виртуальным каналом [C,H], созданным для передачи трафика по сети. Чтобы создать виртуальную топологию, C и H должны иметь некоторую локальную информацию пересылки, отделяющую физическую топологию от виртуальной топологии, которая обычно проходит либо через E, либо через D. Это обычно принимает форму либо специального набора записей виртуального интерфейса в локальной таблице маршрутизации, либо таблицы виртуальной маршрутизации и пересылки (VRF), содержащей только информацию о виртуальной топологии.
Рассмотрение потока пакетов через виртуальную топологию может быть полезно для понимания этих концепций. Как бы выглядел поток пакетов, если бы C и H имели виртуальные интерфейсы? Рисунок 2 демонстрирует это.
На рисунке 2 процесс пересылки выполняется следующим образом:
A передает пакет к M.
C получает этот пакет и, исследуя свою локальную таблицу маршрутизации, находит, что кратчайший путь к месту назначения лежит через виртуальный интерфейс к H. Этот виртуальный интерфейс обычно называется туннельным интерфейсом; он выглядит с точки зрения таблицы маршрутизации, как и любой другой интерфейс маршрутизатора.
Виртуальный интерфейс, через который необходимо передать пакет, имеет инструкции перезаписи, которые включают добавление нового заголовка, заголовка туннеля или внешнего заголовка в пакет и пересылку полученного пакета. Исходный заголовок пакета теперь называется внутренним заголовком. C добавляет внешний заголовок и обрабатывает новый пакет для пересылки.
Теперь C исследует новый пункт назначения, которым является H (помните, что исходным пунктом назначения был M). H не подключен напрямую, поэтому C необходимо выяснить, как достичь H. Это называется рекурсивным поиском, поскольку C ищет путь к промежуточному месту назначения, чтобы доставить пакет к конечному месту назначения, но не к нему.
Теперь C поместит правильную информацию в пакет в заголовок link local, чтобы перенаправить трафик на E.
Когда E получает этот пакет, он удаляет внешнюю информацию о переадресации, Заголовок link local и пересылает трафик на основе первого заголовка C, помещенного в пакет, во время первоначального поиска. Этот внешний заголовок говорит E переслать пакет в H; E не видит и не включает исходный внутренний заголовок, помещенный на пакет A.
E добавит новый Заголовок link local, чтобы пакет был правильно переадресован в H, и передаст пакет по правильному интерфейсу.
Когда H получает пакет, он удаляет Заголовок link local и обнаруживает внешний заголовок. Внешний заголовок говорит, что пакет предназначен для самого H, поэтому он очистит этот заголовок и обнаружит исходный заголовок пакета или внутренний заголовок.
Теперь H посмотрит в своей локальной таблице маршрутизации и обнаружит, что M локально подключен. H поместит правильный Заголовок link local в пакет и передаст его через правильный интерфейс, чтобы пакет достиг M.
Если C и H используют VRF, а не туннельные интерфейсы, процесс в предыдущем списке изменяется на шагах 2 и 8. На шаге 2 C будет искать M как пункт назначения в VRF, связанном каналом [A, C]. Когда C обнаруживает, что трафик к M должен пересылаться через виртуальную топологию через H, он помещает внешний заголовок в пакет и снова обрабатывает пакет на основе этого внешнего заголовка через базовый VRF или, скорее, таблицу маршрутизации, представляющую физическую топологию. Когда H получает пакет, он удаляет внешний заголовок и снова обрабатывает пакет, используя VRF, к которому подключен M, для поиска информации, необходимой для пересылки трафика в его конечный пункт назначения. В этом случае интерфейс туннеля заменяется отдельной таблицей пересылки; вместо того, чтобы обрабатывать пакет через одну и ту же таблицу дважды с использованием двух разных адресатов, пакет обрабатывается через две разные таблицы пересылки.
Термин туннель имеет много различных определений; в этих статьях туннель будет использоваться для описания виртуального канала, где внешний заголовок используется для инкапсуляции внутреннего заголовка, и:
Внутренний заголовок находится на том же уровне или более низком уровне, чем внешний заголовок (например, заголовок Ethernet, переносимый внутри заголовка IPv6; обычно IPv6 переносится внутри Ethernet).
По крайней мере, некоторые сетевые устройства на пути, будь то виртуальные или физические, пересылают пакет только на основе внешнего заголовка.
Переход от виртуальных интерфейсов к VRFs концептуально отличается достаточно, чтобы породить различные описательные термины. Underlay -это физическая (или потенциально логическая!) топология, через которую туннелируется трафик. Overlay - это набор туннелей, составляющих виртуальную топологию. В большинстве случаев термины Underlay и Overlay не используются с отдельными туннелями или в случае службы, работающей через общедоступный Интернет. Сервис, который создает виртуальную топологию через общедоступный Интернет, часто называют сервисом over-the-top.
Опять же, эти термины используются в некоторой степени взаимозаменяемо и даже очень небрежно в более широком мире сетевой инженерии. На этом фоне пора перейти к вариантам использования, чтобы узнать о наборе проблем, которые необходимо решить виртуализацией.
Предоставление услуг Ethernet по IP-сети.
Хотя приложения не должны создаваться с использованием подключения Ethernet в качестве базового, многие из них это делают. Например:
Некоторые поставщики систем хранения данных и баз данных строят свои устройства с предположением, что подключение Ethernet означает короткое расстояние и короткую задержку, или они проектируют системы поверх проприетарных транспортных протоколов непосредственно поверх кадров Ethernet, а не поверх пакетов интернет-протокола (IP).
Некоторые продукты виртуализации включают в свои продукты предположения о возможности подключения, такие как надежность кеширования Ethernet для IP-адресов для шлюза по умолчанию и других доступных мест назначения.
Для таких приложений требуется то, что выглядит как соединение Ethernet между устройствами (физическими или виртуальными), на которых работают различные узлы или копии приложения. Помимо этого, некоторые сетевые операторы считают, что запуск большого плоского домена Ethernet проще, чем запуск крупномасштабного IP-домена, поэтому они предпочли бы создавать самые большие домены Ethernet, которые они могут ("коммутация, где можно, маршрутизация, где необходимо", была распространенная поговорка в те времена, когда коммутация выполнялось аппаратно, а маршрутизация выполнялась программно, поэтому коммутация пакетов выполнялась намного быстрее, чем их маршрутизация). Некоторые кампусы также построены с основной идеей - никогда не просить устройство коммутировать свой IP-адрес после подключения. Поскольку пользователи могут быть подключены к разным сегментам Ethernet в зависимости от их домена безопасности, каждый сегмент Ethernet должен быть доступен в каждой точке беспроводного доступа и часто на каждом порте Ethernet в кампусе.
Учитывая сеть, основанную на IP, которая предполагает Ethernet как один из многих транспортных средств, поверх которых будет работать IP, как вы можете обеспечить подключение Ethernet к устройствам, связанным по IP-сети? На рисунке 3 показаны задачи, которые необходимо решить.
На рисунке 3 процесс, работающий на A с IP-адресом 2001:db8:3e8:100::1, должен иметь возможность взаимодействовать со службой, работающей на B с IP-адресом 2001:db8:3e8:100::2, как если бы они находились в одном сегменте Ethernet (две службы должны видеть друг друга в обнаружении соседей и т. д.). Чтобы сделать проблему более сложной, служба на A также должна иметь возможность перемещаться в K без изменения своего локального кэша обнаружения соседей или маршрутизатора по умолчанию. Сама сеть, является маршрутизируемой сетью, работающей под управлением IPv6.
Что необходимо для выполнения требований?
Должен быть способ передачи кадров Ethernet по IP-сети, разделяющей серверы. Обычно это будет своего рода туннельная инкапсуляция, как описано в начале этого раздела. Туннелирование позволило бы принимать кадры Ethernet на C, например, инкапсулированные в какой-то внешний заголовок, чтобы их можно было транспортировать по маршрутизируемой сети. Когда пакет, содержащий кадр Ethernet, достигает D, этот внешний заголовок может быть удален, и кадр Ethernet пересылается локально. С точки зрения D, фрейм имеет локальное происхождение.
Должен быть способ узнать о пунктах назначения, доступных через туннель, и привлечь трафик в туннель. На самом деле это две отдельные, но взаимосвязанные проблемы. Привлечение трафика в туннель может включать запуск второй плоскости управления с ее собственными VRFs или добавление дополнительной информации в существующую плоскость управления об адресах Ethernet Media Access Control (MAC), доступных на каждом пограничном маршрутизаторе.
Может потребоваться перенести маркировку качества обслуживания (QoS) из внутреннего заголовка во внешний заголовок, чтобы трафик обрабатывался правильно при его пересылке.
Виртуальный частный доступ к корпоративной сети.
Почти в каждой организации есть какие-то удаленные сотрудники, либо на полную ставку, либо просто люди, которые перемещаются, и у большинства организаций есть какие-то удаленные офисы, где часть сотрудников работает вдали от главного офиса, чтобы напрямую взаимодействовать с местным организациями в некоторых отраслях, например, с покупателями или поставщиками. Все эти люди по-прежнему нуждаются в доступе к сетевым ресурсам, таким как электронная почта, системы путешествий, файлы и т. д. Эти службы, конечно, не могут быть доступны в общедоступном Интернете, поэтому необходимо предоставить какой-то другой механизм доступа. На рисунке 4 показаны типичное проблемное пространство.
В этом варианте использования есть две основные проблемы:
Как можно защитить трафик между отдельным хостом - B - и тремя хостами в небольшом офисе - C, D и E - от перехвата и чтения злоумышленником? Как можно защитить сами адреса назначения от попадания в публичную сеть? Эти проблемы связаны с некоторой защитой, которая, в свою очередь, подразумевает некоторую форму инкапсуляции пакетов.
Как можно управлять качеством работы пользователей в этих удаленных местах для поддержки передачи голоса по IP и других приложений в реальном времени? Поскольку провайдеры в Интернете не поддерживают QoS, необходимо обеспечить другие формы гарантии качества.
Таким образом, задача, которую необходимо решить, включает еще две общие проблемы.
Должен быть способ инкапсулировать трафик, передаваемый по общедоступной сети, без раскрытия исходной информации заголовка и без подвергания информации, содержащейся в пакете, для проверки. Самым простым решением этих проблем является туннелирование (часто в зашифрованном туннеле) трафика от A и F к граничному маршрутизатору в сети организации G, где инкапсуляция может быть удалена, а пакеты перенаправлены на A.
Должен быть способ объявить достижимые пункты назначения от G к удаленным пользователям, а также существование (или достижимость) удаленных пользователей к G и сети позади G. Эта информация о достижимости должна использоваться для привлечения трафика в туннели. В этом случае плоскости управления может потребоваться перенаправить трафик между различными точками входа и выхода в общедоступную сеть и попытаться контролировать путь трафика через сеть, чтобы обеспечить удаленным пользователям хорошее качество работы.
Подведем итоги
Два варианта использования, показанные выше, актуализируют два вопроса, которые должно решить каждое решение сетевой виртуализации:
Как трафик инкапсулируется в туннель, чтобы можно было отделить пакеты и информацию плоскости управления от базовой сети?
Решением этой проблемы обычно является некоторая форма инкапсуляции, в которую помещается исходный пакет, когда он передается по сети. Основное внимание при инкапсуляции - поддержка аппаратной коммутации в базовой сети, чтобы обеспечить эффективную пересылку инкапсулированных пакетов. Второстепенным соображением является размер формата инкапсулирующего пакета; каждый октет дополнительного заголовка инкапсуляции уменьшает объем полезной нагрузки, которую туннель может нести (если нет разницы между максимальной единицей передачи или MTU в сети, предназначенной для учета дополнительной информации заголовка, налагаемой туннелированием).
Примечание
Path MTU Detection (PMTUD) часто плохо определяет MTU инкапсулированных пакетов. Из-за этого часто требуется ручная настройка MTU в точке наложения заголовка туннеля.
Как пункты назначения достигаются через туннель, объявленный через сеть?
В более общих туннельных решениях туннель становится "просто еще одним звеном" в общей топологии сети. Пункты назначения, доступные через туннель, и дополнительная виртуальная связь просто включены как часть плоскости управления, как и любые другие пункты назначения и каналы. В этих решениях существует одна таблица маршрутизации или пересылки в каждом устройстве, и рекурсивный поиск используется для обработки пакета посредством пересылки в точке, где трафик входит в туннель или головной узел туннеля. Трафик привлекается в туннель путем изменения метрик таким образом, чтобы туннель был более желательным путем через сеть для тех пунктов назначения, которые оператор сети хотел бы получить через туннель. Это обычно означает в основном ручные решения проблемы привлечения трафика в туннель, такие как установка метрики туннеля ниже пути, по которому проходит туннель, а затем фильтрация пунктов назначения, объявленных через туннель, чтобы предотвратить объявления пунктов назначения, которые должны быть недоступны через туннель. На самом деле, если пункты назначения, достижимые через туннель, включают конечную точку туннеля (хвост туннеля), может образоваться постоянная петля маршрутизации, или туннель будет циклически переключаться между правильной переадресацией трафика и не переадресацией трафика вообще.
В решениях с overlay и over-the-top развертывается отдельная плоскость управления (или передается отдельная база данных с информацией о доступности для адресатов, достижимых в underlay и overlay в единой плоскости управления). Пункты назначения, доступные через underlay и overlay, помещаются в отдельные таблицы маршрутизации (VRF) на головной станции туннеля, а таблица, используемая для пересылки трафика, основана на некоторой форме системы классификации. Например, все пакеты, полученные на конкретном интерфейсе, могут быть автоматически помещены в оверлейный туннель, или все пакеты с определенным классом обслуживания, установленным в их заголовках пакетов, или весь трафик, предназначенный для определенного набора пунктов назначения. Механизмы полного наложения и верхней виртуализации обычно не полагаются на метрики для привлечения трафика в туннель на головной станции.
Еще одно необязательное требование - обеспечить качество обслуживания либо путем копирования информации QoS из внутреннего заголовка во внешний заголовок, либо путем использования какой-либо формы проектирования трафика для передачи трафика по наилучшему доступному пути.
В данный момент на рынке представлено большое количество таких технологий виртуализации, как, например, OpenVZ, KVM и Xen. Вы, должно быть, встречались с этими терминами, если пытались купить виртуальный частный сервер (VPS). В статье мы сравним эти три технологии с точки зрения покупки VPS, чтобы вы могли выбрать наиболее подходящую вам технологию.
Обзор Виртуализации и Контейнеризации
Виртуализация – это технология, которая позволяет вам создавать несколько виртуальных машин (ВМ) на одном аппаратном обеспечении. В свою очередь каждая виртуальная машина представляет собой физический компьютер, на который вы можете установить операционную систему. Работу виртуальных машин контролирует гипервизор, который предоставляет им хостовые системные ресурсы: процессорные, оперативной памяти и устройств хранения.
Все ВМ изолированы друг от друга, то есть программное обеспечение одной ВМ не имеет доступ к ресурсам другой ВМ. Многие провайдеры VPS устанавливают гипервизор на физический сервер и предоставляют пользователям виртуальную машину в качестве виртуального частного сервера (VPS).
Контейнеризация сильно отличается от виртуализации. Вместо гипервизора на хост-систему устанавливается операционная система, на которой вы можете создавать «контейнеры». Внутри контейнеров вы можете создавать приложения, и уже ОС позаботится о выделении ресурсов каждому контейнеру. В этом случае ядро операционной системы и драйверы являются общими для всех контейнеров.
Таким образом, контейнеризация зависит от ОС. И, соответственно, в контейнере можно запускать только те программы, которые соответствуют хостовой ОС. Например, если контейнеризация работает на Linux как на хостовой ОС, внутри контейнера вы можете запускать приложения только на Linux. В этом отличие от виртуализации – в виртуальной машине вы можете запустить любую ОС и, соответственно, любое приложение. С другой стороны, контейнеризация намного более эффективна, чем виртуализация, так как не затрачивает лишнюю энергию на запуск ОС в каждой виртуальной машине.
В этой статье мы уделим внимание системной контейнеризации. Такой вид контейнеризации позволит вам запускать ОС внутри контейнера. Несмотря на это, ядро и драйверы по-прежнему являются общими для различных операционных систем внутри каждого контейнера.
Xen и KVM являются технологиями виртуализации, а OpenVZ – это технология контейнеризации на базе Linux.
OpenVZ
OpenVZ (Open Virtuozzo) – это платформа контейнеризации, базирующаяся на ядре Linux. Она позволяет на одной хост-системе запускать несколько ОС, также базирующихся на Linux. Контейнеры работают как независимая система Linux с правами доступа уровня root, изоляцией на уровне файлов, пользователей или групп, процессов и сетей.
Провайдеры серверов предоставляют контейнерам OpenVZ некоторое количество оперативной памяти, процессорных ядер и места на жестком диске и продают их в качестве виртуальных серверов Linux. Какая-то часть ресурсов ЦП и памяти выделена контейнеру, а какая-то часть ресурсов “разрывается”, то есть если контейнеру требуется больше ресурсов помимо того, что ему было выделено, он может временно заимствовать их из неиспользуемых ресурсов других контейнеров.
Так как при контейнеризации ядро является общим для всех контейнеров, изменить настройки ядра, обновить его или использовать дополнительные модули ядра невозможно. К моменту написание этой статьи большинство провайдеров используют OpenVZ 6 на базе Linux 2.6. Таким образом, вы не сможете улучшить функционирование системы и возможности ядра за счет обновлений. У вас так и останется старый дистрибутив Linux. И вы не сможете установить Docker или использовать утилиты ipset и nftables.
OpenVZ 7 – это самая последняя версия проекта с обновленным ядром. Однако очень немногие провайдеры предоставляют ее из-за сложности установки и нехватки вспомогательных инструментов.
В заключение, с точки зрения провайдера систему OpenVZ легко конфигурировать и запускать, в отличие от KVM и Xen. И так как это система на контейнеризации, она затрачивает намного меньше энергии, вследствие чего провайдеры могут предоставлять большее количество VPS с одного физического сервера.
Xen
Xen – это платформа виртуализации с открытым исходным кодом, которая первоначально начиналась как исследовательский проект в Кембриджском университете. В настоящее время в разработке проекта участвует Linux Foundation.
С помощью различных инструментов провайдер предоставляет виртуальным машинам Xen фиксированный объем оперативной памяти, процессорных ядер, места на жестком диске и IP-адресов и предлагает их в качестве VPS.
В целом гипервизоры делятся на два типа: 1 и 2. Гипервизор типа 1 работает непосредственно на хост-оборудовании, в то время как гипервизор типа 2 зависит от базовой операционной системы. Xen относится к гипервизору первого типа.
Так как Xen – технология виртуализации, созданные на ее основе ВМ могут работать на любой ОС, включая Linux, Windows и BSD. А поскольку каждая ВМ работает на своей операционной системе, вы можете обновить ядро, изменить его настройки или использовать дополнительные модули ядра.
Установка виртуализации несет за собой большой расход энергии на эмуляцию определенных аппаратных функций, а также на запуск операционной системы. Чтобы уменьшить расходы, Xen использует технику "паравиртуализация". В этом случае гипервизор использует альтернативные способы выполнения одних и тех же аппаратных операций более эффективным способом. Если гостевая ОС знает, как использовать эти альтернативные интерфейсы, она делает “гиперзвонок”, чтобы поговорить с гипервизором. Этот режим работы называется Xen Paravirtualization (Xen-PV).
Когда гостевая ОС поддерживает паравиртуализацию, используется другой режим виртуализации – Xen Hardware Virtual Machine (Xen-HVM). В этом случае Xen использует программу QEMU, чтобы обеспечить эмуляцию аппаратного обеспечения. Чтобы использовать Xen-HVM, аппаратная виртуализация должна быть обеспечена хост-системой.
KVM
KVM (Kernel Virtual Machine) – это модуль ядра Linux, который предоставляет платформу для сторонних инструментов (таких как QEMU) для обеспечения виртуализации. Поскольку это модуль ядра, KVM повторно использует многие функции ядра Linux для своих целей.
С точки зрения конечного пользователя Xen похож на KVM, поскольку он позволяет запускать любую ОС и работать с низкоуровневыми настройками ядра. Провайдеры серверов используют сторонние инструменты для создания виртуальных машин с фиксированным объемом оперативной памяти, ядрами ЦП, пространством жесткого диска и IP-адресами и предлагают их в качестве виртуальных машин. Иногда провайдеры VPS, использующие KVM, предоставляют пользователю возможность загрузить свой ISO-файл для установки на VPS.
KVM работает только на оборудовании, поддерживающем аппаратную виртуализацию. Подобно Xen, KVM также обеспечивает паравиртуализацию для устройств ввода-вывода через API «virtio».
Что же выбрать?
Выбор платформы зависит исключительно от ваших предпочтений. Если вы не хотите тратить много денег на Linux сервер и вас не беспокоит старая версия ядра и невозможность пользоваться такими программами, как Docker, то выбирайте OpenVZ. Если вам нужна еще другая ОС, например, Windows или вы хотите использовать обновленное ядро Linux, выбирайте KVM или Xen.
Многие провайдеры используют возможность OpenVZ «разрываться» и перегружают свои системы, вмещая как можно больше серверов на один хост. В случае, если слишком много серверов будет пользоваться центральным процессором и памятью одновременно, вы заметите значительное снижение уровня производительности своего сервера.
Есть провайдеры, которые рекламируют свои KVM и Xen как «специализированные ресурсы», но, к сожалению, это тоже не всегда правда. И KVM, и Xen предлагают функцию «раздувания памяти» («memory ballooning»), при которой ваша оперативная память может быть востребована другим VPS. В каждом VPS установлен драйвер (Balloon Driver), который помогает в этом процессе. Когда гипервизор забирает память у вашего VPS, создается впечатление, что драйвер не дает пользоваться вашей памятью. Однако VPS никогда не сможет получить больше памяти, чем ему было изначально выделено.
Таким образом, перегрузка возможна в случае со всеми тремя платформами. Однако провайдеры KVM/Xen перегружают их намного меньше, чем OpenVZ, из-за технических ограничений системы, основанной на гипервизоре.
Чтобы определить производительность сервера перед покупкой, следует пройти тест производительности (бенчмарк) с помощью приложений: bench.sh, speedtest-cli или Geekbench. К тому же, прежде чем покупать VPS, основанный на одной из технологий – OpenVZ, KVM или Xen, лучше сравнить цены и прочитать комментарии о компании. У провайдера с заниженными ценами или плохой репутацией независимо от технологии будет низкая производительность VPS.