Если можно, сделай ему докер. лол. И пусть ебётся

Дебил

ну меня уже спросили собирал ли я сам пакет уже, еле сдерживаюсь послать в git log

А, да, этому я уже порадовался

Коллеги, есть вопрос касательно отказоустойчивой хранилки в яндексе. В конторе помимо развитой наземной инфры есть здоровый кусок в яндексе. В нем живет с десяток проектов в кубере (и в управляемых кубиках и в саморазвернутых). На текущий момент у яндекса три зоны доступности, которые время от времени падают (точнее некоторые сервисы яндекса в них становятся недоступны по неизвестным причинам).
Саморазвернутые кубики обычно растянуты на все три зоны и стейтлесс сервисы прекрасно себя показывают при кувыркании зон.  Но все же надо хранить и использовать файло. Т.е хочется некой кластерной фс, которую можно было растянуть на три зоны доступности. Предварительно рассматривается гластерфс. Я гластер разворачивал только в локальной сети, как она себя поведет при более значительных сетевых задержках не могу сказать. Что посоветует многоуважаемый ALL ?
P.S. На виртуалках никто кластерную фс разворачивать не будет - яндекс железки дает во всех трех зонах.

не занимайтесь вы самоубийством! даже не думайте между дц растягивать фс(любые). Нужна отказоустойчивость - делайте на уровне приложения.

понятно все правила пишутся кровью, но хотелось бы аргументов

Ой. А наш свежеиспеченный geesefs (fuse over s3) не подойдет?)))

да, смотрим его вовсю

но фс поверх с3 - так себе идея

как бы это пафосно и просто не звучало, базовые аргументы приведены у Брюера(CAP теорема) :)

для нас ваше решение действительно снимает часть остроты проблемы

Ну а что от ФС нужно? Возможности именно ФС прямо действительно нужны? Или более-менее доступ вида положить-забрать?

есть базенки в кубике. не сильно важные не сильно нагруженные, но есть.

Я почему то вспомнил про теорему Брауэра, она же про причесывание ежа

Теперь про s3fs в этом чатике боюсь писать, а то буду токсичным

хых, надо почитать )

Ну s3fs таки реально днище

Он прям жестко неоптимальный

Базееенки