Ceph2: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показано 15 промежуточных версий этого же участника)
Строка 63: Строка 63:
 
<PRE>
  
<PRE>
 
ceph health detail
  
ceph health detail
  +
</PRE>
  +
  +
==Поиск проблемы==
  +
<PRE>
  +
ceph health detail
  +
</PRE>
  +
<PRE>
  +
ceph crash ls-new
  +
</PRE>
  +
<PRE>
  +
ceph crash ls
  +
</PRE>
  +
  +
<PRE>
  +
crash_id=$(ceph crash ls-new | head -n1)
  +
</PRE>
  +
Например
  +
<PRE>
  +
ceph crash ls-new
  +
ID ENTITY NEW
  +
2025-10-09T02:33:59.353672Z_43e260ca-1fdd-497e-9a42-dadb8f33d8a8 osd.432 *
  +
</PRE>
  +
<PRE>
  +
ceph crash info "$crash_id" -f json-pretty | jq -r '.entity_name, .daemon, .utsname.nodename, .timestamp'
  +
</PRE>
  +
Пример
  +
<PRE>
  +
ceph crash info 2025-10-09T02:33:59.353672Z_43e260ca-1fdd-497e-9a42-dadb8f33d8a8
  +
{
  +
"assert_condition": "p->first > start+len",
  +
"assert_file": "/builddir/build/BUILD/ceph-18.2.7/src/include/interval_set.h",
  +
"assert_func": "void interval_set<T, C>::insert(T, T, T*, T*) [with T = long unsigned int; C = std::map]",
  +
"assert_line": 536,
  +
"assert_msg": "/builddir/build/BUILD/ceph-18.2.7/src/include/interval_set.h: In function 'void interval_set<T, C>::insert(T, T, T*, T*) [with T = long unsigned int; C = std::map]' thread 7fe8313de640 time 2025-10-09T02:33:59.350176+0000\n/builddir/build/BUILD/ceph-18.2.7/src/include/interval_set.h: 536: FAILED ceph_assert(p->first > start+len)\n",
  +
"assert_thread_name": "bstore_discard",
  +
"backtrace": [
  +
"/lib64/libc.so.6(+0x3ebf0) [0x7fe83eaacbf0]",
  +
"/lib64/libc.so.6(+0x8c21c) [0x7fe83eafa21c]",
  +
"raise()",
  +
"abort()",
  +
"(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x169) [0x55ad196f0f9f]",
  +
"ceph-osd(+0x3cd100) [0x55ad196f1100]",
  +
"ceph-osd(+0x46831c) [0x55ad1978c31c]",
  +
"(KernelDevice::_discard_thread(unsigned long)+0x1ce) [0x55ad1a062a7e]",
  +
"ceph-osd(+0xd3f355) [0x55ad1a063355]",
  +
"/lib64/libc.so.6(+0x8a4da) [0x7fe83eaf84da]",
  +
"/lib64/libc.so.6(+0x10f550) [0x7fe83eb7d550]"
  +
],
  +
"ceph_version": "18.2.7",
  +
"crash_id": "2025-10-09T02:33:59.353672Z_43e260ca-1fdd-497e-9a42-dadb8f33d8a8",
  +
"entity_name": "osd.432",
  +
"os_id": "centos",
  +
"os_name": "CentOS Stream",
  +
"os_version": "9",
  +
"os_version_id": "9",
  +
"process_name": "ceph-osd",
  +
"stack_sig": "8d98f4fe4f2c07db24137ab90a0513cf1cd5663cb5eaa155a406da0063eb33a6",
  +
"timestamp": "2025-10-09T02:33:59.353672Z",
  +
"utsname_hostname": "kaas-node-b546f17a-885c-4439-8e40-57532fef9c91",
  +
"utsname_machine": "x86_64",
  +
"utsname_release": "5.15.0-143-generic",
  +
"utsname_sysname": "Linux",
  +
"utsname_version": "#153-Ubuntu SMP Fri Jun 13 19:10:45 UTC 2025"
  +
}
  +
</PRE>
  +
  +
==Заархивировать запись==
  +
<PRE>
  +
ceph crash archive "$crash_id"
  +
</PRE>
  +
или все сразу
  +
<PRE>
  +
ceph crash archive-all
 
</PRE>
  
</PRE>
   
Строка 136: Строка 209:
 
</PRE>
  
</PRE>
   
−
==примонтировать диск цефа снаружи виртуалки (на хосте)==
 +
=примонтировать диск цефа снаружи виртуалки (на хосте)=
 
Запускать нужно с правами рута, например в контейнере с libvirt, предварительно скопировав туда файл с ключем /etc/ceph/ceph.client.nova.keyring который можно найти в nova-compute контейнере
  
Запускать нужно с правами рута, например в контейнере с libvirt, предварительно скопировав туда файл с ключем /etc/ceph/ceph.client.nova.keyring который можно найти в nova-compute контейнере
 
<PRE>
  
<PRE>
Строка 142: Строка 215:
 
</PRE>
  
</PRE>
   
−
==проверить фактически занятое место внутри цефа на вольюме==
 +
=проверить фактически занятое место внутри цефа на вольюме=
 
Запускать нужно с правами рута, например в контейнере с libvirt, предварительно скопировав туда файл с ключем
  
Запускать нужно с правами рута, например в контейнере с libvirt, предварительно скопировав туда файл с ключем
 
<code>/etc/ceph/ceph.client.nova.keyring </code> который можно найти в <code>nova-compute</code> контейнере
  
<code>/etc/ceph/ceph.client.nova.keyring </code> который можно найти в <code>nova-compute</code> контейнере
Строка 179: Строка 252:
 
</PRE>
  
</PRE>
   
−
==поставить/снять для всех осд на ноде флаг noout==
 +
=поставить/снять для всех осд на ноде флаг noout=
 
<PRE>
  
<PRE>
 
ceph osd set-group noout kaas-node-820ad8bd-45bd-4c4b-8271-2b697987aa21
  
ceph osd set-group noout kaas-node-820ad8bd-45bd-4c4b-8271-2b697987aa21
Строка 187: Строка 260:
 
</PRE>
  
</PRE>
   
−
==посмотреть метадату по номеру OSD==
 +
=посмотреть метадату по номеру OSD=
 
<PRE>
  
<PRE>
 
ceph osd metadata | jq '.[] | select(.id==22)'
  
ceph osd metadata | jq '.[] | select(.id==22)'
Строка 196: Строка 269:
 
</PRE>
  
</PRE>
   
  +
=<code>kaascephcluster</code>=
−
==1==
  
−
найти диск /dev/sdX по его айди в kaascephcluster объекте зная его имя из вывода dmesg
 +
==найти диск /dev/sdX по его айди в kaascephcluster объекте зная его имя из вывода dmesg==
   
−
быввет так что диск в kaascephcluster добавлен не по букве /dev/sdc а by-id и тогда сложно сопоставить вывалившийся диск по dmesg с kaascephcluster записями.
 +
быввет так что диск в kaascephcluster добавлен не по букве <code>/dev/sdc</code>
  +
а by-id и тогда сложно сопоставить вывалившийся диск по dmesg с kaascephcluster записями.
−
вот так моджн осопоставить зная девайс и ноду:
  
  +
<BR>
  +
вот так можно сопоставить зная девайс и ноду:
   
  +
<PRE>
 
kubectl -n ceph-lcm-mirantis get miracephlog -o yaml
  
kubectl -n ceph-lcm-mirantis get miracephlog -o yaml
  +
</PRE>
−  
 
тут будет нечто:
  
тут будет нечто:
−
kaas-node-12c448d3-ca7e-4817-9d25-fe21aa441d4c:
  
 
<PRE>
  
<PRE>
  +
kaas-node-12c448d3-ca7e-4817-9d25-fe21aa441d4c:
  +
 
osd.17:
  
osd.17:
 
blockPartition: /dev/dm-3
  
blockPartition: /dev/dm-3
Строка 223: Строка 300:
 
</PRE>
  
</PRE>
   
  +
=замьютить варнинги в ceph чтоьбы он показал health-ok и можно было с ним работать(добавлять новые осд и другое)=
−  
  +
<PRE>
−
==замьютить варнинги в ceph чтоьбы он показал health-ok и можно было с ним работать(добавлять новые осд и другое)==
  
 
ceph health mute OSD_NEARFULL 1h
  
ceph health mute OSD_NEARFULL 1h
  +
</PRE>
  +
<PRE>
 
ceph health mute POOL_NEARFULL 1h
  
ceph health mute POOL_NEARFULL 1h
  +
</PRE>
   
  +
поархивировать варнинги о крашнутых osd - раньше они были,
−  
−
поархивировать варнинги о крашнутых osd - раньше они были, сеф их зафиксировал, но сейчас они работают нормлаьно, однако ceph -s показывает ворнинг, решение ниже:
 +
сеф их зафиксировал, но сейчас они работают нормлаьно, однако ceph -s показывает ворнинг, решение ниже:
  +
<PRE>
 
ceph crash archive-all
  
ceph crash archive-all
  +
</PRE>
−  
   
 
==Identify existing images on Ceph==
  
==Identify existing images on Ceph==
−
#from glance pod:
 +
from glance pod:
  +
<PRE>
−
# rbd -n client.glance ls -p <pool-name>
  
  +
rbd -n client.glance ls -p <pool-name>
−  
  +
</PRE>
−
# from keystone-client pod:
  
  +
Смотреть
−
# openstack image list --all-projects
  
  +
* from keystone-client pod:
−
 
  +
* openstack image list --all-projects
−
Compare the two lists, and either delete the VMs using the missing images to permanently remove the image from Openstack, or copy the image to a new UUID for use later on. If you'd like, we can schedule a webex to assist with this action.
  
   
  +
Compare the two lists, and either delete the VMs using the missing images to permanently <BR>
  +
remove the image from Openstack, or copy the image to a new UUID for use later on.
   
 
==to find osd id by device name==
  
==to find osd id by device name==
Строка 274: Строка 357:
 
</PRE>
  
</PRE>
   
−
=2=
  
−
показать список винтов
  
−
ceph device ls | grep "kaas-node-74fd42ba-ec8f-4ce8-8d29-5ba4777d19a6:sdj
  
−
информация о девайсе
  
−
ceph device info <devid>
  
−
показать здоровье кластера
  
−
ceph -s
  
−
ceph health detail
  
−
показать дерево osd
  
−
ceph osd tree
  
−
посмотреть пулы
  
−
ceph osd lspools
  
−
проверить занятость osd
  
−
ceph osd df
  
−
 
 
=Replication Factor=
  
=Replication Factor=
 
Если нет места то можно уменьшить число реплик, вплоть до 1 (что может быть не безопасно)
  
Если нет места то можно уменьшить число реплик, вплоть до 1 (что может быть не безопасно)
Строка 373: Строка 441:
 
* --id nova - “идентификатор клиента” (я не знаю что это означает но без этого параметра не работает)
  
* --id nova - “идентификатор клиента” (я не знаю что это означает но без этого параметра не работает)
 
 
−
Просмотреть подмонтированные
 +
==Просмотреть подмонтированные==
 
<PRE>
  
<PRE>
 
root@r710:/# rbd showmapped
  
root@r710:/# rbd showmapped
Строка 379: Строка 447:
 
0 vms-ssd f2dfe088-0516-45a3-a6ab-305868be9f79_disk - /dev/rbd0
  
0 vms-ssd f2dfe088-0516-45a3-a6ab-305868be9f79_disk - /dev/rbd0
 
</PRE>
 
</PRE>
−
Отключить подключенный диск
 +
==Отключить подключенный диск==
 
<PRE>
  
<PRE>
 
rbd device unmap /dev/rbd0
  
rbd device unmap /dev/rbd0
 
</PRE>
 
</PRE>
  +
−
Еще примеры
  
−
найти все диски для всех ВМок и подмонтировать их (запускать из либвирт контейнера)
 +
==найти все диски для всех ВМок и подмонтировать их (запускать из либвирт контейнера)==
  +
<PRE>
 
for VM_NAME in $(virsh list --all --name);
  
for VM_NAME in $(virsh list --all --name);
 
do
  
do
Строка 392: Строка 461:
 
rbd -c /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.nova.keyring device map --pool ${POOL_NAME} ${DISK_NAME} --id nova
  
rbd -c /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.nova.keyring device map --pool ${POOL_NAME} ${DISK_NAME} --id nova
 
done
  
done
  +
</PRE>
−
 
  +
<PRE>
 
#!/bin/bash
  
#!/bin/bash
   
Строка 416: Строка 486:
 
$rbd -c /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.nova.keyring device unmap ${DEV_NAME}
  
$rbd -c /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.nova.keyring device unmap ${DEV_NAME}
 
done
  
done
  +
</PRE>
   
  +
=Mirantis-специфичное=
−
exit
  
  +
Это куски документации переведенне и с комментариями (иногда)
−
Mirantis
  
−
Задать число реплик контроллеров
+
==Задать число реплик контроллеров==
 
если нужно сэкономить ресурсы и пох на все
  
если нужно сэкономить ресурсы и пох на все
  +
<PRE>
 
EDITOR=mcedit mgtctl -n mosk edit cluster child-cluster
  
EDITOR=mcedit mgtctl -n mosk edit cluster child-cluster
  +
</PRE>
−
 
  +
<PRE>
 
helmReleases:
  
helmReleases:
 
- name: ceph-controller
  
- name: ceph-controller
Строка 438: Строка 511:
 
cephStatus:
  
cephStatus:
 
replicas: 1
  
replicas: 1
  +
</PRE>
 
Часть rookOperatorPlacement не относится к репликам
  
Часть rookOperatorPlacement не относится к репликам
 
 
 
 
−
Задать фактор репликации по-умолчанию
 +
==Задать фактор репликации по-умолчанию==
 
Что бы после обновления он не откатился к дофолту, если был сменен руками установить size: 1
  
Что бы после обновления он не откатился к дофолту, если был сменен руками установить size: 1
  +
<PRE>
 
EDITOR=mcedit mgtctl -n mosk edit kaascephclusters ceph-child-cluster
  
EDITOR=mcedit mgtctl -n mosk edit kaascephclusters ceph-child-cluster
  +
</PRE>
−
 
  +
<PRE>
 
apiVersion: kaas.mirantis.com/v1alpha1
  
apiVersion: kaas.mirantis.com/v1alpha1
 
kind: KaaSCephCluster
  
kind: KaaSCephCluster
Строка 457: Строка 533:
 
role: kubernetes
  
role: kubernetes
 
- default: false
  
- default: false
  +
</PRE>
 
 
  +
=Замена сломанного диска (OSD)=
−
 
−
Замена сломанного диска (OSD)
  
 
Посмотреть метаданные (откуда достать ноду и имя устройства) можно так:
  
Посмотреть метаданные (откуда достать ноду и имя устройства) можно так:
  +
<PRE>
−
root@nest:~# ceph osd metadata | jq '.'
  
  +
ceph osd metadata | jq '.'
  +
</PRE>
  +
<PRE>
 
[
  
[
 
{
  
{
Строка 518: Строка 597:
 
"rotational": "1"
  
"rotational": "1"
 
},
  
},
  +
</PRE>
 
Найти сломанные OSD
  
Найти сломанные OSD
  +
<PRE>
 
ceph osd tree down
  
ceph osd tree down
  +
</PRE>
  +
<PRE>
 
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
  
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
 
-1 111.66374 root default
  
-1 111.66374 root default
Строка 528: Строка 611:
 
30 hdd 3.63799 osd.30 down 0 1.00000
  
30 hdd 3.63799 osd.30 down 0 1.00000
 
31 hdd 3.63799 osd.31 down 0 1.00000
  
31 hdd 3.63799 osd.31 down 0 1.00000
  +
</PRE>
−
 
−
Для того что бы найти ноды (хостнейм известен - kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 ) но это нужно как-то сопоставить с именем ноды в объекте kaascephcluster
+
Для того что бы найти ноды (хостнейм известен - kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 ) <BR>
  +
но это нужно как-то сопоставить с именем ноды в объекте kaascephcluster
 
Это можно сделать через объект machine
 
Это можно сделать через объект machine
  +
<PRE>
 
kubectl get ma -A -o wide | grep mos-ceph-osd004
  
kubectl get ma -A -o wide | grep mos-ceph-osd004
  +
</PRE>
−  
  +
<PRE>
 
eu-production-mos mos-ceph-osd004 true Ready kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 83 false
  
eu-production-mos mos-ceph-osd004 true Ready kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 83 false
  +
</PRE>
 
Тут сопоставление ноды kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 и записи в объекте - mos-ceph-osd004
 
Тут сопоставление ноды kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 и записи в объекте - mos-ceph-osd004
  +
<BR>
−
Например вывод для OSD 22 - тут видно ноду "hostname": "kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4" но для того что бы удалить из кластера эту OSD нужно найти сопоставление с mos-ceph-osd004
 
  +
Например вывод для OSD 22 - тут видно ноду "hostname": "kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4" <BR>
  +
но для того что бы удалить из кластера эту OSD нужно найти сопоставление с mos-ceph-osd004
  +
<PRE>
 
ceph osd metadata 22
 
ceph osd metadata 22
  +
</PRE>
  +
<PRE>
 
{
  
{
 
"id": 22,
  
"id": 22,
Строка 603: Строка 695:
 
"rotational": "1"
  
"rotational": "1"
 
}
  
}
  +
</PRE>
 
Что из этого можно понять
  
Что из этого можно понять
−
bluefs_db_devices": "sdg" - это устройство с метадатой
 +
* bluefs_db_devices": "sdg" - это устройство с метадатой
−
bluefs_db_dev_node": "/dev/dm-2 - это блочное устройство, тут нельзя указать партицию по-тому используется LVM
 +
* bluefs_db_dev_node": "/dev/dm-2 - это блочное устройство, тут нельзя указать партицию по-тому используется LVM
−
bluestore_bdev_devices": "sdh", - устройство с данными
 +
* bluestore_bdev_devices": "sdh", - устройство с данными
 
 
 
https://docs.mirantis.com/container-cloud/latest/operations-guide/operate-managed/operate-managed-bm/manage-ceph/ceph-lcm/replace-failed-node.html
  
https://docs.mirantis.com/container-cloud/latest/operations-guide/operate-managed/operate-managed-bm/manage-ceph/ceph-lcm/replace-failed-node.html
  +
<BR>
 
dropFromClusterOnly - если не очищается поломанный диск
  
dropFromClusterOnly - если не очищается поломанный диск
 
фулл мапинг можно посмотреть на чайлде вот так: kubectl -n ceph-lcm-mirantis get miracephlog -o yaml
  
фулл мапинг можно посмотреть на чайлде вот так: kubectl -n ceph-lcm-mirantis get miracephlog -o yaml
 
При удалении OSD при удалении всех (если упали все OSD на ноде) нужно удалять ВМЕСТЕ С НОДОЙ
 
При удалении OSD при удалении всех (если упали все OSD на ноде) нужно удалять ВМЕСТЕ С НОДОЙ
 
 
−
By-ID или /dev/sdX ? (miracephlog)
 +
==By-ID или /dev/sdX ? (miracephlog)==
 
Бывыет так что диск в kaascephcluster добавлен не по букве /dev/sdX а например /dev/disk/by-id/WDC_WD4003FZEX-0_WD-WMC5D0D9DMEY и тогда сложно сопоставить вывалившийся диск по dmesg с kaascephcluster .
  
Бывыет так что диск в kaascephcluster добавлен не по букве /dev/sdX а например /dev/disk/by-id/WDC_WD4003FZEX-0_WD-WMC5D0D9DMEY и тогда сложно сопоставить вывалившийся диск по dmesg с kaascephcluster .
 
вот так моджно сопоставить зная девайс и ноду:
  
вот так моджно сопоставить зная девайс и ноду:
  +
<PRE>
−
 
 
kubectl -n ceph-lcm-mirantis get miracephlog -o yaml
  
kubectl -n ceph-lcm-mirantis get miracephlog -o yaml
  +
</PRE>
−  
 
тут будет нечто:
  
тут будет нечто:
  +
<PRE>
 
kaas-node-12c448d3-ca7e-4817-9d25-fe21aa441d4c:
  
kaas-node-12c448d3-ca7e-4817-9d25-fe21aa441d4c:
 
...
  
...
Строка 637: Строка 732:
 
up: true
  
up: true
 
...
  
...
  +
</PRE>
−
Очистка алерта от недавно скрашевшихся OSDs
  
  +
==Очистка алерта от недавно скрашевшихся OSDs==
−
 
−
поархивировать варнинги о крашнутых osd - раньше они были, сеф их зафиксировал, но сейчас они работают нормально,
  
−
однако ceph -s показывает ворнинг, решение ниже:
  
 
 
  +
поархивировать варнинги о крашнутых osd - раньше они были, сеф их зафиксировал, но сейчас они работают нормально,<BR>
  +
однако ceph -s показывает ворнинг, решение ниже:
  +
<PRE>
 
ceph crash archive-all
  
ceph crash archive-all
  +
</PRE>
 
 
  +
=Блокировки в CEPH=
−
 
−
Блокировки в CEPH
  
 
 
 
В rbd есть понятие блокировки - и список блокировок можно посмотреть командой:
  
В rbd есть понятие блокировки - и список блокировок можно посмотреть командой:
  +
<PRE>
 
rbd -p volumes-ssd lock list 66b35cdf-845e-47a4-badd-c03e1902fb44
  
rbd -p volumes-ssd lock list 66b35cdf-845e-47a4-badd-c03e1902fb44
  +
</PRE>
  +
<PRE>
 
There is 1 exclusive lock on this image.
  
There is 1 exclusive lock on this image.
 
Locker ID Address
  
Locker ID Address
 
client.53989246 auto 140537302618384 10.80.3.54:0/2974634118
  
client.53989246 auto 140537302618384 10.80.3.54:0/2974634118
  +
</PRE>
−
 
−
volumes-ssd - это имя пула
 +
* volumes-ssd - это имя пула
−
66b35cdf-845e-47a4-badd-c03e1902fb44 - это ID который можно посмотреть в openstack server show
 +
* 66b35cdf-845e-47a4-badd-c03e1902fb44 - это ID который можно посмотреть в openstack server show
−
10.80.3.54 - это адрес compute
 +
* 10.80.3.54 - это адрес compute
  +
 
При этом иногда при краше компьюты локи остаются и новая компьюта после миграции ВМ не может подключить диск
  
При этом иногда при краше компьюты локи остаются и новая компьюта после миграции ВМ не может подключить диск
 
Пример ошибки (хотя это не единственный вариант ошибки):
  
Пример ошибки (хотя это не единственный вариант ошибки):
  +
<PRE>
−
 
 
{'code': 500, 'created': '2024-02-15T17:32:25Z', 'message': 'ReadOnlyImage', 'details': 'Traceback (most recent call last):\n
  
{'code': 500, 'created': '2024-02-15T17:32:25Z', 'message': 'ReadOnlyImage', 'details': 'Traceback (most recent call last):\n
 
File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 207, in decorated_function\n
  
File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 207, in decorated_function\n
Строка 700: Строка 800:
 
File "rbd.pyx", line 3514, in rbd.Image.create_snap\n
  
File "rbd.pyx", line 3514, in rbd.Image.create_snap\n
 
rbd.ReadOnlyImage: [errno 30] RBD read-only image (error creating snapshot b\'nova-resize\' from b\'2786c568-5fda-496d-a267-551e2ce3acc5_disk\')\n'}
  
rbd.ReadOnlyImage: [errno 30] RBD read-only image (error creating snapshot b\'nova-resize\' from b\'2786c568-5fda-496d-a267-551e2ce3acc5_disk\')\n'}
  +
</PRE>
 
Например (с лабы):
  
Например (с лабы):
  +
−
 
  +
<PRE>
 
rbd -p volumes-nvme lock list e0fa47b1-6831-40fa-b626-f4eea84940c2
  
rbd -p volumes-nvme lock list e0fa47b1-6831-40fa-b626-f4eea84940c2
  +
</PRE>
  +
<PRE>
 
There is 1 exclusive lock on this image.
  
There is 1 exclusive lock on this image.
 
Locker ID Address
  
Locker ID Address
 
client.46717700 auto 139629252590528 10.187.84.142:0/3063592878
  
client.46717700 auto 139629252590528 10.187.84.142:0/3063592878
  +
</PRE>
 
Посмотреть кто использует диск можно так:
  
Посмотреть кто использует диск можно так:
 
Пример кастомера:
  
Пример кастомера:
  +
<PRE>
 
rbd status volumes-nvme/e0fa47b1-6831-40fa-b626-f4eea84940c2
  
rbd status volumes-nvme/e0fa47b1-6831-40fa-b626-f4eea84940c2
  +
</PRE>
  +
<PRE>
 
Watchers:
  
Watchers:
 
watcher=10.187.84.142:0/3063592878 client.46717700 cookie=139629252590528
  
watcher=10.187.84.142:0/3063592878 client.46717700 cookie=139629252590528
 
watcher=10.187.84.171:0/2753880368 client.402631226 cookie=140045730189824
  
watcher=10.187.84.171:0/2753880368 client.402631226 cookie=140045730189824
  +
</PRE>
 
пример с лабы
  
пример с лабы
  +
<PRE>
 
rbd status volumes-ssd/66b35cdf-845e-47a4-badd-c03e1902fb44
  
rbd status volumes-ssd/66b35cdf-845e-47a4-badd-c03e1902fb44
  +
</PRE>
  +
<PRE>
 
Watchers:
  
Watchers:
 
watcher=10.80.3.54:0/2974634118 client.53989246 cookie=140537302618384
  
watcher=10.80.3.54:0/2974634118 client.53989246 cookie=140537302618384
  +
</PRE>
 
Тут у кастомера 2 ноды - старая (мертвая), с которой ВМ перенесли на новую
  
Тут у кастомера 2 ноды - старая (мертвая), с которой ВМ перенесли на новую
  +
<BR>
 
В случае лабы только одна актуальная компьют-нода
  
В случае лабы только одна актуальная компьют-нода
  +
</BR>
 
У кастомера - проверяем что нода (10.187.84.142) не работает :
  
У кастомера - проверяем что нода (10.187.84.142) не работает :
  +
<PRE>
 
kubectl -n openstack get nodes -o wide |grep kaas-node-a0d08ca9-14eb-42dd-9908-9ecde7cb9d7c
  
kubectl -n openstack get nodes -o wide |grep kaas-node-a0d08ca9-14eb-42dd-9908-9ecde7cb9d7c
 
kaas-node-a0d08ca9-14eb-42dd-9908-9ecde7cb9d7c NotReady <none> 566d v1.24.6-mirantis-1 10.187.84.142 <none> Ubuntu 20.04.6 LTS 5.4.0-109-generic
  
kaas-node-a0d08ca9-14eb-42dd-9908-9ecde7cb9d7c NotReady <none> 566d v1.24.6-mirantis-1 10.187.84.142 <none> Ubuntu 20.04.6 LTS 5.4.0-109-generic
  +
</PRE>
−
 
 
И можно удалить (заблокировать) watcher 10.187.84.142:0/3063592878
 
И можно удалить (заблокировать) watcher 10.187.84.142:0/3063592878
  +
<PRE>
−
 
 
ceph osd blacklist add 10.187.84.142:0/3063592878 │
  
ceph osd blacklist add 10.187.84.142:0/3063592878 │
 
blocklisting 10.187.84.142:0/3063592878 until 2024-02-01T11:12:42.942069+0000 (3600 sec)
  
blocklisting 10.187.84.142:0/3063592878 until 2024-02-01T11:12:42.942069+0000 (3600 sec)
  +
</PRE>
−
 
−
10.187.84.142:0/3063592878 - адрес и идентификатор который нужно заблокировать
 +
* 10.187.84.142:0/3063592878 - адрес и идентификатор который нужно заблокировать
−
блокировка временная
 +
* блокировка временная
−
После чего диск может использовать новая компьюта
 +
* После чего диск может использовать новая компьюта
  +
−
 
  +
<PRE>
 
rbd -p volumes-nvme lock list e0fa47b1-6831-40fa-b626-f4eea84940c2
  
rbd -p volumes-nvme lock list e0fa47b1-6831-40fa-b626-f4eea84940c2
 
There is 1 exclusive lock on this image.
  
There is 1 exclusive lock on this image.
 
Locker ID Address
  
Locker ID Address
 
client.402631226 auto 140045730189824 10.187.84.171:0/2753880368
  
client.402631226 auto 140045730189824 10.187.84.171:0/2753880368
  +
</PRE>
−
 
 
Или можно удалить сразу lock (пример не с лабы, по-том такие странные пулы)
  
Или можно удалить сразу lock (пример не с лабы, по-том такие странные пулы)
  +
<PRE>
 
rbd lock remove --pool c7000-pxmx1-am7 vm-201-disk-0 "auto 140450841490944" client.70464
  
rbd lock remove --pool c7000-pxmx1-am7 vm-201-disk-0 "auto 140450841490944" client.70464
  +
</PRE>
−
"Неудаляемый" image в glance
  
  +
="Неудаляемый" image в glance=
 
Столкнулся с проблемой - невозможно удалить образ:
  
Столкнулся с проблемой - невозможно удалить образ:
  +
<PRE>
 
openstack image delete Ubuntu-22.04-root-password-set
  
openstack image delete Ubuntu-22.04-root-password-set
  +
</PRE>
  +
<PRE>
 
Failed to delete image with name or ID 'Ubuntu-22.04-root-password-set': HttpException: 500: Server Error for url: https://glance.it.just.works/v2/images/f9b77787-49f0-45cc-9758-11319ae47de8, The server has either erred or is incapable of performing the requested operation.: 500 Internal Server Error
  
Failed to delete image with name or ID 'Ubuntu-22.04-root-password-set': HttpException: 500: Server Error for url: https://glance.it.just.works/v2/images/f9b77787-49f0-45cc-9758-11319ae47de8, The server has either erred or is incapable of performing the requested operation.: 500 Internal Server Error
 
Failed to delete 1 of 1 images.
  
Failed to delete 1 of 1 images.
  +
</PRE>
 
Коротко - проблема в том, что образ был создан из запущенной ВМи - и под капотом там используются снапшоты, когда из этого образа были созданы еще ВМки
  
Коротко - проблема в том, что образ был создан из запущенной ВМи - и под капотом там используются снапшоты, когда из этого образа были созданы еще ВМки
 
 
 
Тем не менее сообщения в логах не информативны:
  
Тем не менее сообщения в логах не информативны:
  +
<PRE>
 
2024-02-05 08:40:28.847 12 WARNING glance.api.v2.images [req-4c9facef-a616-4040-b584-02bd43f0878c 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] After upload to backend, deletion of staged image data has failed because it cannot be found at /tmp/staging//f9b77787-49f0-45cc-9758-11319ae47de8
  
2024-02-05 08:40:28.847 12 WARNING glance.api.v2.images [req-4c9facef-a616-4040-b584-02bd43f0878c 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] After upload to backend, deletion of staged image data has failed because it cannot be found at /tmp/staging//f9b77787-49f0-45cc-9758-11319ae47de8
 
2024-02-05 08:40:29.101 12 ERROR glance.common.wsgi [req-4c9facef-a616-4040-b584-02bd43f0878c 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] Caught error: [errno 1] RBD permission error (error listing children.): rbd.PermissionError: [errno 1] RBD permission error (error listing children.)
  
2024-02-05 08:40:29.101 12 ERROR glance.common.wsgi [req-4c9facef-a616-4040-b584-02bd43f0878c 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] Caught error: [errno 1] RBD permission error (error listing children.): rbd.PermissionError: [errno 1] RBD permission error (error listing children.)
  +
</PRE>
 
Для того что бы (для начала) получить более информативное сообщение нужно дать для glance дополнительные права - в терминах МОСК это делается через kaascephcluster:
  
Для того что бы (для начала) получить более информативное сообщение нужно дать для glance дополнительные права - в терминах МОСК это делается через kaascephcluster:
  +
<PRE>
−
mgtctl -n mosk get kaascephcluster ceph-child-cluster -o yaml | yq .spec.cephClusterSpec.clients
  
  +
kubectl -n mosk get kaascephcluster ceph-child-cluster -o yaml | yq .spec.cephClusterSpec.clients
  +
</PRE>
  +
<PRE>
 
- caps:
  
- caps:
 
mon: allow r
  
mon: allow r
Строка 759: Строка 887:
 
mon: allow r
  
mon: allow r
 
name: cephfs-client
  
name: cephfs-client
  +
</PRE>
 
тут была добавлена секция для glance
  
тут была добавлена секция для glance
  +
<BR>
 
После этого удалить образ все так же нельзя, но есть более-менее информативное сообщение для поиска проблемы:
  
После этого удалить образ все так же нельзя, но есть более-менее информативное сообщение для поиска проблемы:
  +
<PRE>
 
2024-02-05 10:05:30.400 11 WARNING glance_store._drivers.rbd [req-585db1f1-76a7-478b-adce-adb2dfaa78a3 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] Snap Operating Exception RBD image is busy (Image snapshot has external references.) Snapshot is in use.: rbd.ImageBusy: RBD image is busy (Image snapshot has external references.)
  
2024-02-05 10:05:30.400 11 WARNING glance_store._drivers.rbd [req-585db1f1-76a7-478b-adce-adb2dfaa78a3 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] Snap Operating Exception RBD image is busy (Image snapshot has external references.) Snapshot is in use.: rbd.ImageBusy: RBD image is busy (Image snapshot has external references.)
  +
</PRE>
 
Далее можно посмотреть зависимые образы:
  
Далее можно посмотреть зависимые образы:
  +
<PRE>
 
rbd children images-ssd/f9b77787-49f0-45cc-9758-11319ae47de8
  
rbd children images-ssd/f9b77787-49f0-45cc-9758-11319ae47de8
  +
</PRE>
  +
<PRE>
 
vms-ssd/35ed30a8-5e64-4b69-a146-3264496ad6e6_disk
  
vms-ssd/35ed30a8-5e64-4b69-a146-3264496ad6e6_disk
 
vms-ssd/bb679dfb-44b6-4e10-b4c5-afb0715176b3_disk
  
vms-ssd/bb679dfb-44b6-4e10-b4c5-afb0715176b3_disk
 
vms-ssd/dc369981-978d-4fa5-801b-e202ba101d19_disk
  
vms-ssd/dc369981-978d-4fa5-801b-e202ba101d19_disk
  +
</PRE>
 
Тут видно что это диски виртуалок, это видно из имени пула vms-ssd , и ID виртуалок тоже известны - можно удалять ВМки и освобождать блокировку
  
Тут видно что это диски виртуалок, это видно из имени пула vms-ssd , и ID виртуалок тоже известны - можно удалять ВМки и освобождать блокировку
−
После удаления виртуалок, можно убедиться что зависимостей не осталось (rbd children images-ssd/f9b77787-49f0-45cc-9758-11319ae47de8)
 +
После удаления виртуалок, можно убедиться что зависимостей не осталось
  +
<PRE>
  +
rbd children images-ssd/f9b77787-49f0-45cc-9758-11319ae47de8
  +
</PRE>
 
Финальный шаг - удаление “проблемного” образа
  
Финальный шаг - удаление “проблемного” образа
  +
<PRE>
 
openstack image delete f9b77787-49f0-45cc-9758-11319ae47de8
  
openstack image delete f9b77787-49f0-45cc-9758-11319ae47de8
  +
</PRE>
−  
 
==Additional Information==
  
==Additional Information==
 
После создания OSD Ceph запустит операцию восстановления и начнет перемещать группы размещения из вторичных OSD в новый OSD. <BR>
  
После создания OSD Ceph запустит операцию восстановления и начнет перемещать группы размещения из вторичных OSD в новый OSD. <BR>

Текущая версия на 12:00, 13 октября 2025

Ceph2

Сборник рецептов по ceph

Удаление OSD из кластера

  • 123 - номер OSD на удаление
  • node-2 - хостнейм ноды на котрой этот OSD
  • sdd - блочное устройство

Пометить OSD out из кластера Ceph

ceph osd out osd.123

Удалить сбойную OSD из CRUSH map

ceph osd crush rm osd.123

Удалить ключи (authentication keys) для OSD

ceph auth del osd.123

Удалить OSD из кластера Ceph

ceph osd rm osd.123

Please keep in mind that whenever an OSD is unavailable your cluster health will not be OK, and it will continue to perform the recovery which is a normal Ceph operation in this situation.

Заменить диск

Список дисков (после замены) посмотреть так: 

ceph-deploy disk list node-2

Перед добавлением диска в кластер Ceph выполните очистку диска

Перед добавлением проверить как определился диск (sdd или другая буква) 

ceph-deploy disk zap node-2:sdd

Создать OSD на дискеи добавить в кластер Ceph как osd.123

ceph-deploy --overwrite-conf osd create node-2:sdd


показать список винтов

ceph device ls | grep "kaas-node-74fd42ba-ec8f-4ce8-8d29-5ba4777d19a6:sdj

инфа о девайсе

ceph device info <devid>

показать здоровье кластера

ceph -s

ceph health detail

Поиск проблемы

ceph health detail

ceph crash ls-new

ceph crash ls

crash_id=$(ceph crash ls-new | head -n1)

Например 

ceph crash ls-new
ID                                                                ENTITY   NEW
2025-10-09T02:33:59.353672Z_43e260ca-1fdd-497e-9a42-dadb8f33d8a8  osd.432   *

ceph crash info "$crash_id" -f json-pretty | jq -r '.entity_name, .daemon, .utsname.nodename, .timestamp'

Пример 

ceph crash info  2025-10-09T02:33:59.353672Z_43e260ca-1fdd-497e-9a42-dadb8f33d8a8
{
    "assert_condition": "p->first > start+len",
    "assert_file": "/builddir/build/BUILD/ceph-18.2.7/src/include/interval_set.h",
    "assert_func": "void interval_set<T, C>::insert(T, T, T*, T*) [with T = long unsigned int; C = std::map]",
    "assert_line": 536,
    "assert_msg": "/builddir/build/BUILD/ceph-18.2.7/src/include/interval_set.h: In function 'void interval_set<T, C>::insert(T, T, T*, T*) [with T = long unsigned int; C = std::map]' thread 7fe8313de640 time 2025-10-09T02:33:59.350176+0000\n/builddir/build/BUILD/ceph-18.2.7/src/include/interval_set.h: 536: FAILED ceph_assert(p->first > start+len)\n",
    "assert_thread_name": "bstore_discard",
    "backtrace": [
        "/lib64/libc.so.6(+0x3ebf0) [0x7fe83eaacbf0]",
        "/lib64/libc.so.6(+0x8c21c) [0x7fe83eafa21c]",
        "raise()",
        "abort()",
        "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x169) [0x55ad196f0f9f]",
        "ceph-osd(+0x3cd100) [0x55ad196f1100]",
        "ceph-osd(+0x46831c) [0x55ad1978c31c]",
        "(KernelDevice::_discard_thread(unsigned long)+0x1ce) [0x55ad1a062a7e]",
        "ceph-osd(+0xd3f355) [0x55ad1a063355]",
        "/lib64/libc.so.6(+0x8a4da) [0x7fe83eaf84da]",
        "/lib64/libc.so.6(+0x10f550) [0x7fe83eb7d550]"
    ],
    "ceph_version": "18.2.7",
    "crash_id": "2025-10-09T02:33:59.353672Z_43e260ca-1fdd-497e-9a42-dadb8f33d8a8",
    "entity_name": "osd.432",
    "os_id": "centos",
    "os_name": "CentOS Stream",
    "os_version": "9",
    "os_version_id": "9",
    "process_name": "ceph-osd",
    "stack_sig": "8d98f4fe4f2c07db24137ab90a0513cf1cd5663cb5eaa155a406da0063eb33a6",
    "timestamp": "2025-10-09T02:33:59.353672Z",
    "utsname_hostname": "kaas-node-b546f17a-885c-4439-8e40-57532fef9c91",
    "utsname_machine": "x86_64",
    "utsname_release": "5.15.0-143-generic",
    "utsname_sysname": "Linux",
    "utsname_version": "#153-Ubuntu SMP Fri Jun 13 19:10:45 UTC 2025"
}

Заархивировать запись

ceph crash archive "$crash_id"

или все сразу 

ceph crash archive-all

показать дерево osd

ceph osd tree

посмотреть пулы

ceph osd lspools

проверить использование стореджа пулами

ceph df

ceph df detail

--- RAW STORAGE ---
CLASS    SIZE   AVAIL    USED  RAW USED  %RAW USED
hdd    17 TiB  16 TiB  14 GiB    14 GiB       0.08
TOTAL  17 TiB  16 TiB  14 GiB    14 GiB       0.08

--- POOLS ---
POOL                                ID  PGS   STORED   (DATA)   (OMAP)  OBJECTS     USED   (DATA)   (OMAP)  %USED  MAX AVAIL  QUOTA OBJECTS  QUOTA BYTES  DIRTY  USED COMPR  UNDER COMPR
kubernetes-hdd                       1   32  181 MiB  181 MiB      0 B       60  542 MiB  542 MiB      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
.rgw.root                            2    8  6.5 KiB  6.5 KiB      0 B       19  216 KiB  216 KiB      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.log              3    8   89 KiB   23 KiB   66 KiB      339  2.1 MiB  1.9 MiB  199 KiB      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.buckets.index    4    8      0 B      0 B      0 B        0      0 B      0 B      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.otp              5    8      0 B      0 B      0 B        0      0 B      0 B      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.control          6    8      0 B      0 B      0 B        8      0 B      0 B      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.meta             7    8  1.7 KiB  1.3 KiB    402 B        9   73 KiB   72 KiB  1.2 KiB      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.buckets.non-ec   8    8      0 B      0 B      0 B        0      0 B      0 B      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
volumes-hdd                          9  128   89 MiB   89 MiB  233 KiB       73  268 MiB  267 MiB  699 KiB      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
openstack-store.rgw.buckets.data    10   32      0 B      0 B      0 B        0      0 B      0 B      0 B      0     10 TiB            N/A          N/A    N/A         0 B          0 B
.mgr                                11    1   25 MiB   25 MiB      0 B        8   75 MiB   75 MiB      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
vms-hdd                             12  256  151 MiB  151 MiB   12 KiB      349  454 MiB  454 MiB   35 KiB      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
backup-hdd                          13   32     19 B     19 B      0 B        1   12 KiB   12 KiB      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B
images-hdd                          14   32  1.0 GiB  1.0 GiB   11 KiB      167  3.1 GiB  3.1 GiB   32 KiB   0.02    5.2 TiB            N/A          N/A    N/A         0 B          0 B
other-hdd                           15   32     19 B     19 B      0 B        1   12 KiB   12 KiB      0 B      0    5.2 TiB            N/A          N/A    N/A         0 B          0 B

проверить занятость osd

ceph osd df

ceph osd df
Defaulted container "rook-ceph-tools" out of: rook-ceph-tools, cabundle-update (init)
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE  VAR   PGS  STATUS
 1    hdd  0.29109   1.00000  298 GiB  510 MiB   37 MiB   16 KiB  473 MiB  298 GiB  0.17  1.99   38      up
 3    hdd  3.63869   1.00000  3.6 TiB  2.0 GiB  1.3 GiB  125 KiB  769 MiB  3.6 TiB  0.05  0.64  449      up
 6    hdd  0.90970   1.00000  932 GiB  1.0 GiB  224 MiB   67 KiB  842 MiB  930 GiB  0.11  1.33  114      up
 0    hdd  3.63869   1.00000  3.6 TiB  2.5 GiB  759 MiB   92 KiB  1.7 GiB  3.6 TiB  0.07  0.79  278      up
 5    hdd  0.45479   1.00000  466 GiB  1.8 GiB  118 MiB   16 KiB  1.7 GiB  464 GiB  0.38  4.53   33      up
 7    hdd  3.63869   1.00000  3.6 TiB  2.4 GiB  669 MiB  287 KiB  1.8 GiB  3.6 TiB  0.06  0.77  290      up
 2    hdd  0.29109   1.00000  298 GiB  945 MiB  151 MiB    9 KiB  794 MiB  297 GiB  0.31  3.69   40      up
 4    hdd  3.63869   1.00000  3.6 TiB  3.1 GiB  1.4 GiB  375 KiB  1.7 GiB  3.6 TiB  0.08  0.98  561      up
                       TOTAL   17 TiB   14 GiB  4.5 GiB  991 KiB  9.7 GiB   16 TiB  0.08

получмить метадату по osd

ceph osd metadata 75

посмотреть данные авторизации для osd

ceph auth get osd.75

примонтировать диск цефа снаружи виртуалки (на хосте)

Запускать нужно с правами рута, например в контейнере с libvirt, предварительно скопировав туда файл с ключем /etc/ceph/ceph.client.nova.keyring который можно найти в nova-compute контейнере 

rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring device map --pool vms-ssd 6b566a66-ad46-495f-9e21-e8694f18ae74_disk --id nova

проверить фактически занятое место внутри цефа на вольюме

Запускать нужно с правами рута, например в контейнере с libvirt, предварительно скопировав туда файл с ключем /etc/ceph/ceph.client.nova.keyring который можно найти в nova-compute контейнере 

rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring disk-usage --pool vms-ssd  --id nova

(имя пула можно взять из ceph osd lspools) 

NAME                                       PROVISIONED  USED
6b566a66-ad46-495f-9e21-e8694f18ae74_disk        5 GiB  2.8 GiB
b354b7d0-e26d-4f60-9391-a490f7581634_disk        5 GiB  3.1 GiB
df339dd1-f119-4af1-a79e-bed00911f9dc_disk        5 GiB  3.2 GiB
<TOTAL>                                         15 GiB  9.2 GiB

получить список нод, где есть osd down и сами osd

ceph osd tree | awk '/host/ {host=$4} /down/ {print host, $0}'

kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 210   nvme    1.74629              osd.210                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 218   nvme    1.74629              osd.218                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 228   nvme    1.74629              osd.228                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 236   nvme    1.74629              osd.236                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 244   nvme    1.74629              osd.244                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 253   nvme    1.74629              osd.253                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 262   nvme    1.74629              osd.262                                            down         0  1.00000
kaas-node-46c8f4ab-39ec-44d8-ba43-d7b3eecccdec 271   nvme    1.74629              osd.271                                            down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8  72   nvme    1.74629              osd.72                                             down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8  81   nvme    1.74629              osd.81                                             down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8  90   nvme    1.74629              osd.90                                             down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8  99   nvme    1.74629              osd.99                                             down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8 108   nvme    1.74629              osd.108                                            down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8 117   nvme    1.74629              osd.117                                            down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8 126   nvme    1.74629              osd.126                                            down         0  1.00000
kaas-node-f419673f-726c-4804-9c71-5eece76403c8 135   nvme    1.74629              osd.135                                            down         0  1.00000

поставить/снять для всех осд на ноде флаг noout

ceph osd set-group noout kaas-node-820ad8bd-45bd-4c4b-8271-2b697987aa21

ceph osd unset-group noout kaas-node-820ad8bd-45bd-4c4b-8271-2b697987aa21

посмотреть метадату по номеру OSD

ceph osd metadata | jq '.[] | select(.id==22)'

или просто 

ceph osd metadata <ID>

kaascephcluster

найти диск /dev/sdX по его айди в kaascephcluster объекте зная его имя из вывода dmesg

быввет так что диск в kaascephcluster добавлен не по букве /dev/sdc а by-id и тогда сложно сопоставить вывалившийся диск по dmesg с kaascephcluster записями.
вот так можно сопоставить зная девайс и ноду: 

kubectl -n ceph-lcm-mirantis get miracephlog -o yaml

тут будет нечто: 

        kaas-node-12c448d3-ca7e-4817-9d25-fe21aa441d4c:

          osd.17:
            blockPartition: /dev/dm-3
            deviceByID: WDC_WD4003FZEX-0_WD-WMC5D0D9DMEY
            deviceByPath: /dev/disk/by-path/pci-0000:00:11.4-ata-3
            deviceClass: hdd
            deviceName: sdc
            in: true
            metaPartition: /dev/sdg3
            metadataDeviceByID: Samsung_SSD_850_S2RFNX0H512086E
            metadataDeviceByPath: /dev/disk/by-path/pci-0000:00:1f.2-ata-3
            metadataDeviceClass: ssd
            metadataDeviceName: sdg
            osdUUID: 6d26c9e4-35c1-43e1-822e-d5aef566b764
            up: true

замьютить варнинги в ceph чтоьбы он показал health-ok и можно было с ним работать(добавлять новые осд и другое)

ceph health mute OSD_NEARFULL 1h

ceph health mute POOL_NEARFULL 1h

поархивировать варнинги о крашнутых osd - раньше они были, сеф их зафиксировал, но сейчас они работают нормлаьно, однако ceph -s показывает ворнинг, решение ниже: 

ceph crash archive-all

Identify existing images on Ceph

from glance pod: 

rbd -n client.glance ls -p <pool-name>

Смотреть

  • from keystone-client pod:
  • openstack image list --all-projects

Compare the two lists, and either delete the VMs using the missing images to permanently
remove the image from Openstack, or copy the image to a new UUID for use later on.

to find osd id by device name

ceph-volume lvm list

===== osd.167 ======

  [block]       /dev/ceph-f6c4bf7d-ef19-4754-a785-48b499d3b37e/osd-block-941cefab-88b1-4b9e-bfa3-c66296b849dd

      block device              /dev/ceph-f6c4bf7d-ef19-4754-a785-48b499d3b37e/osd-block-941cefab-88b1-4b9e-bfa3-c66296b849dd
      block uuid                6fwQaP-21CC-UryE-hsU6-6da1-wnZF-nj1RHJ
      cephx lockbox secret
      cluster fsid              7c4a3669-c5a7-0990-f711-ac1664aeba94
      cluster name              ceph
      crush device class        None
      db device                 /dev/sdj4
      db uuid                   c1790fbd-d5ae-44af-9cf6-bfe0d1f9bf5f
      encrypted                 0
      osd fsid                  941cefab-88b1-4b9e-bfa3-c66296b849dd
      osd id                    167
      type                      block
      vdo                       0
      devices                   /dev/sdh

как найти на каком девайсе ранится osd

ceph device ls-by-daemon osd.525
DEVICE                             HOST:DEV                                                EXPECTED FAILURE
MZXLR15THALA-000H3_S6C3NA0T200611  kaas-node-8c7a4ad5-f966-43d1-9d3e-32bf79f46a69:nvme3n1

Replication Factor

Если нет места то можно уменьшить число реплик, вплоть до 1 (что может быть не безопасно)

  • min_size - минимальное число реплик (если меньше то пул не работает)
  • size - нормальное число реплик
 
ceph osd pool set vms-ssd  min_size 1

 
ceph osd pool set vms-ssd  size 1 --yes-i-really-mean-it

Что бы заткнуть алерт 

 
ceph health mute  POOL_NO_REDUNDANCY

RBD

Проверить что содержится в пуле

  • Получить списки пулов: ceph osd lspools
 
rbd ls -p vms-ssd

vms-ssd имя пула Пример вывода: 

rbd ls -p vms-ssd
091a31a7-678b-42ae-82b8-9d65efda489a_disk
09804666-7a79-415f-b932-a4de86c65449_disk
0b7ee907-b129-43d6-996a-6bd70cf106ec_disk
0dd34603-ae5e-4de6-9acb-dca4003bc72d_disk
0edb5d35-9bc2-485d-871a-17467cc96aa0_disk
13ed106d-1c67-44dd-8f3a-900f1af24b17_disk
1ed56b4b-7b33-4336-9e78-2d12d7290d18_disk
20051a53-5a8a-4092-be10-fcee67a0011f_disk

Информация о диске

Этот диск - загрузочный диск ВМ, не вольюм (в пуле vms-ssd) 

rbd info feec3eae-2108-4cb5-a1a5-52c50e66db22_disk -p vms-ssd

rbd image 'feec3eae-2108-4cb5-a1a5-52c50e66db22_disk':
  size 5 GiB in 1280 objects
  order 22 (4 MiB objects)
  snapshot_count: 0
  id: 3f423a6496dbfd
  block_name_prefix: rbd_data.3f423a6496dbfd
  format: 2
  features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
  op_features:
  flags:
  create_timestamp: Tue Jun 20 15:01:57 2023
  access_timestamp: Mon Jun 26 00:00:21 2023
  modify_timestamp: Tue Jun 27 12:55:36 2023

feec3eae-2108-4cb5-a1a5-52c50e66db22_disk - это ID инстанса (+ слово disk) , можно посмотреть информацию о сервере openstack server show feec3eae-2108-4cb5-a1a5-52c50e66db22

Использование дисков

Или из контейнера libvirt - с ключами и паролями, или без ключей с ноды ceph 

rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring disk-usage --pool vms-ssd  --id nova

NAME                                       PROVISIONED  USED
6b566a66-ad46-495f-9e21-e8694f18ae74_disk        5 GiB  2.8 GiB
b354b7d0-e26d-4f60-9391-a490f7581634_disk        5 GiB  3.1 GiB
df339dd1-f119-4af1-a79e-bed00911f9dc_disk        5 GiB  3.2 GiB
<TOTAL>                                         15 GiB  9.2 GiB

Удалить диск

rbd remove   feec3eae-2108-4cb5-a1a5-52c50e66db22_disk -p vms-ssd

Подмонтировать диск виртуальной машины (из контейнера libvirt) (например что бы сделать fsck или вытащить данные)

Команда выполняется на хосте, внутри libvirt контейнера Внутри контейнера - по-тому что там есть пароли и конфиги, их в целом можно вытащить оттуда и запустить команду где удобнее. 

 
rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring device map --pool vms-ssd 6b566a66-ad46-495f-9e21-e8694f18ae74_disk --id nova
/dev/rbd0
  • --keyring /etc/ceph/ceph.client.nova.keyring - файл с паролем
  • -c /etc/ceph/ceph.conf - файл с адреcами мониторов
  • --pool vms-ssd - имя пула (смотреть virsh dumpxml)
  • 6b566a66-ad46-495f-9e21-e8694f18ae74_disk - имя диска (смотреть virsh dumpxml)
  • --id nova - “идентификатор клиента” (я не знаю что это означает но без этого параметра не работает)

Просмотреть подмонтированные

root@r710:/# rbd showmapped
id  pool     namespace  image                                      snap  device
0   vms-ssd             f2dfe088-0516-45a3-a6ab-305868be9f79_disk  -     /dev/rbd0

Отключить подключенный диск

rbd device unmap /dev/rbd0

найти все диски для всех ВМок и подмонтировать их (запускать из либвирт контейнера)

for VM_NAME in $(virsh list  --all --name);
do
    echo $VM_NAME
    POOL_NAME=$(virsh dumpxml ${VM_NAME} | grep "protocol='rbd'" | awk '{print $3}' | awk -F "'" '{print $2}' | awk -F "/" '{ print $1 }')
    DISK_NAME=$(virsh dumpxml ${VM_NAME} | grep "protocol='rbd'" | awk '{print $3}' | awk -F "'" '{print $2}' | awk -F "/" '{ print $2 }')
    rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring device map --pool ${POOL_NAME} ${DISK_NAME} --id nova
done

#!/bin/bash

set -eu
set -o pipefail
set -x

virsh="docker exec -ti $(docker ps | grep libvirt | grep '/tmp/libvirt.sh' | awk '{print $1}') virsh"
rbd="docker exec -ti $(docker ps | grep libvirt | grep '/tmp/libvirt.sh' | awk '{print $1}') rbd"
for VM in $( $virsh list --all --name | grep "^instance" | dos2unix);
do
    echo "Instance=${VM}"
    DISK_AND_POOL=$( $virsh dumpxml ${VM} | grep "protocol='rbd'" | awk -F "'" '{print $4}')
    echo "Pool/Disk=${DISK_AND_POOL}"
    POOL=$(echo ${DISK_AND_POOL}| awk -F '/' '{ print $1}')
    echo "POOL=${POOL}"
    DISK=$(echo ${DISK_AND_POOL}| awk -F '/' '{ print $2}')
    echo "DISK=${DISK}"
    #
    DEV_NAME=$( $rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring device map --pool ${POOL} ${DISK} --id nova 2>&1 | dos2unix)
    echo "DEV_NAME=${DEV_NAME}"
    fsck.ext4 -f -y ${DEV_NAME}p1
    $rbd -c /etc/ceph/ceph.conf --keyring  /etc/ceph/ceph.client.nova.keyring device unmap ${DEV_NAME}
done

Mirantis-специфичное

Это куски документации переведенне и с комментариями (иногда)

Задать число реплик контроллеров

если нужно сэкономить ресурсы и пох на все 

EDITOR=mcedit mgtctl  -n mosk edit cluster  child-cluster

helmReleases:
- name: ceph-controller
  values:
    rookOperatorPlacement:
      nodeSelector:
        node-type: storage-node-my-own-label
    controllers:
      cephController:
        replicas: 1
      cephMaintenance:
        replicas: 1
      cephRequest:
        replicas: 1
      cephStatus:
        replicas: 1

Часть rookOperatorPlacement не относится к репликам


Задать фактор репликации по-умолчанию

Что бы после обновления он не откатился к дофолту, если был сменен руками установить size: 1 

 EDITOR=mcedit mgtctl -n mosk   edit kaascephclusters  ceph-child-cluster

apiVersion: kaas.mirantis.com/v1alpha1
kind: KaaSCephCluster
spec:
  cephClusterSpec:
    pools:
    - default: true
      deviceClass: ssd
      name: kubernetes
      replicated:
        size: 1
      role: kubernetes
    - default: false

Замена сломанного диска (OSD)

Посмотреть метаданные (откуда достать ноду и имя устройства) можно так: 

ceph osd metadata | jq '.'

[
  {
    "id": 0,
    "arch": "x86_64",
    "back_addr": "[v2:10.80.4.32:6804/3947867361,v1:10.80.4.32:6805/3947867361]",
    "back_iface": "",
    "bluefs": "1",
    "bluefs_dedicated_db": "0",
    "bluefs_dedicated_wal": "0",
    "bluefs_single_shared_device": "1",
    "bluestore_bdev_access_mode": "blk",
    "bluestore_bdev_block_size": "4096",
    "bluestore_bdev_dev_node": "/dev/dm-0",
    "bluestore_bdev_devices": "vdb",
    "bluestore_bdev_driver": "KernelDevice",
    "bluestore_bdev_optimal_io_size": "0",
    "bluestore_bdev_partition_path": "/dev/dm-0",
    "bluestore_bdev_rotational": "1",
    "bluestore_bdev_size": "375805444096",
    "bluestore_bdev_support_discard": "1",
    "bluestore_bdev_type": "hdd",
    "ceph_release": "quincy",
    "ceph_version": "ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable)",
    "ceph_version_short": "17.2.6",
    "ceph_version_when_created": "ceph version 16.2.11 (3cf40e2dca667f68c6ce3ff5cd94f01e711af894) pacific (stable)",
    "container_hostname": "storage-2",
    "container_image": "127.0.0.1:44301/mirantis/ceph:v17.2.6-cve-1",
    "cpu": "Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz",
    "created_at": "2023-05-31T11:47:32.773612Z",
    "default_device_class": "hdd",
    "device_ids": "",
    "device_paths": "vdb=/dev/disk/by-path/pci-0000:00:0c.1",
    "devices": "vdb",
    "distro": "centos",
    "distro_description": "CentOS Stream 9",
    "distro_version": "9",
    "front_addr": "[v2:10.80.5.32:6802/3946867361,v1:10.80.5.32:6803/3946867361]",
    "front_iface": "",
    "hb_back_addr": "[v2:10.80.4.32:6802/3946867361,v1:10.80.4.32:6803/3946867361]",
    "hb_front_addr": "[v2:10.80.5.32:6804/3946867361,v1:10.80.5.32:6805/3946867361]",
    "hostname": "storage-2",
    "journal_rotational": "1",
    "kernel_description": "#167-Ubuntu SMP Mon May 15 17:35:05 UTC 2023",
    "kernel_version": "5.4.0-150-generic",
    "mem_swap_kb": "0",
    "mem_total_kb": "16393460",
    "network_numa_unknown_ifaces": "back_iface,front_iface",
    "objectstore_numa_unknown_devices": "vdb",
    "os": "Linux",
    "osd_data": "/var/lib/ceph/osd/ceph-0",
    "osd_objectstore": "bluestore",
    "osdspec_affinity": "",
    "pod_name": "rook-ceph-osd-0-645c84b-4fb4b",
    "pod_namespace": "rook-ceph",
    "rotational": "1"
  },

Найти сломанные OSD 

ceph osd tree down

ID   CLASS  WEIGHT     TYPE NAME                                                STATUS  REWEIGHT  PRI-AFF
 -1         111.66374  root default
-23          18.52654      host kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4
 20    hdd    3.80629          osd.20                                             down         0  1.00000
 21    hdd    3.63799          osd.21                                             down         0  1.00000
 22    hdd    3.80629          osd.22                                             down         0  1.00000
 30    hdd    3.63799          osd.30                                             down         0  1.00000
 31    hdd    3.63799          osd.31                                             down         0  1.00000

Для того что бы найти ноды (хостнейм известен - kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 )
но это нужно как-то сопоставить с именем ноды в объекте kaascephcluster Это можно сделать через объект machine 

kubectl get ma -A -o wide | grep mos-ceph-osd004

eu-production-mos   mos-ceph-osd004   true    Ready      kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4   83             false

Тут сопоставление ноды kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4 и записи в объекте - mos-ceph-osd004
Например вывод для OSD 22 - тут видно ноду "hostname": "kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4"
но для того что бы удалить из кластера эту OSD нужно найти сопоставление с mos-ceph-osd004 

ceph osd metadata 22  

{
  "id": 22,
  "arch": "x86_64",
  "back_addr": "[v2:192.168.12.20:6805/322056793,v1:192.168.12.20:6808/322056793]",
  "back_iface": "",
  "bluefs": "1",
  "bluefs_db_access_mode": "blk",
  "bluefs_db_block_size": "4096",
  "bluefs_db_dev_node": "/dev/dm-2",
  "bluefs_db_devices": "sdg",
  "bluefs_db_driver": "KernelDevice",
  "bluefs_db_optimal_io_size": "0",
  "bluefs_db_partition_path": "/dev/dm-2",
  "bluefs_db_rotational": "0",
  "bluefs_db_size": "184318689280",
  "bluefs_db_support_discard": "1",
  "bluefs_db_type": "ssd",
  "bluefs_dedicated_db": "1",
  "bluefs_dedicated_wal": "0",
  "bluefs_single_shared_device": "0",
  "bluestore_bdev_access_mode": "blk",
  "bluestore_bdev_block_size": "4096",
  "bluestore_bdev_dev_node": "/dev/dm-1",
  "bluestore_bdev_devices": "sdh",
  "bluestore_bdev_driver": "KernelDevice",
  "bluestore_bdev_optimal_io_size": "0",
  "bluestore_bdev_partition_path": "/dev/dm-1",
  "bluestore_bdev_rotational": "1",
  "bluestore_bdev_size": "4000783007744",
  "bluestore_bdev_support_discard": "0",
  "bluestore_bdev_type": "hdd",
  "ceph_release": "quincy",
  "ceph_version": "ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable)",
  "ceph_version_short": "17.2.6",
  "ceph_version_when_created": "",
  "container_hostname": "kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4",
  "container_image": "127.0.0.1:44301/mirantis/ceph:v17.2.6-rel-5",
  "cpu": "Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz",
  "created_at": "",
  "default_device_class": "hdd",
  "device_ids": "sdg=WDC_WDS100T2B0A_200231440911,sdh=WDC_WD4001FAEX-0_WD-WCC131110366",
  "device_paths": "sdg=/dev/disk/by-path/pci-0000:00:1f.2-ata-3,sdh=/dev/disk/by-path/pci-0000:00:1f.2-ata-4",
  "devices": "sdg,sdh",
  "distro": "centos",
  "distro_description": "CentOS Stream 9",
  "distro_version": "9",
  "front_addr": "[v2:192.168.10.109:6808/322056793,v1:192.168.10.109:6809/322056793]",
  "front_iface": "",
  "hb_back_addr": "[v2:192.168.12.20:6809/322056793,v1:192.168.12.20:6810/322056793]",
  "hb_front_addr": "[v2:192.168.10.109:6810/322056793,v1:192.168.10.109:6811/322056793]",
  "hostname": "kaas-node-650411e5-eb92-4438-bb95-22aeb2bb79f4",
  "journal_rotational": "0",
  "kernel_description": "#167~18.04.1-Ubuntu SMP Wed May 24 00:51:42 UTC 2023",
  "kernel_version": "5.4.0-150-generic",
  "mem_swap_kb": "0",
  "mem_total_kb": "65746728",
  "network_numa_unknown_ifaces": "back_iface,front_iface",
  "objectstore_numa_unknown_devices": "sdg,sdh",
  "os": "Linux",
  "osd_data": "/var/lib/ceph/osd/ceph-22",
  "osd_objectstore": "bluestore",
  "osdspec_affinity": "",
  "pod_name": "rook-ceph-osd-22-68f7c8cd88-gm6cv",
  "pod_namespace": "rook-ceph",
  "rotational": "1"
}

Что из этого можно понять

  • bluefs_db_devices": "sdg" - это устройство с метадатой
  • bluefs_db_dev_node": "/dev/dm-2 - это блочное устройство, тут нельзя указать партицию по-тому используется LVM
  • bluestore_bdev_devices": "sdh", - устройство с данными

https://docs.mirantis.com/container-cloud/latest/operations-guide/operate-managed/operate-managed-bm/manage-ceph/ceph-lcm/replace-failed-node.html
dropFromClusterOnly - если не очищается поломанный диск фулл мапинг можно посмотреть на чайлде вот так: kubectl -n ceph-lcm-mirantis get miracephlog -o yaml При удалении OSD при удалении всех (если упали все OSD на ноде) нужно удалять ВМЕСТЕ С НОДОЙ

By-ID или /dev/sdX ? (miracephlog)

Бывыет так что диск в kaascephcluster добавлен не по букве /dev/sdX а например /dev/disk/by-id/WDC_WD4003FZEX-0_WD-WMC5D0D9DMEY и тогда сложно сопоставить вывалившийся диск по dmesg с kaascephcluster . вот так моджно сопоставить зная девайс и ноду: 

kubectl -n ceph-lcm-mirantis get miracephlog -o yaml

тут будет нечто: 

        kaas-node-12c448d3-ca7e-4817-9d25-fe21aa441d4c:
...
          osd.17:
            blockPartition: /dev/dm-3
            deviceByID: WDC_WD4003FZEX-0_WD-WMC5D0D9DMEY
            deviceByPath: /dev/disk/by-path/pci-0000:00:11.4-ata-3
            deviceClass: hdd
            deviceName: sdc
            in: true
            metaPartition: /dev/sdg3
            metadataDeviceByID: Samsung_SSD_850_S2RFNX0H512086E
            metadataDeviceByPath: /dev/disk/by-path/pci-0000:00:1f.2-ata-3
            metadataDeviceClass: ssd
            metadataDeviceName: sdg
            osdUUID: 6d26c9e4-35c1-43e1-822e-d5aef566b764
            up: true
...

Очистка алерта от недавно скрашевшихся OSDs

поархивировать варнинги о крашнутых osd - раньше они были, сеф их зафиксировал, но сейчас они работают нормально,
однако ceph -s показывает ворнинг, решение ниже: 

 
ceph crash archive-all

Блокировки в CEPH

В rbd есть понятие блокировки - и список блокировок можно посмотреть командой: 

rbd -p volumes-ssd lock list 66b35cdf-845e-47a4-badd-c03e1902fb44

There is 1 exclusive lock on this image.
Locker           ID                    Address
client.53989246  auto 140537302618384  10.80.3.54:0/2974634118
  • volumes-ssd - это имя пула
  • 66b35cdf-845e-47a4-badd-c03e1902fb44 - это ID который можно посмотреть в openstack server show
  • 10.80.3.54 - это адрес compute

При этом иногда при краше компьюты локи остаются и новая компьюта после миграции ВМ не может подключить диск Пример ошибки (хотя это не единственный вариант ошибки): 

 
{'code': 500, 'created': '2024-02-15T17:32:25Z', 'message': 'ReadOnlyImage', 'details': 'Traceback (most recent call last):\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 207, in decorated_function\n
return function(self, context, *args, **kwargs)\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 5981, in finish_resize\n
self._delete_allocation_after_move(\n File "/var/lib/openstack/lib/python3.8/site-packages/oslo_utils/excutils.py", line 220, in __exit__\n
self.force_reraise()\n File "/var/lib/openstack/lib/python3.8/site-packages/oslo_utils/excutils.py", line 196, in force_reraise\n
six.reraise(self.type_, self.value, self.tb)\n File "/var/lib/openstack/lib/python3.8/site-packages/six.py", line 703, in reraise\n
raise value\n File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 5963, in finish_resize\n
self._finish_resize_helper(context, disk_info, image, instance,\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 5996, in _finish_resize_helper\n
network_info = self._finish_resize(context, instance, migration,\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 5884, in _finish_resize\n
self._set_instance_info(instance, old_flavor)\n
File "/var/lib/openstack/lib/python3.8/site-packages/oslo_utils/excutils.py", line 220, in __exit__\n
self.force_reraise()\n File "/var/lib/openstack/lib/python3.8/site-packages/oslo_utils/excutils.py", line 196, in force_reraise\n
six.reraise(self.type_, self.value, self.tb)\n
File "/var/lib/openstack/lib/python3.8/site-packages/six.py", line 703, in reraise\n
raise value\n File "/var/lib/openstack/lib/python3.8/site-packages/nova/compute/manager.py", line 5867, in _finish_resize\n
self.driver.finish_migration(context, migration, instance,\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",line 10629, in finish_migration\n
self._create_image(context, instance, block_disk_info[\'mapping\'],\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/virt/libvirt/driver.py", line 4200, in _create_image\n
created_disks = self._create_and_inject_local_root(\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/virt/libvirt/driver.py", line 4298, in _create_and_inject_local_root\n
backend.create_snap(libvirt_utils.RESIZE_SNAPSHOT_NAME)\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/virt/libvirt/imagebackend.py", line 1122, in create_snap\n
return self.driver.create_snap(self.rbd_name, name)\n
File "/var/lib/openstack/lib/python3.8/site-packages/nova/storage/rbd_utils.py", line 443, in create_snap\n
vol.create_snap(name)\n
File "/var/lib/openstack/lib/python3.8/site-packages/eventlet/tpool.py", line 190, in doit\n
result = proxy_call(self._autowrap, f, *args, **kwargs)\n
File "/var/lib/openstack/lib/python3.8/site-packages/eventlet/tpool.py", line 148, in proxy_call\n
rv = execute(f, *args, **kwargs)\n
File "/var/lib/openstack/lib/python3.8/site-packages/eventlet/tpool.py", line 129, in execute\n
six.reraise(c, e, tb)\n
File "/var/lib/openstack/lib/python3.8/site-packages/six.py", line 703, in reraise\n
raise value\n
File "/var/lib/openstack/lib/python3.8/site-packages/eventlet/tpool.py", line 83, in tworker\n
rv = meth(*args, **kwargs)\n File "rbd.pyx", line 2770, in rbd.requires_not_closed.wrapper\n
File "rbd.pyx", line 3514, in rbd.Image.create_snap\n
rbd.ReadOnlyImage: [errno 30] RBD read-only image (error creating snapshot b\'nova-resize\' from b\'2786c568-5fda-496d-a267-551e2ce3acc5_disk\')\n'}

Например (с лабы): 

rbd -p volumes-nvme lock list e0fa47b1-6831-40fa-b626-f4eea84940c2

There is 1 exclusive lock on this image.
Locker           ID                    Address
client.46717700  auto 139629252590528  10.187.84.142:0/3063592878

Посмотреть кто использует диск можно так: Пример кастомера: 

rbd status volumes-nvme/e0fa47b1-6831-40fa-b626-f4eea84940c2

Watchers:
        watcher=10.187.84.142:0/3063592878 client.46717700 cookie=139629252590528
        watcher=10.187.84.171:0/2753880368 client.402631226 cookie=140045730189824

пример с лабы 

rbd status volumes-ssd/66b35cdf-845e-47a4-badd-c03e1902fb44

Watchers:
  watcher=10.80.3.54:0/2974634118 client.53989246 cookie=140537302618384

Тут у кастомера 2 ноды - старая (мертвая), с которой ВМ перенесли на новую
В случае лабы только одна актуальная компьют-нода
У кастомера - проверяем что нода (10.187.84.142) не работает : 

kubectl -n openstack get nodes -o wide |grep kaas-node-a0d08ca9-14eb-42dd-9908-9ecde7cb9d7c
kaas-node-a0d08ca9-14eb-42dd-9908-9ecde7cb9d7c   NotReady   <none>   566d   v1.24.6-mirantis-1   10.187.84.142   <none>        Ubuntu 20.04.6 LTS   5.4.0-109-generic

И можно удалить (заблокировать) watcher 10.187.84.142:0/3063592878 

ceph osd blacklist add 10.187.84.142:0/3063592878                                                                                               │
blocklisting 10.187.84.142:0/3063592878 until 2024-02-01T11:12:42.942069+0000 (3600 sec)
  • 10.187.84.142:0/3063592878 - адрес и идентификатор который нужно заблокировать
  • блокировка временная
  • После чего диск может использовать новая компьюта
rbd -p volumes-nvme lock list e0fa47b1-6831-40fa-b626-f4eea84940c2
There is 1 exclusive lock on this image.
Locker            ID                    Address
client.402631226  auto 140045730189824  10.187.84.171:0/2753880368

Или можно удалить сразу lock (пример не с лабы, по-том такие странные пулы) 

rbd lock remove --pool c7000-pxmx1-am7 vm-201-disk-0 "auto 140450841490944" client.70464

"Неудаляемый" image в glance

Столкнулся с проблемой - невозможно удалить образ: 

openstack image delete Ubuntu-22.04-root-password-set

Failed to delete image with name or ID 'Ubuntu-22.04-root-password-set': HttpException: 500: Server Error for url: https://glance.it.just.works/v2/images/f9b77787-49f0-45cc-9758-11319ae47de8, The server has either erred or is incapable of performing the requested operation.: 500 Internal Server Error
Failed to delete 1 of 1 images.

Коротко - проблема в том, что образ был создан из запущенной ВМи - и под капотом там используются снапшоты, когда из этого образа были созданы еще ВМки

Тем не менее сообщения в логах не информативны: 

2024-02-05 08:40:28.847 12 WARNING glance.api.v2.images [req-4c9facef-a616-4040-b584-02bd43f0878c 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] After upload to backend, deletion of staged image data has failed because it cannot be found at /tmp/staging//f9b77787-49f0-45cc-9758-11319ae47de8
2024-02-05 08:40:29.101 12 ERROR glance.common.wsgi [req-4c9facef-a616-4040-b584-02bd43f0878c 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] Caught error: [errno 1] RBD permission error (error listing children.): rbd.PermissionError: [errno 1] RBD permission error (error listing children.)

Для того что бы (для начала) получить более информативное сообщение нужно дать для glance дополнительные права - в терминах МОСК это делается через kaascephcluster: 

kubectl -n mosk get kaascephcluster ceph-child-cluster -o yaml | yq .spec.cephClusterSpec.clients

- caps:
    mon: allow r
    osd: allow class-read object_prefix rbd_children, allow rwx pool=images-ssd, allow rx pool=volumes-ssd, allow rwx pool=vms-ssd
  name: glance
- caps:
    mds: allow rw
    mgr: allow rw
    mon: allow r
  name: cephfs-client

тут была добавлена секция для glance
После этого удалить образ все так же нельзя, но есть более-менее информативное сообщение для поиска проблемы: 

2024-02-05 10:05:30.400 11 WARNING glance_store._drivers.rbd [req-585db1f1-76a7-478b-adce-adb2dfaa78a3 71add96277134f4a97127acc2431cddc fd65e819389849d0b8b50ff5b157b429 - default default] Snap Operating Exception RBD image is busy (Image snapshot has external references.) Snapshot is in use.: rbd.ImageBusy: RBD image is busy (Image snapshot has external references.)

Далее можно посмотреть зависимые образы: 

rbd children images-ssd/f9b77787-49f0-45cc-9758-11319ae47de8

vms-ssd/35ed30a8-5e64-4b69-a146-3264496ad6e6_disk
vms-ssd/bb679dfb-44b6-4e10-b4c5-afb0715176b3_disk
vms-ssd/dc369981-978d-4fa5-801b-e202ba101d19_disk

Тут видно что это диски виртуалок, это видно из имени пула vms-ssd , и ID виртуалок тоже известны - можно удалять ВМки и освобождать блокировку После удаления виртуалок, можно убедиться что зависимостей не осталось 

rbd children images-ssd/f9b77787-49f0-45cc-9758-11319ae47de8

Финальный шаг - удаление “проблемного” образа 

openstack image delete f9b77787-49f0-45cc-9758-11319ae47de8

Additional Information

После создания OSD Ceph запустит операцию восстановления и начнет перемещать группы размещения из вторичных OSD в новый OSD.
Опять же, операция восстановления займет некоторое время в зависимости от размера вашего кластера, после ее завершения ваш кластер Ceph будет HEALTH_OK.
Когда новый хост или диск добавляется в кластер Ceph, CRUSH запускает операцию перебалансировки, в рамках которой он перемещает данные с существующих хостов/дисков на новый хост/диск.
Перебалансировка выполняется для того, чтобы все диски использовались одинаково, что повышает производительность кластера и поддерживает его работоспособность.

Источник — https://noname.com.ua/mediawiki/index.php?title=Ceph2&oldid=15111