Lvm2

Введение

Использовать систему в работе удобно и за все время использования она меня не подводила. Начинал использование с 4 версии, но вышла 5 версия с очень удобными и функциональными изменениями. Сразу после выхода новой версии любого программного продукта я не спешу обновляться и всегда жду в районе 3 месяцев, так я избавляю себя от ошибок которые всегда есть при выходе любой новой версии. На сайте разработчика есть инструкции как производить обновление на новую версию. Вариант установки как с готового образа iso так и ручная установки на Debian.

Никогда не устанавливайте и не загружайте систему разными сервисными службами, на которой установлен Proxmox, если не хотите иметь проблем при обновлении! Отдавайте под раздел boot минимум 500 мегабайт если не хотите получать ошибку о нехватке места при обновлении ядра!

В моем случае я как раз нарушил оба этих правила и обновить систему не удалось.

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

Введение

Использовать систему в работе удобно и за все время использования она меня не подводила. Начинал использование с 4 версии, но вышла 5 версия с очень удобными и функциональными изменениями. Сразу после выхода новой версии любого программного продукта я не спешу обновляться и всегда жду в районе 3 месяцев, так я избавляю себя от ошибок которые всегда есть при выходе любой новой версии. На сайте разработчика есть инструкции как производить обновление на новую версию. Вариант установки как с готового образа iso так и ручная установки на Debian.

В моем случае я как раз нарушил оба этих правила и обновить систему не удалось.

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

Удаление кластера

Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли — все операции делаем в командной строке.

Подключаемся по SSH к одной из нод кластера. Смотрим все узлы, которые присоединены к нему:

pvecm nodes

Мы получим список нод — удалим все, кроме локальной, например:

pvecm delnode pve2

pvecm delnode pve3

* в данном примере мы удалили ноды pve2 и pve3.

Необходимо подождать, минут 5, чтобы прошла репликация между нодами. После останавливаем следующие службы: 

systemctl stop pvestatd pvedaemon pve-cluster corosync

Подключаемся к базе sqlite для кластера PVE:

sqlite3 /var/lib/pve-cluster/config.db

Удаляем из таблицы tree все записи, поле name в которых равно corosync.conf:

> DELETE FROM tree WHERE name = ‘corosync.conf’;

Отключаемся от базы:

> .quit

Удаляем файл блокировки:

rm -f /var/lib/pve-cluster/.pmxcfs.lockfile

Удаляем файлы, имеющие отношение к настройке кластера:

rm /etc/pve/corosync.conf

rm /etc/corosync/*

rm /var/lib/corosync/*

Запускаем ранее погашенные службы:

systemctl start pvestatd pvedaemon pve-cluster corosync

Кластер удален.

Настройка дисковых накопителей

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

Итак, предположим, что физический сервер имеет 2 диска — /dev/sda, где установлен гипервизор, и пустой диск /dev/sdb, планируемый к использованию для хранения данных ВМ. Дабы система увидела новое хранилище, следует воспользоваться наиболее простым и эффективным способом — подключить его, как обычную директорию. Однако перед этим надо выполнить ряд подготовительных действий. Давайте рассмотрим, каким образом подключить новый диск /dev/sdb любого размера, отформатировав его в файловую систему ext4.

1.Первым делом размечаем диск, создавая новый раздел:

fdisk /dev/sdb

2.Потом нажимаем o или g (разметить диск в MBR или GPT).
3.Далее жмём клавишу n (создаём новый раздел).
4.Потом клавишу w (чтобы сохранить изменения).
5.Тепeрь файловую систему ext4:

mkfs.ext4 /dev/sdb1

6.Пришло время создать директорию, где будем монтировать раздел:

mkdir ```/mnt/storage

7.Откроем конфигурационный файл для редактирования:

nano /etc/fstab

8.Добавим туда новую строку:

/dev/sdb1   /mnt/storage    ext4    defaults    0   0

9.После внесения изменений сохраним их сочетанием Ctrl + X.
10.И проверим, что всё работает, отправив сервер в перезагрузку:

shutdown -r now

11.Потом проверим смонтированные разделы:

df –H

По идее, вывод команды покажет, что /dev/sdb1 смонтирован в директорию /mnt/storage. Таким образом, наш накопитель к работе готов.

Тестирование FIO

Тестовый хост — Pentium Silver J5005, 8GB Ram, mdadm RAID1 2x2Tb Seagate HDD (подключены к SoC AHCI), OCZ Vertex2 EX 100Gb SSD Cache (подключен к ASMedia ASM1061), transparent_hugepage выключены. FIO под Windows Server 2008R2 скачанный отсюда: https://bluestop.org/fio/ у меня не заработал. Все время при запуске падал — fio.exe has stopped working.

Очевидно, это проблемы со сборкой, потому что FIO скачанный отсюда: https://ci.appveyor.com/project/axboe/fio/build/job/1q9lno301yq74mxc/artifacts заработал без проблем.

Тесты запускались такими командами:

fio.exe   --name=baseline --rw=randread --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall
fio.exe   --name=baseline --rw=randwrite --direct=1 --size=1g --iodepth=32 --blocksize=4096 --thread --ioengine=windowsaio --filename=E\:fiotest --name=hddBaseline --stonewall

То есть тест блоками по 4k, случайные чтение и запись, глубина очереди 32, размер тестового файла — 1Gb, без кеширования на уровне Windows (direct=1).

Тесты запускались по три раза, чтобы тестовый файл попал в SSD-кеш.

LVM Cache/PM Cache/Format	Read, MiB/s	Write MiB/s	Read IOPS avg, k	Write IOPS avg, k	CPU Read, %	CPU Write, %
WB/NC/qcow2	133	100	34.0	25.6	26
WB/NC/raw	127	104	32.5	26,6	25
WB/WB/qcow2	158	107	40.5	27,4
WB/WT/qcow2	166	5.3	42.6	1.324	4
WB/WT/raw	154	5.47	39.5	1.335	3.5
WB/WB/raw	150	118	38.3	30.1	23
WT/WT/qcow2	213	0.046	54.5	0.011	21
WT/WB/qcow2	159	9.5	40.8	2.37	0.9
WT/NC/qcow2	128	0.612	32.8	0.152	12.5
WT/NC/raw	121	0.832	30.9	0.208
WT/WT/raw	288	0.041	73.7	0.010	56
WT/WB/raw	137	16.8	35.1	4.303	3.3
NC/WB/raw	146	4.4	37.3	1.099	0.4
NC/WT/raw	148	0.0476	37.8	0.011
NC/NC/raw	1.766	0.694	0.441	0.173	0.33
NC/NC/qcow2	1.830	0.244	0.457	0.061	0.86
NC/WT/qcow2	1.7	0.0465	0.449	0.011
NC/WB/qcow2	3.578	4.889	0.894	1.222	0.47

Результаты тестирования fio

• Предсказуемо, стабильно высокие результаты при минимальной загрузке VCPU показал вариант, когда включено кеширование на LVM и Proxmox в режимах WriteBack. Его недостатком можно считать вероятность потери данных при выходе из строя SSD или отключении питания.
• Не сильно отстает конфигурация с кешированием только на SSD в режиме WriteBack. От выхода из строя SSD можно защититься, использовав два накопителя в зеркальном массиве.
• Разница между форматами qcow2 и raw несущественна, при большей функциональности qcow2.
• В режимах Writeback на уровне proxmox без кеширования на SSD на уровне lvm, скорость записи очень нестабильна. Она может быть как довольно высокой (3000-4000 IOPS), так и довольно низкой (500-1000 IOPS) и меняется произвольным образом.
• Режимы кеширования ProxMox WriteThrough — существенно ускоряют чтение (в 100 раз), но замедляют запись (в 5-20 раз) по сравнению с режимами без кеширования и writeback.
• Возможно, на данной системе можно добиться более высоких результатов, если подключить cache SSD к SoC AHCI. Вот тут есть тестирование производительности разных контроллеров: http://www.thg.ru/storage/vliyaniye_kontrollera_na_skorost_ssd/print.html и ASMedia ASM1061 там далеко не лидер по производительности, а сам SSD по паспорту способен выдавать до 70000 IOPS. C PCI-E SSD результаты должны быть еще интереснее.

Introduction

storage pool type: lvm

LVM is a thin software layer on top of hard disks and partitions. It can be used to split available disk space
into smaller logical volumes. LVM is widely used on Linux and makes managing hard drives easier.

Another use case is to put LVM on top of a big iSCSI LUN. That way you can easily manage space on
that iSCSI LUN, which would not be possible otherwise, because the iSCSI specification does not define a
management interface for space allocation

Configuration

The LVM backend supports the common storage properties content, nodes, disable, and the following LVM specific properties:

• vgname
• base
• saferemove
• saferemove_throughput

General LVM advantages

LVM is a typical block storage, but this backend does not support snapshot and clones. Unfortunately,
normal LVM snapshots are quite inefficient, because they interfere all writes on the whole volume group
during snapshot time.

One big advantage is that you can use it on top of a shared storage, for example an iSCSI LUN. The backend
itself implement proper cluster wide locking.

Note: The newer LVM-thin backend allows snapshot and clones, but does not support shared storage.

Troubleshooting and known issues

Thin Overprovisioning

In a LVM_thin pool there is no space limit when defining LVM volumes in it — regardless if these volumes are virtual disks for containers or virtual machines or just volumes for any other purpose defined by «lvcreate». If the total amount of all defined logical volume size within a thin pool exceeds the physical size of the pool it is called «overprovisioning».

Attention! You can never use more space for data than physically is available! Unfortunately in case of reaching the space limit no direct warning or error message occurs. At the user interface — e.g. inside a virtual machine — it looks like all logical space can be used; but when exceeding the physical limit the data are corrupt!

Therefore it is recommended

— to avoid overprovisioning; or at least, if not possible

— to check regularly via

lvs 

the actual physical usage.

See also «Automatically extend thin pool LV» in

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

Построение кластерной системы выполняется в 2 этапа — сначала мы создаем кластер на любой из нод, затем присоединяем к данному кластеру остальные узлы.

Создание кластера

Переходим в панель управления Proxmox на любой их нод кластера. Устанавливаем курсов на Датацентр — кликаем по Кластер — Создать кластер:

Для создания кластера нам нужно задать его имя и, желательно, выбрать IP-адрес интерфейса, на котором узел кластера будет работать:

… кликаем Создать — процесс не должен занять много времени. В итоге, мы должны увидеть «TASK OK»:

Присоединение ноды к кластеру

На первой ноде, где создали кластер, в том же окне станет активна кнопка Данные присоединения — кликаем по ней:

В открывшемся окне копируем данные присоединения:

Теперь переходим в панель управления нодой, которую хотим присоединить к кластеру. Переходим в Датацентр — Кластер — кликаем по Присоединить к кластеру:

В поле «Данные» вставляем данные присоединения, которые мы скопировали с первой ноды — поля «Адрес сервера» и «Отпечаток заполняться автоматически». Заполняем пароль пользователя root первой ноды и кликаем Присоединение:

Присоединение также не должно занять много времени. Ждем несколько минут для завершения репликации всех настроек. Кластер готов к работе — при подключении к любой из нод мы будем подключаться к кластеру:

Готово. Данный кластер можно использовать для централизованного управления хостами Proxmox.

Посмотреть статус работы кластера можно командой в SSH:

pvecm status

Настраиваем автозапуск

По умолчанию Proxmox не запускает машины автоматически. Однако это решается довольно просто:
1. Щелкаем по названию интересующей машины.
2. Выбираем вкладку «Опции» ➝ «Запуск при загрузке».
3. Отмечаем галочкой одноимённую надпись.

В итоге, при перезагрузке физического сервера, машина запустится автоматически.

Кроме того, продвинутый администратор может указать дополнительные параметры запуска (они находятся в разделе «Start/Shutdown order»). Вы можете явно указать, в каком порядке надо запускать машины. Вдобавок к этому, вы можете указать время, которое должно пройти до старта следующей машины, плюс время задержки выключения (когда ОС не успевает завершить работу, гипервизор выключит её принудительно через определенное число секунд).

Источник — блог компании Selectel.

Резервное копирование виртуальных машин

Приступим к настройке резервного копирования виртуальных машин. Для этого мы используйте хранилище home. Чуть подробнее распишем рекомендации, данные в начале статьи. Основная рекомендация: настраивайте хранилище архивных копий в другом расположении, нежели рабочие виртуальные машины, например, можно также подключить FTP или Samba хранилище. Все это легко реализуется на базе Debian 10 с Proxmox VE.

Перейдите Датацентр, pve-test, VM100, в правом меню выберите раздел Резервная копия и нажмите кнопку Создать резервную копию сейчас:

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

Чтобы настроить планировщик резервных копий нужно перейти в дереве в Датацентр и выбрать в правом меню пункт Резервная копия и нажать кнопку Добавить. Ниже показано, как можно настроить резервирование VM100 каждый чётный день недели в 01:45 локального времени сервера, с хорошим сжатием GZIP и отправлять при ошибках уведомление по почте:

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

По этим же причинам, необходимо тщательно подходить к выбору размера виртуального диска, например не выделять на виртуальную машину один диск 90Gb, а три по 30Gb. Во-первых, восстанавливать меньше, если один из виртуальных дисков вышел из строя. Во-вторых, сжатие и восстановление занимает меньше времени за счёт распараллеливания ресурсов хоста Debian 10 с Proxmox VE.

6.2) HA

Сервис HA нужно включать для каждой отдельной VM

Внимание: перед включением HA убедитесь, что данная VM выключена

Так выглядит статус VM без HA:

Добавляем VM в HA:

Активируем:

Новый статус VM с HA:

Все! Не забывайте подключать новые VM в HA.

7) Если хранилища нет

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

raw

• наилучшая производительность
• резервирует место под виртуалку полностью (фиксированный диск)

qcow2

• возможность делать snapshot (в т.ч. “живые”)
• резервирует место под виртуалку НЕ полностью (динамический диск)

vmdk

• полная совместимость с VMware
• резервирует место под виртуалку НЕ полностью (динамический диск)

Файлы контейнеров OpenVZ хранятся на самой ноде здесь: /var/lib/vz/private/ID (где ID – айди конейнера в веб-интерфейсе)

Работа с OpenVZ

Кратко: контейнеры рекомендуются к использованию, если речь идет о ноде без подключенного к ней хранилища и гостевой linux системе. Колоссальная экономия ресурсов + расширение диска/памяти “на лету”.

Чтобы зайти в контейнер, нужно с ноды выполнить команду (где 109 – ID виртуалки):

vzctl enter 109

Все, потом настраивайте ОС как вам надо, устанавливаете весь софт (все как на обычной виртуалке). Когда вы полностью настроите контейнер, давайте сделаем из него шаблон… потом уже из этого шаблона можно расплодить целую кучу контейнеров. Прежде чем приступить, нажмите Shutdown в веб-интерфейсе и полностью погасите нужный вам контейнер. Потом, через веб-интерфейс полностью удалите сетевой интерфейс контейнера:

После этого, зайдите в папку с ID вашего контейнера и выполните команду (где 109 – ID контейнера, а your-template – имя вашего шаблона):

cd /var/lib/vz/private/109
tar -cvzpf /var/lib/vz/template/cache/your-temptate.tar.gz .

Точка в конце строки важна, не трогайте ее!

Все, новый шаблон для контейнеров готов к работе. Он появится в веб-интерфейсе Proxmox.

Эксплуатация

Эксплуатация системы реализована полностью через веб-интерфейс, так что никакие доп. требования и доп. ПО не потребуется. Разве что для функции “Console” (просмотра рабочего стола VM) рекомендую установить вам локально Java. Т.к. просмотр рабочего стола возможен в двух режимах: c VNC и без VNC. Режим с VNC – полнофункционален и он работает через Java.

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

Пользуйтесь с удовольствием!)

Создаём виртуальную машину

Чтобы создать ВМ:
1. Определяемся с версией ОС.
2. Закачиваем ISO-образ (заранее).
3. Выбираем в меню «Хранилище» только что вами созданное.
4. Нажимаем «Содержимое» ➝ «Загрузить».
5. Выбираем ISO-образ из списка, потом подтверждаем выбор кнопкой «Загрузить».

В итоге образ отобразится в списке доступных.

Теперь создадим первую виртуальную машину:
1. Следует нажать «Создать VM».
2. Потом необходимо заполнить поочередно параметры: «Имя» ➝ «ISO-Image» ➝ Размер и тип жесткого диска ➝ Количество процессоров ➝ Объем оперативной памяти ➝ Сетевой адаптер.
3. Выбираем желаемые параметры и нажимаем «Завершить». Созданная виртуальная машина отобразится в меню панели управления.
4. Выбираем эту машину и запускаем её соответствующей кнопкой.
5. Переходим в «Консоль» и устанавливаем ОС так же, как и на любой физический сервер.

Если нужно создать ещё одну ВМ, следует повторить вышеописанные операции.

Установка Proxmox 5 с нюансами

В дальнейшем будем исходить из того что:

• Настроена пересылка почты на внешний адрес,
• Установлен SWAP раздел в виде файла,
• Используется mdadm raid1,
• Используется два сетевых интерфейса.

Инструкция по установке от разработчика Proxmox

Изучив инструкцию разработчика и мою предыдущую статью у вас придет понимание о том как необходимо правильно устанавливать систему виртуализации.

Подключение старых Raid 1 масивов

В моем случае в старой системе было 2 диска на которых было 2 массива RAID1. После подключения дисков в Proxmox 5 выведем информацию о массивах:

Видим два массива md126 и md127. Такую нумерацию дала система по умолчанию. Меня это не совсем устраивает и я переименую их в md2 и md3 соотвественно. Переименование осуществляем стандартным способом. Останавливаем и удаляем массив:

Добавляем в /etc/mdadm/mdadm.conf нужную информацию:

Проверим выполненные действия:

Все хорошо. Мы изменили название массива, но после перезагрузки вы удивитесь что названия не изменились и это особенность системы Proxmox.

Обновим ядро выполнив необходимую команду:

Все другие массивы делаем аналогичным способом.

Настройка сетевых интерфейсов

Настройка сетевых интерфейсов это отдельная тема и сильно вникать в детали я не буду. Расскажу как использую я и что считаю самым удобным и оптимальным при использовании. В случае использования одного сетевого интерфейса все просто. Создаете Bridge и все виртуальные машины будут в одной локальной сети. При использовании двух сетевых интерфейсов варианты реализации увеличиваются. В моем случае сетевой шлюз расположен на виртуальной машине и весь сетевой трафик идет через него. Для такого варианта реализации на обоих сетевых интерфейсах создаем Bridge. Вот так выглядят мои сетевые настройки в панели управления Proxmox 5:

На всякий случай, для понимания, приведу пример как это выглядит в файле настроек сетевых интерфейсов:

Распишу что к чему в этой настройке:

• enp5s0f1 — физическая сетевая карта в которую вставлен провод от внешней сети с которой получаю интернет от роутера Asus,
• vmbr1 — Bridge сетевой карты enp5s0f1 которому назначен сетевой адрес 192.168.1.100 и другие необходимые параметры,
• enp5s0f0 — физическая сетевая карта которая работает с внутренней локальной сетью,
• vmbr0 — Bridge сетевой карты enp5s0f0 которому назначен сетевой адрес 192.168.0.100 и другие необходимые параметры.

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

Проброс портов в локальную сеть с интернета

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

1. Пробрасываем порт с роутера Asus на машину с установленным шлюзом,
2. На самом шлюзе пробрасываем порт до нужной машины.

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

Репликация виртуальных машин

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

Настройка ZFS

Репликация может выполняться только на тома ZFS. Подробная работа с данной файловой системой выходит за рамки данной инструкции, однако, мы разберем основные команды, с помощью которых можно создать необходимы том.

Пул ZFS необходимо создавать из командной строки, например:

zpool create -f zpool1 /dev/sdc

* в данном примере мы создадим пул с названием zpool1 из диска /dev/sdc.

Теперь открываем панель управления Proxmox. Переходим в Датацентр — Хранилище — ZFS:

Задаем настройки для создания хранилища из созданного ранее пула ZFS:

* в данном примере мы создаем хранилище из пула zpool1; название для хранилище задаем zfs-pool, также ставим галочку Дисковое резервирование. Остальные настройки оставляем по умолчанию.

После этого мы должны либо перенести виртуальную машину на хранилище ZFS, либо создать в нем новую машину.

Настройка репликации

Переходим к хосту, где находится виртуальная машина, для которой мы хотим настроить клонирование (она должна также находится на хранилище ZFS) — Репликация:

Задаем настройки для репликации виртуальной машины:

* в данном примере мы указываем системе проверять и реплицировать изменения каждые 15 минут для виртуальной машины с идентификатором 100. Репликация должна проводиться на сервер pve2.

Нажимаем Создать — теперь ждем репликации по расписанию или форсируем событие, кликнув по Запустить сейчас: