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

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

Proxmox VE Administration Guide

Файловая система кластера Proxmox (pmxcfs)

  1. Совместимость с POSIX
  2. Права Доступа К Файлам
  3. Технологии
  4. Структура Файловой Системы
  5. Восстановление
Файловая система кластера Proxmox ("pmxcfs") - это управляемая базой данных файловая система для хранения конфигурационных файлов, реплицируемых в реальном времени на все узлы кластера с помощью corosync . Мы используем ее для хранения всех конфигурационных файлов, связанных с PVE.

Хотя файловая система хранит все данные в базе данных на диске, копия данных находится в оперативной памяти. Это накладывает ограничение на ее максимальный размер, который в настоящее время составляет 30 МБ. Этого по-прежнему достаточно для хранения конфигурации нескольких тысяч виртуальных машин.
Эта система обеспечивает следующие преимущества:

  • Непрерывная репликация всей конфигурации на все узлы в режиме реального времени
  • Обеспечивает строгую проверку согласованности, чтобы избежать дублирования идентификаторов виртуальных машин
  • Только для чтения, когда узел теряет кворум
  • Автоматическое обновление конфигурации кластера corosync для всех узлов
  • Включает распределенный механизм блокировок
  1. Совместимость с POSIX

    Файловая система основана на FUSE, поэтому поведение POSIX подобное. Но некоторые функции просто не реализованы, потому что они нам не нужны:
    • Вы можете просто генерировать обычные файлы и каталоги, но без символических ссылок, ...
    • Вы не можете переименовывать непустые каталоги (потому что это упрощает гарантию того, что VMIDs уникальны).
    • Вы не можете изменить права доступа к файлам (права доступа основаны на пути)
    • O_excl создает не атомарные (как старые NFS)
    • O_trunc создает не атомарные (ограничение FUSE)
  2. Права доступа к файлам

    Все файлы и каталоги принадлежат пользователю root и группе www-data . Только root имеет права на запись, но группа www-data может читать большинство файлов. Файлы под следующими путями:
    /etc/pve/priv/
    /etc/pve/nodes/${NAME}/priv/
    доступны только от root.
  3. Технологии

    Мы используем кластерный движок Corosync для кластерной связи и SQlite для файла базы данных. Файловая система реализована в пользовательском пространстве с помощью FUSE.
  4. Структура Файловой Системы

    Файловая система монтируется по адресу:
    /etc/pve
    1. Файлы

      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Конфигурация брандмауэра для виртуальных машин и контейнеров
    2. Символические ссылки

      localnodes/<LOCAL_HOST_NAME>
      qemu-servernodes/<LOCAL_HOST_NAME>/qemu-server/
      lxcnodes/<LOCAL_HOST_NAME>/lxc/
    3. Специальные файлы состояния для отладки (JSON)

      .versionВерсии файлов (для обнаружения изменений файлов)
      .membersИнформация о членах кластера
      .vmlistСписок всех виртуальных машин
      .clusterlogЖурнал кластера (последние 50 записей)
      .rrdДанные RRD (самые последние записи)
    4. Включение/выключение отладки

      Вы можете включить подробные сообщения системного журнала с помощью:
      echo "1" >/etc/pve/.debug
      И отключить подробные сообщения системного журнала с помощью:
      echo "0" >/etc/pve/.debug
  5. Восстановление

    Если у вас есть серьезные проблемы с вашим хостом Proxmox VE, например, проблемы с оборудованием, было бы полезно просто скопировать файл базы данных pmxcfs /var/lib/pve-cluster/config.db и переместите его на новый хост Proxmox VE. На новом хосте (где ничего не работает)вам нужно остановить службу pve-cluster и заменить файл config.db (права доступа 0600). Во-вторых, адаптировать /etc/hostname и /etc/hosts в соответствии с проблемным хостом Proxmox VE, а затем перезагрузить и проверить. (И не забывайте данные своих VM/CT)
    1. Удаление конфигурации кластера

      Рекомендуется переустановить узел после удаления его из кластера. Это гарантирует, что все секретные ключи кластера/ssh и любые общие данные конфигурации будут уничтожены.
      В некоторых случаях вы можете предпочесть перевести узел обратно в локальный режим без переустановки, что описано в разделе "Отделение узела без переустановки"
    2. Восстановление/перемещение гостей с отказавших узлов

      Для гостевых конфигурационных файлов в 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, что может иметь неожиданные последствия.


      Внимание!
      Гость с локальными дисками (или другими локальными ресурсами, которые доступны только на мертвом узле) не может быть восстановлен таким образом. Либо дождитесь, пока отказавший узел присоединится к кластеру, либо восстановите таких гостей из резервных копий.





Комментариев нет:

Отправить комментарий