Настройка Ceph RBD (Block Device) для виртуальных машин

Локальные диски виртуальных машин привязывают к хосту и превращают каждую миграцию в долгую операцию копирования данных. Мы настраиваем Ceph RBD — блочное хранилище, которое делает диски доступными с любого сервера кластера и позволяет переносить VM без даунтайма. Наша команда реализует проект под ключ: от конфигурации пулов и аутентификации до интеграции с KVM/QEMU и Kubernetes, обеспечивая стабильную работу и последующую поддержку.
Часто задаваемые вопросы

Настройка Ceph RBD (Block Device) для виртуальных машин

Представьте: вам нужно срочно перенести виртуальную машину на другой сервер из-за аппаратной проблемы. Если диск локальный — вы ждёте копирования qcow2 через сеть. Мы в своей практике постоянно сталкиваемся с этой болью и предлагаем решение — Ceph RBD.

Ceph RBD (RADOS Block Device) — это блочные диски, которые хранятся не на локальном железе хоста виртуализации, а в Ceph-кластере. Виртуальная машина на KVM/QEMU работает с RBD-диском точно так же, как с обычным qcow2 на локальном SSD, но при этом диск доступен с любого хоста кластера и реплицируется между Ceph-нодами.

Главный сценарий — live migration виртуальных машин. Нет локального диска, который нужно переносить. virsh migrate работает без копирования данных: VM просто перезапускается на другом хосте, продолжая работать с теми же данными в Ceph. Мы гарантируем SLA времени миграции < 1 секунды при правильно настроенной сети.

Почему RBD лучше локального хранилища?

Локальное хранилище (qcow2) проще, но оно привязывает VM к конкретному хосту и требует копирования данных при миграции. RBD добавляет 10-20% latency (на NVMe это незаметно), но даёт:

  • Live migration без даунтайма
  • Мгновенные снапшоты и клоны из снапшота (CoW)
  • Репликация (size=3 по умолчанию)
  • Возможность расширения диска без остановки VM
  • Интеграция с Kubernetes через CSI

Наши инженеры с 10+ годами опыта развернули RBD для проектов от 10 до 500 VM.

Предварительная настройка: пул и аутентификация

Предполагаем, что Ceph-кластер уже работает. Создаём выделенный пул для VM-дисков и настраиваем репликацию:

ceph osd pool create vms 0 0 replicated
rbd pool init vms
ceph osd pool set vms size 3
ceph osd pool set vms min_size 2
ceph osd pool set vms pg_autoscale_mode on

Создаём отдельного пользователя Ceph для QEMU с минимально необходимыми правами. Принцип наименьших привилегий: клиент libvirt имеет доступ только к пулу vms, не к admin keyring.

ceph auth get-or-create client.libvirt \
    mon 'profile rbd' \
    osd 'profile rbd pool=vms' \
    -o /etc/ceph/ceph.client.libvirt.keyring

Как настроить интеграцию Ceph RBD с KVM/QEMU?

Создаём RBD-образ для виртуальной машины и включаем необходимые фичи (layering, exclusive-lock, object-map, fast-diff, deep-flatten):

rbd create vms/vm-webserver-01 --size 102400
rbd feature enable vms/vm-webserver-01 exclusive-lock
rbd feature enable vms/vm-webserver-01 object-map
rbd feature enable vms/vm-webserver-01 fast-diff
rbd feature enable vms/vm-webserver-01 deep-flatten

Конфигурация диска в libvirt XML (virsh edit vm-webserver-01):

<disk type='network' device='disk'>
  <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
  <auth username='libvirt'>
    <secret type='ceph' uuid='9bbd7a99-7512-4dc2-a443-8a0bec3e2acf'/>
  </auth>
  <source protocol='rbd' name='vms/vm-webserver-01'>
    <host name='192.168.20.1' port='6789'/>
    <host name='192.168.20.2' port='6789'/>
    <host name='192.168.20.3' port='6789'/>
  </source>
  <target dev='vda' bus='virtio'/>
</disk>

Секрет libvirt создаётся из ключа пользователя client.libvirt. Подробности опустим — они есть в официальной документации QEMU.

Kubernetes Persistent Volumes через Ceph CSI

Для Kubernetes RBD-диски предоставляются через ceph-csi-rbd — официальный CSI-драйвер. Установка через Helm:

helm repo add ceph-csi https://ceph.github.io/csi-charts
helm repo update
helm install ceph-csi-rbd ceph-csi/ceph-csi-rbd \
  --namespace ceph-csi \
  --create-namespace \
  --values ceph-csi-rbd-values.yaml

Пример ceph-csi-rbd-values.yaml:

csiConfig:
  - clusterID: "ваш-ceph-cluster-id"
    monitors:
      - "192.168.20.1:6789"
      - "192.168.20.2:6789"
      - "192.168.20.3:6789"
storageClass:
  create: true
  name: ceph-rbd
  clusterID: "ваш-ceph-cluster-id"
  pool: vms
  imageFeatures: layering,exclusive-lock,object-map,fast-diff,deep-flatten
  reclaimPolicy: Delete
  allowVolumeExpansion: true
secret:
  create: true
  name: ceph-csi-rbd-secret
  userID: kubernetes
  userKey: "ваш-base64-ключ"

PVC провижинится за секунды — RBD-образ создаётся в Ceph, форматируется и монтируется на ноду. Мы такая настройка ускоряет развёртывание приложений в 3 раза.

Снапшоты RBD: мгновенные копии VM

Снапшоты — одно из главных преимуществ RBD. Консистентный снапшот VM-диска без остановки ВМ (при наличии гостевого агента):

rbd snap create vms/vm-webserver-01@snap-before-upgrade 

Clone из снапшота (copy-on-write) — копия создаётся мгновенно и не занимает дополнительное место до записи:

rbd snap protect vms/vm-webserver-01@snap-before-upgrade
rbd clone vms/vm-webserver-01@snap-before-upgrade vms/vm-webserver-02
rbd flatten vms/vm-webserver-02 # для независимости

Мониторинг производительности RBD

ceph osd pool stats vms rbd perf image iostat --pool vms ceph osd perf 

Для Prometheus метрики RBD доступны через ceph_exporter. Ключевые метрики: ceph_rbd_read_latency_sum, ceph_rbd_write_latency_sum, ceph_pool_wr_bytes. Рекомендуем дашборд Grafana ID 5336.

Типичные проблемы

Slow ops на OSD при активной работе с VM-диском. Смотрим ceph daemon osd.0 dump_ops_in_flight — видим застрявшие операции. Часто причина — файрвол или MTU mismatch между cluster-сетью и public-сетью.

VM не стартует: rbd: cannot open image, No such file or directory. Проверяем права: rbd info vms/vm-name от имени client.libvirt. Часто — неправильный keyring или expired аутентификационный тикет.

Снапшот замораживает запись ВМ на несколько секунд. Это нормально при fs-freeze через QEMU guest agent. Без агента — снапшот не консистентен, приложения внутри ВМ могут увидеть повреждённые данные после восстановления.

Что входит в работу

Этап Результат
Аудит текущей инфраструктуры Ceph и гипервизоров Рекомендации по оптимизации, план миграции
Проектирование пулов, настройка репликации и pg_autoscaler Конфигурация пула vms с size=3
Создание пользователей и секретов для KVM и Kubernetes keyring-файлы, секреты libvirt, csi-secret
Интеграция с KVM/QEMU: переключение VM на RBD Zero-downtime миграция на RBD
Интеграция с Kubernetes: StorageClass, PVC, снапшоты Работающий ceph-csi, тестовые PVC
Мониторинг и runbook Дашборд Grafana, документация по действиям при авариях
Обучение команды 2-часовой workshop, видео, чеклисты

Сроки и стоимость

Сценарий Время
KVM/QEMU интеграция, базовые операции 2-3 дня
+Kubernetes CSI, StorageClass, snapshotting 3-5 дней
+Мониторинг, runbook, обучение команды +1-2 дня

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Наши инженеры имеют сертификаты Red Hat Ceph, гарантируем SLA 99.9%. Свяжитесь с нами для консультации — оценим проект за 1 день.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1142