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)
Ответ на: комментарий от reprimand

а зачем, если есть zfs?

Затем, что компьтеров бывает больше одного.

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

а зачем, если есть zfs?

z/OS Distributed File Service? так она закрытая же

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

поставим вопрос ребром: есть поделки получше для продакшона?

Поставим ответ ребром: да, есть.

Ты про маслофс лучшефс?

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

У тебя есть петабайт жестких дисков подключеных к одной машине и терабайт ОЗУ чтобы всем этим управлять? Тогда да, можно попробовать zfs, мало-ли

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

Ты специально не перечислил их, дабы получить следующий вопрос?

Да.

Вы всегда отвечаете вопросом на ответ

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

Это реальность. ZFS мало какому продакшену необходима.

Использую zfs без экзабай RAM в проде. Обычные, я бы даже сказал заурядные серверы. Commodity hardware во все поля. Всё отлично, проблем не обнаружено, в отличие от сходного сетапа с lvm2. ЧЯДНТ?

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

Использую zfs без экзабай RAM в проде.

причом тут ceph? хоть бы с глюстерой тогда сравнивали...

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

есть к примеру 60 компьютеров. надо на них сделать общую файловую сичтему. я посмотрю как это будет делаться на XFS и EXT4.

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

есть к примеру 60 компьютеров. надо на них сделать общую файловую сичтему

Есть, к примеру, 60 компьютеров, на которых не надо делать общую файловую систему, и на которых даже дисков нет. Я посмотрю, как ты поставишь ZFS в такой продакшен.

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

а зачем на них ZFS если там нет дисков?:) пусть как тумбочки стоят )

если не надо делать общую фс то поделки типа цефа\ люстры\ гластера не нужны.

проблема в том что иногда такая необходимость есть

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

а зачем на них ZFS если там нет дисков?:)

Потому что продакшен. Для него нет ничего лучше ZFS.

проблема в том что иногда такая необходимость есть

Конечно. Вряд ли Ceph нужен для создания просто общей ФС, но для очень большой общей ФС - вариант.

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

Ты специально не перечислил их, дабы получить следующий вопрос?

Да.

Так перечисли уже список достойных альтернатив Ceph.

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

Присоединяется к разговору о ZFS

Просит список альтернатив Ceph

Хм, ладно. GlusterFS.

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

ну пока они теряют данные

Кто «они»?

про очень большой им лучше молчать мне кажется.

Возможно. Пойнт в том, что «очень большие» не всем нужны.

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

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

ну очень большие распределенно при этом нужны еще меньшему количеству...

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

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

Это было сказано о CephFS, которая является самым верхним слоем из 3-х слоев Ceph. Два нижних уже рекомендованы к использованию в продакшене.

ну очень большие распределенно при этом нужны еще меньшему количеству...

Насколько я понимаю, Ceph предназначен для построения очень больших FS на commodity hardware - здесь хранилище может быть только распределенное.

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

т.е. я так понял распределенный блочный девайс у них уже есть?

Да (и у них _всё_ распределенное). Ты Ъ и не ходишь по ссылкам?

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

Это было сказано о CephFS, которая является самым верхним слоем из 3-х слоев Ceph. Два нижних уже рекомендованы к использованию в продакшене.

Занудства ради, СephFS - один из двух верхних слоёв ceph, так как он работает независимо от rbd.

Насколько я понимаю, Ceph предназначен для построения очень больших FS на commodity hardware - здесь хранилище может быть только распределенное.

Необязательно FS. Можно напрямую использовать объектное хранилище без прослойки фс. Ну и rbd - это тоже не очень большая фс, а их пул, скорее.

В принципе, Ceph требует нескольких устройств хранения, но эти устройства могут находится и на одной машине. Сложно представить, правда, зачем такое может понадобится, кроме как для тестов.

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

Glusterfs по сравнению с ceph - тормоз. Кроме того в ceph более гибкие правила репликации. Но у самого ceph архитектурные ограничения в производительности, неотключаемый журнал. Для блочного доступа более оптимален sheepdog. По тестам, быстрее ceph раза в три. Что касается надежности ceph то есть грустная история взлета и падения сервиса cloudmouse.

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

Насколько я понимаю, Ceph предназначен для построения очень больших FS на commodity hardware - здесь хранилище может быть только распределенное.

Необязательно FS.

Интересно, какие приложения используют Ceph вообще без FS.

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

В принципе, Ceph требует нескольких устройств хранения, но эти устройства могут находится и на одной машине. Сложно представить, правда, зачем такое может понадобится, кроме как для тестов.

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

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

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

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

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

Интересно, какие приложения используют Ceph вообще без FS.

например OpenStack

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

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

Интересно, какие приложения используют Ceph вообще без FS.

Фиг знает, не интересовался, мне фс нужна. Думаю, в основном, самописные поделия на librados, там простое хранилище ключ-значение.

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

зачем, если есть zfs?

Кластеризуй мне ZFS. Как сделаешь - приходи.

По теме - отличная новость. Пользуюсь RBD в качестве хранилища для виртуальных машин KVM и CephFS - для хранения данных из своего инстанса ownCloud. Всё шикарно работает.

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

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

EvgGad_303 ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от Marvin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЫгспЁрд умудрился попутать локал фс с дистрибутед, простые с навороченными, *** с леденцом ... вобщем мушка-от-пушки-вжёпко-застрял в своём репертуаре.

anonymous
()
25 июня 2015 г.
Ответ на: комментарий от tailgunner

нубасятина

zfs используется в продакшене дольше чем шинукс существует. баран

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