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

ceph можно сделать в режиме appendonly? чтобы нельзя было удалять данные и чтобы он только копировал в свободное место если какой-то из дисков сдох? и в случае бэкапов тоже разрешить только запись, и пусть пишет только новые файлы которых еще нет а старые без права удалять, при падении диска в бэкапе синкал в другое место из обычного кластера. И в самом ceph как-то заставить не дробить файл на разные сервера, чтобы он цельным куском лежал на одном диске, чтобы не было такого что пол файла побилось и нельзя востановить

нельзя

архитектура "симметричная", все осд равноправны, всё всегда мажется по всему кластеру (ну, по краш правилам)

Можно :) но Артемию это решение не подойдет 😂

гм??

Политики с3 же 🤗

а... ну у него не с3 же

Ну потому и не подойдет, но можно же :)

ну да, понятно

и он файлы-то в прямом понимании не хранит, он хранит объекты. файлы в цеффс режутся на объекты. плюс к ним допиливаются метаданные mds. всё это размазывается по осд

то что в осд filestore поверх фс - это считай баг, а не фича, в блюсторе уже просто голый девайс

у нас все эти данные как холодное хранилище, обращаются к ним довольно редко, кроме данных за последнюю неделю-две. Если предположить что будет 15 серверов по 8тб каждый, то падение одного из них должно заставить перебалансировать 8тб по чуть чуть равномерно между оставшимися другими 14, это каждый сервер должен около 500гб закачать себе и отдать столько же на другие по чуть чуть каждому из 13, если ограничить соединение между каждым сервером к каждому 200мбит то он должен перебалансировать это где-то за пол часа

Тут с гигабитом та ceph по сути не работает, а вы про 200 мбит

ээээээ не... 8 ТБ / 14 / 200 мбит/с = 22857 сек

и ещё если так сделать то всё это время цеф будет стоять колом

т.е. во время ребаланса будет тормозить всё безбожно

придётся его притормаживать и он будет занимать неделю))

сеть - строго 10G

должна быть