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

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

  7. Запустите задачу 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:

    openstack image create --disk-format raw --container-format bare \
    --file <путь_к_образу> test-ceph-image
    rbd ls images
    
  • Для Cinder — создайте том и проверьте его наличие в пуле volumes:

    openstack 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).