lae.proxmox

Устанавливает и настраивает Proxmox Virtual Environment 6.x/7.x/8.x на серверах Debian.

Эта роль позволяет вам развертывать и управлять однобазовыми установками PVE и PVE кластерами (3 и более узлов) на Debian Buster (10) и Bullseye (11). С помощью этой роли вы сможете настроить следующее:

• Определения RBAC PVE (роли, группы, пользователи и списки управления доступом)
• Определения хранилищ PVE
• datacenter.cfg
• HTTPS-сертификаты для веб-интерфейса Proxmox (принесите свои)
• Выбор репозитория PVE (например, pve-no-subscription или pve-enterprise)
• Модули контроллера (IPMI и NMI) с соответствующей конфигурацией pve-ha-manager
• Настройка ZFS и уведомления по электронной почте ZED

С включенной кластеризацией эта роль делает (или позволяет вам делать) следующее:

• Убедитесь, что все узлы могут подключаться друг к другу как root через SSH
• Инициализировать новый кластер PVE (или, возможно, принять существующий)
• Создать или добавить новые узлы в кластер PVE
• Настроить Ceph на кластере PVE
• Создать и управлять группами высокой доступности

Поддержка/Участие

Для поддержки или если вы хотите внести вклад в эту роль, но вам нужна помощь, не стесняйтесь присоединяться к этому серверу Discord: https://discord.gg/cjqr6Fg. Пожалуйста, обратите внимание, что это временное приглашение, поэтому вам нужно дождаться, пока @lae назначит вам роль, иначе Discord удалит вас с сервера после выхода.

Быстрый старт

Основная цель этой роли - настроить и управлять кластерами Proxmox VE (см. пример плейбука), однако эту роль также можно использовать для быстрой установки однобазовых серверов Proxmox.

Я предполагаю, что у вас уже установлен Ansible. Вам нужно будет использовать внешнюю машину для установки Proxmox (в первую очередь из-за перезагрузки во время установки, хотя я могу немного иначе подойти к этому в будущем).

Скопируйте следующий плейбук в файл, например, install_proxmox.yml:

- hosts: all
  become: True
  roles:
    - role: geerlingguy.ntp
      vars:
        ntp_manage_config: true
        ntp_servers:
          - clock.sjc.he.net
          - clock.fmt.he.net
          - clock.nyc.he.net
    - role: lae.proxmox
      vars:
        - pve_group: all
        - pve_reboot_on_kernel_update: true

Установите эту роль и роль для настройки NTP:

ansible-galaxy install lae.proxmox geerlingguy.ntp

Теперь вы можете выполнить установку:

ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER

Если ваш SSH_USER имеет пароль sudo, передайте флаг -K в вышеуказанную команду. Если вы также аутентифицируетесь на хосте по паролю вместо использования публичного ключа, передайте флаг -k (убедитесь, что у вас также установлен sshpass). Вы можете задать эти переменные перед выполнением команды или просто заменить их. Обратите внимание, что запятая важна, так как ожидается список (иначе он попытается найти файл со списком узлов).

После завершения установки вы сможете получить доступ к вашему экземпляру Proxmox VE по адресу https://$SSH_HOST_FQDN:8006.

Развертывание полнофункционального кластера PVE 8.x

Создайте новый каталог плейбука. Мы назвали его lab-cluster. Наш плейбук в конечном итоге будет выглядеть так, но вам не обязательно следовать всем шагам:

lab-cluster/
├── files
│   └── pve01
│       ├── lab-node01.local.key
│       ├── lab-node01.local.pem
│       ├── lab-node02.local.key
│       ├── lab-node02.local.pem
│       ├── lab-node03.local.key
│       └── lab-node03.local.pem
├── group_vars
│   ├── all
│   └── pve01
├── inventory
├── roles
│   └── requirements.yml
├── site.yml
└── templates
    └── interfaces-pve01.j2

6 директорий, 12 файлов

Первое, что вы можете заметить, это то, что у нас есть множество файлов .key и .pem. Это закрытые ключи и SSL-сертификаты, которые эта роль будет использовать для настройки веб-интерфейса Proxmox на всех узлах. Они не обязательны, однако, если вы хотите продолжать использовать подписанные сертификаты, предоставленные CA, которые Proxmox настраивает внутренне. Обычно вы можете использовать Ansible Vault для шифрования закрытых ключей, например:

ansible-vault encrypt files/pve01/*.key

Это потребует ввести пароль Vault при запуске плейбука.

Сначала давайте укажем наши кластерные узлы. Наш файл inventory может выглядеть так:

[pve01]
lab-node01.local
lab-node02.local
lab-node03.local

Вы можете иметь несколько кластеров, поэтому хорошей идеей будет создание одной группы для каждого кластера. Теперь давайте укажем наши требования к ролям в roles/requirements.yml:

---
- src: geerlingguy.ntp
- src: lae.proxmox

Нам нужна роль NTP для его настройки, поэтому мы используем роль Джеффа Гирлингa для этого. Вам не нужна эта роль, если настройки NTP уже выполнены или у вас есть другой метод настройки NTP.

Теперь давайте укажем несколько групповых переменных. Сначала создадим group_vars/all для установки переменных, связанных с NTP:

---
ntp_manage_config: true
ntp_servers:
  - lab-ntp01.local iburst
  - lab-ntp02.local iburst

Конечно, замените эти серверы NTP на более предпочитаемые.

Теперь перейдем к основной части вашего плейбука, переменные группы pve01. Создайте файл group_vars/pve01, добавьте следующее и измените по необходимости для вашего окружения.

---
pve_group: pve01
pve_watchdog: ipmi
pve_ssl_private_key: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.key') }}"
pve_ssl_certificate: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.pem') }}"
pve_cluster_enabled: yes
pve_groups:
  - name: ops
    comment: Операционная команда
pve_users:
  - name: admin1@pam
    email: [email protected]
    firstname: Admin
    lastname: User 1
    groups: [ "ops" ]
  - name: admin2@pam
    email: [email protected]
    firstname: Admin
    lastname: User 2
    groups: [ "ops" ]
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "ops" ]
pve_storages:
  - name: localdir
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /plop
    maxfiles: 4
pve_ssh_port: 22

interfaces_template: "interfaces-{{ pve_group }}.j2"

pve_group установлен на имя группы нашего кластера, pve01 - это название, которое будет использоваться для обеспечения возможности всем узлам в этой группе подключаться друг к другу и быть объединенными в кластер. Обратите внимание, что имя кластера PVE также будет установлено на это имя группы, если не указано другое значение pve_cluster_clustername. Если оставить это значение неопределенным, оно по умолчанию будет proxmox.

pve_watchdog здесь включает поддержку IPMI watchdog и настраивает PVE для использования его в менеджере высокой доступности. Оставьте это неопределенным, если не хотите настраивать его.

pve_ssl_private_key и pve_ssl_certificate указывают на SSL-сертификаты для pvecluster. Здесь используется поиск файла для чтения содержимого файла в плейбуке, например, files/pve01/lab-node01.key. Вы могли бы также использовать переменные хостов вместо файлов, если предпочтете.

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

pve_groups, pve_users и pve_acls авторизуют некоторых локальных пользователей UNIX (они должны уже существовать) для доступа к PVE и предоставляют им роль администратора как часть группы ops. Читайте раздел Управление пользователями и ACL для получения дополнительной информации.

pve_storages позволяет создавать различные типы хранилищ и настраивать их. Бэкенд должен поддерживаться Proxmox. Читайте раздел Управление хранилищем для получения дополнительной информации.

pve_ssh_port позволяет изменить порт SSH. Если ваш SSH слушает на порту, отличном от стандартного 22, пожалуйста, установите эту переменную. Если новый узел присоединяется к кластеру, кластеру PVE необходимо один раз установить связь через SSH.

pve_manage_ssh (по умолчанию true) позволяет вам отключить любые изменения, которые этот модуль может внести в конфигурацию вашего SSH-сервера. Это полезно, если вы используете другую роль для управления вашим SSH-сервером. Обратите внимание, что установка этого значения в false не поддерживается официально, вам нужно будет самостоятельно воспроизвести изменения, обычно внесенные в ssh_cluster_config.yml и pve_add_node.yml.

interfaces_template установлен на путь к шаблону, который мы будем использовать для настройки сети на этих машинах Debian. Это необходимо только в том случае, если вы хотите управлять настройками сети из Ansible, а не вручную или через каждый хост в PVE. Вероятно, вам следует познакомиться с Ansible перед тем, как это делать, так как ваш метод может включать установку переменных хостов для IP-адресов для каждого хоста и т. д.

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

# {{ ansible_managed }}
auto lo
iface lo inet loopback

allow-hotplug enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0
iface vmbr0 inet static
    address {{ lookup('dig', ansible_fqdn) }}
    gateway 10.4.0.1
    netmask 255.255.255.0
    bridge_ports enp2s0f0
    bridge_stp off
    bridge_fd 0

allow-hotplug enp2s0f1
auto enp2s0f1
iface enp2s0f1 inet static
    address {{ lookup('dig', ansible_hostname + "-clusternet.local") }}
    netmask 255.255.255.0

Вы можете не знать о поиске dig, но, в основном, мы выполняем запрос записи A для каждой машины (например, lab-node01.local) для первого интерфейса (и настраиваем его как мост, который мы будем использовать для интерфейсов ВМ), а затем еще один слегка измененный поиск для "кластерной" сети, которую мы, возможно, будем использовать для Ceph ("lab-node01-clusternet.local"). Конечно, ваш шаблон может выглядеть совершенно иначе, особенно если вы используете связь, три разные сети для управления/коросинк, хранения и трафика ВМ и т. д.

Наконец, давайте напишем наш плейбук. site.yml будет выглядеть примерно так:

---
- hosts: all
  become: True
  roles:
    - geerlingguy.ntp

# Оставьте это, если не изменяете сетевые настройки через Ansible
- hosts: pve01
  become: True
  serial: 1
  tasks:
    - name: Установить bridge-utils
      apt:
        name: bridge-utils

    - name: Настроить /etc/network/interfaces
      template:
        src: "{{ interfaces_template }}"
        dest: /etc/network/interfaces
      register: _configure_interfaces

    - block:
      - name: Перезагружаемся для применения сетевых изменений
        shell: "sleep 5 && shutdown -r now 'Найдены изменения в сети, перезагрузка'"
        async: 1
        poll: 0

      - name: Дождаться повторного включения сервера
        wait_for_connection:
          delay: 15
      when: _configure_interfaces is changed

- hosts: pve01
  become: True
  roles:
    - lae.proxmox

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

На данном этапе наш плейбук готов, и мы можем его запустить.

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

ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython

jmespath требуется для некоторых задач, связанных с кластеризацией. dnspython требуется только в том случае, если вы используете поиск dig, что, вероятно, не будет необходимо, если вы пропустили настройки сети. Мы передаем параметр --force в ansible-galaxy, чтобы роли обновлялись до последних версий, если они уже установлены.

Теперь запустите плейбук:

ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'

Параметр -e '{"pve_reboot_on_kernel_update": true}' в основном следует запускать в первый раз, когда вы настраиваете кластер Proxmox, так как он перезагрузит сервер, чтобы загрузиться в ядро PVE. Последующие запуски должны обходиться без этого параметра, так как вы хотите поочередно перезагружать серверы после запуска кластера.

Чтобы указать конкретного пользователя, используйте -u root (замените root) и, если вам нужно предоставить пароли, используйте -k для пароля SSH и/или -K для пароля sudo. Например:

ansible-playbook -i inventory site.yml -K -u admin1

Это запросит пароль sudo, затем войдет в пользователя admin1 (используя аутентификацию с публичным ключом - добавьте -k для пароля) и запустит плейбук.

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

Пример плейбука

Это настроит узлы в группе pve01 как один кластер, а также перезагрузит машины, если ядро было обновлено. (Рекомендуется устанавливать этот флаг во время установки - перезагрузки во время работы должны происходить последовательно в течение периода обслуживания.) Это также включит IPMI watchdog.

- hosts: pve01
  become: True
  roles:
    - role: geerlingguy.ntp
        ntp_manage_config: true
        ntp_servers:
          - clock.sjc.he.net
          - clock.fmt.he.net
          - clock.nyc.he.net
    - role: lae.proxmox
        pve_group: pve01
        pve_cluster_enabled: yes
        pve_reboot_on_kernel_update: true
        pve_watchdog: ipmi

Переменные роли

[переменная]: [по умолчанию] #[описание/цель]
pve_group: proxmox # группа хостов, в которой находятся Proxmox-узлы, которые необходимо объединить в кластер
pve_repository_line: "deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription" # конфигурация apt-репозитория - измените на enterprise, если необходимо (хотя может потребоваться дальнейшая настройка)
pve_remove_subscription_warning: true # исправляет сообщения об ошибке подписки в proxmox, если вы используете сообщество
pve_extra_packages: [] # любые дополнительные пакеты, которые вы можете захотеть установить, например, ngrep
pve_run_system_upgrades: false # разрешить роли выполнять обновления системы
pve_run_proxmox_upgrades: true # разрешить роли выполнять обновления Proxmox VE
pve_check_for_kernel_update: true # запускает скрипт на хосте для проверки версий ядра
pve_reboot_on_kernel_update: false # если установлено в true, автоматически перезагрузит машину при обновлении ядра
pve_reboot_on_kernel_update_delay: 60 # количество секунд, которые нужно подождать перед и после процесса перезагрузки для продолжения следующей задачи в кластерном режиме
pve_remove_old_kernels: true # в настоящее время удаляет ядро из основного репозитория Debian
pve_pcie_passthrough_enabled: false # установите это в true, чтобы включить PCIe passthrough.
pve_iommu_passthrough_mode: false # установите это в true, чтобы разрешить ВМ обходить трансляцию DMA. Это может повысить производительность для IOMMU passthrough.
pve_iommu_unsafe_interrupts: false # установите это в true, если ваша система не поддерживает перенаправление прерываний.
pve_mediated_devices_enabled: false # установите это в true, если ваше устройство поддерживает gtv-g и вы хотите включить функциональность разделения.
pve_pcie_ovmf_enabled: false # установите это в true, чтобы включить GPU OVMF PCI passthrough.
pve_pci_device_ids: [] # список идентификаторов pci-устройств (см. https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # список драйверов устройств, которые необходимо занести в черный список на хосте Proxmox (см. https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # установите это в true, если происходит передача через Windows, чтобы предотвратить сбой ВМ.
pve_pcie_report_msrs: true # установите это в false, чтобы предотвратить записи о сбоях msrs в dmesg.
pve_watchdog: none # установите это на "ipmi", если вы хотите настроить аппаратный watchdog. Proxmox по умолчанию использует программный watchdog (nmi_watchdog).
pve_watchdog_ipmi_action: power_cycle # может быть одним из "reset", "power_cycle" и "power_off".
pve_watchdog_ipmi_timeout: 10 # количество секунд, которые watchdog должен ждать
pve_zfs_enabled: no # указывает, нужно ли устанавливать и настраивать пакеты ZFS
# pve_zfs_options: "" # параметры модуль для передачи модулю zfs при загрузке/modprobe
# pve_zfs_zed_email: "" # должен быть установлен на электронную почту для получения уведомлений ZFS
pve_zfs_create_volumes: [] # список ZFS томов для создания (для использования в качестве хранилищ PVE). См. раздел Управление хранилищами.
pve_ceph_enabled: false # указывает, нужно ли устанавливать и настраивать пакеты Ceph. См. ниже для примера конфигурации.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bullseye main" # конфигурация apt-репозитория. Будет автоматически установлена для 6.x и 7.x (дополнительная информация: https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # публичная сеть Ceph
# pve_ceph_cluster_network: "" # необязательный, если кластерная сеть ceph отличается от публичной сети (см. https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # группа хостов, содержащая все узлы Ceph
pve_ceph_mon_group: "{{ pve_group }}" # группа хостов, содержащая все хосты-мониторы Ceph
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # группа хостов, содержащая все хосты-менеджеры Ceph
pve_ceph_mds_group: "{{ pve_group }}" # группа хостов, содержащая все хосты-метаданные Ceph
pve_ceph_osds: [] # список дисков OSD
pve_ceph_pools: [] # список пулов для создания
pve_ceph_fs: [] # список файловых систем CephFS для создания
pve_ceph_crush_rules: [] # список правил CRUSH для создания
# pve_ssl_private_key: "" # должен быть установлен на содержимое закрытого ключа для использования HTTPS
# pve_ssl_certificate: "" # должен быть установлен на содержимое сертификата для использования HTTPS
pve_roles: [] # Добавленные роли с особыми привилегиями. См. раздел Управление пользователями.
pve_groups: [] # список определений групп для управления в PVE. См. раздел Управление пользователями.
pve_users: [] # список определений пользователей для управления в PVE. См. раздел Управление пользователями.
pve_storages: [] # список хранилищ для управления в PVE. См. раздел Управление хранилищами.
pve_datacenter_cfg: {} # словарь для конфигурации файла конфигурации PVE datacenter.cfg.
pve_domains_cfg: [] # список областей, которые использовать в качестве источников аутентификации в файле конфигурации PVE domains.cfg.
pve_no_log: false # установите это в true в производственной среде, чтобы предотвратить утечку учетных данных хранилища в журналы выполнения. (может использоваться в других задачах в будущем)

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

pve_cluster_enabled: no # установите это в yes, чтобы настроить узлы для объединения в кластер
pve_cluster_clustername: "{{ pve_group }}" # должно быть установлено на имя кластера PVE
pve_manage_hosts_enabled : yes # установите это в no, чтобы НЕ настраивать файл хостов (в случае использования vpn и файл хостов уже настроен)

Следующие переменные используются для предоставления сетевой информации corosync. Эти переменные известны как ring0_addr/ring1_addr или link0_addr/link1_addr, в зависимости от версии PVE. Они должны быть адресами IPv4 или IPv6. Вы также можете настроить приоритет этих интерфейсов, чтобы намекнуть corosync, какой интерфейс должен обрабатывать трафик кластера (меньшие числа указывают на более высокий приоритет). Для получения дополнительной информации смотрите главу Cluster Manager в документации PVE.

# pve_cluster_addr0: "{{ по умолчанию используется адрес ipv4 или ipv6, если он обнаружен }}"
# pve_cluster_addr1: "IP-адрес или имя хоста другого интерфейса"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0

Вы можете установить параметры в файле конфигурации datacenter.cfg:

pve_datacenter_cfg:
  keyboard: en-us

Вы также можете настроить группы менеджера HA:

pve_cluster_ha_groups: [] # список групп HA для создания в PVE.

Этот пример создает группу "lab_node01" для ресурсов, назначенных хосту lab-node01:

pve_cluster_ha_groups:
  - name: lab_node01
    comment: "Моя группа HA"
    nodes: "lab-node01"
    nofailback: 0
    restricted: 0

Все параметры конфигурации, поддерживаемые в файле datacenter.cfg, задокументированы в разделе справки по datacenter.cfg Proxmox.

Чтобы живая перезагрузка сетевых интерфейсов работала через веб-интерфейс PVE, вам нужно установить пакет ifupdown2. Обратите внимание, что это удалит ifupdown. Вы можете указать это с помощью переменной роли pve_extra_packages.

Вы можете установить области/доменов в качестве источников аутентификации в файле конфигурации domains.cfg. Если этот файл отсутствует, доступны только области Linux PAM и сервер аутентификации Proxmox VE. Поддерживаемые типы: pam, pve, ad и ldap. Возможно автоматически синхронизировать пользователей и группы для областей, основанных на LDAP (LDAP и Microsoft Active Directory), установив sync: true. Одна область должна иметь свойство default: 1, чтобы обозначить ее как основную:

pve_domains_cfg:
  - name: pam
    type: pam
    attributes:
      comment: Стандартная аутентификация Linux PAM
  - name: pve
    type: pve
    attributes:
      comment: Сервер аутентификации Proxmox VE
  - name: ad
    type: ad
    attributes:
      comment: Аутентификация Active Directory
      domain: вашдомен.com
      server1: dc01.вашдомен.com
      default: 1
      secure: 1
      server2: dc02.вашдомен.com
  - name: ldap
    type: ldap
    sync: true
    attributes:
      comment: Аутентификация LDAP
      base_dn: CN=Users,dc=вашдомен,dc=com
      bind_dn: "uid=svc-reader,CN=Users,dc=вашдомен,dc=com"
      bind_password: "{{ secret_ldap_svc_reader_password }}"
      server1: ldap1.вашдомен.com
      user_attr: uid
      secure: 1
      server2: ldap2.вашдомен.com

Зависимости

Эта роль не устанавливает NTP, поэтому вам следует настроить NTP самостоятельно, например, с помощью роли geerlingguy.ntp, как показано в примере плейбука.

Когда кластеризация включена, эта роль использует фильтр json_query, который требует, чтобы библиотека jmespath была установлена на вашем управляющем хосте. Вы можете либо pip install jmespath, либо установить его через пакетный менеджер вашей дистрибуции, например, apt-get install python-jmespath.

Управление пользователями и ACL

Вы можете использовать эту роль для управления пользователями и группами в Proxmox VE (как в развертываниях на одном сервере, так и в развертываниях кластеров). Вот некоторые примеры.

pve_groups:
  - name: Admins
    comment: Администраторы этого кластера PVE
  - name: api_users
  - name: test_users
pve_users:
  - name: root@pam
    email: [email protected]
  - name: lae@pam
    email: [email protected]
    firstname: Musee
    lastname: Ullah
    groups: [ "Admins" ]
  - name: pveapi@pve
    password: "Proxmox789"
    groups:
      - api_users
  - name: testapi@pve
    password: "Test456"
    enable: no
    groups:
      - api_users
      - test_users
  - name: tempuser@pam
    expire: 1514793600
    groups: [ "test_users" ]
    comment: "Временный пользователь, установленный на истечение 1 января 2018 года 00:00:00 PST"
    email: [email protected]
    firstname: Test
    lastname: User

Обратитесь к library/proxmox_user.py link и library/proxmox_group.py link для документации по модулям.

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

pve_roles:
  - name: Monitoring
    privileges:
      - "Sys.Modify"
      - "Sys.Audit"
      - "Datastore.Audit"
      - "VM.Monitor"
      - "VM.Audit"
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "Admins" ]
  - path: /pools/testpool
    roles: [ "PVEAdmin" ]
    users:
      - pveapi@pve
    groups:
      - test_users

Обратитесь к library/proxmox_role.py link и library/proxmox_acl.py link для документации по модулям.

Управление хранилищем

Вы можете использовать эту роль для управления хранилищем в Proxmox VE (как в развертываниях на одном сервере, так и в развертываниях кластеров). В настоящее время поддерживаемые типы это dir, rbd, nfs, cephfs, lvm, lvmthin, zfspool, btrfs, cifs и pbs. Вот некоторые примеры.

pve_storages:
  - name: dir1
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /ploup
    disable: no
    maxfiles: 4
  - name: ceph1
    type: rbd
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    username: admin
    pool: rbd
    krbd: yes
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: nfs1
    type: nfs
    content: [ "images", "iso" ]
    server: 192.168.122.2
    export: /data
  - name: lvm1
    type: lvm
    content: [ "images", "rootdir" ]
    vgname: vg1
  - name: lvmthin1
    type: lvmthin
    content: [ "images", "rootdir" ]
    vgname: vg2
    thinpool: data
  - name: cephfs1
    type: cephfs
    content: [ "snippets", "vztmpl", "iso" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: pbs1
    type: pbs
    content: [ "backup" ]
    server: 192.168.122.2
    username: user@pbs
    password: PBSPassword1
    datastore: main
    namespace: Top/something # Необязательно
  - name: zfs1
    type: zfspool
    content: [ "images", "rootdir" ]
    pool: rpool/data
    sparse: true
  - name: btrfs1
    type: btrfs
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    path: /mnt/proxmox_storage
    is_mountpoint: true
  - name: cifs1
    server: cifs-host.domain.tld
    type: cifs
    content: [ "snippets", "vztmpl", "iso" ]
    share: sharename
    subdir: /subdir
    username: user
    password: supersecurepass
    domain: addomain.tld

Дополнительную информацию смотрите на https://pve.proxmox.com/pve-docs/api-viewer/index.html.

В настоящее время тип zfspool можно использовать только для содержимого images и rootdir. Если вы хотите сохранить другие типы содержимого на ZFS-томе, вам нужно указать их с типом dir, путь /<POOL>/<VOLUME> и добавить запись в pve_zfs_create_volumes. Этот пример добавляет хранилище iso на ZFS-пул:

pve_zfs_create_volumes:
  - rpool/iso
pve_storages:
  - name: iso
    type: dir
    path: /rpool/iso
    content: [ "iso" ]

Обратитесь к library/proxmox_storage.py link для документации по модулю.

Конфигурация Ceph

Этот раздел требует дополнительного освещения. Если вы активно используете эту роль для управления вашим кластером PVE Ceph, пожалуйста, дайте поправки для этого раздела и откройте запрос на изменение! Смотрите проблема #68.

Управление PVE Ceph с помощью этой роли является экспериментальным. Хотя пользователи успешно использовали эту роль для развертывания PVE Ceph, она не полностью протестирована в CI (из-за недостатка доступных блочных устройств, которые можно использовать в качестве OSD в Travis CI). Пожалуйста, разверните тестовую среду с вашей конфигурацией предварительно перед производственными развертываниями, и сообщите о любых проблемах, если они возникнут.

Эта роль может настроить систему хранения Ceph на ваших хостах Proxmox. Следующие определения демонстрируют некоторые из возможных конфигураций.

pve_ceph_enabled: true
pve_ceph_network: '172.10.0.0/24'
pve_ceph_cluster_network: '172.10.1.0/24'
pve_ceph_nodes: "ceph_nodes"
pve_ceph_osds:
  # OSD с всем на одном устройстве
  - device: /dev/sdc
  # OSD с block.db/WAL на другом устройстве
  - device: /dev/sdd
    block.db: /dev/sdb1
  # зашифрованный OSD с всем на одном устройстве
  - device: /dev/sdc
    encrypted: true
  # зашифрованный OSD с block.db/WAL на другом устройстве
  - device: /dev/sdd
    block.db: /dev/sdb1
    encrypted: true
# Правила Crush для разных классов хранилища
# По умолчанию 'type' установлен на host, вы можете найти действительные типы на
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# перечислены в разделе 'ТИПЫ И КОРОБКИ'
pve_ceph_crush_rules:
  - name: replicated_rule
    type: osd # Это пример того, как вы можете переопределить предсуществующее правило
  - name: ssd
    class: ssd
    type: osd
    min-size: 2
    max-size: 8
  - name: hdd
    class: hdd
    type: host
# 2 пула Ceph для ВМ-дисков, которые также будут определены как хранилища Proxmox
# Используя разные правила CRUSH
pve_ceph_pools:
  - name: ssd
    pgs: 128
    rule: ssd
    application: rbd
    storage: true
# Этот пул Ceph использует значения размеров/репликации
  - name: hdd
    pgs: 32
    rule: hdd
    application: rbd
    storage: true
    size: 2
    min-size: 1
# Этот пул Ceph использует относительно настраиваемый режим авто-масштабирования: "off" | "on" | "warn" (по умолчанию = "warn")
  - name: vm-storage
    pgs: 128
    rule: replicated_rule
    application: rbd
    autoscale_mode: "on"
    storage: true
pve_ceph_fs:
# Файловая система CephFS, не определенная как хранилище Proxmox
  - name: backup
    pgs: 64
    rule: hdd
    storage: false
    mountpoint: /srv/proxmox/backup

pve_ceph_network по умолчанию использует фильтр ansible.utils.ipaddr, который требует, чтобы библиотека netaddr была установлена и использовалась вашим управляющим хостом.

pve_ceph_nodes по умолчанию использует pve_group, этот параметр позволяет указать на каких узлах установить Ceph (например, если вы не хотите устанавливать Ceph на всех своих узлах).

pve_ceph_osds по умолчанию создает незашифрованные объемы ceph. Чтобы использовать зашифрованные объемы, нужно указать параметр encrypted для каждого диска как true.

Passthrough PCIe

Эта роль может быть настроена для разрешения передачи устройств PCI с хоста Proxmox на ВМ. Эта функция по умолчанию не включена, так как не все материнские платы и процессоры поддерживают эту функцию. Чтобы включить передачу, процессор должен поддерживать аппаратную виртуализацию (VT-d для систем на базе Intel и AMD-V для систем на базе AMD). Ссылки на инструкции всех компонентов помогут определить, поддерживается ли эта функция. Номенклатура может различаться, но обычно это называют IOMMU, VT-d или AMD-V.

Включив эту функцию, выделенные устройства (такие как GPU или USB-устройства) могут быть переданы ВМ. Вместе с выделенными устройствами могут передаваться различные интегрированные устройства, такие как интегрированные GPU Intel или AMD.

Некоторые устройства могут воспользоваться медиированным использованием. Медиированные устройства могут передаваться нескольким ВМ для совместного использования ресурсов, оставаясь при этом доступными для хост-системы. Разделение устройств не всегда поддерживается, и его следует проверить перед включением, чтобы предотвратить ошибки. Обратитесь к руководству устройства, которое вы хотите передать, чтобы определить, поддерживает ли данное устройство медиированное использование (в настоящее время эта роль поддерживает только GVT-g; SR-IOV в данный момент не поддерживается и должен быть включен вручную после завершения роли).

Следующая конфигурация позволяет включить передачу PCIe:

pve_pcie_passthrough_enabled: true
pve_iommu_passthrough_mode: true
pve_iommu_unsafe_interrupts: false
pve_mediated_devices_enabled: false
pve_pcie_ovmf_enabled: false
pve_pci_device_ids:
  - id: "10de:1381"
  - id: "10de:0fbc"
pve_vfio_blacklist_drivers:
  - name: "radeon"
  - name: "nouveau"
  - name: "nvidia"
pve_pcie_ignore_msrs: false
pve_pcie_report_msrs: true

pve_pcie_passthrough_enabled обязательно для использования любой функциональности передачи PCIe. Без включения этого параметра все другие поля, относящиеся к PCIe, останутся неиспользуемыми.

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

pve_iommu_unsafe_interrupts должен быть включен, чтобы разрешить передачу PCI, если ваша система не поддерживает перенаправление прерываний. Вы можете проверить, поддерживает ли устройство перенаправление прерываний, используя dmesg | grep 'remapping'. Если вы увидите одну из следующих строк:

• "AMD-Vi: Interrupt remapping enabled"
• "DMAR-IR: Enabled IRQ remapping in x2apic mode" ('x2apic' может отличаться на старых процессорах, но должна по-прежнему работать)

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

pve_mediated_devices_enabled включает поддержку GVT-g для интегрированных устройств, таких как iGPU Intel. Не все устройства поддерживают GVT-g, поэтому рекомендуется сначала проверить вашу конкретную модель устройства, чтобы убедиться, что она разрешена.

pve_pcie_ovmf_enabled позволяет передавать GPU OVMF PCI. При использовании OVMF вам следует выбрать 'OVMF' в качестве параметра BIOS для ВМ, а не 'SeaBIOS' в Proxmox. Эта настройка попытается исключить устройства из VGA-арбитража, если это возможно.

pve_pci_device_ids это список идентификаторов устройств и производителей, которые вы хотите передать ВМ с хоста. См. раздел 'Передача GPU' на Wiki Proxmox для поиска ваших конкретных идентификаторов устройства и производителя. При установке этого значения обязательно укажите 'id' для каждого нового элемента в массиве.

pve_vfio_blacklist_drivers это список драйверов, которые нужно исключить/заблокировать на хосте. Это необходимо при передаче устройства PCI, чтобы предотвратить использование устройства хостом перед его назначением на ВМ. При установке этого значения нужно обязательно установить 'name' для каждого нового элемента в массиве.

pve_pcie_ignore_msrs предотвращает сбой некоторых приложений Windows, таких как GeForce Experience, Passmark Performance Test и SiSoftware Sandra. Эта переменная нужна только при передаче PCI-устройств для систем на основе Windows.

pve_pcie_report_msrs можно использовать, чтобы включить или отключить сообщения о предупреждениях msrs. Если вы видите много сообщений предупреждений в вашем системном журнале 'dmesg', это значение может быть использовано, чтобы заглушить предупреждения msrs.

Примечания разработчика

При разработке новых функций или исправлении ошибок в этой роли вы можете протестировать свои изменения, используя Vagrant (в настоящее время поддерживается только libvirt). Плейбук можно найти в tests/vagrant (поэтому убедитесь, что вы вносите изменения в групповые переменные по мере необходимости). Обязательно протестируйте любые изменения как на Debian 10, так и на 11 (обновите Vagrantfile локально, чтобы использовать debian/buster64) перед отправкой запроса на изменение.

Вы также можете указать прокси-кэш для apt (например, apt-cacher-ng, который должен работать на порту 3142), если у вас в вашем окружении имеется такой. Плейбук vagrant определит, доступен ли кэш-прокси, и будет использовать его только в том случае, если он доступен в вашей сети, так что вы можете просто постоянно установить эту переменную в вашей среде разработки, если предпочтете.

Например, вы можете запустить следующее, чтобы отобразить более подробный/легкий для чтения вывод, использовать кэш-прокси и оставлять ВМ работающими, если возникнет ошибка (чтобы вы могли устранить ее и/или выполнить vagrant provision после исправления):

APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error

Участники

Musee Ullah (@lae, lae@lae.is) - Главный разработчик
Fabien Brachere (@Fbrachere) - Поддержка конфигурации хранилищ
Gaudenz Steinlin (@gaundez) - Поддержка Ceph и др.
Richard Scott (@zenntrix) - Поддержка Ceph, поддержка PVE 7.x и др.
Thoralf Rickert-Wendt (@trickert76) - Поддержка PVE 6.x и др.
Engin Dumlu (@roadrunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@SniperCZE)
niko2 (@niko2)
Christian Aublet (@caublet)
Gille Pietri (@gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@lexxxel) - Поддержка PVE 8.x и др.
Bruno Travouillon (@btravouillon) - Усовершенствования UX
Tobias Negd (@wu3rstle) - Поддержка Ceph
PendaGTP (@PendaGTP) - Поддержка Ceph
John Marion (@jmariondev)
foerkede (@foerkede) - Поддержка хранилища ZFS
Guiffo Joel (@futuriste) - Поддержка конфигурации пула
Adam Delo (@ol3d) - Поддержка PCIe Passthrough

Полный список участников