Snippets proxmox что это

Администрирование и не только

Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.

Страницы

понедельник, 16 декабря 2019 г.

Руководство администратора Proxmox VE R 6.0 Глава 8.

Файловая система кластера Proxmox
Оглавление
Directory Backend

Хранилище Proxmox VE

Типы хранилищ
Конфигурация хранилища
Тома
Использование интерфейса командной строки
Directory Backend
NFS Backend
CIFS Backend
GlusterFS Backend
Local ZFS Pool Backend
LVM Backend
LVM thin Backend
Open-iSCSI initiator
User Mode iSCSI Backend
Ceph RADOS Block Devices (RBD)
Ceph Filesystem (CephFS)

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

Типы хранилищ

Тонкая Настройка

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

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

Конфигурация хранилища

Все связанные с Proxmox VE конфигурации хранилища хранятся в одном текстовом файле по адресу /etc/pve/storage.cfg

Пулы Хранения

Каждый пул хранения имеет и однозначно идентифицируется по его .
Конфигурация пула выглядит следующим образом:

Строкой <Тип>: начинается определение пула, затем следует список свойств. Большинство свойств требуют значения, но некоторые имеют разумные значения по умолчанию. В этом случае вы можете опустить значение.

Чтобы быть более конкретным, взгляните на конфигурацию хранилища по умолчанию после установки. Он содержит один специальный локальный пул хранения с именем local, который ссылается на каталог /var/lib/vz и всегда доступен. Программа установки Proxmox VE создает дополнительные записи хранилища в зависимости от типа хранилища, выбранного во время установки.

Конфигурация хранилища по умолчанию ( /etc/pve/storage.cfg )

Общие свойства хранилищ

Тома

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

local:230/example-image.raw local:iso/debian-501-amd64-netinst.iso local:vztmpl/debian-5.0-joomla_1.5.9-1_i386.tar.gz iscsi-storage:0.0.2.scsi-14f504e46494c4500494b5042546d2d646744372d31616d61

Чтобы получить путь к файловой системе для , используйте:

pvesm путь

Владелец тома

Существует отношение собственности для томов типа образ. Каждый такой Том принадлежит виртуальной машине или контейнеру. Например, том local:230/example-image.raw принадлежит VM 230. Большинство серверных систем хранения данных кодирует эту информацию о владельце в имя Тома.

Использование интерфейса командной строки

Рекомендуется ознакомиться с концепцией пулов хранения и идентификаторов томов, но в реальной жизни вы не обязаны выполнять какие-либо из этих низкоуровневых операций в командной строке. Обычно выделение и удаление томов выполняется средствами управления виртуальными машинами и контейнерами.

Примеры

Добавление пулов хранения

pvesm add   pvesm add dir --path pvesm add nfs --path --server --export pvesm add lvm --vgname pvesm add iscsi --portal --target

Отключить пулы хранения

pvesm set --disable 1

Включение пулов хранения

pvesm set --disable 0

Изменение/настройка параметров хранилища

pvesm set  pvesm set --shared 1 pvesm set local --format qcow2 pvesm set --content iso

Удаление пула хранения.
Это не удаляет никаких данных, а также не отключает и не размонтирует ничего. Просто удаляется конфигурация хранилища.

pvesm remove

Выделение томов

pvesm alloc    [--format ]

Выделите том 4G в локальном хранилище. Имя генерируется автоматически, если вы передаете пустую строку в качестве

pvesm alloc local '' 4G

Очистить тома

pvesm free

Внимание! Это действительно уничтожает все данные Тома. Список статусов хранилищ

pvesm status

Список содержимого хранилища

pvesm list [--vmid ]

Список томов, выделенных VMID

pvesm list --vmid

Список iso образов

pvesm list --iso

Список шаблонов контейнеров

pvesm list --vztmpl

Показать путь к файловой системе для Тома

pvesm path

Файловая система кластера Proxmox
Оглавление
Directory Backend

Записки IT специалиста

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Если обратиться к официальной документации, то там будет рассказано о двух основных сетевых конфигурациях: с использованием моста и маршрутизации. Приведенные примеры покрывают основные сценарии использования и не углубляются в подробности, но различные комбинации настроек для этих вариантов позволяют реализовывать самые разнообразные сетевые конфигурации. В данном материале мы рассмотрим базовые возможности Proxmox, не касаясь объединения сетевых адаптеров или использования Open vSwitch, потому как это отдельные темы, лежащие за рамками базовой настройки.

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

Внешняя сеть

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

В основе всех виртуальных сетей в Proxmoх лежит сетевой мост (Linux Bridge) — vmbr, допускается создание до 4095 таких устройств. Сетевой мост может включать в себя как физические, так и виртуальные адаптеры, выполняя для них роль неуправляемого коммутатора. Физическая сетевая карта, подключенная к мосту, не имеет настроек и используется как физический Ehternet-интерфейс для данного виртуального коммутатора. Все сетевые настройки производятся внутри виртуальных машин, которые через мост и физический адаптер прозрачно попадают во внешнюю сеть.

Присвоение интерфейсу моста IP-адреса фактически подключает к виртуальному коммутатору сам хост, т.е. гипервизор, который также прозрачно попадет во внешнюю сеть. Если в Hyper-V для подключения гипервизора к сети на хосте создавался еще один виртуальный сетевой адаптер, то в Proxmox для этого следует назначить IP-адрес интерфейсу моста. Ниже показан пример такой настройки:

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

Фактически это сетевые настройки самого гипервизора. Обратите внимание, что сервера DNS указываются отдельно, в Система — DNS:

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

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

Внешняя изолированная сеть

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

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

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

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

Внутренняя сеть с NAT

Применяется в тех случаях, когда нужно изолировать виртуальные машины в собственной сети, но в тоже время обеспечить им доступ в интернет, а также доступ из внешней сети к некоторым из них (или отдельным сетевым службам). Широко используется в лабораторных сценариях, а также при работе с контейнерами.

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

Все изменения сетевой конфигурации требуют перезагрузки узла гипервизора, поэтому, чтобы не перезагружать узел дважды перейдем в консоль сервера и перейдем в директорию /etc/network, в котором будут присутствовать файлы interfaces — с текущей сетевой конфигурацией и interfaces.new — с новой, которая вступит в силу после перезагрузки.

Откроем именно interfaces.new и внесем в конец следующие строки:

post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.34.0/24' -o ens33 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.34.0/24' -o ens33 -j MASQUERADE

В качестве сети, в нашем случае 192.168.34.0/24, укажите выбранную вами сеть, а вместо интерфейса ens33 укажите тот сетевой интерфейс, который смотрит во внешнюю сеть с доступом в интернет. Если вы используете сетевую конфигурацию по умолчанию, то это будет не физический адаптер, а первый созданный мост vmbr0, как на скриншоте ниже:

Перезагрузим узел и назначим виртуальной машине или контейнеру созданную сеть (vmbr1), также выдадим ей адрес из этой сети, а шлюзом укажем адрес моста.

Не забудьте указать доступный адрес DNS-сервера и убедитесь, что виртуальная машина имеет выход в интернет через NAT.

Внутренняя сеть

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

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

Частная сеть

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

Для такой сети просто создайте еще один сетевой мост без каких-либо настроек:

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

Организуем службы DNS и DHCP для внутренних сетей

Как вы уже могли заметить все адреса для виртуальных машин во внутренних сетях мы назначали вручную. Но можно это делать автоматически, сняв с себя еще одну заботу, это удобно, особенно в лабораторных и тестовых средах, где виртуальных машин много и назначать им адреса вручную может быть достаточно затруднительно.

В нашем примере мы организуем службы DNS и DHCP для внутренней сети с NAT и просто внутренней сети. Для первой мы должны будет выдавать адрес, шлюз и сервера DNS, для второй просто адрес. Данная конфигурация не является реальной, а создана нами исключительно в учебных целях.

В качестве серверов DNS и DHCP мы будем использовать уже известный нашим читателям пакет dnsmasq, который является простым и легким кеширующим DNS и DHCP-сервером. Установим его:

apt install dnsmasq

Затем перейдем в конфигурационный файл /etc/dnsmasq.conf и найдем и приведем к следующему виду параметры:

interface= vmbrl, vmbr2
listen-address= 127.0.0.1, 192.168.34.2, 192.168.35.2

Здесь мы явно указали интерфейсы и адреса, на которых будет работать наш сервер. С одной стороны, присутствует некоторая избыточность, но лучше так, чем потом, при изменении сетевых настроек в вашей сети неожиданно появится неавторизованный DHCP-сервер.

Затем укажем выдаваемые клиентам диапазоны адресов:

dhcp-range=interface:vmbr1,192.168.34.101,192.168.34.199,255.255.255.0,12h
dhcp-range=interface:vmbr2,192.168.35.101,192.168.35.199,255.255.255.0,12h

Обратите внимание на формат записи, перед каждой настройкой мы указываем сетевой интерфейс к которой она применяется.

Аналогичным образом зададим нужные DHCP-опции, в нашем случае это Option 3 и 6 (шлюз и DNS-сервер).

dhcp-option=interface:vmbr1,3,192.168.34.2
dhcp-option=interface:vmbr1,6,192.168.34.2
dhcp-option=interface:vmbr2,3
dhcp-option=interface:vmbr2,6

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

Сохраняем конфигурационный файл и перезапускаем службу

service dnsmasq restart

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Работа с кластером Proxmox: установка, настройка сети, ZFS, решение распространенных проблем

За последние несколько лет я очень тесно работаю с кластерами Proxmox: многим клиентам требуется своя собственная инфраструктура, где они могут развивать свой проект. Именно поэтому я могу рассказать про самые распространенные ошибки и проблемы, с которыми также можете столкнуться и вы. Помимо этого мы конечно же настроим кластер из трех нод с нуля.

Proxmox кластер может состоять из двух и более серверов. Максимальное количество нод в кластере равняется 32 штукам. Наш собственный кластер будет состоять из трех нод на мультикасте (в статье я также опишу, как поднять кластер на уникасте — это важно, если вы базируете свою кластерную инфраструктуру на Hetzner или OVH, например). Коротко говоря, мультикаст позволяет осуществлять передачу данных одновременно на несколько нод. При мультикасте мы можем не задумываться о количестве нод в кластере (ориентируясь на ограничения выше).

Сам кластер строится на внутренней сети (важно, чтобы IP адреса были в одной подсети), у тех же Hetzner и OVH есть возможность объединять в кластер ноды в разных датацентрах с помощью технологии Virtual Switch (Hetzner) и vRack (OVH) — о Virtual Switch мы также поговорим в статье. Если ваш хостинг-провайдер не имеет похожие технологии в работе, то вы можете использовать OVS (Open Virtual Switch), которая нативно поддерживается Proxmox, или использовать VPN. Однако, я рекомендую в данном случае использовать именно юникаст с небольшим количеством нод — часто возникают ситуации, где кластер просто “разваливается” на основе такой сетевой инфраструктуры и его приходится восстанавливать. Поэтому я стараюсь использовать именно OVH и Hetzner в работе — подобных инцидентов наблюдал в меньшем количестве, но в первую очередь изучайте хостинг-провайдера, у которого будете размещаться: есть ли у него альтернативная технология, какие решения он предлагает, поддерживает ли мультикаст и так далее.

Установка Proxmox

Proxmox может быть установлен двумя способами: ISO-инсталлятор и установка через shell. Мы выбираем второй способ, поэтому установите Debian на сервер.

Перейдем непосредственно к установке Proxmox на каждый сервер. Установка предельно простая и описана в официальной документации здесь.

Добавим репозиторий Proxmox и ключ этого репозитория:

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 # optional, if you have a changed default umask

Обновляем репозитории и саму систему:

apt update && apt dist-upgrade

После успешного обновления установим необходимые пакеты Proxmox:

apt install proxmox-ve postfix open-iscsi

Заметка: во время установки будет настраиваться Postfix и grub — одна из них может завершиться с ошибкой. Возможно, это будет вызвано тем, что хостнейм не резолвится по имени. Отредактируйте hosts записи и выполните apt-get update

С этого момента мы можем авторизоваться в веб-интерфейс Proxmox по адресу https://:8006 (столкнетесь с недоверенным сертификатом во время подключения).

Изображение 1. Веб-интерфейс ноды Proxmox

Установка Nginx и Let’s Encrypt сертификата

Мне не очень нравится ситуация с сертификатом и IP адресом, поэтому я предлагаю установить Nginx и настроить Let’s Encrypt сертификат. Установку Nginx описывать не буду, оставлю лишь важные файлы для работы Let’s encrypt сертификата:

/etc/nginx/snippets/letsencrypt.conf

location ^~ /.well-known/acme-challenge/ < allow all; root /var/lib/letsencrypt/; default_type "text/plain"; try_files $uri =404; >

Команда для выпуска SSL сертификата:

certbot certonly --agree-tos --email sos@livelinux.info --webroot -w /var/lib/letsencrypt/ -d proxmox1.domain.name

Конфигурация сайта в NGINX

upstream proxmox1.domain.name < server 127.0.0.1:8006; >server < listen 80; server_name proxmox1.domain.name; include snippets/letsencrypt.conf; return 301 https://$host$request_uri; >server < listen 443 ssl; server_name proxmox1.domain.name; access_log /var/log/nginx/proxmox1.domain.name.access.log; error_log /var/log/nginx/proxmox1.domain.name.error.log; include snippets/letsencrypt.conf; ssl_certificate /etc/letsencrypt/live/proxmox1.domain.name/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/proxmox1.domain.name/privkey.pem; location / < proxy_pass https://proxmox1.domain.name; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_redirect off; proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >

Не забываем после установки SSL сертификата поставить его на автообновление через cron:

0 */12 * * * /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew --renew-hook "systemctl reload nginx"

Отлично! Теперь мы можем обращаться к нашему домену по HTTPS.

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

sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Сетевые настройки

Перед подключением в кластер настроим сетевые интерфейсы на гипервизоре. Стоит отметить, что настройка остальных нод ничем не отличается, кроме IP адресов и названия серверов, поэтому дублировать их настройку я не буду.

Создадим сетевой мост для внутренней сети, чтобы наши виртуальные машины (в моем варианте будет LXC контейнер для удобства) во-первых, были подключены к внутренней сети гипервизора и могли взаимодействовать друг с другом. Во-вторых, чуть позже мы добавим мост для внешней сети, чтобы виртуальные машины имели свой внешний IP адрес. Соответственно, контейнеры будут на данный момент за NAT’ом у нас.

Работать с сетевой конфигурацией Proxmox можно двумя способами: через веб-интерфейс или через конфигурационный файл /etc/network/interfaces. В первом варианте вам потребуется перезагрузка сервера (или можно просто переименовать файл interfaces.new в interfaces и сделать перезапуск networking сервиса через systemd). Если вы только начинаете настройку и еще нет виртуальных машин или LXC контейнеров, то желательно перезапускать гипервизор после изменений.

Теперь создадим сетевой мост под названием vmbr1 во вкладке network в веб-панели Proxmox.

Изображение 2. Сетевые интерфейсы ноды proxmox1

Изображение 3. Создание сетевого моста

Изображение 4. Настройка сетевой конфигурации vmbr1

Настройка предельно простая — vmbr1 нам нужен для того, чтобы инстансы получали доступ в Интернет.

Теперь перезапускаем наш гипервизор и проверяем, создался ли интерфейс:

Изображение 5. Сетевой интерфейс vmbr1 в выводе команды ip a

Заметьте: у меня уже есть интерфейс ens19 — это интерфейс с внутренней сетью, на основе ее будет создан кластер.

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

Также важный этап сейчас заключается во включении форвардинга пакетов — без нее инстансы не будут получать доступ к внешней сети. Открываем файл sysctl.conf и изменяем значение параметра net.ipv4.ip_forward на 1, после чего вводим следующую команду:

sysctl -p

В выводе вы должны увидеть директиву net.ipv4.ip_forward (если не меняли ее до этого)

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

Теперь перейдем непосредственно к кластеру. Каждая нода должна резолвить себя и другие ноды по внутренней сети, для этого требуется изменить значения в hosts записях следующих образом (на каждой ноде должна быть запись о других):

172.30.0.15 proxmox1.livelinux.info proxmox1 172.30.0.16 proxmox2.livelinux.info proxmox2 172.30.0.17 proxmox3.livelinux.info proxmox3

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

Создадим кластер через веб-панель:

Изображение 6. Создание кластера через веб-интерфейс

После создания кластера нам необходимо получить информацию о нем. Переходим в ту же вкладку кластера и нажимаем кнопку “Join Information”:

Изображение 7. Информация о созданном кластере

Данная информация пригодится нам во время присоединения второй и третьей ноды в кластер. Подключаемся к второй ноде и во вкладке Cluster нажимаем кнопку “Join Cluster”:

Изображение 8. Подключение к кластеру ноды

Разберем подробнее параметры для подключения:

Peer Address: IP адрес первого сервера (к тому, к которому мы подключаемся)
Password: пароль первого сервера
Fingerprint: данное значение мы получаем из информации о кластере

Изображение 9. Состояние кластера после подключения второй ноды

Вторая нода успешно подключена! Однако, такое бывает не всегда. Если вы неправильно выполните шаги или возникнут сетевые проблемы, то присоединение в кластер будет провалено, а сам кластер будет “развален”. Лучшее решение — это отсоединить ноду от кластера, удалить на ней всю информацию о самом кластере, после чего сделать перезапуск сервера и проверить предыдущие шаги. Как же безопасно отключить ноду из кластера? Для начала удалим ее из кластера на первом сервере:

pvecm del proxmox2

После чего нода будет отсоединена от кластера. Теперь переходим на сломанную ноду и отключаем на ней следующие сервисы:

systemctl stop pvestatd.service systemctl stop pvedaemon.service systemctl stop pve-cluster.service systemctl stop corosync systemctl stop pve-cluster

Proxmox кластер хранит информацию о себе в sqlite базе, ее также необходимо очистить:

sqlite3 /var/lib/pve-cluster/config.db delete from tree where name = 'corosync.conf'; .quit

Данные о коросинке успешно удалены. Удалим оставшиеся файлы, для этого необходимо запустить кластерную файловую систему в standalone режиме:

pmxcfs -l rm /etc/pve/corosync.conf rm /etc/corosync/* rm /var/lib/corosync/* rm -rf /etc/pve/nodes/*

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

Установка и настройка ZFS

ZFS — это файловая система, которая может использоваться совместно с Proxmox. С помощью нее можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее. Установка ее достаточно простая, приступим к разбору. На моих серверах доступно три SSD диска, которые мы объединим в RAID массив.

nano /etc/apt/sources.list.d/stretch-backports.list deb http://deb.debian.org/debian stretch-backports main contrib deb-src http://deb.debian.org/debian stretch-backports main contrib nano /etc/apt/preferences.d/90_zfs Package: libnvpair1linux libuutil1linux libzfs2linux libzpool2linux spl-dkms zfs-dkms zfs-test zfsutils-linux zfsutils-linux-dev zfs-zed Pin: release n=stretch-backports Pin-Priority: 990

Обновляем список пакетов:

apt update

Устанавливаем требуемые зависимости:

 apt install --yes dpkg-dev linux-headers-$(uname -r) linux-image-amd64

Устанавливаем сам ZFS:

apt-get install zfs-dkms zfsutils-linux

Если вы в будущем получите ошибку fusermount: fuse device not found, try ‘modprobe fuse’ first, то выполните следующую команду:

modprobe fuse

Теперь приступим непосредственно к настройке. Для начала нам требуется отформатировать SSD и настроить их через parted:

Настройка /dev/sda

parted /dev/sda (parted) print Model: ATA SAMSUNG MZ7LM480 (scsi) Disk /dev/sda: 480GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 4296MB 4295MB primary raid 2 4296MB 4833MB 537MB primary raid 3 4833MB 37,0GB 32,2GB primary raid (parted) mkpart Partition type? primary/extended? primary File system type? [ext2]? zfs Start? 33GB End? 480GB Warning: You requested a partition from 33,0GB to 480GB (sectors 64453125..937500000). The closest location we can manage is 37,0GB to 480GB (sectors 72353792..937703087). Is this still acceptable to you? Yes/No? yes

Аналогичные действия необходимо произвести и для других дисков. После того, как все диски подготовлены, приступаем к следующему шагу:

zpool create -f -o ashift=12 rpool /dev/sda4 /dev/sdb4 /dev/sdc4

Мы выбираем ashift=12 из соображений производительности — это рекомендация самого zfsonlinux, подробнее про это можно почитать в их вики: github.com/zfsonlinux/zfs/wiki/faq#performance-considerations

Применим некоторые настройки для ZFS:

zfs set atime=off rpool zfs set compression=lz4 rpool zfs set dedup=off rpool zfs set snapdir=visible rpool zfs set primarycache=all rpool zfs set aclinherit=passthrough rpool zfs inherit acltype rpool zfs get -r acltype rpool zfs get all rpool | grep compressratio

Теперь нам надо рассчитать некоторые переменные для вычисления zfs_arc_max, я это делаю следующим образом:

mem =`free --giga | grep Mem | awk ''` partofmem=$(($mem/10)) echo $setzfscache > /sys/module/zfs/parameters/zfs_arc_max grep c_max /proc/spl/kstat/zfs/arcstats zfs create rpool/data cat > /etc/modprobe.d/zfs.conf /sys/module/zfs/parameters/zfs_arc_max grep c_max /proc/spl/kstat/zfs/arcstats

В данный момент пул успешно создан, также мы создали сабпул data. Проверить состояние вашего пула можно командой zpool status. Данное действие необходимо провести на всех гипервизорах, после чего приступить к следующему шагу.

Теперь добавим ZFS в Proxmox. Переходим в настройки датацентра (именно его, а не отдельной ноды) в раздел «Storage», кликаем на кнопку «Add» и выбираем опцию «ZFS», после чего мы увидим следующие параметры:

ID: Название стораджа. Я дал ему название local-zfs
ZFS Pool: Мы создали rpool/data, его и добавляем сюда.
Nodes: указываем все доступные ноды

Данная команда создает новый пул с выбранными нами дисками. На каждом гипервизоре должен появится новый storage под названием local-zfs, после чего вы сможете смигрировать свои виртуальные машины с локального storage на ZFS.

Репликация инстансов на соседний гипервизор

В кластере Proxmox есть возможность репликации данных с одного гипервизора на другой: данный вариант позволяет осуществлять переключение инстанса с одного сервера на другой. Данные будут актуальны на момент последней синхронизации — ее время можно выставить при создании репликации (стандартно ставится 15 минут). Существует два способа миграции инстанса на другую ноду Proxmox: ручной и автоматический. Давайте рассмотрим в первую очередь ручной вариант, а в конце я предоставлю вам Python скрипт, который позволит создавать виртуальную машину на доступном гипервизоре при недоступности одного из гипервизоров.

Для создания репликации необходимо перейти в веб-панель Proxmox и создать виртуальную машину или LXC контейнер. В предыдущих пунктах мы с вами настроили vmbr1 мост с NAT, что позволит нам выходить во внешнюю сеть. Я создам LXC контейнер с MySQL, Nginx и PHP-FPM с тестовым сайтом, чтобы проверить работу репликации. Ниже будет пошаговая инструкция.

Загружаем подходящий темплейт (переходим в storage —> Content —> Templates), пример на скриншоте:

Изображение 10. Local storage с шаблонами и образами ВМ

Нажимаем кнопку “Templates” и загружаем необходимый нам шаблон LXC контейнера:

Изображение 11. Выбор и загрузка шаблона

Теперь мы можем использовать его при создании новых LXC контейнеров. Выбираем первый гипервизор и нажимаем кнопку “Create CT” в правом верхнем углу: мы увидим панель создания нового инстанса. Этапы установки достаточно просты и я приведу лишь конфигурационный файл данного LXC контейнера:

arch: amd64 cores: 3 memory: 2048 nameserver: 8.8.8.8 net0: name=eth0,bridge=vmbr1,firewall=1,gw=172.16.0.1,hwaddr=D6:60:C5:39:98:A0,ip=172.16.0.2/24,type=veth ostype: centos rootfs: local:100/vm-100-disk-1.raw,size=10G swap: 512 unprivileged:

Контейнер успешно создан. К LXC контейнерам можно подключаться через команду pct enter , я также перед установкой добавил SSH ключ гипервизора, чтобы подключаться напрямую через SSH (в PCT есть небольшие проблемы с отображением терминала). Я подготовил сервер и установил туда все необходимые серверные приложения, теперь можно перейти к созданию репликации.

Кликаем на LXC контейнер и переходим во вкладку “Replication”, где создаем параметр репликации с помощью кнопки “Add”:

Изображение 12. Создание репликации в интерфейсе Proxmox

Изображение 13. Окно создания Replication job

Я создал задачу реплицировать контейнер на вторую ноду, как видно на следующем скриншоте репликация прошла успешно — обращайте внимание на поле “Status”, она оповещает о статусе репликации, также стоит обращать внимание на поле “Duration”, чтобы знать, сколько длится репликация данных.

Изображение 14. Список синхронизаций ВМ

Теперь попробуем смигрировать машину на вторую ноду с помощью кнопки “Migrate”

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

Ошибка “Host Key Verification Failed”

Иногда при настройке кластера может возникать подобная проблема — она мешает мигрировать машины и создавать репликацию, что нивелирует преимущества кластерных решений. Для исправления этой ошибки удалите файл known_hosts и подключитесь по SSH к конфликтной ноде:

/usr/bin/ssh -o 'HostKeyAlias=proxmox2' root@172.30.0.16

Примите Hostkey и попробуйте ввести эту команду, она должна подключить вас к серверу:

/usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=proxmox2' root@172.30.0.16

Особенности сетевых настроек на Hetzner

Переходим в панель Robot и нажимаем на кнопку “Virtual Switches”. На следующей странице вы увидите панель создания и управления интерфейсов Virtual Switch: для начала его необходимо создать, а после “подключить” выделенные сервера к нему. В поиске добавляем необходимые сервера для подключения — их не не нужно перезагружать, только придется подождать до 10-15 минут, когда подключение к Virtual Switch будет активно.

После добавления серверов в Virtual Switch через веб-панель подключаемся к серверам и открываем конфигурационные файлы сетевых интерфейсов, где создаем новый сетевой интерфейс:

auto enp4s0.4000 iface enp4s0.4000 inet static address 10.1.0.11/24 mtu 1400 vlan-raw-device enp4s0

Давайте разберем подробнее, что это такое. По своей сути — это VLAN, который подключается к единственному физическому интерфейсу под названием enp4s0 (он у вас может отличаться), с указанием номера VLAN — это номер Virtual Switch’a, который вы создавали в веб-панели Hetzner Robot. Адрес можете указать любой, главное, чтобы он был локальный.

Отмечу, что конфигурировать enp4s0 следует как обычно, по сути он должен содержать внешний IP адрес, который был выдан вашему физическому серверу. Повторите данные шаги на других гипервизорах, после чего перезагрузите на них networking сервис, сделайте пинг до соседней ноды по IP адресу Virtual Switch. Если пинг прошел успешно, то вы успешно установили соединение между серверами по Virtual Switch.

Я также приложу конфигурационный файл sysctl.conf, он понадобится, если у вас будут проблемы с форвардингом пакетом и прочими сетевыми параметрами:

net.ipv6.conf.all.disable_ipv6=0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.all.forwarding=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.tcp_syncookies=1 net.ipv4.ip_forward=1 net.ipv4.conf.all.send_redirects=0

Добавление IPv4 подсети в Hetzner

Перед началом работ вам необходимо заказать подсеть в Hetzner, сделать это можно через панель Robot.

Создадим сетевой мост с адресом, который будет из этой подсети. Пример конфигурации:

auto vmbr2 iface vmbr2 inet static address ip-address netmask 29 bridge-ports none bridge-stp off bridge-fd 0

Теперь переходим в настройки виртуальной машины в Proxmox и создаем новый сетевой интерфейс, который будет прикреплен к мосту vmbr2. Я использую LXC контейнер, его конфигурацию можно изменять сразу же в Proxmox. Итоговая конфигурация для Debian:

auto eth0 iface eth0 inet static address ip-address netmask 26 gateway bridge-address

Обратите внимание: я указал 26 маску, а не 29 — это требуется для того, чтобы сеть на виртуальной машине работала.

Добавление IPv4 адреса в Hetzner

Ситуация с одиночным IP адресом отличается — обычно Hetzner дает нам дополнительный адрес из подсети сервера. Это означает, что вместо vmbr2 нам требуется использоваться vmbr0, но на данный момент его у нас нет. Суть в том, что vmbr0 должен содержать IP адрес железного сервера (то есть использовать тот адрес, который использовал физический сетевой интерфейс enp2s0). Адрес необходимо переместить на vmbr0, для этого подойдет следующая конфигурация (советую заказать KVM, чтобы в случае чего возобновить работу сети):

auto enp2s0 iface enp2s0 inet manual auto vmbr0 iface vmbr0 inet static address ip-address netmask 255.255.255.192 gateway ip-gateway bridge-ports enp2s0 bridge-stp off bridge-fd 0

Перезапустите сервер, если это возможно (если нет, перезапустите сервис networking), после чего проверьте сетевые интерфейсы через ip a:

2: enp2s0: mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000 link/ether 44:8a:5b:2c:30:c2 brd ff:ff:ff:ff:ff:ff

Как здесь видно, enp2s0 подключен к vmbr0 и не имеет IP адрес, так как он был переназначен на vmbr0.

Теперь в настройках виртуальной машины добавляем сетевой интерфейс, который будет подключен к vmbr0. В качестве gateway укажите адрес, прикрепленный к vmbr0.

В завершении

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

Автор: Илья Андреев, под редакцией Алексея Жадан и команды «Лайв Линукс»

Explaining snippets feature

You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.

timota

Active Member

Oct 14, 2011 9 2 36

recently i discovered that Proxmox now supports great feature — snippets, aka hookscript. Also, it has special content storage type — snippets to hold snippets.

But im curious how they can be used from Web GUI.

Do i need to create hookscript and store it on storage type «snippets» with a special name (vm name) ?
Or do i need to directly edit «vm.conf» files to include hookscript as i could not find any options in GUI.

If this option only supported from CLI and during manually invoking «start» — it useles for daily usage, only for automation/scripting. I mean useles — that if something happens with node and VM has to migrate to another one but we need to prepare ENV before (start some tools, fw, etc) — cluster cant run hook script automatically — admin intervention needed.

Can you please explain more on this feature: how it can be configured ?

mira

Proxmox Staff Member

Staff member
Aug 1, 2018 2,237 285 108

Currently it’s only possible to add a hookscript via CLI. hookscripts have to be on a ‘snippets’-capable storage. All you have to do is create a script in the snippets directory (for the default ‘local’ storage it is /var/lib/vz/snippets), but subdirectories are not supported. Choose whatever name fits the file and add it via ‘qm set —hookscript :snippets/’. The same applies to containers and ‘pct’.
The actions defined in the script are always executed, no matter if started automatically or manually. You have to make sure the script is executable.
If you want to migrate the VM, make sure the hookscript is available on the target node as well. (:snippets/ as configured for the VM/CT has to be available on all nodes you want to migrate to)

In addition snippets can be used to replace the generated cloud-init files (‘network’, ‘user’, ‘meta’, this is undocumented for now). This allows workarounds such as adding a route to a gateway that is not in the subnet on Ubuntu VMs (requires options not supported by cloud-init, but the yaml file is just passed through to netplan because the cloud-init network config is a subset of the netplan config).
You can do this with the following command: ‘qm set —cicustom «network=:snippets/»‘ where ‘network’ can be replaced with ‘user’ or ‘meta’ and they can be mixed by separating them with a comma. («user=. meta=. » or «network=. user=. meta=. «)

Toggle signature

Best regards,
Mira

Do you already have a Commercial Support Subscription? — If not, Buy now and read the documentation