По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В 2012 году Джим Роскинд разработал новый транспортный протокол, основной целью которого было увеличение скорости, с которой данные могут передаваться по относительно стабильным высокоскоростным сетям. В частности:
Сокращение трехстороннего рукопожатия до запуска одного пакета (нулевое рукопожатие)
Уменьшение количества повторно передаваемых пакетов, необходимых для передачи данных
Уменьшение блокировки заголовка между несколькими потоками данных в пределах одного потока TCP, вызванной потерей пакетов
Уменьшение рукопожатия при запуске
Как правило, значение rtt нельзя изменить, поскольку оно обычно ограничено физическим расстоянием и скоростью соединения между отправителем и получателем. Таким образом, один из лучших способов сократить общее время передачи данных - просто уменьшить количество циклов обмена, необходимых между отправителем и получателем для передачи заданного потока или блока данных. QUIC разработан для сокращения количества циклов приема-передачи, необходимых для установки нового соединения, от трехстороннего подтверждения TCP до процесса запуска с нулевым временем приема-передачи. Для этого QUIC использует серию криптографических ключей и хэшей; процесс состоит из:
Клиент отправляет серверу приветствие (CHLO), содержащее требование подтверждения, которое представляет собой список типов сертификатов, которые клиент примет для проверки идентичности сервера; набор сертификатов, к которым у клиента есть доступ; и хэш сертификата, который клиент намеревается использовать в этом соединении. Одно конкретное поле, маркер адреса источника (STK) будет оставлено пустым, потому что раньше с этим сервером не было связи.
Сервер будет использовать эту информацию для создания STK на основе информации, предоставленной в первоначальном приветствии клиента и исходном IP-адресе клиента. Сервер отправляет отклонение (REJ), которое содержит этот STK.
Как только клиент получает STK, он включает его в будущие пакеты приветствия. Если STK совпадает с ранее использованным STK с этого IP-адреса, сервер примет приветствие.
Примечание: Эта пара IP-адрес / STK может быть украдена, и, следовательно, исходный IP-адрес может быть подменен злоумышленником с доступом к любой связи с этой парой. Это известная проблема в QUIC, которая рассматривается в документации QUIC.
Для сравнения, TCP требует, как минимум полтора rtts для создания нового сеанса:
SYN, SYN-ACK, а затем следующий ACK. Сколько времени экономит при переходе на одно соединение rtt? Конечно, это зависит от реализации клиентского и серверного приложений. Однако многие веб-страницы и приложения для мобильных устройств должны подключаться к множеству разных серверов (возможно, к сотням) для создания единой веб-страницы. Если каждое из этих подключений уменьшить с полутора до одного RTT, это может значительно снизить производительность.
Сокращение повторных передач
QUIC использует ряд различных механизмов для уменьшения количества повторно передаваемых пакетов:
Включая Forward Error Correction (FEC) во все пакеты; это позволяет получателю (часто) восстанавливать поврежденную информацию, а не запрашивать ее повторно.
Использование отрицательных подтверждений (NACK) вместо SACK или механизма тройного ACK для запроса повторной передачи определенных порядковых номеров; это предотвращает неоднозначность между запросом на повторную передачу и условиями сети, которые вызывают отправку нескольких подтверждений.
Использование быстрых подтверждений, как описано ранее для TCP.
Использование управления окном предотвращения перегрузки CUBIC.
Механизм предотвращения перегрузки CUBIC - самый интересный из них. CUBIC пытается выполнить двоичный поиск между последним размером окна перед отбрасыванием пакета и некоторым меньшим размером окна, рассчитанным с использованием множительного коэффициента. Когда обнаруживается потеря пакета (либо через тайм-аут RTO, либо через NACK), максимальный размер окна (WMAX) устанавливается равным текущему размеру окна, и вычисляется новый минимальный размер окна (WMIN).
Окно отправителя устанавливается на WMIN, а затем быстро увеличивается до размера окна посередине между WMIN и WMAX. Как только окно достигает этой средней точки, размер окна очень медленно увеличивается при так называемом зондировании, пока не встретится следующий сброс пакета. Этот процесс позволяет CUBIC находить максимальную скорость передачи чуть ниже точки, в которой сеть начинает довольно быстро отбрасывать пакеты.
Исключение блокировки начала строки
"Единая транзакция" в Интернете часто является не "отдельной транзакцией", а скорее большим набором транзакций на нескольких разных серверах. Например, чтобы создать единую веб-страницу, сотни элементов, таких как изображения, скрипты, элементы каскадной таблицы стилей (CSS) и файлы языка гипертекстовой разметки (HTML), должны быть переданы с сервера на клиент. Эти файлы можно передавать двумя способами: последовательно или параллельно. Рисунок 1 иллюстрирует это.
На рисунке 1 показаны три варианта передачи нескольких элементов от сервера к клиенту:
В serialized варианте элементы передаются по одному в течение одного сеанса. Это самый медленный из трех возможных вариантов, так как вся страница должна быть построена поэлементно, при этом меньшие элементы ждут передачи больших, прежде чем их можно будет отобразить.
В варианте с несколькими потоками (multiple streams) каждый элемент передается через отдельное соединение (например, сеанс TCP). Это намного быстрее, но требует создания нескольких подключений, что может негативно повлиять на ресурсы клиента и сервера.
В мультиплексном (multiplexed) варианте каждый элемент передается отдельно через одно соединение. Это позволяет передавать каждый элемент с его собственной скоростью, но с дополнительными расходами ресурсов из-за опции нескольких потоков.
Некоторые формы механизма мультиплексной передачи имеют тенденцию обеспечивать максимальную скорость передачи при наиболее эффективном использовании ресурсов, но как это мультиплексирование должно быть реализовано? Протокол передачи гипертекста версии 2 (HTTPv2) позволяет веб-серверу мультиплексировать несколько элементов в одном сеансе HTTP; поскольку HTTP работает поверх TCP, это означает, что один поток TCP может использоваться для параллельной передачи нескольких элементов веб-страницы. Однако один отброшенный пакет на уровне TCP означает, что каждая параллельная передача в потоке HTTP должна быть приостановлена на время восстановления TCP.
QUICK решает эту проблему, позволяя нескольким потокам HTTP v2 находиться в одном быстром соединении. Это уменьшает транспортные издержки на клиенте и сервере, обеспечивая при этом оптимальную доставку элементов веб - страницы.
Обнаружение MTU пути
Одним из основных вопросов спора между асинхронным режимом передачи (ATM) и интернет-протоколом (IP) был фиксированный размер ячейки. В то время как IP-сети полагаются на пакеты переменной длины, ATM, чтобы обеспечить более высокую скорость коммутации и улучшить взаимодействие с множеством различных физических уровней Time Division Multiplexing (TDM), задал ячейки фиксированной длины. В частности, IPv4 обеспечивает не только пакет переменной длины, но и фрагментацию в процессе передачи. Рисунок 2 иллюстрирует это.
На рис. 2 показано, что если A посылает пакет в направлении E, то какого размера он должен быть? Единственный канал, о котором действительно знает А, - это канал между собой и В, которое помечено как имеющее максимальный размер блока передачи 1500 октетов (Maximum Transmission Unit- MTU). Однако если A отправляет пакет длиной 1500 октетов, то этот пакет не сможет пройти через канал [C,D]. Есть два способа решить эту проблему.
Первый заключается в том, что C фрагментирует пакет на два меньших пакета. Это возможно в IPv4; C может определить, что пакет не поместится на следующем канале, по которому пакет должен быть передан, и разбить пакет на два меньших пакета. Конечно, с этим решением есть ряд проблем. Например, процесс фрагментации пакета требует гораздо больше работы со стороны C, возможно, даже перемещение пакета из аппаратного пути коммутации в программный путь коммутации.
Во-вторых, A никогда не отправляет пакет, превышающий минимальный MTU, по всему пути к E. Для этого A должен определить минимальный MTU на пути, и он должен иметь возможность фрагментировать информацию, отправляемую из протоколов верхнего уровня на несколько пакетов перед передачей. IPv6 выбирает этот последний вариант, полагаясь на обнаружение Path MTU (PMTU), чтобы найти минимальный MTU на пути (при условии, что PMTU действительно работает), и позволяя процессу IPv6 в A фрагментировать информацию из протоколов верхнего уровня на несколько пакетов, которые затем повторно собираются в исходный блок данных верхнего уровня в приемнике.
Это решение, однако, также является проблемным. В недавней работе с системой доменных имен (DNS) исследователи обнаружили, что около 37% всех DNS- resolvers отбрасывают фрагментированные пакеты IPv6. Почему это происходит? Самый простой способ понять это-рассмотреть структуру фрагментированного пакета, а также природу DoS и DDoS атак.
При передаче пакета, в пакет помещается заголовок, указывающий принимающую услугу (номер сокета или протокола какого-либо рода), а также информацию о передаваемой услуге. Эта информация важна для фильтрации пакета на основе различных политик безопасности, особенно если политика безопасности гласит: "разрешать только пакеты инициации сеанса в сеть, если пакет не принадлежит существующему сеансу." Другими словами, типичный фильтр с отслеживанием состояния, защищающий сервер, будет иметь некоторые основные правила, которым он следует:
Если пакет инициирует новый сеанс, пересылайте его и создайте новую запись сеанса.
Если пакет является частью существующего сеанса, перенаправьте его и сбросьте таймер сеанса.
Если пакет не является частью существующего сеанса, отбросьте его.
Время от времени очищайте старые сеансы.
Возможно подделать пакет, похожий на настоящий, но это очень сложно, т.к. используются различные nonce и другие методы, чтобы препятствовать подобному поведению. Но фрагментация пакета удаляет заголовок из второй половины пакета, что фактически означает, что второй пакет во фрагментированной паре может быть присоединен только к определенному сеансу или потоку, отслеживая часть пакета, которая имеет полный заголовок.
Как маршрутизатор или middlebox могут выполнить это? Он должен каким-то образом хранить копию каждого фрагмента пакета с заголовком где-нибудь в памяти, чтобы на пакет с заголовком можно было ссылаться для обработки любых будущих фрагментов. Как долго он должен хранить эти фрагменты с заголовками? На это нет ответа. Проще просто отбросить любые фрагменты, чем поддерживать состояние, необходимое для их обработки.
Каков результат? Похоже, что даже фрагментация на основе исходного кода не очень полезна на уровне IP.
Это должно напомнить об одном из основополагающих принципов пакета Интернет-протоколов: end-to-end принципе. End-to-end принцип гласит, что сеть не должна изменять трафик, передаваемый между двумя оконечными устройствами; или, скорее, сеть должна работать как черный ящик, соединяющий два устройства, никогда не изменяя данные, полученные от конечного хоста.
Означает ли это, что вся фильтрация трафика должна быть запрещена в общедоступном Интернете, всерьез навязывая end-to-end правило, оставляя всю безопасность конечным хостам?
Это представляет собой первоначальное обсуждения фильтрации пакетов в IPv6 с отслеживанием состояния. Однако это менее реалистичный вариант; более сильная защита - это не один идеальный файрволл, а скорее серия неидеальных файрволлов.
Другая альтернатива - принять еще одну частичку реальности, о которой часто забывают в мире сетевой инженерии: утечка абстракций. Сквозной принцип описывает идеально абстрактную систему, способную передавать трафик от одного хоста к другому, и совершенно абстрагированный набор хостов, между которыми переносится трафик. Но утекают все нетривиальные абстракции; проблема MTU и фрагментации - это просто утечка состояния из сети в хост, а система на хосте пытается абстрагировать эту утечку в приложение, отправляющее трафик по сети. В такой ситуации лучше всего просто признать утечку и официально отправить информацию в стек, чтобы приложение могло лучше принять решение о том, как отправлять трафик.
Другая альтернатива-принять еще одну частицу реальности, часто забываемую в мире сетевой инженерии: утечку абстракций. Сквозной принцип описывает идеально абстрагированную систему, способную передавать трафик от одного хоста к другому, и идеально абстрагированный набор хостов, между которыми осуществляется трафик. Но все нетривиальные абстракции протекают; проблема MTU и фрагментации-это просто утечка состояния из сети в хост, и система на хосте пытается абстрагировать эту утечку в приложение, отправляющее трафик по сети. В такой ситуации, возможно, лучше всего просто признать утечку и официально продвинуть информацию вверх по стеку, чтобы приложение могло принять лучшее решение о том, как отправлять трафик.
Но это приводит к еще одному интересному вопросу для размышления: является ли описанная здесь фильтрация состояний предательством end-to-end принципа? Ответ зависит от того, считаете ли вы протокол верхнего уровня, отправляющий данные, конечной точкой, или систему, на которой работает приложение (следовательно, включая сам стек IP), конечной точкой. Так или иначе, эта двусмысленность преследовала Интернет с самых ранних дней, хотя мир сетевой инженерии не всегда серьезно задумывался о разнице между этими двумя точками зрения.
ICMP
Хотя транспортные протоколы, такие как TCP и QUIC, обычно привлекают наибольшее внимание среди протоколов среднего уровня, существует ряд других протоколов, которые не менее важны для работы сети на основе IP. Среди них - протокол ICMP, который, можно сказать, предоставляет метаданные о самой сети. ICMP - это простой протокол, который используется для запроса информации о конкретном состоянии или для отправки сетевыми устройствами информации о том, почему определенный пакет отбрасывается в какой-либо точке сети. В частности:
ICMP может использоваться для отправки эхо-запроса или эхо-ответа. Эта функция используется для проверки связи с конкретным адресом назначения, который можно использовать для определения доступности адреса без использования слишком большого количества ресурсов на приемнике.
ICMP можно использовать для отправки уведомления об отброшенном пакете из-за того, что он слишком велик для передачи по каналу (слишком большой пакет).
ICMP может использоваться для отправки уведомления о том, что пакет был отброшен, поскольку его время жизни (TTL) достигло 0 (срок действия пакета истек при передаче).
Ответ на слишком большой пакет можно использовать для определения максимального размера передаваемого блока (MTU) в сети; отправитель может передать большой пакет и дождаться, чтобы увидеть, не отправит ли какое-либо устройство в сети уведомление о слишком большом пакете через ICMP. Если такое уведомление приходит, отправитель может попробовать постепенно уменьшать пакеты, чтобы определить самый большой пакет, который может быть передан из конца в конец по сети.
Ответ с истекшим транзитом может использоваться для отслеживания маршрута от источника до пункта назначения в сети (это называется трассировкой маршрута). Отправитель может передать пакет в конкретное место назначения, используя любой протокол транспортного уровня (включая TCP, UDP или QUIC), но с TTL равным 1. Сетевое устройство первого перехода должно уменьшить TTL и отправить обратно ICMP-сообщение с истекшим сроком действия в транзитном уведомлении отправителю. Отправляя серию пакетов, каждый с TTL на один больше, чем предыдущий, каждое устройство на пути может быть вынуждено передать отправителю сообщение ICMP с истекшим сроком действия в транзитном уведомлении, открывая весь путь пакета.
В данной статье мы рассмотрим, что такое Terraform и для чего он нужен.
1.Обзор
Terraform – Open Source проект от HashiCorp создан в 2014 году. Является превосходным инструментом для создания Инфраструктуре в коде (Infrastructure as a Code). Проект абсолютно бесплатный и можно даже скомпилировать его из исходников, изменить его, т.е полностью открытый проект. Данный продукт является превосходным инструментом для создания инфраструктуры в коде. Сайт продукта https://www.terraform.io.
И так, что это такое? Язык программирования инфраструктуры в cloud, не важно какой cloud. AWS, Google Cloud, Microsoft Azure, Digital Ocean, Yandex, AliCloud и есть поддержка многого другого, в том числе плагины под VMware. С помощью данного программного обеспечения можно даже управлять репозиторием Git Hub. Данный продукт является отличным для написания IaaS кода.
Синтаксис кода пишется на Hashicorp Configuration Language (HCL). Файлы, содержащие написанный вами код, должны иметь расширение tf. Это обычные текстовые файлы на программном языке. Можно использовать любой текстовый редактор с дополнительными плагинами для Terraform, чтобы система подсказывала, поправляла, давала подсветку или раскрашивала код для удобства, чтения. Очень удобный для этой цели использовать текстовый редактор Atom. Код после написания не требует никакой компиляции, т.е просто пишите свой текстовый файл на HCL и запускаете просто с помощью Terraform. Terraform работает на Windows, MacOS, Linux, т.к он написан на языке Go, компилируете под операционную систему и запускаете, где угодно.
Если рассмотреть конкурентов, то это AWS CloudFormation – инструмент для написания кода для AWS, он не кроссплатформенный и позволяет писать код только для AWS. Следующий конкурент Ansible - с помощью него тоже можно создавать инфраструктуру, через код, но он на мой взгляд слишком громоздкий и не очень удобный. Есть еще Puppet и Chef. Вот самые популярные инструменты конкуренты для создания инфраструктуры из кода.
2. Установка на Windows
Установка на операционную систему MS Windows достаточна простая. Переходим на основной сайт продукта и выбираем операционную систему MS Windows нужной разрядности нажимаем, скачиваем. После закачки мы получим файл в zip архиве. Распаковываем и получаем файл terraform.exe. В принципе этого для работы достаточно, но неудобно. В такой конфигурации необходимо каждый раз вводить путь к файлу terraform.exe. Чтобы этого избежать необходимо добавить путь в переменные среды Windows. В операционной системе Windows 10 нажимаем правой кнопкой Пуск, выбираем Система, в открывшемся окне слева выбираем Сведения о cистеме, далее переходим на вкладку Дополнительно, далее внизу кнопка Переменные среды. В нижнем окне создаем новую переменную terraform и путь к месту, где лежит файл.
3. Установка в Linux
Установка Terraform на Linux происходит не сложнее, чем на Windows. Открываем в браузере официальный сайт, выбираем разрядность Linux и копируем адрес ссылки на файл в буфер обмена. Открываем Terminal. Создаем или переходим в нужную директорию mkdir terraform или cd /tmp. Скачиваем wget URL и в директории появляется нужный файл.
Распаковываем unzip terraform_0.15.1_linux_amd64.zip. В результате распакуется один исполняемый файл terraform. Осталось перенести файл откуда он будет запускаться с любой директории sudo mv terraform /bin. Директория с бинарными файлами. После этого мы можем вызывать терраформ из любого места командой terraform.
В данный момент на рынке представлено большое количество таких технологий виртуализации, как, например, 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.