В настоящее время пытаюсь разобраться с этим прямо в мои 3-дневные мемориальные выходные: D
https://gist.github.com/sfxworks/ce77473a93b96570af319120e74535ec
Моя установка - cluser Kubernetes с ладьей, управляющей Ceph. При использовании 13.2.4 у меня возникает эта проблема с постоянным перезапуском одного из моих экранных меню. Это случилось недавно. На узле не произошло сбоя питания или чего-либо еще.
2019-05-25 01:06:07.192 7fb923359700 3 rocksdb: [/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/13.2.4/rpm/el7/BUILD/ceph-13.2.4/src/rocksdb/db/db_impl_compaction_flush.cc:1929] Compaction error: Corruption: block checksum mismatch: expected 862584094, got 1969278739 in /var/lib/rook/osd1/current/omap/002408.sst offset 15647059 size 3855
В этой сущности есть еще несколько с аналогичным сообщением об ошибке. Единственный другой гласит:
2019-05-25 01:06:07.192 7fb939a4a1c0 0 filestore(/var/lib/rook/osd1) EPERM suggests file(s) in osd data dir not owned by ceph user, or leveldb corruption
Я проверил это на узле. Все рут, как и все остальные. Он также помещен в контейнер, и удаление модуля, чтобы оператор воссоздал его, не помогло.
Единственное, что мне удалось найти, так это https://tracker.ceph.com/issues/21303, но похоже, что это год назад. Я не уверен, с чего начать. Любые указания или ссылки на документацию, которой нужно следовать, или решение, если оно у вас есть, будут большим подспорьем. Я вижу некоторые инструменты для bluestore, но не знаю, насколько они применимы, и хочу быть очень осторожным в данной ситуации.
В худшем случае у меня есть резервные копии. Готовы пробовать вещи в разумных пределах.
Если это просто OSD, Могу ли я уничтожить его и заставить ладью переделать его?? Вот ceph status в последнее время
sh-4.2# ceph status
cluster:
id: e5a100b0-6abd-4968-8895-300501aa9200
health: HEALTH_WARN
Degraded data redundancy: 3407/13644 objects degraded (24.971%), 48 pgs degraded, 48 pgs undersized
services:
mon: 3 daemons, quorum c,a,e
mgr: a(active)
osd: 3 osds: 2 up, 2 in
data:
pools: 1 pools, 100 pgs
objects: 6.82 k objects, 20 GiB
usage: 109 GiB used, 792 GiB / 900 GiB avail
pgs: 3407/13644 objects degraded (24.971%)
52 active+clean
48 active+undersized+degraded
io:
client: 366 KiB/s wr, 0 op/s rd, 42 op/s wr
Если это просто OSD, могу ли я уничтожить его и заставить ладью переделать его?
На основе вашего ceph status, у вас есть ухудшенные данные, но нет зависших / зависших данных. Итак, да, вы можете отключить третье OSD, но при этом обратите внимание, что вы оставляете себя уязвимым для всего, что может отключить любой из оставшихся OSD, пока вы работаете над заменой третьего.
EPERM
Вы делаете что-то очень глупое, например, запускаете это поверх NFS? Что значит df /var/lib/rook/osd1 показать, а как насчет grep /var/lib/rook/osd1 /proc/mounts?
block checksum mismatch
Это также согласуется с гипотезой NFS, но также может быть вызвано плохим оборудованием, плохими драйверами, плохими драйверами FS (правда, только очень) плохая конфигурация VFS или еще несколько вещей, о которых я не могу думать в данный момент. Несколько снимков в темноте:
uptime на машине?-o nobarrier установить на соответствующий ФС?`Я не понимаю, что вы имеете в виду под" -o nobarrier ".
Когда Ceph работает поверх MD, у вас есть по крайней мере две файловые системы и их бесконечное количество. В частности, у вас есть:
-o loop на котором размещается OSD.Это может быть довольно сложно отследить без специализированные инструменты, и даже когда вы это сделаете, вы не можете гарантировать, что барьеры будут соблюдены, потому что врут драйверы, встроенное ПО и оборудование. По сути, тот факт, что ввод-вывод вообще происходит, - маленькое чудо. То, что я здесь просил, вероятно, легче всего решить с помощью grep -i barrier /proc/mounts на всех соответствующих машинах, вместо того, чтобы на самом деле пытаться выяснить, какие FS действительно актуальны.
В любом случае, один из самых простых способов сделать OSD Ceph очень сварливыми - это предоставить ненадежную семантику записи. «Барьер» - это инструмент, используемый в потоке записи, чтобы гарантировать, что, независимо от любой последующей пакетной обработки, ничего после барьер всегда будет сохранен на диске перед все перед барьер сохраняется. Простой пример, банковский перевод:
Напишите 1: Уменьшите баланс счета Эбби на 100 долларов Напишите 2: Увеличьте баланс счета Бобби на 100 долларов
В этом сценарии, если из-за пакетной обработки с некоторыми предыдущими операциями записи или позиционирования головок над магнитными носителями или солнечные вспышки, Сначала происходит запись 2, а затем машина теряет мощность, маленький Бобби только что получил "бесплатные" деньги. Поэтому, по настоянию юридического отдела, мы вставляем барьерный запрос между записями 1 и 2, тем самым гарантируя, что, хотя мы можем немного вернуться во времени в случае потери питания, мы никогда не потеряем ни цента наших собственных денег. (Убытки Эбби также были бы возмещены, если бы мы жили в транзакционно согласованном мире, таком как база данных, конечно, но барьеры - один из способов создания таких миров в первую очередь.)
Ceph использует препятствия (среди прочих уловок), пытаясь одновременно обеспечить пропускную способность и некоторое подобие согласованности данных перед лицом нечистых отключений. Именно по этому последнему пункту я также попросил uptime; хотя есть и другие способы неоднократно нечисто выключать экранное меню (kill -9 или oom_killer на ум), довольно надежный - иметь флэшбокс, который сам перезагружается раз в час.