По=пг

Смотрят на версию карты и хранят истоиб

коллеги, а есть ли где-то внятный док, как обновлять майорный релиз ceph без снятия нагрузки? Вопрос пока что теоретический

http://docs.ceph.com/docs/master/install/upgrading-ceph/

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/installation_guide_for_ubuntu/upgrading_ceph_storage_cluster

спасибо!

коллеги, а есть ли где-то внятный док, как обновлять майорный релиз ceph без снятия нагрузки? Вопрос пока что теоретический

я тут однажды обновил, было весело. Коротко - в новой версии дистра сделали пользователя ceph:ceph, а раньше был root:root и понеслааааась шпулЯ по кочкам, пришлось chown запускать

ну это не так страшно. Данные же не потерлись?

ну это не так страшно. Данные же не потерлись?

нет, просто весь хост с 6 OSD отъехал

потом три часа chown в 6 потоков и все зажило

поверьте - это значительно лучше того, что было у меня при обновлении платных ынтырпрайзных хранилищ

я тут однажды обновил, было весело. Коротко - в новой версии дистра сделали пользователя ceph:ceph, а раньше был root:root и понеслааааась шпулЯ по кочкам, пришлось chown запускать

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

https://rook.io

я еще раз на это наткнулся и еще раз прифигел от наркомании)

https://rook.io

наркомания)

наркомания)

угу

сторадж для куба в кубе :)

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

наркомания)

если оно работает, то чем плохо то?

ну вообще было бы прикольно

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

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

вообще мне не кажется, что ceph должен управлятся из куба. В том числе потому, что ceph не имеет к кубу отношения. С точки зрения куба цеф - это сервис

это некое загадочное "отдай мне вот этих байтов, да побольше". А как оно живет на самом деле - никто не должен знать

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

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

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

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

нет, а зачем? цеф может использоваться (и должен использоваться) полностью самостоятельно, и от куба никак не зависеть

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

не говоря уже то том, что можно best practices натаскать из каких-нибудь helm chart (самому смешно, но вдруг?)

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

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

ну "нервирует" это субъективно. Компиляторы сами себя собирают, никто не умер :)

ну "нервирует" это субъективно. Компиляторы сами себя собирают, никто не умер :)

да, но они же не сами себя собирают тем, что они собирают, правда? про несубъективно - можем попробовать собрать такое хранилище и посмотреть, как именно оно навернется. Например, мне ужасно интересно, как из докера напрямую в диски лазать

да, но они же не сами себя собирают тем, что они собирают, правда? про несубъективно - можем попробовать собрать такое хранилище и посмотреть, как именно оно навернется. Например, мне ужасно интересно, как из докера напрямую в диски лазать

--priveleged

да, но они же не сами себя собирают тем, что они собирают, правда? про несубъективно - можем попробовать собрать такое хранилище и посмотреть, как именно оно навернется. Например, мне ужасно интересно, как из докера напрямую в диски лазать

вы про доступ к блок устройствам? был флаг кажется

вы про доступ к блок устройствам? был флаг кажется

я его выше писал, — privileged. Еще один, более специфичный —device Маэстро Себастьян Хан, гуру пихания цефа в докер пишет https://www.sebastien-han.fr/blog/2017/02/20/No-more-priviledged-containers-for-Ceph-OSDs/

> да, но они же не сами себя собирают тем, что они собирают, правда? именно так и происходит бутстрап: сборка нового компилятора старым, потом новый собирает тот же код повторно.

Использует кто 10G-адаптеры Intel, работающие с модулями ixgbe?

Использует кто 10G-адаптеры Intel, работающие с модулями ixgbe?

да

Использует кто 10G-адаптеры Intel, работающие с модулями ixgbe?

~300 голов

под 6 centos с штатными ядрами обычно приходилось собирать драйверы из исходников с sourceforge и загружать модули с параметрами ITR, DCA,RSS и другими

актуально ли это для CentOS 7

актуально ли это для CentOS 7

у меня взлетало само

модуль из пакета ядра довольно новую версию имеет - 4.4.0, но из параметров только allow_unsupported_sfp и debug

allow unsupported sfp только не забыть

Так же, нужно ли руками распределять обработчики прерываний по ядрам или использовать irqbalance?

актуально ли это для CentOS 7

Ниочинь, если ванильный драйвер устраивает

Пока не знаю, устраивает или нет

Так же, нужно ли руками распределять обработчики прерываний по ядрам или использовать irqbalance?

а это сильно зависит от того чего ты хочешь

в шестёрке не устраивал - начинал загибаться на ~5ГБит\с на интерфейс

и от камня и от много чего еще

а это сильно зависит от того чего ты хочешь

Эм... как это чего хочу? раньше irqbalance не очень хорошо себя показывал и приходилось через smp_affinity_mask прибивать обработчики прерываний

Ядер - 24

Вы, в общем, используете ванильный без тюнинга?

Если ядро лтс, беру с сурсфоржа ( приседания с vfio )

В мейнлайне как правило актуальнее

Вы, в общем, используете ванильный без тюнинга?

https://fasterdata.es.net/host-tuning/linux/test-measurement-host-tuning/

Так же, нужно ли руками распределять обработчики прерываний по ядрам или использовать irqbalance?

irqbalance - как факт плох. Вам тогда ножно между NUMA нодами по QPI гонять весь контекст процессов при переключении. И опять же, это еще и 'размывание' кэша. Что приводит к лишним задержкам, правильнее сразу привязать очереди к своим ядрам.

https://m.habrahabr.ru/post/330908/

Про луа годнота!

Про луа годнота!

Вот вот. кошусь в сторону кракена, но таааааааак сцыкотно .....

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

тоесть можно было лихко юзать VXLAN

У меня кракен

У меня кракен

ну я пойду на кракен только ради блюстора, остальное можно и потерпеть. Но блюстор увы не юзабелен.

ну я пойду на кракен только ради блюстора, остальное можно и потерпеть. Но блюстор увы не юзабелен.

Не ходи. В крякене он сегфолтится

Лично я жду люминоуса

Да и к блюстору надо бкеш прикручивать. Без него прощай пиковые иопсы. Так что я с блюстором не тороплюсь

Лично я жду люминоуса

ну я в целом про обновления это писал. пока сижу на джевеле. Надеюсь выйдет LTS с блюстором, тогда и попробую

Да и к блюстору надо бкеш прикручивать. Без него прощай пиковые иопсы. Так что я с блюстором не тороплюсь

а вот по поводу бкэша, пиковых иопсов итд - в статье есть финт как превратит WAL в кэш =)

Ну точнее намек на это. а там догадаться не трудно.

а вот по поводу бкэша, пиковых иопсов итд - в статье есть финт как превратит WAL в кэш =)

Хм. Но у блюстор же не пишет данные в журнал в отличие от файлстора

Хм. Но у блюстор же не пишет данные в журнал в отличие от файлстора

Однако, как уже упоминалось ранее, такая двойная запись имела обратное воздействие уменьшения латентности записи в случае, когда шпиндельные диски комбинируются с журналами SSD. BlueStore также может применять устройства дискового хранения на основе флеш- памяти для снижения латентности путём отложенных (deferred) записей, вначале записывая данные в имеющиеся WAL RocksDB, а затем позже сбрасывая эти записи на диск. В отличие от файлового хранилища в имеющийся WAL записываются не все записи, параметры настройки определяют установленный размера отсечения ввода/ вывода до которого запись откладывается. Здесь продемонстрирован соответствующий параметр настройки:

http://onreader.mdl.ru/MasteringCeph/content/Ch03.html

Хм. Но у блюстор же не пишет данные в журнал в отличие от файлстора

Я ответил на вопрос ? =)

Читаю

Переводчик статьи -- еблан

Благодаря его стабильности оно быстро стало необходимым хранилищем объектом и обнаружило себя применяемым в промышленных кластерах по всему миру.

это пока заготовка

сырые данные

что это ? у меня кровь из ушей

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