Ceph2

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

показать дерево 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: 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 запускает операцию перебалансировки, в рамках которой он перемещает данные с существующих хостов/дисков на новый хост/диск.
Перебалансировка выполняется для того, чтобы все диски использовались одинаково, что повышает производительность кластера и поддерживает его работоспособность.