Ох, коллеги-коллеги, зачем же вы плохому учите, а?
Давайте побыстрому пробежимся, и начнем с малого: «Плавная балансировка необходима, чтобы не потерять данные. Это особенно актуально, если в OSD находится большой объем данных». Пока вы не выключили OSD, количество реплик данных не уменьшается и вы ничего не потеряете.
Поэтому всё, что можно добиться «плавной балансировкой» — это пустой потери времени.
Наиболее быстрый алгоритм — запретить ребаланс (norebalance): ceph osd set norebalance
Добавить в CRUSH новые OSD и сделать вес 0 старым. При этом у вас появятся remapped PG, которые по-прежнему удерживают реплики данных — поэтому у вас не возникает degraded/undersized PG.
Для полноты картины можно установить primary affinity удаляемым и добавляемым OSD равным 0: ceph osd primary-affinity osd.$OLD 0
ceph osd primary-affinity osd.$NEW 0
Затем снижаете backfill до 1: ceph tell osd.* injectargs --osd_max_backfill=1
Снимаете norebalance: ceph osd unset norebalance
И данные поехали. При этом происходит примерно одно копирование данных, в то время как при «плавном уменьшении» веса у вас перемещений будет сильно больше. Если вам нужно остановить плановую миграцию — просто ставите снова norebalance. При этом если OSD откажет — у вас начнется срочный бакфил всех PG для которых количество реплик меньше заданного — и только их. Те который проосто «не на своих местах» никуда не двигаются пока стоит norebalance.
То же самое при выводе OSD (не замене). Меняем primary affinity, придавливаем бакфилл, сбрасываем вес OSD до 0 и в одну итерацию двигаем данные.
P.S.: я специально указывал norebalance а не nobackfill, потому что norebealance более щадящая опция — она останавливает ребаланс только тех PG, которые имеют достаточное количество реплик.
Особого смысла нет. Мне просто показался интересным сам случай, когда казалось бы избыточная операция неожиданно дает почти семикратный приост производительности. В более жизненных случаях всё не так печально
Юзерспейсный клиент быстрее и проще развивать, поскольку он строится на общей кодовой базе Ceph, поэтому он поддерживает больше «фич» RBD. Ядерный клиент это отдельный проект — но он производительней, поскольку меньше гоняет данные kernelspace <-> userspace. Когда кластер all-flash на хороших процессорах и хорошей сети, разница достаточно существенна.
Уже объяснялось раньше.
Здесь решается больше одной цели, и в частности:
1. Получить производительность (хоть какую-нибудь)
2. Избавиться от юзерспейса — чтобы остановка сервиса не приводила к похоронам таргетов
2. Задействовать каждый «кубик» по отдельности, чтобы:
2.1. Понять как работать с каждым компонентом
2.2. Иметь возможность применять полезные инструменты диагностики
Так веселее. И производительней. Librbd добавляет достаточно заметный оверхед. Плюс появляются всякие крайне интересные плюшки типа возможности сделать blktrace и т.д., нет риска вляпаться в кэш в юзерспейсе и прочее. И плюс универсальности. Можно другой таргет впилить например. Ну да, кое что может не работать ибо ядерный клиент беднее.
Я внимательно прочёл документацию к ядру в Documentation/block касающуюся writeback cache, запустил fio без синков и с синками и действительно увидел обещание поведение когда на устройство отправляются пустые bio с флагом pre-flush — поэтому да, я уверен что запросы на сброс кэша на устройство отправляются. Не вижу причин не доверять увиденному
Сэмплер вам вряд ли поможет. Тут скорее нужена какая то агрегация за достаточно большой интервал времени с одной стороны чтобы не утонуть в данных и достаточно малая чтобы не маскировать короткие всплески.
При тесте на устройстве что fsync, что fdatasync равнозначны — результаты одни и те же. Мы взяли за основную практику не делать тестов поверх ФС, чтобы не добавлять оверхеда и спецэффектов от файловой системы.
Можно предположить что «что-то не так» если виртуалка показывает нереально хорошие цифры в коротком тесте fio --rw=randwrite --runtime=1 --direct=1 и те же цифры с fio --rw=randwrite --runtime=1 --direct=1 --fsync=1. Естественно, тестировать напрямую на блочном устройстве а не на файле на файловой системе, то есть тест «деструктивный».
Но даже тогда достоверно сказать что «меня кидают» нельзя — может вашу машину положили на супер-пупер SSD локально на гипервизоре.
Если у вас SSD с PLP, то тут скорее дело в настройках гипервизора. Несовместимые настройки это nobarrier в виртуалке в сочетании с cache=writeback или cache=unsafe на гипервизоре. Ну и вообще cache=unsafe — он аналогичен безальтернативно включенному nobarrier в гостевой машине. Всё остальное работает нормально.
Любой вариант на ваше усмотрение — все имеют право на жизнь. Если с инфраструктурой не хочется заморочек — managed DB. Если надо чего то необычного от БД типа установки нетиповых расширений — то вариант 2. А техподдержка ответит «не надо отключать nobarrier, это категорически не рекомендуется»
Давайте побыстрому пробежимся, и начнем с малого: «Плавная балансировка необходима, чтобы не потерять данные. Это особенно актуально, если в OSD находится большой объем данных». Пока вы не выключили OSD, количество реплик данных не уменьшается и вы ничего не потеряете.
Поэтому всё, что можно добиться «плавной балансировкой» — это пустой потери времени.
Наиболее быстрый алгоритм — запретить ребаланс (norebalance):
ceph osd set norebalance
Добавить в CRUSH новые OSD и сделать вес 0 старым. При этом у вас появятся remapped PG, которые по-прежнему удерживают реплики данных — поэтому у вас не возникает degraded/undersized PG.
Для полноты картины можно установить primary affinity удаляемым и добавляемым OSD равным 0:
ceph osd primary-affinity osd.$OLD 0
ceph osd primary-affinity osd.$NEW 0
Затем снижаете backfill до 1:
ceph tell osd.* injectargs --osd_max_backfill=1
Снимаете norebalance:
ceph osd unset norebalance
И данные поехали. При этом происходит примерно одно копирование данных, в то время как при «плавном уменьшении» веса у вас перемещений будет сильно больше. Если вам нужно остановить плановую миграцию — просто ставите снова norebalance. При этом если OSD откажет — у вас начнется срочный бакфил всех PG для которых количество реплик меньше заданного — и только их. Те который проосто «не на своих местах» никуда не двигаются пока стоит norebalance.
То же самое при выводе OSD (не замене). Меняем primary affinity, придавливаем бакфилл, сбрасываем вес OSD до 0 и в одну итерацию двигаем данные.
P.S.: я специально указывал norebalance а не nobackfill, потому что norebealance более щадящая опция — она останавливает ребаланс только тех PG, которые имеют достаточное количество реплик.
Здесь решается больше одной цели, и в частности:
1. Получить производительность (хоть какую-нибудь)
2. Избавиться от юзерспейса — чтобы остановка сервиса не приводила к похоронам таргетов
2. Задействовать каждый «кубик» по отдельности, чтобы:
2.1. Понять как работать с каждым компонентом
2.2. Иметь возможность применять полезные инструменты диагностики
Так веселее. И производительней. Librbd добавляет достаточно заметный оверхед. Плюс появляются всякие крайне интересные плюшки типа возможности сделать blktrace и т.д., нет риска вляпаться в кэш в юзерспейсе и прочее. И плюс универсальности. Можно другой таргет впилить например. Ну да, кое что может не работать ибо ядерный клиент беднее.
Я внимательно прочёл документацию к ядру в Documentation/block касающуюся writeback cache, запустил fio без синков и с синками и действительно увидел обещание поведение когда на устройство отправляются пустые bio с флагом pre-flush — поэтому да, я уверен что запросы на сброс кэша на устройство отправляются. Не вижу причин не доверять увиденному
С синком 1K IOPS: fio direct.fio --filename=/dev/mailbox/xxx --rw=randwrite --iodepth=1 --runtime=30 --fsync=1 --fdatasync=1
Можно предположить что «что-то не так» если виртуалка показывает нереально хорошие цифры в коротком тесте fio --rw=randwrite --runtime=1 --direct=1 и те же цифры с fio --rw=randwrite --runtime=1 --direct=1 --fsync=1. Естественно, тестировать напрямую на блочном устройстве а не на файле на файловой системе, то есть тест «деструктивный».
Но даже тогда достоверно сказать что «меня кидают» нельзя — может вашу машину положили на супер-пупер SSD локально на гипервизоре.