Работа с виртуальными машинами KVM. Введение
Как и обещал, начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе KVM.
В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.
Debian
Почему Debian? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.
Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.
Мы же, повторюсь, решили использовать Debian Squeeze с набором пакетов из Sid/Experimental и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
В планах имеется публикация репозитория с пакетами.
При выборе технологии виртуализации рассматривались два варианта — Xen и KVM.
Замечу, что лично я не очень хорошо знаю Xen, его архитектуру и уж тем более мелкие особенности — в основном я знакомился с ним в качестве гостя. Нет повода сказать, что Xen чем-то плох (потому, что он ещё не полностью вошёл в ядро, или у него что-то не так с производительностью, или еще по какой-то причине). Ничего определённого нельзя сказать и в плане производительности: в каких-то тестах KVM на 10-20 процентов опережает Xen по всем показателям, а где-то выигрывает Xen. Фактически, на текущий момент они практически сравнялись по функционалу, производительности, надёжности. И в принципе, не за горами тот день, когда Xen также войдёт в ядро. Уже вошёл в состав ядра virtually-a-machine.blogspot.com/2011/06/xen-support-in-mainline-linux-kernel.html.
Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen — тем интереснее было провести в жизнь решение именно на базе KVM.
Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.
libvirt
Для управления виртуальными машинами оказалось чрезвычайно удобно использовать libvirt и продукты, использующие ее API: virsh, virt-manager, virt-install, пр.
libvirt — это система, которая хранит настройки виртуальных машин, управляет ими, ведёт по ним статистику, следит за тем, чтобы при старте у виртуальной машины поднимался интерфейс, подключает устройства к машине — в общем, выполняет кучу полезной работы и еще немножко сверх того.
Разумеется, решение не идеально. Из минусов libvirt следует назвать:
cgroups
Основной проблемой в реализации услуги в самом начале представлялось лимитирование ресурсов для виртуальных машин. В Xen эта проблема была решена при помощи внутреннего шедулера, распределяющего ресурсы между виртуальными машинами — и что самое прекрасное, была реализована возможность лимитировать и дисковые операции в том числе.
В KVM ничего такого не было до появления механизма распределения ресурсов ядра cgroups. Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup, в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.
Профит в том, что всё это реализуется внутри ядра, и использовать это можно не только для сервера, но и для десктопа (что и использовали в известном «The
200 Line Linux Kernel Patch That Does Wonders»). И на мой взгляд, это одно из самых значительных изменений в ветке 2.6, не считая любимого #12309, а не запиливание очередной файловой системы. Ну, разве что, кроме POHMELFS (но чисто из-за названия).
libguestfs
Отношение к этой библиотеке-утилите у меня весьма неоднозначное.
С одной стороны это выглядит примерно так:
И ещё эту штуку чертовски сложно собрать из исходников и тем более в пакет: иногда мне кажется, что Linux From Scratch собрать с нуля несколько проще.
С другой стороны — очень мощная штука, которая позволяет создавать образы для виртуальных машин, модифицировать их, ужимать, ставить grub, модифицировать таблицу разделов, управлять конфигурационными файлами, переносить «железные» машины в виртуальную среду, переносить виртуальные машины с одного образа на другой, переносить виртуальные машины из образа на железо и, честно говоря, тут меня фантазия немного подводит. Ах, да: ещё можно запустить демон внутри виртуальной машины Linux и получить доступ к данным виртуальной машины вживую, и всё это делать на shell, python, perl, java, ocaml. Это краткий и далеко не полный список того, что можно сделать с libguestfs.
Интересно, что большая часть кода в libguestfs генерируется в момент сборки, равно как и документация к проекту. Очень широко используется ocaml, perl. Сам код пишется на C, который потом оборачивается в OCaml, и повторяющиеся куски кода генерируются сами. Работа с образами осуществляется путём запуска специального сервисного образа (supermin appliance), в который через канал внутрь него отправляются команды. Внутри этого образа содержится некоторый rescue набор утилит, таких как parted, mkfs и прочих полезных в хозяйстве системного администратора.
Я с недавнего времени его даже дома стал использовать, когда выковыривал из образа nandroid нужные мне данные. Но для этого требуется ядро с поддержкой yaffs.
Прочее
Ниже приведено ещё несколько интересных ссылок на описание использованных пограммных средств — почитать и поизучать самостоятельно, если интересно. Например, про утилиту для массовой работы с конфигурационными файлами, KVM best practices от товарищей из IBM. Рекомендую!
В следующей части
Следующая часть будет про установку необходимых программ, и их базовую настройку.
Общие принципы работы QEMU-KVM
Мое текущее понимание:
1) KVM
KVM (Kernel-based Virtual Machine) – гипервизор (VMM – Virtual Machine Manager), работающий в виде модуля на ОС Linux. Гипервизор нужен для того, чтобы запускать некий софт в несуществующей (виртуальной) среде и при этом, скрывать от этого софта реальное физическое железо, на котором этот софт работает. Гипервизор работает в роли «прокладки» между физическим железом (хостом) и виртуальной ОС (гостем).
Поскольку KVM является стандартным модулем ядра Linux, он получает от ядра все положенные ништяки (работа с памятью, планировщик и пр.). А соответственно, в конечном итоге, все эти преимущества достаются и гостям (т.к. гости работают на гипервизоре, которые работает на/в ядре ОС Linux).
KVM очень быстрый, но его самого по себе недостаточно для запуска виртуальной ОС, т.к. для этого нужна эмуляция I/O. Для I/O (процессор, диски, сеть, видео, PCI, USB, серийные порты и т.д.) KVM использует QEMU.
2) QEMU
QEMU (Quick Emulator) – эмулятор различных устройств, который позволяет запускать операционные системы, предназначенные под одну архитектуру, на другой (например, ARM –> x86). Кроме процессора, QEMU эмулирует различные периферийные устройства: сетевые карты, HDD, видео карты, PCI, USB и пр.
Инструкции/бинарный код (например, ARM) конвертируются в промежуточный платформонезависимый код при помощи конвертера TCG (Tiny Code Generator) и затем этот платформонезависимый бинарный код конвертируется уже в целевые инструкции/код (например, x86).
ARM –> промежуточный_код –> x86
По сути, вы можете запускать виртуальные машины на QEMU на любом хосте, даже со старыми моделями процессоров, не поддерживающими Intel VT-x (Intel Virtualization Technology) / AMD SVM (AMD Secure Virtual Machine). Однако в таком случае, это будет работать весьма медленно, в связи с тем, что исполняемый бинарный код нужно перекомпилировать на лету два раза, при помощи TCG (TCG – это Just-in-Time compiler).
Т.е. сам по себе QEMU мега крутой, но работает очень медленно.
3) Protection rings
Бинарный программный код на процессорах работает не просто так, а располагается на разных уровнях (кольцах / Protection rings) с разными уровнями доступа к данным, от самого привилегированного (Ring 0), до самого ограниченного, зарегулированного и «с закрученными гайками» (Ring 3).
Операционная система (ядро ОС) работает на Ring 0 (kernel mode) и может делать с любыми данными и устройствами все, что угодно. Пользовательские приложения работают на уровне Ring 3 (user mode) и не в праве делать все, что захотят, а вместо этого каждый раз должны запрашивать доступ на проведение той или иной операции (таким образом, пользовательские приложения имеют доступ только к собственным данным и не могут «влезть» в «чужую песочницу»). Ring 1 и 2 предназначены для использования драйверами.
До изобретения Intel VT-x / AMD SVM, гипервизоры работали на Ring 0, а гости работали на Ring 1. Поскольку у Ring 1 недостаточно прав для нормального функционирования ОС, то при каждом привилегированном вызове от гостевой системы, гипервизору приходилось на лету модифицировать этот вызов и выполнять его на Ring 0 (примерно так, как это делает QEMU). Т.е. гостевой бинарный код НЕ выполнялся напрямую на процессоре, а каждый раз на лету проходил несколько промежуточных модификаций.
Накладные расходы были существенными и это было большой проблемой и тогда производители процессоров, независимо друг от друга, выпустили расширенный набор инструкций (Intel VT-x / AMD SVM), позволяющих выполнять код гостевых ОС НАПРЯМУЮ на процессоре хоста (минуя всякие затратные промежуточные этапы, как это было раньше).
4) QEMU-KVM
KVM предоставляет доступ гостям к Ring 0 и использует QEMU для эмуляции I/O (процессор, диски, сеть, видео, PCI, USB, серийные порты и т.д., которые «видят» и с которыми работают гости).
Отсюда QEMU-KVM (или KVM-QEMU) 🙂
P.S. Текст этой статьи изначально был опубликован в Telegram канале @RU_Voip в качестве ответа на вопрос одного из участников канала.
Напишите в комментариях, в каких местах я не правильно понимаю тему или если есть, что дополнить.
Битва гипервизоров: VMware или KVM?
Гипервизоры (технологии виртуализации) существуют более 30 лет и за это время сумели стать одним из главных «винтиков» в составе облачной экосистемы.
Многие компании, подбирающие решения для виртуализации, останавливают свой выбор на двух популярных гипервизорах — VMware и KVM. Предлагаем разобраться какой же из них лучше. Но для начала немного теории:
Что такое гипервизор? Гипервизор — это программа, отделяющая операционную систему от железа. Гипервизоры виртуализируют ресурсы сервера (процессор, память, диск, сетевые интерфейсы и др.), позволяя использовать их как свои собственные, и создают на основе одного сервера несколько отдельных виртуальных машин. Каждая созданная виртуальная машина изолируется от соседей, чтобы не влиять на работу других. Для работы гипервизора необходима поддержка виртуализации: для процессоров Intel на процессоре Intel VT, а для процессоров AMD на AMD-V.
Гипервизоры делятся на два типа: первые работают непосредственно с сервером, а операционная система пользователей работает поверх гипервизора. Эти гипервизоры могут предоставлять некоторым пользователям функции управления сервером и большинство предприятий используют именно такие гипервизоры.
Гипервизоры второго типа, также известные как размещенные гипервизоры (Hosted Hypervisor), работают с операционной системой, установленной на сервере. А операционные системы для новых пользователей создаются поверх гипервизора.
Настольные гипервизоры, такие как Oracle VirtualBox или VMware Workstation, являются гипервизорами второго типа, а VMware и KVM – первого. VMware и KVM устанавливаются непосредственно на сервер и не требуют установки какой-либо операционной системы.
VMware vSphere
Перед покупкой VMware vSphere можно попробовать поработать в пробной версии (60 дней), после чего необходимо покупать лицензию, либо мириться с ограничениями бесплатной версии.
В бесплатной версии, которая называется VMware Free vSphere Hypervisor, нет ограничений для хоста по процессорам и памяти, зато есть ряд других:
Продукт от VMware отличается от аналогов поддержкой большого количества операционных систем — Windows, Linux, Solaris, FreeBSD, Netware, MacOS и других.
Установка дистрибутива VMware на сервер очень проста: достаточно загрузиться с CD, флешки или через PXE. К тому же поддерживаются сценарии, позволяющие автоматизировать процесс инсталляции программного обеспечения, настройку сети и подключения к vCenter Server.
Немаловажно и наличие специального конвертера VMware vCenter Converter, позволяющего использовать в ESXi образы MS Virtual Server, Virtual PC, Hyper-V, а также физические серверы и образы дисковых разделов, созданных такими программами как Acronis True Image, Norton Ghost и другими.
У VMware vSphere есть встроенная интеграция с Microsoft Active Directory, то есть аутентификацию пользователей в частном или гибридном облаке можно производить при помощи доменных служб Microsoft. Гибкое распределение ресурсов позволяет использовать горячее добавление CPU, ОЗУ и жесткого диска (в том числе изменять размер текущего жесткого диска без перезагрузки).
VMware Fault Tolerate — технология VMware, предназначенная для защиты виртуальных машин с помощью кластеров непрерывной доступности. При отказе хоста (сервера ESXi) с основной (Primary) рабочей копией виртуальной машины, защищенная виртуальная машина мгновенно переключится на «вторичную» (Secondary) или «теневую» копию, работающую на другом сервере ESXi. Для машин, защищенных VMware Fault Tolerance, происходит постоянное (в реальном времени) копирование всего состояния памяти и процессорных инструкций с основной копии на «теневую». При сбое основного хоста ESXi, пользователи даже не заметят процесса переключения на второй узел. Именно этим Fault Tolerance отличается от High Availability. В High Availability при отказе физического сервера виртуальные машины будут перезапущены на других узлах, и пока операционные системы перезагружаются пользователи не смогут получить доступ к виртуальным серверам.
Кроме VMware Foult Tolerate, лицензия VMware vCloud Suite Enterprise обеспечивает высокую доступность, отказоустойчивость и восстановление после аварий с помощью функций vSphere HA, vMotion, Storage vMotion, и vCenter Site Recovery Manager.
Для уменьшения плановых остановок в обслуживании серверов или систем хранения данных (СХД), функции vMotion и Storage vMotion в онлайн-режиме переносят виртуальные машины и их диски без остановки работы приложений и пользователей. Функция vSphere Replication поддерживает разные варианты репликации vCenter Site Recovery Manager (SRM) для защиты от крупных аварий. SRM обеспечивает централизованное планирование послеаварийного восстановления, автоматические Failover и Failback с резервного сайта или из облака vCloud, а также тестирование послеаварийного восстановления без прерывания работы приложений.
К особенностям этого гипервизора стоит отнести избирательность к железу — перед установкой необходимо тщательно проверить имеющееся оборудование на совместимость с нужной версией ESXi. Для этого на сайте VMware есть специальная страница.
Лицензирование продуктов VMware имеет свои особенности. Дополнительную путаницу добавляют периодические изменения (от версии к версии vSphere) в лицензионной политике VMware. Существует несколько пунктов, которые нужно учесть перед приобретением лицензий VMware vSpere:
Управлять множеством хостов с гипервизорами ESXi, СХД и сетевым оборудованием можно с помощью еще одного продукта VMware — Vcenter Server. Подключаемые модули клиента vSphere, предоставляемые партнерами VMware, дают IT-администраторам возможность управлять сторонними элементами в дата-центре непосредственно из этой консоли. Поэтому пользователи vCenter могут выполнять резервное копирование, защищать данные, управлять серверами, сетями и безопасностью непосредственно из интерфейса vCenter. В этой же консоли можно настроить триггеры, которые оповестят о возникших проблемах, и получить данные о работе всей инфраструктуры в виде графиков или таблиц.
KVM — простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. Он позволяет за минимальные сроки развернуть площадку виртуализации и организовать виртуализацию под управлением операционной системы Linux. В процессе работы KMV осуществляет доступ к ядру операционной системы через специальный модуль (KVM-Intel или KVM-AMD). Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые разные процессоры и гостевые операционные системы, в том числе Linux, BSD, Solaris, Windows и др. Кстати, все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно этот гипервизор.
Поскольку гостевые операционные системы взаимодействуют с гипервизором, который интегрирован в ядро Linux, у гостевых операционных систем есть возможность обращаться напрямую к оборудованию без нужды изменения гостевой операционной системы. За счет этого замедления работы гостевой операционной системы почти не происходит.
KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и другие образы, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другое железо.
Благодаря поддержке немодифицированных образов VMware, физический сервер можно легко виртуализовать при помощи все той же утилиты VMware vServer Converter, а затем перенести полученный файл в гипервизор.
Установка KVM в операционной системе Linux заключается в инсталляции пакета KVM и библиотеки виртуализации Libvirt, а также в тщательной настройке среды виртуализации. В зависимости от используемой на хосте операционной системы необходимо настроить мост или подключение к VNC-консоли, с помощью которой виртуальные машины будут взаимодействовать с хостом.
Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сетевым интерфейсам отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС.
Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту Virsh, реализующую все необходимые функции. Для удобного управления виртуальными машинами можно дополнительно установить пакет Virt-Manager.
У KVM нет встроенных инструментов, подобных Fault Tolerate для VMware, поэтому единственный способ создать кластер высокой доступности — использовать сетевую репликацию при помощи DRDB. Кластер DRBD поддерживает только два узла, а узлы синхронизируются без шифрования. То есть для более безопасной связи необходимо использовать VPN-соединение.
Кроме того, для построения кластера высокой доступности понадобится программа Heartbeat, которая позволяет обмениваться служебными сообщениями о своем состоянии узлам в кластере, и Pacemaker — менеджер ресурсов кластера.
Гипервизор KVM распространяется как продукт с открытым исходным кодом, а для корпоративных пользователей существует коммерческое решение Red Hat Virtualization (RHEL), основанное на KVM и платформе управления виртуальной инфраструктурой oVirt.
Несомненным преимуществом этого гипервизора является то, что он способен работать на любом сервере. Гипервизор довольно неприхотлив к ресурсам, что позволяет с легкостью использовать его для задач тестирования.
Следует учесть, что у KVM нет службы поддержки. Если что-то не получится, можно рассчитывать на форумы и помощь сообщества. Или перейти на RHEL.
Так что же выбрать?
Оба гипервизора являются зрелыми, надежными, высокопроизводительными системами виртуализации, у каждой из которых есть свои особенности, которые нужно учитывать при выборе.
KVM обычно более масштабируем, чем VMware, в первую очередь потому что vSphere имеет некоторые ограничения на серверы, которыми он может управлять. Кроме того, VMware добавила большое количество сетей хранения данных (SAN) для поддержки различных поставщиков. Эта функция означает, что VMware имеет больше вариантов хранения, чем KVM, но также усложняет поддержку хранилища VMware при расширении.
KVM обычно является наиболее популярным гипервизором для компаний, которые стремятся сократить стоимость внедрения и менее заинтересованы в функциях корпоративного уровня.
Исследования показали, что совокупная стоимость владения KVM, как правило, на 39 процентов ниже, чем у VMware, хотя фактическая совокупная стоимость владения зависит от специфичных факторов, таких как эксплуатационные параметры и рабочая нагрузка площадки.
Тесная интеграция с операционной системой на хосте является одной из наиболее распространенных причин, по которой разработчики выбирают KVM. Особенно те, кто использует Linux. Включение KVM во многие дистрибутивы Linux также делает его удобным выбором для разработчиков.
Облачные провайдеры, предлагающие своим клиентам услуги по модели IaaS, обычно выбирают инфраструктуру, построенную на продуктах VMware. Решения на основе VMware Sphere содержат все важные корпоративные функции по обеспечению высокой и непрерывной доступности, обеспечивают поддержку большего числа гостевых операционных систем и имеют возможность сопряжения инфраструктуры заказчика с облачными сервисами.
Что такое виртуализация серверов
Зачем нужна виртуализация
Виртуализацию используют для таких целей:
Какими бывают типы виртуализации
Все VPS/VDS-серверы работают на основе технологии виртуализации. С точки зрения реализации технологии, виртуализацию можно разделить на:
На виртуальной машине находится своя собственная операционная система, называемая гостевой. Операционная система, работающая на физическом сервере, называется хост-системой.
Гипервизор применяется и при программной, и при аппаратной виртуализации.
Программная виртуализация
Разделение ресурсов сервера осуществляется средствами операционной системы, и все виртуальные машины используют общее программное ядро.
Требование программной виртуализации: гостевая ОС должна быть одинакова с хост-системой.
Схема работы программной виртуализации
Аппаратная виртуализация
При аппаратной виртуализации на сервере-хосте устанавливается обычная операционная система и создаются полностью изолированные друг от друга виртуальные машины, каждая из которых имеет свою собственную полноценную ОС и использует в работе ее ядро.
При аппаратной виртуализации гостевая операционная система не обязательно должна совпадать с ОС-гипервизором.
Для ускорения работы аппаратной виртуализации используется паравиртуализация, принцип действия которой основан на том, что гостевая операционная система “знает”, что работает внутри виртуальной машины и может пользоваться некоторыми функциями, предоставляемыми гипервизором. Это ускоряет работу системы за счет того, что ей не приходится эмулировать работу всей виртуальной машины.
Полноценная поддержка паравиртуализации со стороны гостевых ОС есть в системах с открытым исходным кодом, таких, как Linux.
Схема работы паравиртуализации
Решения для виртуализации и их особенности
Рынок решений виртуализации предлагает различные варианты.
Они могут быть платными и бесплатными, различаться:
Рассмотрим популярные системы виртуализации, их преимущества и недостатки.
OpenVZ
Популярна у хостинг-провайдеров для дешевых тарифов виртуальных серверов.
VPS/VDS-серверы на OpenVZ нестабильны в работе из-за неравномерного распределения ресурсов между отдельными виртуальными машинами.
Провайдеры часто практикуют на этой платформе оверселлинг, то есть запускают на одном физическом сервере слишком большое количество виртуальных серверов, что приводит к недостатку ресурсов и медленной работе.
Virtuozzo
Система стоит дорого, но все недостатки, описанные выше для бесплатной версии OpenVZ, сохраняются.
Аппаратная система виртуализации обеспечивает полноценное выделение ресурсов для виртуальной машины, что гарантирует большую стабильность работы и затрудняет оверселлинг.
Для работы KVM требует на сервере центральный процессор с поддержкой виртуализации.
XEN обеспечивает стабильное и гарантированное выделение ресурсов для виртуальных машин, как и KVM. Их достоинства идентичны. Для ядра хост-системы Linux XEN поставляется в виде отдельного модуля, соответственно, требуется перекомпиляция ядра.
Hyper-V
Как коммерческая система требует оплату за лицензию на использование.
VMWare
Бесплатная версия VMWare рекомендуется для владельцев выделенных серверов, которые хотят самостоятельно создавать VPS/VDS на своем физическом сервере.
В бесплатной версии отсутствуют некоторые возможности, например, создание кластеров, миграции сетевых хранилищ и т.п. Для индивидуального использования это неплохое решение.
Лицензия на использование платной версии VMWare достаточно дорогая, поэтому, как правило, провайдеры хостинга не применяют ее для услуги “виртуальный сервер”.
Какую технологию виртуализации выбрать
Если вы выбираете VPS/VDS
Мы советуем выбирать провайдеров, которые применяют системы виртуализации KVM и XEN, обеспечивающих максимальную стабильность и бесперебойную работу виртуальных серверов.
Провайдеры строят свою инфраструктуру на основе какого-то одного из этих решений и выбора пользователю не предоставляют.
Что касается OpenVZ, то ее используют на самых дешевых тарифах VDS. Для задачи хостинга сайтов их можно заменить дорогим тарифом обычного виртуального хостинга, который будет работать более стабильно.
OpenVZ подходит только для тех пользователей, которым обязательно нужен свой отдельный виртуальный сервер за минимальную цену и не слишком важна гарантия доступности ресурсов.
Этот вариант категорически не подходит тем пользователям, которым необходим полноценный сервер и определенные компоненты ядра Linux, например, драйвер аудио или модули криптографии.
Большинство хостеров сейчас уже не предлагают решения на базе OpenVZ.
Чтобы выбрать провайдера с нужной технологией виртуализации для своего выделенного сервера, воспользуйтесь рейтингами хостеров, применяющих OpenVZ, KVM и XEN.
Если вы создаете VPS/VDS на выделенном сервере
Для выделенного сервера стоит использовать одну из технологий аппаратной виртуализации.
Выбор между KVM и XEN для платформы Linux будет зависеть от того, с какой из этих систем лучше знаком заказчик или системные администраторы его организации.
Также для выделенного сервера можно рассмотреть применение коммерческой системы VMWare, которая предлагает высокую надежность и поддержку со стороны производителя.
Для серверов, ориентированных на платформу Windows, самым логичным решением будет использование гипервизора Hyper-V.
Комментарий эксперта
Григорий Бабич, менеджер по развитию продукта в Timeweb
Мы в Timeweb прошли долгий путь к подходящей для нас системе виртуализации. В идеале хотели прийти к полной автономности клиентов VDS от соседей по их серверу. Забегая вперёд, скажу, что у нас это получилось. Но давайте по порядку:
1. OpenVz – использовали такую виртуализацию на ранних этапах и быстро пришли к выводу, что оверселлинг не про нас. Хотели сделать виртуальные машины клиентов автономными друг от друга, а такой формат виртуализации нас технически в этом ограничивал. Поэтому было решено переезжать на Xen.
2. XEN – классная система, с которой мы добились заветной автономности, а, значит, и стабильной производительности для наших клиентов. Мы как будто были на верном пути, но хотелось лучше, поэтому наши специалисты приступили к тестам доступных на тот момент систем.
3. KVM – система, установленная сейчас на всех серверах VDS (пока писали этот комментарий, переводились последние серверы). На первый взгляд, эта система не отличается от XEN, но результаты тестов показали повышение производительности.
Это, кстати, не единственный способ, которым мы пытаемся прокачать услугу VDS. За последние годы вместе с виртуализацией прокачали наши серверы высокоскоростными SSD-дисками, сделали линейку тарифов с упором на мощный процессор и начали размещать серверы в Европе.
