Где proxmox хранит диски виртуальных машин
Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.
понедельник, 16 декабря 2019 г.
Восстановление из резервной копии
Рассмотрим ситуацию, когда виртуальную машину случайно удалили и требуется ее экстренное восстановление из резервной копии:
- Открываем хранилище, на котором лежит резервная копия.
- Переходим на вкладку Содержимое.
- Выбираем нужную копию и нажимаем кнопку Восстановление.
Конфигурация хранилища
Все связанные с Proxmox VE конфигурации хранилища хранятся в одном текстовом файле по адресу /etc/pve/storage.cfg
Пулы Хранения
Каждый пул хранения имеет
Конфигурация пула выглядит следующим образом: Строкой : начинается определение пула, затем следует список свойств. Большинство свойств требуют значения, но некоторые имеют разумные значения по умолчанию. В этом случае вы можете опустить значение.
Чтобы быть более конкретным, взгляните на конфигурацию хранилища по умолчанию после установки. Он содержит один специальный локальный пул хранения с именем local, который ссылается на каталог /var/lib/vz и всегда доступен. Программа установки Proxmox VE создает дополнительные записи хранилища в зависимости от типа хранилища, выбранного во время установки.
Конфигурация хранилища по умолчанию ( /etc/pve/storage.cfg )
Общие свойства хранилищ
Владелец тома
Существует отношение собственности для томов типа образ. Каждый такой Том принадлежит виртуальной машине или контейнеру. Например, том local:230/example-image.raw принадлежит VM 230. Большинство серверных систем хранения данных кодирует эту информацию о владельце в имя Тома.
Common Storage Properties
A few storage properties are common among different storage types.
List of cluster node names where this storage is usable/accessible. One can use this property to restrict storage access to a limited set of nodes.
A storage can support several content types, for example virtual disk images, cdrom iso images, container templates or container root directories. Not all storage types support all content types. One can set this property to select what this storage is used for.
KVM-Qemu VM images.
Allow to store container data.
Backup files ( vzdump ).
Snippet files, for example guest hook scripts
Mark storage as shared.
You can use this flag to disable the storage completely.
Deprecated, please use prune-backups instead. Maximum number of backup files per VM. Use 0 for unlimited.
Retention options for backups. For details, see Backup Retention.
Default image format ( raw|qcow2|vmdk )
Preallocation mode ( off|metadata|falloc|full ) for raw and qcow2 images on file-based storages. The default is metadata , which is treated like off for raw images. When using network storages in combination with large qcow2 images, using off can help to avoid timeouts.
It is not advisable to use the same storage pool on different Proxmox VE clusters. Some storage operation need exclusive access to the storage, so proper locking is required. While this is implemented within a cluster, it does not work between different clusters. |
Работа с образами дисков
В комплекте c Proxmox есть очень удобная утилита, под названием qemu-img. Одной из ее функций является конвертирование образов виртуальных дисков. Чтобы воспользоваться им, достаточно открыть консоль гипервизора и выполнить команду в формате:
Благодаря этой же команде можно принудительно создать нужный образ, используя аргумент create:
Такая команда создаст образ test в формате RAW, размером 40 Гб. Теперь он годится для подключения к любой из виртуальных машин.
File naming conventions
This backend uses a well defined naming scheme for VM images:
This specifies the owner VM.
This can be an arbitrary name ( ascii ) without white space. The backend uses disk-[N] as default, where [N] is replaced by an integer to make the name unique.
Specifies the image format ( raw|qcow2|vmdk ).
When you create a VM template, all VM images are renamed to indicate that they are now read-only, and can be used as a base image for clones:
Such base images are used to generate cloned images. So it is important that those files are read-only, and never get modified. The backend changes the access mode to 0444 , and sets the immutable flag ( chattr +i ) if the storage supports that. |
Example: Add Storage over CLI
Then you could add this share as a storage to the whole Proxmox VE cluster with:
Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.
Configuration
The backend supports all common storage properties, except the shared flag, which is always set. Additionally, the following CIFS special properties are available:
Server IP or DNS name. Required.
To avoid DNS lookup delays, it is usually preferable to use an IP address instead of a DNS name - unless you have a very reliable DNS server, or list the server in the local /etc/hosts file. |
CIFS share to use (get available ones with pvesm scan cifs or the WebUI). Required.
The username for the CIFS storage. Optional, defaults to ‘guest’.
The user password. Optional. It will be saved in a file only readable by root ( /etc/pve/priv/storage/.pw ).
Sets the user domain (workgroup) for this storage. Optional.
SMB protocol Version. Optional, default is 3 . SMB1 is not supported due to security issues.
The local mount point. Optional, defaults to /mnt/pve// .
Proxmox Backup Server
Storage pool type: pbs
This backend allows direct integration of a Proxmox Backup Server into Proxmox VE like any other storage. A Proxmox Backup storage can be added directly through the Proxmox VE API, CLI or the webinterface.
Панель Содержимого
Датацентр
- Поиск: можно искать что-либо в кластере, это может быть узел, виртуальная машина, контейнер, хранилище или пул.
- Сводка: дает краткий обзор работоспособности кластера.
- Кластер: позволяет создать/присоединиться к кластеру и показывает информацию о присоединении.
- Параметры: можно показать и установить значения по умолчанию, которые применяются в масштабах кластера.
- Хранилище: здесь хранилище можно добавить/настроить/удалить.
- Резервное копирование: доступ к планировщику резервного копирования. Это общие настройки кластера, поэтому для расписания не важно, где находится виртуальная машина/контейнер в вашем кластере.
- Репликация: показывает задания репликации и позволяет создавать новые.
- Разрешения: здесь можно настроить разрешение пользователя и группы, LDAP, MS-AD и двухфакторную аутентификацию.
- HA: управление высокой доступностью в Proxmox VE
- Брандмауэр: на этом уровне брандмауэр Proxmox работает по всему кластеру и делает шаблоны доступными для всего кластера.
- Поддержка: здесь вы получите всю информацию о Вашей подписке на поддержку.
На этом уровне Узлы кластера могут управляться индивидуально.
Гости
Есть два различных типа гостей, и оба могут быть преобразованы в шаблон. Один из них-это виртуальная машина на основе ядра (KVM), а другой-контейнер Linux (LXC). Как правило, навигация одинакова, только некоторые параметры отличаются.
В главном центре управления навигация по виртуальной машине начинается, если виртуальная машина выбрана в левом дереве.
Верхний заголовок содержит важные команды работы виртуальной машины, такие как запуск, выключение, сброс, удаление, перенос, консоль и справка. Некоторые из них имеют скрытые кнопки, такие как Shutdown has Stop, а консоль содержит различные типы консолей SPICE, noVNC и xterm.js.
Справа содержимое изменяется в зависимости от выбранного параметра.
С левой стороны. Все доступные опции перечислены одна под другой.
- Сводка: дает краткий обзор состояния виртуальной машины.
- Консоль: интерактивная консоль для виртуальной машины.
- (KVM)оборудование: показывает и устанавливает оборудование виртуальной машины KVM.
- (LXC)ресурсы: определяет аппаратные возможности LXC.
- (LXC)сеть: параметры сети LXC.
- (LXC)DNS: параметры DNS LXC.
- Опции: все опции для гостей настраиваются здесь.
- История задач: здесь будут показаны все предыдущие задачи от выбранного гостя.
- Монитор (KVM): это интерактивный коммуникационный интерфейс для процесса KVM.
- Резервное копирование: показывает доступные резервные копии из выбранного гостя, а также создает резервную копию.
- Репликация: показывает задания репликации для выбранного гостя и позволяет создавать новые задания.
- Моментальные снимки: управление моментальными снимками виртуальной машины.
- Брандмауэр: управление брандмауэром на уровне виртуальной машины.
- Разрешения: управление пользовательским разрешением для выбранного гостя.
Хранилища
- Сводка: показывает важную информацию о хранилищах, таких как использование, тип, содержание, активный и включен.
- Содержимое: Здесь отображается содержимое сгруппированное по типу.
- Разрешения: управление разрешениями пользователя для этого хранилища.
- Сводка: Показывает описание пула.
- Члены: Здесь будут перечислены все члены этого пула и доступно управление ими.
- Разрешения: управление разрешениями пользователя для этого пула.
22 комментария:
Фантастика. Новая глава - не прошло и недели. Александр, спасибище. А как быть если у меня появляются практические вопросы по проектированию/установке/настройкам/практической работе с Proxmox? Именно практические, ответы на которые, возможно, очевидны практикам, уже работающим с Proxmox продолжительное время? Можно ли завести в блоге некий FAQ для всех и дополнять его периодически?
Ну тогда начну с самых простеньких но для меня как начавшего работать практически с Proxmox c месяц назад пока что безответных. Кстати, опыта работы с Linux у меня тоже нет и потому конечно же наверняка эти вопросы могут быть интересны опять же только таким же как и я, имеющие таковой опыт наверняка уже давным-давно знают на них ответы, но всё же.
1. Насколько интенсивно работает с диском где он сам установлен Proxmox? Может ли он сам быть установлен на промышленного типа DOM-носитель (SATA или USB 2.0) а его логи и конфигурационные файлы вынесены отдельно (если в этом есть смысл)? Оправдана ли будет его установка на SSD? Сейчас у меня он установлен на старый SATA HDD 160 Gb.
2. Как правильно разбивать на разделы диск для установки Proxmox? Нужен ли ему SWAP-раздел и какой именно объём в зависимости от установленной RAM? Имеет ли смысл изначальная установка самого Proxmox сразу на создаваемый непосредственно при инсталляции том ZFS (а инсталлятор такое позволяет сейчас)?
3. Установил NVME диск для размещения дисков виртуальных машин, при подключении нужно выбрать файловую систему для него, xfs или ext4 - что выбрать и почему именно? На что это будет влиять? Какой образ диска виртуальной машины предпочтительнее: raw или qcow2? Как его переносить между хранилищами на одной и той же ноде (нечто вроде миграции по прямому указанию администратора) Почему формат образа диска при переносе может самопроизвольно поменяться (например из raw в qcow2)?
4. Я так понял что после создания пула дисков zfs добавить к ним новые нельзя даже если только для конвертации имеющегося raid-z1 в raid-z2 или raid-z3. А что тогда делают команды add и attach?
Пока хватит вопросов, буду признателен за ответы, Александр!
1. Я для Proxmox использую старые SAS Диски 32/72Gb. Файловая система ZFS - у меня был пост по сравнению производительности FS. В более ранних установках использовал настройки по умолчанию. Есть установки на SSD. Был случай выхода SSD из строя, после которого я начал добавлять в планировщике принудительный трим. Интенсивность использования ресурсов можно смотреть в разделе сводка ноды.
2. Я использую маленькие диски 30-120Gb(SAS или SSD), которые Полностью используются только Proxmox, поэтому разбиваю по умолчанию, на SSD своп выключаю, чтоб не умер, на шпиндельных делаю 1-2Gb(у меня в серверах минимум 96Gb RAM)
3. Для хранилища я использую только ZFS или Ceph, так как мне важна высокая доступность, образы использую raw, какой предпочтительнее не скажу.
4. В пулы диски добавлять можно, некоторые типы пулов можно преобразовывать из одного в другой.
4. На самом деле большинство Ваших вопросов достаточно подробно освещены в руководстве.
Убить разметку помогает dd if=/dev/zero of=/dev/sd[X] bs=1M count=1024
С xfs дела не имел, возможно ваш дитк имеет MBR разметку, а требуется GPT.
Нет, диск изначально был виден как GPT, а я ещё раз принудительно его повторно инициализировал как GPT из GUI Proxmox - это точно.
Про эту команду почитаю и попробую, спасибо!
Спасибо за сверхоперативные ответы, правда мне пока не всё понятно, к примеру как отделить интенсивность работы с диском самого Proxmox для своей работы от работы дисковой подсистемы ноды для виртуальных машин - график-то один на всё (вроде как, нет сейчас перед глазами)!
Так-то у меня в планах как раз и наладить постоянный бекап образов виртуальных машин с накопителя NVME на пул ZFS для их надёжного хранения - тогда можно будет безбоязненно работать с единственным диском NVME зная что пару раз за день он бэкапится и не переживать, но это всё будет описано в следующих главах перевода так что я пока что жду его. Кстати о размерах RAM на сервере - у меня тоже будет 96 Gb - купил и жду когда доставят, к сожалению это максимальный объём для этого сервера (Supermicro X8DTL-iF) - если считать что этот сервер планируется сделать гиперконвергентным и отдавать половину памяти виртуальным машинам то с оставшейся половиной каков объём дисковой подсистемы ZFS возможен для комфортной работы? Влияет ли число дисков на этот показатель? - тут я имею в виду есть ли разница для производительности и потребления памяти между, к примеру, 8 дисками по 2 ТБ или 4 дисками по 4 ТБ?
Советы по улучшению производительности ZFS
ZFS использует много памяти, поэтому лучше всего добавить дополнительную оперативную память, если вы хотите использовать ZFS. Хороший расчет-это 4 ГБ плюс 1 ГБ оперативной памяти для каждого ТБ необработанного дискового пространства.
Заключение
Нами были рассмотрены штатные способы резервного копирования и восстановления виртуальных машин. Их использование позволяет без особых проблем сохранять все данные и экстренно восстановить их в случае нештатной ситуации.
Конечно, это не единственный возможный способ сохранения важных данных. Существует множество инструментов, например, Duplicity, с помощью которых можно создавать полные и инкрементные копии содержимого виртуальных серверов на базе Linux.
При выполнении процедур резервного копирования всегда следует учитывать, что они активно нагружают дисковую подсистему. В связи с этим выполнять эти процедуры рекомендуется в моменты минимальной нагрузки, чтобы избежать задержек при выполнении операций ввода-вывода внутри машин. Следить за статусом задержек дисковых операций можно непосредственно из веб-интерфейса гипервизора (параметр IO delay).
Добрый день. Достались мне по гос контракте сервера от поставщика с виртуальными машинами на proxmox.
В админке вижу созданы 2 storage:
local, тип Directory, содержимое backup
iso и pve тип LVM, содержимое images.
Стоит 2 параллельные задачи:
1- Хочу перенести виртуальные машины с proxmox на vmware, не могу найти где на сервере лежат образы машин в raw формате, что бы с конвертировать его в формат vmware.
2 - Хочу перенести виртуальные машины на другой сервер, поднял на нем proxmox, скопировал в папку /var/lib/vz/dump образы бэкапов, в админке их не вижу. Как можно их восстановить на новом сервере?
1) /var/lib/vz/images/ ,если не указано другое, вообще можно посмотреть через веб морду Датацентр-Хранилище. RAW формата может и не быть, все машины могут лежать в более современном qcow2, тогда сначала конввертим в raw, затем в vmware.
2) Вы не указали, что бэкапы должны лежать там, заходим в Датацентр-Хранилище, открываем на изменение local, там выделяем поле . backup.
P.S. Я так понимаю, что цену на vmware вы уже видели, согласовали с руководством и оно готово заплатить кучу денег за ваше неумение пользоваться открытыми инструментами, Proxmox в ровных руках ничем не хуже, а в ситуации, когда много контейнеров даже лучше продуктов vmware, в чем смысл перехода, если и так все работает?
1)Смотрел /var/lib/vz/ через mc, папки images нет.
В веб-морде такая настройка:
2) Спасибо, именно эту отметку пропустил. Восстановил виртуальную машину на новом сервере Proxmox VE 3.4, до этого виртуальная машина крутилась на более старом Proxmox-е 2.6.32.-16.
При запуске востановленной виртуальной машины выходит ошибка:
Не могу понять на что ругается.
P.S. На vmware цены смотрел. Я только начал заниматься визуализацией, и еще не знаю что выбрать.
И еще вопрос, когда в proxmox добавляю раздел LVM поле "Группа разделов" пустая, где её нужно заполнить?
The Proxmox VE storage model is very flexible. Virtual machine images can either be stored on one or several local storages, or on shared storage like NFS or iSCSI (NAS, SAN). There are no limits, and you may configure as many storage pools as you like. You can use all storage technologies available for Debian Linux.
One major benefit of storing VMs on shared storage is the ability to live-migrate running machines without any downtime, as all nodes in the cluster have direct access to VM disk images. There is no need to copy VM image data, so live migration is very fast in that case.
The storage library (package libpve-storage-perl ) uses a flexible plugin system to provide a common interface to all storage types. This can be easily adopted to include further storage types in the future.
Configuration
This backend supports all common storage properties, and adds an additional property called path to specify the directory. This needs to be an absolute file system path.
The above configuration defines a storage pool called backup . That pool can be used to store up to 7 regular backups ( keep-last=7 ) and 3 protected backups per VM. The real path for the backup files is /mnt/backup/dump/. .
Хранилище Proxmox VE
Одним из основных преимуществ хранения виртуальных машин в общем хранилище является возможность оперативной миграции работающих машин без простоев, поскольку все узлы в кластере имеют прямой доступ к образам дисков виртуальных машин. Нет необходимости копировать данные образа виртуальной машины, поэтому динамическая миграция в этом случае выполняется очень быстро.
Examples
Add storage pools
Disable storage pools
Enable storage pools
Change/set storage options
Remove storage pools. This does not delete any data, and does not disconnect or unmount anything. It just removes the storage configuration.
Allocate a 4G volume in local storage. The name is auto-generated if you pass an empty string as
List storage status
List storage contents
List volumes allocated by VMID
List iso images
List container templates
Show file system path for a volume
Exporting the volume local:103/vm-103-disk-0.qcow2 to the file target . This is mostly used internally with pvesm import . The stream format qcow2+size is different to the qcow2 format. Consequently, the exported file cannot simply be attached to a VM. This also holds for the other formats.
Directory Backend
Storage pool type: dir
Proxmox VE can use local directories or locally mounted shares for storage. A directory is a file level storage, so you can store any content type like virtual disk images, containers, templates, ISO images or backup files.
You can mount additional storages via standard linux /etc/fstab , and then define a directory storage for that mount point. This way you can use any file system supported by Linux. |
This backend assumes that the underlying directory is POSIX compatible, but nothing else. This implies that you cannot create snapshots at the storage level. But there exists a workaround for VM images using the qcow2 file format, because that format supports snapshots internally.
Some storage types do not support O_DIRECT , so you can’t use cache mode none with such storages. Simply use cache mode writeback instead. |
We use a predefined directory layout to store different content types into different sub-directories. This layout is used by all file level storage backends.
Configuration
The backend supports all common storage properties, except the shared flag, which is always set. Additionally, the following properties are used to configure the NFS server:
Server IP or DNS name. To avoid DNS lookup delays, it is usually preferable to use an IP address instead of a DNS name - unless you have a very reliable DNS server, or list the server in the local /etc/hosts file.
NFS export path (as listed by pvesm nfsscan ).
You can also set NFS mount options:
The local mount point (defaults to /mnt/pve// ).
NFS mount options (see man nfs ).
After an NFS request times out, NFS request are retried indefinitely by default. This can lead to unexpected hangs on the client side. For read-only content, it is worth to consider the NFS soft option, which limits the number of retries to three. |
Storage Configuration
All Proxmox VE related storage configuration is stored within a single text file at /etc/pve/storage.cfg . As this file is within /etc/pve/ , it gets automatically distributed to all cluster nodes. So all nodes share the same storage configuration.
Sharing storage configuration makes perfect sense for shared storage, because the same “shared” storage is accessible from all nodes. But it is also useful for local storage types. In this case such local storage is available on all nodes, but it is physically different and can have totally different content.
Storage Features
Proxmox Backup Server only supports backups, they can be block-level or file-level based. Proxmox VE uses block-level for virtual machines and file-level for container.
Examples
Please use the following command to allocate a 4GB image on storage local :
The image name must conform to above naming conventions. |
The real file system path is shown with:
And you can remove the image with:
Examples
You can get a list of exported NFS shares with:
Configuration
The backend supports all common storage properties, except the shared flag, which is always set. Additionally, the following special properties to Proxmox Backup Server are available:
Server IP or DNS name. Required.
The username for the Proxmox Backup Server storage. Required.
Do not forget to add the realm to the username. For example, root@pam or archiver@pbs . |
The user password. The value will be saved in a file under /etc/pve/priv/storage/.pw with access restricted to the root user. Required.
The ID of the Proxmox Backup Server datastore to use. Required.
The fingerprint of the Proxmox Backup Server API TLS certificate. You can get it in the Servers Dashboard or using the proxmox-backup-manager cert info command. Required for self-signed certificates or any other one where the host does not trusts the servers CA.
A key to encrypt the backup data from the client side. Currently only non-password protected (no key derive function (kdf)) are supported. Will be saved in a file under /etc/pve/priv/storage/.enc with access restricted to the root user. Use the magic value autogen to automatically generate a new one using proxmox-backup-client key create --kdf none . Optional.
A public RSA key used to encrypt the backup encryption key as part of the backup task. The encrypted copy will be appended to the backup and stored on the Proxmox Backup Server instance for recovery purposes. Optional, requires encryption-key .
Автоматизация создания резервных копий
Использование ручного способа создания резервных копий — задача весьма трудоемкая и занимает много времени. Поэтому Proxmox VE содержит в себе средство для автоматического резервного копирования по расписанию. Рассмотрим, как это сделать:
- Используя веб-интерфейс гипервизора, открываем пункт Датацентр.
- Выбираем пункт Резервирование.
- Нажимаем кнопку Добавить.
- Задаем параметры для планировщика.
CIFS Backend
Storage pool type: cifs
The CIFS backend extends the directory backend, so that no manual setup of a CIFS mount is needed. Such a storage can be added directly through the Proxmox VE API or the WebUI, with all our backend advantages, like server heartbeat check or comfortable selection of exported shares.
Storage Features
CIFS does not support snapshots on a storage level. But you may use qcow2 backing files if you still want to have snapshots and cloning features available.
images rootdir vztmpl iso backup snippets
Форматы виртуальных накопителей
Расскажем подробнее об используемых в Proxmox форматах накопителей:
-
RAW. Самый понятный и простой формат. Это файл с данными жесткого диска «байт в байт» без сжатия или оптимизации. Это очень удобный формат, поскольку его легко смонтировать стандартной командой mount в любой linux-системе. Более того это самый быстрый «тип» накопителя, так как гипервизору не нужно его никак обрабатывать.
Небольшим минусом работы с этим форматом является следующее: чтобы примонтировать такой образ в любой другой системе, потребуется вначале загрузить особый драйвер nbd, а также использовать утилиту qemu-nbd, которая позволит операционной системе обращаться к файлу как к обычному блочному устройству. После этого образ станет доступен для монтирования, разбиения на разделы, осуществления проверки файловой системы и прочих операций.
Обзор графического интерфейса
Пользовательский интерфейс Proxmox VE состоит из четырех областей:
Верхняя панель
На ее левой стороне, первое, что вы видите, это логотип Proxmox. Рядом находится версия запущенной Proxmox VE. В строке поиска рядом вы можете искать определенные объекты (виртуальные машины, контейнеры, узлы, . ). Иногда это происходит быстрее, чем выбор объекта в дереве ресурсов.
Справа от строки поиска мы видим идентификатор (имя пользователя). Символ шестеренки - кнопка, открывающая диалоговое окно "Мои настройки". Там вы можете настроить некоторые параметры пользовательского интерфейса на стороне клиента (сбросить сохраненный логин или макет).
Самая правая часть заголовка содержит четыре кнопки:
Мои Настройки
В окне "Мои настройки" можно задать локально сохраняемые настройки. К ним относятся панели мониторинга хранилищ, которые позволяют включать или отключать определенные хранилища для подсчета общего объема, отображаемого в сводке центра обработки данных. Если ни одно хранилище не выбрано, отображается сумма объемов всех хранилищ, так же как и при включении каждого из них.
Под настройками панели мониторинга вы найдете сохраненное имя пользователя и кнопку для его очистки, а также кнопку для сброса ваших настроек GUI к макету по умолчанию.
На правой стороне есть настройки xterm.js. Они содержат следующие параметры:
Дерево Ресурсов
Это главная панель с деревом навигации. В верхней части этого дерева вы можете выбрать некоторые предопределенные представления, которые изменяют структуру дерева ниже. Представление по умолчанию - это представление сервера, в котором отображаются следующие типы объектов:
Датацентр | Содержит настройки кластера (применяются ко всем узлам) |
Узел | Представляет хосты кластера, на них запускаются гостевые системы |
Гость | VM, контейнеры и шаблоны |
Хранилище | Хранилища Данных |
Пул | Для упрощения управления гости могут группироваться в пулы |
Доступны следующие типы представлений:
Панель Журнала
Основная цель панели журнала-показать вам, что в настоящее время происходит в вашем кластере. Такие действия, как создание новой виртуальной машины, выполняются в фоновом режиме, и мы называем такое фоновое задание задачей.
Любой вывод из такой задачи сохраняется в отдельном файле журнала. Вы можете просмотреть этот журнал, просто дважды щелкнув запись журнала задач. Там также можно прервать выполнение задачи.
NFS Backend
Storage pool type: nfs
The NFS backend is based on the directory backend, so it shares most properties. The directory layout and the file naming conventions are the same. The main advantage is that you can directly configure the NFS server properties, so the backend can mount the share automatically. There is no need to modify /etc/fstab . The backend can also test if the server is online, and provides a method to query the server for exported shares.
понедельник, 11 ноября 2019 г.
Thin Provisioning
A number of storages, and the Qemu image format qcow2 , support thin provisioning. With thin provisioning activated, only the blocks that the guest system actually use will be written to the storage.
Say for instance you create a VM with a 32GB hard disk, and after installing the guest system OS, the root file system of the VM contains 3 GB of data. In that case only 3GB are written to the storage, even if the guest VM sees a 32GB hard drive. In this way thin provisioning allows you to create disk images which are larger than the currently available storage blocks. You can create large disk images for your VMs, and when the need arises, add more disks to your storage without resizing the VMs' file systems.
All storage types which have the “Snapshots” feature also support thin provisioning.
If a storage runs full, all guests using volumes on that storage receive IO errors. This can cause file system inconsistencies and may corrupt your data. So it is advisable to avoid over-provisioning of your storage resources, or carefully observe free space to avoid such conditions. |
Volume Ownership
There exists an ownership relation for image type volumes. Each such volume is owned by a VM or Container. For example volume local:230/example-image.raw is owned by VM 230. Most storage backends encodes this ownership information into the volume name.
When you remove a VM or Container, the system also removes all associated volumes which are owned by that VM or Container.
Руководство администратора Proxmox VE R 6.0 Глава 5.
Using the Command Line Interface
It is recommended to familiarize yourself with the concept behind storage pools and volume identifiers, but in real life, you are not forced to do any of those low level operations on the command line. Normally, allocation and removal of volumes is done by the VM and Container management tools.
Nevertheless, there is a command line tool called pvesm (“Proxmox VE Storage Manager”), which is able to perform common storage management tasks.
Storage Features
As mentioned above, most file systems do not support snapshots out of the box. To workaround that problem, this backend is able to use qcow2 internal snapshot capabilities.
Same applies to clones. The backend uses the qcow2 base image feature to create clones.
images rootdir vztmpl iso backup snippets
raw qcow2 vmdk subvol
Режимы архивирования
Proxmox предлагает на выбор системному администратору три метода резервного копирования. С помощью них можно решить требуемую задачу, определив приоритет между необходимостью простоя и надежностью сделанной резервной копии:
- Режим Snapshot (Снимок). Этот режим можно еще назвать как Live backup, поскольку для его использования не требуется останавливать работу виртуальной машины. Использование этого механизма не прерывает работу VM, но имеет два очень серьезных недостатка — могут возникать проблемы из-за блокировок файлов операционной системой и самая низкая скорость создания. Резервные копии, созданные этим методом, надо всегда проверять в тестовой среде. В противном случае есть риск, что при необходимости экстренного восстановления, они могут дать сбой.
- Режим Suspend (Приостановка). Виртуальная машина временно «замораживает» свое состояние, до окончания процесса резервного копирования. Содержимое оперативной памяти не стирается, что позволяет продолжить работу ровно с той точки, на которой работа была приостановлена. Разумеется, это вызывает простой сервера на время копирования информации, зато нет необходимости выключения/включения виртуальной машины, что достаточно критично для некоторых сервисов. Особенно, если запуск части сервисов не является автоматическим. Тем не менее такие резервные копии также следует разворачивать в тестовой среде для проверки.
- Режим Stop (Остановка). Самый надежный способ резервного копирования, но требующий полного выключения виртуальной машины. Отправляется команда на штатное выключение, после остановки выполняется резервное копирование и затем отдается команда на включение виртуальной машины. Количество ошибок при таком подходе минимально и чаще всего сводится к нулю. Резервные копии, созданные таким способом, практически всегда разворачиваются корректно.
Volumes
We use a special notation to address storage data. When you allocate data from a storage pool, it returns such a volume identifier. A volume is identified by the , followed by a storage type dependent volume name, separated by colon. A valid looks like:
To get the file system path for a use:
Использование интерфейса командной строки
Рекомендуется ознакомиться с концепцией пулов хранения и идентификаторов томов, но в реальной жизни вы не обязаны выполнять какие-либо из этих низкоуровневых операций в командной строке. Обычно выделение и удаление томов выполняется средствами управления виртуальными машинами и контейнерами.
В статье «Магия виртуализации: вводный курс в Proxmox VE» мы успешно установили на сервер гипервизор, подключили к нему хранилище, позаботились об элементарной безопасности и даже создали первую виртуальную машину. Теперь разберем как реализовать самые базовые задачи, которые приходится выполнять, чтобы всегда иметь возможность восстановить работу сервисов в случае сбоя.
Штатные инструменты Proxmox позволяют не только выполнять резервное копирование данных, но и создавать наборы предварительно настроенных образов операционных систем для быстрого развертывания. Это не только помогает при необходимости создать новый сервер для любого сервиса за несколько секунд, но также и уменьшает время простоя до минимального.
Рассказывать о необходимости создания бэкапов мы не будем, поскольку это очевидно и уже давно является аксиомой. Остановимся на некоторых неочевидных вещах и особенностях.
Сначала рассмотрим каким образом сохраняются данные при процедуре резервного копирования.
Руководство администратора Proxmox VE R 6.0 Глава 8.
Выполнение процедуры резервирования
Для создания резервной копии:
- Переходим на нужную виртуальную машину.
- Выбираем пункт Резервирование.
- Нажимаем кнопку Резервировать сейчас. Откроется окно, в котором можно будет выбрать параметры будущей резервной копии.
- В поле Хост вводим IP-адрес нашего сервера виртуализации, в поле Имя пользователя вводим root, в поле Пароль — тот, который был выбран при установке, а в поле Порт указываем «22» (либо любой другой порт, который был задан для SSH-подключений).
- Нажимаем кнопку Быстрое соединение и, если все данные были введены правильно, то в активной панели Вы увидите все файлы, расположенные на сервере.
- Переходим в директорию /mnt/storage. Все создаваемые резервные копии будут лежать в поддиректории «dump». Они будут иметь вид:
- vzdump-qemu-номер_машины-дата-время.vma.gz в случае выбора метода GZIP;
- vzdump-qemu-номер_машины-дата-время.vma.lzo в случае выбора метода LZO.
- raw — образ диска;
- conf — конфигурация VM;
- fw — настройки файервола.
Examples
You can get a list of exported CIFS shares with:
Then you could add this share as a storage to the whole Proxmox VE cluster with:
Изменение размера виртуального диска
И в заключение покажем как увеличить размер образа диска, если по каким-то причинам места на нем перестало хватать. Для этого воспользуемся аргументом resize:
Теперь наш образ стал размером 80 Гб. Посмотреть подробную информацию об образе можно с помощью аргумента info:
Не стоит забывать, что само расширение образа не увеличит размер раздела автоматически — просто добавит доступное свободное пространство. Для увеличения раздела воспользуйтесь командой:
где /dev/sda1 — нужный раздел.
Storage Pools
Each storage pool has a , and is uniquely identified by its . A pool configuration looks like this:
The : line starts the pool definition, which is then followed by a list of properties. Most properties require a value. Some have reasonable defaults, in which case you can omit the value.
To be more specific, take a look at the default storage configuration after installation. It contains one special local storage pool named local , which refers to the directory /var/lib/vz and is always available. The Proxmox VE installer creates additional storage entries depending on the storage type chosen at installation time.
Encryption
Optionally, you can configure client-side encryption with AES-256 in GCM mode. Encryption can be configured either via the web interface, or on the CLI with the encryption-key option (see above). The key will be saved in the file /etc/pve/priv/storage/.enc , which is only accessible by the root user.
Without their key, backups will be inaccessible. Thus, you should keep keys ordered and in a place that is separate from the contents being backed up. It can happen, for example, that you back up an entire system, using a key on that system. If the system then becomes inaccessible for any reason and needs to be restored, this will not be possible as the encryption key will be lost along with the broken system. |
It is recommended that you keep your key safe, but easily accessible, in order for quick disaster recovery. For this reason, the best place to store it is in your password manager, where it is immediately recoverable. As a backup to this, you should also save the key to a USB drive and store that in a secure place. This way, it is detached from any system, but is still easy to recover from, in case of emergency. Finally, in preparation for the worst case scenario, you should also consider keeping a paper copy of your key locked away in a safe place. The paperkey subcommand can be used to create a QR encoded version of your key. The following command sends the output of the paperkey command to a text file, for easy printing.
Additionally, it is possible to use a single RSA master key pair for key recovery purposes: configure all clients doing encrypted backups to use a single public master key, and all subsequent encrypted backups will contain a RSA-encrypted copy of the used AES encryption key. The corresponding private master key allows recovering the AES key and decrypting the backup even if the client system is no longer available.
The same safe-keeping rules apply to the master key pair as to the regular encryption keys. Without a copy of the private key recovery is not possible! The paperkey command supports generating paper copies of private master keys for storage in a safe, physical location. |
Because the encryption is managed on the client side, you can use the same datastore on the server for unencrypted backups and encrypted backups, even if they are encrypted with different keys. However, deduplication between backups with different keys is not possible, so it is often better to create separate datastores.
Do not use encryption if there is no benefit from it, for example, when you are running the server locally in a trusted network. It is always easier to recover from unencrypted backups. |
Графический интерфейс пользователя
Поскольку мы используем файловую систему кластера Proxmox (pmxcfs), вы можете подключиться к любому узлу для управления всем кластером. Каждый узел может управлять всем кластером. Нет необходимости в выделенном узле диспетчера.
Вы можете использовать веб-интерфейс администрирования с любым современным браузером. Когда Proxmox VE обнаруживает, что вы подключаетесь с мобильного устройства, вы перенаправляетесь на более простой, сенсорный пользовательский интерфейс.
Алгоритмы резервного копирования
Начнем с того, что Proxmox имеет неплохой штатный инструментарий для создания резервных копий виртуальных машин. Он позволяет легко сохранить все данные виртуальной машины и поддерживает два механизма сжатия, а также три метода создания этих копий.
Разберем вначале механизмы сжатия:
- Сжатие LZO. Алгоритм сжатия данных без потерь, придуманный еще в середине 90-х годов. Код был написан Маркусом Оберхеймером (реализуется в Proxmox утилитой lzop). Основной особенностью этого алгоритма является очень скоростная распаковка. Следовательно, любая резервная копия, созданная с помощью этого алгоритма, может при необходимости быть развернута за минимальное время.
- Сжатие GZIP. При использовании этого алгоритма резервная копия будет «на лету» сжиматься утилитой GNU Zip, использующей мощный алгоритм Deflate, созданный Филом Кацем. Основной упор делается на максимальное сжатие данных, что позволяет сократить место на диске, занимаемое резервными копиями. Главным отличием от LZO является то, что процедуры компрессии/декомпреcсии занимают достаточно большое количество времени.
Клонирование виртуальной машины
Для примера, предположим, что в компании требуется внести изменения в какой-либо критичный сервис. Такое изменение реализуется через внесение множества правок в конфигурационные файлы. Результат при этом непредсказуем и любая ошибка способна вызвать сбой сервиса. Чтобы подобный эксперимент не затронул работающий сервер, рекомендуется выполнить клонирование виртуальной машины.
Механизм клонирования создаст точную копию виртуального сервера, с которой допустимо проводить любые изменения, при этом не затрагивая работу основного сервиса. Затем, если изменения будут успешно применены, новая VM запускается в работу, а старая выключается. В этом процессе есть особенность, о которой всегда следует помнить. На клонированной машине IP-адрес будет точно таким же, как и у исходной VM, то есть при ее запуске возникнет конфликт адресов.
Расскажем, как избежать такой ситуации. Непосредственно перед выполнением клонирования, следует внести изменения в конфигурацию сети. Для этого необходимо временно изменить IP-адрес, но не перезапускать сетевой сервис. После выполнения клонирования на основной машине следует вернуть настройки обратно, а на клонированной машине задать любой другой IP-адрес. Тем самым мы получим две копии одного и того же сервера на разных адресах. Это позволит быстро ввести новый сервис в работу.
Если этим сервисом является веб-сервер, то достаточно только изменить А-запись у Вашего DNS-провайдера, после чего запросы клиентов по этому доменному имени будут направляться уже на адрес клонированной виртуальной машины.
Кстати, Selectel предоставляет всем своим клиентам услугу размещения любого количества доменов на NS-серверах бесплатно. Управление записями осуществляется как с помощью нашей панели управления, так и с помощью специального API. Подробнее об этом читайте в нашей базе знаний.
Клонирование VM в Proxmox является очень простой задачей. Для ее выполнения необходимо выполнить следующие действия:
- Перейти на нужную нам машину.
- Выбрать из меню More пункт Clone.
- В открывшемся окне заполнить параметр Имя.
Типы хранилищ
Тонкая Настройка
Ряд хранилищ, и образы QEMU в формате qcow2 , поддерживает динамическое выделение памяти. При активированной тонкой настройке в хранилище будут записаны только те блоки, которые фактически используются гостевой системой.
Скажем, например, вы создаете виртуальную машину с жестким диском 32 ГБ, и после установки операционной системы гостевой системы корневая файловая система виртуальной машины содержит 3 ГБ данных. В этом случае только 3 ГБ записываются в хранилище, даже если гостевая виртуальная машина видит жесткий диск 32 ГБ. Таким образом, тонкая настройка позволяет создавать образы дисков, которые больше, чем доступные в настоящее время блоки хранения. Можно создавать большие образы дисков для виртуальных машин, а при необходимости добавлять дополнительные диски в хранилище без изменения размера файловых систем виртуальных машин.
Особенности
Storage Types
There are basically two different classes of storage types:
File level based storage technologies allow access to a fully featured (POSIX) file system. They are in general more flexible than any Block level storage (see below), and allow you to store content of any type. ZFS is probably the most advanced system, and it has full support for snapshots and clones.
Block level storage
Allows to store large raw images. It is usually not possible to store other files (ISO, backups, ..) on such storage types. Most modern block level storage implementations support snapshots and clones. RADOS and GlusterFS are distributed systems, replicating storage data to different nodes.
1 : On file based storages, snapshots are possible with the qcow2 format.
2 : It is possible to use LVM on top of an iSCSI or FC-based storage. That way you get a shared LVM storage.
Storage Features
NFS does not support snapshots, but the backend uses qcow2 features to implement snapshots and cloning.
images rootdir vztmpl iso backup snippets
Читайте также: