Anonymous
что на запись, что на чтение
Anonymous
если нужна сохранность данных и живая миграция - юзать write through?
writeback как раз и нужен
Anonymous
тут написано (http://docs.ceph.com/docs/master/rbd/qemu-rbd/):
Important If you set rbd_cache=true, you must set cache=writeback or risk data loss. Without cache=writeback, QEMU will not send flush requests to librbd. If QEMU exits uncleanly in this configuration, filesystems on top of rbd can be corrupted.
Anonymous
но я так понял, что это для старых QEMU, ибо:
Anonymous
Since QEMU 1.2, QEMU’s cache options control librbd caching:
Anonymous
т.е. если у нас Qemu новее, чем 1.2, то cache=none означает rbd_caching = none
Anonymous
rbd_cache вообще ни как не связан с Qemu. Вот для их согласования и нужно использовать writeback в Qemu
Anonymous
а rbd_cache имеет значение по умолчанию true, с версии помоему firefly.
Anonymous
Since QEMU 1.2, QEMU’s cache options control librbd caching:
Цитата, дословно: "С версии 1.2 qemu контролирует rbd cache"
Anonymous
Цитата, дословно: "С версии 1.2 qemu контролирует rbd cache"
а практика говорит ровно наоборот, делаем в qemu cache=none и видим увеличение скорости
Anonymous
по ссылке внизу страницы кстати написано: (не в то окно написал) ))
edo1
Итого: нужен tiering на ssd
edo1
И сеть с низкими задержками
Anonymous
Итого: нужен tiering на ssd
главное чтобы места хватило в кэш для активных данных. Когда происходит сброс данных, тормоза неимоверные.
edo1
Ну это я из доки понял
Mike
а практика говорит ровно наоборот, делаем в qemu cache=none и видим увеличение скорости
Он прав, параметр cache в xml файле описания VM, перекрывает, что написано в ceph.conf
Anonymous
Он прав, параметр cache в xml файле описания VM, перекрывает, что написано в ceph.conf
http://docs.ceph.com/docs/master/rbd/qemu-rbd/#qemu-cache-options
Anonymous
и выставляя none мы получаем непроходимость fsync через librbd
Mike
http://docs.ceph.com/docs/master/rbd/qemu-rbd/#qemu-cache-options
В чём я не прав?
"QEMU’s cache settings override Ceph’s cache settings (including settings that are explicitly set in the Ceph configuration file).
Note
Prior to QEMU v2.4.0, if you explicitly set RBD Cache settings in the Ceph configuration file, your Ceph settings override the QEMU cache settings."
Anonymous
да я вот про это:
Anonymous
Without cache=writeback, QEMU will not send flush requests to librbd.
Mike
Незнаю, кто будет в здравом уме ставить cache=unsave
Anonymous
ну unsafe это не none rконечно ;)
Anonymous
cache=unfase еще имеется
Anonymous
none более безопасный, чем unsafe
Mike
Он не более, он просто отключает кеширование
Anonymous
но не пропускает fsync. Если нода где была первичная OSD,упала по питанию/сбой контроллера и т.д то данные пострадают.
Anonymous
я из-за этого и нарисовал тот рисунок
Mike
При cache=none и rbd_cache=false, qemu и rbd пробрасывают запросы сразу на osd. Без кеша и прочих раздумий
Anonymous
ага, щаз...
Anonymous
кэш контроллера и dirty objects только забыл
Anonymous
на стороне ноды
Mike
кэш контроллера и dirty objects только забыл
Какой в жопу кеш контроллера? Ты о чем? Мы про компьюты говорим.
Anonymous
а я тебе про полный цикл записи данных на железный HDD на ноде ceph
Anonymous
у тебя видимо никогда контроллер дисковый не помирал?
Mike
а я тебе про полный цикл записи данных на железный HDD на ноде ceph
Мне этого не надо, т.к. разговор про опции кеширования на клиенте.
Anonymous
но я как админ прода обязан знать полный цикл записи данных на железный HDD и в случае сбоя отвечать за сохранность данных.
Mike
у тебя видимо никогда контроллер дисковый не помирал?
Если у тебя есть кеш на контроллере на сервере, это твои проблемы, ты за ним и следи. В любом случае, ask клиент не получит, пока все ноды в реплике не ответят
Anonymous
а ask не получит ceph osd, пока ОС не получит соответсвующий ответ от HDD
Mike
но я как админ прода обязан знать полный цикл записи данных на железный HDD и в случае сбоя отвечать за сохранность данных.
И что? К чему тогда ссылки на rbd cache на стороне клиента?
Maksim
@irekfasikhov Может у человека HBA.
Anonymous
И что? К чему тогда ссылки на rbd cache на стороне клиента?
Потому что он определяет критичность сервиса и его данных внутри.
Mike
а ask не получит ceph osd, пока ОС не получит соответсвующий ответ от HDD
И что? Ask ты получишь от журнала, а не hdd. А клиент, только тогда, когда ему ответит примари osd, а тот - когда ему придет ask от секондари osd.
Anonymous
И что? Ask ты получишь от журнала, а не hdd. А клиент, только тогда, когда ему ответит примари osd, а тот - когда ему придет ask от секондари osd.
ASK ты в начале получишь от внутреннего кэша и от SSD и от HDD.
Anonymous
открой POSIX IO и почитай!
Anonymous
по твоему сижу тут и выдумываю?
Mike
Потому что он определяет критичность сервиса и его данных внутри.
Наличие кеша на контроллере на стороне сервера, никак не влияет на опцию кеширования на стороне клиента.
Anonymous
Наличие кеша на контроллере на стороне сервера, никак не влияет на опцию кеширования на стороне клиента.
вот writeback как раз таки и влияет
Anonymous
отдебаж и увидишь, а с тобой спорить явно бесполезно
Anonymous
открой POSIX IO и почитай!
Mike
ASK ты в начале получишь от внутреннего кэша и от SSD и от HDD.
Нет, получу от журнала, т.к. на него пишется с o_direct и d_sync.
Anonymous
а потом чего, с журналов на HDD копируется?
Mike
отдебаж и увидишь, а с тобой спорить явно бесполезно
Зачем мне дебажить, если я и так знаю как работает.
Mike
а потом чего, с журналов на HDD копируется?
Нет. Данные висят в памяти и потом синкаются на диск. Из памяти. Для этого и есть опции osd: filestore max/min sync interval.
И куча других, управляющие очередью на синк, длиной и т.д.
Anonymous
ну ладно хоть не сказал, что да :)))). А то есть люди которые прям утверждают, что данные в начале сохраняются в журналы прямо, а потом копируются на HDD
Mike
Поэтому, если нода умерла, в журнале есть данные, но не на диске - можно из журнала из закомиттить на диск.
Anonymous
нету данных в журнале, от слова Совсем. Там есть только непосредстве информация о самой операции
Mike
ну ладно хоть не сказал, что да :)))). А то есть люди которые прям утверждают, что данные в начале сохраняются в журналы прямо, а потом копируются на HDD
Так поясни, как настройки кеша клиента, влияют на наличие или отсутствие аппаратного кеша на сервере?
Anonymous
ну и отсюда и epoch
Mike
Anonymous
Бред.
Ceph OSD Daemons write a description of the operation to the journal and apply the operation to the filesystem. This enables atomic updates to an object (for example, placement group metadata). Every few seconds–between filestore max sync interval and filestore min sync interval–the Ceph OSD Daemon stops writes and synchronizes the journal with the filesystem, allowing Ceph OSD Daemons to trim operations from the journal and reuse the space. On failure, Ceph OSD Daemons replay the journal starting after the last synchronization operation.
Anonymous
журнал он и есть журнал, в нем нет данных клиента.
Mike
Именно по этому, видимо, надо делать журнал не пару мегабайт, что бы хранить металанные, а размером в гигабайты, да ещё с огрядкой на поток данных на сервер и интервалы синхронизации.
Кстати iostat тогда тоже безбожно врёт.
Mike
журнал он и есть журнал, в нем нет данных клиента.
В том, что ты процитировал - ровно наоборот.
Mike
И кстати, если ты так уверен в своих словах - bluestore, пустая трата времени, у нас уже давно есть одинарная запись! Нет двойной записи! Уху!
Mike
Вообщем, мне понятно уже.
Советую тебе почитать больше и побольше подебажить.
Anonymous
Именно по этому, видимо, надо делать журнал не пару мегабайт, что бы хранить металанные, а размером в гигабайты, да ещё с огрядкой на поток данных на сервер и интервалы синхронизации.
Кстати iostat тогда тоже безбожно врёт.
а что у тебя пару мегабайт? Сравни количество записанных данных и прочитанных на SSD, я думаю все будет понятно.
Mark ☢️
Ceph OSD Daemons write a description of the operation to the journal and apply the operation to the filesystem. This enables atomic updates to an object (for example, placement group metadata). Every few seconds–between filestore max sync interval and filestore min sync interval–the Ceph OSD Daemon stops writes and synchronizes the journal with the filesystem, allowing Ceph OSD Daemons to trim operations from the journal and reuse the space. On failure, Ceph OSD Daemons replay the journal starting after the last synchronization operation.
нет. в цефном журнале (как и у поцгреса нпример) размещаются и все данные тоже. в блюсторе пофиксили. там иногда сохраняются. Это вобще фишка для ускорения рандомной записи.
Anonymous
Anonymous
я говорил, что blustore как раз убирает особенности связанные с posix io
Mark ☢️
тогда к слову "журнал" надо приписывать о каком журнале идет речь. если о журнале XFS -- то да, в него данные не попадают, только мета связанные с целостностью фс
Mike
Mark ☢️
вот я и помогаю шобы узнал. иначе нахуя чят ?
Anonymous
теперь понятно откуда это хрень