Надежное хранилище с drbd9 и proxmox (часть 1: nfs) / хабр

Отказоустойчивый NFS-сервер

К сожалению на момент написания статьи Linstor имеет готовую интеграцию только с Kubernetes. Но в конце года ожидаются драйверы и для остальных систем Proxmox, OpenNebula, OpenStack.

Но пока готового решения нет, а старое нам так или иначе не нравится. Попробуем использовать DRBD9 по старинке для организации NFS-доступа на общий раздел.

Тем не менее данное решение так-же окажется не без плюсов, ведь NFS-сервер позволит вам организовать конкурентный доступ к файловой системе хранилища с нескольких серверов без необходимости использования сложных кластерных файловых систем с DLM, таких как OCFS и GFS2.

При этом вы получите возможность переключать роли Primary/Secondary нод просто мигрируя контейнер с NFS-сервером в интерфейсе Proxmox.

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

В случае если вы используете Kubernetes вы сможете организовать ReadWriteMany доступ для ваших PersistentVolumes.

Тестирование с помощью CrystalDiskMark 6.0.2 x64

Тестирование производилось на VM — Windows Server 2008 R2, 4GB mem, 2 cores. Для тестирования виртуальной машине добавлен отдельный пустой диск 32Gb.

В качестве SSD cache выступал том LVM на SATA диске OCZ Vertex V2 EX.

Тест в Crystal Mark запускался по 3 раза, чтобы данные успевали закешироваться. В таблице приведены данные после третьего замера.

Параметры CrystalMark — 5, 1GiB. Boot Time — время загрузки ОС от включения до появления приглашения Press Ctrl+Alt+Del.

1 — lvm cache — On WriteBack, proxmox cache — no cache, qcow2

2 — lvm cache — On WriteBack, proxmox cache — no cache, raw

3 — lvm cache — On WriteBack, proxmox cache — WriteBack, qcow2 . WARNING — Very High CPU Load while tests!!! Very Long test!!!

4 — lvm cache — On WriteBack, proxmox cache — WriteThrough, qcow2 WARNING — Very High CPU Load while tests!!! Very Long test!!!

5 — lvm cache — On WriteBack, proxmox cache — WriteThrough, raw WARNING — Very High CPU Load while tests!!! Very Long test!!!

6 — lvm cache — On WriteBack, proxmox cache — WriteBack, raw . WARNING — Very High CPU Load while tests!!! Very Long test!!!

Disk Config	Seq Read Q32T1	Seq Write Q32T1	4KiB Q8T8 Read	4KiB Q8T8 Write	4KiB Q32T1 Read	4KiB Q32T1 Write	4KiB Q1T1 Read	4KiB Q1T1 Write	Boot Time, sec
1	217,1	105,3	112,4	84,32	111,4	78,72	12,12	21,75	16
2	218,9	104,6	112,7	86,15	111,8	84,85	11,87	21,58
3	2423	245,6	329,0	163,6	285,6	165,5	39,83	34,49	16
4	2494	84,31	331,4	6,4	289,5	5,5	40,31	4,0
5	2566	90,61	347,9	6,67	301,8	5,86	40,73	4,2
6	2457	210,9	350,5	161	301,1	173,5	40,47	35,9

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

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

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

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

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

Как увеличить диск LVM на ProxMox VE 5.4

Итак приступим. Сперва выключаем нашу виртуальную машину в программе VirtualBox и добавляем место на диске для нашей виртуальной машины.

Меняем размер на 70ГБ:

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

Ниже видно что размер диска sda изменился и стал 70G. Но sda3 раздел диска остался старого размера.

1. Настройка размера раздела LVM через Gparted

Вот так это будет смотреться если вы в VirtualBox на нашей виртуальной машине в оптический привод вставите iso образ LinuxMint, загрузитесь с него и посмотрите через программу Gparted. Видно что физический том LVM не изменился:

Сразу скажу если у вас есть возможность запустить GParted как показано выше, то вы можете и отсюда изменить размер sda3 без потерь следующим образом. Выбираете раздел -> sda3 и в меню, затем Edit ->Resize/Move см. ниже:

Смотрим ниже — тянем коричневую полосу до конца чтобы увеличить размер диска proxmox:

Жмем Resize:

Теперь чтоб применить все изменения нажимаем на галочку:

После выключаем виртуальную машину Proxmox, ставим первой загрузку с жесткого диска -> запускаем виртуальную машину и увидим что размер логической группы pve увеличился на 20G. И после в консоли можно добавить нужный нам размер, например, для логического тома data с помощью команды:

Мы добавили 10G для логического тома data.

2. Увеличение размера LVM Proxmox через треминал

Но бывает так что только через консоль есть возможность изменить размер, и желательно это сделать в самой вирт. машине. Давайте рассмотрим этот вариант. Вернемся к тому что мы добавили нашей виртуальной машине свободного места через VirtualBox, И все выглядит вот так:

Если с LiveCD смотреть то вот так это выглядит:

Итак мы загрузили нашу виртуальную машину Proxmox, зашли на нее по ssh, набрали lsblk, увидели новый размер sda = 70G. Теперь через консоль будем менять размер раздела sda3 а с ним и размер логического тома LMV c именем data:

Первое что нужно сделать это поставить программу parted, это консольная версия программы Gparted:

После успешной установки заходим в parted и выбираем наш диск /dev/sda. Прошу не путать именно /dev/sda:

Далее смотрим наши разделы с помощью команды print:

Cверху на картинке видим что размер нашего lvm диска 42.4 GB и его номер 3. Будем его изменять. Наберем команду resizepart 3 и жмем Enter:

Далее пишем 100%FREE это значит что увеличиваем диск до максимально возможного и жмем Enter:

После выполнения можно снова выполнить команду print и мы увидим новый размер нашего LVM тома который стал 74.6GB:

Далее выходим с помощью команды quit и жмем Enter:

Теперь проверим как все это выглядит с помощью команды:

Итак на картинке сверху мы видим что размер sda3 раздела стал 69.5G но при этом сам LVM том data мы увеличить не сможем, а будет выходить ошибка, давайте попробуем все таки увеличить логический том LVM, и проверим:

Мы видим что изменения не применялись т.к. недостаточно свободного места. Если мы загрузимся с LiveCD в нашу виртуальную машину и посмотрим через программу Gparted то увидим следующую картину:

Дело в том что раздел sda3 мы увеличили, но при этом сам LVM физический том остался прежним. Физический LVM том — как следствие и группа LVM занимают старый объем. Чтобы это изменить надо растянуть физический LVM том на все свободное место для этого мы применим команду pvresize /dev/sda3 и жмем Enter:

На нижней картинке размер физического тома изменился мы это видим в сообщении:

Так же мы это заметим если поочередно введем команды pvs (инф. о физических томах), vgs (инф. о группах LVM). А вот vgs (инф. о логических томах) показывает старый объем для data root и swap т. к. нам его еще предстоит изменить.

Вот так теперь отображается в программе Gparted если загрузиться с LiveCD:

Осталось только добавить свободный объем в логический раздел data. Набираем команду:

Наши 20G добавились:

Проверяем изменения вводим поочередно команды:

Видим что для pvs и vgs неизменны параметры, а команда lvs показывает что наш раздел data стал 38.87G мы видим что он увеличился на 20G. Если мы посмотрим предыдущий вывод команды lvs на снимке, то там видно, что логический том data занимает 18.87G:

В вэб интерфейсе нашей машины мы тоже видим изменения в логическом томе data:

Всем спасибо, рад поделиться опытом.

P.S. Все действия лучше отрабатывайте в виртуальной среде, так как всякое бывает…

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.