При работе с распределенными хранилищами на базе Ceph иногда возникает необходимость временно или окончательно исключить узел из кластера. Это может понадобиться при обновлении оборудования, обслуживании инфраструктуры или перераспределении ресурсов. Вместе с тем если узел, подлежащий выводу, одновременно исполняет роли MON (Monitor), MGR (Manager Daemon) и MDS (Metadata Server), задача превращается в настоящий квест hard-уровня. Но при должном подходе и с такими кейсами можно справиться.
Меня зовут Алексей Косов. Я старший инженер доступности отдела интеграции и сопровождения облачных решений в команде VK Tech. СХД Ceph — это часть поставки нашего продукта для построения частного облака в ЦОДе заказчика VK Private Cloud. В этой статье я пошагово покажу, как можно вывести узел с полным комплектом сервисов Ceph из кластера, чтобы кластер и остальные узлы не пострадали.
Почему может требоваться вывод узла из Ceph-кластера и какие риски существуют
Существует несколько распространенных ситуаций, когда возникает необходимость вывести узел из кластера Ceph. Выделим некоторые.
Аппаратное обслуживание. Необходимость замены неисправных комплектующих, модернизации оборудования или планового технического обслуживания.
Балансировка нагрузки. Необходимость перераспределения данных и нагрузки (например, при расширении кластера путем добавления новых серверов или при выводе старых узлов с малым объемом хранилища).
Тестирование и отладка. Исследование поведения кластера в стресс-тестах или тестирование новых версий ПО на отдельном узле.
Экономия затрат. Необходимость сокращения количества используемых серверов при сохранении требуемого уровня производительности.
При этом процесс вывода узла из кластера должен происходить аккуратно и контролируемо, поскольку грубые действия могут привести к ряду проблем, среди которых:
потеря доступности данных;
отказ клиентских операций;
перегрузка оставшихся OSD из-за массового ребалансинга;
падение производительности при недостаточном резерве емкости;
ухудшение производительности системы;
риск потери данных, если узел или диск будет удален до завершения rebalancing/recovery;
длительное время восстановления — вывод узла с большим количеством данных может занять много часов или даже дней. В течение всего этого времени кластер остается под повышенной нагрузкой и подвержен рискам, указанным выше.
Вместе с тем, вывод из кластера — посильная задача. Причем при должном подходе и учете ряда факторов безопасно вывести из Ceph-кластера можно даже узел, который решает множество задач. Например, на котором развернуты роли MON (Monitor), MGR (Manager Daemon), MDS (Metadata Server) и OSD. И он одновременно является Active MON, Active MGR и Active MDS. Алгоритм решения подобного кейса я и разберу: в рамках статьи покажу, как вывести из Ceph-кластера узел csn004 с двумя OSD (Object Storage Device) и с полным комплектом сервисов Ceph, при этом Ceph развернут с томами LVM (Logical Volume Manager) для OSD.
Что ж, приступим.
Примечание: Инструкция актуальна для любого кластера Ceph, где используются тома LVM. В рамках статьи все действия выполняются на RedOS 7.3, версия Ceph 17.2.7.
Определяем исходное состояние кластера
Для начала посмотрим статус кластера:
[centos@csn001 ~]$ ceph -s
cluster:
id: 99199b58-63b4-41c3-a51a-263aa9fced25
health: HEALTH_OK
services:
mon: 4 daemons, quorum csn001,csn002,csn003,csn004 (age 2d)
mgr: csn004(active, since 24h), standbys: csn002, csn003, csn001
mds: 1/1 daemons up, 3 standby
osd: 8 osds: 8 up (since 2d), 8 in (since 3d)
data:
volumes: 1/1 healthy
pools: 6 pools, 177 pgs
objects: 29.53k objects, 227 GiB
usage: 684 GiB used, 2.1 TiB / 2.7 TiB avail
pgs: 177 active+clean
io:
client: 12 KiB/s wr, 0 op/s rd, 1 op/s wrКластер находится в статусе HEALTH_OK.
Также видим в списке services, что:
все 4 монитора (mon) находятся в кворуме;
активный менеджер (mgr) находится на csn004.
Имея эту информацию, может начинать подготовку узла к выводу из кластера.
Перенос активных ролей с выводимого узла
Начнем подготовку с удаления мониторов (MON).
Удаление мониторов (MON)
В первую очередь проверяем кворум кластера.
[centos@csn001 ~]$ sudo ceph quorum_status --format json-pretty
{
"election_epoch": 140,
"quorum": [
0,
1,
2,
3
],
"quorum_names": [
"csn001",
"csn002",
"csn003",
"csn004"
],
"quorum_leader_name": "csn001",
"quorum_age": 174189,
"features": {
"quorum_con": "4540138320759226367",
"quorum_mon": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus",
"pacific",
"elector-pinging",
"quincy"
]
},
"monmap": {
"epoch": 4,
"fsid": "99199b58-63b4-41c3-a51a-263aa9fced25",
"modified": "2025-10-02T21:06:48.702324Z",
"created": "2025-09-26T17:59:19.080624Z",
"min_mon_release": 17,
"min_mon_release_name": "quincy",
"election_strategy": 1,
"disallowed_leaders: ": "",
"stretch_mode": false,
"tiebreaker_mon": "",
"removed_ranks: ": "",
"features": {
"persistent": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus",
"pacific",
"elector-pinging",
"quincy"
],
"optional": []
},
"mons": [
{
"rank": 0,
"name": "csn001",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.20:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.20:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.20:6789/0",
"public_addr": "10.30.10.20:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
},
{
"rank": 1,
"name": "csn002",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.14:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.14:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.14:6789/0",
"public_addr": "10.30.10.14:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
},
{
"rank": 2,
"name": "csn003",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.15:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.15:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.15:6789/0",
"public_addr": "10.30.10.15:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
},
{
"rank": 3,
"name": "csn004",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.17:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.17:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.17:6789/0",
"public_addr": "10.30.10.17:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
}
]
}
}Убеждаемся, что все мониторы находятся в кворуме.
Далее удаляем MON с узла csn004 из monmap.
[centos@csn001 ~]$ sudo ceph mon remove csn004
# Смотрим статус кластера после удаления монитора csn004
[centos@csn001 ~]$ ceph -s
cluster:
id: 99199b58-63b4-41c3-a51a-263aa9fced25
health: HEALTH_OK
services:
mon: 3 daemons, quorum csn001,csn002,csn003 (age 27s)
mgr: csn004(active, since 24h), standbys: csn002, csn003, csn001
mds: 1/1 daemons up, 3 standby
osd: 8 osds: 8 up (since 2d), 8 in (since 3d)
data:
volumes: 1/1 healthy
pools: 6 pools, 177 pgs
objects: 29.53k objects, 227 GiB
usage: 684 GiB used, 2.1 TiB / 2.7 TiB avail
pgs: 177 active+cleanCeph пересчитает кворум кластера и изменит его состав.
После этого можно снова проверить кворум:
[centos@csn001 ~]$ sudo ceph quorum_status --format json-pretty
{
"election_epoch": 146,
"quorum": [
0,
1,
2
],
"quorum_names": [
"csn001",
"csn002",
"csn003"
],
"quorum_leader_name": "csn001",
"quorum_age": 72,
"features": {
"quorum_con": "4540138320759226367",
"quorum_mon": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus",
"pacific",
"elector-pinging",
"quincy"
]
},
"monmap": {
"epoch": 5,
"fsid": "99199b58-63b4-41c3-a51a-263aa9fced25",
"modified": "2025-10-06T14:29:49.013963Z",
"created": "2025-09-26T17:59:19.080624Z",
"min_mon_release": 17,
"min_mon_release_name": "quincy",
"election_strategy": 1,
"disallowed_leaders: ": "",
"stretch_mode": false,
"tiebreaker_mon": "",
"removed_ranks: ": "3",
"features": {
"persistent": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus",
"pacific",
"elector-pinging",
"quincy"
],
"optional": []
},
"mons": [
{
"rank": 0,
"name": "csn001",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.20:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.20:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.20:6789/0",
"public_addr": "10.30.10.20:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
},
{
"rank": 1,
"name": "csn002",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.14:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.14:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.14:6789/0",
"public_addr": "10.30.10.14:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
},
{
"rank": 2,
"name": "csn003",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "10.30.10.15:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "10.30.10.15:6789",
"nonce": 0
}
]
},
"addr": "10.30.10.15:6789/0",
"public_addr": "10.30.10.15:6789/0",
"priority": 0,
"weight": 0,
"crush_location": "{}"
}
]
}
}Перенос MGR
Теперь переходим к переносу MGR.
Для начала проверяем список менеджеров:
Убеждаемся, что в кластере есть менеджеры в статусе Standby на других узлах.
Следующим шагом принудительно переводим статус Active с узла csn004:
[centos@csn001 ~]$ sudo ceph mgr fail csn004Примечательно, что это не деструктивная операция — Ceph просто делает другой узел активным менеджером, а csn004 остается Standby.
После этого проверяем, что новый Active MGR выбран:
[centos@csn001 ~]$ sudo ceph mgr dump | jq '{active_name, standbys: [.standbys[].name]}'
{
"active_name": "csn002",
"standbys": [
"csn003",
"csn001",
"csn004"
]
}Перенос MDS (CephFS)
На следующем этапе мы можем перенести MDS — сервер метаданных (metadata server), который нужен только для CephFS и занимается хранением и обслуживанием файловых метаданных (имена, каталоги, права и блокировки), а сами данные файлов хранятся в OSD.
Примечание: MDS не нужны, если кластер Ceph используется только как блочное хранилище (Ceph RBD) или объектное хранилище (Ceph RGW). Но в данном примере мы рассмотрим также вывод из кластера узла с MDS.
Для начала проверяем состояние CephFS:
[centos@csn001 ~]$ sudo ceph fs status
cephfs - 2 clients
======
RANK STATE MDS ACTIVITY DNS INOS DIRS CAPS
0 active csn004 Reqs: 0 /s 10 13 12 2
POOL TYPE USED AVAIL
cephfs_metadata metadata 96.0k 582G
cephfs_data data 0 582G
STANDBY MDS
csn002
csn003
csn001
MDS version: ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy (stable)Если Active MDS = csn004 — необходимо убедиться, что в кластере есть другие MDS в статусе standby (например, csn001, csn002).
Далее переводим Active MDS с csn004:
[centos@csn001 ~]$ sudo ceph mds fail csn004
failed mds gid 614251Это тоже не деструктивная операция — как и в случае с MGR, кластер просто переключит Active MDS на другой узел.
Проверяем результат:
[centos@csn001 ~]$ sudo ceph fs status
cephfs - 0 clients
======
RANK STATE MDS ACTIVITY DNS INOS DIRS CAPS
0 active csn001 Reqs: 0 /s 10 13 12 0
POOL TYPE USED AVAIL
cephfs_metadata metadata 96.0k 582G
cephfs_data data 0 582G
STANDBY MDS
csn002
csn003
csn004
MDS version: ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy (stable)Active MDS должен быть выбран на другом узле.
Очистка ролей MON/MGR/MDS на узле csn004
Очистку ролей на узле начинаем с остановки и отключения сервисов MON/MGR/MDS:
[centos@csn004 ~]$ sudo systemctl disable --now ceph-mon@csn004.service
[centos@csn004 ~]$ sudo systemctl disable --now ceph-mgr@csn004.service
[centos@csn004 ~]$ sudo systemctl disable --now ceph-mds@csn004.service
[centos@csn004 ~]$ sudo systemctl stop ceph-mon@csn004.service
[centos@csn004 ~]$ sudo systemctl stop ceph-mgr@csn004.service
[centos@csn004 ~]$ sudo systemctl stop ceph-mds@csn004.serviceЗатем останавливаем и отключаем .target-сервисы MON/MGR/MDS — это нужно, чтобы исключить повторный запуск ранее отключенных сервисов ceph на узле csn004:
[centos@csn004 ~]$ sudo systemctl disable --now ceph-mon.target
[centos@csn004 ~]$ sudo systemctl disable --now ceph-mgr.target
[centos@csn004 ~]$ sudo systemctl disable --now ceph-mds.target
[centos@csn004 ~]$ sudo systemctl stop ceph-mon.target
[centos@csn004 ~]$ sudo systemctl stop ceph-mgr.target
[centos@csn004 ~]$ sudo systemctl stop ceph-mds.targetУдаляем каталоги с данными о MON/MGR/MDS c узла csn 004:
[centos@csn004 ~]$ sudo rm -rf /var/lib/ceph/mon/ceph-csn004
[centos@csn004 ~]$ sudo rm -rf /var/lib/ceph/mgr/ceph-csn004
[centos@csn004 ~]$ sudo rm -rf /var/lib/ceph/mds/ceph-csn004На этом перенос активных ролей с выводимого узла можно считать завершенным. Переходим к следующему этапу.
Удаление OSD с узла csn004
В данном примере мы будем удалять из кластера OSD с ID 6 и 7 на узле csn004, которые являются томами LVM на диске /dev/sdb.
Предупреждение: убедитесь, что вы выполняете команды только для нужных OSD и на нужном узле кластера. Внимательно проверяйте все команды перед выполнением.
[centos@csn004 ~]$ lsblk
NAME
MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda
8:0 0 50G 0 disk
├─sda1
8:1 0 2G 0 part /boot
└─sda2
8:2 0 48G 0 part /
sdb
8:16 0 700G 0 disk
├─sdb1
8:17 0 300M 0 part /var/lib/ceph/osd/ceph-6
├─sdb2
8:18 0 349.7G 0 part
│ └─ceph--99199b58--63b4--41c3--a51a--263aa9fced25--d96565a0-d225dd3a--874c--5a18--9ed8--7a9749bcd9fd 253:0 0 349.7G 0 lvm
├─sdb3
8:19 0 300M 0 part /var/lib/ceph/osd/ceph-7
└─sdb4
8:20 0 349.7G 0 part
└─ceph--99199b58--63b4--41c3--a51a--263aa9fced25--d96565a0-3a68ae7b--2b2c--5145--a944--8aabe8977579 253:1 0 349.7G 0 lvm После этого выполняем reweight для удаляемых OSD, чтобы данные с них смигрировали на другие OSD:
[centos@csn001 ~]$ for i in {6..7}; do ceph osd crush reweight osd.${i} 0; done
reweighted item id 6 name 'osd.6' to 0 in crush map
reweighted item id 7 name 'osd.7' to 0 in crush mapДалее нужно дождаться, пока удаляемые OSD освободятся и статус кластера вернется в HEALTH_OK.
Для наблюдения в реальном времени можно запустить команду:
watch ceph -s
[centos@csn001 ~]$ ceph -s
cluster:
id: 99199b58-63b4-41c3-a51a-263aa9fced25
health: HEALTH_WARN
Degraded data redundancy: 7466/88599 objects degraded (8.427%), 54 pgs degraded, 24 pgs undersized
services:
mon: 3 daemons, quorum csn001,csn002,csn003 (age 2d)
mgr: csn002(active, since 2d), standbys: csn003, csn001
mds: 1/1 daemons up, 2 standby
osd: 8 osds: 8 up (since 4d), 8 in (since 6d); 43 remapped pgs
data:
volumes: 1/1 healthy
pools: 6 pools, 177 pgs
objects: 29.53k objects, 227 GiB
usage: 695 GiB used, 2.1 TiB / 2.7 TiB avail
pgs: 7466/88599 objects degraded (8.427%)
17569/88599 objects misplaced (19.830%)
103 active+clean
30 active+recovery_wait+degraded
23 active+recovery_wait+undersized+degraded+remapped
19 active+remapped+backfill_wait
1 active+recovering+undersized+degraded+remapped
1 active+recovery_wait
io:
client: 49 KiB/s rd, 57 op/s rd, 0 op/s wr
recovery: 78 MiB/s, 9 objects/sПосле завершения ребаланса кластера помечаем OSD как выведенные из кластера:
[centos@csn001 ~]$ for i in {6..7}; do ceph osd out ${i}; done
marked out osd.6.
marked out osd.7.Следом проверяем, можно ли безопасно удалить OSD из кластера:
echo "Ждем, когда OSD будут освобождены от данных"
for i in {6..7}; do
while ! ceph osd safe-to-destroy osd.${i} ; do
sleep 10
echo "We are waiting for the osd ${i} to be cleared of data"
done
doneПосле того как Ceph полностью смигрирует данные с удаляемых OSD, будет выведено сообщение:
OSD(s) 6 are safe to destroy without reducing data durability.
OSD(s) 7 are safe to destroy without reducing data durability.Теперь можно удалять OSD.
Для этого последовательно выполняем несколько операций.
Отключаем сервисы OSD на узле csn004:
[centos@csn004 ~]$ sudo systemctl disable --now ceph-osd@6.service
Removed /etc/systemd/system/ceph-osd.target.wants/ceph-osd@6.service.
[centos@csn004 ~]$ sudo systemctl disable --now ceph-osd@7.service
Removed /etc/systemd/system/ceph-osd.target.wants/ceph-osd@7.service.На одном из оставшихся узлов Ceph удаляем OSD из кластера:
[centos@csn001 ~]$ ceph osd purge 6 --yes-i-really-mean-it
purged osd.6
[centos@csn001 ~]$ ceph osd purge 7 --yes-i-really-mean-it
purged osd.7Предупреждение: команды, описанные ниже, деструктивны — они безвозвратно стирают данные и LVM-метаданные на выбранных дисках.Трижды проверьте, на каком узле вы находитесь и какие именно диски (OSD) очищаете. Ошибка приведет к безвозвратной потере данных и нестабильности кластера Ceph.
Проверяем список блочных устройств на узле csn004 (в данном примере один диск /dev/sdb разделен на 2 OSD, osd-6 и osd-7, которые представлены LVM-томами):
[centos@csn004 ~]$ sudo lsblk
NAME
MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda
8:0 0 50G 0 disk
├─sda1
8:1 0 2G 0 part /boot
└─sda2 8:2 0 48G 0 part /
sdb
8:16 0 700G 0 disk
├─sdb1
8:17 0 300M 0 part /var/lib/ceph/osd/ceph-6
├─sdb2
8:18 0 349.7G 0 part
│ └─ceph--99199b58--63b4--41c3--a51a--263aa9fced25--d96565a0-d225dd3a--874c--5a18--9ed8--7a9749bcd9fd 253:0 0 349.7G 0 lvm
├─sdb3
8:19 0 300M 0 part /var/lib/ceph/osd/ceph-7
└─sdb4
8:20 0 349.7G 0 part
└─ceph--99199b58--63b4--41c3--a51a--263aa9fced25--d96565a0-3a68ae7b--2b2c--5145--a944--8aabe8977579 253:1 0 349.7G 0 lvm Удаляем строки с точками монтирования /var/lib/ceph/osd/ceph-6 и /var/lib/ceph/osd/ceph-7 из /etc/fstab:
/etc/fstab
#
# /etc/fstab
# Created by anaconda on Mon Jun 30 16:59:50 2025
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=9fc6b0f5-44ac-49c6-95a4-e99e6a8a7a70 / ext4 defaults 1 1
UUID=aef54e97-d3bb-464a-aa31-35b3a6c836ae /boot ext4 defaults 1 2
/dev/disk/by-partuuid/5f8f3fee-1394-4d11-aab4-3e96935f278c /var/lib/ceph/osd/ceph-6 xfs defaults 0 0
/dev/disk/by-partuuid/a3ef1744-0b24-4719-8cfb-6fed7f17da2f /var/lib/ceph/osd/ceph-7 xfs defaults 0 0Размонтируем точки монтирования OSD:
[centos@csn004 ~]$ sudo umount /var/lib/ceph/osd/ceph-6
[centos@csn004 ~]$ sudo umount /var/lib/ceph/osd/ceph-7 Проверяем, что точки монтирования удалены с разделов диска /dev/sdb:
[centos@csn004 ~]$ sudo lsblk
NAME
MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda
8:0 0 50G 0 disk
├─sda1
8:1 0 2G 0 part /boot
└─sda2
8:2 0 48G 0 part /
sdb
8:16 0 700G 0 disk
├─sdb1
8:17 0 300M 0 part
├─sdb2
8:18 0 349.7G 0 part
│ └─ceph--99199b58--63b4--41c3--a51a--263aa9fced25--d96565a0-d225dd3a--874c--5a18--9ed8--7a9749bcd9fd 253:0 0 349.7G 0 lvm
├─sdb3
8:19 0 300M 0 part
└─sdb4
8:20 0 349.7G 0 part
└─ceph--99199b58--63b4--41c3--a51a--263aa9fced25--d96565a0-3a68ae7b--2b2c--5145--a944--8aabe8977579 253:1 0 349.7G 0 lvm Проверяем список VG (Volume Group) и LV (Logical Volume) на удаляемом диске:
[centos@csn004 ~]$ sudo vgdisplay
--- Volume group ---
VG Name ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size <699.41 GiB
PE Size 4.00 MiB
Total PE 179048
Alloc PE / Size 179048 / <699.41 GiB
Free PE / Size 0 / 0
VG UUID OOnoPA-YeBb-fUdu-1zxI-78Hw-dM5M-5J83Yg
[centos@csn004 ~]$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0/d225dd3a-874c-5a18-9ed8-7a9749bcd9fd
LV Name d225dd3a-874c-5a18-9ed8-7a9749bcd9fd
VG Name ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0
LV UUID GDRnPK-7ADg-AVdc-ZbdZ-4HXq-9Tn7-wYyOLI
LV Write Access read/write
LV Creation host, time csn004, 2025-10-03 00:07:15 +0300
LV Status NOT available
LV Size 349.70 GiB
Current LE 89524
Segments 1
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0/3a68ae7b-2b2c-5145-a944-8aabe8977579
LV Name 3a68ae7b-2b2c-5145-a944-8aabe8977579
VG Name ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0
LV UUID qiaYah-wufA-UXYR-eQuf-3mRZ-jPyY-8NKAj2
LV Write Access read/write
LV Creation host, time csn004, 2025-10-03 00:07:29 +0300
LV Status NOT available
LV Size 349.70 GiB
Current LE 89524
Segments 1
Allocation inherit
Read ahead sectors autoОстанавливаем VG на удаляемом диске:
[centos@csn004 ~]$ sudo vgchange -a n ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0
0 logical volume(s) in volume group "ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0" now activeУдаляем логические диски (не по имени, а по LV Path!):
[centos@csn004 ~]$ sudo lvremove /dev/ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0/d225dd3a-874c-5a18-9ed8-7a9749bcd9fd
Logical volume "d225dd3a-874c-5a18-9ed8-7a9749bcd9fd" successfully removed.
[centos@csn004 ~]$ sudo lvremove /dev/ceph-99199b58-63b4-41c3-a51a-263aa9fced25-d96565a0/3a68ae7b-2b2c-5145-a944-8aabe8977579
Logical volume "3a68ae7b-2b2c-5145-a944-8aabe8977579" successfully removed.Удаляем метаданные физического диска LVM:
[centos@csn004 ~]$ sudo pvremove -ff -y /dev/sdb
Labels on physical volume "/dev/sdb" successfully wiped.Проверяем, что все PV, VG и LV удалены с диска (команды должны вернуть пустой вывод):
[centos@csn004 ~]$ sudo pvs; sudo vgs; sudo lvsУдаляем оставшиеся разделы и очищаем диск:
[centos@csn004 ~]$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 700 GiB, 751619276800 bytes, 1468006400 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
[centos@csn004 ~]$ sudo dd if=/dev/zero of=/dev/sdb bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0620861 s, 169 MB/s
[centos@csn004 ~]$ sudo sgdisk --zap-all /dev/sdb
Creating new GPT entries in memory.
GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.
[centos@csn004 ~]$ sudo wipefs -af /dev/sdb
[centos@csn004 ~]$ sudo partprobe /dev/sdbСтираем первые и последние 1 Мб на диске (примерно 2048 секторов):
[centos@csn004 ~]$ sudo dd if=/dev/zero of=/dev/sdb bs=1M count=1 oflag=direct
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00361045 s, 290 MB/s
[centos@csn004 ~]$ sectors=$(blockdev --getsz /dev/sdb)
[centos@csn004 ~]$ sudo dd if=/dev/zero of=/dev/sdb bs=512 seek=$((sectors - 2048)) count=2048 oflag=direct
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.685609 s, 1.5 MB/sОжидаем завершения всех udev-событий:
[centos@csn004 ~]$ sudo udevadm settleДля надежности стираем остаточные метаданные LVM с диска утилитой ceph-volume:
[centos@csn004 ~]$ sudo ceph-volume lvm zap /dev/sdb --destroy
--> Zapping: /dev/sdb
Running command: /bin/dd if=/dev/zero of=/dev/sdb bs=1M count=10 conv=fsync
stderr: 10+0 records in
10+0 records out
stderr: 10485760 bytes (10 MB, 10 MiB) copied, 0.0281396 s, 373 MB/s
--> Zapping successful for: <Raw Device: /dev/sdb>Проверяем, что диск очищен и готов для повторного ввода в кластер Ceph (в столбце available должно быть значение True):
[centos@csn004 ~]$ sudo ceph-volume inventory
Device Path Size Device nodes rotates available Model name
/dev/sdb 700.00 GB sdb True True QEMU HARDDISK
/dev/sda 50.00 GB sda True False QEMU HARDDISKУдаляем каталоги с информацией об OSD:
[centos@csn004 ~]$ sudo rm -rf /var/lib/ceph/osd/ceph-6
[centos@csn004 ~]$ sudo rm -rf /var/lib/ceph/osd/ceph-7Обновляем список сервисов systemd:
[centos@csn004 ~]$ sudo systemctl daemon-reloadПроверяем список сервисов Ceph в systemd:
[centos@csn004 ~]$ systemctl list-units --all | grep -i 'ceph'
ceph-crash.service loaded active running Ceph crash dump collector
system-ceph\x2dmds.slice loaded active active Slice /system/ceph-mds
system-ceph\x2dmgr.slice loaded active active Slice /system/ceph-mgr
system-ceph\x2dmon.slice loaded active active Slice /system/ceph-mon
system-ceph\x2dosd.slice loaded active active Slice /system/ceph-osd
ceph-mon.target loaded inactive dead ceph target allowing to start/stop all ceph-mon@.service instances at once
ceph-osd.target loaded active active ceph target allowing to start/stop all ceph-osd@.service instances at once
ceph.target loaded active active ceph target allowing to start/stop all ceph*@.service instances at onceЗдесь мы видим, что у нас еще остаются активными некоторые сервисы Ceph.
Отключим их.
Финальная зачистка узла csn004
На финальном этапе останавливаем и отключаем оставшиеся сервисы Ceph:
[centos@csn004 ~]$ sudo systemctl disable --now ceph-crash.service
Removed /etc/systemd/system/ceph.target.wants/ceph-crash.service.
[centos@csn004 ~]$ sudo systemctl disable --now ceph-osd.target
Removed /etc/systemd/system/ceph.target.wants/ceph-osd.target.
Removed /etc/systemd/system/multi-user.target.wants/ceph-osd.target.
[centos@csn004 ~]$ sudo systemctl disable --now ceph.target
Removed /etc/systemd/system/multi-user.target.wants/ceph.target.Обновляем список сервисов systemd:
[centos@csn004 ~]$ sudo systemctl daemon-reloadПроверяем список оставшихся сервисов Ceph:
[centos@csn004 ~]$ systemctl list-units --all | grep -i 'ceph'
system-ceph\x2dmds.slice loaded active active Slice /system/ceph-mds
system-ceph\x2dmgr.slice loaded active active Slice /system/ceph-mgr
system-ceph\x2dmon.slice loaded active active Slice /system/ceph-mon
system-ceph\x2dosd.slice loaded active active Slice /system/ceph-osd
ceph.target loaded inactive dead ceph target allowing to start/stop all ceph*@.service instances at onceСервис ceph.target уже отключен и не сможет запустить никакие другие сервисы Ceph на узле csn004. Но он больше не нужен на этом узле. Чтобы удалить и его, продолжим зачистку узла csn004.
Проверяем список rpm-пакетов Ceph:
[centos@csn004 ~]$ sudo rpm -qa | grep -i ceph
python3-ceph-common-17.2.7-1.el7.3.x86_64
libcephfs2-17.2.7-1.el7.3.x86_64
python3-ceph-argparse-17.2.7-1.el7.3.x86_64
python3-cephfs-17.2.7-1.el7.3.x86_64
ceph-common-17.2.7-1.el7.3.x86_64
ceph-base-17.2.7-1.el7.3.x86_64
ceph-selinux-17.2.7-1.el7.3.x86_64
ceph-volume-17.2.7-1.el7.3.noarch
ceph-osd-17.2.7-1.el7.3.x86_64
ceph-mon-17.2.7-1.el7.3.x86_64
ceph-mds-17.2.7-1.el7.3.x86_64
libcephsqlite-17.2.7-1.el7.3.x86_64
ceph-prometheus-alerts-17.2.7-1.el7.3.noarch
ceph-grafana-dashboards-17.2.7-1.el7.3.noarch
cephadm-17.2.7-1.el7.3.noarch
ceph-mgr-cephadm-17.2.7-1.el7.3.noarch
ceph-mgr-dashboard-17.2.7-1.el7.3.noarch
ceph-mgr-diskprediction-local-17.2.7-1.el7.3.noarch
ceph-mgr-k8sevents-17.2.7-1.el7.3.noarch
ceph-mgr-rook-17.2.7-1.el7.3.noarch
ceph-mgr-modules-core-17.2.7-1.el7.3.noarch
ceph-mgr-17.2.7-1.el7.3.x86_64Удаляем пакеты Ceph:
sudo dnf remove -y ceph* python3-ceph* libceph*Удаляем каталог с остаточными данными о кластере Ceph:
[centos@csn004 ~]$ sudo rm -rf /var/lib/cephОбновляем список systemd-юнитов и проверяем наличие сервисов Ceph:
[centos@csn004 ~]$ sudo systemctl daemon-reload
[centos@csn004 ~]$ sudo systemctl list-units --all | grep -i ceph
system-ceph\x2dmds.slice loaded active active Slice /system/ceph-mds
system-ceph\x2dmgr.slice loaded active active Slice /system/ceph-mgr
system-ceph\x2dmon.slice loaded active active Slice /system/ceph-mon
system-ceph\x2dosd.slice loaded active active Slice /system/ceph-osdЭти slice-юниты создаются автоматически при запуске Ceph-сервисов. После удаления пакетов и перезагрузки узла они исчезают.
Можно дополнительно поискать оставшиеся файлы и удалить их, но это не обязательно:
# Поиск файлов и каталогов с *ceph* в имени
[centos@csn004 ~]$ sudo find / -type f -iname '*ceph*'
[centos@csn004 ~]$ sudo find / -type d -iname '*ceph*'На этом этапе узел уже выведен из кластера и полностью зачищен от следов Ceph.
После этого остается только перезагрузить узел — после перезагрузки исчезнут юниты system-ceph2d***.slice и остаточные cgroups.
Таким образом, узел csn004, который ранее был Active MON, MGR, MDS и содержал OSD c томами LVM, будет полностью выведен из кластера Ceph и доступен для введения в другие кластеры. Задача решена.
Что в итоге
Безусловно, рассмотренная в статье задача — специфический кейс. Но многие специалисты при работе с Ceph-кластерами, так или иначе, сталкиваются с подобными задачами, и сталкиваются часто. Вместе с тем описанный алгоритм наглядно показывает, что при тщательном подходе к этой задаче, наличии контроля на каждом этапе и соблюдении простых правил вывести из кластера Ceph можно даже узел с Active MON, MGR, MDS и OSD с томами LVM, причем можно сделать это таким образом, чтобы кластер и оставшиеся узлы не пострадали.