ceph
Заманчивая штука. Красивая архитектура. Решил попробовать. Развернул узел mon+ods+mds. Вроде красиво все взлетело, даже чего-то примонтировалось. Добавил второй узел mon+ods (+mds пока не успел)
На втором узле оба демона стартовали. Однако с точки зрения кластера osd второго узла лежит.
ceph -s
cluster 1da6afeb-f86a-47d4-a94b-e635ca0da6e5
health HEALTH_WARN
264 pgs degraded
264 pgs stuck degraded
264 pgs stuck unclean
264 pgs stuck undersized
264 pgs undersized
recovery 20/40 objects degraded (50.000%)
monmap e2: 2 mons at {ceph1=192.168.100.101:6789/0,ceph2=192.168.100.102:6789/0}
election epoch 22, quorum 0,1 ceph1,ceph2
mdsmap e89: 1/1/1 up {0=ceph1=up:active}
osdmap e137: 2 osds: 1 up, 1 in
pgmap v235: 264 pgs, 3 pools, 2992 bytes data, 20 objects
1044 MB used, 7137 MB / 10240 MB avail
20/40 objects degraded (50.000%)
264 active+undersized+degraded
ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 2.00000 root default
-2 1.00000 host ceph1
0 1.00000 osd.0 up 1.00000 1.00000
-3 1.00000 host ceph2
1 1.00000 osd.1 down 0 1.00000
ceph daemon osd.1 status
{
"cluster_fsid": "1da6afeb-f86a-47d4-a94b-e635ca0da6e5",
"osd_fsid": "352883ba-8479-4ec8-91ae-fd3001cbd1c3",
"whoami": 1,
"state": "booting",
"oldest_map": 1,
"newest_map": 136,
"num_pgs": 0
}
В логах osd
ignoring osdmap until we have initialized
done with init, starting boot process
lsb_release_parse - pclose failed: (0) Success
Похоже что процесс ods зависает в состоянии booting. Может кто знает что делать в этом случае, ну или ссылку на форум цепховодов, можно англоязычных.
- Для комментирования войдите или зарегистрируйтесь
может не в тему, но как ты
может не в тему, но как ты решил вопрос с кворумом при 2-х нодах ? Имхо, их должно быть нечетное число ( сколько копий будет у тебя - это другой вопрос, от числа нод не зависящий)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Она может работать и на одной
Она может работать и на одной ноде, что приятно порадовало. После поднятия одного узла фс легко замонтировалась на запись.
Кворум отключается в конфиге osd crush chooseleaf type = 0
Понятно что на продакшн это будет жесть , но в качестве временной меры при развертывании или восстановительных работах такой функционал (ИМХО) обязателен для подобного софта.
wi написал(а): онятно что на
Да никакой жести не будет. Просто данные будут жестоко и нещадно пролюблены. Эдакий сетевой RAID-0 - помер один винт -> всё накрылось :-)
Нейтральность - высшее достижение сознания!
Была такая же шняга. Лечится
Была такая же шняга. Лечится остановкой демона osd, удалением всего его добра в /var/lib/ceph/osd/[clustername]-[osdnum] и запуска ceph.osd -i [osdnum] --mkfs. keyring можно предварительно забэкапить и докинуть обратно(keyring - это одноименный файл по вышеуказанному пути). Убедись предварительно, что у тебя нет placement group в недоступном состоянии. То есть что хотя бы одна живая реплика всех pg в наличии - иначе будет много-много боли. Меня Бог миловал от подобного пока, но вляпаться в такую жесть не хотелось бы.
Суть проблемы - если попытаться запустить демон без ceph.osd -i [osdnum] --mkfs он то эту самую ФС похоже что создает, но очень уж криво. При этом если смотреть на это богатство tcpdump-ом - видно что ему абсолютно пофиг на мониторы кластера, то есть он даже не пытается до них достучаться и сказать мол, братцы, я живой.
Он не стучит в мониторы -> они не знают что нода поднялась -> ну ты понел
Нейтральность - высшее достижение сознания!
Премного благодарен.Сей
Премного благодарен.
Сей радикальный метод, несмотря на его безусловную действенность, попахивает окнами, где лучшим лекарстовм во все времена был format C:. Потеря данных в данном случае не грозит, ибо сей мятежный осд к кластеру не подключился, соответственно на нем ничего нет. Причину сего безобразного создания файловой системы осд так и не понял, успев нарваться на этот же глюк повторно при переносе опыта с вируалок на железо. Кривизна рук исключена ибо скрипт.
Ваше утверждение насчет потери данных и рейд-ноль сомнительно. Количество мониторов никоим образом не влияет на целостность данных, ибо все данные и метаданные хранятся на осд. При наличии "кластера" из одного узла с одним осд его надежность чисто теоретически сравнима с надежностью сервера с обычной фс (операции чтения-записи с точки зрения демона осд - локалные, синхронизации нет, кворум не нужен как класс ибо сплитбрайн принципиально невозможен). Опровержение же последнего утверждения на мой взгляд сводится к доказательству принципиальной неработоспособности ceph. При расширении кластера до двух и более узлов его устойчивость должна (по идее) расти, вот тут нормальную работу без синхронизации и кворумов представить сложно.
wi, четное количество узлов
wi, четное количество узлов в кластере не поддерживается.
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
таймаут
о чём разговор, пацаны?
кто-то написал новый ништяк или за старое трёте?
иноды вроде все обсосаны в документациях.
В безвременный бан отправлен сей персонаж чудный модератором скучным.
>>четное количество узлов в
>>четное количество узлов в кластере не поддерживается.
Нечетнонодный кластер без узла просто обязан выполнять свою работу, иначе не нужен.
В доках не рекомендуют четное количество мониторов, и вроде как хвастались что пахос лишний выбрасывает. Вобщем работает и два узла.
Подключил три виртуалки на qemu+rbd. Возникли непонятные проблемы с дисковой загрузкой на осд. Я предполагал, что будет проблема с кластерной сеткой ибо 1 gбит "не айс", но сетка загружена в пределах до 30 mбит, а вылез iowait под 50%, что мне вообще непонятно. Кеш на 64 метра вроде как помог, сегодня по ночи буду грузить его дальше. Предполагается, что добавление второго осд несколько снизит загрузку по ио, но пока данные не перенес - тестить не на чем.
Во-первых, запись на ceph -
Во-первых, запись на ceph - дело небыстрое, потому что пока все ноды, где должен храниться pg не ответят о том, что всё сохранили - записи не будет. Во-вторых, как правило в случае Ceph всё упирается в I/O. У меня сеть нагружена в пределах 500-600mbit/sec при ребилде кластера. В штатном режиме работы - и того меньше.
Нейтральность - высшее достижение сознания!
>>Во-первых, запись на ceph -
>>Во-первых, запись на ceph - дело небыстрое
Речь пока не о скорости записи на ceph, а о непонятном потоке дискового ввода-вывода, который неизвестно откуда берется. Ваша гигабитка нагружена вполовину, моя от силы процентов 10. В моем случае суммарный поток по сетевому адаптеру не способен в чистом виде вызвать подобную перегрузку по ио. Есть подозрение, что запись-чтение идет несколько неоптимально из за нелинейности, что в свою очередь наводит на светлую мысль о кешировании и readahed. Используете ли вы rbd, и каковы настройки кэша ceph клиента в вашем случае?
>>потому что пока все ноды, где должен храниться pg
osd пока один. Синхронизации, соответственно нет.
>>У меня сеть нагружена в пределах 500-600mbit/sec при ребилде кластера
Если это мешает, то, судя по документации, есть возможность уменьшить скорость ребилда.