неделю назад у РТ на стыке с telia sonera были проблемы. Пинг из хельсинки и нюрнберга был 600-900мс.
Не знаю как на такой сети сможет ceph работать.

Если я верно понял, это будет трехголовый k8s-мультимастер растянутый на 3 ЦОДа (спб, финляндия, германия). В который rook-ом будет задеплоен ceph. Мониторы разъедутся и будет в каждом ЦОДе по 1 штуке. OSD так же будут все и везде. А коммуникации между компонентами планируются через istio.
Посмотрел беглым взглядом, rook катит кластер в hostNetwork, не уверен, что у вас получится трафик заверуть через istio

Если я верно понял, это будет трехголовый k8s-мультимастер растянутый на 3 ЦОДа (спб, финляндия, германия). В который rook-ом будет задеплоен ceph. Мониторы разъедутся и будет в каждом ЦОДе по 1 штуке. OSD так же будут все и везде. А коммуникации между компонентами планируются через istio.
Посмотрел беглым взглядом, rook катит кластер в hostNetwork, не уверен, что у вас получится трафик заверуть через istio

за 11млн рублей есть/были железки, которые способны прокачать 10 Гбит за достойные latency

ну я пожалуй мог бы дешевле сделать, если сертифицированность не нужна.

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

сейчас где-то 6 java приложений на 6 серверах которые отдают файлы, они за апстримами nginx, запрос идет на каждый из них по очереди пока не найдет файл, когда на сервере кончается место его руками синкают на другой сервер потом удаляют с первого, при этом ни раз теряли данные. И при таком подходе довольно геморно держать много небольших дешевых нод и тем более совмещать это с другими сервисами, поэтому по факту есть два здоровенных дорогих сервера которые хранять только файл и ничего больше и простаивают по процу и памяти.  а другие это так то что приложение локально успело записать временно, при этом всякие триггеры постоянно  загораются что где-то стало кончаться место. Хочется какое-то решение, которое будет работать и максимально скрывать внутри себя ребаланс данных по нодам, а в идеале еще и кешить горячие данные ближе к сервису который их создал. в итоге наверно судя по всему надо идти в сторону какого-то s3, но очень большие сомнения что это реально сделать быстро. хотя вроде что-то скинули posix совместимое, я еще не успел посмотреть. сейчас просто этам раннего тестирования и выбора итогового решения

хочу у существующих OSD сделать level_compaction_dynamic_level_bytes=true, это надо OSD грохать или оно через компакт пройдет?

хочу у существующих OSD сделать level_compaction_dynamic_level_bytes=true, это надо OSD грохать или оно через компакт пройдет?