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

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

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

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

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

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

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

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

имхо

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

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

и да, я могу рассказать как правильно готовить цеф, потому что у меня 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 включён и свет вырубили

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

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

т.е. мы берем диск, запускаем на нем ext4 с writeback

а потом говорим "сеф говно"?

я такого не говорил

там выше комментарии про xfs

rbd синхронный. если он отозвался на sync, это значит что данные вкоммитились в xfs на кворум. если не отозвался - то не отозвался.

нормально работает /= гарантирует сохранность дангых

нормально работает /= гарантирует сохранность дангых

вы кейс опишите, когда вы пишете в сеф, сеф вам говорит "ок", а потом показывает плохое чтение.

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

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

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

это значит что журнал вышележащей файлухи покоррапчен тоже, на старте она пройдет fsck.

он отреплеится на другой ноде

но весь sync файлухи уже не попадёт никуда

это выглядит как кусок сислога внутри бинаря с таблицей

это выглядит как кусок сислога внутри бинаря с таблицей

как это возможно, емое? ну вырубили мы дц, ок. там (в вырубленном дц) остались дохлые данные. сеф перешел в деградировавшее состояние. грязных данных в живой оставшейся части нет. вернули дц. грязные данные не возвращаются, пока не пройдет скраб/проверка версий объектов.

rbd ничего про файлуху не знает. поэтому кворум нужно делать и для fs

rbd ничего про файлуху не знает. поэтому кворум нужно делать и для fs

блин! так вы все это время говорили про случай "мы замонтировали некластерную файлуху в нескольких местах"?

это работает и для одиночного монтирования

для множественного - это гарантированный развал. для одиночного - дайте кейс. "отвалился дц" - это "некоторое небольшое время операции io от файлухи к диску зависают в нигде".

а не "говорят что пишутся, но на самом деле пишется мусор"

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

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

почему он отреплеится? в какой момент?

rbd placement group оперирует

ему вообще пофигу что там сверху

rbd placement group оперирует

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

ну объекты эти с файловой системой никак не связаны

это математика блоков

в момент записи в rbd-устройство, происходит запись в объект(ы), соответствующие кусочку устройства. и ответ на клиентскую файлуху идет в тот момент, когда кворум объектов записался.

грязное чтение в этом случае невозможно.

ну объекты эти с файловой системой никак не связаны

им и не нужно.

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

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

журнал цефа не для реплея вообще предназначен...

когда происходит запись объекта, ответ клиентскому коду (в данном случае rbd) произойдёт когда записался кворум объектов.

Журнал цефа это что то вроде кеша, причем тут реплей с журнала другой ноде?

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