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)

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

ext4. Думал запилить на XFS или даже Btrfs, а потом плюнул, забросил пару workaround-ов(связанных с xattr) в ceph.conf и запилил на ext4 :-)

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

А разве второй режим вообще сейчас существует? Я, судя по документации, понял что он только разрабатывается и для рядового пользователя просто недоступен. Может чего не так понял...

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

А разве второй режим вообще сейчас существует? Я, судя по документации, понял что он только разрабатывается и для рядового пользователя просто недоступен. Может чего не так понял...

Насколько я знаю: да, существует. И его как-то можно включить путём правки конфигов. Но сам я не пытался.

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

Если будет 4 mon, есть ли веса ? Например можно было бы запустить 4 mon на отдельной машине без osd. Хотя в этом случаи можно найти еще одну ненужную машину :) Вообще я так понял по документации нагрузка на mon относительно небольшая ?

CephFS действительно сейчас не нужен, если только на поиграть.Если я правильно понял, то работает по схеме 1 активная копия + резерв. Грубо с одного читаем/пишем , с других читаем ?

И по поводу разбивки. Один диск система, второй диск OSD. Где то я читал, что желательно отдельно вынести журнал (например на SSD) Правильно я понял, что журнал и диск OSD должны быть равного объема ?

Если у меня вдруг появится еще один диск, могу я его поставить в систему и сказать используй не используя RAID0 и другие вещи ?

Как насчет вариант сделать такое извращения, взять RBD и сделать на нем ФС OCFS2 ?

P.S. Заранее спасибо.

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

Если будет 4 mon, есть ли веса ?

У мониторов? Насколько я знаю - нет.

Если я правильно понял, то работает по схеме 1 активная копия + резерв.

Это только для метаданных, сами данные пишутся на OSD настолько параллельно, насколько настроен уровень репликации.

Где то я читал, что желательно отдельно вынести журнал (например на SSD) Правильно я понял, что журнал и диск OSD должны быть равного объема ?

Журнал может быть любого объема. Данные сначала попадают в журнал, потом переносятся на сам OSD. По-умолчанию журнал ЕМНИП 1 Гб. На отдельный диск имеет смысл выносить только для повышения производительности, в общем случае это не обязательно.

Если у меня вдруг появится еще один диск, могу я его поставить в систему и сказать используй не используя RAID0 и другие вещи ?

Да. На одном хосте можно поднять несколько независимых OSD. А уже в CRUSH map сказать, что вооон те 2 OSD находятся на одном физическом хосте. Так как Ceph будет пытаться по умолчанию не хранить несколько копий в пределах одного хоста, то отказоустойчивость не пострадает.

Как насчет вариант сделать такое извращения, взять RBD и сделать на нем ФС OCFS2 ?

Не вижу для этого никаких проблем.

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

Итог:

3 машины по 3 HDD. на первом система на втором OSD на третьем MON

Так как: Running an OSD and a monitor or a metadata server on a single disk–irrespective of partitions–is NOT a good idea either.

Ну и если я вдруг захочу CephFS то отдельный диск для метаданных.

Две сетевые карты, одна для кластера, вторая в сеть (ну это логично) Кстати нет проблем с VLAN и агрегацией (bonding) ?

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

3 машины по 3 HDD. на первом система на втором OSD на третьем MON

1 OSD на одной машине - а зачем вообще ceph тогда, проще nfs.

Ну и если я вдруг захочу CephFS то отдельный диск для метаданных.

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

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

1 OSD на одной машине - а зачем вообще ceph тогда, проще nfs.

я имел ввиду HDD, а не машины. 3 машины с 3 HDD.

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

Вообще, если смотреть документацию то: Running an OSD and a monitor or a metadata server on a single disk–irrespective of partitions–is NOT a good idea either.

те OSD и метаданные раздельно.

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

Если три диска то лучше: 2 диска под OSD (raid0 или два OSD на каждый - обсуждаемо) 1 диск под OS и mon (сомневаюсь что OS будет создавать такое дикое I/O что mon встанет колом, а если разнести на разные lvm тома, то тем более sync будет для разных ФС выполняться)

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

на первом система на втором OSD

Эм. OSD надо ставить на все машины, место на которых ты хочешь расшаривать.

на третьем MON

выключишь машину с монитором - и кластер будет сосать. Монитора тоже нужно 3, по одному на машину. Иначе отказоустойчивости капец.

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

Я выше чуть ответил, что вы не так поняли. Точнее это я криворуко объяснил. 3 машины с 3 дисками :) на первом диске система, на втором диске OSD, на третьем MON. И так на всех трех машинах.

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

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

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

нубасятина

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

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