« Rev
@ceph_ru   260
Fwd »


J
Не понял. А в чем вопрос?
kiosaku
почему не стандартный вариант в 9osd с журналами на них же?
Mike
Нет тут подвоха
kiosaku
?
kiosaku
ну вот если кто сможет объяснить причину, по которой так сделано - будет здорово. у меня есть пока только одна гипотеза, см. выше
kiosaku
про износ журнальных ssd
Александр
Смысл трёх дисков под журналы какой? Балансинг просто?
Александр
Ну типа 2хдд+1ссд
Александр
Диски то на лету не поменяешь
Александр
Так что сомнительно
Александр
А два журнала можно указать?
Александр
Кто нибудь пробовал это?
kiosaku
нет, ещё раз: все диски - SSD
Anonymous
это рекомендация связана с производительсностью
J
Журналы пишутся с dsync, а это дже для ссд не особо простая задача. При интенсивной записи кэш забьется и все упрется в производительность контроллера и флеша (а на некоторых писаться будет вообще в обход кэша). Вот типа и разносят разные виды нагрузок.
Anonymous
не больше 5-6 журналов на один SSD
kiosaku
т.е. смысл всё-таки есть, понятно
kiosaku
с износом никак не связано
kiosaku
там по 2 журнала на диск
Александр
Дорохо выходит
kiosaku
что написано?
Anonymous
это явно очередной высер, школьника )
J
Давай хранить все в озу
Не пойму съязвил ты или шутишь просто)
Anonymous
:)
kiosaku
Irek, не написано, конструкция такая собрана
kiosaku
выше вон есть объяснение данной конструкции дали
Anonymous
Irek, не написано, конструкция такая собрана
но она и правда бредовая...
Anonymous
как показыает практика и 12 журналов успешно живут на одном SSD.
J
но она и правда бредовая...
Почему? Я б не стал так говорить не взглянув чо там происходит в этом кластере. Может и правда смысла есть и пишется очень интенсивно.
Anonymous
понятно, что пики имеются, но их процент в течении суток очень мал и можно принебречь (в моем случае)
Anonymous
Почему? Я б не стал так говорить не взглянув чо там происходит в этом кластере. Может и правда смысла есть и пишется очень интенсивно.
Не используются SSD наполную значит. Лишняя трата денег. Ну или там какой хитрый io кэш настроен
kiosaku
12 журналов на 1 ssd? вылетает ssd - минус 12 дисков osd
kiosaku
замечательно
Anonymous
ак вы не берите душманские ssd, от no name производителя.
J
Я тут недавно рассказывал про беду с ATA_CMD_FLUSH на многих SSD. Вот те которые не игнорируют эту команду писать смогут ну, десятки мегабайт в секунду и пару тысяч иопсов в лучшем случае. Ну и опять же, домен отказа - три ссд. Потеряли один журнальный - теряем три осд. А если б все на одном, то печаль)
kiosaku
Irek, у меня мрут dc-шные интеля. без объявления войны
Anonymous
для меня не критично падения 12 дисков(ноды)
kiosaku
если уж это - noname ...
J
ак вы не берите душманские ssd, от no name производителя.
Это уже демагогия) Допустим, ссд не сдох, а просто смарт показывает что пора его менять. Что, выходит, надо 12 OSD отправлять в даун из-за этого?
Anonymous
Это уже демагогия) Допустим, ссд не сдох, а просто смарт показывает что пора его менять. Что, выходит, надо 12 OSD отправлять в даун из-за этого?
выключаем osd по очереди, делаем flush журналам и создаем его на другом носителе и далее стартуем osd
kiosaku
т.е. надо два ssd под журналы минимум
J
То естЬ, все равно получаем серьезный даунтайм для 12 OSD/
J
т.е. надо два ssd под журналы минимум
Если ссд нормальные и при этом у тебя не суперинтенсивная запись, то можно журналы на тех же дисках держать.
Евгений
То естЬ, все равно получаем серьезный даунтайм для 12 OSD/
Не для 12, а по очереди. И вылет одного OSD вообще никак не должен влиять на кластер - реплики же
kiosaku
блин, возвращаемся к исходному вопросу :)
Anonymous
там всяко разно можно извращаться журналами )
Anonymous
ну а смерть ssd все же редкость.
kiosaku
он звучал как "зачем журналы для ssd выносить на отдельные ssd"
Александр
Хм на 1 osd = 1 ssd
Александр
чо бы нет
Евгений
Хм на 1 osd = 1 ssd
больно жирно
J
он звучал как "зачем журналы для ssd выносить на отдельные ssd"
Я написал зачем. но без очень серьезной нагрузки на запись смысла в этом нет никакого.
Anonymous
он звучал как "зачем журналы для ssd выносить на отдельные ssd"
могу только предполагать, что это для большого объема ПОСЛЕДОВАТЕЛЬНОЙ записи
kiosaku
J, ответ я видел, thx
Александр
больно жирно
И ничего не жЫрно
Евгений
Я написал зачем. но без очень серьезной нагрузки на запись смысла в этом нет никакого.
Так потом журнал забьется и все начнет меееееедленно тащиться на диск
Anonymous
т.к. количество записи данных на OSD и в журналы примерно одинаково
Anonymous
у нас есть бекапный кластер на 500 ТБ, на нем исключительно S3 поднят, там 90 HDD дисков. Все журналы хранятся на самих же дисках. Полет нормальный.
Anonymous
но там скорость не критична конечно же
J
у нас есть бекапный кластер на 500 ТБ, на нем исключительно S3 поднят, там 90 HDD дисков. Все журналы хранятся на самих же дисках. Полет нормальный.
С таким количеством дисков конечно нормально) Тем более что, спасибо цефу, даже случайная запись в последовательную превращается.
Anonymous
кстати, кто как делает бекапы rbd?
Mark ☢️
скорее наоборот
J
скорее наоборот
Если журнал на сыром блочном устройстве, а не на файловой системе, то легко себе представить почему последовательно. Для чего ему писать в какое-то конкретное место на устройстве когда можно просто ебануть весь блок записи прям следом за пердыдущим и обновить leveldb? Да, метаданные которые пишутся в leveldb больше похожи на случайную запись, но сами блоки данных пишутся последовательно.
Mark ☢️
ну окей, полу-рандомная
Anonymous
на самом деле POSIX IO это такой трэш)
Mark ☢️
рандомные блоки а внутри блока линейно
Anonymous
собственно из-за этого и появился на свет блюстор
« Rev
@ceph_ru   260
Fwd »