мне кажется что в данном споре лучше оперировать ссылками на строки в исходниках, чем картинками на сайте.
Потому что официальной документации верить нельзя?
RADOS — это ядро Ceph, без него кластер работать не будет.
RGW — всего лишь один из способов доступа клиентов к своим данным. Этот демон вообще опциональный.
там, очевидно, не может быть соответствия 1-в-1 объектам ceph'а
Почему?
что такое «каталог» в ceph'е?
Я не знаю, это же не для всех очевидно. Но я предположу: каталог в ceph'e — это метаданные? Как и атрибуты, владелец, хардлинки и симлинки? Файлы — объекты, все остальное — метаданные.
Если бы мне было на 10 лет меньше, я бы ввязался в спор, объясняя устройство rgw.
Кому? Разработчикам Ceph, чтоб они у себя на сайте картинку поправили?
rgw не «лежит» поверх радоса, это и есть rados, один-в-один
rgw — это не rados, об этом намекает картинка с сайта. rgw (rados gateway) лежит поверх rados. Это слой доступа к объектам rados, о чем дальше вы и говорите.
В rgw нет файлов, есть объекты. Это те самые объекты, которые в ceph'е и есть, без дополнительного слоя трансляции. RGW к ним только REST API делает.
А вот это уже половина ответа на вопрос, который я действительно задавал. Спасибо. А про CephFS и 1 файл == 1 объект что скажете? Если я создам 10-гиговый файл, он будет лежать в виде жирного 10-гигового объекта?
Вы путаете абстракции. Нижний уровень — rgw. Точнее, rados.
А это не вы путаете абстракции? Нижний уровень — это rados, а rgw (как впрочем и rbd) лежит поверх rados. Это видно на схеме.
Я написал о том, что rbd (блочное устройство) хранит блоки в объектах по 4 мегабайта. Однако, если записать жирный объект напрямую в пул (минуя rbd), он никак не фрагментируется. Посему у меня и возник вопрос: CephFS фрагментирует файлы на объекты или 1 файл == 1 объект? Я спрашиваю, потому что я не работал с CephFS, ибо он не продакшен-реди.
А вот в каком количестве pg он лежит — это уже решает crush map
Так а я и не спрашивал, где и в каком количестве лежит объект. Вы путаете уровни: я спрашивал про логический, вы отвечаете про физический. Физический уровень я могу легко посмотреть командой «ceph osd map rbd <object_name>», где будет видно в какой плейсмент-группе лежит объект, и по каким OSD эта группа размазана.
Ну, вообще, можно получить карту pg, блоков в pg, ковыряться в дисках.
Это что касается блоков RBD. А не знаете, как дело обстоит с CephFS и RGW?
Вообще я наблюдал, что на OSD блоки RBD по умолчанию хранятся в виде объектов по 4 мегабайта. Однако, когда я пробовал записать файл 100 МБ непосредственно в пул в виде объекта (минуя RBD), Ceph никак его не фрагментировал, и я находил на OSD этот самый 100-мегабайтный объект.
А чтобы развалить кластер достаточно сделать какую-нибудь мелкую глупость с монитором.
и приводите ссылку на баг, где выполняете команду
ceph osd crush move pp1 root=fast2500
разве это операция с монитором?
Так или иначе, на убунте 16.04.1 я свободно перемещал узлы и OSD по краш-дереву. Единственное что, я не помню, менял ли я именно root. Возможно, все мои манипуляции не выходили за рамки root=default. И увы, версию самого ceph я тоже не помню на тот момент (но подозреваю, что 10.2.2).
Однако, если почитать переписку, под Вашим багрепортом, становится понятно, что баг еще жив на 10.2.2, а исправили его в 10.2.4, которую я еще не пробовал.
В ближайшее время надеюсь попробовать воспроизвести баг, поменяв в дереве именно root. Спасибо за информацию.
Ceph страхует на случай падения какой-то части дисков или серверов. Если же по какому-то совпадению умирают все диски из одной плейсмент-группы (например, если политика настроена неправильно, и все диски находились в одной стойке, или если весь кластер находился в одном зале, куда прилетело бешеное напряжение, убив значительную часть дисков), то данные конечно пропадут. Или, как кто-то писал выше, если умирает часть дисков плейсмент-группы, и в момент ребалансировки умирают заодно и оставшиеся диски этой же группы, данные тоже уже не восстановить. Это не связано с Ceph, это все логично.
Но я подозреваю, что Вас интересуют именно случаи, когда развалился сам кластер по неведомым причинам, и как потом эти данные по кусочкам восстанавливать. В этом случае я пока не вижу никаких выходов, потому что не видел инструментов по склейке размазанных данных по кусочкам. Да и о таких случаях никто ничего подробно не пишет. Меня тоже интересует этот вопрос.
BlueStore очень вкусная штука судя по описаниям, она должна решить главную проблему производительности журналов, если я все правильно понял. Однако пока я не только не могу написать про нее статью, я даже ее пощупать не могу.
Пока я планирую написать статью (или две) по теме экспериментов на виртуалках, которые доступны каждому желающему на домашнем ПК.
Развалился прям кластер или данные потерялись? Второе вполне возможно, если вылетят все диски из одной плейсмент-группы. И если на них лежали блоки какого-нибудь RBD, которые являлись частью больших файлов (например образов виртуалок), то и остальные (живые) блоки из этого RBD станут скорее всего бесполезными.
а теперь смотрите, у Вас помер сервер, и ceph начинает ребалансить те самые 30 терабайт, ибо ему надо восстановить количество реплик.
Я это понимаю. Но если у вас упало 2 ноды из 5, то 30 терабайт будут ребаланситься между тремя нодами. А если упадет например 2 из 10, то те же 30 терабайт будут ребаланситься между 8 нодами, а это почти в 3 раза меньше нагрузки на конечные OSD.
Вашу мысль я понял, мы это учтем, если будем строить кластер. Но я думаю, это проблема не Ceph, а в принципе любой такой системы с автоматической ребалансировкой, ибо упирается то все в железо и повышенную нагрузку на него в момент отвала почти половины кластера.
Думаю, тут нужно проектировать кластер с учетом количества нод и дисков на них. Если хотите много дисков на ноду, то нужно либо больше нодов, чтобы в ребалансе того же количества данных участвовало больше дисков, распределяя то же количество нагрузки на бОльшее количество физических устройств, либо выставлять минимальный приоритет ребалансингу (при size=3, думаю, это можно себе позволить).
А как кластер чувствует себя в момент отвала OSD и как в момент отвала целой ноды? Мониторы на них же? Ноды в одной серверной? Снапшоты не используете?
Про erasure code не рассказал намеренно, поскольку не работал с ним. Если кому интересно, это метод вместо репликации данных (чем то похож на RAID5, только с другим алгоритмом). Позволяет хранить больше данных на том же количестве свободного места в кластере. Однако, как я понял, немного проигрывает в производительности методу репликации. Такой алгоритм можно использовать для хранилищ бекапов например.
Про BlueStore даже не слышал, спасибо за наводку, почитаю.
Вообще много чего еще стоит упомянуть из неприятного о ceph)
Буду благодарен, если поделитесь этими неприятностями с нами.
Потому что официальной документации верить нельзя?
RADOS — это ядро Ceph, без него кластер работать не будет.
RGW — всего лишь один из способов доступа клиентов к своим данным. Этот демон вообще опциональный.
Почему?
Я не знаю, это же не для всех очевидно. Но я предположу: каталог в ceph'e — это метаданные? Как и атрибуты, владелец, хардлинки и симлинки? Файлы — объекты, все остальное — метаданные.
Кому? Разработчикам Ceph, чтоб они у себя на сайте картинку поправили?
rgw — это не rados, об этом намекает картинка с сайта. rgw (rados gateway) лежит поверх rados. Это слой доступа к объектам rados, о чем дальше вы и говорите.
А вот это уже половина ответа на вопрос, который я действительно задавал. Спасибо. А про CephFS и 1 файл == 1 объект что скажете? Если я создам 10-гиговый файл, он будет лежать в виде жирного 10-гигового объекта?
А это не вы путаете абстракции? Нижний уровень — это rados, а rgw (как впрочем и rbd) лежит поверх rados. Это видно на схеме.
Я написал о том, что rbd (блочное устройство) хранит блоки в объектах по 4 мегабайта. Однако, если записать жирный объект напрямую в пул (минуя rbd), он никак не фрагментируется. Посему у меня и возник вопрос: CephFS фрагментирует файлы на объекты или 1 файл == 1 объект? Я спрашиваю, потому что я не работал с CephFS, ибо он не продакшен-реди.
Так а я и не спрашивал, где и в каком количестве лежит объект. Вы путаете уровни: я спрашивал про логический, вы отвечаете про физический. Физический уровень я могу легко посмотреть командой «ceph osd map rbd <object_name>», где будет видно в какой плейсмент-группе лежит объект, и по каким OSD эта группа размазана.
Это что касается блоков RBD. А не знаете, как дело обстоит с CephFS и RGW?
Вообще я наблюдал, что на OSD блоки RBD по умолчанию хранятся в виде объектов по 4 мегабайта. Однако, когда я пробовал записать файл 100 МБ непосредственно в пул в виде объекта (минуя RBD), Ceph никак его не фрагментировал, и я находил на OSD этот самый 100-мегабайтный объект.
Не знаете, как именно Ceph фрагментирует объекты?
и приводите ссылку на баг, где выполняете команду
разве это операция с монитором?
Так или иначе, на убунте 16.04.1 я свободно перемещал узлы и OSD по краш-дереву. Единственное что, я не помню, менял ли я именно root. Возможно, все мои манипуляции не выходили за рамки root=default. И увы, версию самого ceph я тоже не помню на тот момент (но подозреваю, что 10.2.2).
Однако, если почитать переписку, под Вашим багрепортом, становится понятно, что баг еще жив на 10.2.2, а исправили его в 10.2.4, которую я еще не пробовал.
В ближайшее время надеюсь попробовать воспроизвести баг, поменяв в дереве именно root. Спасибо за информацию.
Но я подозреваю, что Вас интересуют именно случаи, когда развалился сам кластер по неведомым причинам, и как потом эти данные по кусочкам восстанавливать. В этом случае я пока не вижу никаких выходов, потому что не видел инструментов по склейке размазанных данных по кусочкам. Да и о таких случаях никто ничего подробно не пишет. Меня тоже интересует этот вопрос.
Пока я планирую написать статью (или две) по теме экспериментов на виртуалках, которые доступны каждому желающему на домашнем ПК.
Развалился прям кластер или данные потерялись? Второе вполне возможно, если вылетят все диски из одной плейсмент-группы. И если на них лежали блоки какого-нибудь RBD, которые являлись частью больших файлов (например образов виртуалок), то и остальные (живые) блоки из этого RBD станут скорее всего бесполезными.
Я это понимаю. Но если у вас упало 2 ноды из 5, то 30 терабайт будут ребаланситься между тремя нодами. А если упадет например 2 из 10, то те же 30 терабайт будут ребаланситься между 8 нодами, а это почти в 3 раза меньше нагрузки на конечные OSD.
Вашу мысль я понял, мы это учтем, если будем строить кластер. Но я думаю, это проблема не Ceph, а в принципе любой такой системы с автоматической ребалансировкой, ибо упирается то все в железо и повышенную нагрузку на него в момент отвала почти половины кластера.
Думаю, тут нужно проектировать кластер с учетом количества нод и дисков на них. Если хотите много дисков на ноду, то нужно либо больше нодов, чтобы в ребалансе того же количества данных участвовало больше дисков, распределяя то же количество нагрузки на бОльшее количество физических устройств, либо выставлять минимальный приоритет ребалансингу (при size=3, думаю, это можно себе позволить).
Если не секрет, какими были size и min_size?
Про erasure code не рассказал намеренно, поскольку не работал с ним. Если кому интересно, это метод вместо репликации данных (чем то похож на RAID5, только с другим алгоритмом). Позволяет хранить больше данных на том же количестве свободного места в кластере. Однако, как я понял, немного проигрывает в производительности методу репликации. Такой алгоритм можно использовать для хранилищ бекапов например.
Про BlueStore даже не слышал, спасибо за наводку, почитаю.
Буду благодарен, если поделитесь этими неприятностями с нами.
Вот тут есть рекомендации разработчиков