На землю из облаков: переезд Proxmox на компьютер в офисе в РФ

Доброго времени суток, Хабр!

Предлагаю вниманию краткую историю переезда одного сервера виртуализации на базе Proxmox из Hetzner в РФ на сервер виртуализации, расположенный в стойке в офисе компании.
Кратко о причинах выбора Proxmox, его особенностях. Википедия о системе виртуализации Proxmox.

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

Если кратко, то главное желание — отсутствие необходимости администрирования запущенного проекта; отсутствие потребности в обновлениях, только по выходу заплаток безопасности; простота веб-интерфейса. Обусловлено тем, что у компании в штате нет настоящего linux-гуру. Так что, практический стандартный Debian решил все вопросы в пользу Proxmox. Еще один плюс — низкая нагрузка ядром виртуализации на процессор(ы) — это действительно так.

Похвалил систему, за остальным прошу под cut.

В связи с ростом курса Евро передаваемая в аренду услуга по предоставлению удаленных рабочих мест на специально арендованном сервере стала дорожать. После расчетов было принято решение о приобретении в физической конфигурации «Процессор 8 x AMD Ryzen 5 1400 Quad-Core Processor (1 Сокет)», 2 * SSD M.2 1ТБ + райзеры к ним для установки в порт PCI-E, 32 Gb ОЗУ. В облаке же машина CPU(s) 8 x Intel® Core(TM) i7 CPU 920 @ 2.67GHz (1 Socket), 2*2ТБ HDD, 47.16 Gb ОЗУ.


Настройки хранилища Proxmox из коробки базируются на томах LVM, хотя есть возможность под хранилище образов использовать и папку ОС и другие варианты файловых систем и даже внешние FTP ресурсы (ниже об этом). На данной машине настроен раздел LVM с именем «data» на диске №1 и прописано хранилище данных proxmox с именем «data», на нем хранятся образы дисков виртуальных машин. На второй диск сохраняются бекапы (снэпшоты) виртуальных машин по некоему графику.

В облаке запущено две клиентских ноды на 4 CPU 16GB ОЗУ каждая и типом процессора core2duo. Их виртуальные диски занимают полностью 2ТБ.


Для переезда анализируем конфигурацию дисков, смотрим размеры полного бекапа, чтобы определить размеры сжатой ноды и место хранения (на новую ноду или на офисное хранилище):

• Нода 1: 200Gb+400Gb+200Gb; Размер бекапа 175Gb
• Нода 2: 200Gb+500Gb; Размер бекапа 7Gb;

Просим клиента разрешить доступ и определяем, что Нода 2 диск 2 не используется, хотя активен. Следовательно, на исходной машине в облаке необходимо верно настроить гостевую ОС и отключить в веб-интерфейсе Proxmox диск на 500GB. При этом он останется привязан к Ноде 2, но будет «отключен», то есть Нода 2 видеть его не будет.

В веб-интерфейсе делается бекап с произведенными изменениями с максимальным сжатием образа диска в GZip. Получаем те же 6Gb в архиве, что собственно и ожидалось.

В офисном пространстве есть хранилище с доступом по FTP, выделен 1Тб для заливки архивных образов виртуальных машин, поэтому решено подключить к папке "/bkps" облачной ОС это хранилище по FTP.



На сервере — приемнике настроены диски так: LVM data1 на 1TB-> Хранилище data1; LVM data2 временно на SSD 256Gb -> Хранилище data2. После переноса образа машины на FTP-шару подключаем ее методом, описанным выше к директории /bkps сервера-приемника. В хранилище сервера-приемника подключаем Директорию "/bkps" как хранилище бекапов и пытаемся восстановить в ранее созданную Ноду 2 из Web-интерфейса. Первые проблемы:

1. Оказывается, что настройки Ноды полностью в архиве, поэтому нет необходимости создавать аналогичную на приемнике с помощью copy-paste.
2. Оказывается, что для распаковки образа в системе требуется хранилище «data», а у нас же нет такого, поэтому процесс разархивации останавливается с ошибкой.

Попытка отредактировать файл «Архив ноды 2.tar.bz2» в MC закончилась неудачей. Пытаюсь на остановленной Ноде 2 из консоли сервера виртуализации с помощью

dd if=/data/vm-101-disk-0 | gzip -9cf > /bkps/vm-101-disk-0.img.gz

залить на FTP и развернуть на сервере-приемнике из консоли в созданный на LVM data2 образ с именем "/dev/data2/vm-101-disk0" с помощью команд:

cd /bkps
ls | grep vm101
gunzip -c vm101-disk-0.img.gz | dd of=/dev/data2/vm101-disk-0

По окончании процесса Нода 2 запустилась корректно, гостевая ОС заработала без дальнейших манипуляций.

С Нодой 1 процесс пошел сложнее, так как с помощью DD не удалось развернуть диск 2 на 400Gb. В чем причина пока мне неизвестна. Так как время поджимало, было принято Соломоново решение: переименовать Хранилище сервера-приемника с «data1» на «data» и развернуть из бекапа Ноду 1. В такой конфигурации процесс пошел отлично, машина запустилась и корректно работает, видит все подключенные диски.

И в заключение кратко о миграции дисков внутри сервера между хранилищами.

1. Останавливаем ноду.
2. В настройках конфигурации ноды наводимся на диск, который нужно мигрировать. Странно, что работает только на подключенном диске, а тот, который не «attached» мигрировать нельзя.
3. Выбираем целевое хранилище и система перемещает его в необходимое Хранилище.

Исходя из заключения можно было переехать и так (бонусный способ переезда для самых настойчивых читателей):

1. на сервере-в-облаке запустить миграцию в произвольную директорию дисков Ноды1 и Ноды2;
2. перенести их копированием на FTP (можно было сжать тем же gzip для уменьшения трафика);
3. развернуть на FTP сервере файл виртуального диска, если мы передавали сжатый образ;
4. подключить (не стартуя) к необходимой Ноде и нажать кнопку «migrate».

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

Спасибо за внимание, надеюсь кому-то этот текст окажется полезен.