Long Term Support != Enterprise. Понятно, что это будет вызывать «да будет срач», но факт остается фактом. Лично у меня LTS ядро вызывает больше вопросов по стабильности, чем ответов.
HostingManager, не очень конечно в тему. Но интерес берет свое :). У нас имеются Dell R730xd, и возникли вопросы. Поддержка DAS Cache требует отдельной лицензии от dell? обязательно ли применять сертифицированные dell SSD-диски в данном случае(имеем intel nvme p3700)? Спасибо за ответы.
P.S. На самом деле очень скудное упоминания про данную технологию на просторах интернет.
Так, если решения на базе CEPH предлагают ограниченную поддержку команд S3 API, то решение от «Техносерв» поддерживает практически весь «корпоративный набор».
Вот здесь интересуют подробности. Какие именно реализаций команд S3 API отсутствуют в Ceph RGW и имеются у Вас? Спасибо за ответ.
Но на практике, можно организовать классы/модули так, чтобы в unit-тестах просто подставлять нужное время без всяких костылей.
Это как раз и называется «костылями». Зачем реализовывать классы/модули, без которых можно обойтись, да еще о которых надо помнить, особенно «другим» разработчикам.
Python от ОСи время может получать, это тестировать на мой взгляд — излишне.
Только вот по умолчанию значение журнала 5Gb + в оф доке есть формула для расчёта размера журнала. Зачем тогда оно надо, если всем подходит?
Не уточнил, мой косяк. Это для HDD-10Gb и этого более чем достаточно. Об этом же, в качестве примера, написано в документации.
А что, разве есть что-то лучше, чем синхронизировать пулы и переключить клиентов?
Нет, есть второй вариант выдать блочники клиентам из нового кластера и попросить их самих смигрировать в новый кластер, но если у вас публичное облако, то «ой».
Лучше миграция на новый кластер, но точно не создание логических пулов. Мигрировать те же самые виртуалки клиентов — абсолютно ни каких проблем, просто на это нужно чуть больше времени. Если же публичное облако RGW, то можно использовать RGW multisite.
Что вас смущает? Нет это не один такой сервер, если вы про общий конфиг.
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. В связи с этим могут возникать провалы и пики.
На самом деле средств для мониторинга более чем предостаточно. Нужно их просто поискать на github'е. Мы сами пользуемся zabbix'ом а далее уже используем модуль zabbix'а для grafana
Простите, Enter сорвался :). Дополняю… а редактировать нет возможности.
Если у вас такой громкий заголовок статье, то почему нет параметров для оптимизации, а так же тесты и графики до и после?
Ну начнем по вашей же статье :)
Для тех, кто не в курсе: 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
Вы конечно меня простите, но что вы хотели сказать/рассказать в статье? Честно, я лично не понял…
Все что здесь указано и перечислено, пережевано рассылкой и документаций еще пару лет назад, а часть еще и самим хабром.
Если все таки убить 2 из 3 нод, то при факторе репликации 3, и правильной краш-карте оно будет работать на чтение. А если при этом min_size=1 (вместо дефолтного 2), то и на запись. Но такой min_size опасен, и с ним вы рискуете еще больше.
Не будет работать и на чтение. Много-много раз об этом говорил и говорю. Если выставить min_size=1 то будет и чтение и запись, но использовать такое- выстрел в ногу, причем в упор.
Кроме того, если значительная часть кластера падает, может начаться сильная ребалансировка, которая не только положит производительность, но и может такой нагрузкой ускорить умирание старых дисков (которые на тот момент являются единственными местами хранения большой доли объектов), находящихся в оставшихся живых нодах. И вот тогда то данные улетят. Я уже два раза слышал о такой ситуации.
Выставляем соответсвующие параметры задержек для ребалансинга и получаем гораздо меньше рисков как для производительности, так и «умирания старых дисков». И если произошло «умирание старых дисков» никто не запрещает достать необходимые диски от умерших нод и вставить в рабочие ноды и сливать данные с их PG.
И еще частой ситуацией, как я понял, бывает такая: кластер работает нормально, затем происходит какая-нибудь авария (например выключается свет или пожар в одной серверной), часть нод отваливается, кластер пытается все это дело сам разрулить, и в этот момент админы начинают паниковать, менять настройки мониторов, править карты, и тем самым разваливают все к чертям.
Паникующих админов надо успокаивать :). Человеческий фактор всегда был и будет.
вы имеете ввиду pool?
Я сам лично не пробовал, но сама логика сборки файлов будет аналогичной. Восстановление данные из RGW требует больших временных ресурсов.
К сожалению не могу редактировать свое же сообщение…
Я сейчас подсчитал и получилось, что и по занимаемому пространству не тождественно с size=2, вот с size=3 да. Извиняюсь за качество, на коленке рисовал
Заголовок спойлера
Честно сказать, не корректно сравнивать RAID и Ceph.
Я видел в рассылках(к сожалению не могу найти) люди использовали RAID 5/6, но там была сильно специфичная задача.
По занимаемому месту да, но на самом деле не тождественно. Вы не забывайте Ceph распределенное хранилище и все последующие репликации будут хранится на отличных друг от друга серверах. И так же я упоминал про производительность: 10 независимых OSD будут быстрее, чем RAID 0 из 10 HDD но с одним OSD.
Да и зачем нужна лишняя прослойка в виде RAID, которую нужно обслуживать…
в чём разница в отказоустойчивости широко применяемого raid10 на hardware raid контроллерах
По сути разница в том, что вы отдаете полностью сырой диск Ceph и он уже сам решает, что-куда положить и в каком количестве. В Ceph чем больше дисков, тем выше производительность(при использовании многопоточности конечно), даже при объединении одинакового количества дисков в райд 0. И Ceph позиционируется как «без вендерно»
Чтобы спать спокойно всегда, нужно не забывать, что «системные администраторы делятся на тех, кто ещё не делает бэкапы, тех кто уже делает и тех кто ещё и регулярно проверяет создающиеся бэкапы».
Сeph не оперирует блоками, а оперирует PG (я их называю группами размещения). Количество репликации как раз указывает на количество копий этих самых PG в пуле.
Какие рекомендации? фактор репликации минимум 3?
Из рекомендаций size=3, min_size=2, при необходимости и осознанности действий на время можно выставлять min_size=1.
по случайному диску и пул уже неработоспособен?
При потере данных из PG, блокируется только PG, а не Pool целиком.
это должны сойтись звезды
К сожалению это случается, и на моей практике тоже. Банально сбой подачи электричества и вы можете получить сбой дисков на серверах. Понятно. что это зависит от построения CRUSH-карты, но для небольших установок, настройки CRUSH по умолчанию более чем достаточно.
Это было ожидаемо, но зная RedHat можно не беспокойтесь о судьбе CoreOS
Спасибо за ответы.
P.S Не ради троллинга.
P.S. На самом деле очень скудное упоминания про данную технологию на просторах интернет.
Вот здесь интересуют подробности. Какие именно реализаций команд S3 API отсутствуют в Ceph RGW и имеются у Вас? Спасибо за ответ.
Это как раз и называется «костылями». Зачем реализовывать классы/модули, без которых можно обойтись, да еще о которых надо помнить, особенно «другим» разработчикам.
Вот именно, что от ОСи и это надо тестировать.
Лучше миграция на новый кластер, но точно не создание логических пулов. Мигрировать те же самые виртуалки клиентов — абсолютно ни каких проблем, просто на это нужно чуть больше времени. Если же публичное облако RGW, то можно использовать RGW multisite.
Я подумал про JBOD/Pass-through Mode…
Тем что написано в документации:
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
Ну тут как говорится, кому что нравится :). Это была только рекомендация.
По умолчанию на всех клиентах использующих librbd включен(с версии firefly) cache writeback. В связи с этим могут возникать провалы и пики.
Если у вас такой громкий заголовок статье, то почему нет параметров для оптимизации, а так же тесты и графики до и после?
Ну начнем по вашей же статье :)
Вы очень сильно ошибаетесь, самое простое сравните количество чтение и записи на дисках с журналами.
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
Все что здесь указано и перечислено, пережевано рассылкой и документаций еще пару лет назад, а часть еще и самим хабром.
Не будет работать и на чтение. Много-много раз об этом говорил и говорю. Если выставить min_size=1 то будет и чтение и запись, но использовать такое- выстрел в ногу, причем в упор.
Выставляем соответсвующие параметры задержек для ребалансинга и получаем гораздо меньше рисков как для производительности, так и «умирания старых дисков». И если произошло «умирание старых дисков» никто не запрещает достать необходимые диски от умерших нод и вставить в рабочие ноды и сливать данные с их PG.
Паникующих админов надо успокаивать :). Человеческий фактор всегда был и будет.
вы имеете ввиду pool?
Я сам лично не пробовал, но сама логика сборки файлов будет аналогичной. Восстановление данные из RGW требует больших временных ресурсов.
Я сейчас подсчитал и получилось, что и по занимаемому пространству не тождественно с size=2, вот с size=3 да. Извиняюсь за качество, на коленке рисовал
Честно сказать, не корректно сравнивать RAID и Ceph.
Я видел в рассылках(к сожалению не могу найти) люди использовали RAID 5/6, но там была сильно специфичная задача.
Да и зачем нужна лишняя прослойка в виде RAID, которую нужно обслуживать…
По сути разница в том, что вы отдаете полностью сырой диск Ceph и он уже сам решает, что-куда положить и в каком количестве. В Ceph чем больше дисков, тем выше производительность(при использовании многопоточности конечно), даже при объединении одинакового количества дисков в райд 0. И Ceph позиционируется как «без вендерно»
Это точно!
Сeph не оперирует блоками, а оперирует PG (я их называю группами размещения). Количество репликации как раз указывает на количество копий этих самых PG в пуле.
Из рекомендаций size=3, min_size=2, при необходимости и осознанности действий на время можно выставлять min_size=1.
При потере данных из PG, блокируется только PG, а не Pool целиком.
К сожалению это случается, и на моей практике тоже. Банально сбой подачи электричества и вы можете получить сбой дисков на серверах. Понятно. что это зависит от построения CRUSH-карты, но для небольших установок, настройки CRUSH по умолчанию более чем достаточно.