Cinder — Блочное хранилище

Cinder представляет собой компонент OpenStack, отвечающий за управление блочным хранилищем данных. Он предоставляет постоянные блочные устройства хранения для виртуальных машин, работающих под управлением Nova. Cinder абстрагирует различные системы хранения через унифицированный API, позволяя администраторам использовать разнообразные серверные части хранилищ — от локальных дисков до корпоративных систем хранения данных — через единый интерфейс управления. Основная задача Cinder заключается в обеспечении надёжного и масштабируемого хранилища для облачных инфраструктур. Компонент поддерживает создание, подключение и управление томами данных, которые могут быть подключены к виртуальным машинам как дополнительные диски. Cinder также обеспечивает создание моментальных снимков томов для резервного копирования и восстановления данных, поддерживает клонирование томов и предоставляет возможности для миграции данных между различными системами хранения. Благодаря поддержке множества драйверов производителей, Cinder позволяет организациям использовать существующую инфраструктуру хранения данных в облачной среде OpenStack.

Драйверы Cinder

Драйверы Cinder служат для управления хранилищем данных и предоставляют API для создания, управления и масштабирования блочных устройств хранения данных.

Матрица поддержки драйверов Cinder

Матрица поддержки приводит перечень драйверов, которые доступны в настоящее время или находятся в дереве драйверов Cinder на момент выпуска.

Следующие функции считаются обязательными:

  • Создание тома

  • Удаление тома

  • Подключение тома

  • Отключение тома

  • Расширение тома

  • Создание моментального снимка

  • Удаление снимка

  • Создание тома из моментального снимка

  • Создание тома из тома (клонирование)

  • Создание образа из тома

  • Массовая миграция (с помощью хоста)

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

Функция

Поддержка драйверов производителей

Расширение подключенного тома

Качество обслуживания (QoS)

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

Группы согласованности

Динамическое выделение емкости

Перенос тома внутри кластера при помощи хранилища

Поддержка подключения тома к нескольким виртуальным машинам

Возвращение к моментальному снимку

Поддержка высокой доступности для конфигурации, где активны оба узла (Active/Active)

Статус

необязательно

необязательно

необязательно

необязательно

необязательно

необязательно

необязательно

необязательно

необязательно

необязательно

(Ceph) Драйвер хранилища iSCSI (iSCSI)

✔

✔

✖

✔

✖

✔

✖

✔

✔

✔

Драйвер хранилища DataCore (FC, iSCSI)

✔

✖

✖

✖

✖

✖

✖

✖

✔

✖

Драйвер хранилища данных (iSCSI)

✔

✔

✔

✖

✖

✖

✖

✖

✖

✖

Драйвер хранилища Dell PowerFlex (ScaleIO) (ScaleIO)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Драйвер хранилища Dell PowerMax (2000, 8000) (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Драйвер Dell PowerStore NFS (NFS)

✔

✖

✖

✖

✖

✔

✖

✔

✖

✖

Драйвер хранилища Dell PowerStore (iSCSI, FC, NVMe-TCP)

✔

✔

✖

✔

✔

✔

✖

✔

✔

✖

Dell PowerVault ME Series (iSCSI, FC)

✔

✔

✖

✖

✖

✖

✖

✔

✖

✖

Драйвер хранилища Dell серии SC (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✖

✔

✖

✖

Драйвер хранилища Dell Unity (FC, iSCSI)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Драйвер хранилища Dell VMAX Af (250F, 450F, 850F, 950F) (FC, iSCSI)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Драйвер хранилища Dell VMAX3 (100K, 200K, 400K) (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Dell VNX Storage Driver (FC, iSCSI)

✔

✔

✔

✔

✔

✔

✔

✖

✔

✖

Dell XtremeIO Storage Driver (FC, iSCSI)

✔

✔

✖

✖

✔

✔

✖

✔

✖

✖

Fujitsu ETERNUS Driver (FC, iSCSI)

✔

✔

✖

✖

✖

✔

✖

✖

✖

✖

Fungible Storage Driver (NVMe-TCP)

✔

✖

✖

✖

✖

✖

✖

✖

✖

✖

Generic NFS Reference Driver (NFS)

✔

✖

✖

✖

✖

✔

✖

✖

✖

✖

HPE 3PAR Storage Driver (FC, iSCSI)

✔

✔

✔

✔

✔

✔

✖

✔

✔

✖

HPE MSA Driver (iSCSI, FC)

✔

✔

✖

✖

✖

✖

✖

✔

✖

✖

HPE Nimble Storage Driver (iSCSI, FC)

✔

✔

✖

✖

✔

✔

✖

✔

✔

✖

HPE XP Storage Driver (FC, iSCSI)

✔

✔

✖

✖

✔

✔

✖

✔

✔

✖

Hitachi VSP Storage Driver (FC, iSCSI)

✔

✔

✖

✖

✔

✔

✖

✔

✔

✖

Huawei 18000 Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✖

✖

✖

Huawei Dorado V3, V6 Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✖

✖

✖

Huawei F V3 Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✖

✖

✖

Huawei F V5 Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✖

✖

✖

Huawei FusionStorage, OceanStor 100D Driver (dsware)

✔

✔

✖

✖

✖

✖

✖

✖

✖

✖

Huawei T Series V1 Driver (iSCSI, FC)

✔

✔

✖

✖

✖

✖

✖

✖

✖

✖

Huawei T Series V2 Driver (iSCSI, FC)

✔

✔

✔

✖

✖

✖

✖

✖

✖

✖

Huawei V3 Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✖

✖

✖

Huawei V5 Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✖

✖

✖

IBM DS8000 Family Storage Driver (FC)

✔

✔

✖

✔

✔

✖

✖

✔

✔

✖

IBM FlashSystem Driver (iSCSI)

✖

✔

✖

✖

✖

✖

✖

✖

✖

✖

IBM GPFS Storage Driver (gpfs)

✔

✖

✖

✖

✖

✖

✖

✖

✖

✖

IBM Spectrum Accelerate Family Driver (iSCSI, FC)

✔

✖

✖

✔

✔

✖

✖

✔

✖

✖

IBM Storage Virtualize family Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Infinidat Storage Driver (iSCSI, FC)

✔

✔

✔

✖

✖

✔

✖

✔

✔

✖

Inspur AS13000 Storage Driver (iSCSI)

✔

✔

✖

✖

✖

✔

✖

✔

✖

✖

Inspur AS/HF Series Driver (iSCSI, FC)

✔

✔

✔

✔

✔

✖

✖

✖

✖

✖

Kaminario Storage Driver (iSCSI, FC)

✔

✔

✖

✔

✖

✔

✖

✖

✖

✖

Kioxia Kumoscale Driver (NVMeOF)

✔

✔

✖

✖

✖

✔

✖

✖

✖

✖

LINBIT DRBD/LINSTOR Driver (DRBD)

✔

✔

✖

✖

✖

✖

✖

✖

✖

✖

Lenovo Storage Driver (FC, iSCSI)

✔

✔

✖

✖

✖

✖

✖

✔

✖

✖

Lightbits LightOS Storage Driver (NVMeTCP)

✔

✔

✖

✖

✖

✔

✖

✔

✖

✖

Logical Volume Manager (LVM) Reference Driver (iSCSI)

✔

✔

✖

✖

✖

✔

✖

✔

✔

✖

MacroSAN Storage Driver (iSCSI, FC)

✔

✔

✔

✔

✖

✔

✔

✖

✖

✔

Драйвер NEC Storage серии M (iSCSI, FC)

✔

✔

✔

✖

✖

✔

✔

✔

✔

✖

Драйвер NEC Storage серии V (iSCSI, FC)

✔

✔

✖

✖

✔

✔

✖

✔

✔

✖

Драйвер NetApp Data ONTAP (iSCSI, NFS, FC, NVMe / TCP)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✖

Драйвер NetApp Solidfire (iSCSI)

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

Драйвер Nexenta (iSCSI, NFS)

✔

✔

✖

✖

✖

✖

✖

✖

✖

✖

Драйвер хранилища JovianDSS с открытым исходным кодом (iSCSI)

✔

✖

✖

✖

✖

✔

✖

✔

✔

✖

Драйвер ProphetStor Flexvisor (iSCSI, NFS)

✖

✔

✖

✖

✔

✖

✖

✖

✖

✖

Драйвер хранилища Pure (iSCSI, FC, NVMe-RoCE)

✔

✔

✔

✔

✔

✔

✖

✔

✔

✔

Драйвер хранилища QNAP (iSCSI)

✖

✔

✖

✖

✖

✖

✖

✖

✖

✖

Quobyte Storage Driver (quobyte)

✔

✖

✖

✖

✖

✖

✖

✖

✖

✖

Драйвер хранилища RBD (Ceph) (RBD)

✔

✔

✖

✔

✖

✔

✖

✔

✔

✔

Драйвер хранилища SandStone (iSCSI)

✔

✔

✔

✔

✖

✔

✖

✔

✔

✔

Драйвер Seagate (iSCSI, FC)

✔

✔

✖

✖

✖

✖

✖

✔

✖

✖

Драйвер хранилища StorPool (storpool)

✔

✔

✖

✔

✖

✔

✔

✔

✖

✖

Драйвер хранилища Synology (iSCSI)

✔

✔

✖

✖

✖

✖

✖

✖

✖

✖

Драйвер хранилища TOYOU NetStor (iSCSI, FC)

✔

✔

✖

✖

✖

✔

✔

✔

✔

✖

Драйвер хранилища VMware (vmdk)

✔

✔

✖

✖

✖

✖

✖

✖

✔

✖

Драйвер iSCSI Veritas Access (iSCSI)

✖

✔

✖

✖

✖

✖

✖

✖

✖

✖

Драйвер Veritas Cluster NFS (NFS)

✖

✔

✖

✖

✖

✖

✖

✖

✖

✖

Драйвер хранилища Virtuozzo (remotefs)

✖

✔

✖

✖

✖

✖

✖

✖

✖

✖

Драйвер Windows SMB

✔

✔

✖

✖

✖

✔

✖

✖

✖

✖

Драйвер iSCSI для Windows

✔

✔

✖

✖

✖

✖

✖

✖

✖

✖

Унифицированный драйвер Yadro Tatlin (iSCSI)

✔

✔

✔

✖

✖

✔

✖

✔

✔

✔

Драйвер хранилища Zadara (iSCSI, NFS)

✔

✔

✖

✖

✖

✖

✖

✔

✖

✖

Драйвер хранилища infortrend (iSCSI, FC)

✔

✔

✖

✔

✖

✔

✔

✔

✖

✖

Примечания

  1. Поддержка драйверов производителей

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

  2. Расширение подключённого тома

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

  3. Качество обслуживания (QoS)

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

  4. Клонирование томов

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — не поддерживается.

  5. Группы согласованности

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — не поддерживается.

  6. Динамическое выделение емкости

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

  7. Перенос тома внутри кластера при помощи хранилища

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — не поддерживается.

  8. Поддержка подключения тома к нескольким виртуальным машинам

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

  9. Возвращение к моментальному снимку

    При поддержке данной функции драйверы производителей поддерживают возможность возврата тома к последнему сделанному снимку.

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — не поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

  10. Поддержка высокой доступности для конфигурации, где активны оба узла (Active/Active)

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

    • Huawei Dorado драйвер серии V3, V6 (iSCSI, FC) — не поддерживается;

    • Драйвер Yadro Tatlin (iSCSI, FC) — поддерживается.

Внешний Ceph

Для подготовки и настройки кластера Ceph администраторам требуется специализированный инструмент, такой как ceph-ansible или cephadm. При выполнении этого условия становится возможным создавать нужные пулы и цепочки ключей с помощью Ceph CLI или аналогичного CLI.

Подключение внешнего Ceph осуществляется через инсталлятор (kolla-ansible), поэтому интеграция выполняется через переменные globals.yml и файлы в каталогах пользовательских конфигураций.

Предварительные требования

  • Наличие инсталляции Ceph.

  • Наличие пулов хранения Ceph.

  • Наличие учетных данных в Ceph для сервисов OpenStack для подключения к Ceph (Glance, Cinder, Nova).

Подробнее о создании пула и наборов ключей с соответствующими разрешениями для каждого сервиса см. в документации Ceph: Block Devices and OpenStack.

Интеграция с Ceph настраивается для каждого из сервисов OpenStack по отдельности.

Примечание

Такие команды, как ceph config generate-minimal-conf, создают файлы конфигурации с ведущими вкладками. Эти вкладки нарушают работу ini-парсера Kolla Ansible. Обязательно удалите ведущие вкладки из файлов ceph.conf при их копировании в разделы, перечисленные далее.

Подключение Ceph

  1. На стороне Ceph подготовьте:

    • MON-адреса (mon_host) и fsid;

    • пулы (обычно это images, volumes, backups и vms);

    • пользователей (clients) и ключи с нужными caps для Glance/Cinder/Nova.

  2. Включите Ceph-бэкенды в globals.d/ceph.yml (или эквивалентно в globals.d/REGION.yml). Для этого задайте в файле соответствующие переменные со значением yes.

    glance_backend_ceph: "yes"
nova_backend_ceph: "yes"
cinder_backend_ceph: "yes"

  3. Разместите файл ceph.conf и файлы keyring в соответствующих директориях project_k / deployments / <имя региона> / config / ... или других необходимых каталогах. Более подробная информация представлена в разделе Ожидаемые пути и имена файлов.

  4. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  5. Оставьте ветку по умолчанию, соответствующую установленному релизу.

  6. В открывшемся окне добавьте переменную KOLLA_ARGS, в которой укажите теги сервисов, которые будут использовать Ceph в качестве внешнего хранилища: -t glance,cinder,nova.

  7. Запустите пайплайн, нажав кнопку New pipeline.

  8. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

В большинстве установок Ceph по умолчанию имя кластера — ceph, а имена пулов — images, volumes, backups, vms. В таком сценарии конфигурация будет минимальной.

Если у вас другое имя кластера, пулов, пользователей или нестандартные пути/имена файлов keyring — обратитесь к разделу Сноски по кастомизации.

Переменные, задаваемые в globals.d или ceph.yml

Минимально достаточно задать:

  • Необходимые переменные для включения Ceph-бэкендов в соответствующем yml-файле:

    glance_backend_ceph: "yes"
cinder_backend_ceph: "yes"
nova_backend_ceph: "yes"

  • Переменную external_ceph_cephx_enabled. Переменная управляет копированием файлов keyring для Cinder и Nova: при значении "no" аутентификация cephx будет отключена и файлы keyring для этих сервисов скопированы не будут. Для Glance данная переменная не применяется — её keyring копируется всегда.

    external_ceph_cephx_enabled: "yes"

Если у вас стандартные имена пользователей/пулов/файлов keyring, то можно явно задать только то, что отличается от них (или вообще ничего, если ваш шаблон окружения уже задаёт значения).

Ниже приведён пример стандартной конфигурации:

# Glance (обычно)
ceph_glance_user: "glance"
ceph_glance_pool_name: "images"
ceph_glance_keyring: "client.{{ ceph_glance_user }}.keyring"

# Cinder (обычно)
ceph_cinder_user: "cinder"
ceph_cinder_pool_name: "volumes"
ceph_cinder_keyring: "client.{{ ceph_cinder_user }}.keyring"

# Cinder Backup (если используется)
ceph_cinder_backup_user: "cinder-backup"
ceph_cinder_backup_pool_name: "backups"
ceph_cinder_backup_keyring: "client.{{ ceph_cinder_backup_user }}.keyring"

# Nova (эфемерные диски на RBD, если используется)
ceph_nova_user: "{{ ceph_cinder_user }}"
ceph_nova_pool_name: "vms"
ceph_nova_keyring: "client.{{ ceph_cinder_user }}.keyring"

Совет

В некоторых схемах Nova может использовать учётные данные Cinder для доступа к RBD. Это упрощает конфигурацию, но чаще удобнее и безопаснее использовать для Nova отдельного пользователя.

Кластеры и multicluster

Kolla Ansible оперирует «кластером» Ceph через параметр cluster. Он влияет на:

  • имя конфигурационного файла <cluster>.conf (для multicluster);

  • имя файла keyring, который копируется как <cluster>.<keyring>.

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

Практически это означает:

  • Для одного кластера Ceph: используйте cluster: ceph и файл ceph.conf.

  • Для нескольких кластеров: добавьте элементы в *_ceph_backends и в той же директории разместите ceph.conf, rbd1.conf, rbd2.conf и т.д., где имя файла совпадает с cluster (rbd1).

Ожидаемые пути и имена файлов

Во время развёртывания kolla-ansible копирует конфиги/файлы keyring из node_custom_config в директории контейнеров. В терминах структуры пользовательских конфигураций необходимо учитывать следующее:

  • Источник ищется в {{ node_custom_config }}/<service>/....

  • Имя файла keyring строится как <cluster>.<ceph_*_keyring>.

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

Glance

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

    • один кластер (используется по умолчанию): config/glance/ceph.conf

    • несколько кластеров: config/glance/<cluster>.conf (например: config/glance/rbd1.conf)

    Пример ceph.conf:

    [global]
fsid = 1d89fec3-325a-4963-a950-c4afedd37fe3
keyring = /etc/ceph/ceph.client.glance.keyring
mon_initial_members = ceph-0
mon_host = 192.168.0.56
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

  • Файл keyring для Glance (для каждого cluster): config/glance/<cluster>.{{ ceph_glance_keyring }}. Стандартный пример (cluster=ceph, ceph_glance_user=glance): config/glance/ceph.client.glance.keyring.

Cinder

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

    • общая: config/cinder/ceph.conf;

    • отдельно для volume: config/cinder/cinder-volume/ceph.conf (опционально);

    • отдельно для backup: config/cinder/cinder-backup/ceph.conf (опционально).

  • Файлы keyring (для каждого cluster):

    • для cinder-volume: config/cinder/cinder-volume/<cluster>.{{ ceph_cinder_keyring }};

    • для cinder-backup (доступ к volumes): config/cinder/cinder-backup/<cluster>.{{ ceph_cinder_keyring }};

    • для cinder-backup (доступ к backups): config/cinder/cinder-backup/<cluster>.{{ ceph_cinder_backup_keyring }}.

    Стандартные примеры (cluster=ceph, стандартные имена пользователей):

    • config/cinder/cinder-volume/ceph.client.cinder.keyring

    • config/cinder/cinder-backup/ceph.client.cinder.keyring

    • config/cinder/cinder-backup/ceph.client.cinder-backup.keyring

Примечание

Для cinder-backup часто требуются два набора ключей: один — с caps на pool volumes, второй — на pool backups, поскольку cinder-backup читает тома из одного пула (volumes) и записывает резервные копии в другой (backups).

Nova

Nova использует Ceph в двух местах:

  • Эфемерные диски на RBD (если включен nova_backend_ceph):

    • конфигурация: config/nova/ceph.conf (или config/nova/<hostname>/ceph.conf для конфигурации, специфичной для конкретного узла);

      Пример ceph.conf:

      [global]
fsid = 1d89fec3-325a-4963-a950-c4afedd37fe3
keyring = /etc/ceph/ceph.client.nova.keyring
mon_initial_members = ceph-0
mon_host = 192.168.0.56
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

    • файл keyring: config/nova/<cluster>.{{ ceph_nova_keyring }}. Стандартный пример: config/nova/ceph.client.nova.keyring.

  • Подключение томов Cinder через RBD (если включен cinder_backend_ceph): на Compute-узлах nova-compute должен уметь читать RBD-тома от имени пользователя Cinder, поэтому обычно дополнительно нужен файл keyring для Cinder в секции Nova: config/nova/<cluster>.{{ ceph_cinder_keyring }}. Стандартный пример: config/nova/ceph.client.cinder.keyring.

Использование Vault для хранения ключей Ceph

Если в вашей инсталляции используется HashiCorp Vault, ключи Ceph можно хранить в Vault и генерировать файлы keyring в процессе развёртывания (вместо хранения ключей в репозитории).

Переменные, используемые в примерах ниже, задаются в переменных окружения инсталляции и читаются Ansible через group_vars:

  • vault_engine — имя KV v2 mount в Vault (например, secret_v2). Список доступных mount: vault secrets list.

  • vault_prefix — корневой путь секретов конкретной инсталляции облака (регион/площадка/кластер). Внутри этого пути создаётся секрет ceph.

По структуре секрет ceph представляет собой один KV‑секрет, в котором поля содержат строки‑ключи (например: ceph_glance_key, ceph_cinder_key, ceph_nova_key).

Значения ключей Ceph (строки вида AQB...==) получают с кластера Ceph. Выполните следующие команды на административном узле Ceph или на любом узле с доступом к Ceph CLI и кейрингом администратора Ceph:

ceph auth get-key client.glance
ceph auth get-key client.cinder
ceph auth get-key client.nova

Примечание

В стандартном процессе развёртывания загрузка ключей в Vault выполняется автоматически через CI/CD pipeline. Приведённый ниже пример предназначен для случаев, когда требуется загрузить или обновить ключи вручную — вне CI/CD (например, при первоначальной инициализации или отладке). Для ручного запуска необходимы: установленный Vault CLI, доступный VAULT_ADDR и активный метод аутентификации в Vault.

Пример загрузки ключей в Vault (KV v2) через CLI вручную:

# Запись ключей в <vault_engine>/<vault_prefix>/ceph
vault kv put -mount={{ vault_engine }} {{ vault_prefix }}/ceph \
  ceph_glance_key="AQB...==" \
  ceph_cinder_key="AQB...==" \
  ceph_nova_key="AQB...=="

Для проверки записанных значений выполните:

vault kv get -mount={{ vault_engine }} {{ vault_prefix }}/ceph

Примечание

В Ansible lookup для KV v2 часто используется API‑путь вида secret={{ vault_engine }}/data/{{ vault_prefix }}/ceph:ceph_glance_key. Суффикс /data/ относится к HTTP API KV v2; в командах vault kv put/get он не используется.

Далее можно хранить в пользовательских директориях не «готовый» keyring, а его шаблон. Шаблон размещается по тому же пути, что и обычный файл keyring (например, config/glance/ceph.client.glance.keyring). Пример шаблона для Glance:

[client.{{ ceph_glance_user }}]
  key = {{ lookup('hashi_vault',
                  'secret={{ vault_engine }}/data/{{ vault_prefix }}/ceph:ceph_glance_key',
                  ca_cert='/etc/gitlab-runner/certs/ca.crt') }}

Аналогично создаются шаблоны для Cinder/Nova, меняется только имя поля в секрете ceph (например, ceph_cinder_key или ceph_nova_key).

Проверка интеграции

После успешного завершения развёртывания убедитесь, что сервисы корректно используют Ceph в качестве бэкенда:

  • Для Glance — загрузите тестовый образ и проверьте, что он сохранён в пуле images:

    koc image create --disk-format raw --container-format bare \
--file <путь_к_образу> test-ceph-image
rbd ls images

  • Для Cinder — создайте том и проверьте его наличие в пуле volumes:

    koc volume create --size 1 test-ceph-volume
rbd ls volumes

  • Для Nova — убедитесь, что эфемерный диск виртуальной машины размещается в пуле vms:

    rbd ls vms

Сноски по кастомизации

  • Имя кластера: если ваш Ceph‑кластер называется не ceph, то меняются имена файлов <cluster>.conf и <cluster>.<keyring>. Например, при cluster=sales_b стандартный keyring для Glance будет записан как sales_b.client.glance.keyring (а не ceph.client.glance.keyring).

  • Пулы: если пулы называются не стандартно, задайте соответствующие ceph_*_pool_name (например, ceph_cinder_pool_name).

  • Пользователи/keyring-файлы: если пользователи имеют префиксы/суффиксы (например, sales_b.glance), задайте ceph_*_user и (при необходимости) ceph_*_keyring. Тогда ожидаемое имя файла станет, например, ceph.client.sales_b.glance.keyring.

  • Пути: базовый принцип Kolla — читать из {{ node_custom_config }}/<service>/... и копировать в каталог контейнера. Если вы переопределяете пути, ориентируйтесь на задачи Copy over ceph ... keyrings для соответствующих сервисов (glance/cinder/nova).

Переподписка в динамическом выделении ёмкости

OpenStack Block Storage позволяет выбирать бэкенд томов на основе виртуальных ёмкостей для динамического выделения ресурсов с использованием коэффициента переподписки.

Механизм переподписки позволяет администраторам выделять больше виртуальной ёмкости хранилища, чем физически доступно в системе. Это особенно полезно при использовании технологии динамического выделения ёмкости (thin provisioning), когда физическое пространство выделяется только по мере записи данных, а не резервируется заранее.

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

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

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

Значение по умолчанию составляет 20.0, что означает, что выделенная ёмкость может в 20 раз превышать общую физическую ёмкость. Коэффициент 10.5 означает, что выделенная ёмкость может в 10.5 раз превышать общую физическую ёмкость. Коэффициент 1.0 означает, что выделенная ёмкость не может превышать общую физическую ёмкость. Значение коэффициента ниже 1.0 игнорируется, и вместо него используется значение по умолчанию.

Этот параметр также можно установить как max_over_subscription_ratio=auto. При использовании значения auto Cinder автоматически рассчитывает max_over_subscription_ratio на основе выделенной ёмкости и используемого пространства. Это позволяет создавать большее количество томов в начале жизненного цикла пула и начинать ограничивать создание томов по мере приближения свободного места к нулю или зарезервированному лимиту.

Примечание

Параметр max_over_subscription_ratio можно настроить для каждого бэкенда при включении нескольких бэкендом хранилища. Он предоставляется как референсная реализация и используется драйвером LVM. Однако использование этого параметра из cinder.conf не является обязательным требованием для драйвера.

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

При установке значения auto рассчитываемые Cinder значения могут динамически изменяться в зависимости от выделенной ёмкости пула и потребляемого пространства.

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

Примечание

Изменился способ использования reserved_percentage. Раньше он измерялся относительно свободной ёмкости. Теперь он измеряется относительно общей ёмкости.

Возможности драйверов

Драйверы могут сообщать следующие возможности для бэкенда или пула:

  • thin_provisioning_support = True (или False)

  • thick_provisioning_support = True (или False)

  • provisioned_capacity_gb = PROVISIONED_CAPACITY

  • max_over_subscription_ratio = MAX_RATIO

Где PROVISIONED_CAPACITY — это видимое выделенное пространство, указывающее, сколько ёмкости было выделено, а MAX_RATIO — максимальный коэффициент переподписки. Для драйвера LVM это значение max_over_subscription_ratio из cinder.conf.

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

Драйвер LVM сообщает thin_provisioning_support=True и thick_provisioning_support=False, если флаг lvm_type в cinder.conf установлен как thin. В противном случае он сообщает thin_provisioning_support=False и thick_provisioning_support=True.

Дополнительные спецификации типа тома

Если тип тома предоставляется как часть запроса на создание тома, он может иметь следующие определённые дополнительные спецификации:

  • 'capabilities:thin_provisioning_support': '<is> True' или '<is> False'

  • 'capabilities:thick_provisioning_support': '<is> True' или '<is> False'

Примечание

Ключ области capabilities перед thin_provisioning_support и thick_provisioning_support не является обязательным. Поэтому также работают следующие варианты:

  • 'thin_provisioning_support': '<is> True' или '<is> False'

  • 'thick_provisioning_support': '<is> True' или '<is> False'

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

Дополнительные спецификации репликации томов

OpenStack Block Storage имеет возможность создавать реплики томов. Администраторы могут определить политику хранения, включающую репликацию, настроив драйвер томов Cinder. Репликация томов для OpenStack Block Storage помогает защитить среды OpenStack от потери данных во время аварийного восстановления.

Чтобы включить репликацию при создании типов томов, настройте том Cinder с параметром capabilities:replication="<is> True".

Каждый том, созданный с возможностью репликации, установленной в True, создаёт копию тома на бэкенд хранилища.

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

В каждом центре обработки данных узел Cinder поддерживает службу Block Storage. Оба центра обработки данных включают бэкенд хранилища.

В зависимости от требований к хранению может быть один или два узла Cinder. Администратор обращается к файлу конфигурации /etc/cinder/cinder.conf и устанавливает capabilities:replication="<is> True".

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

Фильтр ёмкости

В фильтре ёмкости max_over_subscription_ratio используется при выборе бэкенда, если thin_provisioning_support равен True и max_over_subscription_ratio больше 1.0.

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

Взвешиватель ёмкости

Во взвешивателе ёмкости виртуальная свободная ёмкость используется для ранжирования, если thin_provisioning_support равен True. В противном случае будет использоваться реальная свободная ёмкость, как и раньше.

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