Product SiteDocumentation Site

Альт Виртуализация 10.4

Документация

Руководство пользователя

Редакция январь, 2025

Аннотация

Добро пожаловать в документацию дистрибутива Альт Виртуализация. Данное руководство предназначено как для начинающих, так и для опытных пользователей. Руководство описывает подготовку системы для установки, процесс установки дистрибутива, а также процедуру настройки и использования системы.
Названия компаний и продуктов, встречающихся в руководстве, могут являться торговыми знаками соответствующих компаний.
Данное руководство соответствует текущему состоянию сведений, но какие-либо окончательные правки могли не попасть в него. В случае обнаружения ошибок и неточностей в руководство вносятся изменения.
I. Что такое Альт Виртуализация?
1. Что такое Альт Виртуализация
1.1. Системные требования
1.2. Ограничения для логических объектов виртуализации
2. Что такое Linux
2.1. Свободные программы
2.2. Разработка Linux
2.3. Защищённость
2.4. Дистрибутивы Linux
2.5. Новичку
3. Что такое системы Альт
3.1. ALT Linux Team
3.2. Сизиф
3.3. Что такое десятая платформа
3.3.1. Основные новшества в десятой платформе
II. Установка дистрибутива
4. Подготовка установочного диска
4.1. Запись ISO-образа дистрибутива на DVD
4.1.1. Запись образа диска под операционной системой MS Windows
4.1.2. Запись образа диска под операционной системой Linux
4.2. Запись установочного образа на USB Flash
4.2.1. В операционной системе Windows
4.2.2. В операционной системе Linux
4.2.3. В операционной системе OS X
4.2.4. Проверка целостности записанного образа
5. Сохранение данных и меры предосторожности
6. Начало установки: загрузка системы
6.1. Способы первоначальной загрузки
6.2. Загрузка системы
7. Последовательность установки
8. Язык
9. Лицензионное соглашение
10. Дата и время
11. Подготовка диска
11.1. Выбор профиля разбиения диска
11.2. Автоматический профиль разбиения диска
11.3. Ручной профиль разбиения диска
11.4. Дополнительные возможности разбиения диска
11.4.1. Создание программного RAID-массива
11.4.2. Создание LVM-томов
11.4.3. Создание шифрованных разделов
11.4.4. Создание подтомов BtrFS
12. Перемонтирование
13. Установка системы
13.1. Дополнительные приложения
13.2. Установка пакетов
14. Сохранение настроек
15. Установка загрузчика
16. Настройка сети
16.1. Настройка сети для PVE
16.2. Объединение сетевых интерфейсов
16.3. Сетевые мосты
16.4. VLAN-интерфейсы
17. Администратор системы
18. Системный пользователь
19. Установка пароля на шифрованные разделы
20. Завершение установки
21. Обновление системы до актуального состояния
22. Первая помощь
22.1. Проблемы при установке системы
22.2. Проблемы с загрузкой системы
22.3. Полезные ссылки
III. Начало использования Альт Виртуализация
23. Загрузка системы
24. Получение доступа к зашифрованным разделам
25. Вход в систему
IV. OpenNebula
26. Планирование ресурсов
26.1. Сервер управления
26.2. Серверы виртуализации
26.3. Хранилище данных
26.4. Сетевая инфраструктура
27. Запуск сервера управления OpenNebula
27.1. Установка пароля для пользователя oneadmin
27.2. Настройка MySQL (MariaDB) для хранения конфигурации
27.3. Запуск OpenNebula
27.4. Проверка установки
27.5. Ключи для доступа по SSH
27.6. Конфигурация сети
28. Настройка узлов
28.1. Установка и настройка узла OpenNebula KVM
28.2. Установка и настройка узла OpenNebula LXC
29. Добавление узлов в OpenNebula
29.1. Добавление узла типа KVM в OpenNebula-Sunstone
29.2. Добавление узла типа LXС в OpenNebula-Sunstone
29.3. Работа с узлами в командной строке
30. Виртуальные сети
30.1. Режим Bridged
30.2. Режим 802.1Q VLAN
30.3. Режим VXLAN
30.4. Режим Open vSwitch
30.5. VXLAN в Open vSwitch
31. Работа с хранилищами в OpenNebula
31.1. Типы хранилищ
31.2. Хранилища по умолчанию
31.3. Создание хранилищ
31.3.1. Локальное хранилище
31.3.2. Хранилище NFS/NAS
31.3.3. NFS/NAS и локальное хранилище
31.3.4. Хранилище SAN
31.3.5. Хранилище файлов и ядер
32. Работа с образами в OpenNebula
32.1. Создание образа ОС в среде OpenNebula
32.1.1. Создание образов дисков
32.1.2. Создание шаблона ВМ
32.1.3. Создание ВМ
32.1.4. Подключение к ВМ и установка ОС
32.1.5. Настройка контекстуализации
32.1.6. Создание образа типа ОС
32.2. Использование магазинов приложений OpenNebula
32.2.1. OpenNebula Public
32.2.2. Скачивание шаблона контейнера из магазина DockerHub
33. Управление пользователями
33.1. Пользователи
33.2. Группы пользователей
33.3. Управление разрешениями
33.4. Управление правилами ACL
33.5. Аутентификация пользователей
33.5.1. LDAP аутентификация
34. Настройка отказоустойчивого кластера
34.1. Первоначальная конфигурация Leader
34.2. Добавление дополнительных серверов
34.3. Добавление и удаление серверов
34.4. Восстановление сервера
34.5. Sunstone
V. Средство управления виртуальными окружениями PVE
35. Системные требования
36. Краткое описание возможностей
36.1. Веб-интерфейс
36.2. Хранилище данных
36.3. Сетевая подсистема
37. Установка и настройка PVE
37.1. Установка PVE
37.2. Настройка сетевой подсистемы
37.2.1. Настройка Ethernet-моста в командной строке
37.2.2. Настройка Ethernet-моста в веб-интерфейсе
38. Создание кластера PVE
38.1. Настройка узлов кластера
38.2. Создание кластера в веб-интерфейсе
38.3. Создание кластера в консоли
38.4. Удаление узла из кластера
38.5. Кворум
38.6. Поддержка внешнего арбитра corosync
38.7. Кластерная файловая система PVE (pmxcfs)
39. Системы хранения PVE
39.1. Типы хранилищ в PVE
39.2. Конфигурация хранилища
39.3. Идентификатор тома
39.4. Работа с хранилищами в PVE
39.4.1. Использование командной строки
39.4.2. Добавление хранилища в веб-интерфейсе PVE
39.4.3. Каталог
39.4.4. NFS
39.4.5. BTRFS
39.4.6. CIFS
39.4.7. GlusterFS
39.4.8. Локальный ZFS
39.4.9. LVM
39.4.10. LVM-Thin
39.4.11. iSCSI
39.4.12. iSCSI/libiscsi
39.4.13. Ceph RBD
39.4.14. CephFS
39.4.15. Proxmox Backup Server
39.5. FC/iSCSI SAN
39.5.1. Подключение СХД
39.5.2. Настройка Multipath
39.5.3. Multipath в веб-интерфейсе PVE
39.5.4. Файловые системы на multipath
39.5.5. LVM/LVM-Thin хранилища на multipath
39.5.6. Изменение размера multipath-устройства
39.6. Кластер Ceph
39.6.1. Системные требования
39.6.2. Начальная конфигурация Ceph
39.6.3. Монитор Ceph
39.6.4. Менеджер Ceph
39.6.5. Ceph OSD
39.6.6. Пулы Ceph
39.6.7. Ceph CRUSH и классы устройств
39.6.8. Клиент Ceph
39.6.9. CephFS
39.6.10. Техническое обслуживание Ceph
39.6.11. Мониторинг и устранение неполадок Ceph
40. Сетевая подсистема
40.1. Применение изменений сетевых настроек
40.2. Имена сетевых устройств
40.3. Конфигурация сети с использованием моста
40.3.1. Внутренняя сеть для ВМ
40.4. Объединение/агрегация интерфейсов
40.4.1. Параметры Linux Bond
40.4.2. Параметры OVS Bond
40.4.3. Агрегированный bond-интерфейс с фиксированным IP-адресом
40.4.4. Агрегированный bond-интерфейс в качестве порта моста
40.5. Настройка VLAN
40.5.1. Мост с поддержкой VLAN
40.5.2. Мост на VLAN
41. Управление ISO-образами и шаблонами LXC
42. Виртуальные машины на базе KVM
42.1. Создание виртуальной машины на базе KVM
42.2. Запуск и остановка ВМ
42.2.1. Изменение состояния ВМ в веб-интерфейсе
42.2.2. Автоматический запуск ВМ
42.2.3. Массовый запуск и остановка ВМ
42.3. Управление ВМ с помощью qm
42.4. Скрипты-ловушки (hookscripts)
42.5. Доступ к ВМ
42.6. Внесение изменений в ВМ
42.6.1. Управление образами виртуальных дисков
42.6.2. Настройки дисплея
42.6.3. Дополнительные функции SPICE
42.6.4. Проброс USB
42.6.5. BIOS и UEFI
42.6.6. Доверенный платформенный модуль (TPM)
42.6.7. Проброс PCI(e)
42.6.8. Гостевой агент QEMU
42.7. Файлы конфигурации ВМ
43. Создание и настройка контейнера LXC
43.1. Создание контейнера в графическом интерфейсе
43.2. Создание контейнера из шаблона в командной строке
43.3. Изменение настроек контейнера
43.3.1. Изменение настроек в веб-интерфейсе
43.3.2. Настройка ресурсов в командной строке
43.3.3. Настройка ресурсов прямым изменением
43.4. Запуск и остановка контейнеров
43.4.1. Изменение состояния контейнера в веб-интерфейсе
43.4.2. Изменение состояния контейнера в командной строке
43.5. Доступ к LXC контейнеру
44. Миграция ВМ и контейнеров
44.1. Миграция с применением графического интерфейса
44.2. Миграция с применением командной строки
44.3. Миграция ВМ из внешнего гипервизора
44.3.1. Миграция KVM ВМ в PVE
44.3.2. Миграция ВМ из VMware в PVE
44.3.3. Пример импорта Windows OVF
45. Клонирование ВМ
46. Шаблоны ВМ
47. Теги (метки) ВМ
47.1. Работа с тегами
47.2. Настройка тегов
47.2.1. Стиль тегов
47.2.2. Права
48. Резервное копирование (Backup)
48.1. Алгоритмы резервного копирования
48.2. Режимы резервного копирования
48.3. Хранилище резервных копий
48.4. Резервное копирование по расписанию
48.5. Формат расписания
48.6. Настройка резервного копирования в графическом интерфейсе
48.7. Резервное копирование из командной строки
48.7.1. Файлы резервных копий
48.7.2. Восстановление
48.7.3. Ограничение пропускной способности
48.7.4. Файл конфигурация vzdump.conf
48.7.5. Файлы, не включаемые в резервную копию
48.7.6. Примеры
48.8. Снимки (snapshot)
49. Встроенный мониторинг PVE
50. Высокая доступность PVE
50.1. Как работает высокая доступность PVE
50.2. Требования для настройки высокой доступности
50.3. Настройка высокой доступности PVE
50.3.1. Создание группы высокой доступности
50.3.2. Добавление ресурсов
50.4. Тестирование настройки высокой доступности PVE
51. Пользователи и их права
51.1. API-токены
51.2. Пулы ресурсов
51.3. Области аутентификации
51.3.1. Стандартная аутентификация Linux PAM
51.3.2. Сервер аутентификации PVE
51.3.3. LDAP аутентификация
51.3.4. AD аутентификация
51.4. Двухфакторная аутентификация
51.5. Управление доступом
52. Просмотр событий PVE
52.1. Просмотр событий с помощью pvenode task
52.2. Просмотр событий в веб-интерфейсе PVE
52.2.1. Панель журнала
52.2.2. Журнал задач узла PVE
52.2.3. Журнал задач ВМ
53. PVE API
53.1. URL API
53.2. Аутентификация
53.2.1. Билет Cookie
53.2.2. API-токены
53.3. Пример создания контейнера с использованием API
53.4. Утилита pvesh
54. Основные службы PVE
54.1. pvedaemon — служба PVE API
54.2. pveproxy — служба PVE API Proxy
54.2.1. Управление доступом на основе хоста
54.2.2. Прослушиваемый IP-адрес
54.2.3. Набор SSL-шифров
54.2.4. Поддерживаемые версии TLS
54.2.5. Параметры Диффи-Хеллмана
54.2.6. Альтернативный сертификат HTTPS
54.2.7. Сжатие ответа
54.3. pvestatd — служба PVE Status
54.4. spiceproxy — служба SPICE Proxy
54.4.1. Управление доступом на основе хоста
54.5. pvescheduler — служба PVE Scheduler
VI. Управление виртуализацией на основе libvirt
55. Установка сервера
56. Утилиты управления
56.1. Утилита Virsh
56.2. Утилита virt-install
56.3. Утилита qemu-img
56.4. Менеджер виртуальных машин virt-manager
57. Подключение к гипервизору
57.1. Управление доступом к libvirt через SSH
57.2. Подключение к сессии гипервизора с помощью virsh
57.3. Настройка соединения с удаленным гипервизором в virt-manager
58. Создание виртуальных машин
58.1. Создание ВМ на основе файла конфигурации (утилита virsh)
58.2. Создание ВМ с помощью virt-install
58.3. Создание ВМ с помощью virt-manager
59. Запуск и управление функционированием ВМ
59.1. Управление состоянием ВМ в командной строке
59.2. Управление состоянием ВМ в менеджере виртуальных машин
59.3. Подключение к виртуальному монитору ВМ
59.3.1. Использование протокола SPICE
59.3.2. Использование протокола VNC
60. Управление ВМ
60.1. Редактирование файла конфигурации ВМ
60.2. Получение информации о ВМ
60.3. Конфигурирование ВМ в менеджере виртуальных машин
60.4. Мониторинг состояния
61. Управление виртуальными сетевыми интерфейсами и сетями
61.1. Управление виртуальными сетями в командной строке
61.2. Управление виртуальными сетями в менеджере виртуальных машин
61.3. Режимы работы виртуальной сети
61.3.1. Сеть на основе моста
61.3.2. Маршрутизируемая сеть
61.3.3. Сеть на основе NAT
61.3.4. Изолированная сеть
62. Управление хранилищами
62.1. Управление хранилищами в командной строке
62.2. Настройка хранилищ в менеджере виртуальных машин
63. Миграция ВМ
63.1. Миграция с помощью virsh
63.2. Миграция ВМ в менеджере виртуальных машин
64. Снимки ВМ
64.1. Управления снимками ВМ в консоли
64.2. Управления снимками ВМ в менеджере виртуальных машин
65. Регистрация событий libvirt
66. Управление доступом в виртуальной инфраструктуре
VII. Kubernetes
67. Установка и настройка Kubernetes
67.1. Создание кластера Kubernetes
67.1.1. Инициализация кластера
67.1.2. Настройка сети
67.1.3. Добавление узлов (нод) в кластер
67.2. Тестовый запуск nginx
68. Кластер высокой доступности Kubernetes
68.1. Стековая (составная) топология etcd
68.2. Внешняя etcd-топология
68.3. Создание HA-кластера с помощью kubeadm
68.3.1. Стековая (составная) топология etcd
68.3.2. Настройка HA-кластера etcd с помощью kubeadm
VIII. Настройка системы
69. Центр управления системой
69.1. Описание
69.2. Применение центра управления системой
69.3. Использование веб-ориентированного центра управления системой
IX. Работа с центром управления системой
70. Конфигурирование сетевых интерфейсов
70.1. Модуль Ethernet-интерфейсы
70.2. Объединение сетевых интерфейсов
70.3. Сетевые мосты
70.4. VLAN интерфейсы
71. Доступ к службам сервера из сети Интернет
71.1. Внешние сети
71.2. Список блокируемых хостов
72. Обслуживание сервера
72.1. Мониторинг состояния системы
72.2. Системные службы
72.3. Обновление системы
72.4. Консоль
72.5. Информация о системе
72.6. Веб-интерфейс
72.7. Локальные учётные записи
72.8. Администратор системы
72.9. Дата и время
72.10. Ограничение использования диска
72.11. Выключение и перезагрузка компьютера
73. Прочие возможности ЦУС
74. Права доступа к модулям
X. Установка пакетов для опытных пользователей
Введение
75. Источники программ (репозитории)
75.1. Редактирование репозиториев
75.1.1. Утилита apt-repo для работы с репозиториями
75.1.2. Добавление репозитория на сменном носителе
75.1.3. Добавление репозиториев вручную
76. Поиск пакетов
77. Установка или обновление пакета
78. Удаление установленного пакета
79. Обновление системы
79.1. Обновление всех установленных пакетов
79.2. Обновление ядра
XI. Основы администрирования Linux
80. Общие принципы работы ОС
80.1. Процессы и файлы
80.1.1. Процессы функционирования ОС
80.1.2. Файловая система ОС
80.1.3. Структура каталогов
80.1.4. Организация файловой структуры
80.1.5. Имена дисков и разделов
80.1.6. Разделы, необходимые для работы ОС
80.2. Работа с наиболее часто используемыми компонентами
80.2.1. Виртуальная консоль
80.2.2. Командные оболочки (интерпретаторы)
80.2.3. Командная оболочка Bash
80.2.4. Команда
80.2.5. Команда и параметры
80.2.6. Команда и ключи
80.2.7. Обзор основных команд системы
80.3. Стыкование команд в системе Linux
80.3.1. Стандартный ввод и стандартный вывод
80.3.2. Перенаправление ввода и вывода
80.3.3. Использование состыкованных команд
80.3.4. Недеструктивное перенаправление вывода
81. Средства управления дискреционными правами доступа
81.1. Команда chmod
81.2. Команда chown
81.3. Команда chgrp
81.4. Команда umask
81.5. Команда chattr
81.6. Команда lsattr
81.7. Команда getfacl
81.8. Команда setfacl
82. Режим суперпользователя
82.1. Какие бывают пользователи?
82.2. Для чего может понадобиться режим суперпользователя?
82.3. Как получить права суперпользователя?
82.4. Как перейти в режим суперпользователя?
83. Управление пользователями
83.1. Общая информация
83.2. Команда useradd
83.3. Команда passwd
83.4. Добавление нового пользователя
83.5. Настройка парольных ограничений
83.6. Управление сроком действия пароля
83.7. Настройка неповторяемости пароля
83.8. Модификация пользовательских записей
83.9. Удаление пользователей
84. Система инициализации systemd и sysvinit
84.1. Запуск операционной системы
84.1.1. Запуск системы
84.1.2. Система инициализации
84.2. Системы инициализации systemd и sysvinit
84.2.1. sysvinit
84.2.2. systemd
84.3. Примеры команд управления службами, журнал в systemd
84.4. Журнал в systemd
85. Документация
85.1. Экранная документация
85.1.1. man
85.1.2. info
85.2. Документация по пакетам
XII. Техническая поддержка продуктов «Базальт СПО»
86. Покупателям нашей продукции
87. Пользователям нашей продукции

Часть I. Что такое Альт Виртуализация?

Глава 1. Что такое Альт Виртуализация

Операционная система Альт Виртуализация (альтернативное название Альт Сервер Виртуализации) — многофункциональный дистрибутив для серверов, прежде всего, предназначен для создания виртуальной среды, обеспечивающей функционирование виртуальных машин и управление ими.
Альт Виртуализация представляет собой совокупность интегрированных программных продуктов, созданных на основе ОС Linux и обеспечивает обработку, хранение и передачу информации в круглосуточном режиме эксплуатации. Дистрибутив предоставляет интегрированную операционную систему на единой оптимизированной пакетной базе с поддержкой различных аппаратных платформ.
Включает в себя средства виртуализации:
  • вычислений (ЦПУ и память);
  • сети;
  • хранения данных.
Управление системой виртуализации возможно через командный интерфейс, веб-интерфейс, с использованием API.
Альт Виртуализация оснащён удобным пользовательским интерфейсом для настройки. Управление сервером может осуществляться с любого компьютера через веб-браузер.
ОС Альт Виртуализация включает в себя:
  • базовый гипервизор (libvirt + qemu-kvm);
  • кластер серверов виртуализации на основе проекта PVE;
  • облачную виртуализацию уровня предприятия на основе проекта OpenNebula;
  • контейнерную виртуализацию (docker, kubernetes, podman, lxd/lxc, cri-o);
  • ПО для организации хранилища (Ceph, GlusterFS, NFS, iSCSI, Linstor);
  • ПО для сети (openvswitch, haproxy, keepalived);
  • мониторинг (Zabbix-agent, Telegraf, Collectd, Monit, Prometheus, Nagios NRPE).

1.1. Системные требования

  • Минимальный размер RAM (без учета ВМ) — 1 Гбайт;
  • Рекомендуемый размер RAM (без учета ВМ) — от 2 Гбайт;
  • Минимальное количество CPU — 1;
  • Место на жёстком диске (без учета ВМ) — от 10 Гбайт.

1.2. Ограничения для логических объектов виртуализации

  • Максимальное число узлов в кластере — нет явного ограничения на количество узлов в кластере (на практике реально возможное количество узлов может быть ограничено производительностью хоста и сети).
  • Максимальные лимиты на хост:
    • CPU — 8192 Поддерживается до 8192 ядер, hyper-threading (HT) тоже учитывается. На двух-процессорном сервере, с включенным HT, смогут работать (8192/2/2=) два 2048 ядерных процессора (x86_64);
    • RAM — 32 ТБ;
    • HDD — нет явного ограничения;
    • NIC — нет.
  • Максимальные лимиты на ВМ:
    • CPU — 240;
    • RAM — 4 ТБ. Поддерживает максимальную память которую вы можете выделить ВМ. 32-х разрядные ВМ с поддержкой расширения физических адресов (PAE) могут получить доступ только к 64 ГБ — это ограничение виртуального оборудования;
    • HDD — со стороны PVE нет ограничений (зависит от самой файловой системы);
    • NIC — 32;
    • PCI — 16.

Глава 2. Что такое Linux

2.1. Свободные программы

Операционная система (далее — ОС) Linux — ядро, основные компоненты системы и большинство её пользовательских приложений — свободные программы. Свободные программы можно:
  • запускать на любом количестве компьютеров;
  • распространять бесплатно или за деньги без каких-либо ограничений;
  • получать исходные тексты этих программ и вносить в них любые изменения.
Свобода программ обеспечила их широкое использование и интерес к ним со стороны тысяч разработчиков. Основные программы для Linux выходят под лицензией GNU General Public License (далее — GPL). Лицензия GNU не только гарантирует свободу, но и защищает её. Она допускает дальнейшее распространение программ только под той же лицензией, поэтому исходный код ядра Linux, компиляторов, библиотеки glibc, пользовательских графических оболочек не может быть использован для создания приложений с закрытым кодом. В этом принципиальное отличие Linux от свободных ОС семейства BSD (FreeBSD, NetBSD, OpenBSD), фрагменты которых вошли в Microsoft Windows и даже стали основой OS X. Linux включает в себя многие разработки BSD, но его компиляторы и системные библиотеки разработаны в рамках проекта GNU (http://www.gnu.org/home.ru.html).

2.2. Разработка Linux

В отличие от распространённых несвободных ОС, Linux не имеет географического центра разработки. Нет фирмы, которая владела бы этой ОС, нет и единого координационного центра. Программы для Linux — результат работы тысяч проектов. Большинство из них объединяет программистов из разных стран, связанных друг с другом только перепиской. Лишь некоторые проекты централизованы и сосредоточены в фирмах. Создать свой проект или присоединиться к уже существующему может любой программист, и, в случае успеха, результаты этой работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую. Это позволяет за короткий срок добавлять в программное обеспечение новые возможности, оперативно находить ошибки и исправлять их.
Именно гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение независимых специалистов, обладающих индивидуальным, самостоятельным видением проблем, защита исходного текста программ лицензией GPL — всё это стало причиной успеха свободных программ.
Такая высокая эффективность разработки не могла не заинтересовать крупные фирмы. Они стали создавать свои свободные проекты, основывающиеся на тех же принципах. Так появились Mozilla, LibreOffice, свободный клон Interbase, SAP DB. IBM способствовала переносу Linux на свои мейнфреймы.
Открытый код программ значительно снизил себестоимость разработки закрытых систем для Linux и позволил снизить цену решения для пользователя. Вот почему Linux стала платформой, часто рекомендуемой для таких продуктов, как Oracle, DB2, Informix, Sybase, SAP ERP, Lotus Domino.

2.3. Защищённость

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

2.4. Дистрибутивы Linux

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

2.5. Новичку

Linux — самостоятельная операционная система. Все операционные системы разные: Linux — не Windows, не OS X и не FreeBSD. В Linux свои правила, их необходимо изучить и к ним необходимо привыкнуть. Терпение и настойчивость в изучении Linux обернётся значительным повышением эффективности и безопасности вашей работы. То, что сегодня кажется странным и непривычным, завтра понравится и станет нормой.
Не стесняйтесь задавать вопросы, ведь самый простой способ найти ответ — совет опытного специалиста. Взаимопомощь и общение — традиция в мире Linux. Всегда можно обратиться за помощью к сообществу пользователей и разработчиков Linux. Большинство вопросов повторяются, поэтому для начала стоит поискать ответ на свой вопрос в документации, затем в сети Интернет. Если вы не нашли ответа в перечисленных источниках, не стесняйтесь, пишите на форум или в списки рассылки так, как писали бы своим друзьям, и вам обязательно помогут.

Глава 3. Что такое системы Альт

3.1. ALT Linux Team

Команда ALT Linux (http://www.altlinux.org/ALT_Linux_Team) — это интернациональное сообщество, насчитывающее более 200 разработчиков свободного программного обеспечения.

3.2. Сизиф

Sisyphus (https://packages.altlinux.org) — наш ежедневно обновляемый банк программ (часто называемый репозиторий). Поддерживаемая ALT Linux Team целостность Sisyphus, оригинальная технология сборки программ, утилита apt-get и её графическая оболочка synaptic позволяют пользователям легко обновлять свои системы и быть в курсе актуальных новостей мира свободных программ.
Ежедневно изменяющийся репозиторий содержит самое новое программное обеспечение со всеми его преимуществами и недостатками (иногда ещё неизвестными). Поэтому, перед обновлением вашей системы из Sisyphus, мы советуем взвесить преимущества новых возможностей, реализованных в последних версиях программ, и вероятность возникновения неожиданностей в работе с ними (http://www.altlinux.org/Sisyphus_changes).
Разработка Sisyphus полностью доступна. У нас нет секретных изменений кода и закрытого тестирования с подписками о неразглашении. То, что мы сделали сегодня, завтра вы найдёте в сети. По сравнению с другими аналогичными банками программ (Debian unstable, Mandriva Cooker, PLD, Fedora), в Sisyphus есть немало самобытного. Особое внимание уделяется защите системы, локализации на русский язык, полноте и корректности зависимостей.
Название Sisyphus (Сизиф) заимствовано из греческой мифологии. С кропотливым Сизифом, непрерывно закатывающим в гору камни, команду ALT Linux Team объединяет постоянная работа над усовершенствованием технологий, заложенных в репозиторий.
Sisyphus, в первую очередь, — открытая лаборатория решений. Если вам это интересно, если вы хотите дополнить Sisyphus новыми решениями, если вы считаете, что можете собрать какую-то программу лучше — присоединяйтесь к проекту ALT Linux Team (http://www.altlinux.org/Join).

3.3. Что такое десятая платформа

Как уже говорилось ранее, Sisyphus является часто обновляемым репозиторием, скорее предназначенным для разработчиков. Решением для тех пользователей, которым стабильность и предсказуемость работы системы важнее расширенной функциональности (а это в первую очередь начинающие и корпоративные пользователи), являются дистрибутивы Альт. Такие дистрибутивы базируются на стабильном срезе репозитория Sisyphus. Эти срезы называются платформами.
Десятая платформа (p10) была создана в июле 2021 года и её поддержка продлится до июля 2025.

3.3.1. Основные новшества в десятой платформе

  • Синхронная сборка p10 производится для пяти основных архитектур:
    • 64-битных x86_64, aarch64 и ppc64le;
    • 32-битных i586 и armh (armv7hf);
  • Ядра реального времени — для архитектуры x86_64 собраны два realtime-ядра: Xenomai и Real Time Linux (PREEMPT_RT);
  • Расширение набора групповых политик — групповые политики поддерживают параметры gsettings для управления рабочими средами MATE и Xfce;
  • Центр администрирования Active Directory (admc) — графическое приложение для управления пользователями, группами и групповыми политиками домена Active Directory;
  • Платформа Deploy — предназначена для развёртывания системных служб на локальном компьютере с помощью Ansible. Поддерживаемые роли: Apache, MariaDB, MediaWiki, Nextcloud, PostgreSQL и Moodle;
  • Модуль настройки многотерминального режима alterator-multiseat.

Часть II. Установка дистрибутива

В этой части рассматривается процесс установки дистрибутива.

Содержание

4. Подготовка установочного диска
4.1. Запись ISO-образа дистрибутива на DVD
4.1.1. Запись образа диска под операционной системой MS Windows
4.1.2. Запись образа диска под операционной системой Linux
4.2. Запись установочного образа на USB Flash
4.2.1. В операционной системе Windows
4.2.2. В операционной системе Linux
4.2.3. В операционной системе OS X
4.2.4. Проверка целостности записанного образа
5. Сохранение данных и меры предосторожности
6. Начало установки: загрузка системы
6.1. Способы первоначальной загрузки
6.2. Загрузка системы
7. Последовательность установки
8. Язык
9. Лицензионное соглашение
10. Дата и время
11. Подготовка диска
11.1. Выбор профиля разбиения диска
11.2. Автоматический профиль разбиения диска
11.3. Ручной профиль разбиения диска
11.4. Дополнительные возможности разбиения диска
11.4.1. Создание программного RAID-массива
11.4.2. Создание LVM-томов
11.4.3. Создание шифрованных разделов
11.4.4. Создание подтомов BtrFS
12. Перемонтирование
13. Установка системы
13.1. Дополнительные приложения
13.2. Установка пакетов
14. Сохранение настроек
15. Установка загрузчика
16. Настройка сети
16.1. Настройка сети для PVE
16.2. Объединение сетевых интерфейсов
16.3. Сетевые мосты
16.4. VLAN-интерфейсы
17. Администратор системы
18. Системный пользователь
19. Установка пароля на шифрованные разделы
20. Завершение установки
21. Обновление системы до актуального состояния
22. Первая помощь
22.1. Проблемы при установке системы
22.2. Проблемы с загрузкой системы
22.3. Полезные ссылки

Глава 4. Подготовка установочного диска

Наиболее частый способ установки операционной системы на компьютер представляет собой установку с установочного DVD-диска. В этой главе описываются различные способы записи дистрибутива на DVD-диск.
Установочные образы являются гибридными, что позволяет производить установку, записав такой образ на USB Flash. О записи установочного образа на USB Flash также рассказано в этой главе.

4.1. Запись ISO-образа дистрибутива на DVD

4.1.1. Запись образа диска под операционной системой MS Windows

Файл ISO-образа диска — это файл специального формата, подготовленный для записи на диск. Для записи ISO-образа под операционной системой MS Windows используйте специальные программы: SCDWriter, Nero BurningROM и другие. Рекомендуем для записи использовать новые диски от известных производителей, таких как: Verbatim, TDK. Записанный на плохой диск образ может вызвать неразрешимые проблемы при установке.

4.1.1.1. Запись образа диска с помощью Small CD-Writer

Весь процесс записи установочного диска при помощи Small CD-Writer состоит из следующих шагов:
  • скачать образ дистрибутива;
  • скачать архив программы Small CD-Writer http://gluek.info/wiki/_media/software/scdwriter14.zip;
  • распаковать файлы программы из архива в любой каталог;
  • вставить чистый диск в привод;
  • войти в распакованный каталог и запустить программу SCDWriter.exe;
  • открыть пункт меню ДискЗаписать ISO-образ на диск и, в появившемся окне, указать путь к образу диска;
  • нажать кнопку Записать.
Окно программы Small CD-Writer

4.1.1.2. Запись образа диска с помощью Nero BurningROM

Процесс записи установочного диска при помощи Nero BurningROM состоит из следующих шагов:
  • скачать образ дистрибутива;
  • скачать программу Nero BurningROM с сайта производителя http://www.nero.com и установить её;
  • запустить программу и выбрать в списке устройств необходимый для записи CD/DVD дисковод;
  • нажать кнопку Открыть в главном окне. В появившемся окне выбрать необходимый ISO-образ для записи и нажать кнопку Открыть;
  • в окне Записать проект на вкладке Запись установить отметку в поле Запись и настроить необходимые параметры прожига;
  • записать ISO-образ на диск, щёлкнув по кнопке Прожиг.

4.1.2. Запись образа диска под операционной системой Linux

Для записи ISO-образов можно использовать множество утилит и программ с графическим или текстовым интерфейсом. Наиболее удобно использовать программы K3b или Brasero, которые поставляются в комплекте любого дистрибутива операционной системы Linux.

4.1.2.1. Запись образа диска с помощью K3b

Весь процесс записи установочного диска при помощи K3b состоит из следующих шагов:
  • если программа k3b отсутствует, необходимо установить её в систему, используя стандартные для вашего дистрибутива инструменты установки программ;
  • запустить программу k3b. При правильных настройках программа сообщит об отсутствии проблем с системой и предложит перейти к записи на диск;
  • в меню главного окна Сервис (Service) выбрать пункт Записать образ DVD (Burn DVD image);
  • в появившемся окне Записать образ DVD (Burn DVD image) нажать на кнопку Выбор файла для записи. Откроется диалог, в котором необходимо выбрать ISO-образ для записи и после выбора нажать кнопку ОК;
  • программа k3b покажет информацию о ISO-файле и начнёт вычислять контрольную сумму. Эта операция может занять несколько минут. Полученную контрольную сумму можно сравнить с MD5SUM суммой на странице дистрибутива;
  • если контрольные суммы не совпадают, значит, для записи был выбран не тот файл или скачанный ISO-образ был испорчен во время передачи данных по сети;
  • если контрольные суммы совпадают, вставить диск для записи в дисковод. Дождаться активации кнопки Начать (Start);
  • нажать на кнопку Начать (Start).

4.2. Запись установочного образа на USB Flash

Предупреждение

Запись образа дистрибутива на flash-диск приведёт к изменению таблицы разделов на носителе, таким образом, если flash-диск выполнил функцию загрузочного\установочного устройства и требуется вернуть ему функцию переносного накопителя данных, то необходимо удалить все имеющиеся разделы на flash-диске и создать нужное их количество заново.
Для восстановления совместимости flash-диска с операционными системами семейства Windows может понадобиться также пересоздание таблицы разделов (например, при помощи parted). Нужно удалить таблицу GPT и создать таблицу типа msdos. Кроме того, должен быть только один раздел с FAT или NTFS.
Для создания загрузочного flash-диска понадобится файл ISO-образа установочного диска с дистрибутивом. ISO-образы установочных дисков являются гибридными (Hybrid ISO/IMG), что позволяет записать их на flash-накопитель.

4.2.1. В операционной системе Windows

Для создания загрузочного flash-диска под операционной системой MS Windows используйте специальные программы: ALT Media Writer, Win32 Disk Imager, HDD Raw Copy Tool и другие.
ALT Media Writer — это инструмент, который помогает записывать образы ALT на портативные накопители, такие как flash-диски. Он может автоматически загружать образы из интернета и записывать их. Для записи образа на flash-диск необходимо:
  • скачать и установить ALT Media Writer;
  • вставить flash-диск в USB-разъем;
  • запустить ALT Media Writer;
  • выбрать дистрибутив и нажать кнопку Создать Live USB…:
    ALT Media Writer (altmediawriter)
    начнётся загрузка образа из интернета;
  • выбрать устройство (flash-диск);
  • после окончания загрузки нажать кнопку Записать на диск (если был отмечен пункт Записать образ после загрузки, запись образа начнётся автоматически).
Инструкция для записи образа в программе Win32 Disk Imager:
  • скачать и установить программу Win32 Disk Imager;
  • скачать образ дистрибутива;
  • вставить flash-диск в USB-разъем (размер flash-диска должен быть не меньше размера скачанного образа диска);
  • запустить Win32 Disk Imager;
  • в появившимся окне выбрать ISO-образ дистрибутива, выбрать устройство (flash-диск):
    Win32 Disk Imager
  • нажать кнопку Write для записи образа на flash-диск.
Для записи образа на flash-диск подойдёт и утилита HDD Raw Copy Tool. На первом шаге нужно выбрать файл с образом диска:
Выбор файла с образом диска
На втором шаге нужно выбрать flash-диск, на который будет записан образ:
Выбор flash-диска

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!
После проверки правильности выбранных параметров и нажатия кнопки Continue можно приступать к записи, нажав кнопку START. По успешному завершению записи окно с индикацией процесса записи закроется, после чего можно закрыть и окно самой программы.

4.2.2. В операционной системе Linux

Для записи образа на flash-диск можно воспользоваться одной из программ с графическим интерфейсом:
  • ALT Media Writer (altmediawriter):
    ALT Media Writer (altmediawriter)
    ALT Media Writer может автоматически загружать образы из интернета и записывать их, при необходимости извлекая сжатые образы (img.xz).
  • SUSE Studio Imagewriter (imagewriter):
    SUSE Studio Imagewriter (imagewriter)

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

Предупреждение

Не добавляйте номер раздела, образ пишется на flash-диск с самого начала!
Для записи установочного образа можно воспользоваться утилитой командной строки dd:
# dd oflag=direct if=<файл-образа.iso> of=/dev/sdX bs=1M status=progress;sync
где <файл-образа.iso> — образ диска ISO, а /dev/sdX — устройство, соответствующее flash-диску.
Для удобства показа прогресса записи можно установить пакет pv и использовать команду:
# pv <файл-образа.iso> | dd oflag=direct of=/dev/sdX bs=1M;sync
где <файл-образа.iso> — образ диска ISO, а /dev/sdX — устройство, соответствующее flash-диску.
Просмотреть список доступных устройств можно командой lsblk или (если такой команды нет) blkid.
Например, так можно определить имя flash-диска:
$ lsblk | grep disk
sda      8:0    0 931,5G  0 disk
sdb      8:16   0 931,5G  0 disk
sdc      8:32   1   7,4G  0 disk
flash-диск имеет имя устройства sdc.
Затем записать:
# dd oflag=direct if=/iso/alt-server-v-10.4-x86_64.iso of=/dev/sdc bs=1M status=progress; sync
или, например, так:
# pv /iso/alt-server-v-10.4-x86_64.iso | dd oflag=direct of=/dev/sdc bs=1M;sync
dd: warning: partial read (524288 bytes); suggest iflag=fullblock
3GiB 0:10:28 [4,61MiB/s] [===================================>  ] 72% ETA 0:04:07

Предупреждение

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

4.2.3. В операционной системе OS X

В операционной системе OS X для создания загрузочного flash-диска можно использовать команду:
sudo dd if=alt-server-v-10.4-x86_64.iso of=/dev/rdiskX bs=10M
sync
где alt-server-v-10.4-x86_64.iso — образ диска ISO, а /dev/rdiskX — flash-диск.
Просмотреть список доступных устройств можно командой:
diskutil list

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

4.2.4. Проверка целостности записанного образа

Для проверки целостности записанного образа необходимо выполнить следующие шаги:
  • определить длину образа в байтах:
    $ du -b alt-server-v-10.4-x86_64.iso | cut -f1
    2939768832
    
  • посчитать контрольную сумму образа (или просмотреть контрольную сумму образа из файла MD5SUM на сервере FTP):
    $ md5sum alt-server-v-10.4-x86_64.iso
    96517af90bf017af388e9010055ac30e  alt-server-v-10.4-x86_64.iso
    
  • подсчитать контрольную сумму записанного образа на DVD или USB Flash (выполняется под правами пользователя root):
    #  head -c 2939768832 /dev/sdd | md5sum
    96517af90bf017af388e9010055ac30e
    
    где размер после -c — вывод в п.1, а /dev/sdd — устройство DVD или USB Flash, на которое производилась запись.

Глава 5. Сохранение данных и меры предосторожности

Если необходимо установить ОС Альт Виртуализация и при этом сохранить уже установленную на компьютере операционную систему (например, другую версию GNU/Linux или Microsoft Windows), то нужно обязательно позаботиться о подготовке компьютера к установке второй системы и о сохранении ценных для вас данных.
Если у вас нет загрузочного диска для уже установленной системы, создайте его. В случае прерванной установки ОС Альт Виртуализация или неправильной настройки загрузчика, вы можете потерять возможность загрузиться в вашу предыдущую ОС.
Если на диске, выбранном для установки ОС Альт Виртуализация, не осталось свободного раздела, то программа установки должна будет изменить размер существующего раздела. От этой операции могут пострадать ваши данные, поэтому предварительно надо сделать следующие действия:
  • Выполнить проверку раздела, который вы собираетесь уменьшать. Для этого воспользуйтесь соответствующим программным обеспечением (далее — ПО), входящим в состав уже установленной ОС. Программа установки Альт Виртуализация может обнаружить некоторые очевидные ошибки при изменении размера раздела, но специализированное ПО предустановленной ОС справится с этой задачей лучше.
  • Выполнить дефрагментацию уменьшаемого раздела в целях повышения уровня безопасности данных. Это действие не является обязательным, но мы настоятельно рекомендуем его произвести: изменение размера раздела пройдёт легче и быстрее.

Предупреждение

Полной гарантией от проблем, связанных с потерей данных, является резервное копирование!

Глава 6. Начало установки: загрузка системы

6.1. Способы первоначальной загрузки

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

6.2. Загрузка системы

Для того чтобы начать установку ОС Альт Виртуализация, достаточно загрузиться с носителя, на котором записан дистрибутив.

Примечание

Предварительно следует включить в BIOS опцию загрузки с оптического привода или с USB-устройства.
В большинстве случаев указание способа входа в BIOS отображается на вашем мониторе непосредственно после включения компьютера. Способ входа в меню BIOS и информация о расположении настроек определяется производителем используемого оборудования. За информацией можно обратиться к документации на ваше оборудование.
Начальный загрузчик EFI
Загрузка с установочного диска или специально подготовленного USB-flash-накопителя начинается с меню, в котором перечислено несколько вариантов загрузки. Кроме установки системы с установочного диска, в данном меню доступны несколько вариантов сетевой установки.
  • Boot from hard drive — запуск уже установленной на жестком диске операционной системы;
  • Install ALT Server-V 10.4 — установка операционной системы;
  • VNC install ALT Server-V 10.4 (edit to set server IP address) — установка по VNC с соединением с устанавливаемой машины на сервер VNC с заданным IP-адресом. Параметры установки по VNC передаются как параметры ядра. Нажатие клавиши E позволяет задать IP-адрес компьютера, с которого будет происходить управление (для приёма подключения на сервере VNC следует запустить, например, vncviewer --listen):
    Параметры установки по VNC
  • VNC install ALT Server 10.4 (edit to set password and connect here) — установка по VNC с соединением в сторону устанавливаемой машины. Параметры установки по VNC передаются как параметры ядра. Нажатие клавиши E позволяет задать пароль (по умолчанию — VNCPWD):
    Параметры установки по VNC
  • Rescue LiveCD — восстановление уже установленной, но так или иначе поврежденной ОС Linux путем запуска небольшого образа ОС в оперативной памяти. Восстановление системы потребует некоторой квалификации. Этот пункт также может быть использован для сбора информации об оборудовании компьютера, которую можно отправить разработчикам, если ОС Альт Виртуализация устанавливается и работает неправильно. Загрузка восстановительного режима заканчивается приглашением командной строки:
    [root@localhost /]#
    
  • Change language (press F2) — позволяет выбрать язык интерфейса загрузчика и программы установки (нажатие клавиши F2 вызывает такое же действие);
  • Memory Test (may not work with Secure Boot) — проверка целостности оперативной памяти. Процесс диагностики заключается в проведении нескольких этапов тестирования каждого отдельного модуля ОЗУ (данный процесс будет выполняться бесконечно, пока его не остановят, необходимо дождаться окончания хотя бы одного цикла проверки);
  • UEFI Shell (may not work with Secure Boot) — оболочка/терминал для прошивки, позволяющий запускать EFI-приложения, в том числе загрузчики UEFI;
  • UEFI Firmware Settings — позволяет получить доступ к настройкам UEFI.

Примечание

Начальный загрузчик в режиме Legacy:
Начальный загрузчик в режиме Legacy
Пункт Boot from hard drive — позволяет запустить уже установленную на жёсткий диск операционную систему.

Примечание

Мышь на этом этапе установки не поддерживается. Для выбора опций установки и различных вариантов необходимо использовать клавиатуру.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, то редактировать их нет необходимости.
Чтобы начать процесс установки, нужно клавишами перемещения курсора вверх и вниз выбрать пункт меню Install ALT Server-V 10.4 и нажать Enter. Начальный этап установки не требует вмешательства пользователя: происходит автоматическое определение оборудования и запуск компонентов программы установки. Сообщения о происходящем на данном этапе можно просмотреть, нажав клавишу ESC.

Примечание

В начальном загрузчике установлено небольшое время ожидания: если в этот момент не предпринимать никаких действий, то будет загружена та система, которая уже установлена на жестком диске. Если вы пропустили нужный момент, перезагрузите компьютер и вовремя выберите пункт Install ALT Server-V 10.4.

Глава 7. Последовательность установки

До того как будет произведена установка базовой системы на жёсткий диск, программа установки работает с образом системы, загруженным в оперативную память компьютера.
Если инициализация оборудования завершилась успешно, будет запущен графический интерфейс программы-установщика. Процесс установки разделён на шаги. Каждый шаг посвящён настройке или установке определённого свойства системы. Шаги нужно проходить последовательно. Переход к следующему шагу происходит по нажатию кнопки Далее. При помощи кнопки Назад, при необходимости, можно вернуться к уже пройденному шагу и изменить настройки. Однако возможность перехода к предыдущему шагу ограничена теми шагами, в которых нет зависимости от данных, введённых ранее.
Если по каким-то причинам возникла необходимость прекратить установку, необходимо нажать кнопку <Reset> на корпусе системного блока компьютера.

Примечание

Совершенно безопасно выполнить отмену установки только до шага Подготовка диска, поскольку до этого момента не производится никаких изменений на жёстком диске. Если прервать установку между шагами Подготовка диска и Установка загрузчика, существует вероятность, что после этого с жёсткого диска не сможет загрузиться ни одна из установленных систем (если такие имеются).
Технические сведения о ходе установки можно посмотреть, нажав Ctrl+Alt+F1, вернуться к программе установки — Ctrl+Alt+F7. По нажатию Ctrl+Alt+F2 откроется отладочная виртуальная консоль.
Каждый шаг сопровождается краткой справкой, которую можно вызвать, щёлкнув кнопку Справка или нажав клавишу F1.
Нажатие на кнопку позволяет показать/скрыть панель со списком шагов установки:
Список шагов

Глава 8. Язык

Язык
Установка Альт Виртуализация начинается с выбора основного языка — языка интерфейса программы установки и устанавливаемой системы. В списке, помимо доступных языков региона (выбранного на этапе начальной загрузки), указан и английский язык.
На этом же этапе выбирается вариант переключения раскладки клавиатуры. Раскладка клавиатуры — это привязка букв, цифр и специальных символов к клавишам на клавиатуре. Помимо ввода символов на основном языке, в любой системе Linux необходимо иметь возможность вводить латинские символы (имена команд, файлов и т.п.). Для этого обычно используется стандартная английская раскладка клавиатуры. Переключение между раскладками осуществляется при помощи специально зарезервированных для этого клавиш. Для русского языка доступны следующие варианты переключения раскладки:
  • клавиши Alt и Shift одновременно;
  • клавиша CapsLock;
  • клавиши Control и Shift одновременно;
  • клавиша Control;
  • клавиша Alt.
Если выбранный основной язык имеет всего одну раскладку (например, при выборе английского языка в качестве основного), эта единственная раскладка будет принята автоматически.

Глава 9. Лицензионное соглашение

Лицензионное соглашение
Перед продолжением установки следует внимательно прочитать условия лицензии. В лицензии говорится о ваших правах. В частности, за вами закрепляются права на:
  • эксплуатацию программ на любом количестве компьютеров и в любых целях;
  • распространение программ (сопровождая их копией авторского договора);
  • получение исходных текстов программ.
Если вы приобрели дистрибутив, то данное лицензионное соглашение прилагается в печатном виде к вашей копии дистрибутива. Лицензия относится ко всему дистрибутиву Альт Виртуализация. Если вы согласны с условиями лицензии, отметьте пункт Да, я согласен с условиями и нажмите кнопку Далее.

Глава 10. Дата и время

На данном этапе выполняется выбор региона и города, по которым будет определен часовой пояс и установлены системные часы.
Дата и время (выбор часового пояса)
Для корректной установки даты и времени достаточно правильно указать часовой пояс и выставить желаемые значения для даты и времени.
На этом шаге следует выбрать часовой пояс, по которому нужно установить часы. Для этого в соответствующих списках выберите регион, а затем город. Поиск по списку можно ускорить, набирая на клавиатуре первые буквы искомого слова.
Пункт Хранить время в BIOS по Гринвичу выставляет настройки даты и времени в соответствии с часовыми поясами, установленными по Гринвичу, и добавляет к местному времени часовую поправку для выбранного региона.
После выбора часового пояса будут предложены системные дата и время по умолчанию.
Для ручной установки текущих даты и времени нужно нажать кнопку Изменить…. Откроется окно ручной настройки системных параметров даты и времени.
Дата и время
Для синхронизации системных часов с удалённым сервером времени (NTP) по локальной сети или по сети Интернет нужно отметить пункт Получать точное время с NTP-сервера и указать предпочитаемый NTP-сервер. В большинстве случаев можно указать сервер pool.ntp.org.
Если выбрана опция Получать точное время с NTP-сервера, то компьютер может и сам быть сервером точного времени. Например, использоваться как сервер точного времени машинами локальной сети. Для активации этой возможности необходимо отметить пункт Работать как NTP-сервер.
Для сохранения настроек и продолжения установки системы в окне ручной установки даты и времени необходимо нажать кнопку ОК и затем в окне Дата и время нажать кнопку Далее.

Примечание

В случае если ОС Альт Виртуализация устанавливается как вторая ОС, необходимо снять отметку с пункта Хранить время в BIOS по Гринвичу, иначе время в уже установленной ОС может отображаться некорректно.

Глава 11. Подготовка диска

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

11.1. Выбор профиля разбиения диска

После завершения первичной конфигурации загрузочного носителя откроется окно Подготовка диска. В списке разделов перечислены уже существующие на жёстких дисках разделы (в том числе здесь могут оказаться съёмные flash-диски, подключённые к компьютеру в момент установки).
Подготовка диска
В списке Выберите профиль перечислены доступные профили разбиения диска. Профиль — это шаблон распределения места на диске для установки ОС. Можно выбрать один из профилей:
  • Minimal server (rootfs only /) — единственная файловая система ext4 под корень (swap и раздел под efi автоматически);
  • Generic Server KVM/Docker/LXD/Podman/CRI-O/PVE — большой раздел под /var;
  • Вручную.
Первые два профиля предполагают автоматическое разбиение диска.

11.2. Автоматический профиль разбиения диска

Выбор автоматического профиля разбиения диска влияет на предлагаемый по умолчанию профиль устанавливаемого программного обеспечения.
При выборе пункта Minimal server (rootfs only /) — при разбиении диска будут выделены разделы для подкачки, для efi и для корневой файловой системы.
Выбор автоматического профиля разбиения диска Minimal server (rootfs only /)
При выборе пункта Generic Server KVM/Docker/LXD/Podman/CRI-O/PVE — при разбиении диска будут выделены отдельные разделы для подкачки, для efi и для корневой файловой системы. Оставшееся место будет отведено под раздел /var.
Выбор автоматического профиля разбиения диска Generic Server KVM/Docker/LXD/Podman/CRI-O/PVE
Если было выбрано несколько дисков, то на этих дисках будет создан RAID-массив.
Автоматическое создание RAID-массива
Если результат вас по каким-то причинам не устраивает, прямо сейчас можно его отредактировать.
От возможности редактировать результат разбиения можно отказаться, сняв выделение с пункта Предложить сделать мои изменения после применения профиля. В этом случае никакой информации о распределении дискового пространства на экране отображаться не будет. После осуществления физических изменений на жестком диске начнется установка базовой системы. Этот вариант подойдет для установки на чистый диск.
Рядом с названием каждого профиля указан минимальный объём свободного места на диске, требуемый для установки в соответствии с данным профилем. Если при применении одного из профилей автоматического разбиения диска доступного места на выбранных дисках окажется недостаточно, то на монитор будет выведено сообщение об ошибке: Невозможно применить профиль, недостаточно места на диске.
Невозможно применить профиль, недостаточно места на диске
В этом случае можно воспользоваться методом ручной разметки: профиль Вручную или установить отметку на пункте Очистить выбранные диски перед применением профиля.

Примечание

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

11.3. Ручной профиль разбиения диска

При необходимости освободить часть дискового пространства следует воспользоваться профилем разбиения Вручную. В этом случае можно удалить некоторые из существующих разделов или содержащиеся в них файловые системы. После этого можно создать необходимые разделы самостоятельно или вернуться к шагу выбора профиля и применить автоматический профиль. Выбор этой возможности требует знаний об устройстве диска и технологиях его разметки.
По нажатию кнопки Далее будет произведена запись новой таблицы разделов на диск и форматирование разделов. Только что созданные на диске программой установки разделы пока не содержат данных и поэтому форматируются без предупреждения. Уже существовавшие, но изменённые разделы, которые будут отформатированы, помечаются специальным значком в колонке Файловая система слева от названия. При уверенности в том, что подготовка диска завершена, подтвердите переход к следующему шагу нажатием кнопки Далее.
Не следует форматировать разделы с теми данными, которые вы хотите сохранить, например, со старыми пользовательскими данными (/home) или с другими операционными системами. С другой стороны, отформатировать можно любой раздел, который вы хотите «очистить» (удалить все данные).

Предупреждение

Не уменьшайте NTFS-раздел с установленной Microsoft Windows Vista/Windows 7 средствами программы установки. В противном случае вы не сможете загрузить Microsoft Windows Vista/Windows 7 после установки Альт Виртуализация. Для выделения места под установку Альт Виртуализация воспользуйтесь средствами, предоставляемыми самой Microsoft Windows Vista/Windows 7: Управление дискамиСжать.
Для того чтобы система правильно работала (в частности могла загрузиться) с UEFI, при ручном разбиении диска надо обязательно сделать точку монтирования /boot/efi, в которую нужно смонтировать vfat раздел с загрузочными записями. Если такого раздела нет, то его надо создать вручную. При разбивке жёсткого диска в автоматическом режиме такой раздел создаёт сам установщик. Особенности разбиения диска в UEFI-режиме:
  • требуется создать новый или подключить существующий FAT32-раздел с GPT-типом ESP (efi system partition) размером ~100—500 Мб (будет смонтирован в /boot/efi);
  • может понадобиться раздел типа bios boot partition минимального размера, никуда не подключенный и предназначенный для встраивания grub2-efi;
  • остальные разделы — и файловая система, и swap — имеют GPT-тип basic data; актуальный тип раздела задаётся отдельно.
Для сохранения всех внесенных настроек и продолжения установки в окне Подготовка диска нужно нажать кнопку Далее. Появится окно со списком настроенных разделов и их точек монтирования. Если вы уверены в том, что подготовка диска завершена, подтвердите переход к следующему шагу нажатием кнопки ОК.

11.4. Дополнительные возможности разбиения диска

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

11.4.1. Создание программного RAID-массива

Избыточный массив независимых дисков RAID (redundant array of independent disks) — технология виртуализации данных, которая объединяет несколько жёстких дисков в логический элемент для избыточности и повышения производительности.

Примечание

Для создания программного RAID-массива потребуется минимум два жёстких диска.
Программа установки поддерживает создание программных RAID-массивов следующих типов:
  • RAID 1;
  • RAID 0;
  • RAID 4/5/6;
  • RAID 10.
Процесс подготовки к установке на RAID условно можно разбить на следующие шаги:
  • создание разделов на жёстких дисках;
  • создание RAID-массивов на разделах жёсткого диска;
  • создание файловых систем на RAID-массиве.

Важно

Для создания программного RAID-массива может потребоваться предварительно удалить существующую таблицу разделов с жёсткого диска.

Важно

Системный раздел EFI должен быть физическим разделом в основной таблице разделов диска.
Для настройки параметров нового раздела из состава RAID-массива необходимо выбрать неразмеченный диск в окне профиля разбивки пространства Вручную и нажать кнопку Создать раздел.
Кнопка Создать раздел
Для создания программного массива на GPT-разделах следует сначала создать разделы типа basic data и не создавать на них том (снять отметку с пункта Создать том):
Создание раздела программного массива в режиме UEFI
В этом окне необходимо настроить следующие параметры:
  • Размер — в поле необходимо указать размер будущего раздела в Мбайт;
  • Смещение — в поле необходимо указать смещение начала данных на диске в Мбайт;
  • Тип раздела — в выпадающем поле нужно выбрать значение basic data для последующего включения раздела в RAID-массив.

Примечание

В режиме Legacy при создании разделов на жёстких дисках для последующего включения их в RAID-массивы следует указать Тип раздела для них равным Linux RAID:
Создание разделов для RAID-массива
На втором диске создать два раздела с типом basic data без создания на них томов. При этом разделы на разных дисках должны совпадать по размеру.

Примечание

При создании разделов следует учесть, что объём результирующего массива может зависеть от размера, включённых в него разделов жёсткого диска. Например, при создании RAID 1 результирующий размер массива будет равен размеру минимального участника.
После создания разделов на дисках можно переходить к организации самих RAID-массивов. Для этого в списке следует выбрать пункт RAID, после чего нажать кнопку Создать RAID:
Организация RAID-массива
Далее мастер предложит выбрать тип массива:
Выбор типа RAID-массива
И указать участников RAID-массива (по умолчанию выбираются все разделы, поэтому необходимо снять отметку с раздела sdb1):
Выбор участников RAID-массива
Результат создания RAID-массива:
Результат создания RAID-массива
После того, как RAID-массив создан, его можно использовать как обычный раздел на жёстких дисках, то есть на нём можно создавать файловые системы или же, например, включать в LVM-тома.

Примечание

После установки системы можно будет создать ещё один RAID-массив и добавить в него загрузочный раздел (/boot/efi).

11.4.2. Создание LVM-томов

Менеджер логических дисков LVM (Logical Volume Manager) — средство гибкого управления дисковым пространством, позволяющее создавать поверх физических разделов (либо неразбитых дисков) логические тома, которые в самой системе будут видны как обычные блочные устройства с данными (обычные разделы).
Процесс подготовки к установке на LVM условно можно разбить на следующие шаги:
  • создание разделов на жёстких дисках;
  • создание группы томов LVM;
  • создание томов LVM;
  • создание файловых систем на томах LVM.

Важно

Для создания группы томов LVM может потребоваться предварительно удалить существующую таблицу разделов с жёсткого диска.

Важно

Системный раздел EFI должен быть физическим разделом в основной таблице разделов диска, не под LVM.
Для настройки параметров нового раздела необходимо выбрать неразмеченный диск в окне профиля разбивки пространства Вручную и нажать кнопку Создать раздел:
Кнопка Создать раздел
При создании разделов на жёстких дисках для последующего включения их в LVM-тома следует указать Тип раздела для них равным basic data и не создавать на них том (снять отметку с пункта Создать том):
Создание раздела Linux LVM в режиме UEFI

Примечание

В режиме Legacy при создании разделов на жёстких дисках для последующего включения их в LVM-тома следует указать Тип раздела для них равным Linux LVM:
Создание раздела Linux LVM в режиме Legacy
После создания разделов на дисках можно переходить к созданию группы томов LVM. Для этого в списке следует выбрать пункт LVM, после чего нажать кнопку Создать группу томов:
Создание LVM-томов
В открывшемся окне необходимо выбрать разделы, которые будут входить в группу томов, указать название группы томов и выбрать размер экстента:
Создание группы томов LVM

Примечание

Размер экстента представляет собой наименьший объем пространства, который может быть выделен тому. Размер экстента по умолчанию 65536 (65536*512 байт = 32 Мб, где 512 байт — размер сектора).
После того, как группа томов LVM создана, её можно использовать как обычный жёсткий диск, то есть внутри группы томов можно создавать тома (аналог раздела на физическом жёстком диске) и файловые системы внутри томов.
Создание тома

11.4.3. Создание шифрованных разделов

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

Предупреждение

Установка загрузчика на шифрованный раздел не поддерживается.

11.4.4. Создание подтомов BtrFS

BtrFS — файловая система, которая может работать с очень большими файлами, имеется поддержка снимков файловой системы (снапшотов), сжатие и подтома.
Подтом (subvolume) не является блочным устройством, но в каждом томе BtrFS создаётся один подтом верхнего уровня (subvolid=5), в этом подтоме могут создаваться другие подтома и снапшоты. Подтома (подразделы, subvolumes) создаются ниже вершины дерева BtrFS по мере необходимости, например, для / и /home создаются подтома с именами @ и @home. Это означает, что для монтирования подтомов необходимы определенные параметры вместо корня системы BtrFS по умолчанию:
  • подтом @ монтируется в / с помощью опции subvol=@;
  • подтом @home, если он используется, монтируется в /home с помощью параметра монтирования subvol=@home.
Программа установки Альт Виртуализация позволяет создать подтома (subvolume), указав разные точки монтирования.
Процесс подготовки к установке на подтома условно можно разбить на следующие шаги:
  • создание разделов на жёстких дисках;
  • создание подтомов на разделах жёсткого диска.
В данном разделе рассмотрен вариант подготовки раздела BtrFS с разбивкой на подтома @ и @home.
Для настройки параметров нового раздела необходимо выбрать неразмеченный диск в окне профиля разбивки пространства Вручную и нажать кнопку Создать раздел.
При создании раздела на жёстком диске следует указать Тип раздела равным Linux filesystem или basic data:
Создание раздела с ФС BtrFS
При создании раздела на жёстком диске следует указать Тип раздела равным Linux filesystem или basic data:
Создание раздела с ФС BtrFS в режиме UEFI

Примечание

В режиме Legacy при создании раздела на жёстком диске для последующего создания подтомов BtrFS следует указать Тип раздела равным Linux:
Создание раздела с ФС BtrFS в режиме Legacy
На следующем шаге выбрать файловую систему BtrFS:
Создание раздела с ФС BtrFS
В окне Изменить точку монтирования нажать кнопку Отмена (не указывать точку монтирования для раздела):
Окно Изменить точку монтирования
После создания раздела можно переходить к созданию подтомов. Для этого в списке следует выбрать раздел с файловой системой BtrFS, после чего нажать кнопку Создать подтом:
Кнопка Создать подтом
В открывшемся окне следует указать имя подтома или путь до него. Создание подтома @home:
Создание подтома @home
Данное действие следует повторить для создания подтома @.
После создания подтомов необходимо указать точки монтирования для каждого тома. Для этого выбрать подтом и нажать кнопку Изменить точку монтирования:
Кнопка Изменить точку монтирования
В открывшемся окне указать точку монтирования:
Точка монтирования для подтома @
Далее можно установить систему как обычно.

Глава 12. Перемонтирование

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

Глава 13. Установка системы

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

13.1. Дополнительные приложения

Выбор групп приложений
В дистрибутиве Альт Виртуализация доступно значительное количество программ, часть из них составляет саму операционную систему, а остальные — это прикладные программы и утилиты.
В Альт Виртуализация все операции установки и удаления производятся над пакетами — отдельными компонентами системы. Пакет и программа соотносятся неоднозначно: иногда одна программа состоит из нескольких пакетов, иногда один пакет включает несколько программ.
В процессе установки системы обычно не требуется детализированный выбор компонентов на уровне пакетов — это требует слишком много времени и знаний от проводящего установку, тем более, что комплектация дистрибутива подбирается таким образом, чтобы из имеющихся программ можно было составить полноценную рабочую среду для соответствующей аудитории пользователей. Поэтому в процессе установки системы пользователю предлагается выбрать из небольшого списка групп пакетов именно те, которые необходимы для решения наиболее распространённых задач. Под списком групп на экране отображается информация об объёме дискового пространства, которое будет занято после установки пакетов, входящих в выбранные группы.
Выбор профиля
При установке сервера доступны следующие профили:
  • Минимальная установка — дополнительное ПО в состав устанавливаемых пакетов включаться не будет;
  • Сервер управления Opennebula — управляющий сервер Opennebula;
  • Вычислительный узел Opennebula KVM — гипервизор с виртуальными машинами;
  • Вычислительный узел Opennebula LXC — гипервизор LXC контейнеров;
  • Виртуальное Окружение Proxmox — узел кластера Proxmox Virtual Enviroment. Все ноды кластера равнозначны: нет деления на сервер управления и гипервизор;
  • Базовая виртуализация — минимальный гипервизор, qemu + libvirtd;
  • Docker — сервер с предустановленным docker.
После выбора профиля можно изменить состав устанавливаемых пакетов.
Под списком групп на экране отображается информация об объёме дискового пространства, которое будет занято после установки пакетов, входящих в выбранные группы.
При выборе группы пакетов будет показан список программных пакетов, входящих в состав этой группы:
Выбор групп приложений
Выбрав необходимые группы, следует нажать кнопку Далее, после чего начнётся установка пакетов.

13.2. Установка пакетов

На этом этапе происходит установка набора программ, необходимых для работы системы.
Установка системы
Установка происходит автоматически в два этапа:
  • получение пакетов;
  • установка пакетов.
Получение пакетов осуществляется из источника, выбранного на этапе начальной загрузки. При сетевой установке время выполнения этого шага будет зависеть от скорости соединения и может быть значительно большим в сравнении с установкой с лазерного диска.

Глава 14. Сохранение настроек

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

Глава 15. Установка загрузчика

Загрузчик ОС — это программа, которая позволяет загружать Альт Виртуализация и другие ОС, если они установлены на данной машине.
При установке на EFI модуль установки загрузчика предложит вариант установить загрузчик в специальный раздел «EFI» (рекомендуется выбрать автоматическое разбиение на этапе разметки диска для создания необходимых разделов для загрузки с EFI):
Установка загрузчика при установке в режиме EFI
Варианты установки загрузчика при установке в режиме EFI:
  • EFI (рекомендуемый) — при установке загрузчика в NVRAM будет добавлена запись, без которой большинство компьютеров не смогут загрузиться во вновь установленную ОС;
  • EFI (сначала очистить NVRAM) — перед добавлением записи в NVRAM её содержимое будет сохранено в /root/.install-log, после чего из неё будут удалены все загрузочные записи, что приведёт к восстановлению полностью заполненной NVRAM и гарантирует загрузку вновь установленной ОС;
  • EFI (запретить запись в NVRAM) — этот вариант следует выбрать, только если инсталлятор не может создать запись в NVRAM или если заведомо известно, что запись в NVRAM может вывести компьютер из строя (вероятно, запись в NVRAM придётся создать после установки ОС средствами BIOS Setup);
  • EFI (для съёмных устройств) — этот вариант следует выбрать, только если ОС устанавливается на съёмный накопитель. Этот вариант также можно использовать вместо варианта EFI (запретить запись в NVRAM) при условии, что это будет единственная ОС на данном накопителе. Создавать запись в NVRAM не потребуется.
Выбор варианта установки загрузчика, зависит от вашего оборудования. Если не работает один вариант, попробуйте другие.

Примечание

Установка загрузчика при установке в режиме Legacy:
Установка загрузчика
Программа установки автоматически определяет, в каком разделе жёсткого диска следует располагать загрузчик для возможности корректного запуска ОС Альт Виртуализация. Положение загрузчика, в случае необходимости, можно изменить в списке Устройство, выбрав другой раздел.
Если же вы планируете использовать и другие ОС, уже установленные на этом компьютере, тогда имеет значение, на каком жёстком диске или в каком разделе будет расположен загрузчик.
Для ограничения доступа к опциям загрузки можно установить пароль на загрузчик. Для этого необходимо отметить пункт Установить или сбросить пароль и задать пароль в появившихся полях для ввода.
Установка загрузчика

Примечание

При необходимости изменения опций загрузки при старте компьютера потребуется ввести имя пользователя «boot» и заданный на этом шаге пароль.
Для подтверждения выбора и продолжения работы программы установки необходимо нажать кнопку Далее.

Глава 16. Настройка сети

На этом этапе необходимо задать параметры работы сетевой карты и настройки сети: IP-адреса сетевых интерфейсов, DNS-сервер, шлюз и т.п. Конкретные значения будут зависеть от используемого вами сетевого окружения. Ручного введения настроек можно избежать при наличии в сети настроенного DHCP-сервера. В этом случае все необходимые сетевые настройки будут получены автоматически.
Настройка сети
В окне Настройка сети доступны следующие поля:
  • Имя компьютера — сетевое имя компьютера (это общий сетевой параметр, не привязанный к какому либо конкретному интерфейсу);
  • Интерфейсы — список доступных сетевых интерфейсов;
  • Конфигурация — способ назначения IP-адресов (Использовать DHCP, Использовать Zeroconf, Вручную);
  • IP-адреса — пул назначенных IP-адресов из поля Добавить ↑ IP, выбранные адреса можно удалить нажатием кнопки Удалить;
  • Добавить ↑ IP — позволяет ввести IP-адрес вручную и выбрать в выпадающем поле предпочтительную маску сети. Для переноса адреса в пул поля IP-адреса необходимо нажать кнопку Добавить;
  • Шлюз по умолчанию — адрес шлюза, который будет использоваться сетью по умолчанию;
  • DNS-серверы — список предпочтительных DNS-серверов, которые будут получать информацию о доменах, выполнять маршрутизацию почты и управлять обслуживающими узлами для протоколов в домене;
  • Домены поиска — список предпочтительных доменов, по которым будет выполняться поиск.

16.1. Настройка сети для PVE

Для установки PVE должен быть настроен сетевой мост vmbr0 с указанием статического IP-адреса. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному устройству, обеспечивающему соединение с общей сетью передачи данных.

Важно

При установке PVE в поле Имя компьютера необходимо указать FQDN (полное имя с доменом).

Важно

Для сетевого моста vmbr0 должен быть указан статический IP-адрес.
Для настройки Ethernet-моста следует выполнить следующие действия:
  1. У интерфейса, который будет входить в мост, в поле Конфигурация выбрать значение Вручную.
  2. В поле Интерфейсы выбрать интерфейс vmbr0 и нажать кнопку Настроить сетевой мост:
    Настройка Ethernet-моста
  3. В открывшемся окне Сетевые мосты в списке Доступные интерфейсы выбрать сетевой интерфейс, который будет входить в мост, и переместить его в список Члены. В выпадающем списке Тип моста выбрать тип моста: Linux Bridge (по умолчанию) или Open vSwitch и нажать кнопку Ок:
    Настройка Ethernet-моста
  4. Настроить сетевой интерфейс vmbr0: задать IP-адрес и нажать кнопку Добавить, ввести адрес шлюза по умолчанию и DNS-сервера:
    Настройка параметров сетевого интерфейса vmbr0

Важно

Если в сервере есть несколько сетевых карт, то одну можно использовать для управления (на неё следует назначить IP-адрес без моста), вторую использовать только для моста, в который будут подключаться виртуальные машины:
Настройка параметров сетевого интерфейса для управления
Для использования CEPH, iSCSI, NFS или другого сетевого хранилища стоит использовать третью сетевую карту, желательно 10G.

16.2. Объединение сетевых интерфейсов

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

Примечание

Для сетевых интерфейсов, котороые будут входить в объеденение в поле Конфигурация должно быть выбрано значение Вручную.
Для создания объединения интерфейсов необходимо выполнить следующие действия:
  1. Нажать кнопку Создать объединение…:
    Объединение сетевых интерфейсов
  2. Переместить сетевые интерфейсы, которые будут входить в объединение, из списка Доступные интерфейсы в список Используемые интерфейсы.
  3. В списке Политика выбрать режим объединения:
    • Round-robin — режим циклического выбора активного интерфейса для исходящего трафика;
    • Активный-резервный — активен только один интерфейс, остальные находятся в режиме горячей замены;
    • XOR — один и тот же интерфейс работает с определённым получателем, передача пакетов распределяется между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов;
    • Широковещательная — трафик идёт через все интерфейсы одновременно;
    • Агрегирование каналов по стандарту IEEE 802.3ad — в группу объединяются одинаковые по скорости и режиму интерфейсы, все физические интерфейсы используются одновременно в соответствии со спецификацией IEEE 802.3ad. Для реализации этого режима необходима поддержка на уровне драйверов сетевых карт и коммутатор, поддерживающий стандарт IEEE 802.3ad (коммутатор требует отдельной настройки);
    • Адаптивная балансировка нагрузки передачи — исходящий трафик распределяется в соответствии с текущей нагрузкой (с учётом скорости) на интерфейсах (для данного режима необходима его поддержка в драйверах сетевых карт). Входящие пакеты принимаются только активным сетевым интерфейсом;
    • Адаптивная балансировка нагрузки — включает в себя балансировку исходящего трафика и балансировку на приём (rlb) для IPv4 трафика и не требует применения специальных коммутаторов. Балансировка на приём достигается на уровне протокола ARP путём перехвата ARP ответов локальной системы и перезаписи физического адреса на адрес одного из сетевых интерфейсов (в зависимости от загрузки).
  4. Указать, если это необходимо, параметры объединения в поле Параметры объединения.
  5. Нажать кнопку Назад:
    Выбор сетевых интерфейсов для объединения
  6. В результате будет создан агрегированный интерфейс bond0. Для данного интерфейса можно задать IP-адрес и, если необходимо, дополнительные параметры:
    Настройки интерфейса bond0
  7. Нажать кнопку Применить.
Для удаления агрегированного интерфейса необходимо выбрать его в списке Интерфейсы и нажать кнопку Удалить объединение….

Примечание

На этапе установки системы агрегированный интерфейс нельзя указать в качестве интерфейса для моста.

16.3. Сетевые мосты

Примечание

Для сетевых интерфейсов, котороые будут входить в сетевой мост в поле Конфигурация должно быть выбрано значение Вручную.
Для создания Ethernet-моста необходимо выполнить следующие действия:
  1. Нажать кнопку Создать сетевой мост…:
    Настройка сетевого моста
  2. В окне Сетевые мосты в поле Интерфейс-мост ввести имя моста.
  3. В выпадающем списке Тип моста выбрать тип моста: Linux Bridge (по умолчанию) или Open vSwitch.
  4. Переместить сетевые интерфейсы, которые будут входить в мост, из списка Доступные интерфейсы в список Члены.
  5. Нажать кнопку Ок:
    Выбор сетевых интерфейсов для моста
  6. В результате будет создан сетевой интерфейс моста (в примере vmbr1). Для данного интерфейса можно задать IP-адрес и, если необходимо, дополнительные параметры:
    Настройка параметров сетевого интерфейса vmbr1
  7. Нажать кнопку Применить.
Для удаления интерфейса моста необходимо выбрать его в списке Интерфейсы и нажать кнопку Удалить сетевой мост….

16.4. VLAN-интерфейсы

Для создания интерфейсов VLAN необходимо выполнить следующие действия:
  1. В списке Интерфейсы выбрать сетевой интерфейс и нажать кнопку Настройка VLAN…:
    Создание интерфейса VLAN
  2. Ввести VLAN ID (число от 1 до 4095) в поле VID и нажать кнопку Добавить VLAN:
    Создание интерфейса VLAN

    Примечание

    Следует обратить внимание, что 4094 является верхней допустимой границей идентификатора VLAN, а 4095 используется технически в процессе отбрасывания трафика по неверным VLAN.
  3. Повторить предыдущий пункт, если нужно создать несколько VLAN-интерфейсов.
  4. Для того чтобы вернуться к основным настройкам, нажать кнопку Назад.
  5. В результате будут созданы виртуальные интерфейсы с именем, содержащим VLAN ID. Для данных интерфейсов можно задать IP-адрес и, если необходимо, дополнительные параметры:
    Настройки интерфейса enp0s8.100
  6. Нажать кнопку Применить.
Для удаления интерфейса VLAN следует в списке Интерфейсы выбрать «родительский» сетевой интерфейс и нажать кнопку Настройка VLAN…. Затем в открывшемся окне выбрать VLAN-интерфейс и нажать кнопку Удалить.

Глава 17. Администратор системы

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

Примечание

Чтобы избежать последствий неверной раскладки клавиатуры можно просмотреть пароль, который будет сохранен. Для этого нажмите на значок глаза в поле ввода:
Просмотр пароля
Для автоматической генерации пароля необходимо отметить пункт Создать автоматически. Система предложит пароль, сгенерированный автоматическим образом в соответствии с требованиями по стойкости паролей.
В любой системе Linux всегда присутствует один специальный пользователь — администратор системы, он же суперпользователь. Для него зарезервировано стандартное системное имя — root.
Администратор системы отличается от всех прочих пользователей тем, что ему позволено производить любые, в том числе самые разрушительные изменения в системе. Поэтому выбор пароля администратора системы — очень важный момент для безопасности. Любой, кто сможет ввести его правильно (узнать или подобрать), получит неограниченный доступ к системе. Даже ваши собственные неосторожные действия от имени root могут иметь катастрофические последствия для всей системы.

Важно

Стоит запомнить пароль root — его нужно будет вводить для получения права изменять настройки системы с помощью стандартных средств настройки Альт Виртуализация. Более подробную информацию о режиме суперпользователя вы можете прочитать в главе Режим суперпользователя.
Подтверждение введенного (или сгенерированного) пароля учетной записи администратора (root) и продолжение работы программы установки выполняется нажатием кнопки Далее.

Глава 18. Системный пользователь

На данном этапе программа установки создает учетную запись системного пользователя (пользователя) Альт Виртуализация.
Системный пользователь
Помимо администратора (root) в систему необходимо добавить, по меньшей мере, одного обычного системного пользователя. Работа от имени администратора системы считается опасной, поэтому повседневную работу в Linux следует выполнять от имени ограниченного в полномочиях системного пользователя.
При добавлении системного пользователя предлагается ввести имя учётной записи пользователя. Имя учётной записи всегда представляет собой одно слово, состоящее только из строчных латинских букв (заглавные запрещены), цифр и символа подчёркивания «_» (причём цифра и символ «_» не могут стоять в начале слова).
Для того чтобы исключить опечатки, пароль пользователя вводится дважды. Пароль пользователя можно создать автоматически, по аналогии с автоматическим созданием пароля суперпользователя.
Для автоматической генерации пароля необходимо отметить пункт Создать автоматически. Система предложит пароль, сгенерированный автоматическим образом в соответствии с требованиями по стойкости паролей.
В процессе установки предлагается создать только одну учётную запись системного пользователя — от его имени можно выполнять задачи, не требующие привилегий суперпользователя. Учётные записи для всех прочих пользователей системы можно будет создать в любой момент после установки операционной системы.
Подтверждение введенного (или сгенерированного) пароля учетной записи системного пользователя и продолжение работы программы установки выполняется нажатием кнопки Далее.

Глава 19. Установка пароля на шифрованные разделы

Примечание

Если вы не создавали шифруемые разделы, то этот шаг пропускается автоматически. В этом случае сразу переходите к главе Завершение установки.
На этом этапе требуется ввести пароль для шифруемых разделов. Этот пароль потребуется вводить для того, чтобы получать доступ к информации на данных разделах.
Установка пароля на LUKS-разделы
Например, если вы зашифровали /home, то во время загрузки системы будет необходимо ввести пароль для этого раздела, иначе вы не сможете получить доступ в систему под своим именем пользователя.

Глава 20. Завершение установки

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

Глава 21. Обновление системы до актуального состояния

После установки системы, её лучше сразу обновить до актуального состояния. Можно не обновлять систему и сразу приступать к работе только в том случае, если вы не планируете подключаться к сети или Интернету, не собираетесь устанавливать дополнительных программ.
Для обновления системы необходимо выполнить команды (с правами администратора):
# apt-get update
# apt-get dist-upgrade
# update-kernel
# apt-get clean
# reboot

Примечание

Получить права администратора можно, выполнив в терминале команду:
$ su -
или зарегистрировавшись в системе (например, на второй консоли Ctrl+Alt+F2) под именем root. Про режим суперпользователя можно почитать в главе Режим суперпользователя.

Примечание

Подробнее про обновление пакетов можно прочитать в главах Обновление всех установленных пакетов и Обновление ядра.

Глава 22. Первая помощь

Важно

В случае возникновения каких-либо неприятностей не паникуйте, а спокойно разберитесь в сложившейся ситуации. Linux не так уж просто довести до полной неработоспособности и утраты ценных данных. Поспешные действия отчаявшегося пользователя могут привести к плачевным результатам. Помните, что решение есть, и оно обязательно найдётся!

22.1. Проблемы при установке системы

Важно

При возникновении проблем с UEFI или Legacy/CSM рекомендуется изменить выбор используемого вида прошивки на другой. Не следует выбирать режим смешанной загрузки Legacy/UEFI! Рекомендуется отключить всевозможные оптимизации и ускорение UEFI-загрузки, а также отключить на время установки SecureBoot.
Если в системе не произошла настройка какого-либо компонента после стадии установки пакетов, не отчаивайтесь, доведите установку до конца, загрузитесь в систему и попытайтесь в спокойной обстановке повторить настройку.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. В открывшемся редакторе следует найти строку, начинающуюся с linux /boot/vmlinuz, в её конец дописать требуемые параметры, отделив пробелом и нажать F10.
Редактор параметров пункта загрузки
Примеры параметров пункта загрузки:
  • nomodeset — не использовать modeset-драйверы для видеокарты;
  • vga=normal — отключить графический экран загрузки установщика;
  • xdriver=vesa — явно использовать видеодрайвер vesa. Данным параметром можно явно указать нужный вариант драйвера;
  • acpi=off noapic — отключение ACPI (управление питанием), если система не поддерживает ACPI полностью.
Если вы вообще не смогли установить систему (не произошла или не завершилась стадия установки пакетов), то сначала попробуйте повторить попытку в безопасном режиме (apm=off acpi=off mce=off barrier=off vga=normal). В безопасном режиме отключаются все параметры ядра, которые могут вызвать проблемы при загрузке. В этом режиме установка будет произведена без поддержки APIC. Возможно, у вас какое-то новое или нестандартное оборудование, но может оказаться, что оно отлично настраивается со старыми драйверами.
Если вы хотите получить точный ответ, то сообщите, пожалуйста, подробный состав вашего оборудования и подробное описание возникшей проблемы в нашей системе отслеживания ошибок.

22.2. Проблемы с загрузкой системы

Если не загружается ни одна из установленных операционных систем, то значит, есть проблема в начальном загрузчике. Такие проблемы могут возникнуть после установки системы, в случае если загрузчик все-таки не установлен или установлен с ошибкой. При установке или переустановке Windows на вашем компьютере загрузчик Linux будет перезаписан в принудительном порядке, и станет невозможно запускать Linux.
Повреждение или перезапись загрузчика никак не затрагивает остальные данные на жёстком диске, поэтому в такой ситуации очень легко вернуть работоспособность: для этого достаточно восстановить загрузчик.
Если у вас исчез загрузчик другой операционной системы или другого производителя, то внимательно почитайте соответствующее официальное руководство на предмет его восстановления. Но в большинстве случаев вам это не потребуется, так как загрузчик, входящий в состав Альт Виртуализация, поддерживает загрузку большинства известных операционных систем.
Для восстановления загрузчика достаточно любым доступным способом загрузить Linux и получить доступ к тому жёсткому диску, на котором находится повреждённый загрузчик. Для этого проще всего воспользоваться восстановительным режимом, который предусмотрен на установочном диске дистрибутива (пункт Восстановление системы).
Загрузка восстановительного режима заканчивается приглашением командной строки: [root@localhost /]#. Начиная с этого момента, система готова к вводу команд.
В большинстве случаев для восстановления загрузчика можно просто воспользоваться командой fixmbr без параметров. Программа попытается переустановить загрузчик в автоматическом режиме.

22.3. Полезные ссылки

Если у вас что-то не получается, вы всегда можете поискать решение на ресурсах, указанных в разделе Техническая поддержка продуктов «Базальт СПО».

Часть III. Начало использования Альт Виртуализация

В этой части рассматривается загрузка установленной операционной системы и вход в среду рабочего стола.

Глава 23. Загрузка системы

Запуск Альт Виртуализация выполняется автоматически после запуска компьютера и отработки набора программ BIOS.
На экране появляется меню, в котором перечислены возможные варианты загрузки операционной системы.
Загрузка системы

Важно

При первом старте, в условиях установки нескольких ОС на один компьютер, возможно отсутствие в загрузочном меню пункта/пунктов с другой/другими операционными системами, они будут добавлены в список при последующей перезагрузке. Все перечисленные в меню после перезагрузки варианты могут быть загружены загрузчиком Linux.
Стрелками клавиатуры Вверх и Вниз выберите нужную операционную систему. Дополнительно к основным вариантам запуска ОС из этого меню можно загрузить Linux в безопасном режиме или запустить проверку памяти.
Загрузка операционной системы по умолчанию (первая в списке) начинается автоматически после небольшого времени ожидания (обычно несколько секунд). Нажав клавишу Enter, можно начать загрузку немедленно.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, то редактировать их нет необходимости.
В процессе загрузки Альт Виртуализация пользователь может следить за информацией процесса загрузки, которая отображает этапы запуска различных служб и программных серверов в виде отдельных строк, на экране монитора.
Информация процесса загрузки системы
При этом каждая строка начинается словом вида [XXXXXXX] (FAILED или OK), являющегося признаком нормального или ненормального завершения этапа загрузки. Слово XXXXXXX=FAILED (авария) свидетельствует о неуспешном завершении этапа загрузки, что требует вмешательства и специальных действий администратора системы.
Загрузка операционной системы может занять некоторое время, в зависимости от производительности компьютера. Основные этапы загрузки операционной системы — загрузка ядра, подключение (монтирование) файловых систем, запуск системных служб — периодически могут дополняться проверкой файловых систем на наличие ошибок. В этом случае время ожидания может быть занять больше времени, чем обычно. Подробную информацию о шагах загрузки можно получить, нажав клавишу Esc.

Глава 24. Получение доступа к зашифрованным разделам

В случае, если вы создали шифрованный раздел, вам потребуется вводить пароль при обращении к этому разделу.
Например, если был зашифрован домашний раздел /home, то для того, чтобы войти в систему под своим именем пользователя, вам потребуется ввести пароль этого раздела и затем нажать Enter.

Важно

Если не ввести пароль за отведенный промежуток времени, то загрузка системы завершится ошибкой. В этом случае вам следует перезагрузить систему, нажав для этого два раза Enter, а затем клавиши Ctrl+Alt+Delete.

Глава 25. Вход в систему

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

Примечание

После загрузки будут показаны имя и IP-адрес компьютера, а также, если были установлены OpenNebula или PVE, адрес доступа к панели управления:
IP адрес компьютера и адрес панели управления PVE
В процессе работы ОС Альт Виртуализация активно несколько виртуальных консолей. Каждая виртуальная консоль доступна по одновременному нажатию клавиш Ctrl, Alt и функциональной клавиши с номером этой консоли от F1 до F6.
На первых шести виртуальных консолях (от Ctrl+Alt+F1 до Ctrl+Alt+F6) пользователь может зарегистрироваться и работать в текстовом режиме. Двенадцатая виртуальная консоль (Ctrl+Alt+F12) выполняет функцию системной консоли – на нее выводятся сообщения о происходящих в системе событиях.

Часть IV. OpenNebula

OpenNebula — это платформа облачных вычислений для управления разнородными инфраструктурами распределенных центров обработки данных. Платформа OpenNebula управляет виртуальной инфраструктурой центра обработки данных для создания частных, общедоступных и гибридных реализаций инфраструктуры как службы.
Облачная архитектура определяется 3-мя элементами: хранилищем данных, сетью и системой виртуализации.
OpenNebula состоит из следующих компонентов:
  • Сервер управления (Front-end) — на нём выполняются сервисы OpenNebula;
  • Серверы с виртуальными машинами;
  • Хранилище данных — содержит образы виртуальных машин;
  • Физическая сеть — обеспечивает связь между хранилищем данных, серверами с виртуальными машинами, поддерживает VLAN-ы для виртуальных машин, а также управление сервисами OpenNebula.
Архитектура OpenNebula

Примечание

Компоненты OpenNebula будут установлены в систему, если при установке дистрибутива выбрать профиль Вычислительный узел Opennebula KVM, Вычислительный узел Opennebula LXC или Сервер управления Opennebula (см. главу Установка системы).

Содержание

26. Планирование ресурсов
26.1. Сервер управления
26.2. Серверы виртуализации
26.3. Хранилище данных
26.4. Сетевая инфраструктура
27. Запуск сервера управления OpenNebula
27.1. Установка пароля для пользователя oneadmin
27.2. Настройка MySQL (MariaDB) для хранения конфигурации
27.3. Запуск OpenNebula
27.4. Проверка установки
27.5. Ключи для доступа по SSH
27.6. Конфигурация сети
28. Настройка узлов
28.1. Установка и настройка узла OpenNebula KVM
28.2. Установка и настройка узла OpenNebula LXC
29. Добавление узлов в OpenNebula
29.1. Добавление узла типа KVM в OpenNebula-Sunstone
29.2. Добавление узла типа LXС в OpenNebula-Sunstone
29.3. Работа с узлами в командной строке
30. Виртуальные сети
30.1. Режим Bridged
30.2. Режим 802.1Q VLAN
30.3. Режим VXLAN
30.4. Режим Open vSwitch
30.5. VXLAN в Open vSwitch
31. Работа с хранилищами в OpenNebula
31.1. Типы хранилищ
31.2. Хранилища по умолчанию
31.3. Создание хранилищ
31.3.1. Локальное хранилище
31.3.2. Хранилище NFS/NAS
31.3.3. NFS/NAS и локальное хранилище
31.3.4. Хранилище SAN
31.3.5. Хранилище файлов и ядер
32. Работа с образами в OpenNebula
32.1. Создание образа ОС в среде OpenNebula
32.1.1. Создание образов дисков
32.1.2. Создание шаблона ВМ
32.1.3. Создание ВМ
32.1.4. Подключение к ВМ и установка ОС
32.1.5. Настройка контекстуализации
32.1.6. Создание образа типа ОС
32.2. Использование магазинов приложений OpenNebula
32.2.1. OpenNebula Public
32.2.2. Скачивание шаблона контейнера из магазина DockerHub
33. Управление пользователями
33.1. Пользователи
33.2. Группы пользователей
33.3. Управление разрешениями
33.4. Управление правилами ACL
33.5. Аутентификация пользователей
33.5.1. LDAP аутентификация
34. Настройка отказоустойчивого кластера
34.1. Первоначальная конфигурация Leader
34.2. Добавление дополнительных серверов
34.3. Добавление и удаление серверов
34.4. Восстановление сервера
34.5. Sunstone

Глава 26. Планирование ресурсов

26.1. Сервер управления

Таблица 26.1. Минимальные требования к серверу управления

Ресурс
Минимальное значение
Оперативная память
2 ГБ
CPU
1 CPU (2 ядра)
Диск
100 ГБ
Сеть
2 интерфейса
Максимальное количество серверов (узлов виртуализации), управляемых одним сервером управления, зависит от инфраструктуры, особенно от производительности хранилища. Обычно рекомендуется не управлять более чем 500 серверами из одной точки, хотя существуют примеры с более чем 1000 серверами.

26.2. Серверы виртуализации

Серверы виртуализации — это физические машины, на которых выполняются виртуальные машины. Подсистема виртуализации — это компонент, который отвечает за связь с гипервизором, установленным на узлах, и выполнение действий, необходимых для каждого этапа жизненного цикла виртуальной машины (ВМ).
Серверы (узлы) виртуализации имеют следующие характеристики и их рекомендованные значения:
  • CPU — в обычных условиях каждое ядро, предоставляемое ВМ, должно быть реальным ядром физического процессора. Например, для обслуживания 40 ВМ с двумя процессорами в каждой, облако должно иметь 80 физических ядер. При этом они могут быть распределены по разным серверам: 10 серверов с восемью ядрами или 5 серверов с 16 ядрами на каждом. В случае перераспределения недостаточных ресурсов используются атрибуты CPU и VCPU: CPU определяет физические ядра, выделенные для ВМ, а VCPU — виртуальные ядра для гостевой ОС.
  • Память — по умолчанию OpenNebula не предоставляет памяти для гостевых систем больше, чем есть на самом деле. Желательно рассчитывать объём памяти с запасом в 10% на гипервизор. Например, для 45 ВМ с 2 ГБ памяти на каждой, необходимо 90 ГБ физической памяти. Важным параметром является количество физических серверов: каждый сервер должен иметь 10% запас для работы гипервизора, так, 10 серверов с 10 ГБ памяти на каждом могут предоставить по 9 ГБ для виртуальных машин и смогут обслужить 45 машин из этого примера (10% от 10 ГБ = 1 ГБ на гипервизор).

26.3. Хранилище данных

OpenNebula работает с двумя видами данных в хранилище: образами ВМ и дисками самих ВМ (подробнее см. Работа с хранилищами в OpenNebula).
Одним из основных способов управления хранилищем данных является ограничение хранилища, доступного для пользователей, путем определения квот по максимальному количеству ВМ, а также максимального объема энергозависимой памяти, который может запросить пользователь, и обеспечения достаточного пространства хранения системных данных и образов, отвечающего предельным установленным квотам. OpenNebula позволяет администратору добавлять хранилища системных данных и образов, если это необходимо.
Планирование хранилища — является критически важным аспектом, поскольку от него зависит производительность облака. Размер хранилищ сильно зависит от базовой технологии. Например, при использовании Ceph для среднего по размеру облака, необходимо взять как минимум 3 сервера в следующей конфигурации: 5 дисков по 1 ТБ, 16 ГБ памяти, 2 CPU по 4 ядра в каждом и как минимум 2 сетевые карты.

26.4. Сетевая инфраструктура

Сетевая инфраструктура должна быть спланирована так, чтобы обеспечить высокую надёжность и пропускную способность. Рекомендуется использовать 2 сетевых интерфейса на сервере управления и по 4 на каждом сервере виртуализации (публичный, внутренний, для управления и для связи с хранилищем).

Глава 27. Запуск сервера управления OpenNebula

27.1. Установка пароля для пользователя oneadmin

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

Примечание

Файл /var/lib/one/.one/one_auth будет создан со случайно сгенерированным паролем. Необходимо поменять этот пароль перед запуском OpenNebula.
Для установки пароля для пользователя oneadmin необходимо выполнить команду:
# passwd oneadmin
Теперь зайдя под пользователем oneadmin следует заменить содержимое /var/lib/one/.one/one_auth. Он должен содержать следующее: oneadmin:<пароль>. Например:
$ echo "oneadmin:mypassword" > ~/.one/one_auth

27.2. Настройка MySQL (MariaDB) для хранения конфигурации

По умолчанию OpenNebula работает с SQLite. Если планируется использовать OpenNebula с MySQL, следует настроить данную конфигурацию перед первым запуском OpenNebula, чтобы избежать проблем с учетными данными oneadmin и serveradmin.

Примечание

Задать пароль root для mysql и настройки безопасности:
# mysql_secure_installation
Создать нового пользователя, предоставить ему привилегии в базе данных opennebula (эта база данных будет создана при первом запуске OpenNebula) и настроить уровень изоляции:
$ mysql -u root -p
Enter password:

MariaDB > GRANT ALL PRIVILEGES ON opennebula.* TO 'oneadmin' IDENTIFIED BY '<thepassword>';
Query OK, 0 rows affected (0.003 sec)

MariaDB > SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.001 sec)

MariaDB > quit
Перед запуском сервера OpenNebula в первый раз необходимо настроить параметры доступа к базе данных в конфигурационном файле /etc/one/oned.conf:
#DB = [ BACKEND = "sqlite" ]
#       TIMEOUT = 2500 ]

# Sample configuration for MySQL
DB = [ BACKEND = "mysql",
       SERVER  = "localhost",
       PORT    = 0,
       USER    = "oneadmin",
       PASSWD  = "<thepassword>",
       DB_NAME = "opennebula",
       CONNECTIONS = 25,
       COMPARE_BINARY = "no" ]

27.3. Запуск OpenNebula

Для добавления в атозапуск и запуска OpenNebula необходимо выполнить следующие команды:
# systemctl enable --now opennebula
# systemctl enable --now opennebula-sunstone

27.4. Проверка установки

После запуска OpenNebula в первый раз, следует проверить, что команды могут подключаться к демону OpenNebula. Это можно сделать в командной строке или в графическом интерфейсе пользователя: Sunstone.
В командной строке
$ oneuser show
USER 0 INFORMATION
ID              : 0
NAME            : oneadmin
GROUP           : oneadmin
PASSWORD        : 3bc15c8aae3e4124dd409035f32ea2fd6835efc9
AUTH_DRIVER     : core
ENABLED         : Yes

USER TEMPLATE
TOKEN_PASSWORD="ec21d27e2fe4f9ed08a396cbd47b08b8e0a4ca3c"

VMS USAGE & QUOTAS

VMS USAGE & QUOTAS - RUNNING

DATASTORE USAGE & QUOTAS

NETWORK USAGE & QUOTAS

IMAGE USAGE & QUOTAS
Можно также попробовать войти в веб-интерфейс Sunstone. Для этого необходимо перейти по адресу http://<внешний адрес>:9869. Если все в порядке, будет предложена страница входа.
Необходимо ввести в соответствующие поля имя пользователя (oneadmin) и пароль пользователя (тот, который находится в файле /var/lib/one/.one/one_auth):
Страница авторизации opennebula-sunstone
После входа в систему будет доступна панель инструментов:
Панель инструментов opennebula-sunstone

Примечание

Для смены языка интерфейса необходимо в левом меню выбрать пункт Settings, и на открывшейся странице в выпадающем списке Language выбрать пункт Russian (ru_RU):
Выбор языка интерфейса
Язык интерфейса будет изменён на русский:
Выбор языка интерфейса

27.5. Ключи для доступа по SSH

Сервер управления OpenNebula подключается к узлам гипервизора по SSH. Необходимо распространить открытый ключ пользователя oneadmin со всех машин в файл /var/lib/one/.ssh/authorized_keys на всех машинах.
При установке сервера управления OpenNebula ключ SSH был сгенерирован и добавлен в авторизованные ключи. Необходимо синхронизировать id_rsa, id_rsa.pub и authorized_keys сервера управления и узлов. Кроме того, следует создать файл known_hosts и также синхронизировать его с узлами. Чтобы создать файл known_hosts, необходимо выполнить следующую команду (от пользователя oneadmin на сервере управления) со всеми именами узлов и именем сервера управления в качестве параметров:
$ ssh-keyscan <сервер_управления> <узел1> <узел2> <узел3> ... >> /var/lib/one/.ssh/known_hosts 

Примечание

Команду ssh-keyscan необходимо выполнить, как для имён, так и для IP-адресов узлов/сервера управления:
$ ssh-keyscan <IP-узел1> <hostname-узел1> ... >> /var/lib/one/.ssh/known_hosts 
Например:
$ ssh-keyscan 192.168.0.185 server 192.168.0.190 host-01 >> /var/lib/one/.ssh/known_hosts 
Далее необходимо скопировать каталог /var/lib/one/.ssh на все узлы. Самый простой способ — установить временный пароль для oneadmin на всех узлах и ​​скопировать каталог с сервера управления:
$ scp -rp /var/lib/one/.ssh <узел1>:/var/lib/one/
$ scp -rp /var/lib/one/.ssh <узел2>:/var/lib/one/
$ scp -rp /var/lib/one/.ssh <узел3>:/var/lib/one/
...
После этого следует убедиться, что ни одно из этих подключений (под пользователем oneadmin) не заканчивается ошибкой, и пароль не запрашивается:
  • от сервера управления к самому серверу управления;
  • от сервера управления ко всем узлам;
  • от всех узлов на все узлы;
  • от всех узлов к серверу управления.
Эту проверку можно выполнить, например, на сервере управления:
# от сервера управления к самому серверу управления
ssh <сервер_управления>
exit

# от сервера управления к узлу1, обратно на сервер управления и к другим узлам
ssh <узел1>
ssh <сервер_управления>
exit
ssh <узел2>
exit
ssh <узел3>
exit
exit
И так далее для всех узлов.
Если требуется дополнительный уровень безопасности, можно хранить закрытый ключ только на сервере управления, а не копировать его на весь гипервизор. Таким образом, пользователь oneadmin в гипервизоре не сможет получить доступ к другим гипервизорам. Это достигается путем изменения /var/lib/one/.ssh/config на сервере управления и добавления параметра ForwardAgent к узлам гипервизора для пересылки ключа:
$ cat /var/lib/one/.ssh/config
 Host host-01
    User oneadmin
    ForwardAgent yes
 Host host-02
    User oneadmin
    ForwardAgent yes

27.6. Конфигурация сети

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

Примечание

Настройка сети необходима только на серверах с виртуальными машинами. Точное имя ресурсов (br0, br1 и т.д.) значения не имеет, но важно, чтобы мосты и сетевые карты имели одно и то же имя на всех узлах.

Глава 28. Настройка узлов

28.1. Установка и настройка узла OpenNebula KVM

Перед добавлением узла типа KVM на сервер OpenNebula следует настроить узел KVM.
Для создания узла типа KVM при установке дистрибутива нужно выбрать профиль Вычислительный узел Opennebula KVM (см. главу Установка системы):
Установка сервера виртуализации KVM

Примечание

Для создания узла типа KVM в уже установленной системе можно установить пакет opennebula-node-kvm:
# apt-get install opennebula-node-kvm
И добавить службу libvirtd в автозапуск и запустить её:
# systemctl enable --now libvirtd
После создания узла следует задать пароля для пользователя oneadmin:
# passwd oneadmin
и настроить доступ по SSH (см. раздел Ключи для доступа по SSH).

28.2. Установка и настройка узла OpenNebula LXC

LXD — это гипервизор LXC контейнеров.
Перед добавлением хоста типа LXC на сервер OpenNebula следует настроить узел LXC.

Важно

Для работы с LXC в OpenNebula должна быть настроена пара хранилищ (хранилище образов и системное) НЕ типа qcow2 (например, shared или ssh).
Для создания узла типа LXC, при установке дистрибутива нужно выбрать профиль Вычислительный узел Opennebula LXC (см. главу Установка системы):
Установка сервера контейнеризации LXC

Примечание

Для создания узла типа LXC в уже установленной системе необходимо выполнить следующие шаги:
  • установить пакет opennebula-node-lxc:
    # apt-get install opennebula-node-lxc
    
  • запустить и добавить в автозапуск lxc:
    # systemctl enable --now lxc
    
После создания узла следует задать пароля для пользователя oneadmin:
# passwd oneadmin
и настроить доступ по SSH (см. раздел Ключи для доступа по SSH).

Глава 29. Добавление узлов в OpenNebula

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

Примечание

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

29.1. Добавление узла типа KVM в OpenNebula-Sunstone

Для добавления узла, необходимо в левом меню выбрать ИнфраструктураУзлы и на загруженной странице нажать кнопку +:
Добавление узла в OpenNebula-Sunstone
Далее необходимо указать тип виртуализации, заполнить поле Имя хоста (можно ввести IP-адрес узла или его имя) и нажать кнопку Создать:
Добавление узла типа KVM в OpenNebula-Sunstone
Затем следует вернуться к списку узлов и убедиться, что узел перешел в состояние ВКЛ (это должно занять от 20 секунд до 1 минуты, можно нажать кнопку Обновить для обновления состояния):
Узлы в OpenNebula-Sunstone
Далее на этой вкладке можно включать, отключать, удалять и просматривать информацию об узлах.

29.2. Добавление узла типа LXС в OpenNebula-Sunstone

Для добавления узла типа LXС на сервере OpenNebula, необходимо в левом меню выбрать ИнфраструктураУзлы и на загруженной странице нажать кнопку +:
Добавление узла в OpenNebula-Sunstone
Далее необходимо указать тип виртуализации — LXС, заполнить поле Имя хоста (можно ввести IP-адрес узла или его имя) и нажать кнопку Создать:
Добавление узла типа LXС в OpenNebula-Sunstone
Затем следует вернуться к списку узлов и убедиться, что узел перешел в состояние ВКЛ (это должно занять от 20 секунд до 1 минуты).

29.3. Работа с узлами в командной строке

onehost — это инструмент управления узлами в OpenNebula. Описание всех доступных опций утилиты onehost можно получить, выполнив команду:
$ man onehost
Для добавления узла KVM в облако, необходимо выполнить следующую команду от oneadmin на сервере управления:
$ onehost create host-01 --im kvm --vm kvm
ID: 0
Команда добавления узла типа LXС:
$ onehost create host-02 --im lxс --vm lxс
ID: 1
Список узлов можно просмотреть, выполнив команду:
$ onehost list
  ID NAME         CLUSTER    TVM      ALLOCATED_CPU      ALLOCATED_MEM STAT
   1 host-02      default      0       0 / 100 (0%)     0K / 945M (0%) on
   0 host-01      default      0     0 / 10000 (0%)     0K / 7.6G (0%) on

Примечание

Если возникли проблемы с добавлением узла, то, скорее всего, неправильно настроен SSH. Ошибки можно просмотреть в /var/log/one/oned.log.
Для указания узла можно использовать его ID или имя. Например, удаление узла с указанием ID:
$ onehost delete 1
или имени:
$ onehost delete host-02
Изменение статуса узла:
$ onehost disable host-01 // деактивировать узел
$ onehost enable host-01 // активировать узел
$ onehost offline host-01 // полностью выключить узел

Примечание

Команды onehost disable и onehost offline не меняют состояние уже работающих на узле ВМ. Если необходимо автоматически перенести работающие ВМ, следует использовать команду onehost flush.
Команда onehost flush перенесет все активные ВМ с указанного узла на другой сервер с достаточной емкостью. При этом указанный узел будет отключен. Эта команда полезна для очистки узла от активных ВМ. Процесс миграции можно выполнить с помощью переноса (resched) или действия восстановления, удаления и воссоздания. Это поведение можно настроить в /etc/one/cli/onehost.yaml, установив в поле default_actions\flush значение delete-recreate или resched. Например:
:default_actions:
  - :flush: resched
Просмотр информации об узле:
$ onehost show host-01
Вывод данной команды содержит:
  • общую информацию об узле;
  • информацию о процессоре и объёме оперативной памяти (Host Shares);
  • информацию о локальном хранилище данных (Local System Datastore), если узел настроен на использование локального хранилища данных;
  • данные мониторинга;
  • информацию о ВМ, запущенных на узле.

Глава 30. Виртуальные сети

OpenNebula позволяет создавать виртуальные сети, отображая их поверх физических.
При запуске новой ВМ OpenNebula подключит свои виртуальные сетевые интерфейсы (определяемые атрибутами NIC) к сетевым устройствам гипервизора, так как определено в соответствующей виртуальной сети. Это позволит ВМ иметь доступ к публичным и частным сетям.
onevnet — инструмент управления виртуальными сетями в OpenNebula. Описание всех доступных опций утилиты onevnet можно получить, выполнив команду:
$ man onevnet
Вывести список виртуальных сетей можно, выполнив команду:
$ onevnet list
  ID USER     GROUP    NAME              CLUSTERS   BRIDGE               LEASES
   2 oneadmin oneadmin VirtNetwork       0          onebr2               0
   0 oneadmin oneadmin LAN               0          vmbr0                1
Вывести информацию о сети:
$ onevnet show 0
Создавать, редактировать, удалять и просматривать информацию о виртуальных сетях можно в веб-интерфейсе:
Работа с виртуальными сетями в OpenNebula-Sunstone
OpenNebula поддерживает следующие сетевые режимы:
  • Bridged (режим Сетевой мост) — сетевой адаптер ВМ напрямую соединяется с существующим мостом в узле виртуализации;
  • 802.1Q (режим VLAN) — сетевой адаптер ВМ соединяется с существующим мостом в узле виртуализации, а виртуальная сеть настраивается для изоляции VLAN 802.1Q;
  • VXLAN — сетевой адаптер ВМ соединяется с существующим мостом в узле виртуализации, а виртуальная сеть реализует изоляцию с помощью инкапсуляции VXLAN;
  • Open vSwitch — сетевой адаптер ВМ соединяется с существующим мостом Open vSwitch в узле виртуализации, а виртуальная сеть дополнительно обеспечивает изоляцию VLAN 802.1Q;
  • Open vSwitch — VXLAN — сетевой адаптер ВМ соединяется с существующим мостом Open vSwitch в узле виртуализации, а виртуальная сеть дополнительно обеспечивает изоляцию с помощью инкапсуляции VXLAN и, при необходимости, VLAN 802.1Q.
Атрибут VN_MAD виртуальной сети определяет, какой из вышеуказанных сетевых режимов используется.

30.1. Режим Bridged

В этом режиме трафик ВМ передается напрямую через мост Linux на узлах гипервизора. Мостовые сети могут работать в трёх различных режимах в зависимости от дополнительной фильтрации трафика, выполняемой OpenNebula:
  • Bridged — сетевой мост без фильтрации, управляемый мост;
  • Bridged & Security Groups (сетевой мост с группами безопасности) — для реализации правил групп безопасности устанавливаются правила iptables;
  • Bridged & ebtables VLAN (сетевой мост с правилами ebtables) — аналогично Bridged & Security Groups, плюс дополнительные правила ebtables для обеспечения изоляции L2 виртуальных сетей.
При фильтрации трафика необходимо учитывать следующее:
  • в режимах Bridged и Bridged & Security Groups для обеспечения сетевой изоляции можно добавлять тегированные сетевые интерфейсы;
  • режим Bridged with ebtables VLAN предназначен для небольших сред без соответствующей аппаратной поддержки для реализации VLAN. Данный режим ограничен сетями /24 и IP-адреса не могут перекрываться в виртуальных сетях. Этот режим рекомендуется использовать только в целях тестирования.
На узле виртуализации необходимо создать сетевой мост для каждой сети, в которой будут работать ВМ. При этом следует использовать одно имя сети на всех узлах.

Таблица 30.1. Параметры виртуальной сети в режиме Bridged

Параметр
Значение
Обязательный
NAME
Имя виртуальной сети
Да
VN_MAD
Режим:
  • bridge — режим без фильтрации;
  • fw — фильтрация с группами безопасности;
  • ebtables — фильтрация с изоляцией ebtables;
Да
BRIDGE
Имя сетевого моста в узлах виртуализации
Нет
PHYDEV
Имя физического сетевого устройства (на узле виртуализации), которое будет подключено к мосту
Нет
AR
Диапазон адресов, доступных в виртуальной сети
Нет
Пример создания виртуальной сети с использованием конфигурационного файла:
  1. Создать файл net-bridged.conf со следующим содержимым:
    NAME = "VirtNetwork"
    VN_MAD = "bridge"
    BRIDGE = "vmbr0"
    PHYDEV = "enp3s0"
    
    AR=[
        TYPE = "IP4",
        IP   = "192.168.0.140",
        SIZE = "5"
    ]
    
  2. Выполнить команду:
    $ onevnet create net-bridged.conf
    ID: 1
    
Пример создания виртуальной сети в веб-интерфейсе:
  • в левом меню выбрать пункт СетьВирт. сети, на загруженной странице нажать кнопку + и выбрать пункт Создать.
  • на вкладке Общие указать название виртуальной сети:
    Создание виртуальной сети
  • на вкладке Конфигурация необходимо указать интерфейс сетевого моста, выбрать режим работы сети:
    Создание виртуальной сети в режиме bridge
  • на вкладке Адреса можно указать диапазон IP-адресов, который будет использоваться при выделении IP-адресов для ВМ:
    OpenNebula. Выделение диапазона IP-адресов
  • нажать кнопку Создать.

Примечание

Если в качестве интерфейса моста указать интерфейс, через который производится управление и доступ к узлу, то при запуске ВМ этот интерфейс будет автоматически включен в сетевой мост и соединение с сервером будет потеряно. Поэтому в качестве интерфейса, на котором будут автоматически создаваться сетевые мосты (bridge) для виртуальных сетей, необходимо использовать отдельный сетевой интерфейс (в примере интерфейс enp3s0).

30.2. Режим 802.1Q VLAN

В этом режиме для каждой виртуальной сети OpenNebula создаётся мост, сетевой интерфейс подключается к этому мосту с тегами VLAN. Этот механизм соответствует стандарту IEEE 802.1Q.
Идентификатор VLAN будет автоматически назначен OpenNebula и будет одинаков для каждого интерфейса в данной сети. Идентификатор VLAN также можно назначить принудительно, указав параметр VLAN_ID в шаблоне виртуальной сети.
Идентификатор VLAN рассчитывается в соответствии со следующим параметром конфигурации /etc/one/oned.conf:
VLAN_IDS = [
    START    = "2",
    RESERVED = "0, 1, 4095"
]
Драйвер сначала попытается выделить VLAN_IDS[START] + VNET_ID где
  • START — первый VLAN_ID, который будет использоваться;
  • RESERVED — список VLAN_ID или диапазонов, которые не будут назначаться виртуальной сети (два числа, разделенные двоеточием, обозначают диапазон).

Таблица 30.2. Параметры виртуальной сети в режиме 802.1Q

Параметр
Значение
Обязательный
NAME
Имя виртуальной сети
Да
VN_MAD
802.1Q
Да
BRIDGE
Имя сетевого моста (по умолчанию onebr<net_id> или onebr.<vlan_id>)
Нет
PHYDEV
Имя физического сетевого устройства (на узле виртуализации), которое будет подключено к мосту
Да
VLAN_ID
ID сети VLAN (если не указан и AUTOMATIC_VLAN_ID = "YES", то идентификатор будет сгенерирован)
Да (если AUTOMATIC_VLAN_ID = "NO")
AUTOMATIC_VLAN_ID
Генерировать VLAN_ID автоматически
Да (если не указан VLAN_ID)
MTU
MTU для тегированного интерфейса и моста
Нет
AR
Диапазон адресов, доступных в виртуальной сети
Нет
Пример создания виртуальной сети с использованием конфигурационного файла:
  1. Создать файл net-vlan.conf со следующим содержимым:
    NAME = "VLAN"
    VN_MAD = "802.1Q"
    BRIDGE = "vmbr1"
    PHYDEV = "enp3s0"
    AUTOMATIC_VLAN_ID = "Yes"
    AR=[
        TYPE = "IP4",
        IP   = "192.168.0.150",
        SIZE = "5"
    ]
    
  2. Выполнить команду:
    $ onevnet create net-vlan.conf
    ID: 6
    
Пример создания виртуальной сети в режиме 802.1Q в веб-интерфейсе:
Создание виртуальной сети в режиме 802.1Q
В этом примере драйвер проверит наличие моста vmbr1. Если его не существует, он будет создан. Сетевой интерфейс enp3s0 будет помечен тегом (например, enp3s0.7) и подсоединён к vmbr1.

30.3. Режим VXLAN

В режиме VXLAN (Virtual eXtensible Local Area Network) для каждой виртуальной сети OpenNebula создаётся мост, сетевой интерфейс подключается к этому мосту с тегами VXLAN.
Идентификатор VLAN будет автоматически назначен OpenNebula и будет одинаков для каждого интерфейса в данной сети. Идентификатор VLAN также можно назначить принудительно, указав параметр VLAN_ID в шаблоне виртуальной сети.
С каждой сетью VLAN связывается адрес многоадресной рассылки для инкапсуляции широковещательного и многоадресного трафика L2. По умолчанию данный адрес будет принадлежать диапазону 239.0.0.0/8 в соответствии с RFC 2365 (многоадресная IP-адресация с административной областью). Адрес многоадресной рассылки получается путем добавления значения атрибута VLAN_ID к базовому адресу 239.0.0.0/8.
В данном сетевом режиме задействован стандартный UDP-порт сервера 8472.

Примечание

Сетевой интерфейс, который будет выступать в роли физического устройства, должен иметь IP-адрес.
Начальный идентификатор VXLAN можно указать в файле /etc/one/oned.conf:
VXLAN_IDS = [
    START = "2"
]

Таблица 30.3. Параметры виртуальной сети в режиме VXLAN

Параметр
Значение
Обязательный
NAME
Имя виртуальной сети
Да
VN_MAD
vxlan
Да
BRIDGE
Имя сетевого моста (по умолчанию onebr<net_id> или onebr.<vlan_id>)
Нет
PHYDEV
Имя физического сетевого устройства, которое будет подключено к мосту
Нет
VLAN_ID
ID сети VLAN (если не указан и AUTOMATIC_VLAN_ID = "YES", то идентификатор будет сгенерирован)
Да (если AUTOMATIC_VLAN_ID = "NO")
AUTOMATIC_VLAN_ID
Генерировать VLAN_ID автоматически
Да (если не указан VLAN_ID)
MTU
MTU для тегированного интерфейса и моста
Нет
AR
Диапазон адресов, доступных в виртуальной сети
Нет
Пример создания виртуальной сети с использованием конфигурационного файла:
  1. Создать файл net-vxlan.conf со следующим содержимым:
    NAME = "vxlan"
    VN_MAD = "vxlan"
    BRIDGE = "vxlan50"
    PHYDEV = "enp3s0"
    VLAN_ID = 50
    AR=[
        TYPE = "IP4",
        IP   = "192.168.0.150",
        SIZE = "5"
    ]
    
  2. Выполнить команду:
    $ onevnet create net-vxlan.conf
    ID: 7
    
Пример создания виртуальной сети в режиме VXLAN в веб-интерфейсе:
Создание виртуальной сети в режиме vxlan
В этом примере драйвер проверит наличие моста vxlan50. Если его не существует, он будет создан. Сетевой интерфейс enp3s0 будет помечен тегом (enp3s0.10) и подсоединён к vxlan50.

30.4. Режим Open vSwitch

Сети Open vSwitch создаются на базе программного коммутатора Open vSwitch.

Примечание

На узлах виртуализации должен быть установлен пакет openvswitch:
# apt-get install openvswitch
Запупущена и добавлена в автозагрузку служба openvswitch:
# systemctl enable --now openvswitch.service
Идентификатор VLAN будет автоматически назначен OpenNebula и будет одинаков для каждого интерфейса в данной сети. Идентификатор VLAN также можно назначить принудительно, указав параметр VLAN_ID в шаблоне виртуальной сети.
Идентификатор VLAN можно настроить в файле /etc/one/oned.conf:
VLAN_IDS = [
    START    = "2",
    RESERVED = "0, 1, 4095"
]

Таблица 30.4. Параметры виртуальной сети в режиме Open vSwitch

Параметр
Значение
Обязательный
NAME
Имя виртуальной сети
Да
VN_MAD
ovswitch
Да
BRIDGE
Имя сетевого моста Open vSwitch
Нет
PHYDEV
Имя физического сетевого устройства, которое будет подключено к мосту
Нет (если не используются VLAN)
VLAN_ID
ID сети VLAN (если не указан и AUTOMATIC_VLAN_ID = "YES", то идентификатор будет сгенерирован)
Нет
AUTOMATIC_VLAN_ID
Генерировать VLAN_ID автоматически (игнорируется, если определен VLAN_ID)
Нет
MTU
MTU для моста Open vSwitch
Нет
AR
Диапазон адресов, доступных в виртуальной сети
Нет
Пример создания виртуальной сети с использованием конфигурационного файла:
  1. Создать файл net-ovs.conf со следующим содержимым:
    NAME = "OVS"
    VN_MAD = "ovswitch"
    BRIDGE = "vmbr1"
    AR=[
        TYPE = "IP4",
        IP   = "192.168.0.150",
        SIZE = "5"
    ]
    
  2. Выполнить команду:
    $ onevnet create net-ovs.conf
    ID: 8
    
Пример создания виртуальной сети в режиме Open vSwitch в веб-интерфейсе:
Создание виртуальной сети в режиме Open vSwitch

30.5. VXLAN в Open vSwitch

В качестве основы используется оверлейная сеть VXLAN с Open vSwitch (вместо обычного моста Linux). Трафик на самом низком уровне изолируется протоколом инкапсуляции VXLAN, а Open vSwitch обеспечивает изоляцию второго уровня с помощью тегов VLAN 802.1Q внутри инкапсулированного трафика. Основная изоляция всегда обеспечивается VXLAN, а не VLAN 802.1Q. Если для изоляции VXLAN требуется 802.1Q, драйвер необходимо настроить с использованием созданного пользователем физического интерфейса с тегами 802.1Q.

Таблица 30.5. Параметры виртуальной сети в режиме Open vSwitch VXLAN

Параметр
Значение
Обязательный
NAME
Имя виртуальной сети
Да
VN_MAD
ovswitch_vxlan
Да
BRIDGE
Имя сетевого моста Open vSwitch
Нет
PHYDEV
Имя физического сетевого устройства, которое будет подключено к мосту
Да
OUTER_VLAN_ID
ID внешней сети VXLAN (если не указан и AUTOMATIC_OUTER_VLAN_ID = "YES", то идентификатор будет сгенерирован)
Да (если AUTOMATIC_OUTER_VLAN_ID = "NO")
AUTOMATIC_OUTER_VLAN_ID
Генерировать ID автоматически (игнорируется, если определен OUTER_VLAN_ID)
Да (если не указан OUTER_VLAN_ID)
VLAN_ID
Внутренний идентификатор VLAN 802.1Q. (если не указан и AUTOMATIC_VLAN_ID = "YES", то идентификатор будет сгенерирован)
Нет
AUTOMATIC_VLAN_ID
Генерировать VLAN_ID автоматически (игнорируется, если определен VLAN_ID)
Нет
MTU
MTU для интерфейса и моста VXLAN
Нет
AR
Диапазон адресов, доступных в виртуальной сети
Нет
Пример создания виртуальной сети с использованием конфигурационного файла:
  1. Создать файл net-ovsx.conf со следующим содержимым:
    NAME = "private"
    VN_MAD = "ovswitch_vxla"
    PHYDEV = "eth0"
    BRIDGE = "ovsvxbr0.10000"
    OUTER_VLAN_ID = 10000
    VLAN_ID = 50
    AR=[
        TYPE = "IP4",
        IP   = "192.168.0.150",
        SIZE = "5"
    ]
    
  2. Выполнить команду:
    $ onevnet create net-ovsx.conf
    ID: 11
    
В этом примере драйвер проверит наличие моста ovsvxbr0.10000. Если его нет, он будет создан. Также будет создан интерфейс VXLAN eth0.10000 и подключен к мосту Open vSwitch ovsvxbr0.10000. При создании экземпляра виртуальной машины ее порты моста будут помечены идентификатором 802.1Q VLAN ID 50.
Пример создания виртуальной сети в режиме Open vSwitch VXLAN в веб-интерфейсе:
Создание виртуальной сети в режиме Open vSwitch VXLAN

Глава 31. Работа с хранилищами в OpenNebula

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

OpenNebula использует три типа хранилищ данных:
  • хранилище образов (Images Datastore) — используется для хранения образов ВМ, которые можно использовать для создания ВМ;
  • системное хранилище (System Datastore) — используется для хранения дисков ВМ, работающих в текущий момент. Образы дисков перемещаются, или клонируются, в хранилище образов или из него при развертывании и отключении ВМ, при подсоединении или фиксировании мгновенного состояния дисков;
  • хранилище файлов и ядер (Files & Kernels Datastore) — используется для хранения простых файлов, используемых в контекстуализации, или ядер ВМ, используемых некоторыми гипервизорами.
В зависимости от назначения выделяют два типа образов:
  • постоянные (persistent) — предназначены для хранения пользовательских данных (например, БД). Изменения, внесенные в такие образы, будут сохранены после завершения работы ВМ. В любой момент времени может быть только одна ВМ, использующая постоянный образ.
  • непостоянные (non-persistent) — используются для хранения дисков ВМ, работающих в текущий момент. Образы дисков копируются, или клонируются, в хранилище образов или из него при развертывании и отключении ВМ, при подсоединении или фиксировании мгновенного состояния дисков. После удаления ВМ копия образа в системном хранилище также удаляется.
Схема взаимодействия хранилищ
Образы дисков передаются между хранилищем образов и системным хранилищем с помощью драйверов Transfer Manager (TM). Эти драйверы представляют собой специальные элементы ПО, которые выполняют низкоуровневые операции хранения.
Образы сохраняются в соответствующий каталог хранилища (/var/lib/one/datastores/<идентификатор_хранилища>). Кроме того, для каждой работающей ВМ существует каталог /var/lib/one/datastores/<идентификатор_хранилища>/<идентификатор_ВМ> в соответствующем системном хранилище. Эти каталоги содержат диски ВМ и дополнительные файлы, например, контрольные точки или снимки.
Например, система с хранилищем образов (1) с тремя образами и тремя ВМ (ВМ 0 и 2 работают, 7 — остановлена), развернутыми на системном хранилище (0), будет иметь следующую структуру:
/var/lib/one/datastores
|-- 0/
|   |-- 0/
|   |   |-- disk.0
|   |   `-- disk.1
|   |-- 2/
|   |   `-- disk.0
|   `-- 7/
|       |-- checkpoint
|       `-- disk.0
`-- 1
|-- 19217fdaaa715b04f1c740557826514b
|-- 99f93bd825f8387144356143dc69787d
`-- da8023daf074d0de3c1204e562b8d8d2
Драйвер передачи ssh использует локальную файловую систему узлов для размещения образов работающих ВМ. Все файловые операции выполняются локально, но образы всегда приходится копировать на узлы, что может оказаться очень ресурсоемкой операцией.
Драйвер передачи ssh
Драйвер shared предполагает, что на всех узлах установлена и настроена распределенная файловая система, например, NFS. Все файловые операции (ln, cp и т.д.) выполняются на узле виртуализации. Данный метод передачи сокращает время развертывания ВМ и обеспечивает возможность динамического перемещения.
Драйвер передачи shared
Драйвер lvm рекомендуется использовать при наличии высокопроизводительной сети SAN. Один и тот же LUN можно экспортировать на все узлы, а ВМ будут работать непосредственно из SAN. При этом образы хранятся как обычные файлы (в /var/lib/one/datastores//<идентификатор_хранилища>) в хранилище образов, но при создании ВМ они будут сброшены в логические тома (LV). ВМ будут запускаться с логических томов узла.
Драйвер передачи lvm

31.2. Хранилища по умолчанию

По умолчанию в OpenNebula созданы три хранилища: хранилище образов (Images), системное (System) и файлов (Files).
По умолчанию хранилища настроены на использование локальной файловой системы (каталоги /var/lib/one/datastores/<идентификатор_хранилища>). При этом для передачи данных между хранилищем образов и системным хранилищем используется метод ssh.

Примечание

Стандартный путь для хранилищ /var/lib/one/datastores/ можно изменить, указав нужный путь в параметре DATASTORE_LOCATION в конфигурационном файле /etc/one/oned.conf.
onedatastore — инструмент управления хранилищами в OpenNebula. Описание всех доступных опций утилиты onedatastore можно получить, выполнив команду:
$ man onedatastore
Вывести список хранилищ данных можно, выполнив команду:
$ onedatastore list
ID NAME                       SIZE AVA CLUSTERS IMAGES TYPE DS      TM      STAT
2 files                      95.4G 91% 0             1 fil  fs      ssh     on
1 default                    95.4G 91% 0             8 img  fs      ssh     on
0 system                         - -   0             0 sys  -       ssh     on
Вывести информацию о хранилище образов:
$ onedatastore show default
DATASTORE 1 INFORMATION
ID             : 1
NAME           : default
USER           : oneadmin
GROUP          : oneadmin
CLUSTERS       : 0
TYPE           : IMAGE
DS_MAD         : fs
TM_MAD         : ssh
BASE PATH      : /var/lib/one//datastores/1
DISK_TYPE      : FILE
STATE          : READY

DATASTORE CAPACITY
TOTAL:         : 95.4G
FREE:          : 55.9G
USED:          : 34.6G
LIMIT:         : -

PERMISSIONS
OWNER          : um-
GROUP          : u--
OTHER          : ---

DATASTORE TEMPLATE
ALLOW_ORPHANS="YES"
CLONE_TARGET="SYSTEM"
DISK_TYPE="FILE"
DS_MAD="fs"
LN_TARGET="SYSTEM"
RESTRICTED_DIRS="/"
SAFE_DIRS="/var/tmp"
TM_MAD="ssh"
TYPE="IMAGE_DS"

IMAGES
0
1
2
17
Вывести информацию о системном хранилище:
$ onedatastore show system
DATASTORE 0 INFORMATION
ID             : 0
NAME           : system
USER           : oneadmin
GROUP          : oneadmin
CLUSTERS       : 0
TYPE           : SYSTEM
DS_MAD         : -
TM_MAD         : ssh
BASE PATH      : /var/lib/one//datastores/0
DISK_TYPE      : FILE
STATE          : READY

DATASTORE CAPACITY
TOTAL:         : -
FREE:          : -
USED:          : -
LIMIT:         : -

PERMISSIONS
OWNER          : um-
GROUP          : u--
OTHER          : ---

DATASTORE TEMPLATE
ALLOW_ORPHANS="YES"
DISK_TYPE="FILE"
DS_MIGRATE="YES"
RESTRICTED_DIRS="/"
SAFE_DIRS="/var/tmp"
SHARED="NO"
TM_MAD="ssh"
TYPE="SYSTEM_DS"

IMAGES
Информация о хранилище содержит следующие разделы:
  • INFORMATION — содержит базовую информацию о хранилище (название, путь к файлу хранилища, тип) и набор драйверов (DS_MAD и TM_MAD), используемых для хранения и передачи образов;
  • CAPACITY — содержит основные показатели использования (общее, свободное и использованное пространство);
  • TEMPLATE — содержит атрибуты хранилища;
  • IMAGES — список образов, хранящихся в данный момент в этом хранилище.
В данном примере хранилище образов использует файловый драйвер (DS_MAD="fs") и протокол SSH для передачи (TM_MAD=ssh). Для системного хранилища определен только драйвер передачи (TM_MAD). Для системного хранилища также не указываются показатели использования (CAPACITY), так как драйвер ssh использует локальную область хранения каждого узла.

Примечание

Чтобы проверить доступное пространство на конкретном узле, можно воспользоваться командой onehost show.
В зависимости используемого драйвера хранилища и инфраструктуры, для описания хранилища используются определенные атрибуты. Эти атрибуты описаны в следующих разделах. Кроме того, существует набор общих атрибутов, которые можно использовать в любом хранилище. Эти атрибуты описаны в таблице ниже.

Таблица 31.1. Общие атрибуты хранилищ

Атрибут
Описание
Description
Описание
RESTRICTED_DIRS
Каталоги, которые нельзя использовать для размещения образов. Список каталогов, разделенный пробелами.
SAFE_DIRS
Разрешить использование каталога, указанного в разделе RESTRICTED_DIRS, для размещения образов. Список каталогов, разделенный пробелами.
NO_DECOMPRESS
Не пытаться распаковать файл, который нужно зарегистрировать.
LIMIT_TRANSFER_BW
Максимальная скорость передачи при загрузке образов с URL-адреса http/https (в байтах/секунду). Могут использоваться суффиксы K, M или G.
DATASTORE_CAPACITY_CHECK
Проверять доступную емкость хранилища данных перед созданием нового образа.
LIMIT_MB
Максимально допустимая емкость хранилища данных в МБ.
BRIDGE_LIST
Список мостов узла, разделенных пробелами, которые имеют доступ к хранилищу для добавления новых образов в хранилище.
STAGING_DIR
Путь на узле моста хранения для копирования образа перед его перемещением в конечный пункт назначения. По умолчанию /var/tmp.
DRIVER
Применение специального драйвера сопоставления изображений. Данный атрибут переопределяет DRIVER образа, установленный в атрибутах образа и шаблоне ВМ.
COMPATIBLE_SYS_DS
Только для хранилищ образов. Установить системные хранилища данных, которые можно использовать с данным хранилищем образов (например, «0,100»).
CONTEXT_DISK_TYPE
Указывает тип диска, используемый для контекстных устройств: BLOCK или FILE (по умолчанию).

Примечание

Для использования BRIDGE_LIST, следует установить любой инструмент, необходимый для доступа к базовому хранилищу, а также универсальные инструменты, такие как qemu-img.
Системные хранилища можно отключить, чтобы планировщик не мог развернуть в них новую ВМ. При этом существующие ВМ продолжат работать. Отключение хранилища:
$ onedatastore disable system
$ onedatastore show system
DATASTORE 0 INFORMATION
ID             : 0
NAME           : system
...
STATE          : DISABLED
...
Создавать, включать, отключать, удалять и просматривать информацию о хранилищах можно в веб-интерфейсе:
Работа с хранилищами в OpenNebula-Sunstone

31.3. Создание хранилищ

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

31.3.1. Локальное хранилище

Данная конфигурация использует локальную область хранения каждого узла для запуска ВМ. Кроме того, потребуется место для хранения образа диска ВМ. Образы дисков передаются с сервера управления на узлы по протоколу SSH.
На сервере управления в /var/lib/one/datastores/ должно быть достаточно места для:
  • хранилища образов;
  • системного хранилища (для временных дисков и файлов остановленных и неразвернутых ВМ).
На узле виртуализации в /var/lib/one/datastores/ должно быть достаточно места для хранения дисков ВМ, работающих на этом узле.
Необходимо зарегистрировать два хранилища (системное и хранилище образов).
Чтобы создать новое системное хранилище, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • TYPE — SYSTEM_DS;
  • TM_MAD — shared (для режима общей передачи), qcow2 (для режима передачи qcow2), ssh (для режима передачи ssh).
Зарегистрировать системное хранилище можно как веб-интерфейсе Sunstone:
Драйвер передачи ssh
Так и в командной строке. Например, для создания системного хранилища можно создать файл systemds.conf со следующим содержимым:
NAME    = local_system
TM_MAD  = ssh
TYPE    = SYSTEM_DS
И выполнить команду:
$ onedatastore create systemds.conf
ID: 101
Чтобы создать новое хранилище образов, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • DS_MAD — fs (драйвер хранилища данных);
  • TYPE — IMAGE_DS;
  • TM_MAD — shared (для режима общей передачи), qcow2 (для режима передачи qcow2), ssh (для режима передачи ssh).

Примечание

Необходимо использовать одинаковый метод передачи данных TM_MAD для системного хранилища и для хранилища образов.
Зарегистрировать хранилище образов можно как веб-интерфейсе Sunstone, так и в командной строке. Например, для создания хранилища образов можно создать файл imageds.conf со следующим содержимым:
NAME    = local_image
TM_MAD  = ssh
TYPE    = IMAGE_DS
DS_MAD  = fs
И выполнить команду:
$ onedatastore create imageds.conf
ID: 102

31.3.2. Хранилище NFS/NAS

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

Примечание

В /var/lib/one/datastores/ можно смонтировать каталог с любого сервера NAS/SAN в сети.
Необходимо зарегистрировать два хранилища (системное и хранилище образов).
Чтобы создать новое системное хранилище, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • TYPE — SYSTEM_DS;
  • TM_MAD — shared (для режима общей передачи), qcow2 (для режима передачи qcow2), ssh (для режима передачи ssh).
Зарегистрировать системное хранилище можно как веб-интерфейсе Sunstone, так и в командной строке. Например, для создания системного хранилища можно создать файл systemds.conf со следующим содержимым:
NAME    = nfs_system
TM_MAD  = shared
TYPE    = SYSTEM_DS
И выполнить команду:
$ onedatastore create systemds.conf
ID: 101
Чтобы создать новое хранилище образов, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • DS_MAD — fs (драйвер хранилища данных);
  • TYPE — IMAGE_DS;
  • TM_MAD — shared (для режима общей передачи), qcow2 (для режима передачи qcow2), ssh (для режима передачи ssh).

Примечание

Необходимо использовать одинаковый метод передачи данных TM_MAD для системного хранилища и для хранилища образов.
Зарегистрировать хранилище образов можно как веб-интерфейсе Sunstone, так и в командной строке. Например, для создания хранилища образов можно создать файл imageds.conf со следующим содержимым:
NAME    = nfs_images
TM_MAD  = shared
TYPE    = IMAGE_DS
DS_MAD  = fs
И выполнить команду:
$ onedatastore create imageds.conf
ID: 102
На узле управления (в /var/lib/one/datastores/) будут созданы два каталога: 101 и 102. На узлах виртуализации эти каталоги автоматически не создаются, поэтому на узлах виртализации требуется создать каталоги с соответствующими идентификаторами:
$ mkdir /var/lib/one/datastores/101
$ mkdir /var/lib/one/datastores/102
В каталог /var/lib/one/datastores/<идентификатор_хранилища> на узле управления и узлах виртуализации необходимо смонтировать удалённый каталог NFS. Например:
# mount -t nfs 192.168.0.157:/export/storage /var/lib/one/datastores/102
Для автоматического монтирования к NFS-серверу при загрузке необходимо добавить следующую строку в файл /etc/fstab:
192.168.0.157:/export/storage /var/lib/one/datastores/102   nfs   intr,soft,nolock,_netdev,x-systemd.automount    0 0

Примечание

Для возможности монтирования NFS-хранилища на всех узлах должен быть запущен nfs-client:
# systemctl enable --now nfs-client.target
Получить список совместных ресурсов с сервера NFS можно, выполнив команду:
# showmount -e 192.168.0.157

Важно

При использовании файловой технологии хранения, после добавления записи об автоматическом монтировании в файле /etc/fstab и перезагрузки ОС, необходимо назначить на каталог этого хранилища владельца oneadmin. Например:
# chown oneadmin: /var/lib/one/datastores/102

31.3.3. NFS/NAS и локальное хранилище

При использовании хранилища NFS/NAS можно повысить производительность ВМ, разместив диски в локальной файловой системе узла. Таким образом, хранилище образов будет размещено на сервере NFS, но ВМ будут работать с локальных дисков.
Чтобы настроить этот сценарий, следует настроить хранилище образов и системное хранилища, как описано выше (TM_MAD=shared). Затем добавить системное хранилище (TM_MAD=ssh). Любой образ, зарегистрированный в хранилище образов, можно будет развернуть с использованием любого из этих системных хранилищ.
Чтобы выбрать (альтернативный) режим развертывания, следует добавить в шаблон ВМ атрибут:
TM_MAD_SYSTEM="ssh"

31.3.4. Хранилище SAN

Эта конфигурация хранилища предполагает, что узлы имеют доступ к устройствам хранения (LUN), экспортированным сервером сети хранения данных (SAN) с использованием подходящего протокола, такого как iSCSI или Fibre Channel (FC).
Для организации хранилищ требуется выделение как минимум 2 LUN на системе хранения. Эти LUN должны быть презентованы каждому участнику кластера — узлам управления и узлам виртуализации.
Для хранения образов в виде файлов, используется хранилище файлового типа. Блочные устройства такого хранилища (созданные и презентованные выше LUN) должны быть отформатированы в кластерную файловую систему. Существует также возможность хранить образы исполняемых ВМ в виде томов LVM.
Хранилище SAN может получить доступ к файлам образов двумя способами:
  • режим NFS — файлы образов доступны непосредственно на узлах виртуализации через распределенную файловую систему, например NFS или OCFS2 (fs_lvm);
  • режим SSH — файлы образов передаются на узел по SSH (fs_lvm_ssh).
В любом режиме серверу управления необходимо иметь доступ к хранилищам образов путем монтирования соответствующего каталога в /var/lib/one/datastores/<идентификатор_хранилища>. В случае режима NFS каталог необходимо смонтировать с сервера NAS. В режиме SSH можно смонтировать любой носитель данных в каталог хранилища.
Сервер управления также должен иметь доступ к общему LVM либо напрямую, либо через узел виртуализации, указав его в атрибуте BRIDGE_LIST в шаблоне хранилища.

31.3.4.1. Создание хранилищ

Чтобы создать новое системное хранилище, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • TM_MAD — fs_lvm (для режима NFS), fs_lvm_ssh (для режима SSH);
  • TYPE — SYSTEM_DS;
  • BRIDGE_LIST — список узлов, имеющих доступ к логическим томам. НЕ требуется, если внешний интерфейс настроен на доступ к логическим томам.
Зарегистрировать системное хранилище можно как веб-интерфейсе Sunstone, так и в командной строке. Например, для создания системного хранилища можно создать файл systemds.conf со следующим содержимым:
NAME    = lvm-system
TM_MAD  = fs_lvm_ssh
TYPE    = SYSTEM_DS
BRIDGE_LIST = "host-01 host-02"
И выполнить команду:
$ onedatastore create systemds.conf
ID: 101
Чтобы создать новое хранилище образов, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • TM_MAD — fs_lvm (для режима NFS), fs_lvm_ssh (для режима SSH);
  • DS_MAD — fs;
  • TYPE — IMAGE_DS;
  • BRIDGE_LIST — список узлов, имеющих доступ к логическим томам. НЕ требуется, если внешний интерфейс настроен на доступ к логическим томам;
  • DISK_TYPE — BLOCK.
Зарегистрировать хранилище образов можно как веб-интерфейсе Sunstone, так и в командной строке. Например, для создания хранилища образов можно создать файл imageds.conf со следующим содержимым:
NAME    = lvm-images
TM_MAD  = fs_lvm_ssh
TYPE    = IMAGE_DS
DISK_TYPE = "BLOCK"
DS_MAD  = fs
И выполнить команду:
$ onedatastore create imageds.conf
ID: 102

Примечание

Необходимо использовать одинаковый метод передачи данных TM_MAD для системного хранилища и для хранилища образов.
На узле управления (в /var/lib/one/datastores/) будут созданы два каталога: 101 и 102. На узлах виртуализации эти каталоги автоматически не создаются, поэтому требуется создать каталоги с соответствующими идентификаторами:
$ mkdir /var/lib/one/datastores/101
$ mkdir /var/lib/one/datastores/102

31.3.4.2. Подключение СХД

31.3.4.2.1. Особенности подключения СХД по FC
Алгоритм подключения:
  1. Подготовить СХД (создать LUNы).
  2. На сервере установить FC HBA, драйверы к ним.
  3. Настроить сетевое подключение.
  4. Подключить СХД к серверу.
  5. Предоставить серверу доступ к СХД по WWPN.

Примечание

Для того чтобы узнать глобальные имена портов (WWPN), можно воспользоваться утилитой systool из пакета sysfsutils.
Пакет sysfsutils необходимо установить из репозитория:
# apt-get install sysfsutils
Чтобы найти WWPN, следует ввести следующую команду:
# systool -c fc_host -A port_name
Class = "fc_host"
Class Device = "host1"
port_name = "0x10000090fa59a61a"
Device = "host1"
Class Device = "host16"
port_name = "0x10000090fa59a61b"
Device = "host16"
Просмотреть список подключенных устройств можно, например, выполнив команду:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 59G 0 disk
sdb 8:16 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sdc 8:32 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sdd 8:48 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sde 8:64 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
В данном примере один LUN на 1000GB виден по четырем путям.
31.3.4.2.2. Особенности подключения СХД по ISCSI
Все необходимые соединения iSCSI должны запускаться во время загрузки узла. Сделать это можно, установив для параметра node.startup значение automatic. Значение по умолчанию для параметра node.session.timeo.replacement_timeout составляет 120 секунд. Рекомендуется использовать значение — 15 секунд.
Эти параметры можно указать в файле в /etc/iscsi/iscsid.conf (по умолчанию). Если iSCSI target уже подключен, то необходимо изменить настройки по умолчанию для конкретной цели в файле /etc/iscsi/nodes/<TARGET>/<PORTAL>/default.
На всех узлах PVE необходимо:
  1. Установить пакет open-iscsi, запустить и добавить в автозагрузку сервис iscsid:
    # apt-get install open-iscsi
    # systemctl enable --now iscsid
    
  2. Указать следующие параметры в файле /etc/iscsi/iscsid.conf:
    node.startup = automatic
    node.session.timeo.replacement_timeout = 15
    
  3. Присоединить iSCSI хранилище к кластеру:
    # iscsiadm -m discovery -t sendtargets -p <iscsi-target-1-ip>
    # iscsiadm -m discovery -t sendtargets -p <iscsi-target-2-ip>
    # iscsiadm -m node --login
    
  4. Настроить автоматическое подключение iSCSI-target-ов. Для этого необходимо поменять следующие параметры:
    • в файле /etc/iscsi/iscsid.conf:
      node.startup = automatic
    • в файлах /var/lib/iscsi/send_targets/<TargetServer>,<Port>/st_config:
      discovery.sendtargets.use_discoveryd = Yes
      
  5. После перезагрузки должны появиться подключенные устройства:
    # lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
    sda 8:0 0 59G 0 disk
    sdb 8:16 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sdc 8:32 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sdd 8:48 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sde 8:64 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    
    В данном примере один LUN на 1000GB виден по четырем путям.

Примечание

Примеры использования команды iscsiadm:
  • отключить хранилище (отключить все цели):
    # iscsiadm -m node --logout
    
  • отключить только определенную цель:
    # iscsiadm -m node --targetname "iscsi-target-1.test.alt:server.target1" --logout
    
  • переопросить устройства на ISCSI:
    # iscsiadm -m node -R
    
  • посмотреть все текущие подключения iSCSI:
    # iscsiadm -m session
    

31.3.4.3. Настройка Multipath

Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов СХД с использованием нескольких маршрутов. В случае отказа одного из контроллеров, ОС будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.
Multipath устройства объединяются в одно устройство с помощью специализированного ПО в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Кроме того Multipath позволяет увеличить пропускную способность за счет балансировки нагрузки.
На всех узлах должен быть установлен пакет для multipath:
# apt-get install multipath-tools
И запущена служба multipathd:
# systemctl enable --now multipathd && sleep 5; systemctl status multipathd
31.3.4.3.1. Конфигурация multipath

Примечание

Команда multipath используется для обнаружения и объединения нескольких путей к устройствам.
Некоторые параметры команды multipath:
  • -l — отобразить текущую multipath-топологию, полученную из sysfs и устройства сопоставления устройств;
  • -ll — отобразить текущую multipath-топологию, собранную из sysfs, устройства сопоставления устройств и всех других доступных компонентов системы;
  • -f device — удалить указанное multipath-устройство;
  • -F — удалить все неиспользуемые multipath-устройства;
  • -w device — удалить WWID указанного устройства из файла wwids;
  • -W — сбросить файл wwids, чтобы включить только текущие многопутевые устройства;
  • -r — принудительная перезагрузка multipath-устройства.
После подключения, устройство хранения данных должно автоматически определиться как multipath-устройство:
# multipath -ll
mpatha (3600c0ff00014f56ee9f3cf6301000000) dm-0 HP,P2000 G3 FC
size=931G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:1 sdb 8:16 active ready running
| `- 16:0:1:1 sde 8:64 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 1:0:1:1 sdc 8:32 active ready running
`- 16:0:0:1 sdd 8:48 active ready running
Вывод этой команды разделить на три части:
  • Информация о multipath-устройстве:
    • mpatha (3600c0ff00014f56ee9f3cf6301000000): алиас
    • dm-0: имя устройства dm
    • HP,P2000 G3 FC: поставщик, продукт
    • size=931G: размер
    • features='1 queue_if_no_path': функции
    • hwhandler='01 alua': аппаратный обработчик
    • wp=rw: права на запись
  • Информация о группе путей:
    • policy='service-time 0': политика планирования
    • prio=50: приоритет группы путей
    • status=active: статус группы путей
  • Информация о пути:
    • 7:0:1:1: хост:канал:идентификатор:Lun
    • sde: диск
    • 8:80: номера major:minor
    • active: статус dm
    • ready: статус пути
    • running: online статус
Для получения дополнительной информации об используемых устройствах можно выполнить команду:
# multipath -v3
Настройки multipath содержатся в файле /etc/multipath.conf:
defaults {
    find_multipaths         yes
    user_friendly_names     yes
}
Если для параметра user_friendly_names установлено значение no, то для имени multipath-устройства задается значение World Wide Identifier (WWID). Имя устройства будет /dev/mapper/WWID и /dev/dm-X:
# ls /dev/mapper/
3600c0ff00014f56ee9f3cf6301000000

# lsblk
NAME                                        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                           8:0    0    59G  0 disk
sdb                                           8:16   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sdc                                           8:32   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sdd                                           8:48   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sde                                           8:64   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
Если для параметра user_friendly_names установлено значение yes, то для имени multipath-устройства задаётся алиас (псевдоним), в форме mpathХ. Имя устройства будет /dev/mapper/mpathХ и /dev/dm-X:
# ls /dev/mapper/
mpatha

# lsblk
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                8:0    0    59G  0 disk
sdb                8:16   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sdc                8:32   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sdd                8:48   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sde                8:64   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
Однако не гарантируется, что имя устройства будет одинаковым на всех узлах, использующих это multipath-устройство.
ОС при загрузке определяет пути к устройствам в изменяющейся среде выполнения (например, при новой загрузке в среде выполнения ОС появились новые устройства хранения или исчезли старые, и т.п.) по отношению к предыдущей загрузке или по отношению к заданной ранее конфигурации. Это может приводить к противоречиям при именовании устройств. Для того чтобы избежать такого поведения, рекомендуется:
  • Сделать явное исключение для устройства (раздела) хранения (например, для 3600c0ff00014f56ee9f3cf6301000000, которое в настоящее время определяется как /dev/mapper/mpatha). Для этого в файл /etc/multipath.conf добавить секции:
    blacklist {
            wwid .*
    }
    
    blacklist_exceptions {
            wwid "3600c0ff00014f56ee9f3cf6301000000"
    }
    
    Данная настройка предписывается внести в черный список любые найденные устройства хранения данных, за исключением нужного.
  • Создать еще одну секцию:
    multipaths {
      multipath {
            wwid "3600c0ff00014f56ee9f3cf6301000000"
            alias mpatha
      }
    }
    
    В этом случае устройство всегда будет доступно только по имени /dev/mapper/mpatha. Вместо mpatha можно вписать любое желаемое имя устройства.

Примечание

Получить WWID конкретного устройства можно, выполнив команду:
# /lib/udev/scsi_id -g -u -d /dev/sdb
3600c0ff00014f56ee9f3cf6301000000
Для устройств в одном multipath WWID будут совпадать.
В файл /etc/multipath.conf может также потребоваться внести рекомендованные производителем СХД параметры.
После внесения изменений в файл /etc/multipath.conf необходимо перезапустить службу multipathd для активации настроек:
# systemctl restart multipathd.service

Примечание

Проверить файл /etc/multipath.conf на наличие ошибок можно, выполнив команду:
# multipath -t

31.3.4.4. Разметка хранилища образов

Устройство, на котором размещается хранилище образов должно быть отформатировано кластерной ФС.
Ниже показано создание кластерной ФС ocfs2 на multipath-устройстве и подключение этого устройства в OpenNebula.
31.3.4.4.1. Кластерная ФС ocfs2
На всех узлах кластера необходимо установить пакет ocfs2-tools:
# apt-get install ocfs2-tools

Примечание

Основной конфигурационный файл для OCFS2 — /etc/ocfs2/cluster.conf. Этот файл должен быть одинаков на всех узлах кластера, при изменении в одном месте его нужно скопировать на остальные узлы. При добавлении нового узла в кластер, описание этого узла должно добавлено быть на всех остальных узлах до монтирования раздела ocfs2 с нового узла.
Создание кластерной конфигурации возможно с помощью команд или с помощью редактирования файла конфигурации /etc/ocfs2/cluster.conf.
Пример создания кластера из трёх узлов:
  • В командной строке:
    • Создать кластер с именем mycluster:
      # o2cb_ctl -C -n mycluster -t cluster -a name=mycluster
      
    • Добавить узелы, выполнив команду для каждого:
      # o2cb_ctl -C -n <имя_узла> -t node -a number=0 -a ip_address=<IP_узла> -a ip_port=7777 -a cluster=mycluster
      
  • Редактирование конфигурационного файла /etc/ocfs2/cluster.conf:
    cluster:
    node_count = 3
    heartbeat_mode = local
    name = mycluster
    
    node:
    ip_port = 7777
    ip_address = <IP_узла-01>
    number = 0
    name = <имя_узла-01>
    cluster = mycluster
    
    node:
    ip_port = 7777
    ip_address = <IP_узла-02>
    number = 1
    name = <имя_узла-02>
    cluster = mycluster
    
    node:
    ip_port = 7777
    ip_address = <IP_узла-03>
    number = 2
    name = <имя_узла-03>
    cluster = mycluster
    

Примечание

Имя узла кластера должно быть таким, как оно указано в файле /etc/hostname.
Для включения автоматической загрузки сервиса OCFS2 можно использовать скрипт /etc/init.d/o2cb:
# /etc/init.d/o2cb configure
Для ручного запуска кластера нужно выполнить:
# /etc/init.d/o2cb load
checking debugfs...
Loading filesystem "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
# /etc/init.d/o2cb online mycluster
checking debugfs...
Setting cluster stack "o2cb": OK
Registering O2CB cluster "mycluster": OK
Setting O2CB cluster timeouts : OK
Далее на одном из узлов необходимо создать раздел OCFS2, для этого следует выполнить следующие действия:
  • создать физический раздел /dev/mapper/mpatha-part1 на диске /dev/mapper/mpatha:
    # fdisk /dev/mapper/mpatha
    
  • отформатировать созданный раздел, выполнив команду:
    # mkfs.ocfs2 -b 4096 -C 4k -L DBF1 -N 3 /dev/mapper/mpatha-part1
    mkfs.ocfs2 1.8.7
    Cluster stack: classic o2cb
    Label: DBF1
    …
    mkfs.ocfs2 successful
    

Таблица 31.2. Параметры команды mkfs.ocfs2

Параметр
Описание
-L метка_тома
Метка тома, позволяющая его однозначно идентифицировать при подключении на разных узлах. Для изменения метки тома можно использовать утилиту tunefs.ocfs2
-C размер_кластера
Размер кластера — это наименьшая единица пространства, выделенная файлу для хранения данных. Возможные значения: 4, 8, 16, 32, 64, 128, 256, 512 и 1024 КБ. Размер кластера невозможно изменить после форматирования тома
-N количество_узлов_кластера
Максимальное количество узлов, которые могут одновременно монтировать том. Для изменения количества узлов можно использовать утилиту tunefs.ocfs2
-b размер_блока
Наименьшая единица пространства, адресуемая ФС. Возможные значения: 512 байт (не рекомендуется), 1 КБ, 2 КБ или 4 КБ (рекомендуется для большинства томов). Размер блока невозможно изменить после форматирования тома

Примечание

Для создания нового раздела может потребоваться предварительно удалить существующие данные раздела на устройстве /dev/mpathX (следует использовать с осторожностью!):
# dd if=/dev/zero of=/dev/mapper/mpathX bs=512 count=1 conv=notrunc
31.3.4.4.2. OCFS2 в OpenNebula
На каждом узле OpenNebula необходимо добавить данную ФС OCFS2 к каталогам, которые будут автоматически монтироваться при загрузке узла:
  • определить UUID раздела:
    # blkid
    /dev/mapper/mpatha-part1: LABEL="DBF1" UUID="df49216a-a835-47c6-b7c1-6962e9b7dcb6" BLOCK_SIZE="4096" TYPE="ocfs2" PARTUUID="15f9cd13-01"
    
  • добавить монтирование этого UUID в /etc/fstab:
    UUID=<uuid> /var/lib/one/datastores/<идентификатор_хранилища> ocfs2 _netdev,defaults 0 0
    
    Например:
    UUID=df49216a-a835-47c6-b7c1-6962e9b7dcb6       /var/lib/one/datastores/102     ocfs2 _netdev,defaults 0 0
    
  • убедиться, что монтирование прошло без ошибок, выполнив команду:
    # mount -a
    
    Результатом выполнения команды должен быть пустой вывод без ошибок.
  • пример получившейся конфигурации:
    # lsblk
    NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
    sda                8:0    0    59G  0 disk
    `-sda1             8:1    0   255M  0 part  /boot/efi
    sdb                8:16   0 931.3G  0 disk
    `-mpatha         253:0    0 931.3G  0 mpath
      `-mpatha-part1 253:1    0 931.3G  0 part  /var/lib/one/datastores/102
    sdc                8:32   0 931.3G  0 disk
    |-sdc1             8:33   0 931.3G  0 part
    `-mpatha         253:0    0 931.3G  0 mpath
      `-mpatha-part1 253:1    0 931.3G  0 part  /var/lib/one/datastores/102
    sdd                8:48   0 931.3G  0 disk
    `-mpatha         253:0    0 931.3G  0 mpath
      `-mpatha-part1 253:1    0 931.3G  0 part  /var/lib/one/datastores/102
    sde                8:64   0 931.3G  0 disk
    `-mpatha         253:0    0 931.3G  0 mpath
      `-mpatha-part1 253:1    0 931.3G  0 part  /var/lib/one/datastores/102
    

Примечание

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

Важно

При использовании файловой технологии хранения, после добавления записи об автоматическом монтировании в файле /etc/fstab и перезагрузки ОС, необходимо назначить на каталог этого хранилища владельца oneadmin. Например:
# chown oneadmin: /var/lib/one/datastores/102

Примечание

Вывести все файловые системы OCFS2 на данном узле:
# mounted.ocfs2 -f
Device                    		Stack  Cluster  F  	Nodes
/dev/mapper/mpatha-part1  	o2cb               		server, host-02, host-01
# mounted.ocfs2 -d
Device                    Stack  Cluster  F  UUID                              Label
/dev/mapper/mpatha-part1  o2cb               DF49216AA83547C6B7C16962E9B7DCB6  DBF

31.3.4.5. Разметка системного хранилища

LUN для системного хранилища будет обслуживаться менеджером томов LVM.
Предварительные условия:
  • lvmetad должен быть отключен. Для этого следует установить параметр use_lvmetad = 0 в /etc/lvm/lvm.conf (в разделе global) и отключить службу lvm2-lvmetad.service, если она запущена.
  • Пользователь oneadmin должен входить в группу disk:
     # gpasswd -a oneadmin disk
    
  • Все узлы должны иметь доступ к одним и тем же LUN.
  • Для каждого хранилища необходимо создать LVM VG с именем vg-one-<идентификатор_хранилища> в общих LUN.

Примечание

LUN должен быть виден в системе по пути /dev/mapper/.
LUN должен быть не размечен. Его необходимо очистить от разметки и/или файловых систем на стороне СХД, или выполнить команду:
# wipefs -fa /dev/mapper/[LUN_WWID]
На узле управления необходимо:
  • Создать физический том (PV) на LUN, например:
    # pvcreate /dev/mapper/mpathb
    Physical volume "/dev/mapper/mpathb" successfully created.
    
  • Создать группу томов с именем vg-one-<идентификатор_хранилища>, например:
    # vgcreate vg-one-101 /dev/mapper/mpathb
    Volume group "vg-one-101" successfully created
    
  • Вывести информацию о физических томах:
    # pvs
    PV                       VG         Fmt  Attr PSize   PFree
    /dev/mapper/mpathb       vg-one-101 lvm2 a--  931.32g 931.32g
    
Созданные хранилища будут отображаться в веб-интерфейсе OpenNebula. Индикация объёма хранилища должна соответствать выделенному на СХД для каждого LUN.
SAN хранилища
После создания и запуска ВМ будет создан логический раздел:
# lvscan
  ACTIVE            '/dev/vg-one-101/lv-one-52-0' [50,00 GiB] inherit
# lsblk
sde                               8:64   0   931.3G  0 disk
└─mpathb                        253:1    0   931.3G  0 mpath
  └─vg--one--101-lv--one--52--0 253:3    0   51G     0 lvm
где 52 — идентификатор ВМ.

31.3.5. Хранилище файлов и ядер

Хранилище файлов и ядер позволяет хранить простые файлы, которые будут использоваться в качестве ядер ВМ, виртуальных дисков или любых других файлов, которые необходимо передать ВМ в процессе контекстуализации. Данное хранилище не предоставляет никакого специального механизма хранения, но представляет простой и безопасный способ использования файлов в шаблонах ВМ.
Чтобы создать новое хранилище файлов и ядер, необходимо указать следующие параметры:
  • NAME — название хранилища;
  • TYPE — FILE_DS;
  • DS_MAD — fs;
  • TM_MAD — ssh.
Зарегистрировать хранилище файлов и ядер можно как веб-интерфейсе Sunstone, так и в командной строке. Например, для создания хранилища файлов и ядер можно создать файл fileds.conf со следующим содержимым:
NAME    = local_file
DS_MAD  = fs
TM_MAD  = ssh
TYPE    = FILE_DS
И выполнить команду:
$ onedatastore create fileds.conf
ID: 105

Примечание

Выше приведены рекомендованные значения DS_MAD и TM_MAD, но можно использовать любые другие.
Для того чтобы изменить параметры хранилища, можно создать файл с необходимыми настройками (пример см.выше) и выполнить команду:
$ onedatastore update <идентификатор_хранилища> <имя_файла>

Глава 32. Работа с образами в OpenNebula

Система хранилищ позволяет пользователям настраивать/устанавливать образы, которые могут быть образами ОС или данных, для использования в ВМ. Данные образы могут использоваться несколькими ВМ одновременно, а также предоставляться другим пользователями.
Типы образов для дисков ВМ (хранятся в хранилище образов):
  • OS — образ загрузочного диска;
  • CDROM — файл образа, содержащий CDROM. Эти образы предназначены только для чтения. В каждом шаблоне ВМ, можно использовать только один образ данного типа;
  • DATABLOCK — файл образа, содержащий блок данных (например, базу данных) или может быть отформатирован как пустой диск.
Типы файлов (хранятся в файловом хранилище):
  • KERNEL — файл, который будет использоваться в качестве ядра ВМ (kernels);
  • RAMDISK — файл для использования в качестве виртуального диска;
  • CONTEXT — файл для включения в контекстный CD-ROM.
Образы могут работать в двух режимах:
  • persistent (постоянные) — изменения, внесенные в такие образы, будут сохранены после завершения работы ВМ. В любой момент времени может быть только одна ВМ, использующая постоянный образ.
  • non-persistent (непостоянный) — изменения не сохранятся после завершения работы ВМ. Непостоянные образы могут использоваться несколькими ВМ одновременно, поскольку каждая из них будет работать со своей собственной копией.
Управлять образами можно, используя интерфейс командной строки — команда oneimage.
Управлять образами можно также в веб-интерфейсе на вкладке Образы.
OpenNebula-Sunstone. Вкладка Образы

32.1. Создание образа ОС в среде OpenNebula

Для создания образа ОС, необходимо подготовить ВМ и извлечь её диск.

32.1.1. Создание образов дисков

Создать образ типа CDROM с установочным ISO-образом.
Для этого перейти в раздел ХранилищеОбразы, на загруженной странице нажать +Создать:
Создание образа
В открывшемся окне заполнить поле Название, выбрать тип образа CD-ROM только для чтения, выбрать хранилище, выбрать расположение образа Путь/URL, указать путь к файлу (.iso) и нажать кнопку Создать:
Создание образа типа CD-ROM

Примечание

Если указывается путь на сервере OpenNebula, то ISO-образ должен быть загружен в каталог, к которому имеет доступ пользователь oneadmin.
Создать пустой образ диска, на который будет установлена операционная система.
Для этого создать новый образ. Заполнить поле Название, в выпадающем списке Тип выбрать значение Generic storage datablock, в выпадающем списке Этот образ является постоянным выбрать значение Да, выбрать хранилище, в разделе Расположение образа выбрать пункт Пустой образ диска, установить размер выбранного блока, например, 45ГБ, в разделе Расширенные настройки указать формат qcow2 и нажать кнопку Создать:
Создание образа типа datablock

Примечание

Эти же действия можно выполнить в командной строке.
Создать образ типа CDROM в хранилище данных по умолчанию (ID = 1):
$ oneimage create -d 1 --name "ALT Workstation ISO" \
    --path /var/tmp/alt-workstation-10.0-x86_64.iso --type CDROM
ID: 31
Создать пустой образ диска (тип образа — DATABLOCK, размер 45 ГБ, драйвер qcow2):
$ oneimage create -d 1 --name "ALT Workstation" \
    --type DATABLOCK --size 45G --persistent --driver qcow2
ID: 33

32.1.2. Создание шаблона ВМ

Примечание

Создание шаблона в командной строке:
  1. Создать файл template со следующим содержимым:
    NAME = "ALT Workstation"
    CONTEXT = [
      NETWORK = "YES",
      SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]" ]
    CPU = "1"
    DISK = [
      IMAGE = "ALT Workstation ISO",
      IMAGE_UNAME = "oneadmin" ]
    DISK = [
      DEV_PREFIX = "vd",
      IMAGE = "ALT Workstation",
      IMAGE_UNAME = "oneadmin" ]
    GRAPHICS = [
      LISTEN = "0.0.0.0",
      TYPE = "SPICE" ]
    HYPERVISOR = "kvm"
    INPUTS_ORDER = ""
    LOGO = "images/logos/alt.png"
    MEMORY = "1024"
    MEMORY_UNIT_COST = "MB"
    NIC = [
      NETWORK = "VirtNetwork",
      NETWORK_UNAME = "oneadmin",
      SECURITY_GROUPS = "0" ]
    NIC_DEFAULT = [
      MODEL = "virtio" ]
    OS = [
      BOOT = "disk1,disk0" ]
    SCHED_REQUIREMENTS = "ID=\"0\""
    
  2. Создать шаблон:
    $ onetemplate create template
    ID: 22
    
Ниже рассмотрен пример создания шаблона в веб-интерфейсе.
В левом меню выбрать ШаблоныВМ, на загруженной странице нажать кнопку + и выбрать пункт Создать:
Создание шаблона ВМ. Вкладка Общие
На вкладке Общие необходимо указать параметры процессора, оперативной памяти, а также гипервизор:
Создание шаблона ВМ. Вкладка Общие
На вкладке Хранилище необходимо указать ранее созданный диск с установщиком ОС. Далее следует добавить новый диск и указать ранее созданный пустой диск (DATABLOCK), в разделе Расширенные настройки в выпадающем списке Шина выбрать Virtio.
Создание шаблона ВМ. Вкладка Хранилище
На вкладке Сеть в поле Default hardware model to emulate for all NICs указать Virtio и если необходимо выбрать сеть:
Создание шаблона ВМ. Вкладка Сеть
На вкладке ОС и ЦПУ необходимо указать архитектуру устанавливаемой системы и выбрать порядок загрузки. Можно установить в качестве первого загрузочного устройства — пустой диск (DATABLOCK), а в качестве второго — CDROM (при такой последовательности загрузочных устройств при пустом диске загрузка произойдёт с CDROM, а в дальнейшем, когда ОС будет уже установлена на диск, загрузка будет осуществляться с него).
Создание шаблона ВМ. Вкладка ОС и ЦПУ
На вкладке Ввод/Вывод следует включить SPICE:
Создание шаблона ВМ. Вкладка Ввод/Вывод
На вкладке Контекст необходимо включить параметр Использовать сетевое задание контекста, а также авторизацию по RSA-ключам (укажите свой открытый SSH (.pub) для доступа к ВМ по ключу, если оставить поле пустым, будет использована переменная $USER[SSH_PUBLIC_KEY]):
Создание шаблона ВМ. Вкладка Контекст
На вкладке Расписание если необходимо можно выбрать кластер/узел, на котором будет размещаться виртуальное окружение:
Создание шаблона ВМ. Вкладка Расписание
Для создания шаблона ВМ нажать кнопку Создать.

32.1.3. Создание ВМ

Для инициализации создания ВМ из шаблона в левом меню следует выбрать пункт ШаблоныВМ, выбрать шаблон и нажать кнопку Создать ВМ:
Создание экземпляра ВМ из шаблона
В открывшемся окне необходимо указать имя ВМ и нажать кнопку Создать ВМ:
Создание экземпляра ВМ из шаблона

Примечание

Создание экземпляра ВМ из шаблона в командной строке:
$ onetemplate instantiate 9
VM ID: 5

32.1.4. Подключение к ВМ и установка ОС

Примечание

Процесс создания ВМ может занять несколько минут. Следует дождаться статуса — «ЗАПУЩЕНО» («RUNNING»).
Подключиться к ВМ можно как из веб-интерфейса Sunstone, раздел Экземпляры ВМВМ выбрать ВМ и подключиться по SPICE:
Подключение к ВМ
Так и используя любой клиент SPICE:
spice://192.168.0.180:5905
где 192.168.0.180 — IP-адрес узла с ВМ, а 5 — идентификатор ВМ (номер порта 5900 + 5).
Далее необходимо провести установку системы:
Установка ОС

32.1.5. Настройка контекстуализации

OpenNebula использует метод, называемый контекстуализацией, для отправки информации на ВМ во время загрузки. Контекстуализация позволяет установить или переопределить данные ВМ, имеющие неизвестные значения или значения по умолчанию (имя узла, IP-адрес, .ssh/authorized_keys).
Пример настройки контекстуализации на установленной ОС Альт:
  1. Подключиться к ВМ через SPICE или по ssh.
  2. Установить пакет opennebula-context:
    # apt-get update && apt-get install opennebula-context
    
  3. Переключиться на systemd-networkd:
    • установить пакет systemd-timesyncd:
      # apt-get install systemd-timesyncd
      
    • создать файл автонастройки всех сетевых интерфейсов по DHCP /etc/systemd/network/lan.network со следующим содержимым:
      [Match]
      Name = *
      
      [Network]
      DHCP = ipv4
      
    • переключиться с etcnet/NetworkManager на systemd-networkd:
      # systemctl disable network NetworkManager && systemctl enable systemd-networkd systemd-timesyncd
      
  4. Перезагрузить систему.
После перезагрузки доступ в систему будет возможен по ssh-ключу, ВМ будет назначен IP-адрес, который OpenNebula через механизм IPAM (подсистема IP Address Management) выделит из пула адресов.

32.1.6. Создание образа типа ОС

После завершения установки и настройки системы следует выключить и удалить ВМ. Диск находится в состоянии Persistent, поэтому все внесенные изменения будут постоянными.
Для удаления ВМ в левом меню следует выбрать пункт Экземпляры ВМВМ, выбрать ВМ и нажать кнопку Уничтожить:
Удаление ВМ

Примечание

Удаление ВМ в командной строке:
$ onevm terminate 5
Затем перейти в ХранилищеОбразы ВМ, выбрать образ с установленной ОС (ALT Workstation) и изменить тип блочного устройства с Блок данных на ОС и состояние на Non Persistent:
Изменение типа блочного устройства

Примечание

Изменить тип блочного устройства на ОС и состояние на Non Persistent:
$ oneimage chtype 1 OS
$ oneimage nonpersistent 1
Образ готов. Далее можно использовать как имеющийся шаблон, так и создать новый на основе образа диска «ALT Workstation».

32.2. Использование магазинов приложений OpenNebula

Магазины приложений OpenNebula предоставляют простой способ интеграции облака с популярными поставщиками приложений и изображений.
Список доступных магазинов можно увидеть, выбрав в меню ХранилищеМагазины приложений:
Магазины приложений OpenNebula
Список магазинов приложений, настроенных в OpenNebula, можно вывести, выполнив команду:
$ onemarket list
  ID NAME                               SIZE AVAIL        APPS MAD     ZONE STAT
   3 DockerHub                            0M -             175 dockerh    0 on
   2 TurnKey Linux Containers             0M -               0 turnkey    0 on
   1 Linux Containers                     0M -               0 linuxco    0 on
   0 OpenNebula Public                    0M -              54 one        0 on

32.2.1. OpenNebula Public

OpenNebula Public — это каталог виртуальных устройств, готовых к работе в среде OpenNebula.
Для загрузки приложения из магазина OpenNebula Public необходимо выбрать OpenNebula PublicПриложения в списке магазинов. Появится список доступных приложений:
Магазин приложений OpenNebula Public
Каждое приложение содержит образ и шаблон.
Чтобы импортировать приложение, необходимо его выбрать и нажать кнопку Импорт в хранилище:
Информация о приложении в магазине приложений OpenNebula Public
В открывшемся окне указать имя для образа и шаблона, выбрать хранилище и нажать кнопку Загрузить:
Импорт приложения из магазина приложений OpenNebula
Настройка образов, загруженных из магазина приложений:
  1. Изменить состояние образа на Постоянный (необходимо дождаться состояния ГОТОВО).
  2. Настроить шаблон.
  3. Создать на основе шаблона ВМ.
  4. Подключиться к ВМ. Установить/настроить необходимые компоненты.
  5. Удалить ВМ.
  6. Изменить состояние образа на Не постоянный.
  7. Далее можно создать новые шаблоны на основе этого образа или использовать существующий.

32.2.2. Скачивание шаблона контейнера из магазина DockerHub

Магазин DockerHub предоставляет доступ к официальным образам DockerHub. Контекст OpenNebula устанавливается в процессе импорта образа, поэтому после импорта образ полностью готов к использованию.

Примечание

Для возможности загрузки контейнеров из магазина приложений DockerHub на сервере управления необходимо:
  • Установить Docker:
    # apt-get install docker-engine
    
  • Добавить пользователя oneadmin в группу docker:
    # gpasswd -a oneadmin docker
    
    и выполнить повторный вход в систему
  • Запустить и добавить в автозагрузку службу docker:
    # systemctl enable --now docker
    
  • Перезапустить opennebula:
    # systemctl restart opennebula
    
Для загрузки контейнера из магазина DockerHub необходимо перейти в ХранилищеМагазины приложений, выбрать DockerHubПриложения:
Магазин приложений DockerHub
Чтобы импортировать контейнер, необходимо его выбрать и нажать кнопку Импорт в хранилище:
Информация о контейнере в магазине приложений DockerHub
Каждый контейнер содержит образ и шаблон.
В открывшемся окне указать название для образа и шаблона, выбрать хранилище и нажать кнопку Загрузить:
Импорт контейнера из магазина приложений DockerHub
Из полученного шаблона можно разворачивать контейнеры (ВМ в терминологии Opennebula). Процесс разворачивания контейнера из шаблона такой же, как и процесс разворачивания ВМ из шаблона:
Разворачивание контейнера из шаблона
В Магазине приложений DockerHub перечислены только официальные образы. Для того чтобы использовать неофициальный образ, следует создать образ (oneimage create), используя в качестве PATH (или опции --path) URL-адрес следующего формата:
docker://<image>?size=<image_size>&filesystem=<fs_type>&format=raw&tag=<tag>&distro=<distro>
где:
  • <image> — имя образа DockerHub;
  • <image_size> — размер результирующего образа в МБ (этот размер должен быть больше фактического размера образа);
  • <fs_type> — тип файловой системы (ext4, ext3, ext2 или xfs);
  • <tag> — тег образа (по умолчанию latest);
  • <distro> — дистрибутив образа (опционально).

Примечание

OpenNebula автоматически определяет дистрибутив образа, запуская контейнер и проверяя файл /etc/os-release. Если эта информация недоступна внутри контейнера, необходимо использовать аргумент distro.
Например, чтобы создать новый образ alt-p10 на основе образа alt из DockerHub размером 3 ГБ с использованием ext4 и тега p10, можно выполнить команду:
$ oneimage create --name alt-p10 --path 'docker://alt?size=3072&filesystem=ext4&format=raw&tag=p10' --datastore 1
   ID: 22

Примечание

Этот формат URL-адреса также можно использовать в диалоговом окне создания образа в веб-интерфейсе:
Новый образ из DockerHub

Глава 33. Управление пользователями

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

33.1. Пользователи

Пользователь в OpenNebula определяется именем пользователя и паролем. Каждый пользователь имеет уникальный идентификатор и принадлежит как минимум к одной группе.
При установке OpenNebula создаются две административные учетные записи (oneadmin и serveradmin).
oneuser — инструмент командной строки для управления пользователями в OpenNebula.
Посмотр списка пользователей:
$ oneuser list
  ID NAME                 ENAB GROUP    AUTH            VMS     MEMORY        CPU
   1 serveradmin          yes  oneadmin server_c    0 /   -      0M /   0.0 /   -
   0 oneadmin             yes  oneadmin core              -          -          -
Создание нового пользователя:
$ oneuser create <user_name> <password>
По умолчанию новый пользователь будет входить в группу users. Изменить группу пользователя:
$ oneuser chgrp <user_name> oneadmin
Что бы удалить пользователя из группы, необходимо переместить его обратно в группу users.
Временно отключить пользователя:
$ oneuser disable <user_name>
Включить отключённого пользователя:
$ oneuser enable <user_name>
Удалить пользователя:
$ oneuser delete <user_name>
Все операции с пользователями можно производить в веб-интерфейсе:
Управление пользователями в OpenNebula-Sunstone
Созданный пользователь может аутентифицироваться в веб-интерфейсе OpenNebula и изменить настройки (изменить язык интерфейса, пароль, добавить ssh-ключ для доступа на ВМ и т.д.):
Панель пользователя в OpenNebula-Sunstone

Примечание

Пользователи могут просматривать информацию о своей учётной записи и изменять свой пароль.

33.2. Группы пользователей

При установке OpenNebula создаются две группы (oneadmin и users).
onegroup — инструмент командной строки для управления группами в OpenNebula.
Просмотр списка групп:
$ onegroup list
  ID NAME                 USERS       VMS            MEMORY         CPU
   1 users                    1   0 /   -      0M /       -  0.0 /    -
   0 oneadmin                 3         -                 -           -
Создание новой группы:
$ onegroup create group_name
ID: 100
Новая группа получила идентификатор 100, чтобы отличать специальные группы от созданных пользователем.
После создания группы может быть создан связанный пользователь-администратор. По умолчанию этот пользователь сможет создавать пользователей в новой группе.
Пример создания новой группы с указанием, какие ресурсы могут быть созданы пользователями группы (по умолчанию VM+IMAGE+TEMPLATE):
$ onegroup create --name testgroup \
--admin_user testgroup-admin --admin_password somestr \
--resources TEMPLATE+VM
При выполнении данной команды также будет создан администратор группы.
Сделать существующего пользователя администратором группы:
$ onegroup addadmin <groupid_list> <userid>
Все операции с группами можно производить в веб-интерфейсе:
Создание группы в OpenNebula-Sunstone

33.3. Управление разрешениями

У ресурсов OpenNebula (шаблонов, ВМ, образов и виртуальных сетей) есть права назначенные владельцу, группе и всем остальным. Для каждой из этих групп можно установить три права: Использование (use), Управление (manage) и Администрирование (admin).
Просмотреть/изменить права доступа можно в веб-интерфейсе, выбрав соответсвующий ресурс:
Управление разрешениями в OpenNebula-Sunstone
Просмотреть права можно и в командной строке:
$ onevm show 8
VIRTUAL MACHINE 8 INFORMATION
ID                  : 8
NAME                : test
USER                : oneadmin
GROUP               : oneadmin
STATE               : POWEROFF
LCM_STATE           : LCM_INIT
LOCK                : None
RESCHED             : No
HOST                : host-01
CLUSTER ID          : 0
CLUSTER             : default
START TIME          : 04/08 16:12:53
END TIME            : -
DEPLOY ID           : 69ab21c2-22ad-4afb-bfc1-7b4e4ff2364f

VIRTUAL MACHINE MONITORING
ID                  : 8
TIMESTAMP           : 1712756284

PERMISSIONS
OWNER          : um-
GROUP          : ---
OTHER          : ---
…
В данном примере показаны права на ВМ с ID=8.
Для изменения прав в командной строке используется команда chmod. Права записываются в числовом формате. Пример изменения прав:
$ onevm chmod 8 607
$ onevm show 8
…
PERMISSIONS
OWNER          : um-
GROUP          : ---
OTHER          : uma

Примечание

Разрешения по умолчанию для создаваемых ресурсов могут быть установлены:
  • глобально в oned.conf (атрибут DEFAULT_UMASK);
  • индивидуально для каждого пользователя с помощью команды oneuser umask.
Маска должна состоять из 3 восьмеричных цифр. Каждая цифра — это маска, которая, соответственно, отключает разрешение для владельца, группы и всех остальных. Например, если значение маски равно 137, то для нового объекта будут установлены права 640 (um- u-- ---).

33.4. Управление правилами ACL

Система правил ACL позволяет точно настроить разрешенные операции для любого пользователя или группы пользователей. Каждая операция генерирует запрос на авторизацию, который проверяется на соответствие зарегистрированному набору правил ACL. Затем ядро ​​может дать разрешение или отклонить запрос.
Просмотреть список правил можно, выполнив команду:
$ oneacl list
  ID     USER RES_VHNIUTGDCOZSvRMAPt   RID OPE_UMAC  ZONE
   0       @1     V--I-T---O-S----P-     *     ---c     *
   1        *     ----------Z-------     *     u---     *
   2        *     --------------MA--     *     u---     *
   3       @1     -H----------------     *     -m--    #0
   4       @1     --N---------------     *     u---    #0
   5       @1     -------D----------     *     u---    #0
   6       #3     ---I--------------   #30     u---    #0
Данные правила соответсвуют следующим:
@1      VM+IMAGE+TEMPLATE+DOCUMENT+SECGROUP/*   CREATE  *
*       ZONE/*                                  USE     *
*       MARKETPLACE+MARKETPLACEAPP/*            USE     *
@1      HOST/*                                  MANAGE  #0
@1      NET/*                                   USE     #0
@1      DATASTORE/*                             USE     #0
#3      IMAGE/#30                                    USE     *
Первые шесть правил были созданы при начальной загрузке OpenNebula, а последнее — с помощью oneacl:
$ oneacl create "#3 IMAGE/#30 USE"
ID: 6
Столбцы в выводе oneacl list:
  • ID — идентификатор правила;
  • USER — пользователь. В этом поле может быть указан идентификатор пользователя (#), идентификатор группы (@) или все пользователи (*);
  • Resources — тип ресурса, к которому применяется правило:
    • V — ВМ;
    • H — узел;
    • N — виртуальная сеть;
    • I — образ;
    • U — пользователь;
    • T — шаблон;
    • G — группа;
    • D — хранилище;
    • C — кластер;
    • O — документ;
    • Z — зона;
    • S — группа безопасности;
    • v — виртуальный дата центр (VDC);
    • R — виртуальный маршрутизатор;
    • M — магазин приложений;
    • A — приложение из магазина приложений;
    • P — группа ВМ;
    • t — шаблон виртуальной сети;
  • RID — идентификатор ресурса. В этом поле может быть указан идентификатор отдельного объекта (#), группы (@) или кластера (%), или все объекты (*);
  • Operations — разрешённые операции:
    • U — использовать;
    • M — управлять;
    • A — администрировать;
    • C — создавать;
  • Zone — зоны, в которых применяется правило. В этом поле может быть указан идентификатор отдельной зоны (#), или всех зон (*).
Для удаления правила используется команда:
$ oneacl delete <ID>
Управлять правилами ACL удобно в веб-интерфейсе:
Управление правилами ACL в OpenNebula-Sunstone
Для создания нового правила ACL, следует нажать кнопку Создать. В открывшемся диалоговом окне можно определить ресурсы, на которые распространяется правило, и разрешения, которые им предоставляются:
Управление правилами ACL в OpenNebula-Sunstone

Примечание

Каждое правило ACL добавляет новые разрешения и не может ограничивать существующие: если какое-либо правило даёт разрешение, операция разрешается.

33.5. Аутентификация пользователей

По умолчанию OpenNebula работает с внутренней системой аутентификации (пользователь/пароль). Но можно включить внешний драйвер аутентификации.

33.5.1. LDAP аутентификация

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

Важно

На сервере LDAP должна быть настроена отдельная учётная запись с правами чтения LDAP. От данной учетной записи будет выполняться подключение к серверу каталогов.
Для включения LDAP аутентификации необходимо в файл /etc/one/oned.conf добавить строку DEFAULT_AUTH = "ldap":
…
AUTH_MAD = [
    EXECUTABLE = "one_auth_mad",
    AUTHN = "ssh,x509,ldap,server_cipher,server_x509"
]

DEFAULT_AUTH = "ldap"
…

Важно

В файле /etc/one/sunstone-server.conf для параметра :auth должно быть указано значение opennebula:
:auth: opennebula
Ниже приведён пример настройки аутентификации в Active Directory (домен test.alt).
Для подключения к Active Directory в файле /etc/one/auth/ldap_auth.conf необходимо указать:
  • :user — пользователь AD с правами на чтение (пользователь указывается в формате opennebula@test.alt);
  • :password — пароль пользователя;
  • :host — IP-адрес или имя сервера AD (имя должно разрешаться через DNS или /etc/hosts);
  • :base — базовый DN для поиска пользователя;
  • :user_field — для этого параметра следует установить значение sAMAccountName;
  • :rfc2307bis — для этого параметра следует установить значение true.
Пример файла /etc/one/auth/ldap_auth.conf:
 server 1:
    :user: 'opennebula@test.alt'
    :password: 'Pa$$word'
    :auth_method: :simple
    :host: dc1.test.alt
    :port: 389
    :base: 'dc=test,dc=alt'
    :user_field: 'sAMAccountName'
    :mapping_generate: false
    :mapping_timeout: 300
    :mapping_filename: server1.yaml
    :mapping_key: GROUP_DN
    :mapping_default: 100
    :rfc2307bis: true
:order:
    - server 1

Примечание

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

Примечание

Пример файла /etc/one/auth/ldap_auth.conf для настройки аутентификации в домене FreeIPA (домен example.test):
 server 1:
    :user: 'uid=admin,cn=users,cn=accounts,dc=example,dc=test'
    :password: '12345678'
    :auth_method: :simple
    :host: ipa.example.test
    :port: 389
    :base: 'dc=example,dc=test'
    :user_field: 'uid'
    :mapping_generate: false
    :mapping_timeout: 300
    :mapping_filename: server1.yaml
    :mapping_key: GROUP_DN
    :mapping_default: 100
    :rfc2307bis: true
:order:
    - server 1
После того как пользователь AD авторизуется в веб-интерфейсе OpenNebula, у администратора появится возможность изменять его настройки:
Пользователи AD
Новых пользователей можно автоматически включать в определенную группу/группы. Для этого создается сопоставление группы AD с существующей группой OpenNebula. Эта система использует файл сопоставления, указанный в параметре :mapping_file (файл должен находиться в каталоге /var/lib/one/).
Файл сопоставления может быть сгенерирован автоматически с использованием данных в шаблоне группы, который определяет, какая группа AD сопоставляется с этой конкретной группой (для параметра :mapping_generate должно быть установлено значение true). Если в шаблон группы добавить строку:
GROUP_DN="CN=office,CN=Users,DC=test,DC=alt"
Шаблон группы
И в файле /etc/one/auth/ldap_auth.conf для параметра :mapping_key установить значение GROUP_DN, то поиск DN сопоставляемой группы будет осуществляться в этом параметре шаблона. В этом случае файл /var/lib/one/server1.yaml будет сгенерирован со следующим содержимым:
---
CN=office,CN=Users,DC=test,DC=alt: '100'
и пользователи из группы AD office, будут сопоставлены с группой ALT (ID=100).
Можно отключить автоматическую генерацию файла сопоставления, установив значение :mapping_generate равным false, и выполнить сопоставление вручную. Файл сопоставления имеет формат YAML и содержит хеш, где ключ — это DN группы AD, а значение — идентификатор группы OpenNebula. Например, если содержимое файла /var/lib/one/server1.yaml:
CN=office,CN=Users,DC=test,DC=alt: '100'
CN=Domain Admins,CN=Users,DC=test,DC=alt: '101'
то пользователи из группы AD office, будут сопоставлены с группой ALT (ID=100), а из группы AD Domain Admin — с группой Admin (ID=101):
Сопоставление групп AD с группами OpenNebula

Глава 34. Настройка отказоустойчивого кластера

В данном разделе рассмотрена настройка отказоустойчивого кластера (High Available, HA) для основных служб OpenNebula: core (oned), scheduler (mm_sched).
OpenNebula использует распределенный консенсусный протокол Raft, для обеспечения отказоустойчивости и согласованности состояний между службами. Алгоритм консенсуса построен на основе двух концепций:
  • состояние системы — данные, хранящиеся в таблицах базы данных (пользователи, списки управления доступом или виртуальные машины в системе);
  • журнал (log) — последовательность операторов SQL, которые последовательно применяются к базе данных OpenNebula на всех серверах для изменения состояния системы.
Чтобы сохранить согласованное представление о системе на всех серверах, изменения состояния системы выполняются через специальный узел, лидер или ведущий (Leader). Leader периодически посылает запросы (heartbeats) другим серверам, ведомым (Follower), чтобы сохранить свое лидерство. Если Leader не может послать запрос, Follower-серверы продвигаются к кандидатам и начинают новые выборы.
Каждый раз, когда система изменяется (например, в систему добавляется новая ВМ), Leader обновляет журнал и реплицирует запись у большинства Follower, прежде чем записывать её в базу данных. Таким образом, увеличивается задержка операций с БД, но состояние системы безопасно реплицируется, и кластер может продолжить свою работу в случае отказа узла.
Для настройки High Available требуется:
  • нечетное количество серверов (рекомендуемый размер развертывания — 3 или 5 серверов, что обеспечивает отказоустойчивость при отказе 1 или 2 серверов соответственно);
  • рекомендуется идентичная конфигурация серверов;
  • идентичная программная конфигурация серверов (единственное отличие — это поле SERVER_ID в /etc/one/oned.conf);
  • рекомендуется использовать подключение к базе данных одного типа (MySQL);
  • серверы должны иметь беспарольный доступ для связи друг с другом;
  • плавающий IP, который будет назначен лидеру;
  • общая файловая система.
Добавлять дополнительные серверы или удалять старые можно после запуска кластера.
В данном примере показана настройка HA кластера из трех серверов:
  • 192.168.0.186 opennebula
  • 192.168.0.187 server02
  • 192.168.0.188 server03
  • 192.168.0.200 Floating IP

34.1. Первоначальная конфигурация Leader

Запустить сервис OpenNebula и добавить локальный сервер в существующую или новую зону (в примере зона с ID 0):
$ onezone list
C   ID NAME             ENDPOINT                                      FED_INDEX
*    0 OpenNebula       http://localhost:2633/RPC2                    -1

$ onezone server-add 0 --name opennebula --rpc http://192.168.0.186:2633/RPC2

$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      solo       0          -1         0          -1    -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Остановить сервис opennebula и обновить конфигурацию SERVER_ID в файле /etc/one/oned.conf:
FEDERATION = [
    MODE          = "STANDALONE",
    ZONE_ID       = 0,
    SERVER_ID     = 0, # изменить с -1 на 0 (0 — это ID сервера)
    MASTER_ONED   = ""
]
Включить Raft-обработчики, чтобы добавить плавающий IP-адрес в кластер (файл /etc/one/oned.conf):
RAFT_LEADER_HOOK = [
    COMMAND = "raft/vip.sh",
    ARGUMENTS = "leader enp0s3 192.168.0.200/24"
]

# Executed when a server transits from leader->follower
RAFT_FOLLOWER_HOOK = [
    COMMAND = "raft/vip.sh",
    ARGUMENTS = "follower enp0s3 192.168.0.200/24"
]
Запустить сервис OpenNebula и проверить зону:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     1          5          5          0     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC
Сервер opennebula стал Leader-сервером, так же ему был присвоен плавающий адрес (Floating IP):
$ ip -o a sh enp0s3
2: enp0s3    inet 192.168.0.186/24 brd 192.168.0.255 scope global enp0s3\       valid_lft forever preferred_lft forever
2: enp0s3    inet 192.168.0.200/24 scope global secondary enp0s3\       valid_lft forever preferred_lft forever
2: enp0s3    inet6 fe80::a00:27ff:fec7:38e6/64 scope link \       valid_lft forever preferred_lft forever

34.2. Добавление дополнительных серверов

Предупреждение

Данная процедура удалит полностью базу на сервере и заменит её актуальной с Leader-сервера.

Предупреждение

Рекомендуется добавлять по одному узлу за раз, чтобы избежать конфликта в базе данных.
На Leader создать полную резервную копию актуальной базы и перенести её на другие серверы вместе с файлами из каталога /var/lib/one/.one/:
$ onedb backup -u oneadmin -d opennebula -p oneadmin
MySQL dump stored in /var/lib/one/mysql_localhost_opennebula_2021-6-23_13:43:21.sql
Use 'onedb restore' or restore the DB using the mysql command:
mysql -u user -h server -P port db_name < backup_file

$ scp /var/lib/one/mysql_localhost_opennebula_2021-6-23_13\:43\:21.sql <ip>:/tmp

$ ssh <ip> rm -rf /var/lib/one/.one
$ scp -r /var/lib/one/.one/ <ip>:/var/lib/one/ 
Остановить сервис OpenNebula на Follower-узлах и восстановить скопированную базу:
$ onedb restore -f -u oneadmin -p oneadmin -d opennebula /tmp/mysql_localhost_opennebula_2021-6-23_13\:43\:21.sql
MySQL DB opennebula at localhost restored.
Перейти на Leader и добавить в зону новые узлы (рекомендуется добавлять серверы по-одному):
$ onezone server-add 0 --name server02 --rpc http://192.168.0.187:2633/RPC2
Проверить зону на Leader-сервере:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2
 1 server02        http://192.168.0.187:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     4          22         22         0     -1
 1 server02        error      -          -          -          -     -

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Новый сервер находится в состоянии ошибки, так как OpenNebula на новом сервере не запущена. Следует запомнить идентификатор сервера, в этом случае он равен 1.
Переключиться на добавленный Follower-сервер и обновить конфигурацию SERVER_ID в файле /etc/one/oned.conf, (указать в качестве SERVER_ID значение из предыдущего шага). Включить Raft-обработчики, как это было выполнено на Leader.
Запустить сервис OpenNebula на Follower-сервере и проверить на Leader-сервере состояние зоны:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2
 1 server02        http://192.168.0.187:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     4          28         28         0     -1
 1 server02        follower   4          28         28         0     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2""
Повторить данные действия, чтобы добавить третий сервер в кластер.

Примечание

Добавлять серверы в кластер, следует только в случае нормальной работы кластера (работает Leader, а остальные находятся в состоянии Follower). Если в состоянии error присутствует хотя бы один сервер, необходимо это исправить.
Проверка работоспособности кластера:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2
 1 server02        http://192.168.0.187:2633/RPC2
 2 server03        http://192.168.0.188:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     4          35         35         0     -1
 1 server02        follower   4          35         35         0     -1
 2 server03        follower   4          35         35         0     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Если какой-либо узел находится в состоянии ошибки, следует проверить журнал (/var/log/one/oned.log), как в текущем Leader (если он есть), так и в узле, который находится в состоянии Error. Все сообщения Raft будут регистрироваться в этом файле.

34.3. Добавление и удаление серверов

Команда добавления сервера:
$ onezone server-add <zoneid>
параметры:
  • -n, --name — имя сервера зоны;
  • -r, --rpc — конечная точка RPC сервера зоны;
  • -v, --verbose — подробный режим;
  • --user name — имя пользователя, используемое для подключения к OpenNebula;
  • --password password — пароль для аутентификации в OpenNebula;
  • --endpoint endpoint — URL конечной точки интерфейса OpenNebula xmlrpc.
Команда удаления сервера:
$ onezone server-del <zoneid> <serverid>
параметры:
  • -v, --verbose — подробный режим;
  • --user name — имя пользователя, используемое для подключения к OpenNebula;
  • --password password — пароль для аутентификации в OpenNebula;
  • --endpoint endpoint — URL конечной точки интерфейса OpenNebula xmlrpc.

34.4. Восстановление сервера

Если Follower-сервер в течение некоторого времени не работает, он может выпасть из окна восстановления. Чтобы восстановить этот сервер необходимо:
  1. Leader: создать резервную копию БД и скопировать её на отказавший сервер (повторно использовать предыдущую резервную копию нельзя).
  2. Follower: остановить OpenNebula.
  3. Follower: восстановить резервную копию БД.
  4. Follower: запустить OpenNebula.
  5. Leader: сбросить отказавший Follower, выполнив команду:
    $ onezone server-reset <zone_id> <server_id_of_failed_follower>
    

34.5. Sunstone

Есть несколько способов развертывания Sunstone в среде HA. Базовым является Sunstone, работающий на каждом интерфейсном узле OpenNebula. Клиенты используют только один сервер — Leader с плавающим IP.

Часть V. Средство управления виртуальными окружениями PVE

Proxmox Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора KVM и системы контейнерной изоляции LXC. Основными компонентами среды являются:
  • физические серверы, на которых выполняются процессы гипервизора KVM, и процессы, работающие в контейнерах LXC;
  • хранилища данных, в которых хранятся образы установочных дисков, образы дисков виртуальных машин KVM и файлы, доступные из контейнеров LXC;
  • виртуальные сетевые коммутаторы, к которым подключаются сетевые интерфейсы виртуальных окружений.
PVE состоит из веб-интерфейса, распределённого хранилища данных конфигурации виртуальных окружений и утилит конфигурирования, работающих в командной строке. Все эти инструменты предназначены только для управления средой выполнения виртуальных окружений. За формирование среды отвечают компоненты системы, не входящие непосредственно в состав PVE. В первую очередь это сетевая и дисковая подсистемы, а также механизмы аутентификации.

Содержание

35. Системные требования
36. Краткое описание возможностей
36.1. Веб-интерфейс
36.2. Хранилище данных
36.3. Сетевая подсистема
37. Установка и настройка PVE
37.1. Установка PVE
37.2. Настройка сетевой подсистемы
37.2.1. Настройка Ethernet-моста в командной строке
37.2.2. Настройка Ethernet-моста в веб-интерфейсе
38. Создание кластера PVE
38.1. Настройка узлов кластера
38.2. Создание кластера в веб-интерфейсе
38.3. Создание кластера в консоли
38.4. Удаление узла из кластера
38.5. Кворум
38.6. Поддержка внешнего арбитра corosync
38.7. Кластерная файловая система PVE (pmxcfs)
39. Системы хранения PVE
39.1. Типы хранилищ в PVE
39.2. Конфигурация хранилища
39.3. Идентификатор тома
39.4. Работа с хранилищами в PVE
39.4.1. Использование командной строки
39.4.2. Добавление хранилища в веб-интерфейсе PVE
39.4.3. Каталог
39.4.4. NFS
39.4.5. BTRFS
39.4.6. CIFS
39.4.7. GlusterFS
39.4.8. Локальный ZFS
39.4.9. LVM
39.4.10. LVM-Thin
39.4.11. iSCSI
39.4.12. iSCSI/libiscsi
39.4.13. Ceph RBD
39.4.14. CephFS
39.4.15. Proxmox Backup Server
39.5. FC/iSCSI SAN
39.5.1. Подключение СХД
39.5.2. Настройка Multipath
39.5.3. Multipath в веб-интерфейсе PVE
39.5.4. Файловые системы на multipath
39.5.5. LVM/LVM-Thin хранилища на multipath
39.5.6. Изменение размера multipath-устройства
39.6. Кластер Ceph
39.6.1. Системные требования
39.6.2. Начальная конфигурация Ceph
39.6.3. Монитор Ceph
39.6.4. Менеджер Ceph
39.6.5. Ceph OSD
39.6.6. Пулы Ceph
39.6.7. Ceph CRUSH и классы устройств
39.6.8. Клиент Ceph
39.6.9. CephFS
39.6.10. Техническое обслуживание Ceph
39.6.11. Мониторинг и устранение неполадок Ceph
40. Сетевая подсистема
40.1. Применение изменений сетевых настроек
40.2. Имена сетевых устройств
40.3. Конфигурация сети с использованием моста
40.3.1. Внутренняя сеть для ВМ
40.4. Объединение/агрегация интерфейсов
40.4.1. Параметры Linux Bond
40.4.2. Параметры OVS Bond
40.4.3. Агрегированный bond-интерфейс с фиксированным IP-адресом
40.4.4. Агрегированный bond-интерфейс в качестве порта моста
40.5. Настройка VLAN
40.5.1. Мост с поддержкой VLAN
40.5.2. Мост на VLAN
41. Управление ISO-образами и шаблонами LXC
42. Виртуальные машины на базе KVM
42.1. Создание виртуальной машины на базе KVM
42.2. Запуск и остановка ВМ
42.2.1. Изменение состояния ВМ в веб-интерфейсе
42.2.2. Автоматический запуск ВМ
42.2.3. Массовый запуск и остановка ВМ
42.3. Управление ВМ с помощью qm
42.4. Скрипты-ловушки (hookscripts)
42.5. Доступ к ВМ
42.6. Внесение изменений в ВМ
42.6.1. Управление образами виртуальных дисков
42.6.2. Настройки дисплея
42.6.3. Дополнительные функции SPICE
42.6.4. Проброс USB
42.6.5. BIOS и UEFI
42.6.6. Доверенный платформенный модуль (TPM)
42.6.7. Проброс PCI(e)
42.6.8. Гостевой агент QEMU
42.7. Файлы конфигурации ВМ
43. Создание и настройка контейнера LXC
43.1. Создание контейнера в графическом интерфейсе
43.2. Создание контейнера из шаблона в командной строке
43.3. Изменение настроек контейнера
43.3.1. Изменение настроек в веб-интерфейсе
43.3.2. Настройка ресурсов в командной строке
43.3.3. Настройка ресурсов прямым изменением
43.4. Запуск и остановка контейнеров
43.4.1. Изменение состояния контейнера в веб-интерфейсе
43.4.2. Изменение состояния контейнера в командной строке
43.5. Доступ к LXC контейнеру
44. Миграция ВМ и контейнеров
44.1. Миграция с применением графического интерфейса
44.2. Миграция с применением командной строки
44.3. Миграция ВМ из внешнего гипервизора
44.3.1. Миграция KVM ВМ в PVE
44.3.2. Миграция ВМ из VMware в PVE
44.3.3. Пример импорта Windows OVF
45. Клонирование ВМ
46. Шаблоны ВМ
47. Теги (метки) ВМ
47.1. Работа с тегами
47.2. Настройка тегов
47.2.1. Стиль тегов
47.2.2. Права
48. Резервное копирование (Backup)
48.1. Алгоритмы резервного копирования
48.2. Режимы резервного копирования
48.3. Хранилище резервных копий
48.4. Резервное копирование по расписанию
48.5. Формат расписания
48.6. Настройка резервного копирования в графическом интерфейсе
48.7. Резервное копирование из командной строки
48.7.1. Файлы резервных копий
48.7.2. Восстановление
48.7.3. Ограничение пропускной способности
48.7.4. Файл конфигурация vzdump.conf
48.7.5. Файлы, не включаемые в резервную копию
48.7.6. Примеры
48.8. Снимки (snapshot)
49. Встроенный мониторинг PVE
50. Высокая доступность PVE
50.1. Как работает высокая доступность PVE
50.2. Требования для настройки высокой доступности
50.3. Настройка высокой доступности PVE
50.3.1. Создание группы высокой доступности
50.3.2. Добавление ресурсов
50.4. Тестирование настройки высокой доступности PVE
51. Пользователи и их права
51.1. API-токены
51.2. Пулы ресурсов
51.3. Области аутентификации
51.3.1. Стандартная аутентификация Linux PAM
51.3.2. Сервер аутентификации PVE
51.3.3. LDAP аутентификация
51.3.4. AD аутентификация
51.4. Двухфакторная аутентификация
51.5. Управление доступом
52. Просмотр событий PVE
52.1. Просмотр событий с помощью pvenode task
52.2. Просмотр событий в веб-интерфейсе PVE
52.2.1. Панель журнала
52.2.2. Журнал задач узла PVE
52.2.3. Журнал задач ВМ
53. PVE API
53.1. URL API
53.2. Аутентификация
53.2.1. Билет Cookie
53.2.2. API-токены
53.3. Пример создания контейнера с использованием API
53.4. Утилита pvesh
54. Основные службы PVE
54.1. pvedaemon — служба PVE API
54.2. pveproxy — служба PVE API Proxy
54.2.1. Управление доступом на основе хоста
54.2.2. Прослушиваемый IP-адрес
54.2.3. Набор SSL-шифров
54.2.4. Поддерживаемые версии TLS
54.2.5. Параметры Диффи-Хеллмана
54.2.6. Альтернативный сертификат HTTPS
54.2.7. Сжатие ответа
54.3. pvestatd — служба PVE Status
54.4. spiceproxy — служба SPICE Proxy
54.4.1. Управление доступом на основе хоста
54.5. pvescheduler — служба PVE Scheduler

Глава 35. Системные требования

Минимальные cистемные требования (для тестирования):
  • CPU: 64bit (Intel EMT64 или AMD64), поддержка Intel VT/AMD-V CPU/Mainboard;
  • минимум 1 Гб ОЗУ;
  • жёсткий диск;
  • сетевая карта.
Рекомендуемые cистемные требования:
  • CPU: мультипроцессорный 64bit (Intel EMT64 или AMD64), поддержка Intel VT/AMD-V CPU/Mainboard;
  • минимум 2 Гб ОЗУ для ОС и сервисов PVE. Плюс выделенная память для гостевых систем. Для Ceph или ZFS требуется дополнительная память, примерно 1 ГБ ОЗУ на каждый ТБ используемого хранилища;
  • хранилище для ОС: аппаратный RAID;
  • хранилище для ВМ: аппаратный RAID для локального хранилища, или non-RAID для ZFS. Также возможно совместное и распределенное хранение;
  • быстрые жёсткие диски 15krpm SAS, Raid10;
  • сетевая карта.
Реальные системные требования определяются количеством и требованиями гостевых систем.

Глава 36. Краткое описание возможностей

36.1. Веб-интерфейс

Веб-интерфейс PVE предназначен для решения следующих задач:
  • создание, удаление, настройка виртуальных окружений;
  • управление физическими серверами;
  • мониторинг активности виртуальных окружений и использования ресурсов среды;
  • фиксация состояний (snapshot-ы), создание резервных копий и шаблонов виртуальных окружений, восстановление виртуальных окружений из резервных копий.
Кроме решения пользовательских задач, веб-интерфейс PVE можно использовать еще и для встраивания в интегрированные системы управления — например, в панели управления хостингом. Для этого он имеет развитый RESTful API с JSON в качестве основного формата данных.
Для аутентификации пользователей веб-интерфейса можно использовать как собственные механизмы PVE, так и PAM. Использование PAM дает возможность, например, интегрировать PVE в домен аутентификации.
Так как используется кластерная файловая система (pmxcfs), можно подключиться к любому узлу для управления всем кластером. Каждый узел может управлять всем кластером.
Веб-интерфейс PVE доступен по адресу https://<имя-компьютера>:8006. Потребуется пройти аутентификацию (логин по умолчанию: root, пароль указывается в процессе установки ОС):
Аутентификация в веб-интерфейсе PVE
Пользовательский интерфейс PVE состоит из четырех областей:
  • заголовок — верхняя часть. Показывает информацию о состоянии и содержит кнопки для наиболее важных действий;
  • дерево ресурсов — с левой стороны. Дерево навигации, где можно выбирать конкретные объекты;
  • панель контента — центральная часть. Здесь отображаются конфигурация и статус выбранных объектов;
  • панель журнала — нижняя часть. Отображает записи журнала для последних задач. Чтобы получить более подробную информацию или прервать выполнение задачи, следует дважды щелкнуть левой клавишей мыши по записи журнала.
Веб-интерфейс PVE

Примечание

Есть возможность работы с PVE из мобильного приложения, например, Proxmox. В приложении можно получить доступ к узлам, ВМ и контейнерам:
Работа с PVE из мобильного приложения
Можно зайти в консоль ВМ с помощью noVNC или SPICE, осуществлять необходимые манипуляции внутри ВМ:
Работа с ВМ из мобильного приложения

36.2. Хранилище данных

В случае локальной установки PVE для размещения данных виртуальных окружений можно дополнительно ничего не настраивать и использовать локальную файловую систему сервера. Но в случае кластера из нескольких серверов имеет смысл настроить сетевую или распределенную сетевую файловую систему, обеспечивающую параллельный доступ к файлам со всех серверов, на которых выполняются процессы виртуальных окружений. В качестве таких файловых систем могут выступать, например, NFS или CEPH.

36.3. Сетевая подсистема

В отличие от хранилища данных, сетевая подсистема требует специальной настройки даже в случае локальной установки PVE. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному устройству, обеспечивающему соединение с общей сетью передачи данных. Перед началом настройки сети следует принять решение о том, какой тип виртуализации (LXC/KVM) и какой тип подключения будет использоваться (маршрутизация/мост).

Глава 37. Установка и настройка PVE

Примечание

Компоненты PVE будут установлены в систему, если при установке дистрибутива выбрать профиль Виртуальное окружение Proxmox (см. главу Установка системы).
При установке дистрибутива, необходимо настроить Ethernet-мост vmbr0 и при заполнении поля с именем компьютера указать полное имя с доменом (см. главу Настройка сети).
Все остальные настройки можно делать в веб-интерфейсе см. Создание кластера PVE.

37.1. Установка PVE

Если развертывание PVE происходит в уже установленной системе на базе Десятой платформы, достаточно на всех нодах (узлах) любым штатным способом (apt-get, aptitude, synaptic) установить пакет pve-manager:
# apt-get install pve-manager
Все необходимые компоненты при этом будут установлены автоматически.
Следует также убедиться в том, что пакет systemd обновлен до версии, находящейся в репозитории P10.

37.2. Настройка сетевой подсистемы

На всех узлах необходимо настроить Ethernet-мост.

Важно

Мосту должно быть назначено имя vmbr0 и оно должно быть одинаково на всех узлах.

Важно

При использовании дистрибутива Альт Виртуализация интерфейс vmbr0 создаётся и настраивается в процессе установки системы (см. Настройка сети).

37.2.1. Настройка Ethernet-моста в командной строке

Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна.
Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть еще одну консоль и запустить там, например, команду: sleep 500 && reboot.
Для настройки Ethernet-моста с именем vmbr0, следует выполнить следующие команды:
# mkdir /etc/net/ifaces/vmbr0
# cp /etc/net/ifaces/enp0s3/* /etc/net/ifaces/vmbr0/
# rm -f /etc/net/ifaces/enp0s3/{i,r}* 
# cat <<EOF > /etc/net/ifaces/vmbr0/options
BOOTPROTO=static
CONFIG_WIRELESS=no
CONFIG_IPV4=yes
HOST='enp0s3'
ONBOOT=yes
TYPE=bri
EOF
Имя интерфейса, обозначенного здесь как enp0s3, следует указать в соответствии с реальной конфигурацией сервера.
IP-адрес для интерфейса будет взят из /etc/net/ifaces/enp0s3/ipv4address.
В опции HOST файла /etc/net/ifaces/vmbr0/options нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, enp0s3), то этот адрес должен быть удален (например, можно закомментировать содержимое файла /etc/net/ifaces/enp0s3/ipv4address).
Для того чтобы изменения вступили в силу, необходим перезапуск сервиса network:
# systemctl restart network
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически).

37.2.2. Настройка Ethernet-моста в веб-интерфейсе

При установленных пакетах alterator-net-eth и alterator-net-bridge, для настройки Ethernet-моста можно воспользоваться веб-интерфейсом центра управления системой (ЦУС).

Примечание

Для возможности использования веб-интерфейса ЦУС должен быть установлен пакет alterator-fbi и запущены сервисы ahttpd и alteratord:
# apt-get install alterator-fbi
# systemctl start ahttpd
# systemctl start alteratord
Веб-интерфейс ЦУС доступен по адресу https://<ip-адрес>:8080.
Для настройки Ethernet-моста необходимо выполнить следующие действия:
  1. В веб-интерфейсе ЦУС выбрать пункт СетьEthernet-интерфейсы.
  2. У сетевого интерфейса, который будет входить в мост, удалить IP-адрес и шлюз по умолчанию.
  3. Нажать кнопку Создать сетевой мост…:
    Создание моста в веб-интерфейсе ЦУС
  4. В открывшемся окне, в поле Интерфейс-мост задать имя моста vmbr0, переместить сетевые интерфейсы, которые будут входить в мост, из списка Доступные интерфейсы в список Члены и и нажать кнопку Ок:
    Выбор сетевого интерфейса для моста
  5. Настроить созданный сетевой интерфейс vmbr0: задать IP-адрес и нажать кнопку Добавить, ввести адрес шлюза по умолчанию и DNS-сервера:
    Настройка параметров сетевого интерфейса vmbr0

Глава 38. Создание кластера PVE

Рекомендации:
  • все узлы должны иметь возможность подключаться друг к другу через UDP порты 5404 и 5405;
  • дата и время должны быть синхронизированы;
  • между узлами используется SSH туннель на 22 TCP порту;
  • если необходимо обеспечение высокой доступности (High Availability), необходимо иметь как минимум три узла для организации кворума. На всех узлах должна быть установлена одна версия PVE;
  • рекомендуется использовать выделенный сетевой адаптер для трафика кластера, особенно если используется общее хранилище.
PVE кластер может состоять из двух и более серверов.
Кластер не создается автоматически на только что установленном узле PVE. В настоящее время создание кластера может быть выполнено либо в консоли (вход через ssh), либо в веб-интерфейсе.

Важно

PVE при создании кластера включает парольную аутентификацию для root в sshd. В целях повышения безопасности, после включения всех серверов в кластер, рекомендуется отключить парольную аутентификацию для root в sshd:
# control sshd-permit-root-login without_password
# systemctl restart sshd
При добавлении в кластер нового сервера, можно временно включить парольную аутентификацию:
# control sshd-permit-root-login enabled
# systemctl restart sshd
А после того, как сервер будет добавлен, снова отключить.
Кластеры используют ряд определённых портов для различных функций. Важно обеспечить доступность этих портов и отсутствие их блокировки межсетевыми экранами.

Таблица 38.1. Используемые порты

Порт
Функция
TCP 8006
Веб-интерфейс PVE
TCP 5900-5999
Доступ к консоли VNC
TCP 3128
Доступ к консоли SPICE
TCP 22
SSH доступ
UDP 5404, 5405
Широковещательный CMAN для применения настроек кластера

38.1. Настройка узлов кластера

PVE должен быть установлен на всех узлах. Следует убедиться, что каждый узел установлен с окончательным именем хоста и IP-конфигурацией. Изменение имени хоста и IP-адреса невозможно после создания кластера.
Необходимо обеспечить взаимно однозначное прямое и обратное преобразование имен для всех узлов кластера. Крайне желательно использовать DNS, в крайнем случае, можно обойтись соответствующими записями в локальных файлах /etc/hosts:
# echo "192.168.0.186 pve01.test.alt pve01" >> /etc/hosts
# echo "192.168.0.90 pve02.test.alt pve02" >> /etc/hosts
# echo "192.168.0.70 pve03.test.alt pve03" >> /etc/hosts

Примечание

В PVE это можно сделать в панели управления: выбрать узел, перейти в СистемаХосты, добавить все узлы, которые будут включены в состав кластера:
Редактирование записей в файле /etc/hosts

Примечание

Имя машины не должно присутствовать в файле /etc/hosts разрешающимся в 127.0.0.1.

38.2. Создание кластера в веб-интерфейсе

Для создания кластера необходимо выполнить следующие действия:
  1. В панели управления любого узла кластера выбрать Центр обработки данныхКластер и нажать кнопку Создать кластер:
    Создание кластера в веб-интерфейсе
  2. В открывшемся окне задать название кластера, выбрать IP-адрес интерфейса, на котором узел кластера будет работать, и нажать кнопку Создать:
    Название кластера
  3. При успешном создании кластера будет выведена соответствующая информация:
    Информация о создании кластера
Для добавления узла в кластер необходимо выполнить следующие действия:
  1. В панели управления узла, на котором был создан кластер, выбрать Центр обработки данныхКластер и нажать кнопку Данные присоединения:
    Создание кластера в веб-интерфейсе. Получить данные присоединения
  2. В открывшемся окне, нажав кнопку Копировать данные, скопировать данные присоединения:
    Создание кластера. Данные присоединения
  3. Перейти в панель управления узла, который следует присоединить к кластеру. Выбрать Центр обработки данныхКластер и нажать кнопку Присоединить к кластеру:
    Узел, который следует присоединить к кластеру
  4. В поле Данные вставить данные присоединения, поля Адрес сервера и Отпечаток при этом будут заполнены автоматически. В поле Пароль ввести пароль пользователя root первого узла и нажать кнопку Join <имя_кластера> (Присоединение):
    Присоединение узла к кластеру
  5. Через несколько минут, после завершения репликации всех настроек, узел будет подключен к кластеру:
    Узлы кластера в веб-интерфейсе
Сразу после инициализации кластера в пределах каждого из узлов доступно одно локальное хранилище данных:
Веб-интерфейс PVE

38.3. Создание кластера в консоли

Команда создания кластера:
# pvecm create <cluster_name>
На «головном» узле кластера необходимо выполнить команду инициализации конкретного кластера PVE, в данном случае — «pve-cluster»:
# systemctl start pve-cluster
# pvecm create pve-cluster
Проверка:
# pvecm status
Cluster information
-------------------
Name:             pve-cluster
Config Version:   1
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Mon Apr  1 10:32:25 2024
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.5
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            Quorate

Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 192.168.0.186 (local)
Команда создания кластера создает файл настройки /etc/pve/corosync.conf. По мере добавления узлов в кластер файл настройки будет автоматически пополняться информацией об узлах.
Команда для добавления узла в кластер:
# pvecm add <existing_node_in_cluster>
где existing_node_in_cluster — адрес уже добавленного узла (рекомендуется указывать самый первый).
Для добавления узлов в кластер, необходимо на «подчинённых» узлах выполнить команду:
# pvecm add pve01
где pve01 — имя или IP-адрес «головного» узла.
При добавлении узла в кластер потребуется ввести пароль администратора главного узла кластера:
# pvecm add pve01
Please enter superuser (root) password for 'pve01': ***
Establishing API connection with host 'pve01'

Login succeeded.
Request addition of this node
Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '/var/lib/pve-cluster/backup/config-1625747072.sql.gz'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys and known hosts
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'pve03' to cluster.
После добавления узлов в кластер, файл настройки кластера в /etc/pve/corosync.conf должен содержать информацию об узлах кластера.
На всех узлах кластера должны быть запущены и добавлены в список служб, запускаемых при старте узла, службы:
# systemctl start pve-cluster pveproxy pvedaemon pvestatd pve-firewall pvefw-logger pve-ha-crm pve-ha-lrm spiceproxy lxc lxcfs lxc-net lxc-monitord qmeventd pvescheduler pve-lxc-syscalld
# systemctl enable pve-cluster pveproxy pvedaemon pvestatd pve-firewall corosync pvefw-logger pve-guests pve-ha-crm pve-ha-lrm spiceproxy lxc lxcfs lxc-net lxc-monitord qmeventd pvescheduler pve-lxc-syscalld

38.4. Удаление узла из кластера

Перед удалением узла из кластера необходимо переместить все ВМ с этого узла, а также убедиться, что нет никаких локальных данных или резервных копий, которые необходимо сохранить.
Для удаления узла из кластера необходимо выполнить следующие шаги:
  1. Войти в узел кластера, не подлежащий удалению (в примере pve01).
  2. Ввести команду pvecm nodes, чтобы определить идентификатор узла, который следует удалить:
    # pvecm nodes
    
    Membership information
    ----------------------
        Nodeid      Votes Name
             1          1 pve01 (local)
             2          1 pve02
             3          1 pve03
    
  3. Выключить подлежащий удалению узел (в данном случае pve02).
  4. Удалить узел из кластера, выполнив команду:
    # pvecm delnode pve02
    
  5. Проверить, что узел удален (команда отобразит список узлов кластера без удаленного узла):
    # pvecm nodes
    Membership information
    ----------------------
        Nodeid      Votes Name
             1          1 pve01 (local)
             3          1 pve03
    
Если необходимо вернуть удаленный узел обратно в кластер, следует выполнить следующие действия:
  • переустановить PVE на этом узле (это гарантирует, что все секретные ключи кластера/ssh и любые данные конфигурации будут уничтожены);
  • присоединиться к кластеру.

38.5. Кворум

Для обеспечения согласованного состояния среди всех узлов кластера PVE использует метод на основе кворума. Кворум — это минимальное количество голосов, которые должны быть доступны для работы кластера.
Проверить наличие кворума можно, выполнив команду:
# pvecm status
…
Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3
Flags:            Quorate
…
В выводе команды видно, что в кластере пять узлов (Expected votes), из них для кворума необходимо не менее трёх (Quorum), сейчас все пять узлов активны (Total votes), кворум соблюден (Flags: Quorate).
Если количество голосов окажется меньше, чем требуется для кворума, кластер переключится в режим только для чтения (read-only): гостевые системы продолжат работать, но любые операции с узлами или гостевыми системами станут невозможными.
В PVE по умолчанию каждому узлу назначается один голос.

38.6. Поддержка внешнего арбитра corosync

Добавив в кластер PVE внешний арбитр, можно добиться того, что кластер сможет выдержать большее количество отказов узлов без нарушения работы кластера.
Для работы арбитра задействованы две службы:
  • Corosync Quroum (QDevice) — служба, которая работает на каждом узле кластера PVE. Она предоставляет настроенное количество голосов подсистеме кворума на основе решения внешнего управляющего арбитра. Основное назначение этой службы — позволить кластеру выдержать большее количество отказов узлов, чем это позволяют стандартные правила кворума. Арбитр видит все узлы и может выбрать только один набор узлов, чтобы отдать свой голос (это будет сделано только в том случае, если указанный набор узлов при получении голоса арбитра сможет иметь кворум).
  • Внешний арбитр, который работает на независимом сервере. Единственное требование к арбитру — наличие сетевого доступа к кластеру.

Примечание

В настоящее время Qdevices для кластеров с нечетным числом узлов не поддерживается. Это связано с разницей в количестве голосов, которые QDevice предоставляет для кластера.
Кластеры с чётным числом узлов получают один дополнительный голос, что только увеличивает доступность, поскольку сбой самого QDevice не влияет на работоспособность кластера.
Для кластера с нечётным числом узлов QDevice предоставляет (N-1) голосов, где N — количество узлов кластера. Этот алгоритм допускает сбой всех узлов, кроме одного и самого QDevice. При этом есть два недостатка:
  • если произойдет сбой арбитра, ни один другой узел не может выйти из строя, или кластер немедленно потеряет кворум. Например, в кластере с 15 узлами 7 могут выйти из строя, прежде чем кластер станет неработоспособным. Но если в этом кластере настроен QDevice и он сам выйдет из строя, ни один узел из 15 не может выйти из строя. В этом случае QDevice действует почти как единая точка отказа;
  • возможность выхода из строя всех узлов, кроме одного, плюс QDevice, может привести к массовому восстановлению служб высокой доступности (HA), что может привести к перегрузке единственного оставшегося узла. Кроме того, сервер Ceph прекратит предоставлять услуги, если в сети останется только ((N-1)/2) узлов или меньше.

Важно

При настройке QDevice PVE копирует ключи кластера на внешний сервер. Для добавления QDevice можно временно включить парольную аутентификацию для root в sshd на внешнем сервере:
# control sshd-permit-root-login enabled
# systemctl restart sshd
А после того, как QDevice будет добавлен, отключить:
# control sshd-permit-root-login without_password
# systemctl restart sshd
Для настройки работы арбитра необходимо выполнить следующие действия:
  1. На внешнем сервере:
    • установить пакет corosync-qnetd (из репозитория):
      # apt-get install corosync-qnetd
      
    • запустить и добавить в автозагрузку службу corosync-qnetd:
      # systemctl enable --now corosync-qnetd
      
  2. На всех узлах PVE установить пакет corosync-qdevice (из репозитория):
    # apt-get install corosync-qdevice
    
  3. На одном из узлов PVE настроить QDevice, выполнив команду:
    # pvecm qdevice setup 192.168.0.88
    
    где 192.168.0.88 — IP-адрес арбитра (внешнего сервера).
    SSH-ключи из кластера будут автоматически скопированы в QDevice.
  4. На любом узле PVE проверить статус кластера:
    # pvecm status
    …
    Votequorum information
    ----------------------
    Expected votes:   5
    Highest expected: 5
    Total votes:      5
    Quorum:           3
    Flags:            Quorate Qdevice
    
    Membership information
    ----------------------
        Nodeid      Votes    Qdevice Name
    0x00000001          1    A,V,NMW 192.168.0.186 (local)
    0x00000002          1    A,V,NMW 192.168.0.90
    0x00000003          1    A,V,NMW 192.168.0.70
    0x00000004          1    A,V,NMW 192.168.0.91
    0x00000000          1            Qdevice
    
Для добавления нового узла или удаления существующего из кластера с настроенным QDevice, сначала необходимо удалить QDevice. После можно добавлять или удалять узлы в обычном режиме.
Команда удаления QDevice:
# pvecm qdevice remove

38.7. Кластерная файловая система PVE (pmxcfs)

Кластерная файловая система PVE (pmxcfs) — это файловая система на основе базы данных для хранения файлов конфигурации виртуальных окружений, реплицируемая в режиме реального времени на все узлы кластера с помощью corosync. Эта файловая система используется для хранения всех конфигурационных файлов связанных c PVE. Хотя файловая система хранит все данные в базе данных на диске, копия данных находится в оперативной памяти, что накладывает ограничение на максимальный размер данных, который в настоящее время составляет 30 МБ.
Преимущества файловой системы pmxcfs:
  • мгновенная репликация и обновление конфигурации на все узлы в кластере;
  • исключается вероятность дублирования идентификаторов виртуальных машин;
  • в случае развала кворума в кластере, файловая система становится доступной только для чтения.
Все файлы и каталоги принадлежат пользователю root и имеют группу www-data. Только root имеет права на запись, но пользователи из группы www-data могут читать большинство файлов. Файлы в каталогах /etc/pve/priv/ и /etc/pve/nodes/${NAME}/priv/ доступны только root.
Файловая система смонтирована в /etc/pve/.

Глава 39. Системы хранения PVE

Образы ВМ могут храниться в одном или нескольких локальных хранилищах или в общем (совместно используемом) хранилище, например, NFS или iSCSI (NAS, SAN). Ограничений нет, можно настроить столько хранилищ, сколько необходимо.
В кластерной среде PVE наличие общего хранилища не является обязательным, однако оно делает управление хранением более простой задачей. Преимущества общего хранилища:
  • миграция ВМ в реальном масштабе времени;
  • плавное расширение пространства хранения с множеством узлов;
  • централизованное резервное копирование;
  • многоуровневое кэширование данных;
  • централизованное управление хранением.

39.1. Типы хранилищ в PVE

Существует два основных типа хранилищ:
  • файловые хранилища — хранят данные в виде файлов. Технологии хранения на уровне файлов обеспечивают доступ к полнофункциональной файловой системе (POSIX). В целом они более гибкие, чем любое хранилище на уровне блоков, и позволяют хранить контент любого типа;
  • блочное хранилище — позволяет хранить большие необработанные образы. Обычно в таких хранилищах невозможно хранить другие файлы (ISO-образы, резервные копии, и т.д.). Большинство современных реализаций хранилищ на уровне блоков поддерживают моментальные снимки и клонирование. RADOS и GlusterFS являются распределенными системами, реплицирующими данные хранилища на разные узлы.
Хранилищами данных удобно управлять через веб-интерфейс. В качестве бэкенда хранилищ PVE может использовать:
  • сетевые файловые системы, в том числе распределенные: NFS, CEPH, GlusterFS;
  • локальные системы управления дисковыми томами: LVM, ZFS;
  • удаленные (iSCSI) и локальные дисковые тома;
  • локальные дисковые каталоги.

Таблица 39.1. Доступные типы хранилищ

Хранилище
PVE тип
Уровень
Общее (shared)
Снимки (snapshots)
ZFS (локальный)
zfspool
файл
нет
да
dir
файл
нет
нет (возможны в формате qcow2)
btrfs
файл
нет
да
NFS
nfs
файл
да
нет (возможны в формате qcow2)
cifs
файл
да
нет (возможны в формате qcow2)
glusterfs
файл
да
нет (возможны в формате qcow2)
cephfs
файл
да
да
LVM
lvm
блок
нет*
нет
lvmthin
блок
нет
да
iscsi
блок
да
нет
iscsidirect
блок
да
нет
rbd
блок
да
да
ZFS over iSCSI
zfs
блок
да
да
pbs
файл/блок
да
-

Примечание

Можно использовать LVM поверх хранилища на базе iSCSI или FC, получив таким образом общее хранилище LVM.

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

Вся связанная с PVE информация о хранилищах хранится в файле /etc/pve/storage.cfg. Поскольку этот файл находится в /etc/pve/, он автоматически распространяется на все узлы кластера. Таким образом, все узлы имеют одинаковую конфигурацию хранилища.
Совместное использование конфигурации хранилища имеет смысл для общего хранилища, поскольку одно и то же «общее» хранилище доступно для всех узлов. Но также полезно для локальных типов хранения. В этом случае такое локальное хранилище доступно на всех узлах, но оно физически отличается и может иметь совершенно разное содержимое.
Каждое хранилище имеет <тип> и уникально идентифицируется своим <STORAGE_ID>. Конфигурация хранилища выглядит следующим образом:
<type>: <STORAGE_ID>
        <property> <value>
        <property> <value>
        ...
Строка <type>: <STORAGE_ID> определяет хранилище, затем следует список свойств.
Пример файла /etc/pve/storage.cfg:
# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content images,rootdir,iso,snippets,vztmpl
        maxfiles 0
nfs: nfs-storage
        export /export/storage
        path /mnt/nfs-vol
        server 192.168.0.105
        content images,iso,backup,vztmpl
        options vers=3,nolock,tcp
В данном случае файл содержит описание специального хранилища local, которое ссылается на каталог /var/lib/vz, и описание NFS-хранилища nfs-storage.

Таблица 39.2. Параметры хранилищ

Свойство
Описание
nodes
Список узлов кластера, где хранилище можно использовать/доступно. Можно использовать это свойство, чтобы ограничить доступ к хранилищу.
content
Хранилище может поддерживать несколько типов содержимого. Это свойство указывает, для чего используется это хранилище.
Доступные опции:
  • images — образы виртуальных дисков;
  • rootdir — данные контейнеров;
  • vztmpl — шаблоны контейнеров;
  • backup — резервные копии (vzdump);
  • iso — ISO образы;
  • snippets — файлы фрагментов (сниппетов), например, скрипты-ловушки гостевой системы.
shared
Указать, что это единое хранилище с одинаковым содержимым на всех узлах (или на всех перечисленных в опции nodes). Данное свойство не делает содержимое локального хранилища автоматически доступным для других узлов, он просто помечает как таковое уже общее хранилище!
disable
Отключить хранилище
maxfiles
Устарело, следует использовать свойство prune-backups. Максимальное количество файлов резервных копий на ВМ
prune-backups
Варианты хранения резервных копий
format
Формат образа по умолчанию (raw|qcow2|vmdk)
preallocation
Режим предварительного выделения (off|metadata|falloc|full) для образов raw и qcow2 в файловых хранилищах. По умолчанию используется значение metadata (равносильно значению off для образов raw). При использовании сетевых хранилищ в сочетании с большими образами qcow2, использование значения off может помочь избежать таймаутов.

Примечание

Не рекомендуется использовать один и тот же пул хранения в разных PVE-кластерах. Для некоторых операций требуется монопольный доступ к хранилищу, поэтому требуется правильная блокировка. Блокировка реализована внутри кластера, но не работает между разными кластерами.

39.3. Идентификатор тома

Для обращения к данным хранилищ используется специальная нотация. Том идентифицируется по <STORAGE_ID>, за которым через двоеточие следует имя тома, зависящее от типа хранилища. Примеры <VOLUME_ID>:
local:iso/slinux-10.2-x86_64.iso
local:101/vm-101-disk-0.qcow2
local:backup/vzdump-qemu-100-2023_08_22-21_12_33.vma.zst
nfs-storage:vztmpl/alt-p10-rootfs-systemd-x86_64.tar.xz
Чтобы получить путь к файловой системе для <VOLUME_ID> используется команда:
# pvesm path <VOLUME_ID>
Например:
# pvesm path local:iso/slinux-10.2-x86_64.iso
/var/lib/vz/template/iso/slinux-10.2-x86_64.iso
# pvesm path nfs-storage:vztmpl/alt-p10-rootfs-systemd-x86_64.tar.xz
/mnt/pve/nfs-storage/template/cache/alt-p10-rootfs-systemd-x86_64.tar.xz
Для томов типа image существует отношение владения. Каждый такой том принадлежит ВМ или контейнеру. Например, том local:101/vm-101-disk-0.qcow2 принадлежит ВМ 101. При удалении ВМ или контейнера, система также удаляет все связанные тома, принадлежащие этой ВМ или контейнеру.

39.4. Работа с хранилищами в PVE

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

Утилита pvesm (PVE Storage Manager), позволяет выполнять общие задачи управления хранилищами.
Команды добавления (подключения) хранилища:
# pvesm add <TYPE> <STORAGE_ID> <OPTIONS>
# pvesm add dir <STORAGE_ID> --path <PATH>
# pvesm add nfs <STORAGE_ID> --path <PATH> --server <SERVER> --export <EXPORT>
# pvesm add lvm <STORAGE_ID> --vgname <VGNAME>
# pvesm add iscsi <STORAGE_ID> --portal <HOST[:PORT]> --target <TARGET>
Отключить хранилище:
# pvesm set <STORAGE_ID> --disable 1
Включить хранилище:
# pvesm set <STORAGE_ID> --disable 0
Для того чтобы изменить/установить опции хранилища, можно выполнить команды:
# pvesm set <STORAGE_ID> <OPTIONS>
# pvesm set <STORAGE_ID> --shared 1
# pvesm set local --format qcow2
# pvesm set <STORAGE_ID> --content iso
Удалить хранилище (при этом никакие данные не удаляются, удаляется только конфигурация хранилища):
# pvesm remove <STORAGE_ID>
Команда выделения тома:
# pvesm alloc <STORAGE_ID> <VMID> <name> <size> [--format <raw|qcow2>]
Выделить том 4 ГБ в локальном хранилище (имя будет сгенерировано):
# pvesm alloc local <VMID> '' 4G
Освободить место (уничтожает все данные тома):
# pvesm free <VOLUME_ID>
Вывести список хранилищ:
# pvesm status
Вывести список содержимого хранилища:
# pvesm list <STORAGE_ID> [--vmid <VMID>]
Вывести список ISO-образов:
# pvesm list <STORAGE_ID> --iso

39.4.2. Добавление хранилища в веб-интерфейсе PVE

Хранилища, которые могут быть добавлены в веб-интерфейсе PVE:
  • Локальные хранилища:
    • Каталог — хранение на существующей файловой системе;
    • LVM — локальные устройства, такие как, FC, DRBD и т.д.;
    • ZFS;
    • BTRFS;
  • Сетевые хранилища:
    • LVM — сетевая поддержка с iSCSI target;
    • NFS;
    • CIFS;
    • GlusterFS;
    • iSCSI;
    • CephFS;
    • RBD;
    • ZFS over iSCSI.
Выбор типа добавляемого хранилища
При создании каждому хранилищу данных присваивается роль или набор ролей. Например, хранение контейнеров, образов виртуальных дисков, ISO-файлов и так далее. Список возможных ролей зависит от бэкенда хранилища. Например, для NFS или каталога локальной файловой системы доступны любые роли или наборы ролей, а хранилища на базе RBD можно использовать только для хранения образов дисков и контейнеров:
Выбор ролей для хранилища

Примечание

Можно добавить локальные хранилища (ZFS, LVM и LVM-Thin), расположенные на других узлах кластера. Для этого в мастере добавления хранилища следует выбрать узел для сканирования:
LVM хранилище. Выбор узла для сканирования

39.4.3. Каталог

PVE может использовать локальные каталоги или локально смонтированные общие ресурсы для организации хранилища. Каталог — это файловое хранилище, поэтому в нем можно хранить данные любого типа, например, образы виртуальных дисков, контейнеры, шаблоны, ISO-образы или файлы резервных копий. Для хранения данных разного типа, используется предопределенная структура каталогов. Эта структура используется на всех файловых хранилищах.

Таблица 39.3. Структура каталогов

Тип данных
Подкаталог
Образы дисков ВМ
images/<VMID>/
ISO-образы
template/iso/
Шаблоны контейнеров
template/cache/
Резервные копии VZDump
dump/
Фрагменты (сниппеты)
snippets/

Примечание

Дополнительные хранилища можно подключить в /etc/fstab, а затем определить хранилище каталогов для этой точки монтирования. Таким образом, можно использовать любую файловую систему (ФС), поддерживаемую Linux.

Примечание

Большинство ФС «из коробки» не поддерживают моментальные снимки. Чтобы обойти эту проблему, этот бэкэнд может использовать возможности внутренних снимков qcow2.
Для создания нового хранилища типа Каталог необходимо выбрать Центр обработки данныхХранилище, нажать кнопку Добавить и в выпадающем меню выбрать пункт Каталог.
Диалог создания хранилища local-iso типа Каталог для хранения ISO-образов и шаблонов контейнеров, которое будет смонтировано в каталог /mnt/iso:
Добавление хранилища типа Каталог
Данное хранилище поддерживает все общие свойства хранилищ и дополнительно свойства:
  • path — указание каталога (это должен быть абсолютный путь к файловой системе);
  • content-dirs (опционально) — позволяет изменить макет по умолчанию. Состоит из списка идентификаторов, разделенных запятыми, в формате:
    vtype=path
    где vtype — один из разрешенных типов контента для хранилища, а path — путь относительно точки монтирования хранилища.
Пример файла конфигурации (/etc/pve/storage.cfg):
dir: backup
    path /mnt/backup
    content backup
    prune-backups keep-last=7
    shared 0
    content-dirs backup=custom/backup
Данная конфигурация определяет пул хранения резервных копий. Этот пул может использоваться для последних 7 резервных копий на виртуальную машину. Реальный путь к файлам резервных копий — /mnt/backup/custom/backup.

Примечание

Флаг shared (Общий доступ) можно установить только для кластерных ФС (например, ocfs2).
Хранилище Каталог использует следующую схему именования образов ВМ:
VM-<VMID>-<NAME>.<FORMAT>
где:
  • <VMID> — идентификатор ВМ;
  • <NAME> — произвольное имя (ascii) без пробелов. По умолчанию используется disk-[N], где [N] заменяется целым числом;
  • <FORMAT> — определяет формат образа (raw|qcow2|vmdk).
Пример:
# ls /var/lib/vz/images/101
vm-101-disk-0.qcow2  vm-101-disk-1.qcow2
При создании шаблона ВМ все образы дисков ВМ переименовываются, чтобы указать, что они теперь доступны только для чтения и могут использоваться в качестве базового образа для клонов:
base-<VMID>-<NAME>.<FORMAT>

39.4.4. NFS

Хранилище NFS аналогично хранению каталогов и файлов на диске, с дополнительным преимуществом совместного хранения и миграции в реальном времени. Свойства хранилища NFS во многом совпадают с хранилищем типа Каталог. Структура каталогов и соглашение об именах файлов также одинаковы. Основным преимуществом является то, что можно напрямую настроить свойства сервера NFS, и общий ресурс будет монтироваться автоматически (без необходимости изменения /etc/fstab).
Данное хранилище поддерживает все общие свойства хранилищ кроме флага shared, который всегда установлен. Кроме того, для настройки NFS используются следующие свойства:
  • server — IP-адрес сервера или DNS-имя. Предпочтительнее использовать IP-адрес вместо DNS-имени (чтобы избежать задержек при поиске DNS);
  • export — совместный ресурс с сервера NFS (список можно просмотреть, выполнив команду pvesm scan nfs <server>);
  • path — локальная точка монтирования (по умолчанию /mnt/pve/<STORAGE_ID>/);
  • content-dirs (опционально) — позволяет изменить макет по умолчанию. Состоит из списка идентификаторов, разделенных запятыми, в формате:
    vtype=path
    где vtype — один из разрешенных типов контента для хранилища, а path — путь относительно точки монтирования хранилища;
  • options — параметры монтирования NFS (см. man nfs).
Пример файла конфигурации (/etc/pve/storage.cfg):
nfs: nfs-storage
    export /export/storage
    path /mnt/pve/nfs-storage
    server 192.168.0.105
    content images,backup,vztmpl,iso
    options vers=3,nolock,tcp

Примечание

По истечении времени ожидания запрос NFS по умолчанию повторяется бесконечно. Это может привести к неожиданным зависаниям на стороне клиента. Для содержимого, доступного только для чтения, следует рассмотреть возможность использования NFS-опции soft, в этом случае будет выполняться только три запроса.

Примечание

Для возможности монтирования NFS-хранилища должен быть запущен nfs-client:
# systemctl enable --now nfs-client.target
Присоединение хранилища NFS с именем nfs-storage с удаленного сервера 192.168.0.105:
Создание хранилища NFS
После ввода IP-адреса удаленного сервера, доступные ресурсы будут автоматически просканированы и будут отображены в выпадающем списке Export. В данном примере обнаруженная в блоке диалога точка монтирования — /export/storage.
Пример добавления хранилища NFS в командной строке с помощью утилиты pvesm:
# pvesm add nfs nfs-storage --path /mnt/nfs-vol --server 192.168.0.105 --options vers=3,nolock,tcp --export /export/storage --content images,iso,vztmpl,backup
Получить список совместных ресурсов с сервера NFS:
# pvesm nfsscan <server>

39.4.5. BTRFS

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

Примечание

BTRFS учитывает флаг O_DIRECT при открытии файлов, что означает, что ВМ не должны использовать режим кеширования none, иначе возникнут ошибки контрольной суммы.
Данное хранилище настраивается аналогично хранилищу типа Каталог.

Примечание

При добавлении в качестве хранилища BTRFS каталога, который сам по себе не является точкой монтирования, настоятельно рекомендуется указать фактическую точку монтирования с помощью параметра is_mountpoint.
Пример файла конфигурации (/etc/pve/storage.cfg):
btrfs: btrfs-storage
    path /mnt/data/btrfs-storage
    content rootdir,images
    is_mountpoint /mnt/data
    nodes pve02
    prune-backups keep-all=1
В данном примере файловая система BTRFS смонтирована в /mnt/data, а в качестве пула хранения данных добавляется её подкаталог btrfs-storage/.
Диалог создания хранилища brtfs-storage типа BTRFS для хранения образов дисков и контейнеров, которое будет смонтировано в каталог /mnt/data:
Создание хранилища BTRFS
Пример добавления хранилища BTRFS в командной строке с помощью утилиты pvesm:
# pvesm add btrfs btrfs-storage --path /mnt/data/btrfs-storage --is_mountpoint /mnt/data/ --content images,rootdir

39.4.5.1. Администрирование BTRFS

В этом разделе приведены некоторые примеры работы с ФС BTRFS.
Пример создания ФС BTRFS на диске /dev/sdd:
# mkfs.btrfs -m single -d single -L My-Storage /dev/sdd
Параметры -m и -d используются для установки профиля для метаданных и данных соответственно. С помощью необязательного параметра -L можно установить метку.
Можно создать RAID1 на двух разделах /dev/sdb1 и/dev/sdc1:
# mkfs.btrfs -m raid1 -d raid1 -L My-Storage /dev/sdb1 /dev/sdc1
Новую ФС можно смонтировать вручную, например:
# mkdir /mnt/data
# mount /dev/sdd /mnt/data
Для автоматического монтирования BTRFS раздела, следует добавить этот раздел в /etc/fstab. Рекомендуется использовать значение UUID (выведенное командой mkfs.btrf), например:
UUID=5a556184-43b2-4212-bc21-eee3798c8322 /mnt/data btrfs defaults 0 0
Выполнить проверку монтирования:
# mount -a
Результатом выполнения команды должен быть пустой вывод без ошибок.

Примечание

UUID можно также получить, выполнив команду:
# blkid
/dev/sdd: LABEL="My-Storage" UUID="5a556184-43b2-4212-bc21-eee3798c8322" BLOCK_SIZE="4096" TYPE="btrfs"
Создание подтома (файловая система BTRFS должна быть примонтирована):
# btrfs subvolume create /mnt/data/btrfs-storage
Удаление подтома:
# btrfs subvolume delete /mnt/data/btrfs-storage
Создание снимка (снимок — это подтом, который имеет общие данные и метаданные с другим подтомом):
# btrfs subvolume snapshot -r /mnt/data/btrfs-storage /mnt/data/new
Будет создан доступный только для чтения «клон» подтома /mnt/data/btrfs-storage. Чтобы из снимка, доступного только для чтения, создать его версию, доступную для записи, следует просто создать его снимок без опции -r.
Просмотреть список текущих подтомов:
# btrfs subvolume list /mnt/data
ID 256 gen 17 top level 5 path btrfs-storage
ID 257 gen 14 top level 5 path new
Отображение занятого/свободного места:
# btrfs filesystem usage /mnt/data
или:
$ btrfs filesystem df /mnt/data

39.4.6. CIFS

Хранилище SMB/CIFS расширяет хранилище типа Каталог, поэтому ручная настройка монтирования CIFS не требуется.

Примечание

Для возможности просмотра общих ресурсов на каждом узле кластера необходимо установить пакет samba-client.
Данное хранилище поддерживает все общие свойства хранилищ кроме флага shared, который всегда установлен. Кроме того, для настройки CIFS используются следующие свойства:
  • server — IP-адрес сервера или DNS-имя. Предпочтительнее использовать IP-адрес вместо DNS-имени (чтобы избежать задержек при поиске DNS);
  • share — совместный ресурс с сервера CIFS (список можно просмотреть, выполнив команду pvesm scan cifs <server>);
  • username — имя пользователя для хранилища CIFS (опционально, по умолчанию «guest»);
  • password — пароль пользователя (опционально). Пароль будет сохранен в файле, доступном только для чтения root-пользователю (/etc/pve/priv/storage/<STORAGE-ID>.pw);
  • domain — устанавливает домен пользователя (рабочую группу) для этого хранилища (опционально);
  • smbversion — версия протокола SMB (опционально, по умолчанию 3). Версия 1 не поддерживается;
  • path — локальная точка монтирования (по умолчанию /mnt/pve/<STORAGE_ID>/);
  • content-dirs (опционально) — позволяет изменить макет по умолчанию. Состоит из списка идентификаторов, разделенных запятыми, в формате:
    vtype=path
    где vtype — один из разрешенных типов контента для хранилища, а path — путь относительно точки монтирования хранилища;
  • options — дополнительные параметры монтирования CIFS (см. man mount.cifs). Некоторые параметры устанавливаются автоматически, и их не следует задавать в этом параметре. PVE всегда устанавливает опцию soft;
  • subdir — подкаталог общего ресурса, который необходимо смонтировать (опционально, по умолчанию используется корневой каталог общего ресурса).
Пример файла конфигурации (/etc/pve/storage.cfg):
cifs: newCIFS
    path /mnt/pve/newCIFS
    server 192.168.0.105
    share smb_data
    smbversion 2.1
Получить список совместных ресурсов с сервера CIFS можно, выполнив команду:
# pvesm cifsscan <server> [--username <username>] [--password]
Команда добавления общего ресурса в качестве хранилища:
# pvesm add cifs <storagename> --server <server> --share <share> [--username <username>] [--password]
Подключение хранилища SMB/CIFS с именем newCIFS с удаленного сервера 192.168.0.105:
Добавление SMB/CIFS хранилища
После ввода IP-адреса удаленного сервера, доступные ресурсы будут автоматически просканированы и будут отображены в выпадающем списке Share.

Примечание

При создании CIFS хранилища в веб-интерфейсе, PVE предполагает, что удаленный сервер поддерживает CIFS v3. В веб-интерфейсе нет возможности указать версию CIFS, поэтому в случае, если удалённый сервер поддерживает версии CIFS отличные от v3, создать хранилище можно в командной строке, например:
# pvesm add cifs newCIFS --server 192.168.0.105 --share smb_data --smbversion 2.1

39.4.7. GlusterFS

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

Примечание

После сбоя узла GlusterFS выполняет полную синхронизацию, чтобы убедиться в согласованности данных. Для больших файлов это может занять очень много времени, поэтому это хранилище не подходит для хранения больших образов ВМ.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • server — IP-адрес или DNS-имя сервера GlusterFS;
  • server2 — IP-адрес или DNS-имя резервного сервера GlusterFS;
  • volume — том GlusterFS;
  • transport — транспорт GlusterFS: tcp, unix или rdma.
Пример файла конфигурации (/etc/pve/storage.cfg):
glusterfs: gluster-01
    server 192.168.0.105
    server2 192.168.0.110
    volume glustervol
    content images,iso
Подключение хранилища GlusterFS с именем gluster-01 с удаленного сервера 192.168.0.105:
Создание хранилища GlusterFS

39.4.8. Локальный ZFS

Примечание

Для работы с локальным ZFS хранилищем должен быть установлен модуль ядра kernel-modules-zfs-std-def. Включить модуль:
# modprobe zfs
Чтобы не вводить эту команду после перезагрузки, следует раскомментировать строку:
#zfs
в файле /etc/modules-load.d/zfs.conf.
Локальный ZFS позволяет получить доступ к локальным пулам ZFS (или файловым системам ZFS внутри таких пулов).
Данное хранилище поддерживает общие свойства (content, nodes, disable) хранилищ, кроме того, для настройки ZFS используются следующие свойства:
  • pool — пул/файловая система ZFS;
  • blocksize — размер блока;
  • sparse — использовать тонкое выделение ресурсов;
  • mountpoint — точка монтирования пула/файловой системы ZFS. Изменение этого параметра не влияет на свойство точки монтирования набора данных, видимого zfs. По умолчанию /<pool>.
Пул ZFS поддерживает следующие типы RAID:
  • RAID-0 (Single Disk) — размер такого пула — сумма емкостей всех дисков. RAID0 не добавляет избыточности, поэтому отказ одного диска делает том не пригодным для использования (минимально требуется один диск);
  • пул RAID-1 (Mirror) — данные зеркалируются на все диски (минимально требуется два диска);
  • пул RAID-10 — сочетание RAID0 и RAID1 (минимально требуется четыре диска);
  • пул RAIDZ-1 — вариация RAID-5, одинарная четность (минимально требуется три диска);
  • пул RAIDZ-2 — вариация на RAID-5, двойной паритет (минимально требуется четыре диска);
  • пул RAIDZ-3 — разновидность RAID-5, тройная четность (минимально требуется пять дисков).
Пример файла конфигурации (/etc/pve/storage.cfg):
zfspool: vmdata
    pool vmdata
    content images,rootdir
    mountpoint /vmdata
    nodes pve03
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw или subvol).
Используется следующая схема именования образов дисков ВМ:
  • vm-<VMID>-<NAME> — образ ВМ;
  • base-<VMID>-<NAME> — шаблон образа ВМ (только для чтения);
  • subvol-<VMID>-<NAME> — файловая система ZFS для контейнеров.

Примечание

Если в ВМ созданной в ZFS хранилище будет создан диск с LVM разделами, то гипервизор не позволит удалить этот диск. Пример ошибки:
cannot destroy 'data/vm-101-disk-0': dataset is busy
Чтобы избежать этой ситуации следует исключить ZFS-диски из области сканирования LVM, добавив в конфигурацию LVM (файл /etc/lvm/lvm.conf) в секцию devices{} строки:
# Do not scan ZFS zvols (to avoid problems on ZFS zvols snapshots)
filter = [ "r|^/dev/zd*|" ]
global_filter = [ "r|^/dev/zd*|" ]

39.4.8.1. Создание локального хранилища ZFS в веб-интерфейсе

Для создания локального хранилища ZFS в веб-интерфейсе, следует выбрать узел, на котором будет создано хранилище, в разделе Диски выбрать пункт ZFS и нажать кнопку Создать: ZFS:
Добавление ZFS хранилища
В открывшемся окне следует задать параметры ZFS хранилища: имя хранилища, выбрать диски, уровень RAID и нажать кнопку Создать:
Параметры ZFS хранилища
Статус пула можно просмотреть выбрав его в списке и нажав кнопку Подробно:
Локальное ZFS хранилище
Для того чтобы внести изменения в настройки ZFS хранилища, следует выбрать Центр обработки данныхХранилище, затем нужное хранилище и нажать кнопку Редактировать:
Выбор хранилища для редактирования
В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище, включить дисковое резервирование:
Редактирование ZFS хранилища

39.4.8.2. Администрирование ZFS

Основными командами для управления ZFS являются zfs и zpool.
Для создания нового пула необходим как минимум один пустой диск.
Создание нового пула RAID-0 (минимум 1 диск):
# zpool create -f -o ashift=12 <pool> <device1> <device2>
Создание нового пула RAID-1 (минимум 2 диска):
# zpool create -f -o ashift=12 <pool> mirror <device1> <device2>
Создание нового пула RAID-10 (минимум 4 диска):
# zpool create -f -o ashift=12 <pool> mirror <device1>
<device2> mirror <device3> <device4>
Создание нового пула RAIDZ-1 (минимум 3 диска):
# zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>
Создание нового пула RAIDZ-2 (минимум 4 диска):
# zpool create -f -o ashift=12 <pool> raidz2 <device1>
<device2> <device3> <device4>
Смена неисправного устройства:
# zpool replace -f <pool> <old device> <new device>
Включить сжатие:
# zfs set compression=on <pool>
Получить список доступных ZFS файловых систем:
# pvesm zfsscan
Пример создания RAID1(mirror) с помощью zfs:
# zpool create -f vmdata mirror sdb sdc
Просмотреть созданные в системе пулы:
# zpool list
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
vmdata  17,5G   492K  17,5G        -         -     0%     0%  1.00x    ONLINE  -
Просмотреть статус пула:
# zpool status
  pool: vmdata
 state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    vmdata      ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0

errors: No known data errors

39.4.9. LVM

LVM (Logical Volume Management) — это система управления дисковым пространством. Позволяет логически объединить несколько дисковых пространств (физические тома) в одно, и уже из этого пространства (дисковой группы или группы томов — VG), можно выделять разделы (логические тома — LV), доступные для работы.
Использование LVM групп обеспечивает лучшую управляемость. Логические тома можно легко создавать/удалять/перемещать между физическими устройствами хранения. Если база хранения для группы LVM доступна на всех PVE узлах (например, ISCSI LUN) или репликах (например, DRBD), то все узлы имеют доступ к образам ВМ, и возможна live-миграция.
Данное хранилище поддерживает общие свойства (content, nodes, disable) хранилищ, кроме того, для настройки LVM используются следующие свойства:
  • vgname — имя группы томов LVM (должно указывать на существующую группу томов);
  • base — базовый том. Этот том автоматически активируется перед доступом к хранилищу. Это особенно полезно, когда группа томов LVM находится на удаленном сервере iSCSI;
  • saferemove — обнуление данных при удалении LV (гарантирует, что при удалении тома все данные будут удалены);
  • saferemove_throughput — очистка пропускной способности (значение параметра cstream -t).
Пример файла конфигурации (/etc/pve/storage.cfg):
lvm: vg
    vgname vg
    content rootdir,images
    nodes pve03
    shared 0
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw).

39.4.9.1. Создание локального LVM хранилища в веб-интерфейсе

Примечание

Для создания локального LVM хранилища в веб-интерфейсе необходимо чтобы в системе имелся хотя бы один пустой жесткий диск.
Для создания локального LVM хранилища в веб-интерфейсе, следует выбрать узел, на котором будет создано хранилище, в разделе Диски выбрать пункт LVM и нажать кнопку Создать: Volume Group:
Пункт LVM в разделе Диски
В открывшемся окне следует выбрать диск, задать имя группы томов, отметить пункт Добавить хранилище (если этот пункт не отмечен будет создана только группа томов) и нажать кнопку Создать:
Создание группы томов
Для того чтобы внести изменения в настройки LVM хранилища, следует выбрать Центр обработки данныхХранилище, затем нужное хранилище и нажать кнопку Редактировать. В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище:
Редактирование LVM хранилища
Одним из преимуществ хранилища LVM является то, что его можно использовать поверх общего хранилища, например, iSCSI LUN. Сам бэкэнд реализует правильную блокировку на уровне кластера.
Добавление хранилища типа LVM (over iSCSI)

39.4.9.2. Создание хранилища LVM в командной строке

Пример создания LVM хранилища на пустом диске /dev/sdd:
  1. Создать физический том (PV):
    # pvcreate /dev/sdd
      Physical volume "/dev/sdd" successfully created.
    
  2. Создать группу томов (VG) с именем vg:
    # vgcreate vg /dev/sdd
      Volume group "vg" successfully created
    
  3. Показать информацию о физических томах:
    # pvs
      PV         VG        Fmt  Attr PSize   PFree
      /dev/sdd   vg        lvm2 a--  <18,00g <3,00g
    
  4. Показать информацию о группах томов:
    # vgs
      VG        #PV #LV #SN Attr   VSize   VFree
      vg          1   2   0 wz--n- <18,00g <3,00g
    
  5. Получить список доступных PVE групп томов:
    # pvesm lvmscan
    vg
    
  6. Создать LVM хранилище с именем myspace:
    # pvesm add lvm myspace --vgname vg --nodes pve03
    

39.4.10. LVM-Thin

LVM-Thin (thin provision) — это возможность использовать какое-либо внешнее блочное устройство в режиме только для чтения как основу для создания новых логических томов LVM. Такие разделы при создании уже будут выглядеть так, будто они заполнены данными исходного блочного устройства. Операции с томами изменяются налету таким образом, что чтение данных выполняется с исходного блочного устройства (или с тома, если данные уже отличаются), а запись — на том.
Такая возможность может быть полезна, например, при создании множества однотипных ВМ или для решения других аналогичных задач, т.е. задач, где нужно получить несколько изменяемых копий одних и тех же исходных данных.
Данное хранилище поддерживает все общие свойства хранилищ, кроме того, для настройки LVM-Thin используются следующие свойства:
  • vgname — имя группы томов LVM (должно указывать на существующую группу томов);
  • thinpool — название тонкого пула LVM.
Пример файла конфигурации (/etc/pve/storage.cfg):
lvmthin: vmstore
    thinpool vmstore
    vgname vmstore
    content rootdir,images
    nodes pve03
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw).
LVM-Thin является блочным хранилищем, но полностью поддерживает моментальные снимки и клоны. Новые тома автоматически инициализируются с нуля.
Тонкие пулы LVM не могут совместно использоваться несколькими узлами, поэтому их можно использовать только в качестве локального хранилища.

39.4.10.1. Создание локального LVM-Thin хранилища в веб-интерфейсе

Примечание

Для создания локального LVM-Thin хранилища в веб-интерфейсе необходимо, чтобы в системе имелся хотя бы один пустой жесткий диск.
Для создания локального LVM-Thin хранилища в веб-интерфейсе следует выбрать узел, на котором будет создано хранилище, в разделе Диски выбрать пункт LVM-Thin, и нажать кнопку Создать: Thinpool:
Пункт LVM-Thin в разделе Диски
В открывшемся окне следует выбрать диск, задать имя группы томов, отметить пункт Добавить хранилище (если этот пункт не отмечен будет создана только группа томов) и нажать кнопку Создать:
Создание LVM-Thin хранилища
Для того чтобы внести изменения в настройки LVM-Thin хранилища, следует выбрать Центр обработки данныхХранилище, затем нужное хранилище и нажать кнопку Редактировать. В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище:
Редактирование LVM-Thin хранилища

39.4.10.2. Создание хранилища LVM-Thin в командной строке

Для создания и управления пулами LVM-Thin можно использовать инструменты командной строки.
Пул LVM-Thin должен быть создан поверх группы томов.
Команда создания нового тонкого пула LVM (размер 80 ГБ) с именем vmstore (предполагается, что группа томов LVM с именем vg уже существует):
# lvcreate -L 80G -T -n vmstore vg
Получить список доступных LVM-Thin пулов в группе томов vg:
# pvesm lvmthinscan vg
vmstore
Команда создания LVM-Thin хранилища с именем vmstore на узле pve03:
# pvesm add lvmthin vmstore --thinpool vmstore --vgname vg --nodes pve03

39.4.11. iSCSI

iSCSI (Internet Small Computer System Interface) — широко применяемая технология, используемая для подключения к серверам хранения.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • portal — IP-адрес или DNS-имя сервера iSCSI;
  • target — цель iSCSI.
Пример файла конфигурации (/etc/pve/storage.cfg):
iscsi: test1-iSCSI
    portal 192.168.0.105
    target iqn.2021-7.local.omv:test
    content images
Возможные типы содержимого: images (образ виртуального диска в формате raw).
iSCSI является типом хранилища блочного уровня и не предоставляет интерфейса управления. Поэтому обычно лучше экспортировать один большой LUN и установить LVM поверх этого LUN.

Примечание

Если планируется использовать LVM поверх iSCSI, имеет смысл установить:
content none
В этом случае нельзя будет создавать ВМ с использованием iSCSI LUN напрямую.

Примечание

Для работы с устройством, подключенным по интерфейсу iSCSI, на всех узлах необходимо выполнить команду (должен быть установлен пакет open-iscsi):
# systemctl enable --now iscsid
Добавление адресата iSCSI с именем test1-iSCSI, который настроен на удаленном узле 192.168.0.105:
Добавление хранилища типа iSCSI
Параметр Использовать LUN напрямую — разрешение/запрет прямого применения LUN (параметр должен быть установлен на запрет, разрешение может привести к потере данных).
Посмотреть доступные для подключения iSCSI цели:
# pvesm scan iscsi <IP-адрес сервера[:порт]>>
Команда создания хранилища iSCSI:
# pvesm add iscsi <ID> --portal <Сервер iSCSI> --target <Цель iSCSI> --content none

39.4.12. iSCSI/libiscsi

Это хранилище обеспечивает в основном ту же функциональность, что и iSCSI, но использует библиотеку пользовательского уровня. Так как при этом не задействованы драйверы ядра, то это можно рассматривать как оптимизацию производительности. Но поверх такого iSCSI LUN нельзя использовать LVM (управлять распределением пространства необходимо на стороне сервера хранения).

Примечание

Для использования этого хранилища должен быть установлен пакет libiscsi.
Данное хранилище поддерживает все свойства хранилища iscsi.
Пример файла конфигурации (/etc/pve/storage.cfg):
iscsidirect: test1-iSCSi
    portal 192.168.0.191
    target dc1.test.alt:server.target
Возможные типы содержимого: images (образ виртуального диска в формате raw).

39.4.13. Ceph RBD

Хранилище RBD (Rados Block Device) предоставляется распределенной системой хранения Ceph. По своей архитектуре Ceph является распределенной системой хранения. Хранилище RBD может содержать только форматы образов .raw.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • monhost — список IP-адресов демона монитора (только если Ceph не работает на кластере PVE);
  • pool — название пула Ceph (rbd);
  • username — идентификатор пользователя Ceph (только если Ceph не работает на кластере PVE);
  • krbd (опционально) — обеспечивает доступ к блочным устройствам rados через модуль ядра krbd.

Примечание

Контейнеры будут использовать krbd независимо от значения параметра krbd.
Пример файла конфигурации (/etc/pve/storage.cfg):
rbd: new
    content images
    krbd 0
    monhost 192.168.0.105
    pool rbd
    username admin
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw).
Добавление хранилища RBD:
Добавление хранилища типа RBD
Если используется аутентификация cephx (включена по умолчанию), необходимо предоставить связку ключей из внешнего кластера Ceph.
При настройке хранилища в командной строке, предварительно следует сделать доступным файл, содержащий связку ключей. Один из способов — скопировать файл из внешнего кластера Ceph непосредственно на один из узлов PVE. Например, скопировать файл в каталог /root узла:
# scp <external cephserver>:/etc/ceph/ceph.client.admin.keyring /root/rbd.keyring
Команда настройки внешнего хранилища RBD:
# pvesm add rbd <name> --monhost "10.1.1.20 10.1.1.21 10.1.1.22" --content images --keyring /root/rbd.keyring
При настройке внешнего хранилища RBD в графическом интерфейсе, связку ключей можно указать в поле Keyring.
Связка ключей будет храниться в файле /etc/pve/priv/ceph/<STORAGE_ID>.keyring.
Пример добавления хранилища RBD, используещего пул Ceph под управлением PVE (см. Кластер Ceph):
Добавление хранилища типа RBD
Связка ключей в этом случае будет скопирована автоматически.

39.4.14. CephFS

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

Примечание

PVE может управлять настройками Ceph (см. Кластер Ceph), что упрощает настройку хра-нилища CephFS. Поскольку современное оборудование предлагает большую вычислительную мощность и оперативную память, запуск служб хранения и ВМ на одном узле возможен без существенного влияния на производительность.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • monhost — список IP-адресов демона монитора (только если Ceph не работает на кластере PVE);
  • path — локальная точка монтирования (по умолчанию используется /mnt/pve/<STORAGE_ID>/);
  • username — идентификатор пользователя (только если Ceph не работает на кластере PVE);
  • subdir — подкаталог CephFS для монтирования (по умолчанию /);
  • fuse — доступ к CephFS через FUSE (по умолчанию 0).
Пример файла конфигурации (/etc/pve/storage.cfg):
cephfs: cephfs-external
    content backup
    monhost 192.168.0.105
    path /mnt/pve/cephfs-external
    username admin
Возможные типы содержимого: vztmpl (шаблон контейнера), iso (ISO-образ), backup (резервная копия), фрагменты (сниппеты).
Добавление хранилища CephFS:
Добавление хранилища CephFS

Примечание

Получить список доступных cephfs, для указания в поле Имя ФС, можно с помощью команды:
# ceph fs ls
Если используется аутентификация cephx (включена по умолчанию), необходимо указать ключ из внешнего кластера Ceph.
При настройке хранилища в командной строке, предварительно сделать файл с ключом доступным. Один из способов — скопировать файл из внешнего кластера Ceph непосредственно на один из узлов PVE. Например, скопировать файл в каталог /root узла:
# scp <external cephserver>:/etc/ceph/cephfs.secret /root/cephfs.secret
Команда настройки внешнего хранилища CephFS:
# pvesm add cephfs <name> --monhost "10.1.1.20 10.1.1.21 10.1.1.22" --content backup --keyring /root/cephfs.secret
При настройке внешнего хранилища CephFS в графическом интерфейсе, ключ можно указать в поле Секретный ключ.
Ключ будет храниться в файле /etc/pve/priv/ceph/<STORAGE_ID>.secret.
Ключ можно получить из кластера Ceph (как администратор Ceph), выполнив команду:
# ceph auth get-key client.userid > cephfs.secret

39.4.15. Proxmox Backup Server

Proxmox Backup Server — позволяет напрямую интегрировать сервер резервного копирования Proxmox в PVE.
Данное хранилище поддерживает только резервные копии, они могут быть на уровне блоков (для ВМ) или на уровне файлов (для контейнеров).
Серверная часть поддерживает все общие свойства хранилищ, кроме флага «общее» («shared»), который всегда установлен. Кроме того, для Proxmox Backup Server доступны следующие специальные свойства:
  • server — IP-адрес или DNS-имя сервера резервного копирования;
  • username — имя пользователя на сервере резервного копирования (например, root@pam, backup_u@pbs);
  • password — пароль пользователя. Значение будет сохранено в файле /etc/pve/priv/storage/<STORAGE-ID>.pw, доступном только суперпользователю;
  • datastore — идентификатор хранилища на сервере резервного копирования;
  • fingerprint — отпечаток TLS-сертификата API Proxmox Backup Server. Требуется, если сервер резервного копирования использует самоподписанный сертификат. Отпечаток можно получить в веб-интерфейсе сервера резервного копирования или с помощью команды proxmox-backup-manager cert info;
  • encryption-key — ключ для шифрования резервной копии. В настоящее время поддерживаются только те файлы, которые не защищены паролем (без функции получения ключа (kdf)). Ключ будет сохранен в файле /etc/pve/priv/storage/<STORAGE-ID>.enc, доступном только суперпользователю. Опционально;
  • master-pubkey — открытый ключ RSA, используемый для шифрования копии ключа шифрования (encryption-key) в рамках задачи резервного копирования. Зашифрованная копия будет добавлена к резервной копии и сохранена на сервере резервного копирования для целей восстановления. Опционально, требуется encryption-key.
Пример файла конфигурации (/etc/pve/storage.cfg):
pbs: pbs_backup
    datastore store2
    server 192.168.0.123
    content backup
    fingerprint 42:5d:29:20:…:d1:be:bc:c0:c0:a9:9b:b1:a8:1b
    prune-backups keep-all=1
    username root@pam

39.4.15.1. Подключение хранилища

Подключение хранилища Proxmox Backup Server с именем pbs_backup с удаленного сервера 192.168.0.123:
Добавление хранилища Proxmox Backup Server
Добавление хранилища Proxmox Backup Server в командной строке:
# pvesm add pbs pbs_backup --server 192.168.0.123 --datastore store2 --username root@pam --fingerprint 42:5d:29:20:…:d1:be:bc:c0:c0:a9:9b:b1:a8:1b --password

39.4.15.2. Шифрование

На стороне клиента можно настроить шифрование с помощью AES-256 в режиме GCM. Шифрование можно настроить либо в командной строке с помощью опции encryption-key, либо через веб-интерфейс:
Сгенерировать клиентский ключ шифрования
Необходимо сохранить ключ шифрования:
Сохранить клиентский ключ шифрования
Шифрование настроено:
Используется клиентское шифрование
Ключ будет сохранен в файле /etc/pve/priv/storage/<STORAGE-ID>.enc, который доступен только пользователю root.

Примечание

Для работы с ключами в командной строке используется команда proxmox-backup-client key. Например, сгенерировать ключ:
# proxmox-backup-client key create --kdf none <path>
Сгенерировать мастер-ключ:
# proxmox-backup-client key create-master-key

Важно

Без ключа шифрования резервные копии будут недоступны. Следует хранить ключи в надежном месте, отдельном от содержимого резервной копии.
Рекомендуется хранить ключ в безопасносном, но при этом легкодоступном месте, чтобы можно было быстро восстановить его после сбоев. Лучшее место для хранения ключа шифрования — менеджер паролей. В качестве резервной копии также следует сохранить ключ на USB-накопитель. Таким образом, ключ будет отсоединен от системы, но его по-прежнему легко можно будет восстановить в случае возникновения чрезвычайной ситуации.
Кроме того, можно использовать пару мастер-ключей RSA для целей восстановления ключей: для этого необходимо настроить всех клиентов, выполняющих зашифрованное резервное копирование, на использование одного открытого мастер-ключа, и все последующие зашифрованные резервные копии будут содержать зашифрованную RSA копию использованного ключа шифрования AES. Соответствующий закрытый мастер-ключ позволяет восстановить ключ AES и расшифровать резервную копию, даже если клиентская система больше не доступна.

Важно

К паре мастер-ключей применяются те же правила хранения, что и к обычным ключам шифрования. Без копии закрытого ключа восстановление невозможно!

Примечание

Не следует использовать шифрование, если от него нет никакой пользы, например, если сервер запущен локально в доверенной сети. Восстановить данные из незашифрованных резервных копий всегда проще.

39.5. FC/iSCSI SAN

Данная конфигурация предполагает, что узлы кластера имеют доступ к устройствам хранения (LUN), экспортированным сервером сети хранения данных (SAN) с использованием протоко-ла iSCSI или Fibre Channel (FC).
Соединение узла PVE к хранилищу называется путем. Если в подсистеме хранения данных существует несколько путей к устройству хранения данных (LUN), это называется многопутевым подключением (multipath). Необходимо использовать как минимум два выделенных сетевых адаптера для iSCSI/FC, использующих отдельные сети (и коммутаторы для защиты от сбоев коммутатора).
Основная цель многопутевого подключения (multipath) — обеспечить резервный доступ к устройству хранения данных. Еще одним преимуществом многопутевого доступа является увеличение пропускной способности за счет балансировки нагрузки. Типичным примером использования нескольких путей является добавление избыточности и получение максимальной производительности от устройства FC/iSCSI SAN.

Примечание

В данном разделе приведена общая информация. Для получения информации о настройках конкретной СХД следует обратиться к документации производителя хранилища.

39.5.1. Подключение СХД

39.5.1.1. Особенности подключения СХД по FC

Алгоритм подключения:
  1. Подготовить СХД (создать LUNы).
  2. На сервере установить FC HBA, драйверы к ним.
  3. Настроить сетевое подключение.
  4. Подключить СХД к серверу.
  5. Предоставить серверу доступ к СХД по WWPN.

Примечание

Для того чтобы узнать глобальные имена портов (WWPN), можно воспользоваться утилитой systool из пакета sysfsutils.
Пакет sysfsutils необходимо установить из репозитория:
# apt-get install sysfsutils
Чтобы найти WWPN, следует ввести следующую команду:
# systool -c fc_host -A port_name
Class = "fc_host"
Class Device = "host1"
port_name = "0x10000090fa59a61a"
Device = "host1"
Class Device = "host16"
port_name = "0x10000090fa59a61b"
Device = "host16"
Просмотреть список подключенных устройств можно, например, выполнив команду:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 59G 0 disk
sdb 8:16 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sdc 8:32 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sdd 8:48 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sde 8:64 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
В данном примере один LUN на 1000GB виден по четырем путям.

39.5.1.2. Особенности подключения СХД по ISCSI

Все необходимые соединения iSCSI должны запускаться во время загрузки узла. Сделать это можно, установив для параметра node.startup значение automatic. Значение по умолчанию для параметра node.session.timeo.replacement_timeout составляет 120 секунд. Рекомендуется использовать значение — 15 секунд.
Эти параметры можно указать в файле в /etc/iscsi/iscsid.conf (по умолчанию). Если iSCSI target уже подключен, то необходимо изменить настройки по умолчанию для конкретной цели в файле /etc/iscsi/nodes/<TARGET>/<PORTAL>/default.
На всех узлах PVE необходимо:
  1. Установить пакет open-iscsi, запустить и добавить в автозагрузку сервис iscsid:
    # apt-get install open-iscsi
    # systemctl enable --now iscsid
    
  2. Указать следующие параметры в файле /etc/iscsi/iscsid.conf:
    node.startup = automatic
    node.session.timeo.replacement_timeout = 15
    
  3. Присоединить iSCSI хранилище к кластеру:
    # iscsiadm -m discovery -t sendtargets -p <iscsi-target-1-ip>
    # iscsiadm -m discovery -t sendtargets -p <iscsi-target-2-ip>
    # iscsiadm -m node --login
    
  4. Настроить автоматическое подключение iSCSI-target-ов. Для этого необходимо поменять следующие параметры:
    • в файле /etc/iscsi/iscsid.conf:
      node.startup = automatic
    • в файлах /var/lib/iscsi/send_targets/<TargetServer>,<Port>/st_config:
      discovery.sendtargets.use_discoveryd = Yes
      
  5. После перезагрузки должны появиться подключенные устройства:
    # lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
    sda 8:0 0 59G 0 disk
    sdb 8:16 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sdc 8:32 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sdd 8:48 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sde 8:64 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    
    В данном примере один LUN на 1000GB виден по четырем путям.

Примечание

Примеры использования команды iscsiadm:
  • отключить хранилище (отключить все цели):
    # iscsiadm -m node --logout
    
  • отключить только определенную цель:
    # iscsiadm -m node --targetname "iscsi-target-1.test.alt:server.target1" --logout
    
  • переопросить устройства на ISCSI:
    # iscsiadm -m node -R
    
  • посмотреть все текущие подключения iSCSI:
    # iscsiadm -m session
    

39.5.2. Настройка Multipath

Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов СХД с использованием нескольких маршрутов. В случае отказа одного из контроллеров, ОС будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.
Multipath устройства объединяются в одно устройство с помощью специализированного ПО в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Кроме того Multipath позволяет увеличить пропускную способность за счет балансировки нагрузки.
На всех узлах должен быть установлен пакет для multipath:
# apt-get install multipath-tools
И запущена служба multipathd:
# systemctl enable --now multipathd && sleep 5; systemctl status multipathd

39.5.2.1. Конфигурация multipath

Примечание

Команда multipath используется для обнаружения и объединения нескольких путей к устройствам.
Некоторые параметры команды multipath:
  • -l — отобразить текущую multipath-топологию, полученную из sysfs и устройства сопоставления устройств;
  • -ll — отобразить текущую multipath-топологию, собранную из sysfs, устройства сопоставления устройств и всех других доступных компонентов системы;
  • -f device — удалить указанное multipath-устройство;
  • -F — удалить все неиспользуемые multipath-устройства;
  • -w device — удалить WWID указанного устройства из файла wwids;
  • -W — сбросить файл wwids, чтобы включить только текущие многопутевые устройства;
  • -r — принудительная перезагрузка multipath-устройства.
После подключения, устройство хранения данных должно автоматически определиться как multipath-устройство:
# multipath -ll
mpatha (3600c0ff00014f56ee9f3cf6301000000) dm-0 HP,P2000 G3 FC
size=931G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:1 sdb 8:16 active ready running
| `- 16:0:1:1 sde 8:64 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 1:0:1:1 sdc 8:32 active ready running
`- 16:0:0:1 sdd 8:48 active ready running
Вывод этой команды разделить на три части:
  • Информация о multipath-устройстве:
    • mpatha (3600c0ff00014f56ee9f3cf6301000000): алиас
    • dm-0: имя устройства dm
    • HP,P2000 G3 FC: поставщик, продукт
    • size=931G: размер
    • features='1 queue_if_no_path': функции
    • hwhandler='01 alua': аппаратный обработчик
    • wp=rw: права на запись
  • Информация о группе путей:
    • policy='service-time 0': политика планирования
    • prio=50: приоритет группы путей
    • status=active: статус группы путей
  • Информация о пути:
    • 7:0:1:1: хост:канал:идентификатор:Lun
    • sde: диск
    • 8:80: номера major:minor
    • active: статус dm
    • ready: статус пути
    • running: online статус
Для получения дополнительной информации об используемых устройствах можно выполнить команду:
# multipath -v3
Настройки multipath содержатся в файле /etc/multipath.conf:
defaults {
    find_multipaths         yes
    user_friendly_names     yes
}
Если для параметра user_friendly_names установлено значение no, то для имени multipath-устройства задается значение World Wide Identifier (WWID). Имя устройства будет /dev/mapper/WWID и /dev/dm-X:
# ls /dev/mapper/
3600c0ff00014f56ee9f3cf6301000000

# lsblk
NAME                                        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                           8:0    0    59G  0 disk
sdb                                           8:16   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sdc                                           8:32   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sdd                                           8:48   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sde                                           8:64   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
Если для параметра user_friendly_names установлено значение yes, то для имени multipath-устройства задаётся алиас (псевдоним), в форме mpathХ. Имя устройства будет /dev/mapper/mpathХ и /dev/dm-X:
# ls /dev/mapper/
mpatha

# lsblk
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                8:0    0    59G  0 disk
sdb                8:16   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sdc                8:32   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sdd                8:48   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sde                8:64   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
Однако не гарантируется, что имя устройства будет одинаковым на всех узлах, использующих это multipath-устройство.
ОС при загрузке определяет пути к устройствам в изменяющейся среде выполнения (например, при новой загрузке в среде выполнения ОС появились новые устройства хранения или исчезли старые, и т.п.) по отношению к предыдущей загрузке или по отношению к заданной ранее конфигурации. Это может приводить к противоречиям при именовании устройств. Для того чтобы избежать такого поведения, рекомендуется:
  • Сделать явное исключение для устройства (раздела) хранения (например, для 3600c0ff00014f56ee9f3cf6301000000, которое в настоящее время определяется как /dev/mapper/mpatha). Для этого в файл /etc/multipath.conf добавить секции:
    blacklist {
            wwid .*
    }
    
    blacklist_exceptions {
            wwid "3600c0ff00014f56ee9f3cf6301000000"
    }
    
    Данная настройка предписывается внести в черный список любые найденные устройства хранения данных, за исключением нужного.
  • Создать еще одну секцию:
    multipaths {
      multipath {
            wwid "3600c0ff00014f56ee9f3cf6301000000"
            alias mpatha
      }
    }
    
    В этом случае устройство всегда будет доступно только по имени /dev/mapper/mpatha. Вместо mpatha можно вписать любое желаемое имя устройства.

Примечание

Получить WWID конкретного устройства можно, выполнив команду:
# /lib/udev/scsi_id -g -u -d /dev/sdb
3600c0ff00014f56ee9f3cf6301000000
Для устройств в одном multipath WWID будут совпадать.
В файл /etc/multipath.conf может также потребоваться внести рекомендованные производителем СХД параметры.
После внесения изменений в файл /etc/multipath.conf необходимо перезапустить службу multipathd для активации настроек:
# systemctl restart multipathd.service

Примечание

Проверить файл /etc/multipath.conf на наличие ошибок можно, выполнив команду:
# multipath -t

39.5.3. Multipath в веб-интерфейсе PVE

Диски, подключенные по mulipath, можно увидеть в веб-интерфейсе PVE:
Multipath в веб-интерфейсе PVE
Поверх хранилища на базе iSCSI или FC можно использовать LVM или хранилище файлового типа (если нужны снапшоты).

39.5.4. Файловые системы на multipath

На multipath-устройстве можно создать файловую систему (ФС) и подключить его как хранилище типа «Каталог» в PVE. Можно использовать любую ФС, но при использовании, например, ext4 или xfs, хранилище нельзя будет использовать как общее. Для возможности совместного использования хранилища необходимо использовать кластерную ФС.
Ниже показано создание кластерной ФС ocfs2 на multipath-устройстве и подключение этого устройства в PVE.

39.5.4.1. Кластерная ФС ocfs2

На всех узлах кластера необходимо установить пакет ocfs2-tools:
# apt-get install ocfs2-tools

Примечание

Основной конфигурационный файл для OCFS2 — /etc/ocfs2/cluster.conf. Этот файл должен быть одинаков на всех узлах кластера, при изменении в одном месте его нужно скопировать на остальные узлы. При добавлении нового узла в кластер, описание этого узла должно добавлено быть на всех остальных узлах до монтирования раздела ocfs2 с нового узла.
Создание кластерной конфигурации возможно с помощью команд или с помощью редактирования файла конфигурации /etc/ocfs2/cluster.conf.
Пример создания кластера из трёх узлов:
  • В командной строке:
    • Создать кластер с именем mycluster:
      # o2cb_ctl -C -n mycluster -t cluster -a name=mycluster
      
    • Добавить узелы, выполнив команду для каждого:
      # o2cb_ctl -C -n <имя_узла> -t node -a number=0 -a ip_address=<IP_узла> -a ip_port=7777 -a cluster=mycluster
      
  • Редактирование конфигурационного файла /etc/ocfs2/cluster.conf:
    cluster:
    node_count = 3
    heartbeat_mode = local
    name = mycluster
    
    node:
    ip_port = 7777
    ip_address = <IP_узла-01>
    number = 0
    name = <имя_узла-01>
    cluster = mycluster
    
    node:
    ip_port = 7777
    ip_address = <IP_узла-02>
    number = 1
    name = <имя_узла-02>
    cluster = mycluster
    
    node:
    ip_port = 7777
    ip_address = <IP_узла-03>
    number = 2
    name = <имя_узла-03>
    cluster = mycluster
    

Примечание

Имя узла кластера должно быть таким, как оно указано в файле /etc/hostname.
Для включения автоматической загрузки сервиса OCFS2 можно использовать скрипт /etc/init.d/o2cb:
# /etc/init.d/o2cb configure
Для ручного запуска кластера нужно выполнить:
# /etc/init.d/o2cb load
checking debugfs...
Loading filesystem "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
# /etc/init.d/o2cb online mycluster
checking debugfs...
Setting cluster stack "o2cb": OK
Registering O2CB cluster "mycluster": OK
Setting O2CB cluster timeouts : OK
Далее на одном из узлов необходимо создать раздел OCFS2, для этого следует выполнить следующие действия:
  • создать физический раздел /dev/mapper/mpatha-part1 на диске /dev/mapper/mpatha:
    # fdisk /dev/mapper/mpatha
    
  • отформатировать созданный раздел, выполнив команду:
    # mkfs.ocfs2 -b 4096 -C 4k -L DBF1 -N 3 /dev/mapper/mpatha-part1
    mkfs.ocfs2 1.8.7
    Cluster stack: classic o2cb
    Label: DBF1
    …
    mkfs.ocfs2 successful
    

Таблица 39.4. Параметры команды mkfs.ocfs2

Параметр
Описание
-L метка_тома
Метка тома, позволяющая его однозначно идентифицировать при подключении на разных узлах. Для изменения метки тома можно использовать утилиту tunefs.ocfs2
-C размер_кластера
Размер кластера — это наименьшая единица пространства, выделенная файлу для хранения данных. Возможные значения: 4, 8, 16, 32, 64, 128, 256, 512 и 1024 КБ. Размер кластера невозможно изменить после форматирования тома
-N количество_узлов_кластера
Максимальное количество узлов, которые могут одновременно монтировать том. Для изменения количества узлов можно использовать утилиту tunefs.ocfs2
-b размер_блока
Наименьшая единица пространства, адресуемая ФС. Возможные значения: 512 байт (не рекомендуется), 1 КБ, 2 КБ или 4 КБ (рекомендуется для большинства томов). Размер блока невозможно изменить после форматирования тома

Примечание

Для создания нового раздела может потребоваться предварительно удалить существующие данные раздела на устройстве /dev/mpathX (следует использовать с осторожностью!):
# dd if=/dev/zero of=/dev/mapper/mpathX bs=512 count=1 conv=notrunc

39.5.4.2. OCFS2 в PVE

На каждом узле PVE необходимо смонтировать раздел (например, в /mnt/ocfs2):
# mkdir /mnt/ocfs2
# mount /dev/mapper/mpatha-part1 /mnt/ocfs2
Для автоматического монтирования раздела следует добавить в файл /etc/fstab строку (каталог /mnt/ocfs2 должен существовать):
/dev/mapper/mpatha-part1 /mnt/ocfs2 ocfs2 _netdev,defaults 0 0
Выполнить проверку монтирования:
# mount -a
Результатом выполнения команды должен быть пустой вывод без ошибок.

Примечание

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

Примечание

Так как имя является символической ссылкой, в некоторых случаях (например, при смене порядка опроса устройств на шине ISCSI) она может меняться (указывая на иное устройство). Поэтому если для устройства хранения не используется алиас, рекомендуется производить автоматическое монтирование этого устройства (раздела) в файле /etc/fstab по его уникальному идентификатору, а не по имени /dev/mapper/mpatha:
UUID=<uuid> /<каталог> ocfs2 _netdev,defaults 0 0
Например, определить UUID uuid разделов:
# blkid
/dev/mapper/mpatha-part1: LABEL="DBF1" UUID="df49216a-a835-47c6-b7c1-6962e9b7dcb6" BLOCK_SIZE="4096" TYPE="ocfs2" PARTUUID="15f9cd13-01"
Добавить монтирование этого UUID в /etc/fstab:
UUID=df49216a-a835-47c6-b7c1-6962e9b7dcb6       /mnt/ocfs2     ocfs2 _netdev,defaults 0 0
Созданный раздел можно добавить как хранилище в командной строке:
# pvesm add dir mpath --path /mnt/ocfs2 --shared 1
или в веб-интерфейсе PVE (Центр обработки данныхХранилище, нажать кнопку ДобавитьКаталог):
Добавление multipath-устройства

39.5.5. LVM/LVM-Thin хранилища на multipath

Примечание

multipath-устройство не отображается в веб-интерфейсе PVE LVM/LVM-Thin, поэтому потребуется использовать CLI.

Примечание

LVM при запуске сканирует все устройства на предмет поиска конфигурации LVM, и если настроен multipath-доступ, он найдет конфигурацию LVM как на (виртуальных) multipath-устройствах, так и на базовых (физических) дисках. Поэтому рекомендуется создать фильтр LVM для фильтрации физических дисков и разрешить LVM сканировать только multipath-устройства.
Сделать это можно, добавив фильтр в раздел device в файле /etc/lvm/lvm.conf, например:
filter = [ "a|/dev/mapper/|", "a|/dev/sda.*|", "r|.*|" ]
В данном примере принимаются только multipath-устройства и /dev/sda.*, все остальные устройства отклоняются:
  • a|/dev/mapper/| — принять устройства /dev/mapper;
  • a|/dev/sda.*| — принять устройство /dev/sda;
  • r|.*| — отклонить все остальные устройства.
Пример создания LVM на multipath:
  1. Вывести список разделов /dev/mapper/mpatha:
    # fdisk -l /dev/mapper/mpatha
    Disk /dev/mapper/mpatha: 931.32 GiB, 999999995904 bytes, 1953124992 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 1048576 bytes
    Disklabel type: dos
    Disk identifier: 0x2221951e
    
    Device Boot Start End Sectors Size Id Type
    /dev/mapper/mpatha-part1 2048 1953124991 1953122944 931.3G 83 Linux
    
  2. Создать физический том (PV) на /dev/mapper/mpatha-part1:
    # pvcreate /dev/mapper/mpatha-part1
    Physical volume "/dev/mapper/mpatha-part1" successfully created.
    
  3. Создать группу томов (VG) с именем VG1:
    # vgcreate VG1 /dev/mapper/mpatha-part1
    Volume group "VG1" successfully created
    
  4. Вывести информацию о физических томах:
    # pvs
    PV                       VG  Fmt  Attr PSize   PFree
    /dev/mapper/mpatha-part1 VG1 lvm2 a--  931.32g 931.32g
    

39.5.5.1. LVM-хранилище

Получить список доступных PVE групп томов:
# pvesm lvmscan
VG1
Список доступных PVE групп томов можно также увидеть в веб-интерфейсе:
Список LVM томов
Пример создания LVM хранилища с именем mpath-lvm:
# pvesm add lvm mpath-lvm --vgname VG1 --content images,rootdir
Пример создания LVM хранилища в веб-интерфейсе (Центр обработки данныхХранилище, нажать кнопку ДобавитьLVM):
LVM хранилище на multipath

39.5.5.2. LVM-Thin хранилище

Создать тонкий пул LVM на multipath:
  1. Вывести информацию о физических томах:
    # pvs
      PV                       VG  Fmt  Attr PSize   PFree
      /dev/mapper/mpatha-part1 VG1 lvm2 a--  931.32g 931.32g
    
  2. Вывести информацию о группах томов:
    # vgs
      VG  #PV #LV #SN Attr   VSize   VFree
      VG1   1   0   0 wz--n- 931.32g 931.32g
    
  3. Создать тонкий пул LVM (размер 100 ГБ) с именем vmstore:
    # lvcreate -L 100G -T -n vmstore VG1
    Logical volume "vmstore" created.
    
Получить список доступных PVE LVM-thin пулов в группе томов VG1:
# pvesm lvmthinscan VG1
vmstore
Список доступных PVE LVM-thin пулов можно также увидеть в веб-интерфейсе:
Список LVM-thin пулов
Пример создания LVM-Thin хранилища с именем mpath-lvmthin:
# pvesm add lvmthin mpath-lvmthin --thinpool vmstore --vgname VG1 --nodes pve01
Пример создания LVM-Thin хранилища в веб-интерфейсе (Центр обработки данныхХранилище, нажать кнопку ДобавитьLVM-Thin):
LVM хранилище на multipath

39.5.6. Изменение размера multipath-устройства

Для изменения размера multipath-устройства необходимо:
  • Изменить размер физического устройства;
  • Определить пути к номеру логического устройства (LUN):
    # multipath -l
    mpatha (3600c0ff00014f56ee9f3cf6301000000) dm-0 HP,P2000 G3 FC
    size=465G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
    |-+- policy='service-time 0' prio=0 status=active
    | |- 1:0:1:1  sdc 8:32 active undef running
    | `- 16:0:1:1 sde 8:64 active undef running
    `-+- policy='service-time 0' prio=0 status=enabled
    |- 1:0:0:1  sdb 8:16 active undef running
    `- 16:0:0:1 sdd 8:48 active undef running
    
  • Изменить размер путей, выполнив команду:
    # echo 1 > /sys/block/<path_device>/device/rescan
    
    Данную команду необходимо выполнить для каждого диска, входящего в multipath-устройство:
    # echo 1 > /sys/block/sdb/device/rescan
    # echo 1 > /sys/block/sdc/device/rescan
    # echo 1 > /sys/block/sdd/device/rescan
    # echo 1 > /sys/block/sde/device/rescan
    
  • Убедиться, что ядро увидело новый размер, выполнив команду:
    # dmesg -wHT
    
    Новый размер диска в выводе команды dmesg
  • Изменить размер multipath-устройства:
    # multipathd -k"resize map 3600c0ff00014f56ee9f3cf6301000000"
    
    где 3600c0ff00014f56ee9f3cf6301000000 — WWID multipath-устройства;
  • Изменить размер блочного устройства (если используется LVM):
    # pvresize /dev/mapper/mpatha
    
  • Изменить размер файловой системы (если разделы LVM или DOS не используются):
    # resize2fs /dev/mapper/mpatha
    

Примечание

Данную процедуру следует выполнить на каждом узле, к которому присоединён этот LUN.

39.6. Кластер Ceph

PVE позволяет использовать одни и те же физические узлы в кластере как для вычислений (обработка виртуальных машин и контейнеров), так и для реплицированного хранилища.
Ceph — программная объектная отказоустойчивая сеть хранения данных. Она реализует возможность файлового и блочного доступа к данным. Ceph интегрирован в PVE, поэтому запускать и управлять хранилищем Ceph можно непосредственно на узлах гипервизора.
Некоторые преимущества Ceph на PVE:
  • простая настройка и управление через веб-интерфейс и командную строку;
  • тонкое резервирование;
  • поддержка моментальных снимков;
  • самовосстановление;
  • масштабируемость до уровня эксабайт;
  • настройка пулов с различными характеристиками производительности и избыточности;
  • данные реплицируются, что делает их отказоустойчивыми;
  • работает на стандартном оборудовании;
  • нет необходимости в аппаратных RAID-контроллерах;
  • открытый исходный код.
pveceph — инструмент для установки и управления службами Ceph на узлах PVE.
Кластерная система хранения данных Ceph состоит из нескольких демонов:
  • монитор Ceph (ceph-mon) — хранит информацию о состоянии работоспособности кластера, карту всех узлов и правила распределения данных (карту CRUSH). Мониторы также отвечают за управление аутентификацией между демонами и клиентами. Обычно для обеспечения резервирования и высокой доступности требуется не менее трех мониторов;
  • менеджер Ceph (ceph-mgr) — собирает информацию о состоянии со всего кластера. Менеджер Ceph работает вместе с демонами монитора. Он обеспечивает дополнительный мониторинг и взаимодействует с внешними системами мониторинга и управления. Он также включает другие службы. Для обеспечения высокой доступности обычно требуется по крайней мере два менеджера;
  • OSD Ceph (ceph-osd; демон хранилища объектов) — демон, управляющий устройствами хранения объектов, которые представляют собой физические или логические единицы хранения (жесткие диски или разделы). Демон дополнительно отвечает за репликацию данных и перебалансировку в случае добавления или удаления узлов. Демоны Ceph OSD взаимодействуют с демонами монитора и предоставляют им состояние других демонов OSD. OSD являются основными демонами кластера, на которые ложится большая часть нагрузки. Для обеспечения резервирования и высокой доступности обычно требуется не менее трех OSD Ceph;
  • Сервер метаданных Ceph (Metadata Server) — хранит метаданные файловой системы CephFS (блочные устройства Ceph и хранилище объектов Ceph не используют MDS). Разделение метаданных от данных значительно увеличивает производительность кластера. Серверы метаданных Ceph позволяют пользователям файловой системы POSIX выполнять базовые команды (такие как ls, find и т.д.), не создавая огромной нагрузки на кластер хранения Ceph.

39.6.1. Системные требования

Чтобы построить гиперконвергентный кластер PVE + Ceph, необходимо использовать не менее трех (предпочтительно) идентичных серверов для настройки.
Требования к оборудованию для Ceph могут варьироваться в зависимости от размера кластера, ожидаемой нагрузки и других факторов.

Таблица 39.5. Системные требования к оборудованию для Ceph

Процесс
Критерий
Требования
Монитор Ceph
Процессор
2 ядра минимум, 4 рекомендуется
ОЗУ
5ГБ+ (большим/производственным кластерам нужно больше)
Жёсткий диск
100 ГБ на демон, рекомендуется SSD
Сеть
1 Гбит/с (рекомендуется 10+ Гбит/с)
Менеджер Ceph
Процессор
1 ядро
ОЗУ
1 ГБ
OSD Ceph
Процессор
  • 1 ядро минимум, 2 рекомендуется
  • 1 ядро на пропускную способность 200-500 МБ/с
  • 1 ядро на 1000-3000 IOPS
  • SSD OSD, особенно NVMe, выиграют от дополнительных ядер на OSD
ОЗУ
  • 4 ГБ+ на демон (больше – лучше)
  • 1 ГБ на 1 ТБ данных OSD
Жёсткий диск
1 SSD накопитель на демон
Сеть
1 Гбит/с (рекомендуется агрегированная сеть 10+ Гбит/с)
Сервер метаданных Ceph
Процессор
2 ядра
ОЗУ
2 ГБ+ (для производственных кластеров больше)
Жёсткий диск
1 ГБ на демон, рекомендуется SSD
Сеть
1 Гбит/с (рекомендуется 10+ Гбит/с)
Серверу в целом требуется как минимум сумма потребностей демонов, которые он размещает, а также ресурсы для журналов и других компонентов ОС. Следует также учитывать, что потребность сервера в ОЗУ и хранилище будет больше при запуске и при выходе из строя или добавлении компонентов и перебалансировке кластера.
Дополнительные рекомендации:
  • Память: при гиперконвергентной настройке необходимо тщательно контролировать потребление памяти. Помимо прогнозируемого использования памяти ВМ и контейнерами необходимо также учитывать наличие достаточного объема памяти для Ceph;
  • Сеть: Рекомендуется использовать сеть не менее 10 Гбит/с, которая используется исключительно для Ceph. Объем трафика, особенно во время восстановления, будет мешать другим службам в той же сети и может даже сломать стек кластера PVE. Кроме того, необходимо оценить потребность в пропускной способности. Например, один жесткий диск может не заполнить канал 1 Гбит, несколько жестких дисков OSD на узел могут, а современные твердотельные накопители NVMe быстро заполнят 10 Гбит/с. Развертывание сети, способной обеспечить еще большую пропускную способность, гарантирует, что это не станет узким местом. Возможны 25, 40 или даже 100 Гбит/с.
  • Жесткие диски: OSD-диски, намного меньшие одного терабайта, используют значительную часть своей емкости для метаданных, а диски меньше 100 ГБ будут вообще неэффективны. Настоятельно рекомендуется, чтобы SSD были предоставлены как минимум для узлов мониторов Ceph и менеджеров Ceph, а также для пулов метаданных CephFS и пулов индексов Ceph Object Gateway (RGW), даже если жесткие диски должны быть предоставлены для больших объемов данных OSD.
    Помимо типа диска, Ceph лучше всего работает с равномерным по размеру и распределенным количеством дисков на узел. Например, 4 диска по 500 ГБ в каждом узле лучше, чем смешанная установка с одним диском на 1 ТБ и тремя дисками по 250 ГБ.
    Необходимо также сбалансировать количество OSD и емкость одного OSD. Большая емкость позволяет увеличить плотность хранения, но это также означает, что один сбой OSD заставляет Ceph восстанавливать больше данных одновременно.
    Поскольку Ceph обрабатывает избыточность объектов данных и несколько параллельных записей на диски (OSD) самостоятельно, использование RAID-контроллера обычно не улучшает производительность или доступность. Напротив, Ceph разработан для самостоятельной обработки целых дисков, без какой-либо абстракции между ними. RAID-контроллеры не предназначены для рабочей нагрузки Ceph и могут усложнять ситуацию, а иногда даже снижать производительность, поскольку их алгоритмы записи и кеширования могут мешать алгоритмам Ceph.

Примечание

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

39.6.2. Начальная конфигурация Ceph

Для создания начальной конфигурации Ceph рекомендуется использовать мастер установки PVE Ceph. В случае использования мастер установки PVE Ceph следует перейти в раздел Центр обработки данныхCeph и нажать кнопку Настроить Ceph:
Инициализация кластера Ceph
В открывшемся окне необходимо выбрать открытую сеть в выпадающем списке Public Network и сеть кластера в списке Cluster Network:
  • Public Network — позволяет настроить выделенную сеть для Ceph. Настоятельно рекомендуется выделить трафик Ceph в отдельную сеть;
  • Cluster Network — позволяет разделить трафик репликации OSD и heartbeat. Это разгрузит общедоступную сеть и может привести к значительному повышению производительности, особенно в больших кластерах.
Настройка сетевых параметров Ceph

Примечание

Сеть в поле Cluster Network можно не указывать, по умолчанию сеть кластера совпадает с открытой сетью, указанной в поле Public Network.
После нажатия кнопки Далее будет выведено сообщение об успешной установке:
Сообщение об успешной установке Ceph
Создать начальную конфигурацию Ceph также можно, выполнив следующую команду на любом узле PVE:
# pveceph init --network 192.168.0.0/24
В результате инициализации Ceph будет создана начальная конфигурация в файле /etc/pve/ceph.conf с выделенной сетью для Ceph. Файл /etc/pve/ceph.conf автоматически распространяется на все узлы PVE с помощью pmxcfs. Будет также создана символическая ссылка /etc/ceph/ceph.conf, которая указывает на файл /etc/pve/ceph.conf. Таким образом, можно запускать команды Ceph без необходимости указывать файл конфигурации.
При инициализации Ceph будет создан один монитор. Далее необходимо создать несколько дополнительных мониторов, менеджер, OSD и по крайней мере один пул.

39.6.3. Монитор Ceph

Монитор Ceph поддерживает основную копию карты кластера. Для поддержания высокой доступности нужно не менее трёх мониторов. Если использовался мастер установки, один монитор уже будет установлен.

Примечание

Если кластер небольшой или средних размеров, трёх мониторов будет достаточно, больше мониторов требуется только для действительно больших кластеров.

39.6.3.1. Создание монитора

Для создания монитора в веб-интерфейсе, необходимо на любом узле перейти на вкладку ХостCephМонитор и создать необходимое количество мониторов на узлах. Для этого нажать кнопку Создать в разделе Монитор и в открывшемся окне выбрать имя узла, на котором будет создан монитор:
Создание монитора на узле pve02
Для создания монитора в командной строке, следует на каждом узле, где нужно разместить монитор, выполнить команду:
# pveceph mon create

39.6.3.2. Удаление монитора

Чтобы удалить монитор в веб-интерфейсе, необходимо выбрать любой узел в дереве, перейти на панель ХостCephМонитор, выбрать монитор и нажать кнопку Уничтожить.
Для удаления монитора Ceph в командной строке, необходимо подключиться к узлу, на котором запущен монитор, и выполнить команду:
# pveceph mon destroy

39.6.4. Менеджер Ceph

Менеджер Ceph работает вместе с мониторами. Он предоставляет интерфейс для мониторинга кластера. Требуется как минимум один демон ceph-mgr.

Примечание

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

39.6.4.1. Создание менеджера

Для создания менеджера в веб-интерфейсе, следует на любом узле перейти на вкладку ХостCephМонитор и создать необходимое количество менеджеров на узлах. Для этого нажать кнопку Создать в разделе Диспетчер и в открывшемся окне выбрать имя узла, на котором будет создан менеджер Ceph:
Создание менеджера на узле pve02
Для создания менеджера в командной строке, следует на каждом узле, где нужно разместить менеджер Ceph, выполнить команду:
# pveceph mgr create

39.6.4.2. Удаление менеджера

Чтобы удалить менеджер в веб-интерфейсе, необходимо выбрать любой узел в дереве, перейти на панель ХостCephМонитор, выбрать менеджер и нажать кнопку Уничтожить.
Для удаления менеджера Ceph в командной строке, необходимо подключиться к узлу, на котором запущен менеджер, и выполнить команду:
# pveceph mgr destroy

39.6.5. Ceph OSD

Рекомендуется использовать один OSD на каждый физический диск.

39.6.5.1. Создание OSD

Рекомендуется использовать кластер Ceph с не менее чем тремя узлами и не менее чем 12 OSD, равномерно распределенными по узлам.
Если диск использовался ранее (например, для ZFS или как OSD), сначала нужно удалить все следы этого использования. Чтобы удалить таблицу разделов, загрузочный сектор и любые другие остатки OSD, можно использовать команду:
# ceph-volume lvm zap /dev/[X] --destroy

Предупреждение

Эта команда уничтожит все данные на диске!
Для создания OSD в веб-интерфейсе PVE, необходимо перейти на вкладку ХостCephOSD и нажать кнопку Создать: OSD:
Создание OSD
В открывшемся окне выбрать локальный диск, который будет включен в Сeph-кластер. Отдельно можно указать диски для метаданных (Диск базы данных) и журналирования (Диск WAL).
Для создания OSD в командной строке можно выполнить команду:
# pveceph osd create /dev/[X]
Указать отдельные устройства для метаданных (DB) и журналирования (WAL) для OSD можно с помощью параметров -db_dev и -wal_dev:
# pveceph osd create /dev/[X] -db_dev /dev/[Y] -wal_dev /dev/[Z]
Если диск для журналирования не указан, WAL размещается вместе с DB.
Можно напрямую указать размер WAL и DB с помощью параметров -db_size и -wal_size соответственно. Если эти параметры не указаны, будут использоваться следующие значения (по порядку):
  • bluestore_block_{db,wal}_size из конфигурации Ceph:
    • … база данных, раздел [osd];
    • … база данных, раздел [global];
    • … файл, раздел [osd];
    • … файл, раздел [global];
  • 10% (DB)/1% (WAL) от размера OSD.

Примечание

В DB хранятся внутренние метаданные BlueStore, а WAL — это внутренний журнал BlueStore или журнал предварительной записи. Для лучшей производительности рекомендуется использовать высокопроизводительные диски.

39.6.5.2. Удаление OSD

Процедура удаления OSD в веб-интерфейсе:
  1. Выбрать узел PVE и перейти на панель CephOSD.
  2. Выбрать OSD, который нужно удалить и нажать кнопку Out.
  3. После того как статус OSD изменится с in на out, нажать кнопку Остановка.
  4. После того как статус изменится с up на down, выбрать раскрывающемся списке ДополнительноУничтожить.
Чтобы удалить OSD в консоли, следует выполнить следующие команды:
# ceph osd out <ID>
# systemctl stop ceph-osd@<ID>.service
Первая команда указывает Ceph не включать OSD в распределение данных. Вторая команда останавливает службу OSD. До этого момента данные не теряются.
Следующая команда уничтожит OSD (можно указать параметр -cleanup, чтобы дополнительно уничтожить таблицу разделов):
# pveceph osd destroy <ID>

Предупреждение

Эта команда уничтожит все данные на диске!

39.6.6. Пулы Ceph

Пул — это логическая группа для хранения объектов. Он содержит набор объектов, известных как группы размещения (PG, pg_num).

39.6.6.1. Создание и редактирование пула

Создавать и редактировать пулы можно в командной строке или в веб-интерфейсе любого узла PVE в разделе ХостCephПулы.
Создание пула
Следующие параметры доступны при создании пула, а также частично при редактировании пула (в скобках приведены соответствующие опции команды pveceph pool create):
  • Имя — имя пула. Имя должно быть уникальным и не может быть изменено впоследствии;
  • Размер (-size) — количество реплик на объект. Ceph всегда пытается иметь указанное количество копий объекта (по умолчанию 3);
  • PG Autoscale Mode (Режим автоматического масштабирования PG) (-pg_autoscale_mode) — автоматический режим масштабирования PG пула. Если установлено значение warn, выводится предупреждающее сообщение, если в пуле неоптимальное количество PG (по умолчанию warn);
  • Добавить как хранилище (-add_storages) — настроить хранилище с использованием нового пула. Доступно только при создании пула (по умолчанию true);
  • Мин. Размер (-min_size) — минимальное количество реплик для объекта. Ceph отклонит ввод-вывод в пуле, если в PG меньше указанного количества реплик (по умолчанию 2);
  • Crush Rule (Правило Crush) (-crush_rule) — правило, используемое для сопоставления размещения объектов в кластере. Эти правила определяют, как данные размещаются в кластере;
  • # of PGs (Количество PG) (-pg_num) — количество групп размещения, которые должен иметь пул в начале (по умолчанию 128);
  • Целевой коэффициент (-target_size_ratio) — соотношение ожидаемых данных в пуле. Автомасштабирование PG использует соотношение относительно других наборов соотношений. Данный параметр имеет приоритет над целевым размером, если установлены оба;
  • Целевой размер (-target_size) — предполагаемый объем данных, ожидаемых в пуле. Автомасштабирование PG использует этот размер для оценки оптимального количества PG;
  • Min # of PGs (Мин. количество PG) (-pg_num_min) — минимальное количество групп размещения. Этот параметр используется для точной настройки нижней границы количества PG для этого пула. Автомасштабирование PG не будет объединять PG ниже этого порогового значения.

Примечание

Не следует устанавливать min_size равным 1. Реплицированный пул с min_size равным 1 разрешает ввод-вывод для объекта, при наличии только одной реплики, что может привести к потере данных, неполным PG или ненайденным объектам.
Рекомендуется либо включить режим автоматического масштабирования PG (PG autoscaler), либо рассчитать количество PG на основе ваших настроек.
Команда создания пула в командной строке:
# pveceph pool create <pool-name> -add_storages

39.6.6.2. Пулы EC

Erasure coding (EC) — это метод коррекции ошибок, используемый для обеспечения надежности и восстановления данных в системах хранения. Основная цель EC — повысить доступность данных, минимизировав их избыточное копирование. Пулы EC могут предложить больше полезного пространства по сравнению с реплицированными пулами, но они делают это за счет производительности.
В классических реплицированных пулах хранится несколько реплик данных (size), тогда как в пуле EC данные разбиваются на k фрагментов данных с дополнительными m фрагментами кодирования (проверки). Эти фрагменты кодирования можно использовать для воссоздания данных, если фрагменты данных отсутствуют.
Количество фрагментов кодирования m определяет, сколько OSD может быть потеряно без потери данных. Общее количество хранимых объектов равно k + m.
Пулы EC можно создавать с помощью команды pveceph. При планировании пула EC необходимо учитывать тот факт, что они работают иначе, чем реплицированные пулы.
По умолчанию значение min_size для пула EC зависит от параметра m. Если m = 1, значение min_size для пула EC будет равно k. Если m > 1, значение min_size будет равно k + 1. В документации Ceph рекомендуется использовать консервативное значение min_size, равное k + 2.
Если доступно меньше, чем min_size OSD, любой ввод-вывод в пул будет заблокирован до тех пор, пока снова не будет достаточно доступных OSD.

Примечание

При планировании пула EC необходимо следить за min_size, так как он определяет, сколько OSD должно быть доступно. В противном случае ввод-вывод будет заблокирован.
Например, пул EC с k = 2 и m = 1 будет иметь size = 3, min_size = 2 и останется работоспособным, если один OSD выйдет из строя. Если пул настроен с k = 2, m = 2, будет иметь size = 4 и min_size = 3 и останется работоспособным, если один OSD будет потерян.
Команда для создания пула EC:
# pveceph pool create <pool-name> --erasure-coding k=<integer> ,m=<integer> \
[,device-class=<class>] [,failure-domain=<domain>] [,profile=<profile>]
В результате выполнения этой команды будет создан новый пул EC для RBD с сопутствующим реплицированным пулом для хранения метаданных (<pool name>-data и <pool name>-metada). По умолчанию также будет создано соответствующее хранилище. Если такое поведение нежелательно, отключить создание хранилища можно, указав параметр --add_storages 0. При настройке конфигурации хранилища вручную необходимо будет задать параметр data-pool, только тогда пул EC будет использоваться для хранения объектов данных.

Примечание

Необязательные параметры --size, --min_size и --crush_rule будут использоваться для реплицированного пула метаданных, но не для пула данных EC. Если нужно изменить min_size в пуле данных, это можно будет сделать позже. Параметры size и crush_rule нельзя изменить в пулах EC.
Изменить настройки профиля EC нельзя, в этом случае нужно создать новый пул с новым профилем.
Если необходимо дополнительно настроить профиль EC, можно создать его напрямую с помощью инструментов Ceph и указать профиль в параметре profile. Например:
# pveceph pool create <pool-name> --erasure-coding profile=<profile-name>
Существующий пул EC можно добавить в качестве хранилища в PVE:
# pvesm add rbd <storage-name> --pool <replicated-pool> --data-pool <ec-pool>

Примечание

Для любых внешних кластеров Ceph, не управляемых локальным кластером PVE, также следует указывать параметры keyring и monhost.

39.6.6.3. Удаление пула

Чтобы удалить пул в веб-интерфейсе, необходимо в разделе ХостCephПулы выбрать пул, который нужно удалить и нажать кнопку Уничтожить. Для подтверждения уничтожения пула, нужно в открывшемся диалоговом окне ввести имя пула и нажать кнопку Удалить:
Удаление пула
Команда для удаления пула:
# pveceph pool destroy <name>
Следующая команда уничтожит OSD (можно указать параметр -cleanup, чтобы дополнительно уничтожить таблицу разделов):
# pveceph osd destroy <ID>
Чтобы также удалить связанное хранилище следует указать опцию -remove_storages.

Примечание

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

39.6.6.4. Автомасштабирование PG

Автомасштабирование PG позволяет кластеру учитывать объем (ожидаемых) данных, хранящихся в каждом пуле, и автоматически выбирать соответствующие значения pg_num.

Примечание

Может потребоваться активировать модуль pg_autoscaler:
# ceph mgr module enable pg_autoscaler
Список запущенных модулей можно посмотреть, выполнив команду:
# ceph mgr module ls
Автомасштабирование настраивается для каждого пула и имеет следующие режимы:
  • warn — предупреждение о работоспособности выдается, если предлагаемое значение pg_num слишком сильно отличается от текущего значения;
  • on — pg_num настраивается автоматически без необходимости ручного вмешательства;
  • off — автоматические корректировки pg_num не производятся, и предупреждение не выдается, если количество PG не является оптимальным.
Коэффициент масштабирования можно настроить с помощью параметров target_size, target_size_ratio и pg_num_min.

39.6.7. Ceph CRUSH и классы устройств

В основе Ceph лежит алгоритм CRUSH (Controlled Replication Under Scalable Hashing). CRUSH вычисляет, где хранить и откуда извлекать данные. Этот алгоритм позволяет однозначно определить местоположение объекта на основе хеша имени объекта и определенной карты, которая формируется исходя из физической и логической структур. Карта не включает в себя информацию о местонахождении данных Путь к данным каждый клиент определяет сам, с помощью CRUSH-алгоритма и актуальной карты, которую он предварительно спрашивает у монитора. При добавлении диска или падении сервера, карта обновляется.
Карта Crush
Карту можно изменить, чтобы она отражала различные иерархии репликации. Реплики объектов можно разделить (например, домены отказов), сохраняя при этом желаемое распределение.
Классы устройств можно увидеть в выходных данных дерева OSD ceph. Эти классы представляют свой собственный корневой контейнер, который можно увидеть, выполнив команду:
# ceph osd crush tree --show-shadow
ID   CLASS  WEIGHT   TYPE NAME
 -6   nvme  0.09760  root default~nvme
 -5   nvme        0      host pve01~nvme
 -9   nvme  0.04880      host pve02~nvme
  1   nvme  0.04880          osd.1
-12   nvme  0.04880      host pve03~nvme
  2   nvme  0.04880          osd.2
 -2    ssd  0.04880  root default~ssd
 -4    ssd  0.04880      host pve01~ssd
  0    ssd  0.04880          osd.0
 -8    ssd        0      host pve02~ssd
-11    ssd        0      host pve03~ssd
 -1         0.14639  root default
 -3         0.04880      host pve01
  0    ssd  0.04880          osd.0
 -7         0.04880      host pve02
  1   nvme  0.04880          osd.1
-10         0.04880      host pve03
  2   nvme  0.04880          osd.2
Чтобы указать пулу распределять объекты только на определенном классе устройств, сначала необходимо создать политику для класса устройств:
# ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>
Где:
  • rule-name — имя политики;
  • root — корень отказа (значение default — корень Ceph);
  • failure-domain — домен отказа, на котором должны распределяться объекты (обычно host);
  • class — какой тип хранилища резервных копий OSD использовать (например, nvme, ssd).
Пример создания политики replicated_nvme для реплицированных пулов, данные будут иметь домен отказа host, а размещаться — на nvme:
# ceph osd crush rule create-replicated my_rule default host nvme
Посмотреть настройки политик можно, выполнив команду:
# ceph osd crush rule dump
После того как политика будет создана в карте CRUSH, можно указать пулу использовать набор правил:
# ceph osd pool set <pool-name> crush_rule <rule-name>

Примечание

Если пул уже содержит объекты, их необходимо переместить соответствующим образом. В зависимости от настроек это может оказать большое влияние на производительность кластера. Либо можно создать новый пул и переместить диски по отдельности.

39.6.8. Клиент Ceph

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

Примечание

Имя файла должно быть в формате <storage_id>.keyring, где <storage_id> — идентификатор хранилища rbd.

39.6.9. CephFS

Ceph предоставляет файловую систему, которая работает поверх того же хранилища объектов, что и блочные устройства RADOS. Сервер метаданных (MDS) используется для сопоставления поддерживаемых RADOS объектов с файлами и каталогами, что позволяет Ceph предоставлять POSIX-совместимую, реплицированную файловую систему. Это позволяет легко настраивать кластерную, высокодоступную, общую файловую систему. Серверы метаданных Ceph гарантируют, что файлы равномерно распределены по всему кластеру Ceph В результате даже случаи высокой нагрузки не перегрузят один хост, что может быть проблемой при традиционных подходах к общим файловым системам, например, NFS.
PVE поддерживает как создание гиперконвергентной CephFS, так и использование существующей CephFS в качестве хранилища для хранения резервных копий, ISO-файлов и шаблонов контейнеров.

39.6.9.1. Сервер метаданных (MDS)

В кластере можно создать несколько серверов метаданных, но по умолчанию только один может быть активным. Если MDS или его узел перестает отвечать, становится активным другой резервный MDS. Ускорить передачу данных между активным и резервным MDS можно, используя параметр hotstandby при создании сервера, или, после его создания, установив в соответствующем разделе MDS в /etc/pve/ceph.conf параметр:
mds standby replay = true
Если этот параметр включен, указанный MDS будет находиться в состоянии warm, опрашивая активный, чтобы в случае возникновения каких-либо проблем быстрее взять на себя управление.

Примечание

Этот активный опрос оказывает дополнительное влияние на производительность системы и активного MDS.
Для работы CephFS требуется настроить и запустить по крайней мере один сервер метаданных. MDS можно создать в веб-интерфейсе PVE (ХостCephCephFS и нажать кнопку Создать):
Создание сервера метаданных Ceph
Или из командной строки, выполнив команду:
# pveceph mds create

39.6.9.2. Создание CephFS

Создать CephFS можно либо в веб-интерфейсе PVE (ХостCephCephFS и нажать кнопку Создать CephFS):
Создание CephFS
Или с помощью инструмента командной строки pveceph, например:
# pveceph fs create --pg_num 128 --add-storage
В результате будет создана CephFS с именем cephfs, пул данных cephfs_data со 128 группами размещения и пул метаданных cephfs_metadata с четвертью групп размещения пула данных (32). Параметр --add-storage (опция Добавить как хранилище) добавит CephFS в конфигурацию хранилища PVE.

39.6.9.3. Удаление CephFS

Предупреждение

Уничтожение CephFS сделает все ее данные непригодными для использования. Это действие нельзя отменить!
Чтобы полностью и корректно удалить CephFS, необходимо выполнить следующие шаги:
  1. Отключить всех клиентов, не являющихся PVE (например, размонтировать CephFS в гостевых системах);
  2. Отключить все связанные записи хранилища CephFS PVE (чтобы предотвратить автоматическое монтирование);
  3. Удалить все используемые ресурсы из гостевых систем (например, ISO-образы), которые находятся на CephFS, которую нужно уничтожить;
  4. Вручную размонтировать хранилища CephFS на всех узлах кластера с помощью команды:
    # umount /mnt/pve/<STORAGE-NAME>
    
    где <STORAGE-NAME> — имя хранилища CephFS в PVE.
  5. Убедиться, что для этого CephFS не запущен ни один сервер метаданных (MDS), остановив или уничтожив их. Это можно сделать в веб-интерфейсе или в командной строке, выполнив команду:
    # pveceph stop --service mds.NAME
    
    чтобы остановить их, или команду:
    # pveceph mds destroy NAME
    
    чтобы уничтожить их.
    Следует обратить внимание, что резервные серверы будут автоматически повышены до активных при остановке или удалении активного MDS, поэтому лучше сначала остановить все резервные серверы.
  6. Теперь можно уничтожить CephFS, выполнив команду:
    # pveceph fs destroy NAME --remove-storages --remove-pools
    
    Это автоматически уничтожит базовые пулы Ceph, а также удалит хранилища из конфигурации PVE.
После этих шагов CephFS должен быть полностью удален, и при наличии других экземпляров CephFS, остановленные серверы метаданных можно снова запустить для работы в качестве резервных.

39.6.10. Техническое обслуживание Ceph

39.6.10.1. Замена OSD

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

Примечание

При значениях size/min_size по умолчанию (3/2) восстановление начнется только при наличии узлов size + 1. Причина этого в том, что балансировщик объектов Ceph CRUSH по умолчанию использует полный узел в качестве «домена отказа».
Чтобы заменить работающий диск из веб-интерфейса, следует выполнить шаги, указанные в разделе Удаление OSD. Единственное дополнение — дождаться, пока кластер не покажет HEALTH_OK, прежде чем останавливать OSD для его уничтожения.
Для замены работающего диска в командной строке, следует выполнить следующие действия:
  1. Выполнить команду:
    # ceph osd out osd.<id>
    
  2. Проверить можно ли безопасно удалить OSD:
    # ceph osd safe-to-destroy osd.<id>
    
  3. После того как проверка покажет, что можно безопасно удалить OSD, выполнить команды:
    # systemctl stop ceph-osd@<id>.service
    # pveceph osd destroy <id>
    
Далее следует заменить старый диск новым и использовать ту же процедуру, что описана в разделе Создание OSD.

39.6.10.2. Trim/Discard

Рекомендуется регулярно запускать fstrim (discard) на ВМ и контейнерах. Это освобождает блоки данных, которые файловая система больше не использует. В результате снижается нагрузка на ресурсы. Большинство современных ОС регулярно отправляют такие команды discard своим дискам. Нужно только убедиться, что ВМ включают опцию disk discard.

39.6.10.3. Очистка (scrubing)

Ceph обеспечивает целостность данных, очищая группы размещения. Ceph проверяет каждый объект в PG на предмет его работоспособности. Существует две формы очистки: ежедневные проверки метаданных и еженедельные глубокие проверки данных. Еженедельная глубокая очистка считывает объекты и использует контрольные суммы для обеспечения целостности данных Если запущенная очистка мешает бизнес-потребностям (производительности), можно настроить время выполнения очисток.

39.6.11. Мониторинг и устранение неполадок Ceph

Важно постоянно контролировать работоспособность Ceph, либо с помощью инструментов Ceph, либо путем доступа к статусу через API PVE.
Следующие команды Ceph можно использовать для проверки работоспособности кластера (HEALTH_OK), наличия предупреждений (HEALTH_WARN) или ошибок (HEALTH_ERR):
# ceph -s # однократный вывод
# ceph -w # непрерывный вывод изменений статуса
Эти команды также предоставляют обзор действий, которые необходимо предпринять если кластер находится в неработоспособном состоянии.
Чтобы получить более подробную информацию можно воспользоваться файлами журнала Ceph в /var/log/ceph/.

Глава 40. Сетевая подсистема

PVE использует сетевой стек Linux, что обеспечивает большую гибкость в настройке сети на узлах PVE. Настройку сети можно выполнить либо через графический интерфейс (ХостСистемаСеть), либо вручную, редактируя файлы в каталоге /etc/net/ifaces.
Сетевые интерфейсы узла pve01

Примечание

Интерфейс vmbr0 необходим для подключения гостевых систем к базовой физической сети. Это мост Linux, который можно рассматривать как виртуальный коммутатор, к которому подключены гостевые системы и физические интерфейсы.
Новый сетевой интерфейс
Виды сетевых соединений в PVE:
  • Linux Bridge — способ соединения двух сегментов Ethernet на канальном уровне;
  • Linux Bond — реализация агрегации нескольких сетевых интерфейсов в единый логический bonded интерфейс на базе ядра Linux;
  • Linux VLAN — реализация VLAN на базе ядра Linux.
  • OVS Bridge — реализация моста на базе Open vSwitch. Мосты Open vSwitch могут содержать необработанные устройства Ethernet, а также виртуальные интерфейсы OVSBonds или OVSIntPorts. Эти мосты могут нести несколько vlan и быть разбиты на «внутренние порты» для использования в качестве интерфейсов vlan на хосте. Все интерфейсы, входящие в мост, должны быть перечислены в ovs_ports;
  • OVS Bond — реализация агрегации сетевых интерфейсов на базе Open vSwitch. Отличается от реализованной в ядре Linux режимами балансировки нагрузки;
  • OVS VLAN — реализация VLAN на базе Open vSwitch.
Мосты, VLAN и агрегированные интерфейсы Open vSwitch и Linux не должны смешиваться. Например, не нужно добавлять Linux Bond к OVSBridge или наоборот.

40.1. Применение изменений сетевых настроек

Все изменения конфигурации сети, сделанные в веб-интерфейсе PVE, сначала записываются во временный файл, что позволяет сделать несколько связанных изменений одновременно. Это также позволяет убедиться, что изменения сделаны верно, так как неправильная конфигурация сети может сделать узел недоступным.
Для применения изменений сетевых настроек, сделанных в веб-интерфейсе PVE, следует нажать кнопку Применить конфигурацию. В результате изменения будут применены в реальном времени.
Ещё один способ применить новую сетевую конфигурацию — перезагрузить узел.

40.2. Имена сетевых устройств

В PVE используются следующие соглашения об именах устройств:
  • устройства Ethernet: en*, имена сетевых интерфейсов systemd;
  • мосты: vmbr[N], где 0 ≤ N ≤ 4094 (vmbr0 — vmbr4094);
  • сетевые объединения: bond[N], где 0 ≤ N (bond0, bond1, …);
  • VLAN: можно просто добавить номер VLAN к имени устройства, отделив точкой (eno1.50, bond1.30).
Systemd использует префикс en для сетевых устройств Ethernet. Следующие символы зависят от драйвера устройства и того факта, какая схема подходит первой:
  • o<index>[n<phys_port_name>|d<dev_port>] — встроенные устройства;
  • s<slot>[f<function>][n<phys_port_name>|d<dev_port>] — устройства по идентификатору горячего подключения;
  • [P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>] — устройства по идентификатору шины;
  • x<MAC> — устройство по MAC-адресу.
Наиболее распространенные шаблоны:
  • eno1 — первая сетевая карта;
  • enp0s3 — сетевая карта в слоте 3 шины pcibus 0.

40.3. Конфигурация сети с использованием моста

Мосты похожи на физические сетевые коммутаторы, реализованные в программном обеспечении. Все виртуальные системы могут использовать один мост, также можно создать несколько мостов для отдельных сетевых доменов. На каждом хосте можно создать до 4094 мостов.
По умолчанию после установки на каждом узле PVE есть единственный мост (vmbr0), который подключается к первой плате Ethernet:
Узлы PVE с мостом vmbr0
При этом ВМ ведут себя так, как если бы они были напрямую подключены к физической сети. Каждая ВМ видна в сети со своим MAC-адресом.

40.3.1. Внутренняя сеть для ВМ

Если необходимо несколько ВМ объединить в локальную сеть без доступа во внешний мир, можно создать новый мост.

40.3.1.1. Настройка в веб-интерфейсе PVE

Для того чтобы создать мост, в разделе Сеть необходимо нажать кнопку Создать и в выпадающем меню выбрать пункт Linux Bridge или OVS Bridge:
Создать мост
В открывшемся окне в поле Имя следует указать имя моста и нажать кнопку Создать:
PVE. Создание Linux Bridge
Создание моста Open vSwitch отличается возможностью указания дополнительных параметров Open vSwitch (поле Параметры OVS):
PVE. Создание OVS Bridge

Примечание

Адрес интерфейса можно не указывать, настроенные на подключение к интерфейсу ВМ будут использовать его как обычный коммутатор. Если же указать IPv4 и/или IPv6-адрес, то он будет доступен извне на интерфейсах, перечисленных в поле Порты сетевого моста.
Для применения изменений следует нажать кнопку Применить конфигурацию.
Теперь мост vmbr1 можно назначать ВМ:
PVE. Назначение моста vmbr1 ВМ

40.3.1.2. Настройка в командной строке

Для настройки Linux bridge с именем vmbr1, следует выполнить следующие команды:
# mkdir /etc/net/ifaces/vmbr1
# cat <<EOF > /etc/net/ifaces/vmbr1/options
BOOTPROTO=static
CONFIG_IPV4=yes
HOST=
ONBOOT=yes
TYPE=bri
EOF

Примечание

Если в мост будут входить интерфейсы, которые до этого имели IP-адрес, то этот адрес должен быть удалён. Интерфейсы, которые будут входить в мост, должны быть указаны в опции HOST.
Пример настройки моста vmbr1 на интерфейсе enp0s8:
# mkdir /etc/net/ifaces/vmbr1
# cp /etc/net/ifaces/enp0s8/* /etc/net/ifaces/vmbr1/
# rm -f /etc/net/ifaces/enp0s8/{i,r}* 
# cat <<EOF > /etc/net/ifaces/vmbr1/options
BOOTPROTO=static
CONFIG_WIRELESS=no
CONFIG_IPV4=yes
HOST='enp0s8'
ONBOOT=yes
TYPE=bri
EOF
IP-адрес для интерфейса vmbr1 будет взят из /etc/net/ifaces/enp0s8/ipv4address.
Для настройки OVS bridge с именем vmbr1, следует выполнить следующие команды:
# mkdir /etc/net/ifaces/vmbr1
# cat <<EOF > /etc/net/ifaces/vmbr1/options
BOOTPROTO=static
CONFIG_IPV4=yes
ONBOOT=yes
TYPE=ovsbr
EOF
Пример настройки моста vmbr1 на интерфейсе enp0s8:
# mkdir /etc/net/ifaces/vmbr1
# cp /etc/net/ifaces/enp0s8/* /etc/net/ifaces/vmbr1/
# rm -f /etc/net/ifaces/enp0s8/{i,r}* 
# cat <<EOF > /etc/net/ifaces/vmbr1/options
BOOTPROTO=static
CONFIG_IPV4=yes
ONBOOT=yes
HOST='enp0s8'
TYPE=ovsbr
EOF
Для применения изменений необходимо перезапустить службу network:
# systemctl restart network
или перезагрузить узел:
# reboot

40.4. Объединение/агрегация интерфейсов

Объединение/агрегация интерфейсов (bonding) — это объединение двух и более сетевых интерфейсов в один логический интерфейс для достижения отказоустойчивости или увеличения пропускной способности. Поведение такого логического интерфейса зависит от выбранного режима работы.
Если на узлах PVE есть несколько портов Ethernet, можно распределить точки отказа, подключив сетевые кабели к разным коммутаторам, и в случае проблем с сетью агрегированное соединение переключится с одного кабеля на другой. Агрегация интерфейсов может сократить задержки выполнения миграции в реальном времени и повысить скорость репликации данных между узлами кластера PVE.
Кластерную сеть (Corosync) рекомендуется настраивать с несколькими сетями. Corosync не нуждается в агрегации для резервирования сети, поскольку может сам переключаться между сетями.

40.4.1. Параметры Linux Bond

В следующей таблице приведены режимы агрегации Linux Bond.

Таблица 40.1. Режимы агрегации Linux Bond

Режим
Название
Описание
Отказоустойчивость
Балансировка нагрузки
balance-rr или mode=0
Round-robin
Режим циклического выбора активного интерфейса для трафика. Пакеты последовательно передаются и принимаются через каждый интерфейс один за другим. Данный режим не требует применения специальных коммутаторов.
Да
Да
active-backup или mode=1
Active Backup
В этом режиме активен только один интерфейс, остальные находятся в режиме горячей замены. Если активный интерфейс выходит из строя, его заменяет резервный. MAC-адрес интерфейса виден извне только на одном сетевом адаптере, что предотвращает путаницу в сетевом коммутаторе. Это самый простой режим, работает с любым оборудованием, не требует применения специальных коммутаторов.
Да
Нет
balance-xor или mode=2
XOR
Один и тот же интерфейс работает с определённым получателем. Передача пакетов распределяется между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Режим не требует применения специальных коммутаторов. Этот режим обеспечивает балансировку нагрузки и отказоустойчивость.
Да
Да
broadcast или mode=3
Широковещательный
Трафик идёт через все интерфейсы одновременно.
Да
Нет
LACP (802.3ad) или mode=4
Агрегирование каналов по стандарту IEEE 802.3ad
В группу объединяются одинаковые по скорости и режиму интерфейсы. Все физические интерфейсы используются одновременно в соответствии со спецификацией IEEE 802.3ad. Для реализации этого режима необходима поддержка на уровне драйверов сетевых карт и коммутатор, поддерживающий стандарт IEEE 802.3ad (коммутатор требует отдельной настройки).
Да
Да
balance-tlb или mode=5
Адаптивная балансировка нагрузки при передаче
Исходящий трафик распределяется в соответствии с текущей нагрузкой (с учетом скорости) на интерфейсах (для данного режима необходима его поддержка в драйверах сетевых карт). Входящие пакеты принимаются только активным сетевым интерфейсом.
Да
Да (исходящий трафик)
balance-alb или mode=6
Адаптивная балансировка нагрузки
Включает в себя балансировку исходящего трафика, плюс балансировку на приём (rlb) для IPv4 трафика и не требует применения специальных коммутаторов (балансировка на приём достигается на уровне протокола ARP, перехватом ARP ответов локальной системы и перезаписью физического адреса на адрес одного из сетевых интерфейсов, в зависимости от загрузки).
Да
Да
В таблице ниже приведены алгоритмы выбора каналов (распределения пакетов между физическими каналами, входящими в многоканальное соединение) для режимов balance-alb, balance-tlb, balance-xor, 802.3ad (значение параметра xmit_hash_policy).

Таблица 40.2. Режимы выбора каналов при организации балансировки нагрузки

Режим
Описание
layer2
Канал для отправки пакета однозначно определяется комбинацией MAC-адреса источника и MAC-адреса назначения. Весь трафик между определённой парой узлов всегда идёт по определённому каналу. Алгоритм совместим с IEEE 802.3ad. Этот режим используется по умолчанию.
layer2+3
Канал для отправки пакета определяется по совокупности MAC- и IP-адресов источника и назначения. Трафик между определённой парой IP-хостов всегда идёт по определённому каналу (обеспечивается более равномерная балансировка трафика, особенно в случае, когда большая его часть передаётся через промежуточные маршрутизаторы). Для протоколов 3 уровня, отличных от IP, данный алгоритм равносилен layer2. Алгоритм совместим с IEEE 802.3ad.
layer3+4
Канал для отправки пакета определяется по совокупности IP-адресов и номеров портов источника и назначения (трафик определённого узла может распределяться между несколькими каналами, но пакеты одного и того же TCP/UDP-соединения всегда передаются по одному и тому же каналу). Для фрагментированных пакетов TCP и UDP, а также для всех прочих протоколов 4 уровня, учитываются только IP-адреса. Для протоколов 3 уровня, отличных от IP, данный алгоритм равносилен layer2. Алгоритм не полностью совместим с IEEE 802.3ad.
Для создания агрегированного bond-интерфейса средствами etcnet необходимо создать каталог для интерфейса (например, bond0) с файлами options, ipv4address. В файле options следует указать тип интерфейса (TYPE) bond, в переменной HOST перечислить родительские интерфейсы, которые будут входить в агрегированный интерфейс, в переменной BONDMODE указать режим (по умолчанию 0), а опции для модуля ядра bonding — в BONDOPTIONS.

Примечание

Агрегированный bond-интерфейс можно создать в веб-интерфейсе ЦУС, подробнее см. Объединение сетевых интерфейсов.

40.4.2. Параметры OVS Bond

Таблица 40.3. Параметры OVS Bond

Параметр
Описание
bond_mode=active-backup
В этом режиме активен только один интерфейс, остальные находятся в режиме горячей замены. Если активный интерфейс выходит из строя, его заменяет резервный. MAC-адрес интерфейса виден извне только на одном сетевом адаптере, что предотвращает путаницу в сетевом коммутаторе. Это самый простой режим, работает с любым оборудованием, не требует применения специальных коммутаторов.
bond_mode=balance-slb
Режим простой балансировки на основе MAC и VLAN. В этом режиме нагрузка трафика на интерфейсы постоянно измеряется, и если один из интерфейсов сильно загружен, часть трафика перемещается на менее загруженные интерфейсы. Параметр bond-rebalance-interval определяет, как часто OVS должен выполнять измерение нагрузки трафика (по умолчанию 10 секунд). Этот режим не требует какой-либо специальной настройки на коммутаторах.
bond_mode=balance-tcp
Этот режим выполняет балансировку нагрузки, принимая во внимание данные уровней 2-4 (например, MAC-адрес, IP -адрес и порт TCP). На коммутаторе должен быть настроен LACP. Этот режим похож на режим mode=4 Linux Bond. Всегда, когда это возможно, рекомендуется использовать этот режим
lacp=[active|passive|off]
Управляет поведением протокола управления агрегацией каналов (LACP). На коммутаторе должен быть настроен протокол LACP. Если коммутатор не поддерживает LACP, необходимо использовать bond_mode=balance-slb или bond_mode=active-backup.
other-config:lacp-fallback-ab=true
Устанавливает поведение LACP для переключения на bond_mode=active-backup в качестве запасного варианта
other_config:lacp-time=[fast|slow]
Определяет, с каким интервалом управляющие пакеты LACPDU отправляются по каналу LACP: каждую секунду (fast) или каждые 30 секунд (slow). По умолчанию slow
other_config:bond-detect-mode=[miimon|carrier]
Режим определения состояния канала. По умолчанию carrier
other_config:bond-miimon-interval=100
Устанавливает периодичность MII мониторинга в миллисекундах
other_config:bond_updelay=1000
Задает время задержки в миллисекундах, перед тем как поднять линк при обнаружении восстановления канала
other_config:bond-rebalance-interval=10000
Устанавливает периодичность выполнения измерения нагрузки трафика в миллисекундах (по умолчанию 10 секунд).

40.4.3. Агрегированный bond-интерфейс с фиксированным IP-адресом

Конфигурация bond с фиксированным IP-адресом может использоваться как распределенная/общая сеть хранения. Преимущество будет заключаться в том, что вы получите больше скорости, а сеть будет отказоустойчивой:
bond с фиксированным IP-адресом

40.4.3.1. Настройка в веб-интерфейсе

Для настройки Linux Bond необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, нажать кнопку Создать и в выпадающем меню выбрать пункт Linux Bond:
    Создать Linux Bond
  2. В открывшемся окне указать имя агрегированного соединения, в выпадающем списке Режим выбрать режим агрегации (в примере balance-rr), в поле Устройства указать сетевые интерфейсы, которые будут входить в объединение, в поле IPv4/CIDR ввести IP-адрес объединения и нажать кнопку Создать:
    Редактирование параметров объединения bond0

    Примечание

    В зависимости от выбранного режима агрегации будут доступны разные поля.
  3. Для применения изменений нажать кнопку Применить конфигурацию.
  4. Получившаяся конфигурация:
    Агрегированный bond-интерфейс с фиксированным IP-адресом

40.4.3.2. Настройка в командной строке

Для создания такой конфигурации, необходимо выполнить следующие действия:
  1. Создать Linux Bond bond0 на интерфейсах eno1 и eno2, выполнив следующие команды:
    # mkdir /etc/net/ifaces/bond0
    # rm -f /etc/net/ifaces/eno1/{i,r}* 
    # rm -f /etc/net/ifaces/eno2/{i,r}* 
    # cat <<EOF > /etc/net/ifaces/bond0/options
    BOOTPROTO=static
    CONFIG_WIRELESS=no
    CONFIG_IPV4=yes
    HOST='eno1 eno2'
    ONBOOT=yes
    TYPE=bond
    BONDOPTIONS='miimon=100'
    BONDMODE=0
    EOF
    
    где:
    • BONDMODE=1 — режим агрегации Round-robin;
    • HOST='eno1 eno2' — интерфейсы, которые будут входить в объединение;
    • miimon=100 — определяет, как часто производится мониторинг MII (Media Independent Interface).
  2. В файле /etc/net/ifaces/bond0/ipv4address, указать IP-адрес для интерфейса bond0:
    # echo "192.168.200.20/24" > /etc/net/ifaces/bond0/ipv4address
    
  3. Перезапустить службу network, чтобы изменения вступили в силу:
    # systemctl restart network
    

40.4.4. Агрегированный bond-интерфейс в качестве порта моста

Чтобы сделать гостевую сеть отказоустойчивой можно использовать bond напрямую в качестве порта моста:
Агрегированный bond-интерфейс в качестве порта моста

40.4.4.1. Настройка в веб-интерфейсе

Для настройки Linux Bond необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, выбрать существующий мост vmbr0 и нажать кнопку Редактировать:
    Мост vmbr0
  2. В открывшемся окне удалить содержимое поля Порты сетевого моста и нажать кнопку ОК:
    Редактирование параметров моста vmbr0
  3. Нажать кнопку Создать и в выпадающем меню выбрать пункт Linux Bond.
  4. В открывшемся окне в выпадающем списке Режим выбрать режим агрегации (в примере LACP), в поле Устройства указать сетевые интерфейсы, которые будут входить в объединение, в выпадающем списке Политика хэширования выбрать политику хэширования и нажать кнопку Создать:
    Редактирование параметров объединения bond0

    Примечание

    В зависимости от выбранного режима агрегации будут доступны разные поля.
  5. Выбрать мост vmbr0 и нажать кнопку Редактировать.
  6. В открывшемся окне в поле Порты сетевого моста вписать значение bond0 и нажать кнопку ОК:
    Редактирование параметров моста vmbr0
  7. Для применения изменений нажать кнопку Применить конфигурацию.
  8. Получившаяся конфигурация:
    bond в качестве порта моста
Для настройки OVS Bond необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, выбрать существующий мост vmbr0 и нажать кнопку Редактировать:
    Мост vmbr0
  2. В открывшемся окне удалить содержимое поля Порты сетевого моста и нажать кнопку ОК:
    Редактирование параметров моста vmbr0
  3. Нажать кнопку Создать и в выпадающем меню выбрать пункт OVS Bond.
  4. В открывшемся окне указать имя агрегированного интерфейса, в выпадающем списке Режим выбрать режим агрегации, в поле Устройства указать сетевые интерфейсы, которые будут входить в объединение, в выпадающем списке OVS Bridge выбрать мост, в который должен добавиться созданный интерфейс и нажать кнопку Создать:
    Редактирование параметров OVS Bond
  5. Для применения изменений нажать кнопку Применить конфигурацию.
  6. Получившаяся конфигурация:
    OVS Bond в качестве порта моста

40.4.4.2. Настройка в командной строке

Исходное состояние: мост vmbr0 на интерфейсе enp0s3. Необходимо создать агрегированный интерфейс bond0 (enp0s3 и enp0s8) и включить его в мост vmbr0.
Для создания Linux Bond, необходимо выполнить следующие действия:
  1. Создать агрегированный интерфейс bond0 на интерфейсах enp0s3 и enp0s8, выполнив следующие команды:
    # mkdir /etc/net/ifaces/bond0
    # cat <<EOF > /etc/net/ifaces/bond0/options
    BOOTPROTO=static
    CONFIG_WIRELESS=no
    CONFIG_IPV4=yes
    HOST='enp0s3 enp0s8'
    ONBOOT=yes
    TYPE=bond
    BONDOPTIONS='xmit_hash_policy=layer2+3 lacp_rate=1 miimon=100'
    BONDMODE=4
    EOF
    
    где:
    • BONDMODE=4 — режим агрегации LACP (802.3ad);
    • HOST='enp0s3 enp0s8' — интерфейсы, которые будут входить в объединение;
    • xmit_hash_policy=layer2+3 — определяет режим выбора каналов;
    • lacp_rate=1 — определяет, что управляющие пакеты LACPDU отправляются по каналу LACP каждую секунду;
    • miimon=100 — определяет, как часто производится мониторинг MII (Media Independent Interface).
  2. В настройках Ethernet-моста vmbr0 (файл /etc/net/ifaces/vmbr0/options) в опции HOST указать интерфейс bond0:
    BOOTPROTO=static
    BRIDGE_OPTIONS="stp_state 0"
    CONFIG_IPV4=yesq
    HOST='bond0'
    ONBOOT=yes
    TYPE=bri
    
  3. Перезапустить службу network, чтобы изменения вступили в силу:
    # systemctl restart network
    
Для создания OVS Bond, необходимо выполнить следующие действия:
  1. Начальная конфигурации:
    # ovs-vsctl show
    6b1add02-fb20-48e6-b925-260bf92fa889
        Bridge vmbr0
            Port enp0s3
                Interface enp0s3
            Port vmbr0
                Interface vmbr0
                    type: internal
        ovs_version: "2.17.6"
    
  2. Привести настройки сетевого интерфейса enp0s3 (файл /etc/net/ifaces/enp0s3/options) к виду:
    TYPE=eth
    CONFIG_WIRELESS=no
    BOOTPROTO=static
    CONFIG_IPV4=yes
    
  3. Создать агрегированный интерфейс bond0 на интерфейсах enp0s3 и enp0s8, выполнив следующие команды:
    # mkdir /etc/net/ifaces/bond0
    # cat <<EOF > /etc/net/ifaces/bond0/options
    BOOTPROTO=static
    BRIDGE=vmbr0
    CONFIG_IPV4=yes
    HOST='enp0s3 enp0s8'
    OVS_OPTIONS='other_config:bond-miimon-interval=100 bond_mode=balance-slb'
    TYPE=ovsbond
    EOF
    
    где:
    • bond_mode=balance-slb — режим агрегации;
    • HOST='enp0s3 enp0s8' — интерфейсы, которые будут входить в объединение;
    • BRIDGE=vmbr0 — мост, в который должен добавиться созданный интерфейс;
    • other_config:bond-miimon-interval=100 — определяет, как часто производится мониторинг MII (Media Independent Interface).
  4. В опции HOST настроек моста vmbr0 (файл /etc/net/ifaces/vmbr0/options) указать bond0:
    BOOTPROTO=static
    CONFIG_IPV4=yes
    HOST=bond0
    ONBOOT=yes
    TYPE=ovsbr
    
  5. Перезапустить службу network, чтобы изменения вступили в силу:
    # systemctl restart network
    
  6. Проверка конфигурации:
    # ovs-vsctl show
    6b1add02-fb20-48e6-b925-260bf92fa889
        Bridge vmbr0
            Port bond0
                Interface enp0s3
                Interface enp0s8
            Port vmbr0
                Interface vmbr0
                    type: internal
        ovs_version: "2.17.6"
    

40.5. Настройка VLAN

Виртуальные сети (VLAN) являются сетевым стандартом на основе 802.1q для создания логических разделов на одном и том же сетевом интерфейсе для изоляции обмена множества сетей.

Примечание

На стороне физического коммутатора порт должен быть настроен как trunk, от него должен приходить тэгированный трафик 802.1q.
Если на коммутаторе сделана агрегация портов (Portchannel или Etherchannel), то параметр Trunk выставляется на это новом интерфейсе.

40.5.1. Мост с поддержкой VLAN

Если используется Linux Bridge, то для возможности использования тегов VLAN в настройках ВМ необходимо включить поддержку VLAN для моста (Linux Bridge). Для этого в веб-интерфейсе в настройках моста следует установить отметку в поле Поддержка виртуальной ЛС:
Настройка сетевой конфигурации vmbr1
Если используется OVS Bridge, то никаких дополнительных настроек не требуется.
Тег VLAN можно указать в настройках сетевого интерфейса при создании ВМ, либо отредактировав параметры сетевого устройства:
Тег VLAN в настройках сетевого интерфейса ВМ

40.5.2. Мост на VLAN

Можно создать конфигурацию VLAN <интерфейс>.<vlan tag> (например, enp0s8.100), этот VLAN включить в мост Linux Bridge и указывать этот мост в настройках сетевого интерфейса ВМ.
Для создания такой конфигурации, необходимо выполнить следующие действия:
  1. Настроить VLAN с ID 100 на интерфейсе enp0s8, выполнив следующие команды:
    # mkdir /etc/net/ifaces/enp0s8.100
    # cat <<EOF > /etc/net/ifaces/enp0s8.100/options
    BOOTPROTO=static
    CONFIG_WIRELESS=no
    CONFIG_IPV4=yes
    HOST=enp0s8
    ONBOOT=yes
    TYPE=vlan
    VID=100
    EOF
    
    В опции HOST нужно указать тот интерфейс, на котором будет настроен VLAN.
  2. Настроить Ethernet-мост vmbr1, выполнив следующие команды:
    # mkdir /etc/net/ifaces/vmbr1
    # cat <<EOF > /etc/net/ifaces/vmbr1/options
    BOOTPROTO=static
    CONFIG_WIRELESS=no
    CONFIG_IPV4=yes
    HOST='enp0s8.100'
    ONBOOT=yes
    TYPE=bri
    EOF
    
    В опции HOST нужно указать VLAN-интерфейс.
  3. В файле /etc/net/ifaces/vmbr1/ipv4address, если это необходимо, можно указать IP-адрес для интерфейса моста:
    # echo "192.168.10.3/24" > /etc/net/ifaces/vmbr1/ipv4address
    
  4. Перезапустить службу network, чтобы изменения вступили в силу:
    # systemctl restart network
    
  5. Получившаяся конфигурация в веб-интерфейсе PVE:
    Конфигурация VLAN в веб-интерфейсе PVE
    Теперь в настройках сетевого интерфейса ВМ можно указать сетевой мост vmbr1 (трафик через этот интерфейс будет помечен тегом 100):
    Конфигурация VLAN в веб-интерфейсе PVE

Глава 41. Управление ISO-образами и шаблонами LXC

Для загрузки ISO-образов и шаблонов LXC в хранилище PVE следует выполнить следующие шаги:
  1. Выбрать хранилище.
  2. Перейти на вкладку ISO-образы для загрузки ISO-образов (на вкладку Шаблоны контейнеров для загрузки шаблонов LXC):
    Локальное хранилище. Вкладка ISO-образы
  3. Для загрузки образа (шаблона) с локального компьютера следует нажать кнопку Отправить. В открывшемся окне необходимо нажать кнопку Выбрать файл, выбрать файл с ISO-образом и нажать кнопку Отправить:
    Выбор файла с ISO-образом

    Примечание

    Здесь же можно выбрать алгоритм и указать контрольную сумму. В этом случае после загрузки образа будет проверена его контрольная сумма.
  4. Для загрузки образа (шаблона) с сервера следует нажать кнопку Загрузить по URL-адресу. В открывшемся окне необходимо указать ссылку на образ (шаблон) в поле URL-адрес, нажать кнопку Запрос URL-адреса, для того чтобы получить метаинформацию о файле. Нажать кнопку Загрузка для старта загрузки файла в хранилище:
    Выбор образа для загрузки файла с сервера
Для удаления ISO-образа или шаблона LXC следует выбрать файл из списка в хранилище и нажать кнопку Удалить.
PVE предоставляет базовые шаблоны для некоторых дистрибутивов Linux. Эти шаблоны можно загрузить в веб-интерфейсе или в командной строке.
Загрузка базового шаблона в веб-интерфейсе:
  1. Запустить обновление списка доступных шаблонов (например, на вкладке Оболочка):
    # pveam update
    
  2. Выбрать хранилище.
  3. Перейти на вкладку Шаблоны контейнеров и нажать кнопку Шаблоны:
    Локальное хранилище. Вкладка Шаблоны контейнеров
  4. В открывшемся окне выбрать шаблон и нажать кнопку Загрузка:
    Выбор шаблона контейнера
Загрузка базового шаблона в консоли:
  1. Запустить обновление списка доступных шаблонов:
    # pveam update
    update successful
    
  2. Просмотреть список доступных шаблонов:
    # pveam available
    mail            proxmox-mailgateway-7.3-standard_7.3-1_amd64.tar.zst
    mail            proxmox-mailgateway-8.0-standard_8.0-1_amd64.tar.zst
    system          almalinux-8-default_20210928_amd64.tar.xz
    system          almalinux-9-default_20221108_amd64.tar.xz
    system          alpine-3.16-default_20220622_amd64.tar.xz
    …
    
  3. Загрузить шаблон в хранилище local:
    # pveam download local almalinux-9-default_20221108_amd64.tar.xz
    
  4. Просмотреть список загруженных шаблонов в хранилище local:
    # pveam list local
    NAME                                                         SIZE  
    local:vztmpl/almalinux-9-default_20221108_amd64.tar.xz       97.87MB
    
Если используются только локальные хранилища, то ISO-образы и шаблоны LXC необходимо загрузить на все узлы в кластере. Если есть общее хранилище, то можно хранить все образы в одном месте, таким образом, сохраняя пространство локальных хранилищ.

Таблица 41.1. Каталоги локального хранилища

Каталог
Тип шаблона
/var/lib/vz/template/iso/
ISO-образы
/var/lib/vz/template/cache/
Шаблоны контейнеров LXC

Таблица 41.2. Каталоги общих хранилищ

Каталог
Тип шаблона
/mnt/pve/<storage_name>/template/iso/
ISO-образы
/mnt/pve/<storage_name>/template/cache/
Шаблоны контейнеров LXC

Глава 42. Виртуальные машины на базе KVM

Виртуальные машины являются строительными блоками виртуальной среды.

42.1. Создание виртуальной машины на базе KVM

Прежде чем создать в интерфейсе PVE виртуальную машину (ВМ), необходимо определиться со следующими моментами:
  • откуда будет загружен инсталлятор гостевой ОС;
  • на каком физическом узле будет выполняться процесс гипервизора kvm;
  • в каком хранилище данных будут располагаться образы дисков ВМ.
Все остальные параметры ВМ относятся к конфигурации виртуального компьютера и могут быть определены по ходу процесса создания ВМ (PVE пытается выбрать разумные значения по умолчанию для ВМ).
Чтобы установить ОС на ВМ, расположенную на этом узле, нужно обеспечить возможность загрузки инсталлятора на этой ВМ. Для этого необходимо загрузить ISO-образ инсталлятора в хранилище данных выбранного физического узла или общее хранилище. Это можно сделать в веб-интерфейсе (см. Управление ISO-образами и шаблонами LXC).
Для создания ВМ необходимо нажать кнопку Создать ВМ, расположенную в правом верхнем углу веб-интерфейса PVE:
Кнопка Создать ВМ
Процесс создания ВМ оформлен в виде «мастера», привычного для пользователей систем управления ВМ.
На вкладке Общее необходимо указать:
  • Узел — физический сервер, на котором будет работать ВМ;
  • VM ID — идентификатор ВМ в численном выражении. Одно и то же значение идентификатора не может использоваться более чем для одной машины. По умолчанию поле идентификатора ВМ заполняется автоматически инкрементально: первая созданная ВМ по умолчанию будет иметь VM ID со значением 100, следующая 101 и так далее;
  • Имя — текстовая строка названия ВМ;
  • Пул ресурсов — логическая группа ВМ. Чтобы иметь возможность выбора, пул должен быть предварительно создан.
Вкладка Общее

Примечание

Настроить диапазон, из которого выбираются новые VM ID при создании ВМ или контейнера можно, выбрав на вкладке Центр обработки данныхПараметры пункт Следующий свободный диапазон ID виртуальных машин:
Настройка диапазона VM ID
Установка нижнего значения (Нижний предел) равным верхнему (Верхний предел) полностью отключает автоподстановку VM ID.
На вкладке ОС необходимо указать источник установки ОС и тип ОС:
Вкладка ОС
В качестве источника установки ОС можно указать:
  • Использовать файл с образом CD/DVD — использовать уже загруженный в хранилище ISO-образ:
    Выбор ISO-образа
  • Использовать физический привод CD/DVD — использовать физический диск хоста PVE;
  • Не использовать носители — не использовать ISO-образ или физический носитель.
Выбор типа гостевой ОС при создании ВМ позволяет PVE оптимизировать некоторые параметры низкого уровня.
На следующем этапе (вкладка Система) можно выбрать видеокарту, контроллер SCSI, указать нужно ли использовать Агент QEMU:
Вкладка Система

Примечание

Подробнее о выборе видеокарты см. Настройки дисплея.
PVE позволяет загружать ВМ с разными прошивками (SeaBIOS и OVMF). Прошивку OVMF следует выбирать, если планируется использовать канал PCIe. При выборе прошивки OVMF (UEFI) для сохранения порядка загрузки, должен быть добавлен диск EFI (см. BIOS и UEFI):
Выбор прошивки OVMF
Тип машины ВМ определяет аппаратную компоновку виртуальной материнской платы ВМ. Доступно два варианта набора микросхем: Intel 440FX (по умолчанию) и Q35 (предоставляет виртуальную шину PCIe).
Вкладка Диски содержит следующие настройки:
  • Шина/Устройство — тип устройства виртуального диска. Допустимые значения: IDE, SATA, VirtIO Block и SCSI (по умолчанию). Можно также указать идентификатор устройства;
  • Хранилище — выбор хранилища для размещения виртуального диска (выбор хранилища определяет возможный формат образа диска);
  • Размер диска (GiB) — размер виртуального диска в гигабайтах;
  • Формат — выбирается формат образа виртуального диска. Доступные значения: Несжатый образ диска (raw), Формат образа QEMU (qcow2) и Формат образа Vmware (vmdk). Формат образа RAW является полностью выделяемым (thick-provisioned), т.е. выделяется сразу весь объем образа. QEMU и VMDK поддерживают динамичное выделение пространства (thin-provisioned), т.е. объем растет по мере сохранения данных на виртуальный диск;
  • Кэш — выбор метода кэширования ВМ. По умолчанию выбирается работа без кэширования. Доступные значения: Direct sync, Write through, Write back и Writeback (не безопасно) и Нет кэша;
  • Отклонить — если эта опция активирована и если гостевая ОС поддерживает TRIM, то это позволит очищать неиспользуемое пространство образа виртуального диска и соответственно сжимать образ диска.
Вкладка Жёсткий диск
В мастере создания ВМ можно добавить несколько дисков (кнопка Добавить):
Вкладка Жёсткий диск. Создание нескольких дисков
Максимально можно добавить: 31 диск SCSI, 16 — VirtIO, 6 — SATA, 4 — IDE.
В разделе Пропускная способность можно задать максимальную скорость чтения/записи с диска (в мегабайтах в секунду или в операциях в секунду):
Скорость чтения/записи с диска

Примечание

SCSI и VirtIO дискам может быть добавлен атрибут read-only (отметка Только для чтения):
Отметка Только для чтения
На следующем этапе настраивается процессор (CPU):
  • Сокеты — число сокетов ЦПУ для ВМ;
  • Ядра — число ядер для ВМ;
  • Тип — тип процессора.
Вкладка Процессор
Максимальное количество виртуальных процессоров в ВМ — 512.
На вкладке Память необходимо указать объем оперативной памяти выделяемой ВМ:
Вкладка Память
Максимальное количество памяти, выделяемое ВМ — 2ТБ.
Вкладка Сеть содержит следующие настройки:
  • Нет сетевого устройства — выбор данного параметра пропускает шаг настройки сетевой среды;
  • Сетевой мост — установка сетевого интерфейса в режиме моста. Это предпочтительный параметр для сетевой среды ВМ. В этом режиме возможно создание множества мостов с виртуальными сетями для создания изолированных сетей в одной и той же платформе, поскольку ВМ не имеют прямого доступа к реальной локальной сетевой среде;
  • Тег виртуальной ЛС — применяется для установки идентификатора VLAN для данного виртуального интерфейса;
  • Сетевой экран — разрешает использование для ВМ встроенных межсетевых экранов;
  • Модель — тип драйвера сетевого устройства. Для максимальной сетевой производительности ВМ следует выбрать пункт VirtIO (паравиртуализированно);
  • Адрес MAC — по умолчанию PVE автоматически создает уникальный MAC-адрес для сетевого интерфейса. Если есть такая необходимость, можно ввести пользовательский MAC-адрес вручную.
Вкладка Сеть
Последняя вкладка Подтверждение отобразит все введенные или выбранные значения для ВМ:
Вкладка Подтверждение
Для создания ВМ следует нажать кнопку Готово. Если необходимо внести изменения в параметры ВМ, можно перейти по вкладкам назад. Если отметить пункт Запуск после создания ВМ будет запущена сразу после создания.

42.2. Запуск и остановка ВМ

42.2.1. Изменение состояния ВМ в веб-интерфейсе

Запустить ВМ можно, выбрав в контекстном меню ВМ пункт Запуск:
Контекстное меню ВМ
либо нажав на кнопку Запуск:
Кнопки управления состоянием ВМ
Запустить ВМ также можно, нажав кнопку Start Now в консоли гостевой машины:
Кнопка Start Now в консоли ВМ
Запущенная ВМ будет обозначена зеленой стрелкой на значке ВМ.
Для запущенной ВМ доступны следующие действия:
  • Приостановить — перевод ВМ в спящий режим;
  • Гибернация — перевод ВМ в ждущий режим;
  • Отключить — выключение ВМ;
  • Остановка — остановка ВМ, путем прерывания её работы;
  • Перезагрузить — перезагрузка ВМ.
Контекстное меню запущенной ВМ

42.2.2. Автоматический запуск ВМ

Для того чтобы ВМ запускалась автоматически при загрузке хост-системы, необходимо отметить опцию Запуск при загрузке на вкладке Параметры требуемой ВМ в веб-интерфейсе или установить её с помощью команды:
# qm set <vmid> -onboot 1
Иногда необходимо точно настроить порядок загрузки ВМ, например, если одна из ВМ обеспечивает межсетевой экран или DHCP для других гостевых систем. Для настройки порядка запуска ВМ можно использовать следующие параметры (опция Порядок запуска и отключения на вкладке Параметры требуемой ВМ):
  • Порядок запуска и отключения — определяет приоритет порядка запуска. Для того чтобы ВМ запускалась первой, необходимо установить этот параметр в значение 1. Для выключения используется обратный порядок: ВМ, с порядком запуска 1, будет выключаться последней. Если несколько хостов имеют одинаковый порядок, определенный на хосте, они будут дополнительно упорядочены в порядке возрастания VMID;
  • Задержка запуска — определяет интервал (в секундах) между запуском этой ВМ и последующими запусками ВМ;
  • Задержка выключения — определяет время в секундах, в течение которого PVE должен ожидать, пока ВМ не перейдет в автономный режим после команды выключения. Значение по умолчанию — 180, т.е. PVE выдаст запрос на завершение работы и подождет 180 секунд, пока машина перейдет в автономный режим. Если после истечения тайм-аута машина все еще находится в сети, она будет принудительно остановлена.
Настройка порядка запуска и выключения ВМ

Примечание

Виртуальные машины, управляемые стеком HA, не поддерживают опции запуска при загрузке и порядок загрузки. Запуск и остановку таких ВМ обеспечивает диспетчер HA.
ВМ без установленного параметра Порядок запуска и отключения всегда будут запускаться после тех, для которых этот параметр установлен . Кроме того, этот параметр может применяться только для ВМ, работающих на одном хосте, а не в масштабе кластера.

42.2.3. Массовый запуск и остановка ВМ

Для массового запуска или остановки ВМ, необходимо в контекстном меню узла выбрать Массовый запуск или Массовое отключение соответственно:
Контекстное меню узла
В окрывшемся окне необходимо отметить нужные ВМ и нажать кнопку Запуск/Отключить. Для массового отключения ВМ можно также переопределить параметры Время ожидания и Принудительная остановка:
Массовое отключение ВМ

42.3. Управление ВМ с помощью qm

Если веб-интерфейс PVE недоступен, можно управлять ВМ в командной строке (используя сеанс SSH, из консоли noVNC, или зарегистрировавшись на физическом хосте).
qm — это инструмент для управления ВМ Qemu/KVM в PVE. Утилиту qm можно использовать для создания/удаления ВМ, для управления работой ВМ (запуск/остановка/приостановка/возобновление), для установки параметров в соответствующем конфигурационном файле, а также для создания виртуальных дисков.
qm <КОМАНДА> [АРГУМЕНТЫ] [ОПЦИИ]
Чтобы просмотреть доступные для управления ВМ команды можно выполнить следующую команду:
# qm help
В таблице Команды qm приведены описания команд qm.

Таблица 42.1. Команды qm

Команда
Описание
qm agent
Псевдоним для qm guest cmd
qm block <vmid>
Заблокировать ВМ.
  • vmid — идентификатор ВМ.
qm cleanup <vmid> <clean-shutdown> <guest-requested>
Очищает ресурсы, такие как сенсорные устройства, vgpu и т.д. Вызывается после выключения, сбоя ВМ и т. д.
  • vmid — идентификатор ВМ (100 — 999999999);
  • clean-shutdown — указывает, корректно ли была завершена работа qemu;
  • guest-requested — указывает, было ли завершение работы запрошено гостем или через qmp.
qm clone <vmid> <newid> [ОПЦИИ]
Создать копию ВМ/шаблона.
  • vmid — идентификатор ВМ (100 — 999999999);
  • newid — VMID для клона (100 — 999999999);
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с) (0–N);
  • --description <строка> — описание новой ВМ;
  • --format <qcow2 | raw | vmdk> — целевой формат хранения файлов (действительно только для полного клона);
  • --full <логическое значение> — создать полную копию всех дисков (используется по умолчанию при клонировании ВМ). Для шаблонов ВМ по умолчанию пытается создать связанный клон;
  • --name <строка> — имя новой ВМ;
  • --pool <строка> — пул, в который будет добавлена ВМ;
  • --snapname <строка> — имя снимка;
  • --storage <строка> — целевое хранилище для полного клона;
  • --target <строка> — целевой узел (доступно в случае, если исходная ВМ находится в общем хранилище).
qm cloudinit dump <vmid> <type>
Получить автоматически сгенерированную конфигурацию cloud-init.
  • vmid — идентификатор ВМ;
  • type — тип конфигурации (meta | network | user).
qm cloudinit pending <vmid>
Получить конфигурацию cloud-init с текущими и ожидающими значениями.
  • vmid — идентификатор ВМ.
qm cloudinit update <vmid>
Восстановить и изменить диск конфигурации cloud-init.
  • vmid — идентификатор ВМ.
qm config <vmid> <ОПЦИИ>
Вывести конфигурацию ВМ с применёнными ожидающими изменениями конфигурации. Для вывода текущей конфигурации следует указать параметр current.
  • vmid — идентификатор ВМ;
  • --current <логическое значение> — вывести текущие значения вместо ожидающих (по умолчанию 0);
  • --snapshot <строка> — вывести значения конфигурации из данного снимка.
qm create <vmid> <ОПЦИИ>
Создать или восстановить ВМ.
Некоторые опции:
  • vmid — идентификатор ВМ;
  • --acpi <логическое значение> — включить/отключить ACPI (по умолчанию 1);
  • --affinity <строка> — список ядер хоста, используемых для выполнения гостевых процессов, например: 0,5,8-11;
  • --agent [enabled=]<1|0> [,freeze-fs-on-backup=<1|0>] [,fstrim_cloned_disks=<1|0>] [,type=<virtio|isa>] — включить/отключить связь с гостевым агентом QEMU;
  • --arch <aarch64 | x86_64> — архитектура виртуального процессора;
  • --archive <строка> — создать ВМ из архива. Указывается либо путь к файлу .tar или .vma, либо идентификатор тома резервной копии хранилища PVE;
  • --args <строка> — передача произвольных аргументов в KVM;
  • --audio0 device=<ich9-intel-hda|intel-hda|AC97>[,driver=<spice|none>] — настройка аудиоустройства;
  • --balloon <целое число> — объём целевой оперативной памяти для ВМ в МиБ (0 отключает Balloon Driver);
  • --bios <ovmf | seabios> — реализация BIOS (по умолчанию seabios);
  • --boot [order=<устройство[;устройство...]>] — порядок загрузки ВМ;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --cdrom <volume> — псевдоним опции ide2;
  • --cicustom [meta=<volume>] [,network=<volume>] [,user=<volume>] [,vendor=<volume>] — cloud-init: указать пользовательские файлы для замены автоматически созданных;
  • --cipassword <пароль> — cloud-init: пароль для пользователя. Рекомендуется использовать ключи SSH вместо пароля;
  • --citype <configdrive2 | nocloud | opennebula> — формат конфигурации cloud-init;
  • --ciupgrade <логическое значение> — cloud-init: выполнить автоматическое обновление пакета после первой загрузки (по умолчанию 1);
  • --ciuser <строка> — cloud-init: имя пользователя для изменения пароля и ключей SSH вместо настроенного пользователя по умолчанию;
  • --cores <целое число> — количество ядер на сокет (по умолчанию 1);
  • --cpu <тип> — эмулируемый тип процессора;
  • --cpulimit <целое число (0–128)> — ограничение использования процессора (по умолчанию 0);
  • --cpuunits <целое число (1–262144)> — вес ЦП для ВМ будет ограничен значением [1, 10000] в cgroup v2 (по умолчанию cgroup v1: 1024, cgroup v2: 100);
  • --description <строка> — описание ВМ;
  • --efidisk0 [file=]<volume> [,efitype=<2m|4m>] [,format=<enum>] [,import-from=<source volume>] [,pre-enrolled-keys=<1|0>] [,size=<DiskSize>] — диск для хранения переменных EFI;
  • --force <логическое значение> — разрешить перезапись существующей ВМ (требуется опция --archive);
  • --freeze <логическое значение> — заморозить процессор при запуске;
  • --hookscript <строка> — скрипт, который будет выполняться на разных этапах жизненного цикла ВМ;
  • --ipconfig[n] [gw=<GatewayIPv4>] [,gw6=<GatewayIPv6>] [,ip=<IPv4Format/CIDR>] [,ip6=<IPv6Format/CIDR>] — cloud-init: указать IP-адрес и шлюз для соответствующего интерфейса;
  • --kvm <логическое значение> — включить/отключить аппаратную виртуализацию KVM (по умолчанию 1);
  • --live-restore <логическое значение> — запустить ВМ из резервной копии и восстановить её в фоновом режиме (только PBS). Требуется опция --archive;
  • --localtime <логическое значение> — установить часы реального времени (RTC) на местное время;
  • --lock <backup | clone | create | migrate | rollback | snapshot | snapshot-delete | suspended | suspending> — заблокировать/разблокировать ВМ;
  • --machine <тип> — тип машины QEMU;
  • --memory [current=]<целое число> — свойства памяти;
  • --migrate_downtime <число> — максимально допустимое время простоя (в секундах) для миграции (по умолчанию 0,1);
  • --migrate_speed <целое число> — максимальная скорость (в МБ/с) для миграции (по умолчанию 0 — не ограничивать скорость);
  • --name <строка> — имя ВМ;
  • --nameserver <строка> — cloud-init: устанавливает IP-адрес DNS-сервера для контейнера;
  • --net <сеть> — сетевые устройства;
  • --numa <логическое значение> — включить/отключить NUMA (по умолчанию 0);
  • --numa[n] <топология> — топология NUMA;
  • --onboot <логическое значение> — запускать ВМ во время загрузки системы (по умолчанию 0);
  • --ostype <l24 | l26 | other | solaris | w2k | w2k3 | w2k8 | win10 | win11 | win7 | win8 | wvista | wxp> — гостевая ОС;
  • --pool <строка> — добавить ВМ в указанный пул;
  • --protection <логическое значение> — установить флаг защиты ВМ (по умолчанию 0). Флаг защиты отключит возможность удаления ВМ и удаления дисковых операций;
  • --reboot <логическое значение> — разрешить перезагрузку (по умолчанию 1). Если установлено значение 0, ВМ завершит работу при перезагрузке;
  • --rng0 [source=] </dev/urandom|/dev/random|/dev/hwrng> [,max_bytes=<целое число>] [,period=<целое число>] — настройть генератор случайных чисел на основе VirtIO;
  • --sata[n] <описание> — использовать в качестве жёсткого диска SATA или компакт-диск (n от 0 до 5). Чтобы выделить новый том используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --scsi[n] <описание> — использовать в качестве жёсткого диска SCSI или компакт-диск (n от 0 до 30). Чтобы выделить новый том используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --scsihw <lsi | lsi53c810 | megasas | pvscsi | virtio-scsi-pci | virtio-scsi-single> — модель контроллера SCSI (по умолчанию lsi);
  • searchdomain <строка> — cloud-init: устанавить домены поиска DNS для контейнера;
  • serial[n] (/dev/.+|socket) — последовательное устройство внутри ВМ (n от 0 до 3);
  • --shares <целое число (0–50000)> — объем разделяемой памяти (по умолчанию 1000);
  • --sockets <целое число> — количество сокетов процессора (по умолчанию 1);
  • --spice_enhancements [foldersharing=<1|0>] [,videostreaming=<off|all|filter>] — настройки для SPICE;
  • --sshkeys <путь к файлу> — cloud-init: настройка публичных ключей SSH (по одному ключу в строке, формат OpenSSH);
  • --start <логическое значение> — запустить ВМ после создания (по умолчанию 0);
  • --startup `[[order=]\d+] [,up=\d+] [,down=\d+] ` — поведение при запуске и выключении. order — неотрицательное число, определяющее общий порядок запуска. Выключение выполняется в обратном порядке. up/down — задержка включения/выключения в секундах;
  • --storage <строка> — хранилище;
  • --tablet <логическое значение> — включить/отключить USB-планшет (по умолчанию 1);
  • --tags <строка> — теги ВМ;
  • --template <логическое значение> — включить/отключить шаблон (по умолчанию 0);
  • --tpmstate0 <диск> — настроить диск для хранения состояния TPM. Формат фиксированный — raw;
  • --unique <логическое значение> — назначить уникальный случайный адрес Ethernet;
  • --usb[n] [[host=]<HOSTUSBDEVICE|spice>] [,mapping=<mapping-id>] [,usb3=<1|0>] — настройка USB-устройства (n — от 0 до 4, для версии машины >= 7.1 и ostype l26 или windows > 7, n может достигать 14);
  • --vcpus <целое число> — количество виртуальных процессоров с горячим подключением;
  • --vga [[type=]<enum>] [,clipboard=<vnc>] [,memory=<целое число>] — настройка VGA;
  • virtio[n] <описание> — использовать жёсткий диск VIRTIO (n от 0 до 15);
  • vmgenid <UUID> — установить идентификатор поколения ВМ (по умолчанию 1 — генерировать автоматически);
  • --vmstatestorage <строка>  — хранилище по умолчанию для томов/файлов состояния ВМ;
  • --watchdog [[model=]<i6300esb|ib700>] [,action=<enum>]  — создать сторожевое устройство виртуального оборудования.
qm delsnapshot <vmid> <snapname> <ОПЦИИ>
Удалить снимок ВМ.
  • vmid — идентификатор ВМ;
  • snapshot — имя снимка;
  • --force <логическое значение> — удалить из файла конфигурации, даже если удаление снимков диска не удалось.
qm destroy <vmid> [ОПЦИИ]
Уничтожить ВМ и все её тома (будут удалены все разрешения, специфичные для ВМ).
  • vmid — идентификатор ВМ;
  • --destroy-unreferenced-disks <логическое значение> — дополнительно уничтожить все диски, не указанные в конфигурации, но с совпадающим VMID из всех включенных хранилищ (по умолчанию 0);
  • --purge <логическое значение> — удалить VMID из конфигураций резервного копирования и высокой доступности;
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm disk import <vmid> <source> <storage> [ОПЦИИ]
Импортировать образ внешнего диска в неиспользуемый диск ВМ. Формат образа должен поддерживаться qemu-img.
  • vmid — идентификатор ВМ;
  • source — путь к образу диска;
  • storage — идентификатор целевого хранилища;
  • --format <qcow2 | raw | vmdk> — целевой формат.
qm disk move <vmid> <disk> <storage> [ОПЦИИ]
Переместить том в другое хранилище или в другую ВМ.
  • vmid — идентификатор ВМ;
  • disk — диск, который необходимо переместить (например, scsi1);
  • storage — целевое хранилище;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --delete <логическое значение> — удалить исходный диск после успешного копирования. По умолчанию исходный диск сохраняется как неиспользуемый (по умолчанию 0);
  • --digest <строка> — запретить изменения, если текущий файл конфигурации имеет другой SHA1 дайджест (можно использовать для предотвращения одновременных изменений);
  • --format <qcow2 | raw | vmdk> — целевой формат;
  • --target-digest <строка> — запретить изменения, если текущий файл конфигурации целевой ВМ имеет другой SHA1 дайджест (можно использовать для обнаружения одновременных модификаций);
  • --target-disk <efidisk0 | ide0 | ide1| …| virtio9 > — ключ конфигурации, в который будет перемещен диск на целевой ВМ (например, ide0 или scsi1). По умолчанию используется ключ исходного диска;
  • --target-vmid <целое число> — идентификатор целевой ВМ.
qm disk rescan [ОПЦИИ]
Пересканировать все хранилища и обновить размеры дисков и неиспользуемые образы дисков.
  • --dryrun <логическое значение> — не записывать изменения в конфигурацию ВМ (по умолчанию 0);
  • --vmid <целое число> — идентификатор ВМ.
qm disk resize <vmid> <disk> <size> [ОПЦИИ]
Увеличить размер диска.
  • vmid — идентификатор ВМ;
  • disk — диск, размер которого необходимо увеличить (например, scsi1);
  • size — новый размер. Со знаком «+» значение прибавляется к фактическому размеру тома, а без него значение принимается как абсолютное. Уменьшение размера диска не поддерживается;
  • --digest <строка> — запретить изменения, если текущий файл конфигурации имеет другой SHA1 дайджест (можно использовать для предотвращения одновременных изменений);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm disk unlink <vmid> --idlist <строка> [ОПЦИИ]
Отсоединить/удалить образы дисков.
  • vmid — идентификатор ВМ;
  • --idlist <строка> — список идентификаторов дисков, которые необходимо удалить;
  • --force <логическое значение> — принудительное физическое удаление (иначе диск будет удалён из файла конфигурации и будет создана дополнительная запись конфигурации с именем unused[n], которая содержит идентификатор тома).
qm guest cmd <vmid> <команда>
Выполнить команды гостевого агента QEMU.
  • vmid — идентификатор ВМ;
  • команда — команда QGA (fsfreeze-freeze | fsfreeze-status | fsfreeze-thaw | fstrim | get-fsinfo | get-host-name | get-memory-block-info | get-memory-blocks | get-osinfo | get-time | get-timezone | get-users | get-vcpus | info | network-get-interfaces | ping | shutdown | suspend-disk | suspend-hybrid | suspend-ram).
qm guest exec <vmid> [<extra-args>] [ОПЦИИ]
Выполнить данную команду через гостевой агент.
  • vmid — идентификатор ВМ;
  • extra-args — дополнительные аргументы в виде массива;
  • --pass-stdin <логическое значение> — если установлено, читать STDIN до EOF и пересылать гостевому агенту через входные данные (по умолчанию 0). Допускается максимум 1 МБ;
  • --synchronous <логическое значение> — если установлено значение 0, возвращает pid немедленно, не дожидаясь завершения команды или тайм-аута (по умолчанию 1);
  • --timeout <целое число> — максимальное время синхронного ожидания завершения команды. Если достигнуто, возвращается pid. Для отключения следует установить значение 0 (по умолчанию 30).
qm guest exec-status <vmid> <pid>
Получить статус данного pid, запущенного гостевым агентом.
  • vmid — идентификатор ВМ;
  • pid — PID для запроса.
qm guest passwd <vmid> <username> [ОПЦИИ]
Установить пароль для данного пользователя.
  • vmid — идентификатор ВМ;
  • username — пользователь, для которого устанавливается пароль;
  • crypted <логическое значение> — если пароль уже был передан через crypt(), следует установить значение 1 (по умолчанию 0).
qm help [extra-args] [ОПЦИИ]
Показать справку по указанной команде.
  • extra-args — показать справку по конкретной команде;
  • --verbose <логическое значение> — подробный формат вывода.
qm importdisk
Псевдоним для qm disk import.
qm importovf <vmid> <manifest> <storage> [ОПЦИИ]
Создать новую ВМ, используя параметры, считанные из манифеста OVF.
  • vmid — идентификатор ВМ;
  • manifest — путь до файла ovf;
  • storage — идентификатор целевого хранилища;
  • --format <qcow2 | raw | vmdk> — целевой формат.
qm list [ОПЦИИ]
Вывести список ВМ узла.
  • --full <логическое значение> — определить полный статус активных ВМ.
qm listsnapshot <vmid>
Вывести список снимков ВМ.
  • vmid — идентификатор ВМ;
qm migrate <vmid> <target> [ОПЦИИ]
Перенос ВМ. Создаёт новую задачу миграции.
  • vmid — идентификатор ВМ;
  • target — целевой узел;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --force <логическое значение> — разрешить миграцию ВМ, использующих локальные устройства (может использовать только root);
  • --migration_network <строка> — CIDR (под)сети, которая используется для миграции;
  • --migration_type <insecure | secure> — трафик миграции по умолчанию шифруется с использованием SSH-туннеля. В безопасных сетях эту функцию можно отключить для повышения производительности;
  • --online <логическое значение> — использовать онлайн-/живую миграцию, если ВМ запущена (игнорируется, если ВМ остановлена);
  • --targetstorage <строка> — сопоставление исходных и целевых хранилищ. Предоставление только одного идентификатора хранилища сопоставляет все исходные хранилища с этим хранилищем. Если указать специальное значение 1, каждое исходное хранилище будет сопоставлено самому себе;
  • --online <логическое значение> — включить живую миграцию хранилища для локального диска.
qm monitor <vmid>
Войти в интерфейс монитора QEMU.
  • vmid — идентификатор ВМ.
qm move-disk
Псевдоним для qm disk move.
qm move_disk
Псевдоним для qm disk move.
qm nbdstop <vmid>
Остановить встроенный сервер NBD.
  • vmid — идентификатор ВМ.
qm pending <vmid>
Получить конфигурацию ВМ с текущими и ожидающими значениями.
  • vmid — идентификатор ВМ.
qm reboot <vmid> [ОПЦИИ]
Перезагрузить ВМ. Применяет ожидающие изменения.
  • vmid — идентификатор ВМ;
  • --timeout <целое число> — максимальное время ожидания для выключения.
qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <строка> --target-storage <строка> [ОПЦИИ]
Перенос ВМ в удалённый кластер. Создаёт новую задачу миграции. ЭКСПЕРИМЕНТАЛЬНАЯ функция!
  • vmid — идентификатор ВМ;
  • target-vmid — идентификатор целевой ВМ;
  • target-endpoint — удалённая целевая конечная точка. Удалённая точка указывается в формате: apitoken=<API-токен PVE, включая секретное значение> ,host=<имя или IP удалённого узла> [,fingerprint=<отпечаток сертификата удаленного хоста, если ему не доверяет системное хранилище>] [,port=<целое число>];
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --delete <логическое значение> — удалить исходную ВМ и связанные с ней данные после успешной миграции (по умолчанию 0). По умолчанию исходная ВМ остается в исходном кластере в остановленном состоянии;
  • --online <логическое значение> — использовать онлайн-/живую миграцию, если ВМ запущена (игнорируется, если ВМ остановлена);
  • --target-bridge <строка> — сопоставление исходных и целевых мостов. Предоставление только одного идентификатора моста сопоставляет все исходные мосты с этим мостом. Предоставление специального значения 1 сопоставит каждый исходный мост с самим собой;
  • --target-storage <строка> — сопоставление исходных и целевых хранилищ. Предоставление только одного идентификатора хранилища сопоставляет все исходные хранилища с этим хранилищем. Если указать специальное значение 1, каждое исходное хранилище будет сопоставлено самому себе;
  • --online <логическое значение> — включить живую миграцию хранилища для локального диска.
qm rescan
Псевдоним для qm disk rescan.
qm reset <vmid> [ОПЦИИ]
Сбросить ВМ.
  • vmid — идентификатор ВМ;
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm resize
Псевдоним для qm disk resize.
qm resume <vmid> [ОПЦИИ]
Возобновить работу ВМ.
  • vmid — идентификатор ВМ;
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm rollback <vmid> <snapname> [ОПЦИИ]
Откат состояния ВМ до указанного снимка.
  • vmid — идентификатор ВМ;
  • snapname — имя снимка;
  • --start <логическое значение> — запустить ВМ после отката (по умолчанию 0). ВМ будут запускаться автоматически, если снимок включает ОЗУ.
qm sendkey <vmid> <ключ> [ОПЦИИ]
Послать нажатия клавиш на ВМ.
  • vmid — идентификатор ВМ;
  • ключ — ключ (в кодировке qemu monitor, например, ctrl-shift);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm set <vmid> [ОПЦИИ]
Установить параметры ВМ.
Некоторые опции:
  • vmid — идентификатор ВМ;
  • --acpi <логическое значение> — включить/отключить ACPI (по умолчанию 1);
  • --affinity <строка> — список ядер хоста, используемых для выполнения гостевых процессов, например: 0,5,8-11;
  • --agent [enabled=]<1|0> [,freeze-fs-on-backup=<1|0>] [,fstrim_cloned_disks=<1|0>] [,type=<virtio|isa>] — включить/отключить связь с гостевым агентом QEMU;
  • --arch <aarch64 | x86_64> — архитектура виртуального процессора;
  • --args <строка> — передача произвольных аргументов в KVM;
  • --audio0 device=<ich9-intel-hda|intel-hda|AC97>[,driver=<spice|none>] — настройка аудиоустройства;
  • --balloon <целое число> — объём целевой оперативной памяти для ВМ в МиБ (0 отключает Balloon Driver);
  • --bios <ovmf | seabios> — реализация BIOS (по умолчанию seabios);
  • --boot [order=<устройство[;устройство...]>] — порядок загрузки ВМ;
  • --cdrom <volume> — псевдоним опции ide2;
  • --cicustom [meta=<volume>] [,network=<volume>] [,user=<volume>] [,vendor=<volume>] — cloud-init: указать пользовательские файлы для замены автоматически созданных;
  • --cipassword <пароль> — cloud-init: пароль для пользователя. Рекомендуется использовать ключи SSH вместо пароля;
  • --citype <configdrive2 | nocloud | opennebula> — формат конфигурации cloud-init;
  • --ciupgrade <логическое значение> — cloud-init: выполнить автоматическое обновление пакета после первой загрузки (по умолчанию 1);
  • --ciuser <строка> — cloud-init: имя пользователя для изменения пароля и ключей SSH вместо настроенного пользователя по умолчанию;
  • --cores <целое число> — количество ядер на сокет (по умолчанию 1);
  • --cpu <тип> — эмулируемый тип процессора;
  • --cpulimit <целое число (0–128)> — ограничение использования процессора (по умолчанию 0);
  • --cpuunits <целое число (1–262144)> — вес ЦП для ВМ будет ограничен значением [1, 10000] в cgroup v2 (по умолчанию cgroup v1: 1024, cgroup v2: 100);
  • --delete <строка> — список настроек, которые необходимо удалить;
  • --description <строка> — описание ВМ;
  • --digest <строка> — запретить изменения, если текущий файл конфигурации имеет другой дайджест SHA1 (можно использовать для предотвращения одновременных изменений);
  • --efidisk0 [file=]<volume> [,efitype=<2m|4m>] [,format=<enum>] [,import-from=<source volume>] [,pre-enrolled-keys=<1|0>] [,size=<DiskSize>] — диск для хранения переменных EFI;
  • --force <логическое значение> — разрешить перезапись существующей ВМ (требуется опция --archive);
  • --freeze <логическое значение> — заморозить процессор при запуске;
  • --hookscript <строка> — описание ВМ;
  • --hostpci[n] [описание] — сопоставить PCI-устройства хоста с гостевыми устройствами;
  • --ide[n] [описание] — использовать в качестве жёсткого диска IDE или компакт-диск (n от 0 до 3). Чтобы выделить новый том используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --ipconfig[n] [gw=<GatewayIPv4>] [,gw6=<GatewayIPv6>] [,ip=<IPv4Format/CIDR>] [,ip6=<IPv6Format/CIDR>] — cloud-init: указать IP-адрес и шлюз для соответствующего интерфейса;
  • --kvm <логическое значение> — включить/отключить аппаратную виртуализацию KVM (по умолчанию 1);
  • --localtime <логическое значение> — установите часы реального времени (RTC) на местное время;
  • --lock <backup | clone | create | migrate | rollback | snapshot | snapshot-delete | suspended | suspending> — заблокировать/разблокировать ВМ;
  • --machine <тип> — тип машины QEMU;
  • --memory [current=]<целое число> — свойства памяти;
  • --migrate_downtime <число> — максимально допустимое время простоя (в секундах) для миграции (по умолчанию 0,1);
  • --migrate_speed <целое число> — максимальная скорость (в МБ/с) для миграции (по умолчанию 0 — не ограничивать скорость);
  • --name <строка> — имя ВМ;
  • --nameserver <строка> — cloud-init: уста