Внешний 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¶
На стороне Ceph подготовьте:
MON-адреса (
mon_host) иfsid;пулы (обычно это
images,volumes,backupsиvms);пользователей (clients) и ключи с нужными caps для Glance/Cinder/Nova.
Включите Ceph-бэкенды в
globals.d/ceph.yml(или эквивалентно вglobals.d/REGION.yml). Для этого задайте в файле соответствующие переменные со значениемyes.glance_backend_ceph: "yes" nova_backend_ceph: "yes" cinder_backend_ceph: "yes"
Разместите файл
ceph.confи файлыkeyringв соответствующих директориях project_k / deployments / <имя региона> / config / ... или других необходимых каталогах. Более подробная информация представлена в разделе Ожидаемые пути и имена файлов.Создайте новый пайплайн: .
В открывшемся окне добавьте переменную
KOLLA_ARGS, в которой укажите теги сервисов, которые будут использовать Ceph в качестве внешнего хранилища:-t glance,cinder,nova.Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу 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.keyringconfig/cinder/cinder-backup/ceph.client.cinder.keyringconfig/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).