Так не, вопрос делать рейд или нет вообще не стоит. Не делать ни в коем случае. Ceph сам справится и с репликацией и с балансировкой нагрузки.

Т.е. то что raid10 дает прирост, для ceph не важно?

http://bash.im/quote/12782

Какой прирост то?

Чтения, записи, иопсы

я стесняюсь спросить. а что такое write amplification?

Коэффициент показывающий насколько реальный объем записи отличается от объема олезных данных записываемых.

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

объем. в мегабайтах?

Суть в том что Ceph Придуман как раз для того чтобы не ебаться с рейдами.

Суть в том что Ceph Придуман как раз для того чтобы не ебаться с рейдами.

Ебаться то будет проц хоста?)

Ебаться будет проц клиента. Так говоришь будто там нагрузка дикая.

Я так говорю, потому как не щупал не с не без рэйда, а в голову много мыслей лезут.

А. Ну так это. В общем то, я и не знаю людей которые софтовые хранилища с рейдом используют.

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

Ну я использовал например. Dell 720xd не умеет в JBOD / Initiator-target. Каждый диск надо было создавать как RAID0 из одного диска для VSAN

Ну, с реплицированными пулами процессор хоста будет все время нагружен довольно слабо. Репликацией Ceph управляет сам, поэтому пытаться сколхозить еще и зеркало для ущей сохранности данных идея довольно дурацкая. Ну а с производительностью такая шляпа - при хорошо подобранном количестве placement groups нагрузка сама естественным образом будет размазываться по куче дисков в кластере. А если включить еще и stripe для объектов и разумно потюнить, то вот тебе аналог твоего нулевого рейда, но не в пределах одного хоста, а в пределах кластера.

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

Ну, с реплицированными пулами процессор хоста будет все время нагружен довольно слабо. Репликацией Ceph управляет сам, поэтому пытаться сколхозить еще и зеркало для ущей сохранности данных идея довольно дурацкая. Ну а с производительностью такая шляпа - при хорошо подобранном количестве placement groups нагрузка сама естественным образом будет размазываться по куче дисков в кластере. А если включить еще и stripe для объектов и разумно потюнить, то вот тебе аналог твоего нулевого рейда, но не в пределах одного хоста, а в пределах кластера.

А при плохо подобранном?

Ну я вот и оговорился потому. Пока попадались умеющие. :)

Производительность страдает) Потому что, например, при маленьком количестве групп какие-то диски окажутся недогружены, а какие-то наоборот. А при большом количестве PG много процессорного времени будет тратиться на подсчет что куда положить.

Производительность страдает) Потому что, например, при маленьком количестве групп какие-то диски окажутся недогружены, а какие-то наоборот. А при большом количестве PG много процессорного времени будет тратиться на подсчет что куда положить.

А его реально надо подбирать, и потом следить, ребалансить?

Почему нельзя сделать автоматику?

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

потому что сеф не умеет решардить данные между PG в сторону уменьшения числа PG. не написали-с.

Опесорс же, миллионы глаз. Сделайте, чтоб умел

так ты троллишь. неинтересно.

"Зато я могу переписать как надо и затюнить" - это как, только на обои работает?

толсто, Антон, будьте тоньше.

я ж не сказал "будьте легче" или "будьте худее" :)

Вопрос а сохранности/зеркалировании не стоит, допустим не raid10, а raid0 аппаратный и поверх osd

Ну тут знаешь как. Сделать так можно и прирост производительности даст, в общем то. Но OSD пойдет пиздой в случае отказа одного из дисков. А как, я говорил, Ceph и сам умеет страйпить объекты а-ля RAID0. То есть, все то же самое что и аппаратный рейд, но гибче гораздо. Ценой, конечно же, процессорных ресурсов и памяти. Но я там где можно выбрать из аппаратного решения и софтового выберу почти всегда софтовое. Потому что софт можно на другое железо накатить и все будет так же работать. А вот железо поменять не всегда быстро и просто.

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

Ну тут знаешь как. Сделать так можно и прирост производительности даст, в общем то. Но OSD пойдет пиздой в случае отказа одного из дисков. А как, я говорил, Ceph и сам умеет страйпить объекты а-ля RAID0. То есть, все то же самое что и аппаратный рейд, но гибче гораздо. Ценой, конечно же, процессорных ресурсов и памяти. Но я там где можно выбрать из аппаратного решения и софтового выберу почти всегда софтовое. Потому что софт можно на другое железо накатить и все будет так же работать. А вот железо поменять не всегда быстро и просто.

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

Ну у меня многие коллеги отдают предпочтение mdadm нежели железке. Поэтому я так неуверенно на jbod лезу

Ну в твоем случае jbod выглядит как ОК решение. Раз есть контроллер и никуда от него не деться, то рейды делать не стоит, а вот JBOD - и рыбку съесть и эт самое. Кэширование задействовать сможешь)

latency - из-за jbod на smartarray-е с включённым cache

latency - из-за jbod на smartarray-е с включённым cache

И чо, менять железку?(