> Что "вот это"? Список юнитов systemd вас испугал, или наличие *готовых* (вам
> велосипедить не надо) юнитов в продукте является отягчающим обстоятельством? А зачем Вы действительно не понимаете или только делаете вид? Вопрос не в наличии, а в том, что внутри.
> start, restart". Как оно внутри работает с udev, linux kernel, ктулху
> и прочим вас вообще не должно колыхать. Нас во всяком случае
От грамотного админа во-первых все-таки требуется понимание, как оно работает с udev и прочим. Как там внутри реализовано - можно не знать, а как оно взаимодействует с системной - знать надо. Во-вторых, само наличие таких зависимостей это усложнение системы. Это и есть минус.
> (но вообще вы в очередной раз передёргиваете, к сожалению http://docs.ceph.com/docs/kraken/start/quick-start-preflight...)
От того, что здесь это написано чуть более мягкими словами, факт, что предлагают отключить не меняется. Как внешний сервис, сами демоны ceph все равно не ограничены политикой selinux по умолчанию. Раз требуется отключать, значит он куда-то лезет в более системные вещи, нарываясь на то, что запрещено по умолчанию. Сам факт этого не очень плох (хотя то, что с пакетами не дают соответствующей политики selinux немного печалит); но это еще один признак усложнения системы.
>> данные не чексаммятся и при наличии одной копии объекта оно даже не знает, корректная ли она - не смущает?
> Вообще-то знает. Вы очевидно читали что я написал по диагонали и потому
> ничего не поняли. Более того, есть механизм (deep) scrub, но про
Расскажите, можно со ссылкой на документацию. Где там хранятся контрольные суммы объектов и как именно они проверяются?
> него вы видимо тоже ничего не знаете. Проводить краткую лекцию по
scrub, который просто считает сумму на лету исключительно для сравнения с другими репликами?
Еще раз, кейз: есть две живых копии, одна искажена. Как именно это найдется?
> прямого вопроса: какие конкретно были проблемы и почему они были с
> вашей ТЗ не решаемы и якобы упирались в деньги?
Потому что так вопроса не стояло. И вообще, нерешаемых проблем при достаточном желании не существует. Но решения бывают оптимальные и неоптимальные.
> Рад за них, и никому не говорю что "плохо, не используйте!", потому
> что ничего о нём не знаю. И советую вам делать то
> же самое - не рассуждать о том в чём не разбираетесь.
А я не говорю, что плохо. Я указываю на конкретные проблемы. Сложность и отсутствие внятных контрольных сумм. Про сложность вы понимать не хотите, ок, проехали. Про контрольные суммы хотя бы чуть более полноценно прокомментируете? Не обязательно своими словами, можно ссылкой на документацию, где есть внятный ответ - я не запарюсь, прочту.
>> В 2014 году
> Ясно. Делать столь сильные заявления в IT базируясь на 3-4летнем опыте. Это
> действительно сильно и смело. Только неразумно.
Ну как есть. Я же не вызываюсь комментировать новые инсталляции ceph и решать в них проблемы :) Этим можете вы заняться.
>> Судя по документации, так делать категорически нельзя.
> Странную вы какую-то документацию читаете.
Т.к. фичи нет, то в документации про нее напрямую и не написано - логично?
А так находится например https://tracker.ceph.com/projects/ceph/wiki/Can_Ceph_Support...
> В сухом остатке имеем один пункт который реально можно подтвердить - отсутствие
> той самой высокоуровневой репликации, на которую у разработчиков Ceph затачивания явно
> не было. Но в описаной вами ситуации использования Ceph через RBD
> вам она ничем не помогла бы.
Конечно, не помогла. Но RBD это уже не от хорошей жизни.
> Ну так и не стоит делать выводов в духе "там всё сложна-ломается"
Вы просто не хотите понять. Вообще про что угодно можно сказать "не сложно", если хорошо разобраться. Но с точки зрения структуры хранения и работы с данными LeoFS устроен проще и надежнее. Также, рассуждая логически, есть основания считать, что LeoFS будет сильно быстрее (именно как объектный сторейдж), особенно на маленьких объектах; но возможности провести осмысленный бенчмарк у меня нет, а в целом это видимо никому не интересно. Т.к. и тот, и другой способны обеспечить "достаточную" производительность при правильном подходе и другие факторы тут куда важнее этих циферок.
> и тут же сравнивать с тем что вы используете те же
> N лет и потому знаете как облупленное.
Совсем не так долго использую, на самом деле (годик, наверное).
> В двух словах - потенциально можно загнать туда несколько сот Тб видеофайлов,
> при условии что со свежими файлами постоянно идёт работа (редактирование) и
> к ним нужен Posix FS доступ, а старые могут в рандомном
> порядке запрашиваться пользователем. И в ситуации "один ЦОД лёг" не получить
> тыкву в данных или split brain после восстановления?
Я тут в другом ответе давал комментарии про Posix FS доступ через NFS. Вкратце: нет, на таких нагрузках это не будет работать, надо использовать через S3 API. Несколько сот ТБ само по себе не проблема, есть вопросы про размер объектов и то, какими кусками идет их изменение (всегда заливка новой версии объекта целиком? Или вообще всегда идет сохранение объекта с новым именем, старые через какое-то время удаляются?).
Про ЦОД, split brain и прочее - надо все рассматривать конкретнее. Параметры консистентности R/W/D настраиваются, чтобы получить нужный баланс между консистентностью и доступностью, от полной консистентности до полной доступности. В режиме Multi DC репликация между ДЦ это отдельный канал со своими независимыми настройками репликации R/W/D. Приложения не знают про то, произошла ли Multi DC репликация, операции в каждом ДЦ работают возвращают результат на основе параметров R/W/D в этом ДЦ.
Давайте тогда задам встречный вопрос про ceph. Вижу вот такие баги https://bugzilla.redhat.com/show_bug.cgi?id=1457767 - становится страшно. Есть потребность хранить объекты, средний размер 70 КБ, на узел с 4 дисками по 6 ТБ влезают 300 млн таких объектов. Все нормально будет, никаких проблем с производительностью? Потому что на решении, которое было до LeoFS, в какой-то момент от количества сущностей в файловой системе оно начало еле ползать на операциях с метаданными типа листинга (доступ к объекту по конкретному имени норм). Из-за того, что слишком большое количество объектов в ФС это огромные расходы на метаданные, которые не влезают в кэш. Где-то на 50 млн становится заметны подтупливания, а когда >100 млн, совсем грустно. С 300 млн просто тоска-печаль. Если ставить современный Ceph последней версии и все правильно настроить - никаких проблем не ожидается?
