Комментарии 67
Кластер можно поднять на любом железе в обычной сети, потратив минимум времени и сил, при этом Ceph сам будет заботиться о сохранности данных, предпринимая необходимые меры в случае сбоев железа.
Я бы настолько категорично утверждать не стал. Гигабитную сеть ceph с удовольствием кладет на обе лопатки во время перебалансировки. Между OSD нужно тянуть 10 гигабит и никак иначе. Иначе получится крайне шаткая конструкция.
С другой стороны, поведение этой шаткой конструкции на время репликации является довольно мягким — тормозит, не, не так, ТОРМОЗИТ, но виртуалки ползут хоть как-то. Это гораздо приятнее внезапного визита STONITH на OCFS, который перезагружает весь кластер к такой-то матери, в случае малейших сетевых проблем.
Личный опыт, прод — 9 узлов, 36 osd, гигабитная клиентская и гигабитная кластерная сеть, size=1 для горячих данных и size=3 для образов ОС виртуалок, размер 9Т. Доступ через RBD.
Личный опыт, лаб — 2 узла, 12 osd, сеть 10G, size=2, доступ через ceph-fs + dokan. Клиенты — Windows 2012. Вполне неплохо бегало.
У меня нет технической возможности собирать как у вас кластера с SSD и 10G. Мой маленький (пока) кластер обладает 1Gb/s на public network в сторону клиента и 1Gb/s — private network. Да, это скудно, но суровая жизнь пока нагнула так. Планируется расширение ещё серверами, дополнительная карта для увеличения скорости хотя до 2Gb/s и если всё сложится, то и SSD под журнал.
Нет отрицательных отзывов за годы работы, рад что внедрили в него, поверив в него.
Нет отрицательных отзывов за годы работы, рад что внедрили в него, поверив в него.
Спасибо за статью!
Возник вопрос. У Cepth есть веб интерфейс для обзора файлов в хранилище и администрирования всего кластера?
Для мониторинга и администрирования есть Calamari
А для обзора файлов в хранилище что посоветуете? Например, как в Amozon S3, где можно посмотреть файлы и скачать их если нужно.
Там же три пути доступа к хранилищу — нативный (RADOS), как к блочным утройствам (RBD) и как к ФС c POSIX-семантикой.
Для первого — делать средствами своего приложения, КМК. Чтобы работало с учетом прикладного аспекта.
Для второго — мне хватает заклинания
Для третьего — ваш любимый файловый менеджер. Я люблю mc, а вы?
Для первого — делать средствами своего приложения, КМК. Чтобы работало с учетом прикладного аспекта.
Для второго — мне хватает заклинания
rbd ls | grep XXX | less
Для третьего — ваш любимый файловый менеджер. Я люблю mc, а вы?
Или свое написать, там почти все доступно через REST
Спасибо за статью, ещё хотелось бы увидеть статью по способам мониторинга и тюнинга системы, а так же операцию ввода\вывода нового железа из\в класстер
Написано весело — без точек отказа, мол все хорошо.
Забыли только упомянуть — не быстро.
Но я бы посоветовал обратить внимание на доводы из этой статьи:
https://habrahabr.ru/company/oleg-bunin/blog/313364/
https://habrahabr.ru/company/oleg-bunin/blog/313330/
Для решения проблем CEPH-подобных можно, к примеру, сделать с единой точкой отказа (координатор), которая лишь частично ограничивает кластер в случае выхода этой точки отказа из строя.
Я про то, что есть и альтернативный взгляд на эту тематику.
Забыли только упомянуть — не быстро.
Но я бы посоветовал обратить внимание на доводы из этой статьи:
https://habrahabr.ru/company/oleg-bunin/blog/313364/
https://habrahabr.ru/company/oleg-bunin/blog/313330/
Для решения проблем CEPH-подобных можно, к примеру, сделать с единой точкой отказа (координатор), которая лишь частично ограничивает кластер в случае выхода этой точки отказа из строя.
Я про то, что есть и альтернативный взгляд на эту тематику.
Забыли только упомянуть — не быстро.
1. не забыли
2. у кого-то быстро
А о каких доводах Вы говорите? Мне сегодня некогда читать приведенные статьи к сожалению.
Отдельное спасибо за прекрасные схемы.
А можно получить небольшую консультацию. ы тут строим небольшой вычеслительный кластер. И рассматривали CEPH как один из вариантов. У нас следующие требования. Оперативное хранилище порядка 40TB. и около 26 нод. Мы думали совмещать, тоесть хостить вычисления и ceph osd на одной ноде. Но нас отговаривают от решения ceph тем что ему на 1tb данных нужно порядка 1,5 ГБ ram на ноде что при наших обемах нуочень приемлемо.
Предлогают решения поднять отдельные серваки с хранилищем и вобще поставить туда pNFS
Может я в чемто не прав?
Предлогают решения поднять отдельные серваки с хранилищем и вобще поставить туда pNFS
Может я в чемто не прав?
По производительности не могу ничего сказать, я писал эту статью с целью получить фидбеки о производительности от пользователей в коментах.
Вот тут есть рекомендации разработчиков
Вот тут есть рекомендации разработчиков
Арифметика показывает, что 40/26 = условно 2 терабайта на ноду. При size=3 — это 6 терабайт на ноду или 9 Гб RAM.
Учитывая, что современные серверы несут на борту от 64Гб RAM, отдать шестую часть под хранилище — не страшно. Или у вас ноды — музейные?
Учитывая, что современные серверы несут на борту от 64Гб RAM, отдать шестую часть под хранилище — не страшно. Или у вас ноды — музейные?
Нет ноды не музейные, но вот рам очень важные ресурс. Так-как основное нагрузочное приложение будет выедать подчистую, то чтобы OOMKiller не пребил CEPH предлогают запустить CEPH в гипервизоре.
А вот основное приложение недолжно быть под гипервизором, так-как туда еще придется прокидывать GPU
А вот основное приложение недолжно быть под гипервизором, так-как туда еще придется прокидывать GPU
Так, засуньте свое приложение в cgroup (что я настоятельно рекомендую делать со всеми числодробилками), ограничьте ему RAM чем-нибудь разумным.
ceph osd и так запускается в рамках systemd, и тоже попадает в cgroup, так что ему нужно просто задать MemoryLimit
Тащить сюда для изоляции гипервизор — немножко из пушки по микробам.
ceph osd и так запускается в рамках systemd, и тоже попадает в cgroup, так что ему нужно просто задать MemoryLimit
Тащить сюда для изоляции гипервизор — немножко из пушки по микробам.
У нас небольшой кластер из трёх нод на 6ТБ (по два ТБ на каждом). Всё подключенно через 10Гб/с сеть, скорость получается 630-650МБ/с.
К этому кластеру подключен сервер, на котором крутится докер (тоже через 10Гб/с), докер пишет данные на кластер. Для этого используем RBD. Так как и там и там были SSD, то разницы не было. Уже примерно год работает, полёт нормальный.
Проблемной оказалась СеphFS, хотели сперва чтобы докер через неё писал, но если на неё писать много маленьких файлов и большим количеством (У нас это делал Jenkins), то скорость падает до 120-150кб/с. Так и не смогли решить, поэтому RBD.
Сейчас пытаюсь прикрутить к ней openstack, точнее glance. Но пока не очень.
К этому кластеру подключен сервер, на котором крутится докер (тоже через 10Гб/с), докер пишет данные на кластер. Для этого используем RBD. Так как и там и там были SSD, то разницы не было. Уже примерно год работает, полёт нормальный.
Проблемной оказалась СеphFS, хотели сперва чтобы докер через неё писал, но если на неё писать много маленьких файлов и большим количеством (У нас это делал Jenkins), то скорость падает до 120-150кб/с. Так и не смогли решить, поэтому RBD.
Сейчас пытаюсь прикрутить к ней openstack, точнее glance. Но пока не очень.
А как кластер чувствует себя в момент отвала OSD и как в момент отвала целой ноды? Мониторы на них же? Ноды в одной серверной? Снапшоты не используете?
Cегодня как-раз все три перезагружал (из-за openstack'a). Просидания производительности я не заметил, но я специально не замерял, хотя я думаю, что при большом размере кластера что-то такое будет. Хотя опять же, если на одной ноде не будет много OSD, то будет нормально. У меня при двух минутах простоя и 650МБ/с скорости, всё очень быстро синхронизироваллось.
Мониторы стоят на всех трёх. Спапшоты хотели использовать, чтобы потом с них делать бэкапы, но там тоже был какой-то косяк (уже не помню, но точно не технический) и теперь делаем через Btrfs, который стоит на RBD.
Мониторы стоят на всех трёх. Спапшоты хотели использовать, чтобы потом с них делать бэкапы, но там тоже был какой-то косяк (уже не помню, но точно не технический) и теперь делаем через Btrfs, который стоит на RBD.
НЛО прилетело и опубликовало эту надпись здесь
Согласен с каждым словом.
Про erasure code не рассказал намеренно, поскольку не работал с ним. Если кому интересно, это метод вместо репликации данных (чем то похож на RAID5, только с другим алгоритмом). Позволяет хранить больше данных на том же количестве свободного места в кластере. Однако, как я понял, немного проигрывает в производительности методу репликации. Такой алгоритм можно использовать для хранилищ бекапов например.
Про BlueStore даже не слышал, спасибо за наводку, почитаю.
Буду благодарен, если поделитесь этими неприятностями с нами.
Про erasure code не рассказал намеренно, поскольку не работал с ним. Если кому интересно, это метод вместо репликации данных (чем то похож на RAID5, только с другим алгоритмом). Позволяет хранить больше данных на том же количестве свободного места в кластере. Однако, как я понял, немного проигрывает в производительности методу репликации. Такой алгоритм можно использовать для хранилищ бекапов например.
Про BlueStore даже не слышал, спасибо за наводку, почитаю.
Вообще много чего еще стоит упомянуть из неприятного о ceph)
Буду благодарен, если поделитесь этими неприятностями с нами.
НЛО прилетело и опубликовало эту надпись здесь
Все правильно.
Думаю, тут нужно проектировать кластер с учетом количества нод и дисков на них. Если хотите много дисков на ноду, то нужно либо больше нодов, чтобы в ребалансе того же количества данных участвовало больше дисков, распределяя то же количество нагрузки на бОльшее количество физических устройств, либо выставлять минимальный приоритет ребалансингу (при size=3, думаю, это можно себе позволить).
Если не секрет, какими были size и min_size?
Думаю, тут нужно проектировать кластер с учетом количества нод и дисков на них. Если хотите много дисков на ноду, то нужно либо больше нодов, чтобы в ребалансе того же количества данных участвовало больше дисков, распределяя то же количество нагрузки на бОльшее количество физических устройств, либо выставлять минимальный приоритет ребалансингу (при size=3, думаю, это можно себе позволить).
Если не секрет, какими были size и min_size?
НЛО прилетело и опубликовало эту надпись здесь
а теперь смотрите, у Вас помер сервер, и ceph начинает ребалансить те самые 30 терабайт, ибо ему надо восстановить количество реплик.
Я это понимаю. Но если у вас упало 2 ноды из 5, то 30 терабайт будут ребаланситься между тремя нодами. А если упадет например 2 из 10, то те же 30 терабайт будут ребаланситься между 8 нодами, а это почти в 3 раза меньше нагрузки на конечные OSD.
Вашу мысль я понял, мы это учтем, если будем строить кластер. Но я думаю, это проблема не Ceph, а в принципе любой такой системы с автоматической ребалансировкой, ибо упирается то все в железо и повышенную нагрузку на него в момент отвала почти половины кластера.
По теме:
Есть кластер 4 ноды. В каждой 2 SSD (один:os,mon второй: jornal) 3 hdd (WD RAID edition SATA) процы E5-1650.
Фактор репликации 3.
Proxmox с его дефолтными настройками ceph. Ничего не подкручивал.
Терминалы с 2008 около 150 пользователей всего. Полёт хороший. 350-400 iops на виртуалку под нагрузкой.
Решение имеет сравнительно низкую цену при приемлемых для работы показателях.
Есть кластер 4 ноды. В каждой 2 SSD (один:os,mon второй: jornal) 3 hdd (WD RAID edition SATA) процы E5-1650.
Фактор репликации 3.
Proxmox с его дефолтными настройками ceph. Ничего не подкручивал.
Терминалы с 2008 около 150 пользователей всего. Полёт хороший. 350-400 iops на виртуалку под нагрузкой.
Решение имеет сравнительно низкую цену при приемлемых для работы показателях.
Правильно ли я понял, у Вас по монитору на каждой ноде? То бишь 4 штуки? А SSD выделены под ось с монитором и под журналы?
Да — каждая нода — монитор.
Из минусов — если второй SSD накроется (на котором журналы) то отвалятся 3 OSD :-( — все, которые на ноде.
Ещё забыл упомянуть, что сеть для ceph 10гигабитная.
Из минусов — если второй SSD накроется (на котором журналы) то отвалятся 3 OSD :-( — все, которые на ноде.
Ещё забыл упомянуть, что сеть для ceph 10гигабитная.
У вас получается четное количество мониторов, сплитбрейна не боитесь? Зачем под ось и монитор SSD?
Зачем под ось и монитор SSD? — Выполнял рекомендации ProxMox. На их сайте гайд, в котором сказано, что mon должен быть быстрым и SSD рекомендуют.
Датастор подсоединён по rbd.
Сплитбрейна не боитесь? — А об этом совершенно не подумал. Никак… В том бешеном угаре, когда за неделю с нуля поднять из состояния «в коробках» до виртуалки смигрированы от хостера и работают…
Датастор подсоединён по rbd.
Сплитбрейна не боитесь? — А об этом совершенно не подумал. Никак… В том бешеном угаре, когда за неделю с нуля поднять из состояния «в коробках» до виртуалки смигрированы от хостера и работают…
В ceph не бывает сплитбрейнов мониторов. При 4-х мониторах должно всегда работать не менее 3-х, иначе все операции в кластере приостанавливаются.
Кстати, о том, что повышать отказоустойчивость можно не только простым дублированием данных на разных OSD, но и организацией из OSD аналогов RAID5/6 — в ceph так и не додумались? Вроде-бы были-же какие-то телодвижения в эту сторону?
Вы не первый, кто спрашивает. Почитайте ветку коментов дальше, там будет про это.
del
Что-то не попадалось еще статей о том как ceph правильно бэкапить. Вот помню, что он разваливался в труху у одного облачного провайдера и у самих авторов цеф недавно. Так, что данные было совсем не восстановить.
Есть ли методы как правильно бэкапить логику?
Есть ли методы как правильно бэкапить логику?
Очень скверно. Есть подробности?
Развалился прям кластер или данные потерялись? Второе вполне возможно, если вылетят все диски из одной плейсмент-группы. И если на них лежали блоки какого-нибудь RBD, которые являлись частью больших файлов (например образов виртуалок), то и остальные (живые) блоки из этого RBD станут скорее всего бесполезными.
Развалился прям кластер или данные потерялись? Второе вполне возможно, если вылетят все диски из одной плейсмент-группы. И если на них лежали блоки какого-нибудь RBD, которые являлись частью больших файлов (например образов виртуалок), то и остальные (живые) блоки из этого RBD станут скорее всего бесполезными.
В development идет 11 версия (Кракен), там что-то вынесли в новый сервис менеджмента (Вроде как для улучшения общего контроля за кластером). Еще вышел очень интересный проект petasan.org на ceph. Из коробки собирается кластер мин за 5 (все на web) там же управление, плюс готовый для использования iscsi. Смотрю теперь за его развитием.
У себя используем для бэкапов и файлового сервера, пока вроде всем устраивает. Cеть — две по 1Gb.
У себя используем для бэкапов и файлового сервера, пока вроде всем устраивает. Cеть — две по 1Gb.
Спасибо за статью, все очень наглядно показали и объянили..
Грядет новый backend для ceph — bluestore, в новых версиях его сделают backend'ом по дефолту.
Было бы очень интересно почитать про него в том же формате, что и в этой статье. :)
https://www.sebastien-han.fr/blog/2016/03/21/ceph-a-new-store-is-coming/
BlueStore очень вкусная штука судя по описаниям, она должна решить главную проблему производительности журналов, если я все правильно понял. Однако пока я не только не могу написать про нее статью, я даже ее пощупать не могу.
Пока я планирую написать статью (или две) по теме экспериментов на виртуалках, которые доступны каждому желающему на домашнем ПК.
Пока я планирую написать статью (или две) по теме экспериментов на виртуалках, которые доступны каждому желающему на домашнем ПК.
Подскажите, а что будет работать в Виндовс? Задача следующая - есть организация с примерно 300 офисных компьютеров разнесенных территориально по нескольким независимым офисам. Все офисы соединены VPN - 150-200 Mбите/сек. На каждом офисном ПК специально есть от 500- до 1000 Гб свободного места.
Есть ли како то решение чтобы это свободное место использовать под распределенное хранилище с 3-4 репликацией (резервированием).
Почему я акцентировал на "специально есть от 500- до 1000 Гб свободного места" - потому что мы его специально заложили под задачи резервного копирования, но пока (уже 10 лет) делаем это вручную. То есть у нас есть примерно 20-25 Тб архив (который по чуть чуть еще растет), и мы вручную раскидываем его тома на свободное место офисных компов (сейчас с репликацией 8-10 копий). 10 лет назад, когда архив был поменьше - то репликацию доводили и до 20-30 копий. В принципе нас устраивает и ручное управление копиями, и как показала практика этот способ в целом оказался очень надежным даже на длинном промежутке времени. Если на каком то офисном диск и ломался, то меняли и закидывали на него снова как было до поломки. За 10 лет не было ни разу, чтобы выходили из строя более 1 диска одновременно (из почти 300). Сейчас если иногда и выходят из строя (в среднем 2 диска в год), то уже меняем на 2-3Тб. Сами диски в офисных компах никак не мешают работающим на этих компах. многие диски вообще программно отключаем когда не нужны.
Но архив постоянно увеличивается, к некоторым данным стал нужен быстрый доступ с изменением, и может есть какое то решение автоматизирующее этот алгоритм с проверкой целостности и надежности.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью.
У себя используем Ceph из где-то 50 OSD на гигабитных сетях под бэкапы. Впечатления только положительные.
У себя используем Ceph из где-то 50 OSD на гигабитных сетях под бэкапы. Впечатления только положительные.
а поделитесь впечатлениями, кто его восстанавливал? Ковырял при падениях… Потому что все прекрасно, как говорится, и про страховые компании много удобного рассказывают, пока не наступают страховые случаи и не нужно получать обратно деньги/данные.
Ceph страхует на случай падения какой-то части дисков или серверов. Если же по какому-то совпадению умирают все диски из одной плейсмент-группы (например, если политика настроена неправильно, и все диски находились в одной стойке, или если весь кластер находился в одном зале, куда прилетело бешеное напряжение, убив значительную часть дисков), то данные конечно пропадут. Или, как кто-то писал выше, если умирает часть дисков плейсмент-группы, и в момент ребалансировки умирают заодно и оставшиеся диски этой же группы, данные тоже уже не восстановить. Это не связано с Ceph, это все логично.
Но я подозреваю, что Вас интересуют именно случаи, когда развалился сам кластер по неведомым причинам, и как потом эти данные по кусочкам восстанавливать. В этом случае я пока не вижу никаких выходов, потому что не видел инструментов по склейке размазанных данных по кусочкам. Да и о таких случаях никто ничего подробно не пишет. Меня тоже интересует этот вопрос.
Но я подозреваю, что Вас интересуют именно случаи, когда развалился сам кластер по неведомым причинам, и как потом эти данные по кусочкам восстанавливать. В этом случае я пока не вижу никаких выходов, потому что не видел инструментов по склейке размазанных данных по кусочкам. Да и о таких случаях никто ничего подробно не пишет. Меня тоже интересует этот вопрос.
Безусловно, если умирают обе копии данных, неважно где они располагаются, ситуация мало приятная и сложная. Хотя из дисков достаются данные компаниями по восстановлению, через доноров, и собирается заново RAID. Тут все отработано и возможно, зависит от суммы и сложности. А вот что делать с Ceph не очень понятно. Может amarao что-нибудь прояснит?
Ну, вообще, можно получить карту pg, блоков в pg, ковыряться в дисках. Сами диски (обычно) xfs, так что сначала восстанавливаем xfs, потом данные с неё. Но это не сценарий использования ceph'а.
А чтобы развалить кластер достаточно сделать какую-нибудь мелкую глупость с монитором. См. мой недавний багрепорт, который в апстриме пофиксили, а в бубунте всё ещё нет:
https://bugs.launchpad.net/bugs/1597411
Одна команда — и весь кластер лежит.
А чтобы развалить кластер достаточно сделать какую-нибудь мелкую глупость с монитором. См. мой недавний багрепорт, который в апстриме пофиксили, а в бубунте всё ещё нет:
https://bugs.launchpad.net/bugs/1597411
Одна команда — и весь кластер лежит.
А чтобы развалить кластер достаточно сделать какую-нибудь мелкую глупость с монитором.
и приводите ссылку на баг, где выполняете команду
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. Спасибо за информацию.
Там есть ссылка на github, где подробно обсуждается бага. Надо иметь специальный crush map (tree, вместо straw2). Проще всего — поднимите мониторы из приложенного архива мониторовых данных.
Это баг в коде мониторов, которые обрабатывают перемещение. Вместо того, чтобы его обработать как положено, оно сваливается в сегфолт. Т.к. код одинаковый на всех мониторах, и данные одинаковые, он одинаково сегфолтится. (Я этот баг записал в hatelist к любым кластеризованным системам).
Это баг в коде мониторов, которые обрабатывают перемещение. Вместо того, чтобы его обработать как положено, оно сваливается в сегфолт. Т.к. код одинаковый на всех мониторах, и данные одинаковые, он одинаково сегфолтится. (Я этот баг записал в hatelist к любым кластеризованным системам).
Ну, вообще, можно получить карту pg, блоков в pg, ковыряться в дисках.
Это что касается блоков RBD. А не знаете, как дело обстоит с CephFS и RGW?
Вообще я наблюдал, что на OSD блоки RBD по умолчанию хранятся в виде объектов по 4 мегабайта. Однако, когда я пробовал записать файл 100 МБ непосредственно в пул в виде объекта (минуя RBD), Ceph никак его не фрагментировал, и я находил на OSD этот самый 100-мегабайтный объект.
Не знаете, как именно Ceph фрагментирует объекты?
Вы путаете абстракции. Нижний уровень — rgw. Точнее, rados. На его объектах уже построен rbd и cephfs, т.е. процесс выковыривания будет одинаковым в любом случае.
cephfs — не продакшен-реди, так что вопросы восстановления данных там пока рано обсуждать. Подозреваю веселье с метаданными.
Ваш эксперимент выглядит странно, потому что вы работали с объектами. Очевидно, что объект как положили, так он и лежит. А вот в каком количестве pg он лежит — это уже решает crush map. Точнее объяснить не могу, потому что вы терминологию путаете. Перечитайте про устройство RBD/rados/pg в документации.
cephfs — не продакшен-реди, так что вопросы восстановления данных там пока рано обсуждать. Подозреваю веселье с метаданными.
Ваш эксперимент выглядит странно, потому что вы работали с объектами. Очевидно, что объект как положили, так он и лежит. А вот в каком количестве pg он лежит — это уже решает crush map. Точнее объяснить не могу, потому что вы терминологию путаете. Перечитайте про устройство RBD/rados/pg в документации.
Вы путаете абстракции. Нижний уровень — rgw. Точнее, rados.
А это не вы путаете абстракции? Нижний уровень — это rados, а rgw (как впрочем и rbd) лежит поверх rados. Это видно на схеме.
Я написал о том, что rbd (блочное устройство) хранит блоки в объектах по 4 мегабайта. Однако, если записать жирный объект напрямую в пул (минуя rbd), он никак не фрагментируется. Посему у меня и возник вопрос: CephFS фрагментирует файлы на объекты или 1 файл == 1 объект? Я спрашиваю, потому что я не работал с CephFS, ибо он не продакшен-реди.
А вот в каком количестве pg он лежит — это уже решает crush map
Так а я и не спрашивал, где и в каком количестве лежит объект. Вы путаете уровни: я спрашивал про логический, вы отвечаете про физический. Физический уровень я могу легко посмотреть командой «ceph osd map rbd <object_name>», где будет видно в какой плейсмент-группе лежит объект, и по каким OSD эта группа размазана.
rgw не «лежит» поверх радоса, это и есть rados, один-в-один. Фрагментацию дисков делает только rbd и только для целей оптимизации partial writes, т.к. для object storage изменение части блоков на ходу — это нестандартная схема.
В rgw нет файлов, есть объекты. Это те самые объекты, которые в ceph'е и есть, без дополнительного слоя трансляции. RGW к ним только REST API делает.
В rgw нет файлов, есть объекты. Это те самые объекты, которые в ceph'е и есть, без дополнительного слоя трансляции. RGW к ним только REST API делает.
rgw не «лежит» поверх радоса, это и есть rados, один-в-один
rgw — это не rados, об этом намекает картинка с сайта. rgw (rados gateway) лежит поверх rados. Это слой доступа к объектам rados, о чем дальше вы и говорите.
В rgw нет файлов, есть объекты. Это те самые объекты, которые в ceph'е и есть, без дополнительного слоя трансляции. RGW к ним только REST API делает.
А вот это уже половина ответа на вопрос, который я действительно задавал. Спасибо. А про CephFS и 1 файл == 1 объект что скажете? Если я создам 10-гиговый файл, он будет лежать в виде жирного 10-гигового объекта?
Если бы мне было на 10 лет меньше, я бы ввязался в спор, объясняя устройство rgw. Сейчас — да пожалуйста, это ваши проблемы.
в cephfs ключевое — блокировки и метаданные, там, очевидно, не может быть соответствия 1-в-1 объектам ceph'а (что такое «каталог» в ceph'е?)
в cephfs ключевое — блокировки и метаданные, там, очевидно, не может быть соответствия 1-в-1 объектам ceph'а (что такое «каталог» в ceph'е?)
там, очевидно, не может быть соответствия 1-в-1 объектам ceph'а
Почему?
что такое «каталог» в ceph'е?
Я не знаю, это же не для всех очевидно. Но я предположу: каталог в ceph'e — это метаданные? Как и атрибуты, владелец, хардлинки и симлинки? Файлы — объекты, все остальное — метаданные.
Если бы мне было на 10 лет меньше, я бы ввязался в спор, объясняя устройство rgw.
Кому? Разработчикам Ceph, чтоб они у себя на сайте картинку поправили?
> Кому? Разработчикам Ceph, чтоб они у себя на сайте картинку поправили?
Я слабо представляю внутренне устройство ceph, но мне кажется что в данном споре лучше оперировать ссылками на строки в исходниках, чем картинками на сайте.
Я слабо представляю внутренне устройство ceph, но мне кажется что в данном споре лучше оперировать ссылками на строки в исходниках, чем картинками на сайте.
мне кажется что в данном споре лучше оперировать ссылками на строки в исходниках, чем картинками на сайте.
Потому что официальной документации верить нельзя?
RADOS — это ядро Ceph, без него кластер работать не будет.
RGW — всего лишь один из способов доступа клиентов к своим данным. Этот демон вообще опциональный.
cephfs — не продакшен-реди
В описании Infernalis вроде как утверждается обратное.
Исправляюсь.
http://docs.ceph.com/docs/jewel/cephfs/
Плюс ссылка на http://docs.ceph.com/docs/jewel/cephfs/early-adopters/
«This pages provides guidance for early adoption of CephFS by users with an appetite for adventure. „
Интересный production-ready без fsck и appetite for adventure.
http://docs.ceph.com/docs/jewel/cephfs/
Important
CephFS currently lacks a robust ‘fsck’ check and repair function. Please use caution when storing important data as the disaster recovery tools are still under development. For more information about using CephFS today, see CephFS for early adopters.
Плюс ссылка на http://docs.ceph.com/docs/jewel/cephfs/early-adopters/
«This pages provides guidance for early adoption of CephFS by users with an appetite for adventure. „
Интересный production-ready без fsck и appetite for adventure.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с хранилищем Ceph в картинках