Привет всем! Недавно у нас произошел сбой электропитания и потеря сетевого соединения (вышел из строя коммутатор Junpier, который использовался кластером Ceph). Некоторые узлы Proxmox/Ceph были перезапущены. Сетевой трафик и узлы восстановлены, но кластер находится в критическом состоянии. На мониторах мы видим список PG, но кластер практически завис и не меняет статус. Вот статус здоровья: Code: ceph -s
cluster:
id: xxxx
health: HEALTH_ERR
noscrub,nodeep-scrub флаги установлены
3 OSD в состоянии nearfull
3 пула nearfull
нет активных менеджеров
Обнаружен перенос BlueFS на 2 OSD
Снижена доступность данных: 4083 PG неактивны, 31 PG отключены, 289 PG в процессе согласования, 2 PG устарели
Повреждена целостность данных: 48877/1358004 объекта с повреждениями (3.599%), 25 PG с повреждениями, 48 PG с недостаточным размером
242 PG не были глубоко проверены
1 PG не была проверена
2 демона недавно аварийно завершились
18 медленных запросов заблокированы > 32 сек
6 зависших запросов заблокированы > 4096 сек
24 медленных операций, самая старая заблокирована на 47745 сек, демоны [osd.12,osd.13] имеют медленные операции.
Демоны мониторинга разрешают восстановление глобального ID при незащищенном доступе
services:
mon: 3 демона, кворум mon3,mon4,mon5 (возраст 2ч)
mgr: нет активных демонов (с 5ч)
osd: 37 OSD: 35 в рабочем состоянии, 30 онлайн; 230 переназначенных PG
флаги noscrub,nodeep-scrub
data:
pools: 14 пулов, 4352 PG
objects: 679.00к объектов, 2.5 TiB
usage: 5.1 TiB используется, 4.1 TiB / 9.1 TiB доступно
pgs: 85.777% PG неизвестны
8.042% PG неактивны
48877/1358004 объекта с повреждениями (3.599%)
8181/1358004 объекта смещены (0.602%)
3733 неизвестны
268 в процессе согласования
226 активны+чистые
31 отключены
23 активируются
23 активны+недостаточного размера
18 переназначены+в процессе согласования
16 активны+недостаточного размера+с повреждениями
6 недостаточного размера+с повреждениями+в процессе согласования
2 активны+недостаточного размера+с повреждениями+переназначены+ожидание заполнения
2 устарели+переназначены+в процессе согласования
1 создаются+в процессе согласования
1 активны+переназначены+ожидание заполнения
1 активны+недостаточного размера+с повреждениями+переназначены+в процессе заполнения
1 активируются+переназначены некоторые OSD показаны как "down", но они были намеренно помечены как отключены некоторое время назад и должны были быть заменены - после этого не было никаких проблем с кластером. Состояние кластера не меняется вообще, похоже, все застряло в процессе согласования. PG, отмеченные как неизвестные, переходят в состояние согласования после запуска MGR, но после достижения примерно ~200 активных PG ничего не меняется и все висит. Вот фрагмент из одного из OSD с расширенной отладкой (большинство OSD возвращают те же самые записи): Code: 2025-03-30 21:00:20.922 7fd71b27a700 1 --1- [v2:192.168.17.125:6806/1759437,v1:192.168.17.125:6807/1759437] >> conn(0x5566ad690000 0x5566adb65000 :6807 s=ACCEPTING pgs=0 cs=0 l=0).handle_client_banner read peer banner and addr failed
2025-03-30 21:00:20.922 7fd71a278700 1 -- [v2:192.168.17.125:6804/1759437,v1:192.168.17.125:6805/1759437] >> conn(0x5566adacb200 legacy=0x5566add50000 unknown :6805 s=ACCEPTING pgs=0 cs=0 l=0).send_server_banner sd=85 legacy v1:192.168.17.125:6805/1759437 socket_addr v1:192.168.17.125:6805/1759437 target_addr v1:192.168.17.119:39209/0 Этот фрагмент из одного из OSD без расширенной отладки. Osd практически заваливает логи записями типа: Code: 2025-03-30 21:06:20.957 7f0e27f85700 0 log_channel(cluster) log [WRN] : slow request osd_pg_create(e128618 15.1b:115413 15.31:115413 15.40:115413 15.6c:115413 15.6e:115413 15.71:115413 15.75:115413 15.7a:115413 15.84:115413 15.9f:115413 15.a5:115413 15.c9:115413 15.d4:115413 15.da:115413 15.fc:115413) initiated 2025-03-30 20:22:38.487018 currently started
2025-03-30 21:06:20.957 7f0e27f85700 -1 osd.36 128650 get_health_metrics reporting 1 slow ops, oldest is osd_pg_create(e128618 15.1b:115413 15.31:115413 15.40:115413 15.6c:115413 15.6e:115413 15.71:115413 15.75:115413 15.7a:115413 15.84:115413 15.9f:115413 15.a5:115413 15.c9:115413 15.d4:115413 15.da:115413 15.fc:115413) Попытка выполнения `ceph pg dump` приводит к зависанию. Проверка команды с помощью `strace` показывает только таймауты. Кто-нибудь сталкивался с чем-то подобным раньше? Есть ли еще шанс восстановить данные в этом состоянии?
cluster:
id: xxxx
health: HEALTH_ERR
noscrub,nodeep-scrub флаги установлены
3 OSD в состоянии nearfull
3 пула nearfull
нет активных менеджеров
Обнаружен перенос BlueFS на 2 OSD
Снижена доступность данных: 4083 PG неактивны, 31 PG отключены, 289 PG в процессе согласования, 2 PG устарели
Повреждена целостность данных: 48877/1358004 объекта с повреждениями (3.599%), 25 PG с повреждениями, 48 PG с недостаточным размером
242 PG не были глубоко проверены
1 PG не была проверена
2 демона недавно аварийно завершились
18 медленных запросов заблокированы > 32 сек
6 зависших запросов заблокированы > 4096 сек
24 медленных операций, самая старая заблокирована на 47745 сек, демоны [osd.12,osd.13] имеют медленные операции.
Демоны мониторинга разрешают восстановление глобального ID при незащищенном доступе
services:
mon: 3 демона, кворум mon3,mon4,mon5 (возраст 2ч)
mgr: нет активных демонов (с 5ч)
osd: 37 OSD: 35 в рабочем состоянии, 30 онлайн; 230 переназначенных PG
флаги noscrub,nodeep-scrub
data:
pools: 14 пулов, 4352 PG
objects: 679.00к объектов, 2.5 TiB
usage: 5.1 TiB используется, 4.1 TiB / 9.1 TiB доступно
pgs: 85.777% PG неизвестны
8.042% PG неактивны
48877/1358004 объекта с повреждениями (3.599%)
8181/1358004 объекта смещены (0.602%)
3733 неизвестны
268 в процессе согласования
226 активны+чистые
31 отключены
23 активируются
23 активны+недостаточного размера
18 переназначены+в процессе согласования
16 активны+недостаточного размера+с повреждениями
6 недостаточного размера+с повреждениями+в процессе согласования
2 активны+недостаточного размера+с повреждениями+переназначены+ожидание заполнения
2 устарели+переназначены+в процессе согласования
1 создаются+в процессе согласования
1 активны+переназначены+ожидание заполнения
1 активны+недостаточного размера+с повреждениями+переназначены+в процессе заполнения
1 активируются+переназначены некоторые OSD показаны как "down", но они были намеренно помечены как отключены некоторое время назад и должны были быть заменены - после этого не было никаких проблем с кластером. Состояние кластера не меняется вообще, похоже, все застряло в процессе согласования. PG, отмеченные как неизвестные, переходят в состояние согласования после запуска MGR, но после достижения примерно ~200 активных PG ничего не меняется и все висит. Вот фрагмент из одного из OSD с расширенной отладкой (большинство OSD возвращают те же самые записи): Code: 2025-03-30 21:00:20.922 7fd71b27a700 1 --1- [v2:192.168.17.125:6806/1759437,v1:192.168.17.125:6807/1759437] >> conn(0x5566ad690000 0x5566adb65000 :6807 s=ACCEPTING pgs=0 cs=0 l=0).handle_client_banner read peer banner and addr failed
2025-03-30 21:00:20.922 7fd71a278700 1 -- [v2:192.168.17.125:6804/1759437,v1:192.168.17.125:6805/1759437] >> conn(0x5566adacb200 legacy=0x5566add50000 unknown :6805 s=ACCEPTING pgs=0 cs=0 l=0).send_server_banner sd=85 legacy v1:192.168.17.125:6805/1759437 socket_addr v1:192.168.17.125:6805/1759437 target_addr v1:192.168.17.119:39209/0 Этот фрагмент из одного из OSD без расширенной отладки. Osd практически заваливает логи записями типа: Code: 2025-03-30 21:06:20.957 7f0e27f85700 0 log_channel(cluster) log [WRN] : slow request osd_pg_create(e128618 15.1b:115413 15.31:115413 15.40:115413 15.6c:115413 15.6e:115413 15.71:115413 15.75:115413 15.7a:115413 15.84:115413 15.9f:115413 15.a5:115413 15.c9:115413 15.d4:115413 15.da:115413 15.fc:115413) initiated 2025-03-30 20:22:38.487018 currently started
2025-03-30 21:06:20.957 7f0e27f85700 -1 osd.36 128650 get_health_metrics reporting 1 slow ops, oldest is osd_pg_create(e128618 15.1b:115413 15.31:115413 15.40:115413 15.6c:115413 15.6e:115413 15.71:115413 15.75:115413 15.7a:115413 15.84:115413 15.9f:115413 15.a5:115413 15.c9:115413 15.d4:115413 15.da:115413 15.fc:115413) Попытка выполнения `ceph pg dump` приводит к зависанию. Проверка команды с помощью `strace` показывает только таймауты. Кто-нибудь сталкивался с чем-то подобным раньше? Есть ли еще шанс восстановить данные в этом состоянии?
