Доброго времени суток, Хабр!
Предлагаю вниманию краткую историю переезда одного сервера виртуализации на базе 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ТБ.
Для переезда анализируем конфигурацию дисков, смотрим размеры полного бекапа, чтобы определить размеры сжатой ноды и место хранения (на новую ноду или на офисное хранилище):
Просим клиента разрешить доступ и определяем, что Нода 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-интерфейса. Первые проблемы:
Попытка отредактировать файл «Архив ноды 2.tar.bz2» в MC закончилась неудачей. Пытаюсь на остановленной Ноде 2 из консоли сервера виртуализации с помощью
залить на FTP и развернуть на сервере-приемнике из консоли в созданный на LVM data2 образ с именем "/dev/data2/vm-101-disk0" с помощью команд:
По окончании процесса Нода 2 запустилась корректно, гостевая ОС заработала без дальнейших манипуляций.
С Нодой 1 процесс пошел сложнее, так как с помощью DD не удалось развернуть диск 2 на 400Gb. В чем причина пока мне неизвестна. Так как время поджимало, было принято Соломоново решение: переименовать Хранилище сервера-приемника с «data1» на «data» и развернуть из бекапа Ноду 1. В такой конфигурации процесс пошел отлично, машина запустилась и корректно работает, видит все подключенные диски.
И в заключение кратко о миграции дисков внутри сервера между хранилищами.
Исходя из заключения можно было переехать и так (бонусный способ переезда для самых настойчивых читателей):
Данные манипуляции привели бы к штатной миграции образа виртуального диска в необходимое нам хранилище.
Спасибо за внимание, надеюсь кому-то этот текст окажется полезен.
Предлагаю вниманию краткую историю переезда одного сервера виртуализации на базе 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 ОЗУ.
Кстати, о еще причине ухода из облака
В этом году выходил из строя один из HDD, благо не рабочий, а для хранения снэпшотов виртуальных машин. Длительная переписка с техподдержкой и срок замены в 2 недели так же повлияли на решение о переносе виртуальных машин.
Настройки хранилища Proxmox из коробки базируются на томах LVM, хотя есть возможность под хранилище образов использовать и папку ОС и другие варианты файловых систем и даже внешние FTP ресурсы (ниже об этом). На данной машине настроен раздел LVM с именем «data» на диске №1 и прописано хранилище данных proxmox с именем «data», на нем хранятся образы дисков виртуальных машин. На второй диск сохраняются бекапы (снэпшоты) виртуальных машин по некоему графику.
В облаке запущено две клиентских ноды на 4 CPU 16GB ОЗУ каждая и типом процессора core2duo. Их виртуальные диски занимают полностью 2ТБ.
Особенности установки Proxmox на дистрибутив Debian (в облаке)
Официальный How-To
Смысл в том, что вместо танцев с бубном вокруг скачивания/подключения образа Proxmox можно воспользоваться скриптом для Debian для его установки. Опуская детали, кратко необходимо c правами root:
1) подключить репозиторий без поддержки
2) Обновить данные о доступных пакетах
3) Установить Promox и перезагрузить машину
В результате WEB-Интерфейс будет доступен по адресу: ВашIP:8006/
Смысл в том, что вместо танцев с бубном вокруг скачивания/подключения образа Proxmox можно воспользоваться скриптом для Debian для его установки. Опуская детали, кратко необходимо c правами root:
1) подключить репозиторий без поддержки
echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg
chmod +r /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg
2) Обновить данные о доступных пакетах
apt update && apt dist-upgrade3) Установить Promox и перезагрузить машину
apt remove os-prober
apt install proxmox-ve postfix open-iscsi
reboot
В результате WEB-Интерфейс будет доступен по адресу: ВашIP:8006/
Для переезда анализируем конфигурацию дисков, смотрим размеры полного бекапа, чтобы определить размеры сжатой ноды и место хранения (на новую ноду или на офисное хранилище):
- Нода 1: 200Gb+400Gb+200Gb; Размер бекапа 175Gb
- Нода 2: 200Gb+500Gb; Размер бекапа 7Gb;
Просим клиента разрешить доступ и определяем, что Нода 2 диск 2 не используется, хотя активен. Следовательно, на исходной машине в облаке необходимо верно настроить гостевую ОС и отключить в веб-интерфейсе Proxmox диск на 500GB. При этом он останется привязан к Ноде 2, но будет «отключен», то есть Нода 2 видеть его не будет.
В веб-интерфейсе делается бекап с произведенными изменениями с максимальным сжатием образа диска в GZip. Получаем те же 6Gb в архиве, что собственно и ожидалось.
В офисном пространстве есть хранилище с доступом по FTP, выделен 1Тб для заливки архивных образов виртуальных машин, поэтому решено подключить к папке "/bkps" облачной ОС это хранилище по FTP.
Как подключить в Debian возможность примонтировать FTP-шару к каталогу ОС
Спасибо коллеге, очень полезная статья
Все команды от root:
Должно быть видно содержание шары FTP. Если не видно, то ищем где проблема.
Все команды от root:
apt update
apt install curlftpfs
mkdir /bkps
curlftpfs ftp://$USER:$PASSWD@$HOST:$PORT/ /bkps
cd /bkps
ls
Должно быть видно содержание шары FTP. Если не видно, то ищем где проблема.
fusermount -u /bkps
Создание образа Proxmox для установки с флешки помощью Rufus 3.xx
В привычной мне манере, в привычном ПО из под Windows, выбрал образ, диск флешки и несколько раз не глядя нажал «да», «ок» — кнопки, которые были выделены по умолчанию. В итоге при установке с флешки машина начинает грузиться, а затем выдает сообщение, что ISO образ не найден.
Внимательно перечитав сообщение Rufus выяснил, что он мне предлагает сделать образ флешки либо с помощью развертки из iso на существующий диск либо развернуть образ с помощью DD (CheckBox с Radio-Button). Так вот, надо создавать образ флешки с помощью DD-тогда iso образ находится, Proxmox устанавливается.
Внимательно перечитав сообщение Rufus выяснил, что он мне предлагает сделать образ флешки либо с помощью развертки из iso на существующий диск либо развернуть образ с помощью DD (CheckBox с Radio-Button). Так вот, надо создавать образ флешки с помощью DD-тогда iso образ находится, Proxmox устанавливается.
На сервере — приемнике настроены диски так: LVM data1 на 1TB-> Хранилище data1; LVM data2 временно на SSD 256Gb -> Хранилище data2. После переноса образа машины на FTP-шару подключаем ее методом, описанным выше к директории /bkps сервера-приемника. В хранилище сервера-приемника подключаем Директорию "/bkps" как хранилище бекапов и пытаемся восстановить в ранее созданную Ноду 2 из Web-интерфейса. Первые проблемы:
- Оказывается, что настройки Ноды полностью в архиве, поэтому нет необходимости создавать аналогичную на приемнике с помощью copy-paste.
- Оказывается, что для распаковки образа в системе требуется хранилище «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. В такой конфигурации процесс пошел отлично, машина запустилась и корректно работает, видит все подключенные диски.
И в заключение кратко о миграции дисков внутри сервера между хранилищами.
- Останавливаем ноду.
- В настройках конфигурации ноды наводимся на диск, который нужно мигрировать. Странно, что работает только на подключенном диске, а тот, который не «attached» мигрировать нельзя.
- Выбираем целевое хранилище и система перемещает его в необходимое Хранилище.
Исходя из заключения можно было переехать и так (бонусный способ переезда для самых настойчивых читателей):
- на сервере-в-облаке запустить миграцию в произвольную директорию дисков Ноды1 и Ноды2;
- перенести их копированием на FTP (можно было сжать тем же gzip для уменьшения трафика);
- развернуть на FTP сервере файл виртуального диска, если мы передавали сжатый образ;
- подключить (не стартуя) к необходимой Ноде и нажать кнопку «migrate».
Данные манипуляции привели бы к штатной миграции образа виртуального диска в необходимое нам хранилище.
Спасибо за внимание, надеюсь кому-то этот текст окажется полезен.
