Налаштування 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