тогда и кубернетес не нужен, надо купить VMware и все

swift и cinder никто уже не развивает и вряд ли будут)

я вообще против вендорлок и проприетарных коробок

3 миллиона отдашь а потом ещё надо 2 за лицензии платить)

куб и вмаварь решают несколько разные задачи, это разные подходы. А насчет дорого - а что делать, если вариантов нет? Если бизнес требует, скажем, 10птб с производительностью не ниже заданной

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

кстати не такой уж это и лок-ин - протокол, который торчит наружу - чаще всего стандартный

куча денег и нервы, таких клиентов относительно немного

правда чаще всего это iscsi или nfs4

куча денег и нервы, таких клиентов относительно немного

их большинство. Думаю, если мы соберем все хранилища на опенсорц и все коммерческие хранилища - коммерческие хранилища победят с разгромным счетом.

малый и средний бизнес такого купить не сможет

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

задача крупного вендора - продавать решения (коробки) крупному покупателю, типа сбера.

поэтому сбер потом нанимает 10 тысяч спецов чтобы как-то все работало) а карту где заводили туда и идите все равно)

тут чат не про ентерпрайз

тут противоположный полюс

энетрпрайз - это вопрос перекладывания цены ошибки на вендора. Я про энетрпрайз знаю довольно много, и искренне рад, что от него ушел. Считаю, что большая часть энтерпрайза умрет. Причем вне зависимости от нашего (или их) желания. А я в этом немножечко помогу :)

вот в альфабанке послвременнее подход вроде бы

ну совсем не умрёт, миллионы человек не могут без работы же остаться

ну совсем не умрёт, миллионы человек не могут без работы же остаться

скажите об этом например, кучерам :)

если такие аналогии проводить, то на смену коню пришёл двс. в нашем случае до двс всем этим технологиям, как например цеф, ещё далековато

крупный бизнес не заинтересован, прорыва не будет.

имхо

пилят потихоньку, пока манагеры от нетапа продают очередную вундервафлю

крупный бизнес полне заинтересован и на облака уезжает уже несколько лет

и да, я могу рассказать как правильно готовить цеф, потому что у меня 600Тб кластер сейчас в проде и 2 петабайта запускаю прям вот сейчас)

А тебя случайно не было на митапе по опенстеку ? Оч хочется слайды оттуда. А то Илья свалил внезапно

swift и cinder никто уже не развивает и вряд ли будут)

Cinder это менеджер твоих бекендов и он вполне живёт

А тебя случайно не было на митапе по опенстеку ? Оч хочется слайды оттуда. А то Илья свалил внезапно

Я жду, что Илья выложит. У меня только мой доклад. А куда он свалил?

cinder это block storage service. Без опенстека он не нужен. Чтобы его использовать, надо тащит такую кучу тухлой питонятины, что любой админ в запой уйдет

что собственно любого компонента опенстек касается

мирантис ещё это как-то причесывал, но увы

cinder это block storage service. Без опенстека он не нужен. Чтобы его использовать, надо тащит такую кучу тухлой питонятины, что любой админ в запой уйдет

Есть нюансы) например в овирт можно цеф пока только через cinder

ну и представьте сколько там слоев абстракции и ненужных сущностей

И вообще cinder еще очень даже ничего.

плюс напитонили. это быстро не работает

Предлагаю обсуждать циндер в соответствующем канале

Ну просто из приличия)

Я жду, что Илья выложит. У меня только мой доклад. А куда он свалил?

Пока в отпуск и так и не дал флешку :(

Кто-нить использует ceph в кубернетсе ? Для баз данных к примеру

cepfs? плохая идея

базы данных на Shared fs ни одна не работает, постгрес делает вид что живой, но там все плохо по производительности

cepfs? плохая идея

А почему сразу cephfs? А не рбд

базы данных на Shared fs ни одна не работает, постгрес делает вид что живой, но там все плохо по производительности

ну скорость работы баз сильно зависит от iops-ов, а они очень зависят и от настроек цефа и от сетевых задержек :)

и от дисков канеш )))

И от упоротости и прочности яиц цефостроителя)

И от упоротости и прочности яиц цефостроителя)

ну вот прочитаем/послушаем твой доклад, и вжух! цеф полетит :)

ну вот прочитаем/послушаем твой доклад, и вжух! цеф полетит :)

1) вы меня переоцениваете 2) там нет упоротых конфигов)

говорят, что много ручек надо крутить в зависимоти от профиля нагрузки на ceph

rbd это сетевой Block device

я так понял в чатике особо никто не юзал pv

для работы бд нужна fs

для работы бд нужна fs

но она не обязана быть кластерной.

ceph+xfs вполне себе насколько я знаю

ну если маунтить в одну точку

тогда смысл в rbd?

тогда смысл в rbd?

в том, что можно взлететь с этим же диском на другой ноде через 5 секунд.

не уверен что хорошая идея. если произошёл фейл, то журнал цефа будет неконсистентный

не уверен что хорошая идея. если произошёл фейл, то журнал цефа будет неконсистентный

смотря какой фейл. если кластер ушел в оффлайн целиком - да.

не уверен что хорошая идея. если произошёл фейл, то журнал цефа будет неконсистентный

Я не очень знаю, что надо сделать с цефом, что бы потерять в нем данные с тройной репликой

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

в целом лучше сделать нативно репликации для бд и взлететь со слейва

в целом лучше сделать нативно репликации для бд и взлететь со слейва

да.

Я не очень знаю, что надо сделать с цефом, что бы потерять в нем данные с тройной репликой

как делать нефиг. роняем три диска в разных доменах отказа (:

как делать нефиг. роняем три диска в разных доменах отказа (:

Надо будет попробовать прям убить данные)

Надо будет попробовать прям убить данные)

если ты выдернешь три диска из трех разных нод, при этом у тебя crush считает за одну корзину одну ноду, то ты гарантированно потеряешь какие-то данные.

rbd это сетевой рейд, не более того

всё равно нужна нормальная кластерная posix совместимая файлуха

которой нет

всё равно нужна нормальная кластерная posix совместимая файлуха

зачем нужна? :)

чтобы бд не потеряла данные на уровне абстракции файловой системы

чтобы бд не потеряла данные на уровне абстракции файловой системы

у вас кластерная реляционная бд, которая может работать поверх кластерной распределенной файловой системы?

(postgres|mysql) over (ext4|xfs) over rbd работает норм и не теряет данные.

у тебя журнал блок девайса отреплеится, что совсем не гарантирует консистентность журнала файловой системы поверх

и прощай бд

у тебя журнал блок девайса отреплеится, что совсем не гарантирует консистентность журнала файловой системы поверх

с чего бы вдруг?

ну это разные уровни абстракции

никак не связанные

консистентность журнала файловой системы какой? которая поверх rbd или под rbd?

представь что у тебя write cache включён и свет вырубили

поверх, на которой бд работает