Ceph2: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
| Строка 75: | Строка 75: | ||
</PRE> |
</PRE> |
||
| − | + | =проверить использование стореджа пулами= |
|
<PRE> |
<PRE> |
||
ceph df |
ceph df |
||
Версия 16:34, 19 сентября 2025
Ceph2
Сборник рецептов по ceph
Удаление OSD из кластера
123- номер OSD на удалениеnode-2- хостнейм ноды на котрой этот OSDsdd- блочное устройство
Пометить 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
показать дерево 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>
1
найти диск /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. If you'd like, we can schedule a webex to assist with this action.
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
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
Если нет места то можно уменьшить число реплик, вплоть до 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
exit 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) Посмотреть метаданные (откуда достать ноду и имя устройства) можно так: root@nest:~# 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: mgtctl -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 запускает операцию перебалансировки, в рамках которой он перемещает данные с существующих хостов/дисков на новый хост/диск.
Перебалансировка выполняется для того, чтобы все диски использовались одинаково, что повышает производительность кластера и поддерживает его работоспособность.
