Прежде, чем начать наш обзор, стоит разобраться, что представляет из себя гипервизор, и какие функции он выполняет. При выполнении большого количества разнообразных задач очень удобно пользоваться . Это связно с тем, что они дают возможность на одном физическом сервере размещать несколько операционных систем, каждая из которых оснащена собственным программным обеспечением для решения разнообразных задач. Чтобы обеспечить простое взаимодействие с такими виртуальными машинами, используются гипервизоры. Они представляют из себя программное обеспечение, которое и позволяет осуществлять управление виртуальными машинами: устанавливать, включать и выключать их. Одним из самых популярных гипервизоров на сегодняшний день можно назвать KVM.
Гипервизор KVM
Он дает возможность осуществлять виртуализацию на серверах с операционной системой Linux. Однозначным плюсом является то, что данный гипервизор входит в состав ядра Linux, поэтому он постоянно совершенствуется и обновляется. Использовать его можно только в случае аппаратной виртуализации – с помощью процессоров Intel или Amd. Процессорный модуль KVM дает ему возможность осуществлять доступ непосредственно к ядру. Благодаря этому можно напрямую управлять файлами виртуальных машин и образами дисков. Для каждой ВМ предназначено индивидуальное пространство.
Гипервизор Xen
Впервые разработанный еще Кэмбриджскими студентами, данный проект быстро стал коммерческим благодаря своей перспективности. Кроссплатформенность и широкий функционал Xen делает его возможности достаточно обширными для применения в офисах крупных компаний и корпораций. Его ядро обладает режимом паравиртуализации, то есть его можно настроить на одновременное взаимодействие с гипервизором.
Код этого гипервизора не перегружен лишними функциями. Он оснащен возможностями управления ОЗУ, частотой работы процессора, работы c прямым доступом к памяти, а также таймером. Все остальные функции выполняют подключенные к работе в данный момент ВМ. Перечисленные преимущества делают работу с Xen простой и удобной даже для человека, познания которого не очень глубоки в данной сфере.
Исследование
Для того, чтобы сравнить два гипервизора, нужно провести их тестирование. Для этого были взяты два сервера с абсолютно идентичным железом и ПО, за исключением, конечно же, рассматриваемых гипервизоров. Все настройки для созданных виртуальных машин были выставлены по умолчанию в соответствии с базовыми настройками обоих гипервизоров. Каждому варианту было выделено одинаковое количество памяти.
Уточним, что мнения о том, что выбранный нами дистрибутив для ОС – Fedora 20 от Red Hat – лучше подходит для KVM не совсем верны. Мы не рассматриваем борьбу ВМ за ресурсы процессора во время одновременной работы, так как при разной степени конкуренции гипервизоры могут показывать разную производительность. Поэтому мы считаем условия соревнования честными для обеих сторон.
Результаты
Тестирование основывалось на замере результатов тестов для ВМ, расположенных на одном только железе, исключая программное обеспечение. Отклонение в производительности двух серверов без виртуализации получилось меньше половины процента.
Первый кандидат – KVM показал производительность в среднем на полтора процента ниже производительности железа. В тесте на 7-ZIP данный гипервизор оказался почти на 3 процента медленнее, а в тесте на PostMark на целых 4 с лишним процента быстрее железа. Результаты Xen оказались хуже, он не превзошел своего конкурента ни в одном из тестов, отстав от железа на 2.5 процента в трех тестах, а в остальных показал себя еще хуже. Самое сильное отклонение выявилось, как и у KVM – в тесте на PostMark, но Xen не обогнал железо, как его конкурент, а отстал практически на 15 процентов. Повторные результаты теста отклонились от предыдущих не более, чем на 2 процента. Более подробно с результатами тестирования вы можете ознакомиться в таблице:
Итог
KVM всегда показывал себя медленнее железа примерно на 2 процента, но не более того. Xen же уступал железу на 2.5-7 процентов в большинстве из тестов. Хорошие результаты KVM в тесте на PostMark могут быть не совсем точными про причине недостаточного количества проведенных тестов. Чтобы принять правильное решение в выборе теста гипервизора, изучите характер нагрузок своего сайта. При необходимости проведите больше тестов для получения более точных результатов.
Мне лично проще всего думать о KVM (Kernel-based Virtual Machine), как о таком уровне абстракции над технологиями хардверной виртуализации Intel VT-x и AMD-V. Берем машину с процессором, поддерживающим одну из этих технологий, ставим на эту машину Linux, в Linux’е устанавливаем KVM, в результате получаем возможность создавать виртуалки. Так примерно и работают облачные хостинги, например, Amazon Web Services . Наряду с KVM иногда также используется и Xen, но обсуждение этой технологии уже выходит за рамки данного поста. В отличие от технологий контейнерной виртуализации, например, того же Docker , KVM позволяет запускать в качестве гостевой системы любую ОС, но при этом имеет и бо льшие накладные расходы на виртуализацию.
Примечание: Описанные ниже действия были проверены мной на Ubuntu Linux 14.04, но по идее будут во многом справедливы как для других версий Ubuntu, так и других дистрибутивов Linux. Все должно работать как на десктопе, так и на сервере, доступ к которому осуществляется по SSH.
Установка KVM
Проверяем, поддерживается ли Intel VT-x или AMD-V нашим процессором:
grep -E "(vmx|svm)" / proc/ cpuinfo
Если что-то нагреполось, значит поддерживается, и можно действовать дальше.
Устанавливаем KVM:
sudo
apt-get update
sudo
apt-get install
qemu-kvm libvirt-bin virtinst bridge-utils
Что где принято хранить:
- /var/lib/libvirt/boot/ — ISO-образы для установки гостевых систем;
- /var/lib/libvirt/images/ — образы жестких дисков гостевых систем;
- /var/log/libvirt/ — тут следует искать все логи;
- /etc/libvirt/ — каталог с файлами конфигурации;
Теперь, когда KVM установлен, создадим нашу первую виртуалку.
Создание первой виртуалки
В качестве гостевой системы я выбрал FreeBSD. Качаем ISO-образ системы:
cd
/
var/
lib/
libvirt/
boot/
sudo
wget
http://
ftp.freebsd.org/
path/
to/
some-freebsd-disk.iso
Управление виртуальными машинами в большинстве случаев производится при помощи утилиты virsh:
sudo virsh --help
Перед запуском виртуалки нам понадобится собрать кое-какие дополнительные сведения.
Смотрим список доступных сетей:
sudo virsh net-list
Просмотр информации о конкретной сети (с именем default):
sudo virsh net-info default
Смотрим список доступных оптимизаций для гостевых ОС:
sudo virt-install --os-variant list
Итак, теперь создаем виртуальную машину с 1 CPU, 1 Гб RAM и 32 Гб места на диске, подключенную к сети default:
sudo
virt-install \
--virt-type
=kvm \
--name
freebsd10 \
--ram
1024
\
--vcpus
=1
\
--os-variant
=freebsd8 \
--hvm
\
--cdrom
=/
var/
lib/
libvirt/
boot/
FreeBSD-10.2
-RELEASE-amd64-disc1.iso \
--network
network
=default,model
=virtio \
--graphics
vnc \
--disk
path
=/
var/
lib/
libvirt/
images/
freebsd10.img,size
=32
,bus
=virtio
Вы можете увидеть:
WARNING Unable to connect to graphical console: virt-viewer not
installed. Please install the "virt-viewer" package.
Domain installation still in progress. You can reconnect to the console
to complete the installation process.
Это нормально, так и должно быть.
Затем смотрим свойства виртуалки в формате XML:
sudo virsh dumpxml freebsd10
Тут приводится наиболее полная информация. В том числе есть, к примеру, и MAC-адрес, который понадобятся нам далее. Пока что находим информацию о VNC. В моем случае:
С помощью любимого клиента (я лично пользуюсь Rammina) заходим по VNC , при необходимости используя SSH port forwarding. Попадаем прямо в инстялятор FreeBSD. Дальше все как обычно — Next, Next, Next, получаем установленную систему.
Основные команды
Давайте теперь рассмотрим основные команды для работы с KVM.
Получение списка всех виртуалок:
sudo virsh list --all
Получение информации о конкретной виртуалке:
sudo virsh dominfo freebsd10
Запустить виртуалку:
sudo virsh start freebsd10
Остановить виртуалку:
sudo virsh shutdown freebsd10
Жестко прибить виртуалку (несмотря на название, это не удаление):
sudo virsh destroy freebsd10
Ребутнуть виртуалку:
sudo virsh reboot freebsd10
Склонировать виртуалку:
sudo
virt-clone -o
freebsd10 -n
freebsd10-clone \
--file
/
var/
lib/
libvirt/
images/
freebsd10-clone.img
Включить/выключить автозапуск:
sudo
virsh autostart freebsd10
sudo
virsh autostart --disable
freebsd10
Запуск virsh в диалоговом режиме (все команды в диалоговом режиме — как описано выше):
sudo virsh
Редактирование свойств виртуалки в XML, в том числе здесь можно изменить ограничение на количество памяти и тд:
sudo virsh edit freebsd10
Важно! Комментарии из отредактированного XML, к сожалению, удаляются.
Когда виртуалка остановлена, диск тоже можно ресайзить:
sudo
qemu-img resize /
var/
lib/
libvirt/
images/
freebsd10.img -2G
sudo
qemu-img info /
var/
lib/
libvirt/
images/
freebsd10.img
Важно! Вашей гостевой ОС, скорее всего, не понравится, что диск внезапно стал больше или меньше. В лучшем случае, она загрузится в аварийном режиме с предложением переразбить диск. Скорее всего, вы не должны хотеть так делать. Куда проще может оказаться завести новую виртуалку и смигрировать на нее все данные.
Резервное копирование и восстановление производятся довольно просто. Достаточно сохранить куда-то вывод dumpxml, а также образ диска, а потом восстановить их. На YouTube удалось найти видео с демонстрацией этого процесса, все и вправду несложно.
Настройки сети
Интересный вопрос — как определить, какой IP-адрес получила виртуалка после загрузки? В KVM это делается хитро. Я в итоге написал такой скрипт на Python :
#!/usr/bin/env python3
# virt-ip.py script
# (c) 2016 Aleksander Alekseev
# http://сайт/
import
sys
import
re
import
os
import
subprocess
from
xml
.etree
import
ElementTree
def
eprint(str
)
:
print
(str
,
file
=
sys
.stderr
)
if
len
(sys
.argv
)
<
2
:
eprint("USAGE: "
+ sys
.argv
[
0
]
+ "
eprint("Example: "
+ sys
.argv
[
0
]
+ " freebsd10"
)
sys
.exit
(1
)
if
os
.geteuid
()
!=
0
:
eprint("ERROR: you shold be root"
)
eprint("Hint: run `sudo "
+ sys
.argv
[
0
]
+ " ...`"
)
;
sys
.exit
(1
)
if
subprocess
.call
("which arping 2>&1 >/dev/null"
,
shell =
True
)
!=
0
:
eprint("ERROR: arping not found"
)
eprint("Hint: run `sudo apt-get install arping`"
)
sys
.exit
(1
)
Domain = sys .argv [ 1 ]
if
not
re
.match
("^*$"
,
domain)
:
eprint("ERROR: invalid characters in domain name"
)
sys
.exit
(1
)
Domout =
subprocess
.check_output
("virsh dumpxml "
+domain+" || true"
,
shell =
True
)
domout =
domout.decode
("utf-8"
)
.strip
()
if
domout ==
""
:
# error message already printed by dumpxml
sys
.exit
(1
)
Doc = ElementTree.fromstring (domout)
# 1. list all network interfaces
# 2. run `arping` on every interface in parallel
# 3. grep replies
cmd
=
"(ifconfig | cut -d " " -f 1 | grep -E "." | "
+ \
"xargs -P0 -I IFACE arping -i IFACE -c 1 {} 2>&1 | "
+ \
"grep "bytes from") || true"
for
child in
doc.iter
()
:
if
child.tag
==
"mac"
:
macaddr =
child.attrib
[
"address"
]
macout =
subprocess
.check_output
(cmd
.format
(macaddr)
,
shell =
True
)
print
(macout.decode
("utf-8"
)
)
Скрипт работает как с default сетью, так и с bridged сетью, настройку которой мы рассмотрим далее. Однако на практике куда удобнее настроить KVM так, чтобы он всегда назначал гостевым системам одни и те же IP-адреса. Для этого правим настройки сети:
sudo virsh net-edit default
… примерно таким образом:
После внесения этих правок
>
… и заменяем на что-то вроде:
>
Перезагружаем гостевую систему и проверяем, что она получила IP по DHCP от роутера. Если же вы хотите, чтобы гостевая система имела статический IP-адрес, это настраивается как обычно внутри самой гостевой системы.
Программа virt-manager
Вас также может заинтересовать программа virt-manager:
sudo
apt-get install
virt-manager
sudo
usermod
-a
-G
libvirtd USERNAME
Так выглядит ее главное окно:
Как видите, virt-manager представляет собой не только GUI для виртуалок, запущенных локально. С его помощью можно управлять виртуальными машинами, работающими и на других хостах, а также смотреть на красивые графички в реальном времени. Я лично нахожу особенно удобным в virt-manager то, что не нужно искать по конфигам, на каком порту крутится VNC конкретной гостевой системы. Просто находишь виртуалку в списке, делаешь двойной клик, и получаешь доступ к монитору.
Еще при помощи virt-manager очень удобно делать вещи, которые иначе потребовали бы трудоемкого редактирования XML-файлов и в некоторых случаях выполнения дополнительных команд. Например, переименование виртуальных машин, настройку CPU affinity и подобные вещи. Кстати, использование CPU affinity существенно снижает эффект шумных соседей и влияние виртуальных машин на хост-систему. По возможности используйте его всегда.
Если вы решите использовать KVM в качестве замены VirtualBox, примите во внимание, что хардверную виртуализацию они между собой поделить не смогут. Чтобы KVM заработал у вас на десктопе, вам не только придется остановить все виртуалки в VirtualBox и Vagrant , но и перезагрузить систему. Я лично нахожу KVM намного удобнее VirtualBox, как минимум, потому что он не требует выполнять команду sudo / sbin/ rcvboxdrv setup после каждого обновления ядра, адекватно работает c Unity , и вообще позволяет спрятать все окошки.
В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.
Почему ? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.
Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.
Мы же, повторюсь, решили использовать Debian Squeeze
с набором пакетов из Sid/Experimental
и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
В планах имеется публикация репозитория с пакетами.
При выборе технологии виртуализации рассматривались два варианта - Xen и KVM.
Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen - тем интереснее было провести в жизнь решение именно на базе KVM.
Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.
Для управления виртуальными машинами оказалось чрезвычайно удобно использовать и продукты, использующие ее API: virsh , virt-manager , virt-install , пр.
Это система, которая хранит настройки виртуальных машин, управляет ими, ведёт по ним статистику, следит за тем, чтобы при старте у виртуальной машины поднимался интерфейс, подключает устройства к машине - в общем, выполняет кучу полезной работы и еще немножко сверх того.
Разумеется, решение не идеально. Из минусов следует назвать:
- Абсолютно невменяемые сообщения об ошибках.
- Невозможность изменять часть конфигурации виртуальной машины на лету, хотя QMP (QEMU Monitor Protocol) это вполне позволяет.
- Иногда к libvirtd по непонятной причине невозможно подключиться - он перестаёт реагировать на внешние события.
Основной проблемой в реализации услуги в самом начале представлялось лимитирование ресурсов для виртуальных машин. В 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.
Прочее
Ниже приведено ещё несколько интересных ссылок на описание использованных пограммных средств - почитать и поизучать самостоятельно, если интересно. Например,
При выборе тарифа, человек выбирает также и способ виртуализации для сервера. Предлагаем на выбор виртуализации на уровне операционной системы OpenVZ и аппаратную виртуализацию KVM.
Сменить тип виртуализации после запуска невозможно, поскольку серверы находятся на разных аппаратных платформах. Вам придётся заказать новый сервер, перенести проект и отказаться от старого сервера.
Сравнение типов виртуализаций
| OpenVZ | KVM |
ОС из ряда предложенных: Debian, CentOS, Ubuntu | Linux, Windows, FreeBSD, установка собственного дистрибутива |
Изменение ресурсов без перезагрузки (жёсткий диск, память, процессор) | Память и процессор изменятся после перезагрузки, жёсткий диск - только после обращения в поддержку (на готовых тарифах память изменить нельзя) |
Смена тарифного плана без перезагрузки | Смена тарифного плана . Сервер будет недоступен 1-2 часа. |
Мягкие лимиты: максимальная производительность сервера может отклоняться в большую или меньшую сторону | Жёсткие лимиты: каждый сервер получает заявленные ресурсы |
Ограничение на запуск высоконагруженных проектов. Запрещено запускать Java-приложения, массовые рассылки и проксировать трафик. TUN/TAP выключен. | Возможность запуска любых проектов (кроме систем распределённых вычислений) |
Возможность . Для этого типа виртуализации подключение к графическому интерфейсу по VNC невозможно. | Возможность . Если сервер по каким-либо причинам недоступен по SSH или нужно подключиться к графическому интерфейсу, можно получить доступ к серверу по VNC. |
Перейти в панель управления ISPmanager можно:
|
Виртуализация OpenVZ
OpenVZ - виртуализация уровня операционной системы. Технология базируется на ядре ОС Linux и позволяет на одном физическом сервере создавать и запускать изолированные друг от друга копии выбранной операционной системы (Debian, CentOS, Ubuntu). Установка другой ОС невозможна, так как виртуальные серверы используют общее ядро Linux.
Технология отличается легкостью управления сервером : пользователь может в личном кабинете самостоятельно* добавить количество ресурсов (память, процессор, жесткий диск) или перейти на другой тариф с той же виртуализацией. Изменения применяются автоматически, без перезагрузки сервера.
На серверах с виртуализацией OpenVZ запрещается запускать:
- сервисы для организации проксирования любого вида трафика
- сервисы потокового вещания
- игровые серверы
- системы или элементы систем распределённых вычислений (например, bitcoin mining)
- сервисы массовой рассылки почтовых сообщений, даже если они используются в легальных целях
- Java-приложения
- иные ресурсоёмкие приложения
Такие проекты создают неравномерную нагрузку на родительском сервере и могут мешать соседним виртуальным машинам.
* - для прошлых версий тарифов (VDS-2015, VDS-Лето, VDS-2016) смена тарифа в личном кабинете больше не доступна. Самостоятельное изменение тарифного плана возможно только на актуальных тарифах виртуализации OVZ. Если для вас важно иметь доступ к быстрому управлению ресурсами сервера - для перехода на актуальный тарифный план. Если стоимость нового тарифа выше стоимости текущего, смена тарифа происходит бесплатно, в остальных случаях - в рамках . Тариф меняется без перезагрузки сервера.
Виртуализация KVM
KVM (Kernel-based Virtual Machine) - технология аппаратной виртуализации, позволяющая создать на хост-машине полный виртуальный аналог физического сервера . KVM позволяет создать полностью изолированный от «соседей» виртуальный сервер с собственным ядром ОС, который пользователь может настраивать и модифицировать под собственные нужды без ограничений. Каждому такому серверу выделяется своя область в оперативной памяти и пространство на жестком диске, что повышает общую надежность работы такого сервера.
Возможна установка любой операционной системы на выбор (Debian, CentOS, Ubuntu, FreeBSD, Windows Server), либо установка собственного дистрибутива (в панели VMmanager в разделе ISO-образы нажмите кнопку Создать и добавьте свой ISO-образ системы).
Смена тарифного плана возможна только в большую сторону и только в рамках базовой линейки тарифов (Старт, Разгон, Отрыв, Улёт). Если ваш проект «вырастет» из тарифа, напишите запрос в поддержку из Личного кабинета - администраторы сменят тариф на требуемый бесплатно. Изменить тариф в меньшую сторону можно только переносом на новый сервер. Закажите новый сервер и перенесите данные самостоятельно, либо специалисты технической поддержки помогут с переносом за 1 обращение по пакету администрирования или 250 руб.
Помните, что на тарифах VDS-Форсаж и VDS-Атлант , вы можете изменять ресурсы вместо смены тарифа : количество доступных ядер процессора и оперативной памяти самостоятельно в панели управления, а размер жёсткого диска - после обращения в поддержку (в рамках администрирования или за 250 руб.).
Учитывая особенности и преимущества, которые дает виртуализация KVM, ее тарифы стоят дороже аналогичных тарифов с виртуализацией OpenVZ.
На серверах с виртуализацией KVM Абоненту запрещается размещать системы или элементы систем распределённых вычислений (например, bitcoin mining).
Смена виртуализации на сервере
В рамках одного сервера сменить виртуализацию с OpenVZ на KVM и обратно невозможно.
1. Закажите второй сервер с нужной виртуализацией в панели BILLmanager, раздел Виртуальные серверы → Заказать
2. Перенесите на него данные.
3. После переноса и проверки старый сервер можно удалить (Виртуальные серверы → Удалить).
В жизни сисадмина однажды настает момент, когда приходится с нуля разворачивать инфраструктуру предприятия либо переделывать уже имеющуюся, перешедшую по наследству. В этой статье я расскажу о том, как правильно развернуть гипервизор на основе 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.
Logical Volume Manager
Менеджер логических томов (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 .
INFO
В серверах используются носители SATA, SSD, SAS, SCSI, NVMe. Хорошим тоном при создании логической группы будет указывать не имя хоста, а тип носителей, которые используются в группе. Советую логическую группу назвать так: vg_sata , vg_ssd , vg_nvme и так далее. Это поможет понять, из каких носителей построена логическая группа.
Создаем наш первый логический том. Это будет том для корневого раздела операционной системы. Выбираем пункт «Создать логический том».
Выбираем группу для нового логического тома. У нас она всего одна.
Присваиваем имя логическому тому. Правильнее всего при назначении имени будет использовать префикс в виде названия логической группы - например, vg_sata_root , vg_ssd_root и так далее.
Указываем объем для нового логического тома. Советую выделить под корень 10 Гбайт, но можно и меньше, благо логический том всегда можно расширить.
По аналогии с примером выше создаем следующие логические тома:
- vg_sata_home - 20 Гбайт под каталоги пользователей;
- vg_sata_opt - 10 Гбайт для установки прикладного ПО;
- vg_sata_var - 10 Гбайт для часто меняющихся данных, к примеру логов системы и других программ;
- vg_sata_tmp - 5 Гбайт для временных данных, если объем временных данных велик, можно сделать и больше. В нашем примере этот раздел не создавался за ненадобностью;
- vg_sata_swap - равен объему оперативной памяти. Это раздел для свопа, и создаем мы его для подстраховки - на случай, если закончится оперативная память на гипервизоре.
После создания всех томов завершаем работу менеджера.
Теперь имеем несколько томов для создания разделов операционной системы. Нетрудно догадаться, что для каждого раздела есть свой логический том.
Создаем одноименный раздел под каждый логический том.
Сохраняем и записываем проделанные изменения.
После сохранения изменений разметки диска начнут ставиться базовые компоненты системы, а затем будет предложено выбрать и установить дополнительные компоненты системы. Из всех компонентов нам понадобится 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
INFO
Для нормальной работы группы 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" . Сохраняем файл, перезагружаем гипервизор и проверяем, все ли службы запустились и работают.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!