Битва гипервизоров: 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, нет ограничений для хоста по процессорам и памяти, зато есть ряд других:
- API продукта доступно только для чтения;
- виртуальная машина не может иметь более 8 ядер;
- ее нельзя использовать вместе с Veeam для создания резервных копий;
- подключение к vCenter Server не поддерживается;
- не поддерживается и высокая доступность, а также технологии VM Host Live Migration и VM Storage Live Migration.
Продукт от 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:
- лицензирование гипервизора выполняется по числу физических процессоров (CPU). Каждый CPU сервера требует отдельной лицензии vSphere (ядра не являются физическими процессорами и не учитываются в лицензировании);
- доступный функционал сервера ESXi определяется установленной на нем лицензией vSphere. Подробное руководство по лицензиям есть на сайте VMware;
- для каждой купленной лицензии vShpere необходимо приобретать пакет сервисной поддержки (минимум на год);
- VMware не накладывает ограничения на количество памяти (RAM), установленной на сервере, и на количество запущенных виртуальных машин.
Управлять множеством хостов с гипервизорами 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 содержат все важные корпоративные функции по обеспечению высокой и непрерывной доступности, обеспечивают поддержку большего числа гостевых операционных систем и имеют возможность сопряжения инфраструктуры заказчика с облачными сервисами.
Источник
Импортозамещение на практике. Часть 2. Начало. Гипервизор
В предыдущей статье были рассмотрены варианты, на что можно заменить существующие системы в рамках выполнения приказа об импортозамещении. Далее в статьях речь пойдет о выборе конкретных продуктов для замены развернутых в настоящее время. Начнем с точки отсчета — системы виртуализации.
1. Муки выбора
- Система серверной виртуализации «Р-Виртуализация» (libvirt, KVM, QEMU)
- Программный комплекс «Средства виртуализации «Брест»» (libvirt, KVM, QEMU)
- Платформа управления и мониторинга среды виртуализации «Sharx Stream» (облачное решение, которое не подходит для госконтор в 95% случаев (секретность и т.д.)
- Программный комплекс виртуализации серверов, рабочих столов и приложений «ХОСТ» (KVM x86)
- Система безопасного управления средой виртуализации «Z|virt» (он же oVirt+KVM)
- Система управления средой виртуализации «ROSA Virtualization» (он же oVirt+KVM)
- Гипервизор QP VMM (слишком похож на Oracle Virtual Box, чтобы быть чем-то другим)
Так же можно брать в расчет гипервизоры, входящие в состав поставки ОС, или находящиеся в их репозитории. Например, у той же Astra Linux есть поддержка KVM. И так как он входит в репозитории ОС, то его можно считать «легитимным» для установки и использования. О том, «что можно использовать в рамках импортозамещения, а что нет», было оговорено в предыдущей статье, так что не буду останавливаться на этом вопросе.
- VirtualBox
- Virt-manager (KVM) Орел current
- libvirt over KVM
- ROSA Virtualization over oVirt over KVM
- QEMU over KVM
- oVirt 3.5 over KVM
1.2. Есть одно НО
При ближайшем рассмотрении, делаем вывод, что иметь дело нам придется всего лишь с несколькими известными гипервизорами, а именно:
- KVM
- VirtualBox
- QEMU
- bhyve
QEMU — свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ, которая может работать и без использования KVM, но использование аппаратной виртуализации значительно ускоряет работу гостевых систем, поэтому использование KVM в QEMU (-enable-kvm) является предпочтительным вариантом. (с) То есть QEMU — гипервизор 2го типа, что неприемлемо в продуктовой среде. С KVM его можно использовать, но в этом случае QEMU будет использоваться в качестве средства управления KVM.
bhyve — гипервизов второго типа. Отметается.
Использование оригинального VirtualBox в коммерции является фактически нарушением лицензии: «Начиная с версии 4, выпущенной в декабре 2010 года, основная часть продукта распространяется бесплатно под лицензией GPL v2. Устанавливаемый поверх неё дополнительный пакет, обеспечивающий поддержку устройств USB 2.0 и 3.0, протокол удалённого рабочего стола (RDP), шифрование накопителя, загрузку с NVMe и по PXE, распространяется под особой лицензией PUEL («для личного использования и ознакомления»), по который система бесплатна для личного использования, в целях обучения или для оценки перед принятием решения о приобретении коммерческой версии.» (с) Плюс VirtualBox так же является гипервизором 2го типа, так что он так же отпадает.
Итого: в чистом виде мы имеем только KVM.
2. В остатке: KVM или KVM?
В случае, если вам все же необходимо перейти на «отечественный» гипервизор — выбор у вас, прямо скажем, невелик. Это будет KVM в той или иной обертке, с теми или иными доработками, но все равно это будет KVM. Хорошо это или плохо — вопрос другой, все равно альтернативы нет.
В случае, если условия не столь строги, то, как говорилось в предыдущей статье: «Нам надо привести показатели к установленным пределам. На деле это значит, что мы должны заменить существующие ОС на продукты из реестра Минкомсвязи и довести количество замененных операционных систем до 80%.… Итак, мы спокойно можем оставить кластер на Hyper-V, раз уж он у нас есть и нам он нравится. » (с) Так что перед нами стоит выбор: Microsoft Hyper-V или KVM. KVM может быть с «прикрученными» к нему средствами управления, но он все равно останется все тем же KVM.
Эти продукты сравнивались далеко не однократно, не двукратно, не трехкратно… Ну, вы поняли…
Про развертывание и настройку KVM так же писалось не однократно, не двукратно, не трехкратно и не четырехкратно… Словом, выпонели.
Не вижу смысла повторяться и описывать эти системы, сравнивать и т.д. Можно, конечно, повыдергивать из статей ключевые моменты, но это будет неуважение к авторам, я считаю. Кому предстоит выбирать — тот прочтет не только это, но и еще гору информации, чтобы определиться.
Единственное отличие, на котором хочу заострить внимание — отказоустойчивая кластеризация. Если у Microsoft это встроено в ОС и функционал гипервизора, то в случае с KVM придется использовать стороннее ПО, которое должно входить в репозитории ОС. Та же связка Corosync+Pacemaker, например. (Эта связка есть почти у всех отечественных ОС… может, и у всех, но все 100% я проверять не стал.) Мануалы по настройке кластеризации так же имеются в избытке.
3. Вывод
Ну, как обычно, наши Кулибины не стали заморачиваться, взяли что было, прикрутили чуточку своего, и выдали «продукт», который по документам является отечественным, а на деле — OpenSource. Есть ли смысл тратить деньги из бюджета за «отдельные» системы виртуализации (читай не входящие в состав ОС)? Не думаю. Так как все равно вы получите тот же KVM, только за него еще нужно будет заплатить.
Таким образом, выбор замены для гипервизора сводится к тому, какие серверные ОС вы собираетесь закупать для Предприятия и эксплуатировать. Или же, как в моем случае, останетесь на том, что у вас уже есть (Hyper-V\ESXi\вписать_нужное).
Так же по теме можете почитать:
Предыдущая статья про планирование импортозамещения.
И далее по теме:
Статья про «отечественные» операционные системы.
Источник
