Основные преимущества software defined storage, что пришли сразу в голову, я перечислил чуть выше.
По поводу экономики — при сравнение надо учитывать намного больше переменных чем только «электричество и зарплату админов», потому что архитектура объектного хранилища совершенно иная от стандартного подхода на голове + JBOD.
Смотрите, Ceph это полностью распределенное объектное хранилище. Наличие абстрактного уровня Группы Размещения (Placement Group) позволяет очень гибко обслуживать репликацию блоков. У хранилища нет SPF. Отказ диска, ноды или шкафа с нодами не приводит к даунтайму, при правильном проектировании даже просадки производительности не будет при восстановлении. Архитектура может содержать несколько десятков серверов. Масштабирование горизонтальное и полностью прозрачное.
Да, при kill -9 mds ввод-вывод зависает на несколько секунд, я об этом написал чуть выше уже.
Kernal panic не наблюдал.
Я уверен — через несколько релизов допилят и Fault tolerance для mds.
В препродакшн по-прежнему рекомендуют ставить не более одного mds.
Я пробовал то, о чем вы написали на версии 0.56.4 — задержка при создании/удалении файлов была, но измерялась секундами.
Простите, не осилил до конца вопрос.
Ceph работает с выделенными дисковыми ресурсами посредством файловой системы, в этом примере — xfs. То есть, на презентованом диске должна быть файловая система, а ниже может быть HBA с multipath на LUN дисковой полки.
А клиенту всё равно к какой ноде цепляться? И, возмжно стоит через днс раздавать ip сереов, тогда при вылете первой он не потеряет хранилище.
Клиент «разговаривает» с тремя доступными демонами мониторинга mon.a, mon.b, mon.c.
Но основной вопрос в другом, что у этой штуки с произвоительностью?
Как она себя будет вести, если скажем планово выключить хранилище.
Т.е. порядок выключения 1,2,3 (на третью что-то успели записать, после выключения 1). потом включаем 1,2 (пытаемся прочитать то, что записали на 3), потом уже включается 3.
Все файлы размещаемые на Ceph FS разбиваются на блоки данных которые дублируются на разных физических дисках так, что бы оба дубликата одного и того же блока не попадали на диски одной ноды. В результате каждый блок данных будет случайно записан в двух экземплярах учитывая размещение физических дисков друг к другу. Хранилище не подтверждает команду записи блока данных до момента подтверждения записи от всех элементов участвующих в репликации этого блока.
Плановое выключение, как и аварийное при продуманном дизайне дисковой подсистемы, не приведет к потери каких либо данных.
Дополню.
Вот посмотрите на верхнюю строчку тут
Тут взяли всего один контроллер, пробросили 6 SATA дисков и получили около 800MB/s. Это при блоке в 4MB и btrfs.
Давайте представим себе наиболее худшую ожидаемую аварию — пропадает такое количество дисков при такой утилизации хранилища, при которых является необходимым отреплицировать все существующие блоки всех серверов.
К примеру, при 12 3TB дисках на каждой ноде и уровне избыточности 2, это может означать необходимость отреплицировать 18 TB данных.
— не рекомендуется маунтить туда, где крутится сам osd
— mds в данном конкретном случае очень важная штука, ей надо подкрутить ресурсов, она при большом количестве файлов жрет их очень много.
— журнал лучше убрать подальше от всего хозяйства, он прямо и четко влияет на производительность.
— btrfs лучше, чем xfs, ext4 тоже можно, но она самая медленная )
— много чего еще из нюансов.
И не только. Хочу написать об этом подробно позднее.
Для виртуализации замечательно подходит RBD, который можно использовать в продакшн.
По поводу экономики — при сравнение надо учитывать намного больше переменных чем только «электричество и зарплату админов», потому что архитектура объектного хранилища совершенно иная от стандартного подхода на голове + JBOD.
Kernal panic не наблюдал.
Я уверен — через несколько релизов допилят и Fault tolerance для mds.
Я пробовал то, о чем вы написали на версии 0.56.4 — задержка при создании/удалении файлов была, но измерялась секундами.
Ceph работает с выделенными дисковыми ресурсами посредством файловой системы, в этом примере — xfs. То есть, на презентованом диске должна быть файловая система, а ниже может быть HBA с multipath на LUN дисковой полки.
Можно мне взглянуть на вашу песочницу, если она еще не снесена?
Клиент «разговаривает» с тремя доступными демонами мониторинга mon.a, mon.b, mon.c.
Все файлы размещаемые на Ceph FS разбиваются на блоки данных которые дублируются на разных физических дисках так, что бы оба дубликата одного и того же блока не попадали на диски одной ноды. В результате каждый блок данных будет случайно записан в двух экземплярах учитывая размещение физических дисков друг к другу. Хранилище не подтверждает команду записи блока данных до момента подтверждения записи от всех элементов участвующих в репликации этого блока.
Плановое выключение, как и аварийное при продуманном дизайне дисковой подсистемы, не приведет к потери каких либо данных.
Вот посмотрите на верхнюю строчку тут
Тут взяли всего один контроллер, пробросили 6 SATA дисков и получили около 800MB/s. Это при блоке в 4MB и btrfs.
Давайте представим себе наиболее худшую ожидаемую аварию — пропадает такое количество дисков при такой утилизации хранилища, при которых является необходимым отреплицировать все существующие блоки всех серверов.
К примеру, при 12 3TB дисках на каждой ноде и уровне избыточности 2, это может означать необходимость отреплицировать 18 TB данных.
И не только. Хочу написать об этом подробно позднее.