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

Вот смотри, ты не веришь разрабам и докам, все тестишь сам - молодец, мне бы столько свободного времёни. К тому же, не считаю себя умнее разрабов ceph, в плане его разработки, внутреннего устройства и работы. Поэтому если они пишут, что не стоит использовать ext4 потому то и потому - склонен верить

Аналогично

Я даже центос под ноды ставлю

Потому что это рекомендуемое. Хоть и говно

Но это тема друного чата

Скопировал спецом)

We recommend against using ext4 due to limitations in the size of xattrs it can store, and the problems this causes with the way Ceph handles long RADOS object names. Although these issues will generally not surface with Ceph clusters using only short object names (e.g., an RBD workload that does not include long RBD image names), other users like RGW make extensive use of long object names and can break.

Потому что это рекомендуемое. Хоть и говно

А чО не генту?

Под чистый рбд то есть ок.

Гента + ceph + kvm. как раз 3 ноды. полёт нормальный.

Гента + ceph + kvm. как раз 3 ноды. полёт нормальный.

В доках не рекомендуют)

Гента + ceph + kvm. как раз 3 ноды. полёт нормальный.

Норм собралось на генту?

А то тут кое-кто не смог собрать и пытался понять как оно работает

:)

А не, тут нет его.

А не накидаете примеров настроек ceph, чтобы выжать из него по максимуму, с возможностью пережить ребаланс в момент дневной нагрузки

Не поможет) Подбирать нужно под каждый конкретный кластер.

А что именно подбирать? Какие ручки крутить? У нас небольшой кластер в основном под образы rbd, подключаемых к linux физическим машинам, и вот хотелось бы эти образы хоть как то ускорить

Речь сейчас об ускорении RBD или о безболезненной починке? Или и то и то?

Об ускорении rbd, чинить ничего не требуется

В частности у нас на rbd сидит парьицированная mysql база под zabbix

И вот как то уж очень медленно она ворочается на чтение

И нельзя сказать что база большая, всего-то 200GB

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

rbd cache readahead, bcache во writethrough режиме или Ceph Cache Tiers.

Это у нам по мере возможности все есть

Я имею в виду кеширование в памяти

А вот насчёт cache tier

В этой рассылке натолкнулся на изречение что оно и не работает вовсе

Если что у нас ceph jewel

Оно работает, но очень специфично. Если база все время горячая, к ней все время есть обращения и если она поместится в быструю кэш прослойку целиком, то да, это поможет. Но с таким же успехом можно вообще сделать пачку OSD прямо на ssd дисках.

И вот насчёт bcache тоже вопрос

Насколько быстро можно на нем ухлопать ssd

При частой перезаписи?

Смотря какие SSD и смотря какая нагрузка. Но если журналы и так на SSD, например, то чо уж там бояться)

Журналы мы только планируем на ssd(нет столько бюджета что бы все и сразу сделать)

А ssd сами есть?

И тут же вопрос упадет ли у нас apply latency на osd при журналировании на ssd

?

Ssd заложены в бюджет только на следующий месяц

Так что сейчас их нет

Я просто неоднократно встречал высказывания что журналы на ssd не дают большого профита

Но это по идее странно

Я ожидаю существенного снижения apply latency сейчас оно у нас в районе 70-100ms

И тут же вопрос упадет ли у нас apply latency на osd при журналировании на ssd

Да, потому что транзакции будут считаться законченными сразу после того как в журналы всех OSD в placement группе запишется, диски ждать не придется. Выходит, будет настолько быстрее насколько позволят SSD и сеть.

Угу большое спасибо за разьяснения

Хотя вот какой момент, я чо-то протупил.

Я то про commit latency тут.

Оо commit у нас секундами измеряется 1-2

Но если я все правильно понимаю он не так влияет как apply

На производительность rbd устройства

Стоп, я чего-то запутался.

Ну смотрите у нас на каждом osd apply latency в пределах 70-100ms

На ты можно же)

Commit latency на них где то 1-2 секунды(это когда я как понимаю происходит полный sync fs пороисходит)

При этом летннтность самого rbd устройства как раз 70-100ms

Если сравнивать с ssd простым бытовым это вообще тормоз

Наоборот. В цефе commit latency - задержка на запись в журнал, грубо говоря, а apply - на слив в filestore.

Так что, странно что commit больше)

Разве?

Эт вообще не точно, а из головы вспоминал) Ща прочту.

Ну вроде все верно я вспомнил.

Возможно неверные термины я использую

А вот как даже. commitcycle_latency: —------------------------ Filestore backend while carrying out transaction, do a buffered write. In a separate thread it does call syncfs() to persist the data to the disk and update the persistent commit number in a separate file. This thread runs by default 5 sec interval. This latency measures the time taken to carry out this job after the timer expires i.e the actual persisting cycle. apply_latency: —------------— This is the entire latency till the transaction finishes i.e journal write + transaction time. It will do a buffer write here.

http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-July/002806.html

То что apply берется с служебного сокета osd и называется filestore.apply_letency

Получается все верно apply небольшой

А commit огромный

Потому как syncfs в нем дергается

У нас конечно оба этих параметра огромные

Дак все таки получается даст журнал на ssd снижение apply?

Или так как это все буферизированно, то ничего мы не получим?

А вот чо.

ЧТо показывает ceph osd perf? А то мне покоя это не даст.

Это все одно и тоже

Сейчас скрин запощу

Ну так тут то commit latency ниже, выходит)

Тогда я не понимаю что за статистику ceph выдает в свои служебные сокеты