Установка Proxmox в Debian на raid 1

На сегодняшний день существует несколько наиболее популярных гипервизоров для построения виртуальной информационной системы. В данной статье я рассмотрю установку и настройку бесплатной системы виртуализации proxmox на базе ОС Debian 8, установленной на raid 1. В качестве гипервизоров она использует опенсорсные KVM и LXC, позволяя виртуализировать наиболее популярные ОС.

Введение

Некоторое время назад я узнал про систему виртуализации proxmox на базе KVM. Ранее с этим гипервизором я был знаком, но он мне не понравился из-за отсутсвия удобных инструментов управления под windows. Мне пришлось администрировать уже настроенный гипервизор и мне это не понравилось, слишком много действий приходилось делать в консоли. Не скажу, что мне это прям не нравится, но я не вижу смысла в консоли делать то, что в других гипервизорах мышкой ты делаешь в 5 раз быстрее. Свое время стараюсь экономить и использовать рационально.

Все изменилось, когда я решил посмотреть на Proxmox. Простая установка и удобная панель управления через браузер привлекли сразу. Попробовал, потестировал, вроде все неплохо работает, управление удобное и понятное. Особенно понравились бэкапы из коробки. Не решался использовать в реальной работе, потому что не имею опыта работы c zfs, а ставить гипервизор на одиночные диски плохая идея. Обычно я использую XenServer, установленный на mdadm raid1. Proxmox почему-то не поддерживает установку на простой и понятный mdadm, но при этом есть zfs. Этот момент мне искренне не понятен, если учитывать, что proxmox работает на базе системы Debian, которая без проблем устанавливается на программный рейд.

Наконец-то у меня дошли руки установить, настроить и протестировать proxmox, установленный на программный raid 1 mdadm. Диски отключал, вынимал, вставлял обратно. Все прекрасно работает. Отказоустойчивость на уровне дисков обеспечена, значит можно использовать в реальной работе. Отдельно упомяну, что меня сразу привлекло в KVM — возможность пробрасывать USB. До сих пор Hyper-V и XenServer не умеют это делать. Первый совсем не умеет, второй вроде как-то пробрасывает, но без гарантий и не все устройства работают. А в KVM без проблем получилось пробросить USB в виртуалку и воткнуть туда HASP ключ от 1С. Для малых и средних офисов это актуальная потребность.

Для того, чтобы установить proxmox на raid 1 пойдем окольным путем. Стандартный инсталлятор не дает нам необходимой возможности установки на рейд. У нас есть 2 варианта решения проблемы:

1. Установка сначала голой системы Debian 8 на raid1, а затем на нее устанавливается proxmox. Конечный результат не будет отличаться от инсталляции со стандартного диска.
2. Установить систему proxmox на одиночный диск, а потом перенести ее на raid1.

Я пробовал оба способа, первый мне показался более простым и понятным, поэтому займемся его реализацией.

Установка proxmox на mdadm raid1 в debian 8

Первым делом нам нужно установить чистую систему Debian. На данный момент это версия 8 Jessie. У меня есть статья по установке Debian. Подробную инфорацию по процессу можно подсмотреть там, за исключением одного нюанса, который я рассмотрю здесь отдельно — установка именно на raid1.

Скачивайте дистрибутив последней версии Debian. Взять его можно, к примеру, на Yandex.Mirror, конкретно здесь. Для установки подойдет образ CD-1 либо netinst. Начинайте стандартную установку и доходите до пункта настройки жесткого диска. Я буду использовать консольное отображение, не графическое. Мне так удобнее. Принципиальных отличий нет, можете делать по аналогии, если начали установку в графическом режиме. Когда дело дойдет до настройки диска, выбирайте вариант ручной разметки.

Если вы делаете установку на чистые диски, то вас должна встретить такая картина состояния дисков:

Если есть какие-то разделы, то удалите их все, чтобы были чистые диски. Для написания статьи я использую виртуальную тестовую среду, диски выделены небольшого объема. Для учебных целей этого достаточно. Я разобью диски следующим образом:

Создаем в инсталляторе указанные разделы на обоих дисках. Не буду расписывать по шагам как их сделать, надеюсь сами разберетесь, это не сложно. Должна получиться такая картина:

Параметры первого раздела на 100 Мб:

Параметры второго раздела на 10 Гб:

Оба раздела должны быть Primary.

Теперь создадим 2 отдельных raid массива на 100мб и 10гб. Выбираем раздел Configure Software RAID, дальше Create MD device, потом RAID1, 2 диска в массиве, и в завершении выбираем 2 наших раздела по 100мб:

То же самое делаем с разделами по 10гб — объединяем их в рейд:

Как закончите, жмете Finish. У вас должна получиться такая картина:

Теперь нужно создать файловую систему на рейд массивах. Сделаем на первом раздел /boot ext2, а на втором корень системы — / и файловую систему ext4.

В итоге должно получиться вот так:

Применяем изменения и продолжаем стандартную установку. В конце будет предложено установить загрузчик на один из дисков. Можете выбрать любой диск, позже мы установим загрузчик на второй диск и убедимся, что он будет установлен на обоих дисках. Это нужно для того, чтобы система могла загружаться с любого из дисков, в случае выхода другого из строя.

После установки рекомендую выполнить базовую настройку Debian. Это не обязательно, посмотрите на мои рекомендации и делайте то, что посчитаете нужным. Если гипервизор будет внутри локальной сети, то фаервол можно выключить, порт ssh не трогать, а логин под root разрешить. Обновиться, настроить сеть, время и полезные утилиты. Так же на всякий случай создайте swap раздел хотя бы на 2-4 гигабайта.

Теперь установим grub на оба жестких диска. Для этого выполняем команду:

# dpkg-reconfigure grub-pc

На все вопросы оставляете дефолтные значения, в конце выбираете оба жестких диска для установки загрузчика:

На всякий случай проверим как встала система на жесткие диски:

# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/md1 9.1G 930M 7.7G 11% /

udev 10M 0 10M 0% /dev

tmpfs 792M 8.4M 784M 2% /run

tmpfs 2.0G 0 2.0G 0% /dev/shm

tmpfs 5.0M 0 5.0M 0% /run/lock

tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup

/dev/md0 91M 32M 55M 37% /boot

# cat /proc/mdstat

Personalities : [raid1]

md1 : active raid1 sda2[0] sdb2[1]

9757696 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]

96128 blocks super 1.2 [2/2] [UU]

Все в порядке, получилось так как и задумывали. На данном этапе можно повынимать жесткие диски и проверить как система работает без одного из них, научиться заменять сбойный диск. Команды и рекомендации не буду приводить, чтобы не раздувать статью. Мануалов по работе с mdadm в интернете полно. Рекомендую сразу настроить мониторинг mdadm в zabbix.

Переходим непосредственно к установке proxmox. Для этого редактируем файл /etc/hosts и приводим его строго к следующему виду. Если что-то будет не так, как указано у меня, получите ошибку установки с очень большой долей вероятности. Я на этом моменте прилично застрял, когда разбирался.

# mcedit /etc/hosts

127.0.0.1 localhost.localdomain localhost

192.168.1.113 proxmox.local proxmox pvelocalhost

Проверить правильность настроек можно командой:

# hostname --ip-address

192.168.1.113

В ответ должны получить свой ip адрес.

Добавляем в список репозиториев репу proxmox и стандартные репозитории debian на зеркале яндекса, все остальное можно закомментировать:

# mcedit /etc/apt/sources.list

deb http://mirror.yandex.ru/debian/ jessie main non-free contrib

deb-src http://mirror.yandex.ru/debian/ jessie main non-free contrib

deb http://download.proxmox.com/debian jessie pve-no-subscription

Добавляем цифровую подпись proxmox репозитория:

# wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -

Если раньше не обновили систему, то обновитесь и на всякий случай перезагрузите сервер после этого:

# apt-get update && apt-get dist-upgrade

# reboot

Теперь устанавливаем саму систему виртуализации:

# apt-get install proxmox-ve ntp ssh postfix ksm-control-daemon open-iscsi systemd-sysv

Если получите ошибку во время установки:

dpkg: error processing package proxmox-ve (--configure):

 dependency problems - leaving unconfigured

Errors were encountered while processing:

 pve-cluster

 libpve-access-control

 librados2-perl

 pve-firewall

 pve-ha-manager

 qemu-server

 pve-container

 pve-manager

 proxmox-ve

Проверяйте файл hosts. У меня там лишние строки были, кроме тех, что я указал ранее. Когда исправил, установка прошла без ошибок. После окончания установки перезагрузите сервер, чтобы загрузилось новое ядро. Если все в порядке, то увидите окно приветствия на мониторе сервера:

Открывайте браузер по указанному адресу и заходите в web интерфейс. Напоминаю, что web порт proxmox по-умолчанию — 8006. Не забывайте его указывать в строке адреса в браузере.

Базовая настройка proxmox

Заходим через браузер по указанному адресу. В окне логина вводите системный root и пароль от него. Нас сразу же встречает предупреждение:

You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.

У нас нет платной подписки, поэтому нужно удалить из списка репозиториев платный. Для этого открываем консоль сервера и закомментируем репозиторий:

# mcedit /etc/apt/sources.list.d/pve-enterprise.list

#deb https://enterprise.proxmox.com/debian jessie pve-enterprise

Теперь убираем окно с предупреждением:

# sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/pve-manager/ext6/pvemanagerlib.js

При входе больше не будет выскакивать безполезное предупреждение.

Настройка сети

Обычно для виртуальных машин достаточно 3 режима работы сети:

1. Режим Bridge. В этом режиме виртуальные машины получают ip адрес из одной подсети с гипервизором и имеют в нее прямой доступ.
2. Режим NAT. Вирутальные машины получают ip адреса в своей виртуальной подсети, во внешнюю сеть выходят через гипервизор и настроенный на нем NAT.
3. Routed режим, когда шлюзом в интернет является одна из виртуальных машин.

Я обычно использую первый вариант, второй только в тестовых средах. Но рассмотрим настройку обоих вариантов.

Как создать bridge в proxmox

Для создания сетевого интерфейса типа bridge в proxmox, в web интерфейсе перейдите в раздел Network и нажмите Create -> Linux Bridge.

Заполняете необходимые поля. Обязательными являются поле IP address, Subnet mask, Gateway, Bridge Ports.

С такими настройками вы сможете в качестве локального интерфейса оставить только vmbr0, а eth0 отключить. Это на ваше усмотрение. Если оставить оба интерфейса, то ваш proxmox будет доступен по двум разным ip адресам. Если получите ошибку:

Удалите настройку шлюза на eth0, добавьте его на vmbr0.

Сразу обращаю внимание, что после создания бриджа, в системе создается новый файл с сетевыми настройками — /etc/network/interfaces.new. Там отражены сделанные нами изменения. Информация из него будет добавлена в основной файл interfaces после перезагрузки. Перезагрузите сервер и проверьте. Если все в порядке, то вы сможете подключаться и по ssh и по web доступу к обоим ip адресам — eth0 и vmbr0.

Настройка NAT для вирутальных машин

В настройке NAT в proxmox есть нюансы, чтобы в них разобраться мне пришлось прилично повозиться. NAT может работать прямо из коробки без всяких настроек. Достаточно в настройках сетевого интерфейса ВМ указать, что вы хотите использовать подключение типа NAT:

В самой виртуальной машине необходимо установить получение сетевых настроек по DHCP. После загрузки ВМ получит сетевой адрес 10.0.2.15 и у нее уже будет доступ в интернет. Этот тип подключения реализован в QEMU и не требует настройки. Все виртуальные машины, у которых будут указаны приведенные выше параметры получат один и тот же ip 10.0.2.15, будут видеть локальную сеть гипервизора и иметь доступ в интернет. Но друг друга такие виртуальные машины не увидят. Каждая из них будет в своей виртуальной сети находиться с одинаковыми ip адресами.

Чтобы настроить более удобный способ подключения ВМ с помощью NAT, когда все виртуалки вместе с гипервизором будут в единой вирутальной сети видеть друг друга, потребуется создать еще один bridge и настроить трансляцию адресов с помощью iptables на самом гипервизоре. Сделаем это.

Заходим по ssh на гипервизор и добавляем в файл с новыми сетевыми настройками несколько строк:

# mcedit /etc/network/interfaces.new

auto vmbr1

iface vmbr1 inet static

address 192.168.5.211

netmask 255.255.255.0

bridge_ports none

bridge_stp off

bridge_fd 0

post-up echo 1 > /proc/sys/net/ipv4/ip_forward

post-up iptables -t nat -A POSTROUTING -s '192.168.5.0/24' -o vmbr0 -j MASQUERADE

post-down iptables -t nat -D POSTROUTING -s '192.168.5.0/24' -o vmbr0 -j MASQUERADE

Сохраняем файл и перезагружаем сервер. В настройках сети ВМ указываете интерфейс vmbr1, в самой системе вручную прописываете сетевые настройки, где адрес шлюза равен адресу на vmbr1, а ip адрес самой машины будет в подсети 192.168.5.0/24. Все виртуальные машины, у которых установлен бридж vmbr1 будут видеть друг друга.

Если вам не хочется на каждой ВМ вручную прописывать IP, можно настроить dhcp сервер либо на одной из виртуалок, либо на самом гипервизоре. Главное назначить ему нужный интерфейс — vmbr1. Настройка dhcp сервера выходит за рамки этой статьи, не буду на этом останавливаться. Для общего использования достаточно того, что я уже указал. Можете использовать любой из способов подключения NAT в виртуальных машинах в зависимости от ваших потребностей.

Routed режим сети

Последний вариант, который я иногда использую. В качестве шлюза в интернет для локальных машин, а если необходимо и офиса, выступает виртуальная машина. Этот режим ничем особо не отличается от режима NAT, кроме того, что сам нат не нужен, так как натить трафик будет шлюз на виртуальной машине. Нам нужны будут 2 бриджа: один для передачи сети провайдера в виртуальную машину-шлюз, второй для сети виртуальных машин. Настройка может немного отличаться, в зависимости от того, что вы хотите получить. Тут могут быть 2 варианта:

1. У вас гипервизор с 1 физической сетевой картой, в которую воткнут шнурок с интернетом от провайдера. Вся ваша инфраструктура виртуальная, доступ только через интернет. Например, вы арендуете выделенный сервер где-то и используете для различных целей.
2. На вашем физическом сервере 2 и более сетевых карт. В первую приходит интернет от провайдера, вторая смотрит в локальную сеть. На гипервизоре виртуальные машины используются пользователями из локальной сети и находятся с ними в едином адресном пространстве.

В обоих случаях есть еще варианты настройки в зависимости от количества ip адресов, которые вам выдает провайдер. Если у вас только 1 внешний IP адрес, вы должны его пробросить в виртуальный шлюз. Только он будет иметь доступ в интернет. Для этого вы должны создать бридж вместе с сетевой картой, в которую приходит интернет, но при этом сам бридж не должен иметь IP адреса. Вот пример, как это должно выглядеть с первом варианте:

iface eth0 inet manual

auto vmbr0

iface vmbr0 inet manual

bridge_ports eth0

bridge_stp off

bridge_fd 0

auto vmbr1

iface vmbr1 inet static

address 10.0.0.1

netmask 255.255.255.0

gateway 10.0.0.2

bridge_ports none

bridge_stp off

bridge_fd 0

В eth0 входит провод от провайдера. Этот интерфейс включен в vmbr0 и ему не назначен ip адрес. Второй бридж vmbr1 имеет виртуальный ip адрес и создан для локальной сети виртуальных машин. Дальше вы создаете виртуальную машину для шлюза и добавляете ему оба бриджа — vmbr0 и vmbr1. На первом настраиваете ip в соответствии с настройками провайдера, на втором в данном случае указываете статический ip адрес 10.0.0.2, который будет являться шлюзом для всех виртуальных машин и самого гипервизора в том числе. Это отражено в параметре gateway в свойствах vmbr1. Потом настраиваете виртуальнвй шлюз и все будет работать.

Виртуальному шлюзу нужно не забыть поставить автозапуск при старте гипервизора, чтобы можно было перезагружать гипервизор удаленно и не терять доступ. Схема кажется немного запутанной, надо просто немного вникнуть и разобраться. На самом деле это удобно в том случае, если у вас один единственный сервер и на нем надо развернуть всю инфраструктуру. Шлюз замечательно живет на виртуальной машине, легко бэкапится и переносится. Настроить можно любой функционал. Единственный нюанс — настраивать нужно локально, тщательно проверить и только убедившись, что все корректно работает и перезагружается, ставить на постоянную работу.

Если у вас две сетевые карты, то все то же самое. Первый бридж для интернета от провайдера без ip, второй бридж для виртуальных машин и локальной сети. Нужно только указать в нем bridge_ports eth1, если eth1 используется для физического подключения в локальную сеть.

Я часто использовал такую схему подключения, каких-то особых проблем и подводных камней тут нет. Если сервер под гипервизор надежный, то работает такое решение зачастую лучше, чем отдельный бюджетный роутер. А функционал в разы больше. Последнее время стараюсь под шлюз использовать Mikrotik там, где это возможно и оправданно.

Хранилище для виртуальных машин

После чистой установки proxmox на debian, автоматически создается хранилище local, которое располагается на одном разделе с самой операционной системой по адресу /var/lib/vz. Оно уже предназначено для хранения образов дисков, виртуальных машин и контейнеров.

Для удобства лучше этот раздел не занимать, оставить необходимое пространство для нормальной работы ОС, а для виртуальных машин создать отдельное хранилище в незанятой области жестких дисков, которую мы оставили во время утановки, либо на отдельном жестком диске или рейд массиве. Сначала рассмотрим вариант создания хранилища на неразмеченной области диска.

Мы создадим еще один raid1 mdadm из незанятого места на дисках. Для этого нам нужно будет там создать разделы и объединить их в программный рейд с помощью mdadm.

Смотрим имена дисков в нашей системе:

# ls -l /dev | grep sd

brw-rw---- 1 root disk 8, 0 Sep 20 09:05 sda

brw-rw---- 1 root disk 8, 1 Sep 20 09:05 sda1

brw-rw---- 1 root disk 8, 2 Sep 20 09:05 sda2

brw-rw---- 1 root disk 8, 16 Sep 20 09:05 sdb

brw-rw---- 1 root disk 8, 17 Sep 20 09:05 sdb1

brw-rw---- 1 root disk 8, 18 Sep 20 09:05 sdb2

У меня 2 диска sda и sdb. На них уже есть по 2 раздела, которые мы сделали во врем установки системы. Создадим на каждом из них еще по одному разделу из всего оставшегося свободного места.

# cfdisk /dev/sda

Выбираем свободное пространство, создаем на нем раздел и указываем тип — Linux raid autodetect.

То же самое делаем со вторым диском. После этих действий у вас должны появиться новые разделы /dev/sda3 и /dev/sdb3. Чтобы это произошло, нужно либо перезагрузить сервер, либо перечитать таблицу разделов командой:

# partprobe -s

Если команда не найдена, установите parted:

# apt-get install parted

Проверим новые разделы:

# ls -l /dev | grep sd

brw-rw---- 1 root disk 8, 0 Sep 22 16:28 sda

brw-rw---- 1 root disk 8, 1 Sep 22 16:28 sda1

brw-rw---- 1 root disk 8, 2 Sep 22 16:28 sda2

brw-rw---- 1 root disk 8, 3 Sep 22 16:28 sda3

brw-rw---- 1 root disk 8, 16 Sep 22 16:28 sdb

brw-rw---- 1 root disk 8, 17 Sep 22 16:28 sdb1

brw-rw---- 1 root disk 8, 18 Sep 22 16:28 sdb2

brw-rw---- 1 root disk 8, 19 Sep 22 16:28 sdb3

Теперь объединим только что созданные разделы в raid1:

# mdadm --create /dev/md2 --level=1 --raid-disks=2 /dev/sda3 /dev/sdb3

mdadm: Note: this array has metadata at the start and

may not be suitable as a boot device. If you plan to

store '/boot' on this device please ensure that

your boot-loader understands md/v1.x metadata, or use

--metadata=0.90

Continue creating array? y

mdadm: Defaulting to version 1.2 metadata

mdadm: array /dev/md2 started.

Проверим информацию о mdadm:

# cat /proc/mdstat

Personalities : [raid1]

md2 : active raid1 sdb3[1] sda3[0]

21577728 blocks super 1.2 [2/2] [UU]

[==============>......] resync = 71.3% (15405120/21577728) finish=0.5min speed=200050K/sec

md1 : active raid1 sda2[0] sdb2[1]

9757696 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]

96128 blocks super 1.2 [2/2] [UU]

Все в порядке, массив синхронизируется. Дождитесь окончания синхронизации и продолжайте. Хотя это не обязательно, массив и сейчас уже готов к работе, он он будет сильно тормозить во время ребилда. Добавим информацию о новом массиве в конфигурационный файл /etc/mdadm/mdadm.conf, иначе после перезагрузки массив исчезнет:

# mdadm --examine --scan | grep 'md/2' >> /etc/mdadm/mdadm.conf

Конфигурационный файл примет такой вид:

# cat /etc/mdadm/mdadm.conf

# mdadm.conf

#

# Please refer to mdadm.conf(5) for information about this file.

#

# by default (built-in), scan all partitions (/proc/partitions) and all

# containers for MD superblocks. alternatively, specify devices to scan, using

# wildcards if desired.

#DEVICE partitions containers

# auto-create devices with Debian standard permissions

CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system

HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts

MAILADDR root

# definitions of existing MD arrays

ARRAY /dev/md/0 metadata=1.2 UUID=d934b08f:47e7e455:359c663e:95015d85 name=proxmox:0

ARRAY /dev/md/1 metadata=1.2 UUID=2e26a1d8:70a94110:7e45b7a5:ec35a885 name=proxmox:1

# This configuration was auto-generated on Fri, 16 Sep 2016 22:26:02 +0300 by mkconf

ARRAY /dev/md/2 metadata=1.2 UUID=901b7580:fba3fe08:c888d6fa:9bbfb712 name=proxmox:2

Дальше у нас 2 пути:

1. Создать файловую систему на md2, смонтировать раздел в систему и создать storage в виде обычной директории, такой же, как по-умолчанию.
2. Создать том LVM и на его основе storage.

Традиционно используют второй способ, так как он позволяет потом использовать в качестве дисков виртуальных машин lvm разделы. С ними удобно работать. Так что пойдем по второму пути. Выполним инициализацию раздела для работы с LVM:

# pvcreate /dev/md2

Physical volume "/dev/md2" successfully created

Создадим группу томов:

# vgcreate raid1-md2 /dev/md2

Volume group "raid1-md2" successfully created

Теперь идем в web интерфейс, выбираем Datacenter, вкладку Storage, жмем Add и выбираем LVM:

Указываем параметры только что созданной группы томов

Все готово. Новый storage добавили. Его можно использовать для хранения дисков виртуальных машин.

Добавление и подключение диска

Рассмотрим вариант добавления нового диска и использование его в качестве хранилища виртуальных машин. По большому счету, это то же самое, что мы проделали ранее с новым разделом, только теперь все указанные выше операции нужно будет проделать над новым диском. Быстро пройдем по этапам.

Я подключил новый жесткий диск, проверим его имя в системе:

# ls -l /dev | grep sd

brw-rw---- 1 root disk 8, 0 Sep 22 17:12 sda

brw-rw---- 1 root disk 8, 1 Sep 22 17:12 sda1

brw-rw---- 1 root disk 8, 2 Sep 22 17:12 sda2

brw-rw---- 1 root disk 8, 3 Sep 22 17:12 sda3

brw-rw---- 1 root disk 8, 16 Sep 22 17:12 sdb

brw-rw---- 1 root disk 8, 17 Sep 22 17:12 sdb1

brw-rw---- 1 root disk 8, 18 Sep 22 17:12 sdb2

brw-rw---- 1 root disk 8, 19 Sep 22 17:12 sdb3

brw-rw---- 1 root disk 8, 32 Sep 22 17:12 sdc

Можно не создавать на диске раздел, а сразу его инициализировать для работы в lvm и создать группу томов:

# pvcreate /dev/sdc

# vgcreate disk-sdc /dev/sdc

Идем в веб интерфейс и создаем новый storage:

Если у вас будет не одиночный диск, а несколько, то перед этим создайте рейд массив из них и так же поверх накатывайте lvm и добавляйте новый storage. На этом настройку локальных хранилищ завершаем. Все основные действия мы выполнили, можно начинать работать с системой — создавать виртуальные машины.

 Хранилище по NFS

Приведу простой пример подключения хранилища по NFS. Мне оно в будущем понадобится для организации бэкапа виртуальных машин. Об этом я расскажу позже. Сейчас только добавим новое хранилище. Сделать это очень просто. У меня уже есть настроенный сервер NFS. Описание его настрйоки выходит за рамки материала, поэтому бедем считать, что сервер у вас есть. Идем в раздел Storage и добавляем новое хранилище NFS:

Я это хранилище буду использовать только для iso образов и backup’ов, поэтому выставляю соответствующие настройки.

Создание и настройка виртуальных машин

В настройке виртуальных машин нет ничего сложного и необычного. Я не буду по шагам рассказывать, как это сделать. Если вы дошли до этого пункта, преодолев все остальные, разобраться не составит труда. Обращаю внимание только на несколько ключевых моментов. Чтобы установить виртуальную машину, нужно использовать iso образ. Его надо как-то загрузить на proxmox. Сделать это не сложно, нужно только понимать, что загрузить образ можно только на тот storage, который поддерживает такую возможность. Сторейджи LVM не позволяют загружать образы, для этого нужно использовать, например, storage в виде локальной директории. По умолчанию, один такой есть в системе. В него и загрузим образ вирутальной машины. Для этого открываем нужный сторейдж и выбираем вкладку Content. Жмем на Upload и выбираем нужный образ.

Дожидаемся окончания загрузки. Теперь этот образ можно использовать для установки ОС на виртуальную машину. Создание виртуальной машины выглядит следующим образом. Нажимаем на кнопку Create VM

Заполняем все необходимые поля и стартуем машину. Некоторое время уйдет на создание машины (1-2 минуты). В нижней части экрана ведется лог событий, там увидите информацию об окончании создания:

Выбирайте только что созданную машину и запсукайте ее. Для того, чтобы попасть в консоль виртуальной машины, выбери соответствующий раздел:

Рассказывать про настройку виртуальных машин особенно нечего. Все настройки видны в свойствах машины, выставляйте то, что вам нобходимо и пользуйтесь. Отдельно рассмотрю вопрос автозапуска.

Автозапуск виртуальной машины

По-умолчанию созданные виртуальные машины не запускаются со стартом гипервизора, это нужно делать вручную. Но есть настройка, которая отвечает за автозагрузку виртуальных машин, а так же за порядок их загрузки. Вот список параметров, которыми мы можем управлять:

Рассмотрим простой пример. У нас есть виртуальная машина, к примеру Windows Server с ролью Active Directory на борту. Все остальные серверы завязаны на корректную работу службы каталогов. Нам надо сначала запустить контроллер домена, а затем все остальные серверы за ним. Установите параметр Start at boot в положение Yes для всех виртуальных машин, которые хотите запускать автоматически. Укажите Start/Shutdown order на контроллере домена 1, Startup delay 240, Shutdown timeout 120. С такими настройками при запуске гипервизора первой стартует виртуальная машина с КД, через 240 секунд все остальные в соответствии с их настройками.

Backup виртуальных машин

Подошли к очень важному этапу настройки proxmox — огранизация бэкапа виртуальных машин. На этот момент нужно обратить особенное внимание, и все хорошенько проверить. Настраивается backup так же просто, как и все остальное в proxmox. Идем в раздел Backup и создаем задание:

Выставляем небоходимые параметры, например такие:

Ждем назначенного часа и проверяем исполнение задания.

Для того, чтобы выполнить разовый бэкап конкретной виртуальной машины, достаточно открыть виртуальную машины, выбрать в ней раздел Backup и нажать Backup Now:

Дальше указываете необходимые параметры и дожидаетесь завершения бэкапа. Обращаю внимание, что бэкап будет выполняться при работающей виртуальной машине. Останавливаеть ее не требуется.

Тут сразу встает следующий вопрос — как автоматически удалять старые бэкапы? Однозначно ответить не получится, все будет зависеть от того, где будут храниться бэкапы. Если это обычный linux сервер с доступом к консоли, то можно воспользоваться программой find:

# /usr/bin/find /mnt/backups-vm -type f -mtime +30 -exec rm {} ;

После выполнения этой команды, все файлы в папке /mnt/backups-vm старше 30 дней будут удалены. Для автоматизации процесса команду можно поместить в cron. С помощью zabbix вы можете мониторить актуальность бэкапов и следить за их размерами.

После создания бэкапа рекомендую сразу убедиться, что из него можно восстановить виртуальную машину. Для этого откройте обзор сторейджа, где у вас сделана копия и оттуда начните процесс восстановления. В таком случае вы сможете указать новое имя для виртуальной машины. Если вы будете пробовать восстановить из бэкапа в интерфейсе виртуальной машины, то будет предложена только замена существующей ВМ.

Заключение

Подведем итог тому, что сделали:

• Установили гипервизор proxmox на сервер под управлением Debian на программный raid1, обеспечив отказоустойчивость системы на уровне дисков.
• Настроили виртуальную сеть для виртуальных машин.
• Подключили различные storage для выполнения задач размещения и бэкапа виртуальных машин.
• Добавили и настроили виртуальные машины.
• Организовали атоматический бэкап всех ВМ.

Я постарался выбрать наиболее востребованные функции и описать их, чтобы систему можно было использовать в реальной работе и не бояться за надежность решения. Собрал необходимый минимум, но статься все равно получилась очень большая, объемная. Я не стал ее разделять на части, чтобы была целостная картина всего того, что сделали. Тут есть еще над чем поработать, особенно актуален вопрос бэкапа. Без инкрементного бэкапа неудобно хранить резервные копии на удаленном сервере, очень большой объем передаваемых данных получается. Пока я не изучал подробно этот вопрос, буду рад, если кто-то посоветует хорошее решение для KVM.