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







