чет у них вообще плохо все продается

)

https://rook.github.io/ мож потыкать

ни в коем случае.

ни в коем случае.

для прода - да

как и вообще желание сeph поселить на тех же нодах, где и кубер

как и вообще желание сeph поселить на тех же нодах, где и кубер

Но ceph можно мигрировать при включении прода.

как и вообще желание сeph поселить на тех же нодах, где и кубер

действительно, где же это видано - колоцировать сторадж и вычисления!

ой, хадуп есть, ну это фигня

Но ceph можно мигрировать при включении прода.

и если он стабилен то нормальная стратегия гибкости

действительно, где же это видано - колоцировать сторадж и вычисления!

ты когда-то видет поведение osd при крупном ребалансе?

когда на ноде с 128 гигов паняти память заканчивается

ты когда-то видет поведение osd при крупном ребалансе?

не, я школьник

ну я не про школьника

а про то, что osd на ребалансе хорошо кушает память, и чем больше данных надо отребалансить - тем больше кушается память

как и вообще желание сeph поселить на тех же нодах, где и кубер

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

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

ну так о том и речь

а про то, что osd на ребалансе хорошо кушает память, и чем больше данных надо отребалансить - тем больше кушается память

В storageos диски не разбивают , а льют целиком на N машин, от того и ребалансить приятнее. Кто-нибудь пробовал?

ну так о том и речь

как оно кушает память? на чем оно написано, кстати? ceph

и что? 1) придумали сигруппы, чтобы лимитировать память (и остальные ресурсы) расходуемые разными приложениями. 2) если недостаточно сигрупп - придумали хардварную виртуализацию. и в ней есть возможность лочить память на старте машины так, что НИКОГДА физические страницы не смогут оверлапиться между машинами 3) с точки зрения расхода сети - придумали tc, который тоже замечательно работает на TCP-нагрузке (а ceph работает по TCP)

как оно кушает память? на чем оно написано, кстати? ceph

с++

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

и что? 1) придумали сигруппы, чтобы лимитировать память (и остальные ресурсы) расходуемые разными приложениями. 2) если недостаточно сигрупп - придумали хардварную виртуализацию. и в ней есть возможность лочить память на старте машины так, что НИКОГДА физические страницы не смогут оверлапиться между машинами 3) с точки зрения расхода сети - придумали tc, который тоже замечательно работает на TCP-нагрузке (а ceph работает по TCP)

вышел за переделы сигруппы - пришел оом, оно надо на осд?

про виртуализацию - кто сказал что она будет

)

и что? 1) придумали сигруппы, чтобы лимитировать память (и остальные ресурсы) расходуемые разными приложениями. 2) если недостаточно сигрупп - придумали хардварную виртуализацию. и в ней есть возможность лочить память на старте машины так, что НИКОГДА физические страницы не смогут оверлапиться между машинами 3) с точки зрения расхода сети - придумали tc, который тоже замечательно работает на TCP-нагрузке (а ceph работает по TCP)

Проблема в том, что если OSD словит OOM все совсем разваливается , говорят вплоть до порчи данных

вышел за переделы сигруппы - пришел оом, оно надо на осд?

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

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

Проблема в том, что если OSD словит OOM все совсем разваливается , говорят вплоть до порчи данных

если софт корраптит данные на ООМ - этот софт нельзя использовать. вообще.

это не сторадж, это хуёрадж

я правда не ломал сеф синхронными оомами всех его нод

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

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

я правда не ломал сеф синхронными оомами всех его нод

я ломал

не специально

я вот посчитал что засунуть его в lxc и сигруппой память ограничить - это хорошая идея

оказалось нихуя

я вот посчитал что засунуть его в lxc и сигруппой память ограничить - это хорошая идея

физическая память делает ровно точно так же.

действительно, где же это видано - колоцировать сторадж и вычисления!

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

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

физическая память делает ровно точно так же.

ну так osd вообще прожорлив к памяти на ребалансах, а тут еще его ограничивать и ускорять наступление кромешнего пиздеца

всем "you are welcome" как говориться...

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

сеф хуевый в этом плане с точки зрения дата-локалити

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

Память закончится раньше, если на ноде еще и приложения. А при неаккуратных лимитах, закончится еще и без всяких ребалансов и не в пользу ОСД :)

ну так osd вообще прожорлив к памяти на ребалансах, а тут еще его ограничивать и ускорять наступление кромешнего пиздеца

купите больше памяти и аллоцируйте сефу столько, сколько ему нужно. серьезно, если в типовом сервере 512 гб рам, 56 ядер и 8 ссд - всю такую ноду выделять на сеф?

Память закончится раньше, если на ноде еще и приложения. А при неаккуратных лимитах, закончится еще и без всяких ребалансов и не в пользу ОСД :)

"память закончится раньше" - если оверпровижионить.

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

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

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

Вы делали замечание относительно rook, оно не про вм :) против нарезания на вм железного монстра никто как раз не выступает :)

Вы делали замечание относительно rook, оно не про вм :) против нарезания на вм железного монстра никто как раз не выступает :)

рук - хипстерская хуита, пока не доказано обратное :)

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

эх. оптимизация по нуманодам... хочу себе железки обратно. фтопку облако...

купите больше памяти и аллоцируйте сефу столько, сколько ему нужно. серьезно, если в типовом сервере 512 гб рам, 56 ядер и 8 ссд - всю такую ноду выделять на сеф?

ну опять же - вопрос же какие ноды, какая сеть, сколько банально дисков и какого объема

это все виляет

ну опять же - вопрос же какие ноды, какая сеть, сколько банально дисков и какого объема

нет, постойте. если эта память цефу нужна - то ее НЕЛЬЗЯ забивать приложениями. вообще нельзя.

если не нужна - то не нужна.

короче давай так, опыт что был, 128 гигов памяти и порядка 100 терабайт на ноду дисков (это рав), таких нод было 5

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

что больше говорит о цефе, кстати, чем о чем-либо еще :)

при наполнении ноды на так 60% и вырубании одной - на сотальных на ребалансе осд отьели всю память

сеть в бонде две карты по 10Г

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

вы меня напугать-то чем хотите? какая разница, чем память ограничена сверху - гипервизором или физическим размером планок?

и тогда кластер развалился вообще

я не вас я просто опыт

5% дисков насмерть - оно и без ребаланса покорраптит данные

вопрос не в ораничении, а в совместном использовании этой памяти

так не используйте совместно страницы памяти.

убить ШИНУ памяти сефом крайне сложно

ERROR: S client not available

я даже не знаю как этого добиться

Короче цеф херня, если нет требований чтобы один вирт диск был больше размеров ноды - drbd

Короче цеф херня, если нет требований чтобы один вирт диск был больше размеров ноды - drbd

а вот с ним я какашек накушался больше, надо сказать

хотя мб щас чот поменялось

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

ну вот я такой

а вот с ним я какашек накушался больше, надо сказать

А чего он? В active passive простой как палка

я же никого не зставляю так делать, каждый волен сам решать)

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

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

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

ну отлично, сколько данных было в кластере цефа, какой прогноз по их росту?

сколько реплик

это же тоже влияет

ну отлично, сколько данных было в кластере цефа, какой прогноз по их росту?

а теперь выше - какая разница, что вас ограничивает - железный объём памяти или то что гипервизор разрешил взять?

так можно сказать что пока нет бесконечного объема памяти, сеф нельзя запускать

а теперь выше - какая разница, что вас ограничивает - железный объём памяти или то что гипервизор разрешил взять?

я не про ограницения, а про то, что бы на ту память что есть у цефа никто не посягал больше

А чего он? В active passive простой как палка

простой, но однажды я отведал мегатонны крови, когда был молод и юн: https://toster.ru/q/39291

я не про ограницения, а про то, что бы на ту память что есть у цефа никто не посягал больше

что в слове "лочите" вам непонятно? :)

https://libvirt.org/formatdomain.html When set and supported by the hypervisor, memory pages belonging to the domain will be locked in host's memory and the host will not be allowed to swap them out, which might be required for some workloads such as real-time

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

я еще раз задам вопрос (простите уже за тон), что в слове "лочите" вам непонятно?

эта память в RES процесса

ее НЕЛЬЗЯ использовать для чего-то еще. НИКАК. это НЕВОЗМОЖНО.

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

http://man7.org/linux/man-pages/man2/mlock.2.html

ну и?

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

выделить, если оверкоммит включен - обычно хоть петабайт

выделить, если оверкоммит включен - обычно хоть петабайт

оверкоммит это хорошо

а оверкоммит почти всегда включен.

но он не бесконечный

у меня серьезное опасение, что вы не понимаете, что такое резидентная память процесса

и с ограничениями