Proxmox VE Administration Guide
Хотя файловая система хранит все данные в базе данных на диске, копия данных находится в оперативной памяти. Это накладывает ограничение на ее максимальный размер, который в настоящее время составляет 30 МБ. Этого по-прежнему достаточно для хранения конфигурации нескольких тысяч виртуальных машин.
Эта система обеспечивает следующие преимущества:
Файловая система кластера Proxmox (pmxcfs)
Файловая система кластера Proxmox ("pmxcfs") - это управляемая базой данных файловая система для хранения конфигурационных файлов, реплицируемых в реальном времени на все узлы кластера с помощью corosync . Мы используем ее для хранения всех конфигурационных файлов, связанных с PVE.Хотя файловая система хранит все данные в базе данных на диске, копия данных находится в оперативной памяти. Это накладывает ограничение на ее максимальный размер, который в настоящее время составляет 30 МБ. Этого по-прежнему достаточно для хранения конфигурации нескольких тысяч виртуальных машин.
Эта система обеспечивает следующие преимущества:
- Непрерывная репликация всей конфигурации на все узлы в режиме реального времени
- Обеспечивает строгую проверку согласованности, чтобы избежать дублирования идентификаторов виртуальных машин
- Только для чтения, когда узел теряет кворум
- Автоматическое обновление конфигурации кластера corosync для всех узлов
- Включает распределенный механизм блокировок
Совместимость с POSIX
Файловая система основана на FUSE, поэтому поведение POSIX подобное. Но некоторые функции просто не реализованы, потому что они нам не нужны:- Вы можете просто генерировать обычные файлы и каталоги, но без символических ссылок, ...
- Вы не можете переименовывать непустые каталоги (потому что это упрощает гарантию того, что VMIDs уникальны).
- Вы не можете изменить права доступа к файлам (права доступа основаны на пути)
- O_excl создает не атомарные (как старые NFS)
- O_trunc создает не атомарные (ограничение FUSE)
Права доступа к файлам
Все файлы и каталоги принадлежат пользователю root и группе www-data . Только root имеет права на запись, но группа www-data может читать большинство файлов. Файлы под следующими путями:
доступны только от root./etc/pve/priv/ /etc/pve/nodes/${NAME}/priv/
Технологии
Мы используем кластерный движок Corosync для кластерной связи и SQlite для файла базы данных. Файловая система реализована в пользовательском пространстве с помощью FUSE.Структура Файловой Системы
Файловая система монтируется по адресу:
/etc/pve
Файлы
corosync.conf Файл конфигурации кластера Corosync (до Proxmox VE 4.x этот файл назывался cluster.conf) storage.cfg Конфигурация хранилища Proxmox VE datacenter.cfg Общая конфигурация датацентра Proxmox VE (раскладка клавиатуры, прокси, …) user.cfg Конфигурация управления доступом Proxmox VE (пользователи/группы/…) domains.cfg Домены аутентификации Proxmox VE status.cfg Конфигурация сервера внешних метрик Proxmox VE authkey.pub Открытый ключ, используемый системой тикетов pve-root-ca.pem Открытый сертификат центра сертификации кластера priv/shadow.cfg Файл скрытых паролей priv/authkey.key Закрытый ключ, используемый системой тикетов priv/pve-root-ca.key Закрытый ключ центра сертификации кластера nodes/<NAME>/pve-ssl.pem Открытый сертификат SSL для веб-сервера (подписанный центром сертификации кластера) nodes/<NAME>/pve-ssl.key Закрытый ключ SSL для pve-ssl.pem nodes/<NAME>/pveproxy-ssl.pem Открытый SSL-сертификат (цепочка) для веб-сервера (необязательное переопределение для pve-ssl.pem) nodes/<NAME>/pveproxy-ssl.key Закрытый ключ SSL для pveproxy-ssl.pem (опционально) nodes/<NAME>/qemu-server/<VMID>.conf Данные конфигурации виртуальной машины для виртуальных машин KVM nodes/<NAME>/lxc/<VMID>.conf Данные конфигурации виртуальной машины для контейнеров LXC firewall/cluster.fw Конфигурация брандмауэра применяется ко всем узлам firewall/<NAME>.fw Конфигурация брандмауэра для отдельных узлов firewall/<VMID>.fw Конфигурация брандмауэра для виртуальных машин и контейнеров Символические ссылки
local nodes/<LOCAL_HOST_NAME> qemu-server nodes/<LOCAL_HOST_NAME>/qemu-server/ lxc nodes/<LOCAL_HOST_NAME>/lxc/ Специальные файлы состояния для отладки (JSON)
.version Версии файлов (для обнаружения изменений файлов) .members Информация о членах кластера .vmlist Список всех виртуальных машин .clusterlog Журнал кластера (последние 50 записей) .rrd Данные RRD (самые последние записи) Включение/выключение отладки
Вы можете включить подробные сообщения системного журнала с помощью:
И отключить подробные сообщения системного журнала с помощью:echo "1" >/etc/pve/.debug
echo "0" >/etc/pve/.debug
Восстановление
Если у вас есть серьезные проблемы с вашим хостом Proxmox VE, например, проблемы с оборудованием, было бы полезно просто скопировать файл базы данных pmxcfs /var/lib/pve-cluster/config.db и переместите его на новый хост Proxmox VE. На новом хосте (где ничего не работает)вам нужно остановить службу pve-cluster и заменить файл config.db (права доступа 0600). Во-вторых, адаптировать /etc/hostname и /etc/hosts в соответствии с проблемным хостом Proxmox VE, а затем перезагрузить и проверить. (И не забывайте данные своих VM/CT)Удаление конфигурации кластера
Рекомендуется переустановить узел после удаления его из кластера. Это гарантирует, что все секретные ключи кластера/ssh и любые общие данные конфигурации будут уничтожены.
В некоторых случаях вы можете предпочесть перевести узел обратно в локальный режим без переустановки, что описано в разделе "Отделение узела без переустановки"Восстановление/перемещение гостей с отказавших узлов
Для гостевых конфигурационных файлов в nodes/<name>/qemu-server/ (VMs) и nodes/<name>/lxc/ (containers) Proxmox VE видит содержащий узел <name> как владельца соответствующего гостя. Эта концепция позволяет использовать локальные блокировки вместо дорогостоящих блокировок на уровне кластера для предотвращения одновременных изменений конфигурации гостя.
Как следствие, если узел-владелец гостя выходит из строя (например, из-за отключения электроэнергии, изолирующие события, ...), обычная миграция невозможна (даже если все диски расположены на общем хранилище), поскольку такая локальная блокировка на (мертвом) узле-владельце недоступна. Это не проблема для гостей, управляемых HA, поскольку стек высокой доступности Proxmox VE включает в себя необходимые (для всего кластера) функции блокировки и сторожевого таймера, чтобы обеспечить правильное и автоматическое восстановление гостей с изолированных узлов.
Если гость, не управляемый HA, имеет только общие диски (и никакие другие локальные ресурсы, доступные только на отказавшем узле, не настроены), ручное восстановление возможно простым перемещением файла конфигурации гостя из каталога отказавшего узла в /etc/pve/ в каталог живого узла (который изменяет логического владельца или местоположение гостя).
Например, восстановление виртуальной машины с идентификатором 100 из мертвого узла node1 в другой узел node2 выполняется с помощью следующей команды, выполняемой, при входе в систему как root, на любом узле-члене кластера:mv /etc/pve/nodes/node1/qemu-server/100.conf /etc/pve/nodes/node2/
- Внимание!
- Перед ручным восстановлением гостя, как в этом случае, удостоверьтесь, что отказавший исходный узел действительно выключен/изолирован. В противном случае принципы блокировки Proxmox VE нарушаются командой mv, что может иметь неожиданные последствия.
- Внимание!
- Гость с локальными дисками (или другими локальными ресурсами, которые доступны только на мертвом узле) не может быть восстановлен таким образом. Либо дождитесь, пока отказавший узел присоединится к кластеру, либо восстановите таких гостей из резервных копий.
Комментариев нет:
Отправить комментарий