IF
т.е. тут вопрос в том, как аккуратно и правильно добавлять новый не дефолтный класс в кластер в которм было только одно тупое правило. что все не начало туда-сюда носиться и все такое
Если меняешь класс, то обязательно все переедет
Size: a a a
2020 June 25
Am
т.е. тут вопрос в том, как аккуратно и правильно добавлять новый не дефолтный класс в кластер в которм было только одно тупое правило. что все не начало туда-сюда носиться и все такое
если ты добавишь не дефолтное класс вообще ни чего не поменяется )))
VO
да но нет. даже одна pg может например забить osd
А
т.е. тут вопрос в том, как аккуратно и правильно добавлять новый не дефолтный класс в кластер в которм было только одно тупое правило. что все не начало туда-сюда носиться и все такое
новый класс устройств как правило, добавляется созданием отдельного древа в crush конкретно для этого класса устройств
А
вместе классы устройств обычно не смешивают и крайне не рекомендуют смешивать
А
безопасно - скорее да, чем нет, данные не угробит, но проблем добавит сильно больше, чем оно того стоит
VO
я понимаю когда сразу есть правила с классами. а когда есть правило без класс и с класом?
ВН
я понимаю когда сразу есть правила с классами. а когда есть правило без класс и с класом?
если у тебя пул не был привязан к классу, а ты добавишь ssd - он на него просто доразмажет данные
ВН
если у тебя пул был привязан к классу hdd, а ты добавишь ssd - ничего не произойдёт вообще
ВН
если у тебя пул не был привязан, а ты его привяжешь к классу - поедут ребаланситься почти ВСЕ данные (ну там, 75%), т.к. поменяются все crush ID
ВН
в остальном - если добавить ссд к хдд, и ожидать от кластера той же скорости, что была при хдд - то думаю ничего не может случиться. хуже-то не станет
ВН
но ссд скорость станет тогда, когда уберёшь хдд %)
D
Коллеги, всем привет! Начал получать slowrequests на одной из osd(db вынесен на ssd).LVM. Версия ceph 12.2.11.В логах osd на которой вижу проблему следующие логи
Try to delete WAL files size 254635380, prev total WAL file size 254641129, number of live WAL files 2.
Куда копать ?
Am
Коллеги, всем привет! Начал получать slowrequests на одной из osd(db вынесен на ssd).LVM. Версия ceph 12.2.11.В логах osd на которой вижу проблему следующие логи
Try to delete WAL files size 254635380, prev total WAL file size 254641129, number of live WAL files 2.
Куда копать ?
Похоже копать надо в производительность ссд
VO
если у тебя пул не был привязан, а ты его привяжешь к классу - поедут ребаланситься почти ВСЕ данные (ну там, 75%), т.к. поменяются все crush ID
вот это я и хотел бы без ребаланса.
VO
в остальном - если добавить ссд к хдд, и ожидать от кластера той же скорости, что была при хдд - то думаю ничего не может случиться. хуже-то не станет
не, я ссд в пул добавить хочу, а в кластер. и на этих ssd сделать отдельный пул, для rgw index
ВН
вот это я и хотел бы без ребаланса.
тогда для тебя девайс классы - не вариант, увы
ВН
они сделаны на "параллельных иерархиях"
ВН
т.е. одни и те же краш узлы дублируются в карте с разными id
ВН
и из-за этого при смене класса едут ВСЕ хеши