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 Defaulted container "rook-ceph-tools" out of: rook-ceph-tools, cabundle-update (init) --- 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

Additional Information

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