> Мм, рассказ тут не про Ceph, но когда набрасываете, то извольте конкретно
> излагать.Тоже не хотелось бы, но пару вещей прокомментирую.
>> Ceph - устроен значительно сложнее, чем LeoFS.
> Базовый комплект необходимый для работы - 3 сервера-монитора (можно один, если вы
> - герой мозга) и условно неограниченное количество OSD серверов на которых
> хранятся данные. mon сервера хранят "карту сети", osd хранят данные и
> проводят операции с ними же, никаких серверов под метаданные не нужно.
> Сложно? Вроде нет. Для дополнительных плюшек (s3/rados-gateway/iscsi и т.п) нужны будут
> отдельные сервера обслуживающие эти сервисы, но это нормально и в целом
> адекватно - архитектура наращивается по мере необходимости.
Например, вот это https://github.com/ceph/ceph/tree/master/systemd - в особенности то, как оно интегрируется с udev - на порядок сложнее LeoFS. И вообще, все познается в сравнении. Там 3 простых типа узла, для (продакшен!) настройки каждого достаточно прописать или поменять 3-4 строки в конфиге и все будет работать как часы. Данные хранятся в обычном каталоге.
Но дело не только в установке, само хранение данных в LeoFS очень простое.
А вот вам вопрос на засыпку: в руководстве по установку Ceph написано "отключите selinux". Это что вообще за фокусы, почему в 2018 году программа этого требует?
> В каких режимах использования Ceph и как конкретно вы добивались "проблем с
> данными" на Ceph? И каких конкретно проблем? И что конкретно не
> получилось восстановить? Единственный зафиксированный у нас случай когда таки проблема
> _могла быть_, это когда погорячились и выдернули сбойный диск раньше чем
> с него унесли все данные. На нём осталось некоторое количество данных
> без копий в остальном кластере. Но это получилось только потому что:
> в этом пуле была избыточность 2 (т.к. резервный кластер, в продных
> везде 3), коллеги поспешили. Проблемный диск потом подключили к другому серверу,
> экспортировали с него (штатной утилитой) недонесённые данные, импортировали в кластер
> и всё в порядке.
В режиме RBD, но это не так важно. Вот подумайте над тем, что вы только что написали: вас сам факт, что данные не чексаммятся и при наличии одной копии объекта оно даже не знает, корректная ли она - не смущает? А при наличие двух живых и различающихся - как выбирает?
Вот в LeoFS данные между копиями всегда сверяются относительно эталонной, возникаюшей при сохранении объекта (когда вычисляется ETag, который возвращается клиенту в ответ на операцию). В режиме strict все данные проверяются и на всех чтениях. Даже если вы унесете диск, на котором среди неповрежденных данных была последняя копия, вы все равно можете ВЕРНУТЬ его и взять с него эту копию. И она проверится по контрольным суммам, что не поверждена перед репликацией.
Да, разумеется на операции PUT в S3 и REST режимах можно еще хоть на клиенте вычислить эти контрольные суммы и сразу передать заголовок, и он проверит, что данные не побились на передаче, если вы совсем параноик.
>> Также есть сильное подозрение (частично подтвержденное небольшим опытом эксплуатации) все режимы Ceph, кроме того же объектного сторейджа это не очень надежно
> Есть сильное подозрение что вы свои фантазии выдаёте со слишком авторитетным видом,
> слабо подчёркивая что это ваши фантазии на очень скромном опыте.
Т.е. утверждение на оф. сайте, что CephFS тот же NOT PRODUCTION READY это ок? Или то, что сам Ceph открыто предлагают ставить на Btrfs, который и сам по себе разваливается - это ок?
> Возможно ваш негативный опыт обусловлен какими-то ранними/тестовыми версиями, неудачным
> выбором ФС поверх RBD, плохим железом, чем-то ещё, не знаю.
В 2014 году - тестовые? А когда же тогда стабильные?
Я не помню, что там поверх было, но либо Ext4, либо XFS, других вариантов-то нет. Скорее Ext4.
Но дело тут вот в чем. Вы посмотрите, как внутри хранит данные LeoFS. У вас есть большой линейный файл, заголовок-данные, заголовок-данные.. В заголовке - полная контрольная сумма объекта, который собственно "данные". Для больших объектов чуть хитрее, но ненамного: они разрезаются на куски (по возможности еще на S3 клиенте, но можно и на шлюзе), для каждого куска та же контрольная сумма, плюс заголовочный объект, по которому видно размер/куски/общая контрольная сумма. Все как на ладони, все прошито контрольными суммами, ETag'ами оригинального объекта. Никаких потерь на множество файлов и размазанные метаданные. На ФС, на которой это лежит ему по большому счету вообще по фигу, хоть рекомендуют XFS, но на практике разницы нет. Большие файлы append-only формата имеют очень серьезные плюшки.
Это я к тому, что тут и "неудачный выбор" не сделать, и если "плохое железо" и т.п., пострадать особо не выйдет. А для Ceph есть и нюансы с ФС, которая под хранилищем, и больше нюансов в эксплуатации. Говорю же, там все сложнее.
> RBD'шки с образами от десятков гигабайт, до десятков терабайт спокойно переживают рестарты
> машин на которых они собраны, промежуточных сетей, клиентов которые в них
> пишут, OSD на которых хранятся данные и т.п. (я тут хочу
> сказать что хранить данные в Ceph в многотерабайтных RBD это вообще
> неправильно, но такая ситуация сложилась из экстренных требований бизнеса)
Это да. Неправильно, но иногда есть требования.
> Опять же, формулировка "серьёзным последствиям" звучит конечно очень внушительно, но не
> более чем статья со швабры в начале обсуждения. Конкретики чуть-чуть намазать
> нельзя было? Ну типа какого характера в итоге проблема была, как
> добились, почему не чинилось?
Почему не чинилось? Чинилось. Но блоки в конечном итоге в RBD оказались некоторые побитые в итоге (немного). Когда это приходилось на метаданные фс, фс грустила.
> Ну и вы говорили про "все режимы", а как же режим CephFS?
> Или не проверяли?
Нет, отметка "not production ready" отговорила.
>> нет multi-DC репликации.
> Извините, я наверное на швабру просто не хожу практически совсем, потому отстал
> от мира и не вполне понимаю о чём вы тут речь
> ведёте, в чём суть "репликации"?
У вас есть основной ДЦ, пусть с 4 копиями данных. У вас есть второй ДЦ, пусть с 3 копиями данных. И там, и там идет работа с данными. Нужно, чтобы в обоих кластерах данные синхронизировались. Нужно, чтобы система не паниковала и не тормозила ни в одном из ДЦ, когда между серверами пропадает коннект, проседает до 100 мбит и другие реальности жизни.
> На всяк случай, вдруг речь об этом: в Ceph можно сделать столько
> копий сколько попросите, и разложить их строго по тем дискам/хостам/стойкам/рядам/комнатам/ЦОДам/континентам
Первое же руководство говорит, что там только синхронная репликация и ему нельзя объяснить, что вот это локально и должно работать, а вот это между ДЦ, высоколатентно и может проседать. И когда это случится, записям в это время будет довольно грустно.
В LeoFS и RiakCS именно репликация двух кластеров между ДЦ как отдельная система.
> (там по дефолту 10 градаций), по скольким вам это захочется сделать.
Ну, не знаю зачем 10 градаций, по-моему "сервер", "стойка" и "ДЦ" более чем достаточно.
> Что-то вроде: "первую копию на SSD ЦОДа А, вторую копию на
> SSD ЦОДа Б, третью на медленные и большие диски ЦОДов В
> и Г, а четвёртую мы отправим в другое полушарие".
> Или этого недостаточно и нужна какая-то доп.магия?
Судя по документации, так делать категорически нельзя.
> PS Я против LeoFS ничего не имею, хотя бы потому что ничего
> о ней не знаю. Не нравится когда с авторитетным видом рассказывают
> ерунду.
Я могу и не ерунду, просто надо понимать, что с LeoFS я успел плотно поработать, кое-какие вещи помог там доработать даже, а Ceph несколько лет как не интересуюсь. Мне на уровне концепций тамошняя исключительная простота (то, что то ли я никак не могу вам правильными словами объяснить, то ли вы мыслите совсем в другом ключе и не хотите понимать, утверждая что "ceph тоже несложный") очень понравилась. Я прекрасно понимаю, что у Ceph есть своя - и немалая - ниша, но там, где хватает LeoFS, есть реальные причины предпочесть его. Так что не надо спрашивать меня про Ceph, хотите спросить про LeoFS - спрашивайте.
