Кластер Ceph постоянно осуществляет наблюдение за собой при помощи средств scrub и deep-scrub. Scrub осуществляет проверку атрибутов и размеров объектов. Он является очень быстрым и не слишком требовательным к ресурсам — идеальным средством для ежедневных проверок. Deep-scrub проверяет все контрольные суммы объектов rados алгоритмом CRC32 и все обнаруженные различия в репликах отмечаются в сообщениях как нарушающие согласованность данных.

Операции scrub и deep-scrub являются чрезвычайно ёмкими в отношении ресурсов ввода/ вывода и могут оказывать существенное влияние на производительность кластера. Однако, данные операции должны быть включены чтобы гарантировать целостность и доступность данных. Ceph пытается выполнять операции scrub и deep-scrub когда не перегружен работой. Тем не менее, будучи запущенным, scrub выполняется пока не завершит проверку всех имеющихся Групп размещения (PG).

Чтобы отключить scrub и deep-scrub выполните следующие команды:

ceph set noscrub
ceph set nodeep-scrub

Для возвращения к стандартным опциям необходимо выполнить:

ceph unset noscrub
ceph unset nodeep-scrub

Для тонкой настройки процессов выскребания воспользуйтесь следующими опциями настройки (предоставлены значения по умолчанию):

osd_scrub_begin_hour = 0 # начинать в этот час
osd_scrub_end_hour = 24 # когда  запускать последний scrub
osd_scrub_load_threshold = 0.05 #scrub только в случае когда нагрузка ниже
osd_scrub_min_interval = 86400 # не чаще чем  1 раз в день
osd_scrub_max_interval = 604800 # не менее чем 1 раз в неделю
osd_deep_scrub_interval = 604800 # глубокий scrub выполнять раз в неделю

Операции scrub применяются для проверки жизнеспособности объектов и их доступности. Группы размещения выскребаются пока кластер не выполняет никакие интенсивные операции ввода/ вывода, например, восстановление (хотя уже начавшееся выскребание должно продолжиться). Если данное задание обнаружит, что некий объект повреждён или имеется несоответствие данных (в результате проверки контрольной суммы), он помечает данный объект как неиспользуемый и далее требуется ручное вмешательство оператора.
Вплоть до версии Ceph 0.90 при записи объекта не выполнялось сохранение его контрольной суммы. Контрольные суммы вычислялись при операциях записи OSD, причём Ceph не мог произвольно определять какая из них является правильной. Для простейшего примера с 3 репликами и одной отличающейся контрольной суммой просто определить что пошло не так и должно быть исправлено (восстановлено из реплики), однако когда у нас различаются все три контрольные суммы, либо мы имеем некий износ оборудования, или неверно работающий контроллер на двух узлах — мы не можем определить какие данные являются верными. Это не является вариантом для общей проверки.

Для исправления данных испорченной Группы размещения вручную необходимо:

1. Для начала определить испорченную Группу размещения с противоречивыми объектами:
   

   ceph pg dump | grep inconsistent
   

   
   либо
   

   ceph health detail
   

   
   
2. Затем запустить восстановление (в случае, когда ваша первичная копия содержит правильные данные), или же восстановить вручную, переместив/ удалив испорченные файлы на диске OSD:
   

   ceph pg repair {pgnum}
   

   
   

Важно: В случае ошибок в первичной копии процесс восстановления достаточно сложен. В настоящее время восстановление реплицированных Групп размещения состоит в перемещении первичных данных в другие узлы. Это приводит к самосогласованности кластера Ceph, однако может создать проблемы для потребителей данных если первичные данные содержат ошибки.
Такие дела.

Ceph и его мониторинг подробнее:

• Zabbix. Полное руководство Андреа Далле Ваккье, 2016
• Proxmox. Полное руководство. 2е изд Васим Ахмед, 2016
• Книга рецептов Ceph Каран Сингх, 2016
• Изучаем Ceph Каран Сингх, 2015
• Книга рецептов Proxmox Васим Ахмед, 2015, Главы 1-6, Дополнения: Преобразование OpenVZ в LXC, Организация ограждения