Comments 21
Вы конечно меня простите, но что вы хотели сказать/рассказать в статье? Честно, я лично не понял…
Все что здесь указано и перечислено, пережевано рассылкой и документаций еще пару лет назад, а часть еще и самим хабром.
Все что здесь указано и перечислено, пережевано рассылкой и документаций еще пару лет назад, а часть еще и самим хабром.
Здравствуйте.
Хотел объеденить в одном месте основные вопросы по приготовлению CEPH. Как показала практика не все готовы читать maillist, а вопросы возникающие в статье возникают довольно часто.
Если Вам есть что рассказать, то присоединяйтесь к нашей группе в телеграм по ссылке https://t.me/ceph_ru, будем рады.
Хотел объеденить в одном месте основные вопросы по приготовлению CEPH. Как показала практика не все готовы читать maillist, а вопросы возникающие в статье возникают довольно часто.
Если Вам есть что рассказать, то присоединяйтесь к нашей группе в телеграм по ссылке https://t.me/ceph_ru, будем рады.
Простите, Enter сорвался :). Дополняю… а редактировать нет возможности.
Если у вас такой громкий заголовок статье, то почему нет параметров для оптимизации, а так же тесты и графики до и после?
Ну начнем по вашей же статье :)
Вы очень сильно ошибаетесь, самое простое сравните количество чтение и записи на дисках с журналами.
10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.
Абсолютно ни как не связан.
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.
Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.
МММ? ;)
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.
Все очень хорошо крутится с параметрами:
«osd_scrub_sleep»: «0.5», можно увеличивать
«osd_disk_thread_ioprio_class»: «idle»,
«osd_scrub_load_threshold»: «1»,
«osd_disk_thread_ioprio_priority»: «7»
С использованием cfq scheduler на хостах с OSD.
Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»,
Вы сами себе противоречите, т.к. reweight-by-utilization выставляет «высоты» OSD, количество данных в кластере от этого не поменяется.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump
Смотрим в сторону sysctl.conf: vm.min_free_kbytes = 1024000 я думаю, что решит вашу проблему.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true
Если у вас такой громкий заголовок статье, то почему нет параметров для оптимизации, а так же тесты и графики до и после?
Ну начнем по вашей же статье :)
Для тех, кто не в курсе: ceph сначала пишет данные на журнал, а через какое-то время переносит их на медленный OSD.
Вы очень сильно ошибаетесь, самое простое сравните количество чтение и записи на дисках с журналами.
какой размер журнала указать и какой параметр filestore max sync interval выбрать.
10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.
Один большой пул ведет к проблемам с удобством управления и апгрейдом. Как апгрейд связан с размером пула?
Абсолютно ни как не связан.
поэтому есть смысл развернуть новый небольшой рядом, отреплецировать данные в новый пул и переключить.
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.
Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.
с одним JBOD и 30-ю дисками
МММ? ;)
между нодами CEPH 10гбит/сек обязательно
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.
CEPH имеется проверка целостности данных — так называемые scrub и deep scrub.
Все очень хорошо крутится с параметрами:
«osd_scrub_sleep»: «0.5», можно увеличивать
«osd_disk_thread_ioprio_class»: «idle»,
«osd_scrub_load_threshold»: «1»,
«osd_disk_thread_ioprio_priority»: «7»
С использованием cfq scheduler на хостах с OSD.
Ограничьте скорость ребаланса параметрами osd_recovery_op_priority и osd_client_op_priority. Вполне можно пережить днём медленный ребаланс
Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»,
Не заполняйте кластер под завязку
то используйте reweight-by-utilization.
Вы сами себе противоречите, т.к. reweight-by-utilization выставляет «высоты» OSD, количество данных в кластере от этого не поменяется.
интересен мониторинг вывода ceph osd perf.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump
Видели ООМ на ОСД. Просто пришёл ООМ, убил ОСД
Местами CEPH очень прожорлив по swap. Возможно надо править настройки swappiness.
Смотрим в сторону sysctl.conf: vm.min_free_kbytes = 1024000 я думаю, что решит вашу проблему.
FIO с параметром engine=rbd может врать.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true
По-моему вам пора нести истину по Ceph в массы :) Особенно с высоты видимого опыта.
Видимо скоро придется это осуществить истину :). Предлагайте тему/ы ;)
Вот мне кажется, что автор хорошо уже начал и введение у него неплохое, надо как то развивать эту тему и развеивать миф, что Ceph это сложно, по тому что я и сам это довольно часто слышу. Так же интересует производительность на небольших системах (или с малым кол-вом репликаций), aka бюджетных и тд
Главный миф, который стоит развеить после умирания cloudmouse это стабильность CEPH и его готовность к production. И я буду крайне рад, если мне его будут помогать развеивать. Вы же своим желанием сделать кластер «с малым количеством репликаций» лишь увеличиваете шансы пойти путём cloudmouse. К сожалению у CEPH есть нижнее ограничение по объему и количеству серверов. Этого нигде не пишут, но это выходит логически. И в некоторых случаях уж лучше взять старый добрый drbd со всеми его проблемами.
Касательно малого кол-ва репликаций — вопрос сводился к теме производительности системы, а не в плане надёжности.
Может, и некропостинг, но раз я наткнулся, то и ещё кто-то наткнётся. Малое количество репликаций (т.е. меньше 3) — это прямой путь к потере данных. Никогда… нет, не так! НИКОГДА не используйте size 2 в продакшене, если данные хоть сколько-нибудь важны. О size 1 я, понятное дело, просто не упоминаю.
Это уже на пропаганду какую-то смахивает… А почему не пять? А если OSD не на "голых" дисках работают, а поверх RAID6?
Дмитрий, если мне память не изменяет вы обсуждали этот вопрос с Wido и Christian в декабре прошлого года. И если мне память не изменяет, Christian тогда говорил, что пробовал такой дизайн кластера, и его не устроила производительность. Я лично не пробовал, но если не важна производительность, я бы смотрел в сторону EC. Но нужно тут, конечно, считать конечную стоимость. Кроме того, с появлением в продакшене bluestore с расчётом контрольных сумм блоков есть возможность эффективнее RAID6 уберечься от проблем. И да, мои слова выше следует рассматривать в разрезе best practice, т.е. использования контроллеров в IT-режиме и one drive per osd.
Что же касается количества копий, то некоторые утверждают, что в ближайшее время даже RAID6 (или size=3) будет недостаточно для надежной защиты. Поэтому калькулятор каждому в руки и вперёд. Для ceph в онлайне не припомню инструментов, но плюс-минус столетие и очень теоретически прикинуть можно и калькулятором для RAID.
Предлагаю — расскажите как мониторить CEPH: как мониторить кластер, как завести графики производительности, заполненности в кибану/графану и т.д.
https://github.com/digitalocean/ceph_exporter классный – экспортит в prometheus, а оттуда уже и графана, и алерты.
А мне нравится простейший ceph-dash
На самом деле средств для мониторинга более чем предостаточно. Нужно их просто поискать на github'е. Мы сами пользуемся zabbix'ом а далее уже используем модуль zabbix'а для grafana
Мониторить <> завести в zabbix/графану/ etc
Тут вопрос более комплексный: какие метрики собирать, на что обращать внимание, что выводить на графики и как эти графики трактовать. Как различать — вот тут оно само починится, а тут уже админам звонить. Или вот тут вроде само чинится, но что-то идет не так.
Тут вопрос более комплексный: какие метрики собирать, на что обращать внимание, что выводить на графики и как эти графики трактовать. Как различать — вот тут оно само починится, а тут уже админам звонить. Или вот тут вроде само чинится, но что-то идет не так.
10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.
Только вот по умолчанию значение журнала 5Gb + в оф доке есть формула для расчёта размера журнала. Зачем тогда оно надо, если всем подходит?
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.
Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.
А что, разве есть что-то лучше, чем синхронизировать пулы и переключить клиентов?
Нет, есть второй вариант выдать блочники клиентам из нового кластера и попросить их самих смигрировать в новый кластер, но если у вас публичное облако, то «ой».
МММ? ;)
Что вас смущает? Нет это не один такой сервер, если вы про общий конфиг.
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.
Совет про 10Гбит/сек был про то, что это надо минимум, а не вообще.
С использованием cfq scheduler на хостах с OSD.
Чем вызван выбор именно этого планировщика?
Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»
Ок, на кластере у нас это есть но в посте нет. Косяк.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump
Лучше, чем что? чем вывод ceph osd perf может быть, однако тем же ceph_exporter к prometheus это банально удобнее.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true
Интересное заявление, хотелось бы пруфов.
Только вот по умолчанию значение журнала 5Gb + в оф доке есть формула для расчёта размера журнала. Зачем тогда оно надо, если всем подходит?Не уточнил, мой косяк. Это для HDD-10Gb и этого более чем достаточно. Об этом же, в качестве примера, написано в документации.
А что, разве есть что-то лучше, чем синхронизировать пулы и переключить клиентов?
Нет, есть второй вариант выдать блочники клиентам из нового кластера и попросить их самих смигрировать в новый кластер, но если у вас публичное облако, то «ой».
Лучше миграция на новый кластер, но точно не создание логических пулов. Мигрировать те же самые виртуалки клиентов — абсолютно ни каких проблем, просто на это нужно чуть больше времени. Если же публичное облако RGW, то можно использовать RGW multisite.
Что вас смущает? Нет это не один такой сервер, если вы про общий конфиг.
Я подумал про JBOD/Pass-through Mode…
Чем вызван выбор именно этого планировщика?
Тем что написано в документации:
ceph cfq
osd disk thread ioprio class
Description: Warning: it will only be used if both osd disk thread ioprio class and osd disk thread ioprio priority are set to a non default value. Sets the ioprio_set(2) I/O scheduling class for the disk thread. Acceptable values are idle, be or rt. The idle class means the disk thread will have lower priority than any other thread in the OSD. This is useful to slow down scrubbing on an OSD that is busy handling client operations. be is the default and is the same priority as all other threads in the OSD. rt means the disk thread will have precendence over all other threads in the OSD. Note: Only works with the Linux Kernel CFQ scheduler. Since Jewel scrubbing is no longer carried out by the disk iothread, see osd priority options instead.
Type: String
Default: the empty string
osd disk thread ioprio priority
Description: Warning: it will only be used if both osd disk thread ioprio class and osd disk thread ioprio priority are set to a non default value. It sets the ioprio_set(2) I/O scheduling priority of the disk thread ranging from 0 (highest) to 7 (lowest). If all OSDs on a given host were in class idle and compete for I/O (i.e. due to controller congestion), it can be used to lower the disk thread priority of one OSD to 7 so that another OSD with priority 0 can have priority. Note: Only works with the Linux Kernel CFQ scheduler.
Type: Integer in the range of 0 to 7 or -1 if not to be used.
Default: -1
Description: Warning: it will only be used if both osd disk thread ioprio class and osd disk thread ioprio priority are set to a non default value. Sets the ioprio_set(2) I/O scheduling class for the disk thread. Acceptable values are idle, be or rt. The idle class means the disk thread will have lower priority than any other thread in the OSD. This is useful to slow down scrubbing on an OSD that is busy handling client operations. be is the default and is the same priority as all other threads in the OSD. rt means the disk thread will have precendence over all other threads in the OSD. Note: Only works with the Linux Kernel CFQ scheduler. Since Jewel scrubbing is no longer carried out by the disk iothread, see osd priority options instead.
Type: String
Default: the empty string
osd disk thread ioprio priority
Description: Warning: it will only be used if both osd disk thread ioprio class and osd disk thread ioprio priority are set to a non default value. It sets the ioprio_set(2) I/O scheduling priority of the disk thread ranging from 0 (highest) to 7 (lowest). If all OSDs on a given host were in class idle and compete for I/O (i.e. due to controller congestion), it can be used to lower the disk thread priority of one OSD to 7 so that another OSD with priority 0 can have priority. Note: Only works with the Linux Kernel CFQ scheduler.
Type: Integer in the range of 0 to 7 or -1 if not to be used.
Default: -1
Лучше, чем что? чем вывод ceph osd perf может быть, однако тем же ceph_exporter к prometheus это банально удобнее.Ну тут как говорится, кому что нравится :). Это была только рекомендация.
Интересное заявление, хотелось бы пруфов.
По умолчанию на всех клиентах использующих librbd включен(с версии firefly) cache writeback. В связи с этим могут возникать провалы и пики.
UFO just landed and posted this here
Sign up to leave a comment.
CEPH на прокачку