LINUX.ORG.RU

Ceph 0.94 - распределенное отказоустойчивое хранилище данных

 block storage,


5

3

7 апреля стала доступна новая версия отказоустойчивого распределенного хранилища данных Ceph.

Ceph — это масштабируемое петабайтное хранилище с открытым исходным кодом, в основе которого лежит принцип объединения дисковых пространств серверов в единое объектное хранилище, что позволяет реализовать гибкую многократную псевдослучайную избыточность данных. Ceph предоставляет на выбор три различных интерфейса для работы с хранилищем:

  • RADOS Gateway (RGW) — S3- и Swift-совместимый RESTful интерфейс;
  • RADOS block device (RBD) — блочное устройство с поддержкой тонкого роста и снэпшотами;
  • Ceph FS — распределенная POSIX-совместимая файловая система.

Для горячих голов: CephFS пока ещё не рекомендуется использовать для хранения информации, которую будет жалко потерять. :)

Основные изменения:

  • увеличено быстродействие RADOS: в OSD (Object Storage Daemon) и в библиотеку librados внесён ряд улучшений, направленных на улучшение работы на flash-накопителях, а также на улучшение параллелизма и масштабируемости системы на быстрых узлах;
  • добавлено версионирование объектов RGW: добавлена поддержка S3 obect versioning API;
  • добавлено шаридирование бакетов RGW: индексы бакетов теперь поддерживают разнесение на разные узлы, что увеличивает быстродействие для больших бакетов;
  • добавлены карты объектов RBD: создан механизм, отслеживающий аллокации частей образов блочных устройств, что увеличивает производительность операций клонирования, удаления и др.
  • много улучшений в механизме создания снэпшотов CephFS;
  • много улучшений направленных на повышение скорости и стабильности в утилитах восстановления и диагностики CephFS;
  • улучшения в CRUSH*): добавлен новый алгоритм (straw2), который позволяет снизить количество миграций при переконфигурировании кластера.

*) CRUSH - Controlled Replication Under Scalable Hashing; алгоритм определяющий распределение данных по узлам и, соответственно, их извлечение.

исходный код

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: INFOMAN (всего исправлений: 2)

Ответ на: комментарий от tailgunner

Может для построения распределённого архива или системы документооборота с метаданными, полнотекстовым индексированием и WORM. Правда статус WORM тикета за 2013 год не вселяет оптимизма.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от JaM

всего. Пула 3 стандартных - data, metadata и rbd. Ceph старенький у меня - 0.67.9, планирую обновляться

Pinkbyte ★★★★★
()
Ответ на: комментарий от tailgunner

Для хранения образов?

например, но не только, для дисков виртуалок тоже используется

shty ★★★★★
() автор топика
Ответ на: комментарий от Marvin

Но у самого ceph архитектурные ограничения в производительности, не отключаемый журнал

Зачем так врать? Почитайте документацию по сабжу внимательнее. Все зависит от бекенда, который используется: с btrfs журнал не используется, с KeyValue - тоже. Вы можете использовать cache tiering на ssd. Вообще журнал - это фича.

Были проблемы с read path, когда один OSD не мог выдать больше 3-3.5К IOPS на 4kb блоках: в последних трёх крупных релизах сильно фиксилась данная проблема. Попутно фиксят и оптимизируют write path. SunDisk, активно коммитящий в Ceph, выпустил all flash storage на Ceph.

Сейчас на RR 4кб, в HAMMER один OSD может выдавать больше 20к IOPS. Правда ценой потребления CPU - в all flash ноды надо ставить мощные CPU с большим кол-вом ядер.

Что касается надежности ceph то есть грустная история взлета и падения сервиса cloudmouse.

С cloudmouse - ещё не известно, где проблемы. Есть мнение, что мышки не осиляторы и не понимают в ceph.

Ceph - довольно сложный, можно легко напартачить с CRUSH rules, необходимо понимать как и с чем работает. Зато Ceph даёт большую гибкость.

anonymous
()
Ответ на: комментарий от tailgunner

Для хранения образов? Окей, но там огрызок интерфейса ФС создает REST.

Для всего. Вообще всё общение там - через libvirt, который умеет ceph. VM-ки не создаются как файл на файловом хранилище, а пробрасывается RBD устройство.

anonymous
()
Ответ на: комментарий от anonymous

VM-ки не создаются как файл на файловом хранилище, а пробрасывается RBD устройство.

Ну а поверх этого RBD создается какая-то ФС.

tailgunner ★★★★★
()
Ответ на: комментарий от Pinkbyte

А как с производительностью? Если так мало данных, делал исключительно для отказоустойчивости?

anonymous
()
Ответ на: комментарий от Marvin

Глянул краем глаза ридми шипдога, что за зверь такой.. Дык, оно тока под КЕМУ заточено штоле? Какой тогда смысол?

Indexator ★★★
()
Ответ на: комментарий от Indexator

Глянул краем глаза ридми шипдога, что за зверь такой.. Дык, оно тока под КЕМУ заточено штоле? Какой тогда смысол?

Собачку умеет libvirt, а это значит - что её умеет OpenStack с KVM. И другие приложения, работающие через libvirt.

Для точности: что-то отличное от Linux/KVM (говорю про vmware, azure pack (HyperV), Xen) не умеют ни gluster, ни ceph, ни собаку. Умеют только что-то своё или унылый ISCSI/NFS.

anonymous
()
Ответ на: комментарий от anonymous

Да. Внутренняя ФС VM-ки.

или то, что туда положит самое приложение.

anonymous
()
Ответ на: комментарий от anonymous

И кому верить?

А почитать дальше глаза не опускаются?

Ceph block storage давно prodaction ready.

anonymous
()

не думал что у регистрантов так бомбанет

но я всё еще не получил вменяемого ответа

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

CephFS пока ещё не рекомендуется использовать для хранения информации, которую будет жалко потерять.

http://www.redhat.com/en/technologies/storage/ceph «Enterprise readiness» И кому верить?

никому не верить :)
и очевидно же Ceph Storage != 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.

shty ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Что не так?. Ceph Storage - Enterprise ready, CephFS - нет.

JaM
()
Ответ на: комментарий от shty

пишут уже можно пробовать, но пока не стоит хранить критические данные, то есть дело движется

Ну так пускай админы локалхостов и пробуют. А пока что в продакшине glusterfs наше фсё.

iron ★★★★★
()
Ответ на: комментарий от shty

мне в этой теме 5 раз ответили, я каждый перечитал

если ты не понял о чем я, я выделю:

я всё еще не получил вменяемого ответа

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

Да, исключительно ради отказоустойчивости. Производительность у меня упирается в основном в сеть - ноды условно объединены в 2 «датацентра»(в терминологии Ceph), ибо они разнесены географически. 3 ноды - в одном, 3 в другом. Между «датацентрами» линк - максимум 100 мегабит/сек, иногда сильно меньше. Внутри «датацентров» - 1 Гбит/сек. Репликация в CRUSH настроена в режиме - хранить по одной копии в каждом датацентре(в остальном выбранная нода не имеет значения).

Датацентры я пишу не зря в кавычках - это всё по большой части наколенщина, но это лучшее из того, что я пробовал. DRBD уж очень черезжопно масштабируется, не его это уровень ИМХО. Gluster - не блещет скоростью.

А мне нужна как кластерная ФС, так и блочные устройства, не привязанные к одной физической машине. RBD и CephFS тут очень сильно подошли.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от anonymous

Ceph - довольно сложный, можно легко напартачить с CRUSH rules, необходимо понимать как и с чем работает. Зато Ceph даёт большую гибкость.

Плюсую. Достаточно много времени убил на чтение документации к CRUSH, когда понял как реализовать то, что мне нужно, был искренне поражен гибкостью правил.

Pinkbyte ★★★★★
()
Ответ на: комментарий от reprimand

а я тебе уже сказал:

не тупи

ты хочешь чтобы тебе сравнили зеленое и квадратное

shty ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Ну а поверх этого RBD создается какая-то ФС.

Это делает уже сама виртуалка. RBD в данном случае для неё - образ жесткого диска, не более. Как оно там внутри работает, под слоем абстракции - для виртуалки скрыто.

Единственное, что может быть важно - использование ФС на виртуалках с поддержкой discard. Но это нужно только если хочется thin provisioning.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Единственное, что может быть важно - использование ФС на виртуалках с поддержкой discard. Но это нужно только если хочется thin provisioning.

thin provisioning разве не сам ceph обеспечивает?

JaM
()
Ответ на: комментарий от reprimand

ленивый ***** сын

и горжусь этим

но не тебе, не удосужившемуся даже заголовок прочитать, об этом рассуждать

shty ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

Единственное, что может быть важно - использование ФС на виртуалках с поддержкой discard. Но это нужно только если хочется thin provisioning.

Ceph умеет discard, как libvirt, так и в ядре.

Что-бы его использовать, в openstack например, надо использовать scsi bus и scsi drive. Пока discard на vda - в openstack сломан.

anonymous
()
Ответ на: комментарий от shty

и горжусь этим

я знаю таких, видел в живую

это цитата, если что. Из твоих же слов

но не тебе

а вы специалист?)

reprimand ★★★★★
()
Ответ на: комментарий от iron

А пока что в продакшине glusterfs наше фсё.

Хех. Глустер, который тупо раскладывает файлы по хешу, не умеет балансировку ёмкости между нодами, ему нужен RAID, не умеет балансировать нагрузку.

Гластер хорош тем - что он тупой как дрова.

anonymous
()
Ответ на: комментарий от anonymous

Чота я недопонял, кто кого умеет... Xen не умеет libvirt?

Indexator ★★★
()
Ответ на: комментарий от JaM

Как ты себе это представляешь? Ему нужна информация о том, какие блоки свободны. Предположим ты сделал dd if=/dev/zero of=/dev/rbd. Откуда Ceph знать, какие из этих нулей тебе не нужны? Правильно - ниоткуда.

Тоже самое и с ФС, которые не дают команду на освобождения блоков. Я использую ext4 с флагом discard, ЕМНИП btrfs и XFS тоже умеют. Умеет ли discard та же reiserfs - хз.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от anonymous

Спасибо кэп, я в курсе, сам использую virtio-scsi и thin provisioning работает. Я всего лишь сказал, что если в самой виртуалке допустим ext4 не будет примонтирована с флагом discard - он работать не будет.

Pinkbyte ★★★★★
()
Ответ на: комментарий от anton_jugatsu

На гипервизоре стоит один из MDS и один монитор. OSD на этой машине нет, хотя я подумываю над тем, чтобы воткнуть его.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

А, понял. Я только про первоначальное выделение места думал.

JaM
()
Ответ на: комментарий от Pinkbyte

Ну а поверх этого RBD создается какая-то ФС.

Это делает уже сама виртуалка

Естественно. И что? Всё равно сырое RBD не используется. А находится ОС внутри VM, используя RBD в виде виртуального устройства, или исполняется на голом железе, используя RBD напрямую - никакой разницы.

tailgunner ★★★★★
()
Ответ на: комментарий от reprimand

мне в этой теме 5 раз ответили, я каждый перечитал

А ты попробуй читать тему, а не ответы лично тебе. Ну, если тебя интересует понимание, конечно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Всё равно сырое RBD не используется

Изнутри виртуальной машины - нет. В чём вообще ваш спор я тогда не понял, если ты правильно суть технологии понимаешь(как видно из твоих же слов).

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

В чём вообще ваш спор я тогда не понял

ИМХО для использования Ceph практически всегда нужна ФС поверх RBD. Пока что единственный юзкейс, где это по большей степени не так - хранение образов.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Дык, rbd и есть образ, или я чего-то не понимаю?

JaM
()
Ответ на: комментарий от Pinkbyte

Что конкретно тебя интересует? У меня масштабы крохотные(даже терабайта не будет), уровень репликации - 2, osd-нод - всего 6.

Можно я тут то же влезу ?

Хочется попробовать но пока под все дело могу выделить 3 машины, еще три хочу выделать под openstack. Пока тесты, если все будет хорошо оставить. Можно совет как лучше 3 машины разнести ? везде ставить OSD,MON,MDS ? или может по сусекам поскрести и поставить еще одну машину дополнительно под mon и mds ? Может еще что скажите из опыта ,на что обратить внимание?

TuLiss
()
Ответ на: комментарий от TuLiss

Лучше отдельную машину под mon и mds. В крайнем случае можно и одну, но ни в коем случае не держать данные монитора и osd на одном устройстве, монитор пишет часто и много синкится.

JaM
()
Ответ на: комментарий от TuLiss

Сужу по-моему личному опыту(ну и чтению доков, да):

Количество mon лучше выбирать любое нечетное. Чтоб избежать split brain. В твоём случае - либо 1, либо 3. Если 1 - как ты понимаешь, об отказоустойчивости можешь забыть сразу(клиенты общаются с mon - если mon недоступны или нет кворума - клиент будет ждать либо восстановления кворума, либо отвала по таймауту). Поэтому - 3.

mds нужно ставить, только если будешь использовать CephFS. Если тебе она не нужна и тебя устроит чистый RBD(как образы для виртуалок) -> можешь вообще не ставить mds. Если он всё-таки нужен - его не рекомендуют ставить больше 1 в кластер(ибо CephFS еще сырая). У меня в кластере 2 mds - проблем не заметил, но такая конфигурация, как и сама CephFS считается экспериментальной, решай сам - надо ли оно тебе.

По поводу OSD никаких ограничений по количеству в принципе нет. Ну разве что - лучше держать его данные на отдельном разделе(у меня - отдельный LVM-том).

Ну и несмотря на то, что ограничений по размеру тоже нет, желательно точно указывать весовые приоритеты для OSD, в случае, если они будут неравномерными. Например, 1 хост - 100 гигабайт, второй - 50 Гб, третий - 33 Гб. Если предположить, что уровень репликации в кластере равен 3, а весовые приоритеты не настроены, то надо понимать, что первый OSD никогда не удастся забить больше чем на одну треть.

Ах, и да, не стоит допускать заполнения отдельного OSD выше чем на 95% ёмкости. Могут начаться всякие невеселые штуковины. Подробности - в документации.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Marvin

Что касается надежности ceph то есть грустная история взлета и падения сервиса cloudmouse.

Судя по тому, что никаких технических подробностей этого падения они не привели, косяк на сто процентов их, а не ceph'a. Очевидно, что был бы это глюк ceph'a они бы молчать не стали, защитили бы свою репутацию.

anonymous
()
Ответ на: комментарий от Pinkbyte

Про весовые приоритеты добавлю, что есть замечательные команды ceph osd reweight-by-pg и ceph osd reweight-by-utilization, которые сильно пригодятся по мере заполнения кластера.

JaM
()
Ответ на: комментарий от Marvin

Что касается надежности ceph то есть грустная история взлета и падения сервиса cloudmouse.

В случае с cloudmouse дело было не в бобине - дол...б сидел в кабине. Сервис и бизнес накрылся мамкиной панамкой по вине криворуких админов. Они с таким же успехом убились бы и на любой другой кластерной ФС.

anonymous
()
Ответ на: комментарий от Pinkbyte

Если он всё-таки нужен - его не рекомендуют ставить больше 1 в кластер(ибо CephFS еще сырая). У меня в кластере 2 mds - проблем не заметил, но такая конфигурация, как и сама CephFS считается экспериментальной, решай сам - надо ли оно тебе.

Возможно ты не совсем правильно понял. Грубо говоря, есть два режима работы MDS:

  • один active MDS + хоть сколько standby MDS и
  • несколько active MDS

Вот второй режим и не рекомендуется, так как он ещё очень сырой. Но он просто выключен по умолчанию.

Первый режим отказоустойчив, так как при вылете активного MDS новым активным станет один из standby, и он тут же начнёт реплеить журнал. Но он не масштабируется, так как распределения нагрузки между несколькими MDS не происходит. Второй режим, когда его допилят, по идее будет обеспечивать и отказоустойчивость и масштабируемость.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.