Ceph2

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску

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 контейнера - потому что в этом контейнере есть ключи и конфиг цефа (их можно вытащить наружу и примонтировать прямо на хосте) 

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

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

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

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

[rook@rook-ceph-tools-6bdcfd7c4b-rjbzk /]$ 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

  1. ceph osd set-group noout kaas-node-820ad8bd-45bd-4c4b-8271-2b697987aa21
  1. 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

  1. from glance pod:
  2. rbd -n client.glance ls -p <pool-name>
  1. from keystone-client pod:
  2. 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 Проверить что содержится в пуле 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

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

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