Гипервизоры (технологии виртуализации) существуют более 30 лет и за это время сумели стать одним из главных «винтиков» в составе облачной экосистемы. Многие компании, подбирающие решения для виртуализации, останавливают свой выбор на двух популярных гипервизорах - VMware и KVM. Предлагаем разобраться какой же из них лучше. Но для начала немного теории.
Гипервизор - это программа, отделяющая операционную систему от железа. Гипервизоры виртуализируют ресурсы сервера (процессор, память, диск, сетевые интерфейсы и др.), позволяя использовать их как свои собственные, и создают на основе одного сервера несколько отдельных виртуальных машин. Каждая созданная виртуальная машина изолируется от соседей, чтобы не влиять на работу других. Для работы гипервизора необходима поддержка виртуализации: для процессоров Intel на процессоре Intel VT, а для процессоров AMD на AMD-V.
Гипервизоры делятся на два типа: первые работают непосредственно с сервером, а операционная система пользователей работает поверх гипервизора. Эти гипервизоры могут предоставлять некоторым пользователям функции управления сервером и большинство предприятий используют именно такие гипервизоры.
Гипервизоры второго типа, также известные как размещенные гипервизоры (Hosted Hypervisor), работают с операционной системой, установленной на сервере. А операционные системы для новых пользователей создаются поверх гипервизора.
Настольные гипервизоры, такие как Oracle VirtualBox или VMware Workstation, являются гипервизорами второго типа, а VMware и KVM – первого. VMware и KVM устанавливаются непосредственно на сервер и не требуют установки какой-либо операционной системы.
Перед покупкой 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 содержат все важные корпоративные функции по обеспечению высокой и непрерывной доступности, обеспечивают поддержку большего числа гостевых операционных систем и имеют возможность сопряжения инфраструктуры заказчика с облачными сервисами.
В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.
Почему ? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.
Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.
Мы же, повторюсь, решили использовать Debian Squeeze
с набором пакетов из Sid/Experimental
и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
В планах имеется публикация репозитория с пакетами.
При выборе технологии виртуализации рассматривались два варианта - Xen и KVM.
Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen - тем интереснее было провести в жизнь решение именно на базе KVM.
Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.
Для управления виртуальными машинами оказалось чрезвычайно удобно использовать и продукты, использующие ее API: virsh , virt-manager , virt-install , пр.
Это система, которая хранит настройки виртуальных машин, управляет ими, ведёт по ним статистику, следит за тем, чтобы при старте у виртуальной машины поднимался интерфейс, подключает устройства к машине - в общем, выполняет кучу полезной работы и еще немножко сверх того.
Разумеется, решение не идеально. Из минусов следует назвать:
Основной проблемой в реализации услуги в самом начале представлялось лимитирование ресурсов для виртуальных машин. В Xen эта проблема была решена при помощи внутреннего шедулера, распределяющего ресурсы между виртуальными машинами - и что самое прекрасное, была реализована возможность лимитировать и дисковые операции в том числе.
В KVM ничего такого не было до появления механизма распределения ресурсов ядра . Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup , в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.
Профит в том, что всё это реализуется внутри ядра, и использовать это можно не только для сервера, но и для десктопа (что и использовали в известном «The ~200 Line Linux Kernel Patch That Does Wonders »). И на мой взгляд, это одно из самых значительных изменений в ветке 2.6, не считая любимого #12309 , а не запиливание очередной файловой системы. Ну, разве что, кроме POHMELFS (но чисто из-за названия).
Отношение к этой библиотеке-утилите у меня весьма неоднозначное.
С одной стороны это выглядит примерно так:
И ещё эту штуку чертовски сложно собрать из исходников и тем более в пакет: иногда мне кажется, что Linux From Scratch собрать с нуля несколько проще.
С другой стороны - очень мощная штука, которая позволяет создавать образы для виртуальных машин, модифицировать их, ужимать, ставить grub, модифицировать таблицу разделов, управлять конфигурационными файлами, переносить «железные» машины в виртуальную среду, переносить виртуальные машины с одного образа на другой, переносить виртуальные машины из образа на железо и, честно говоря, тут меня фантазия немного подводит. Ах, да: ещё можно запустить демон внутри виртуальной машины Linux и получить доступ к данным виртуальной машины вживую, и всё это делать на shell, python, perl, java, ocaml. Это краткий и далеко не полный список того, что можно сделать с .
Интересно, что большая часть кода в генерируется в момент сборки, равно как и документация к проекту. Очень широко используется ocaml, perl. Сам код пишется на C, который потом оборачивается в OCaml, и повторяющиеся куски кода генерируются сами. Работа с образами осуществляется путём запуска специального сервисного образа (supermin appliance), в который через канал внутрь него отправляются команды. Внутри этого образа содержится некоторый rescue набор утилит, таких как parted, mkfs и прочих полезных в хозяйстве системного администратора.
Я с недавнего времени его даже дома стал использовать, когда выковыривал из образа nandroid нужные мне данные. Но для этого требуется ядро с поддержкой yaffs.
Ниже приведено ещё несколько интересных ссылок на описание использованных пограммных средств - почитать и поизучать самостоятельно, если интересно. Например,
Проверка поддержки гипервизора
Проверяем, что сервер поддерживает технологии виртуализации:
cat /proc/cpuinfo | egrep "(vmx|svm)"
В ответ должны получить что-то наподобие:
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
В противном случае, заходим в БИОС, находим опцию для включения технологии виртуализации (имеет разные названия, например, Intel Virtualization Technology или Virtualization) и включаем ее — задаем значение Enable .
Также проверить совместимость можно командой:
* если команда вернет ошибку «kvm-ok command not found» , установите соответствующий пакет: apt-get install cpu-checker .
Если видим:
INFO: /dev/kvm exists
KVM acceleration can be used
значит поддержка со стороны аппаратной части есть.
Для нашего удобства, создадим каталог, в котором будем хранить данные для KVM:
mkdir -p /kvm/{vhdd,iso}
* будет создано два каталога: /kvm/vhdd (для виртуальных жестких дисков) и /kvm/iso (для iso-образов).
Настроим время:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* данная команда задает зону в соответствии с московским временем.
ntpdate ru.pool.ntp.org
* выполняем синхронизацию с сервером времени.
Устанавливаем KVM и необходимые утилиты управления.
а) Ubuntu до версии 18.10
apt-get install qemu-kvm libvirt-bin virtinst libosinfo-bin
б) Ubuntu после 18.10:
apt-get install qemu-kvm libvirt-daemon-system libvirt-bin virtinst libosinfo-bin
* где qemu-kvm — гипервизор; libvirt-bin — библиотека управления гипервизором; virtinst — утилита управления виртуальными машинами; libosinfo-bin — утилита для просмотра списка вариантов операционных систем, которые могут быть в качестве гостевых.
Настроим автоматический запуск сервиса:
systemctl enable libvirtd
Запустим libvirtd:
systemctl start libvirtd
Виртуальные машины могут работать за NAT (в качестве которого выступает сервер KVM) или получать IP-адреса из локальной сети — для этого необходимо настроить сетевой мост. Мы настроим последний.
Используя удаленное подключение, внимательно проверяйте настройки. В случае ошибки соединение будет прервано.
Устанавливаем bridge-utils:
apt-get install bridge-utils
а) настройка сети в старых версиях Ubuntu (/etc/network/interfaces).
Открываем конфигурационный файл для настройки сетевых интерфейсов:
vi /etc/network/interfaces
И приведем его к виду:
#iface eth0 inet static
# address 192.168.1.24
# netmask 255.255.255.0
# gateway 192.168.1.1
# dns-nameservers 192.168.1.1 192.168.1.2
Auto br0
iface br0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 192.168.1.2
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
* где все, что закомментировано — старые настройки моей сети; br0 — название интерфейса создаваемого моста; eth0 — существующий сетевой интерфейс, через который будет работать мост.
Перезапускаем службу сети:
systemctl restart networking
б) настройка сети в новых версиях Ubuntu (netplan).
vi /etc/netplan/01-netcfg.yaml
* в зависимости от версии системы, конфигурационной файл yaml может иметь другое название.
Приводим его к виду:
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: false
dhcp6: false
wakeonlan: true
Bridges:
br0:
macaddress: 2c:6d:45:c3:55:a7
interfaces:
- eth0
addresses:
- 192.168.1.24/24
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses:
- 192.168.1.1
- 192.168.1.2
parameters:
stp: true
forward-delay: 4
dhcp4: false
dhcp6: false
* в данном примере мы создаем виртуальный бридж-интерфейс br0 ; в качестве физического интерфейса используем eth0 .
Применяем сетевые настройки:
Настаиваем перенаправления сетевого трафика (чтобы виртуальные машины с сетевым интерфейсом NAT могли выходить в интернет):
vi /etc/sysctl.d/99-sysctl.conf
Добавляем строку:
net.ipv4.ip_forward=1
Применяем настройки:
sysctl -p /etc/sysctl.d/99-sysctl.conf
Для создания первой виртуальной машины вводим следующую команду:
virt-install -n VM1 \
--autostart \
--noautoconsole \
--network=bridge:br0 \
--ram 2048 --arch=x86_64 \
--vcpus=2 --cpu host --check-cpu \
--disk path=/kvm/vhdd/VM1-disk1.img,size=16 \
--cdrom /kvm/iso/ubuntu-18.04.3-server-amd64.iso \
--graphics vnc,listen=0.0.0.0,password=vnc_password \
--os-type linux --os-variant=ubuntu18.04 --boot cdrom,hd,menu=on
На компьютер, с которого планируем работать с виртуальными машинами, скачиваем VNC-клиент, например, TightVNC и устанавливаем его.
На сервере вводим:
virsh vncdisplay VM1
команда покажет, на каком порту работает VNC для машины VM1. У меня было:
* :1 значит, что нужно к 5900 прибавить 1 — 5900 + 1 = 5901.
Запускаем TightVNC Viewer, который мы установили и вводим данные для подключения:
Кликаем по Connect . На запрос пароля вводим тот, что указали при создании ВМ, (vnc_password ). Мы подключимся к виртуальной машине удаленной консолью.
Если мы не помним пароль, открываем настройку виртуальной машины командой:
И находим строку:
* в данном примере для доступа к виртуальной машине используется пароль 12345678 .
Примеры команд, которые могут пригодиться при работе с виртуальными машинами.
1. Получить список созданных машин:
virsh list --all
2. Включить виртуальную машину:
virsh start VMname
* где VMname — имя созданной машины.
3. Выключить виртуальную машину:
ubuntu-vm-builder — пакет, разработанный компанией Canonical для упрощения создания новых виртуальных машин.
Для его установки вводим:
apt-get install ubuntu-vm-builder
На днях вышел интересный отчет компании Principled Technologies, специализирующейся, в том числе, на всякого рода тестировании аппаратно-программных сред. В документе " " рассказывается о том, что на одном и том же оборудовании с помощью гипервизора ESXi можно запустить больше виртуальных машин, чем на гипервизоре KVM платформы RHEV.
Понятное дело, что исследование ангажированное (хотя бы, если посмотреть на заголовок), но поскольку таких документов не так много, мы решили обратить на него внимание.
Для тестирования использовался стоечный сервер Lenovo x3650 M5, на котором в виртуальных машинах работала СУБД Microsoft SQL Server 2016 с нагрузкой типа OLTP. В качестве основного показателя производительности использовался OPM (orders per minute), отображающий количественную оценку исполненных транзакций.
Если не использовать техники Memory Overcommit, то результат выполнения на 15 виртуальных машинах одного хоста в числе OPM примерно одинаковый на обоих гипервизорах:
А вот когда происходит увеличение числа виртуальных машин, то vSphere показывает себя значительно лучше:
Крестиками отмечены машины, которые на RHV просто не запустились, консоль продукта выдала вот такую ошибку:
Несмотря на включение техник оптимизации памяти в Red Hat Virtualization Manager (RHV-M), таких как memory ballooning и kernel shared memory, шестнадцатая виртуальная машина все равно отказывалась запускаться на KVM:
Ну а на vSphere продолжали наращивать число ВМ, пока не уперлись в недостаток ресурсов:
Получилось, что с техниками overcommit на vSphere получилось запустить 24 виртуальных машины, а на RHV - всего 15 штук. По итогу сделали вывод, что на VMware vSphere в 1,6 раза можно запустить больше виртуальных машин:
Не сказать, что это объективное тестирование, но очевидно, что ESXi в данном случае работает лучше KVM с точки зрения всяких оптимизаций памяти и прочих ресурсов ВМ.
Напомним, что RHEV основана на гипервизоре Kernel-based Virtual Machine (KVM) и поддерживает открытую облачную архитектуру OpenStack. Давайте посмотрим, что нового появилось в обновленном RHEV версии 3.4.
Инфраструктура
Сетевое взаимодействие
Возможности хранилищ
Средства виртуализации
Улучшения планировщика и средств обеспечения уровня обслуживания
Улучшения интерфейса
Скачать Red Hat Enterprise Virtualization 3.4 можно по этой ссылке . Документация доступна .
Новая версия ОС RHEL имеет множество новых интересных возможностей, среди которых немало касаются технологий виртуализации. Некоторые основные новые возможности RHEL 7:
Более подробно о новых возможностях RHEL 7 рассказано Red Hat.
В плане виртуализации в Red Hat Enterprise Linux 7 появились следующие основные нововведения:
Release Notes новой версии ОС доступны по этой ссылке . О функциях виртуализации в новом релизе RHEL 7 можно почитать (а - на русском). Исходные коды rpm-пакетов Red Hat Enterprise Linux 7 теперь доступны только через Git-репозиторий .
Компания Ravello нашла интересный способ использовать вложенную виртуализацию в своем продукте Cloud Application Hypervisor , который позволяет универсализовать развертывание ВМ разных платформ виртуализации в публичных облаках различных сервис провайдеров.
Основным компонентом этой системы является технология HVX - собственный гипервизор (на базе Xen), являющийся частью ОС Linux и запускающий вложенные виртуальные машины без их изменения средствами техник бинарной трансляции. Далее эти машины можно разместить в облаках Amazon EC2, HP Cloud, Rackspace и даже частных облаках, управляемых VMware vCloud Director (поддержка последнего ожидается в скором времени).
Продукт Ravello - это SaaS-сервис, а такие матрешки можно просто загружать на любой из поддерживаемых хостингов, вне зависимости от используемого им гипервизора. Виртуальная сеть между машинами создается через L2-оверлей над существующей L3-инфраструктурой хостера с использованием GRE-подобного протокола (только на базе UDP):
Сама механика предлагаемого сервиса Cloud Application Hypervisor такова:
Очевидный вопрос, который возникает первым: что с производительностью? Ну, во-первых, решение Cloud Application Hypervisor рассчитано на команды разработки и тестирования, для которых производительность не является критичным фактором.
А во-вторых, результаты тестов производительности таких вложенных матрешек показывают не такие уж и плохие результаты:
Для тех, кто заинтересовался технологией HVX, есть хорошее обзорное видео на рунглише:
Новая версия открытой платформы виртуализации RHEV 3.0 основана на дистрибутиве Red Ha Enterprise Linux версии 6 и, традиционно, гипервизоре KVM.
Новые возможности Red Hat Enterprise Virtualization 3.0:
Скачать финальный релиз Red Hat Enterprise Virtualization 3.0 можно по этой ссылке .
Ну и, напоследок, небольшой видео-обзор Red Hat Enterprise Virtualization Manager 3.0 (RHEV-M):
Молодцы NetApp! Роман, ждем перевода на русский язык)
Продукт ConVirt 2.0 Open Source позволяет управлять гипервизорами Xen и KVM, входящими в бесплатные и коммерческие издания дистрибутивов Linux, развертывать виртуальные серверы из шаблонов, осуществлять мониторинг производительности, автоматизировать задачи администратора и настраивать все аспекты виртуальной инфраструктуры. ConVirt 2.0 поддерживает функции горячей миграции виртуальных машин, "тонкие" виртуальные диски (растущие по мере наполнения данными), контроль ресурсов виртуальных машин (в т.ч. запущенных), обширные функции мониторинга и средства интеллектуального размещения виртуальных машин на хост-серверах (ручная балансировка нагрузки).
ConVirt 2.0 пока существует только в издании Open Source, однако разработчики обещают в скором времени выпустить издание ConVirt 2.0 Enteprise, которое будет отличаться от бесплатного следующими возможностями:
Feature | ConVirt 2.0 Open Source | ConVirt 2.0 Enterprise |
---|---|---|
Architecture |
||
Multi-platform Support | ||
Agent-less Architecture | ||
Universal Web Access | ||
Datacenter-wide Console | ||
Administration |
||
Start, Stop, Pause, Resume | ||
Maintanence Mode | ||
Snapshot | ||
Change Resource Allocation on a Running VM | ||
Monitoring |
||
Real-time Data | ||
Historical Information | ||
Server Pools | ||
Storage Pools | ||
Alerts and Notifications | ||
Provisioning |
||
Templates-based Provisioning | ||
Template Library | ||
Integrated Virtual Appliance Catalogues | ||
Thin Provisioning | ||
Scheduled Provisioning | ||
Automation |
||
Intelligent Virtual Machine Placement | ||
Live Migration | ||
Host Private Networking | ||
SAN, NAS Storage Support | ||
Advanced Automation |
||
High Availability | ||
Backup and Recovery | ||
VLAN Setup | ||
Storage Automation | ||
Dynamic Resource Allocation | ||
Power Saving Mode | ||
Security |
||
SSH Access | ||
Multi-user Administration | ||
Auditing | ||
Fine Grained Access Control | ||
Integration |
||
Open Repository | ||
Command Line Interface | ||
Programmatic API |
Компания Convirture, занимавшаяся в 2007 году проектом XenMan, представлявшим собой GUI для управления гипервизором XEN, выпустила недавно релиз бесплатного продукта Convirture ConVirt 1.0, на который изменил свое название XenMan.
С помощью ConVirt можно управлять гипервизорами Xen и KVM, используя следующие возможности:
Скачать Convirture ConVirt 1.0 можно по этой ссылке:
Convirture ConVirt 1.0
Таги: Xen, KVM
В жизни сисадмина однажды настает момент, когда приходится с нуля разворачивать инфраструктуру предприятия либо переделывать уже имеющуюся, перешедшую по наследству. В этой статье я расскажу о том, как правильно развернуть гипервизор на основе Linux KVM и libvirt c поддержкой LVM (логических групп).
Мы пройдемся по всем тонкостям управления гипервизором, включая консольные и GUI-утилиты, расширение ресурсов и миграцию виртуальных машин на другой гипервизор.
Для начала разберемся с тем, что такое виртуализация. Официальное определение звучит так: «Виртуализация - это предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе». То есть, если выражаться человеческим языком, имея один мощный сервер, мы можем превратить его в несколько средних серверов, и каждый из них будет выполнять свою задачу, отведенную ему в инфраструктуре, не мешая при этом другим.
Системные администраторы, работающие вплотную с виртуализацией на предприятии, мастера и виртуозы своего дела, поделились на два лагеря. Одни - приверженцы высокотехнологичной, но безумно дорогой VMware для Windows. Другие - любители open source и бесплатных решений на основе Linux VM. Можно долго перечислять преимущества VMware, но здесь мы остановимся на виртуализации, основанной на Linux VM.
Сейчас есть две популярные технологии виртуализации: Intel VT и AMD-V. В Intel VT (от Intel Virtualization Technology) реализована виртуализация режима реальной адресации; соответствующая аппаратная виртуализация ввода-вывода называется VT-d. Часто эта технология обозначается аббревиатурой VMX (Virtual Machine eXtension). В AMD создали свои расширения виртуализации и первоначально называли их AMD Secure Virtual Machine (SVM). Когда технология добралась до рынка, она стала называться AMD Virtualization (сокращенно AMD-V).
Перед тем как вводить аппаратное обеспечение в эксплуатацию, убедись, что оборудование поддерживает одну из этих двух технологий (посмотреть можно в характеристиках на сайте производителя). Если поддержка виртуализации имеется, ее необходимо включить в BIOS перед развертыванием гипервизора.
Среди других требований гипервизоров - поддержка аппаратного RAID (1, 5, 10), которая повышает отказоустойчивость гипервизора при выходе жестких дисков из строя. Если поддержки аппаратного RAID нет, то можно использовать программный на крайний случай. Но RAID - это мастхэв!
Решение, описанное в этой статье, несет на себе три виртуальные машины и успешно работает на минимальных требованиях: Core 2 Quad Q6600 / 8 Гбайт DDR2 PC6400 / 2 × 250 Гбайт HDD SATA (хардверный RAID 1).
Я покажу, как настраивать гипервизор, на примере Debian Linux 9.6.0 - Х64-86. Ты можешь использовать любой дистрибутив Linux, который тебе по душе.
Когда ты определишься с выбором железа и его наконец-то привезут, придет время ставить гипервизор. При установке ОС все делаем, как обычно, за исключением разметки дисков. Неопытные администраторы часто выбирают опцию «Автоматически разбить все дисковое пространство без использования LVM». Тогда все данные будут записаны на один том, что нехорошо по нескольким причинам. Во-первых, если жесткий диск выйдет из строя, ты потеряешь все данные. Во-вторых, изменение файловой системы доставит массу хлопот.
В общем, чтобы избежать лишних телодвижений и потери времени, рекомендую использовать разметку диска с LVM.
Менеджер логических томов (LVM) - это подсистема, доступная в Linux и OS/2, построенная поверх Device Mapper. Ее задача - представление разных областей с одного жесткого диска или областей с нескольких жестких дисков в виде одного логического тома. LVM создает из физических томов (PV - Phisical Volumes) логическую группу томов (VG - Volumes Group). Она, в свою очередь, состоит из логических томов (LV - Logical Volume).
Сейчас во всех дистрибутивах Linux с ядром 2.6 и выше есть поддержка LVM2. Для использования LVM2 на ОС с ядром 2.4 надо устанавливать патч.
После того как система обнаружила жесткие накопители, запустится менеджер разбивки жестких дисков. Выбираем пункт Guided - use entire disk and set up LVM.
Теперь выбираем диск, на который будет установлена наша группа томов.
Система предложит варианты разметки носителя. Выбираем «Записать все файлы на один раздел» и идем дальше.
После сохранения изменений мы получим одну логическую группу и два тома в ней. Первый - это корневой раздел, а второй - это файл подкачки. Тут многие зададут вопрос: а почему не выбрать разметку вручную и не создать LVM самому?
Я отвечу просто: при создании логической группы VG загрузочный раздел boot не пишется в VG, а создается отдельным разделом с файловой системой ext2. Если этого не учесть, то загрузочный том окажется в логической группе. Это обречет тебя на мучения и страдания при восстановлении загрузочного тома. Именно поэтому загрузочный раздел отправляется на том без LVM.
Переходим к конфигурации логической группы для гипервизора. Выбираем пункт «Конфигурация менеджера логических томов».
Система оповестит о том, что все изменения будут записаны на диск. Соглашаемся.
Создадим новую группу - к примеру, назовем ее vg_sata .
В серверах используются носители SATA, SSD, SAS, SCSI, NVMe. Хорошим тоном при создании логической группы будет указывать не имя хоста, а тип носителей, которые используются в группе. Советую логическую группу назвать так: vg_sata , vg_ssd , vg_nvme и так далее. Это поможет понять, из каких носителей построена логическая группа.
Создаем наш первый логический том. Это будет том для корневого раздела операционной системы. Выбираем пункт «Создать логический том».
Выбираем группу для нового логического тома. У нас она всего одна.
Присваиваем имя логическому тому. Правильнее всего при назначении имени будет использовать префикс в виде названия логической группы - например, vg_sata_root , vg_ssd_root и так далее.
Указываем объем для нового логического тома. Советую выделить под корень 10 Гбайт, но можно и меньше, благо логический том всегда можно расширить.
По аналогии с примером выше создаем следующие логические тома:
После создания всех томов завершаем работу менеджера.
Теперь имеем несколько томов для создания разделов операционной системы. Нетрудно догадаться, что для каждого раздела есть свой логический том.
Создаем одноименный раздел под каждый логический том.
Сохраняем и записываем проделанные изменения.
После сохранения изменений разметки диска начнут ставиться базовые компоненты системы, а затем будет предложено выбрать и установить дополнительные компоненты системы. Из всех компонентов нам понадобится ssh-server и стандартные системные утилиты.
После установки будет сформирован и записан на диск загрузчик GRUB. Устанавливаем его на тот физический диск, где сохранен загрузочный раздел, то есть /dev/sda .
Теперь ждем, пока закончится запись загрузчика на диск, и после оповещения перезагружаем гипервизор.
После перезагрузки системы заходим на гипервизор по SSH. Первым делом под рутом устанавливаем нужные для работы утилиты.
$ sudo apt-get install -y sudo htop screen net-tools dnsutils bind9utils sysstat telnet traceroute tcpdump wget curl gcc rsync
Настраиваем SSH по вкусу. Советую сразу сделать авторизацию по ключам. Перезапускаем и проверяем работоспособность службы.
$ sudo nano /etc/ssh/sshd_config $ sudo systemctl restart sshd; sudo systemctl status sshd
Перед установкой софта для виртуализации необходимо проверить физические тома и состояние логический группы.
$ sudo pvscan $ sudo lvs
Устанавливаем компоненты виртуализации и утилиты для создания сетевого моста на интерфейсе гипервизора.
$ sudo apt-get update; apt-get upgrade -y $ sudo apt install qemu-kvm libvirt-bin libvirt-dev libvirt-daemon-system libvirt-clients virtinst bridge-utils
После установки настраиваем сетевой мост на гипервизоре. Комментируем настройки сетевого интерфейса и задаем новые:
$ sudo nano /etc/network/interfaces
Содержимое будет примерно таким:
Auto br0 iface br0 inet static address 192.168.1.61 netmask 255.255.255.192 gateway 192.168.1.1 broadcast 192.168.0.61 dns-nameserver 127.0.0.1 dns-search сайт bridge_ports enp2s0 bridge_stp off bridge_waitport 0 bridge_fd 0
Добавляем нашего пользователя, под которым будем работать с гипервизором, в группы libvirt и kvm (для RHEL группа называется qemu).
$ sudo gpasswd -a iryzhevtsev kvm $ sudo gpasswd -a iryzhevtsev libvirt
Теперь необходимо инициализировать нашу логическую группу для работы с гипервизором, запустить ее и добавить в автозагрузку при запуске системы.
$ sudo virsh pool-list $ sudo virsh pool-define-as vg_sata logical --target /dev/vg_sata $ sudo virsh pool-start vg_sata; sudo virsh pool-autostart vg_sata $ sudo virsh pool-list
Для нормальной работы группы LVM с QEMU-KVM требуется сначала активировать логическую группу через консоль virsh .
Теперь скачиваем дистрибутив для установки на гостевые системы и кладем его в нужную папку.
$ sudo wget https://mirror.yandex.ru/debian-cd/9.5.0/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso $ sudo mv debian-9.5.0-amd64-netinst.iso /var/lib/libvirt/images/; ls -al /var/lib/libvirt/images/
Чтобы подключаться к виртуальным машинам по VNC, отредактируем файл /etc/libvirt/libvirtd.conf:
$ sudo grep "listen_addr = " /etc/libvirt/libvirtd.conf
Раскомментируем и изменим строчку listen_addr = "0.0.0.0" . Сохраняем файл, перезагружаем гипервизор и проверяем, все ли службы запустились и работают.
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!