Доброго времени суток, Хабр!
Предлагаю вниманию краткую историю переезда одного сервера виртуализации на базе Proxmox из Hetzner в РФ на сервер виртуализации, расположенный в стойке в офисе компании.
Кратко о причинах выбора Proxmox, его особенностях. Википедия о системе виртуализации Proxmox
Размещено в качестве пособия самому себе и желающим, чтобы не восстанавливать порядок действий и не терять время на тех подводных камнях, о которых, собственно, в статье ниже.
Если кратко, то главное желание — отсутствие необходимости администрирования запущенного проекта; отсутствие потребности в обновлениях, только по выходу заплаток безопасности; простота веб-интерфейса. Обусловлено тем, что у компании в штате нет настоящего linux-гуру. Так что, практический стандартный Debian решил все вопросы в пользу Proxmox. Еще один плюс — низкая нагрузка ядром виртуализации на процессор(ы) — это действительно так.
В связи с ростом курса Евро передаваемая в аренду услуга по предоставлению удаленных рабочих мест на специально арендованном сервере стала дорожать. После расчетов было принято решение о приобретении в физической конфигурации «Процессор 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 из консоли сервера виртуализации с помощью
По окончании процесса Нода 2 запустилась корректно, гостевая ОС заработала без дальнейших манипуляций.
С Нодой 1 процесс пошел сложнее, так как с помощью DD не удалось развернуть диск 2 на 400Gb. В чем причина пока мне неизвестна. Так как время поджимало, было принято Соломоново решение: переименовать Хранилище сервера-приемника с «data1» на «data» и развернуть из бекапа Ноду 1. В такой конфигурации процесс пошел отлично, машина запустилась и корректно работает, видит все подключенные диски.
И в заключение кратко о миграции дисков внутри сервера между хранилищами:
1. Останавливаем ноду
2. В настройках конфигурации ноды наводимся на диск, который нужно мигрировать. Странно, что работает только на подключенном диске, а тот, который не «attached» мигрировать нельзя.
3. Выбираем целевое хранилище и система перемещает его в необходимое Хранилище
Исходя из заключения можно было переехать и так (бонусный способ переезда для самых настойчивых читателей):
1) На сервере-в-облаке запустить миграцию в произвольную директорию дисков Ноды1 и Ноды2;
2) Перенести их копированием на FTP (можно было сжать тем же gzip для уменьшения трафика);
3) Развернуть на FTP сервере файл виртуального диска, если мы передавали сжатый образ;
4) подключить (не стартуя) к необходимой Ноде и нажать кнопку «migrate».
Данные манипуляции привели бы к штатной миграции образа виртуального диска в необходимое нам хранилище.
Спасибо за внимание, надеюсь кому-то этот текст окажется полезен.
Предлагаю вниманию краткую историю переезда одного сервера виртуализации на базе Proxmox из Hetzner в РФ на сервер виртуализации, расположенный в стойке в офисе компании.
Кратко о причинах выбора Proxmox, его особенностях. Википедия о системе виртуализации Proxmox
Размещено в качестве пособия самому себе и желающим, чтобы не восстанавливать порядок действий и не терять время на тех подводных камнях, о которых, собственно, в статье ниже.
Если кратко, то главное желание — отсутствие необходимости администрирования запущенного проекта; отсутствие потребности в обновлениях, только по выходу заплаток безопасности; простота веб-интерфейса. Обусловлено тем, что у компании в штате нет настоящего linux-гуру. Так что, практический стандартный Debian решил все вопросы в пользу Proxmox. Еще один плюс — низкая нагрузка ядром виртуализации на процессор(ы) — это действительно так.
В связи с ростом курса Евро передаваемая в аренду услуга по предоставлению удаленных рабочих мест на специально арендованном сервере стала дорожать. После расчетов было принято решение о приобретении в физической конфигурации «Процессор 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-upgrade
3) Установить 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-интерфейса. Первые проблемы:
1. Оказывается, что настройки Ноды полностью в архиве, поэтому нет необходимости создавать аналогичную на приемнике с помощью copy-paste.
2. Оказывается, что для распаковки образа в системе требуется хранилище «data», а у нас же нет такого, поэтому процесс разархивации останавливается с ошибкой.
Попытка отредактировать файл «Архив ноды 2.tar.bz2» в MC закончилась неудачей. Пытаюсь на остановленной Ноде 2 из консоли сервера виртуализации с помощью
dd if=/data/vm-101-disk-0 | grep -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».
Данные манипуляции привели бы к штатной миграции образа виртуального диска в необходимое нам хранилище.
Спасибо за внимание, надеюсь кому-то этот текст окажется полезен.