====== Исправляем ошибку с Placement Group в Ceph ======
Устранение проблем c **PG** **Ceph** кластера ''HEALTH_ERR 1 pgs inconsistent; 1 scrub errors''
После замены патч-кордов на тестовом кластере обнаружил ошибку в **Ceph**.
$ ceph health detail
HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
pg 2.2e is active+clean+inconsistent, acting [8]
1 scrub errors
Проверяем лог-файлы **OSD**:
$ grep 2.2e /var/log/ceph/*
/var/log/ceph/ceph.audit.log:2017-04-24 15:38:46.124303 mon.2 192.168.2.120:6789/0 103771 : audit [INF] from='client.? 192.168.2.101:0/2439225090' entity='client.admin' cmd=[{"prefix": "pg repair", "pgid": "2.2e"}]: dispatch
/var/log/ceph/ceph.log:2017-04-24 10:10:24.576558 osd.3 192.168.2.100:6804/4914 4445 : cluster [INF] 2.2e deep-scrub starts
/var/log/ceph/ceph.log:2017-04-24 10:10:37.434117 osd.3 192.168.2.100:6804/4914 4446 : cluster [ERR] 2.2e shard 8: soid 2:74433408rbd_data.a12342ae8944a.000000000000071f:head candidate had a read error
/var/log/ceph/ceph.log:2017-04-24 10:10:48.940079 osd.3 192.168.2.100:6804/4914 4447 : cluster [ERR] 2.2e deep-scrub 0 missing, 1 inconsistent objects
/var/log/ceph/ceph.log:2017-04-24 10:10:48.940085 osd.3 192.168.2.100:6804/4914 4448 : cluster [ERR] 2.2e deep-scrub 1 errors
/var/log/ceph/ceph.log:2017-04-24 15:38:46.717506 osd.3 192.168.2.100:6804/4914 4459 : cluster [INF] 2.2e repair starts
/var/log/ceph/ceph.log:2017-04-24 15:38:56.741299 osd.3 192.168.2.100:6804/4914 4460 : cluster [ERR] 2.2e shard 8: soid 2:74433408rbd_data.a12342ae8944a.000000000000071f:head candidate had a read error
Запускаем восстановление **Placement Group**:
$ ceph pg repair 2.2e
instructing pg 2.2e on osd.3 to repair
Спустя несколько секунд наблюдаем, что **PG** успешно восстановлена и состояние кластера вернулось в нормальный режим работы.
$ ceph health detail
HEALTH_OK
Проверим информацию о **PG**:
$ ceph pg 2.2e query
{
"state": "active+clean",
"snap_trimq": "[]",
"epoch": 516,
"up": [
3,
8
],
"acting": [
3,
8
],
"actingbackfill": [
"3",
"8"
],
Проверяем еще раз лог и наблюдаем, что проблема устранена:
$ grep 2.2e /var/log/ceph/*
/var/log/ceph/ceph-osd.3.log:2017-04-24 15:38:46.717501 7f2070c50700 0 log_channel(cluster) log [INF] : 2.2e repair starts
/var/log/ceph/ceph-osd.3.log:2017-04-24 15:38:56.741297 7f2070c50700 -1 log_channel(cluster) log [ERR] : 2.2e shard 8: soid 2:74433408rbd_data.a12342ae8944a.000000000000071f:head candidate had a read error
/var/log/ceph/ceph-osd.3.log:2017-04-24 15:39:07.692446 7f206e44b700 -1 log_channel(cluster) log [ERR] : 2.2e repair 0 missing, 1 inconsistent objects
/var/log/ceph/ceph-osd.3.log:2017-04-24 15:39:07.752099 7f206e44b700 -1 log_channel(cluster) log [ERR] : 2.2e repair 1 errors, 1 fixed
Правила хорошего тона - использовать на серверах **LACP**.\\
Но поскольку кластер тестовый, то такие ошибки не исключение.