Scrub — это фоновый процесс проверки целостности данных в Ceph. Он позволяет выявлять и устранять несоответствия в копиях, а также находить разрушающиеся диски, чтобы вовремя их заменить.
При этом сам Scrub может создавать высокую нагрузку на кластер и мешать другим процессам.
Сегодня мы поговорим о настройках, которые помогут оптимизировать его работу и сделать нагрузку практически незаметной.
Статья подготовлена на основе лекции Александра Руденко, ведущего инженера группы разработки КРОК Cloud. Лекция доступна в течение Курс Ceph в Слерме .
Предыдущие материалы серии о Ceph: Флаги для управления состояниями OSD , Флаги для управления восстановлением и перемещением данных .
Как работает скраб
Очистка или очистка — это специальный фоновый процесс, проверяющий согласованность данных в группе размещения.Например, есть пул с тройной репликацией, то есть одна группа размещения в нем имеет три копии.
Данные в этих копиях должны быть полностью идентичными, что и проверяет Scrub. Если Scrub обнаруживает несоответствия (например, в какой-то группе размещения объект имеет контрольную сумму, отличную от двух других, или вообще отсутствует), то возникает ошибка, администратор узнает о ней и может исправить.
В закодированном пуле Erasure копий нет, но принцип тот же: Scrub выявляет неточности в данных, несоответствия, возникшие по тем или иным причинам.
Одна из основных причин – «тихое» повреждение магнитных дисков.
Вчера вы записали данные, а сегодня на диске отвалились некоторые сектора и данные повреждены.
Скраб бывает двух видов: обычный и глубокий.
В примере на скриншоте четыре группы размещения находятся в состоянии очистки, а также в состоянии очистки+глубокой очистки.
«Deep» означает глубокий скраб.
Обычный Scrub всегда выполняется первым, и только в случае его успешного завершения запускается глубокий.
Обычный скраб проверяет атрибуты и размеры объектов.
Проходит быстро и незаметно с точки зрения нагрузки.
Глубокий скраб читает практически каждый байт объектов и проверяет их на всех OSD в рамках проверки одной группы размещения.
То есть считываются все данные, проверяются их контрольные суммы и проверяются контрольные суммы.
Это достаточно ресурсоемкий процесс.
Это может затронуть сразу несколько групп размещения.
В приведенном выше примере данные четырех групп размещения проверяются параллельно.
Максимальная частота проверки одной группы размещения – один раз в сутки; чаще Скраб не запускается.
Причем у процесса есть срок: одна группа размещения должна быть проверена в течение недели.
То есть Скраб можно проводить не один раз в день, а хотя бы раз в семь дней.
Если группа размещения не проверялась более семи дней, появляется сообщение об ошибке.
Пример такого сообщения — на скриншоте.
Это показывает, сколько групп размещения не успели пройти тестирование в течение отведенных 7 дней.
Когда Scrub обнаруживает разницу в данных в одной группе размещения, возникает следующая ошибка: 
В первой строке показано, какие ошибки есть и сколько их.
Во второй строке указано, в скольких группах размещения было обнаружено несоответствие данных.
Только Scrub может выдавать такие оповещения.
В противном случае вы не узнаете, что группа размещения находится в несогласованном состоянии.
Фактически в оповещении говорится: по какой-то причине данные были неправильно записаны в одно OSD и необходимо запустить процесс восстановления - восстановления консистентности.
Мы также считаем процесс Scrub очень важным, поскольку он позволяет нам обнаружить повреждение диска.
При проверке данные группы размещения считываются целиком.То есть в течение 7 дней 100% данных кластера читаются и проверяются на разных OSD. В результате мы получаем проверку состояния дисков: способны ли они передавать данные, работает ли чтение с них.
Scrub считывает данные, которые пользователь, возможно, не читал месяцами и не будет читать еще год. Если при чтении с диска возникает проблема (например, вышел из строя сектор магнитного диска), это вызывает ошибку.
В журнале ядра Linux мы видим ошибку типа ошибки ввода/вывода.
Ceph сообщает, что произошла ошибка проверки.
В мониторинге появляется оповещение, в котором указан идентификатор диска.
Мы понимаем, что на нем есть ошибки ввода/вывода, внимательно смотрим на него и почти всегда меняем.
Управление отзывами
Если Скраб завершается с ошибкой, необходимо узнать подробности: какая группа размещения находится в несогласованном состоянии и на каком OSD она находится в данный момент. Вы можете сделать это с помощью следующей команды:Вывод будет примерно таким:$ ceph health detail
После этого можно зайти в логи ядра конкретной OSD и проверить.
Скорее всего, там будет обнаружена ошибка ввода-вывода и станет понятно, что диск нужно менять.
Чтобы узнать, какую именно ошибку выдал Scrub, используйте команду: $ rados list-inconsistent-obj {PG} | jq
Длинный вывод будет иметь раздел, аналогичный показанному на скриншоте ниже.
Показывает OSD и состояния проблемного объекта на них.
На скриншоте видно, что на двух OSD (875 и 925), включая основную, объект есть, контрольная сумма у него есть, а на третьей (463) его просто нет. Когда первичная копия есть и она правильная, можно запустить восстановление командой: $ ceph pg repair {PG}
Процесс ремонта может занять несколько часов.
После этого вы сможете найти эту группу размещения по id в журнале Ceph и посмотреть результат восстановления.
Там будет написано, сколько ошибок исправлено, а сколько нет. Но когда большая часть данных в порядке и повреждена только одна копия, процесс восстановления без проблем восстанавливает объект, взяв его из основного OSD.
Оптимизация сканирования
Несмотря на всю свою полезность, скрабирование имеет недостаток – оно создает сильный стресс.При запуске глубокого Скраба считываются данные из группы размещения, чтение этих данных никак не отражается в системах мониторинга (это внутреннее io) и этот запущенный Скраб может создавать нагрузку сам по себе.
Раньше это было колоссальной нагрузкой.
Кластеры в более ранних версиях сильно пострадали от проверки.
Скраб был невероятным испытанием.
Можно было встретить множество статей о том, как его ограничить, чтобы оно шло медленнее и не создавало такой нагрузки.
Теперь Scrub в Ceph стал умнее; к нему привязано множество параметров, позволяющих его оптимизировать и практически в любом кластере сделать так, чтобы нагрузка от него была не сильно заметна.
Давайте рассмотрим некоторые из этих вариантов.
Давайте посмотрим на параметры экранного меню, содержащие слово «скраб», чтобы увидеть все связанные с ним настройки.
ceph daemon osd.0 config show | grep osd | grep scrub
«osd_max_scrubs» — определяет, сколько групп размещения одно OSD может «чистить» параллельно.
Значение по умолчанию — «1», то есть Scrub зажимается максимально.
Есть настройки, которые полезно настроить с самого начала: «osd_scrub_begin_hour» и «osd_scrub_end_hour».
В нашем примере первый параметр содержит значение «0», второй — «24», то есть процесс разрешен к запуску в любое время.
Поменяем значения: установим время начала «02», время окончания «08»: ceph config set osd osd_scrub_begin_hour 02
ceph config set osd osd_scrub_end_hour 08
Таким образом мы задаем нужный интервал времени для проверки.
Но есть важный момент: хорошо это будет работать только на первых порах.
Как только некоторые группы размещения не успеют «почистить» в течение недели из-за этого интервала, Scrub будет запущен сразу после окончания недели, независимо от временных ограничений.
Крайний срок для Scrub более важен, чем эти интервалы.
Другими словами, с помощью этих параметров вы устанавливаете время, когда Ceph должен выполнить Scrub, если он может это сделать.
Если у него есть дедлайн по какой-то группе размещения, то он проигнорирует интервалы, потому что дедлайн имеет решающее значение.
«osd_scrub_sleep» — еще один важный параметр.
Для обычного скраба его значение равно «0,00000».
Можно установить значение «0,1», хотя для обычного Скраба это не особо важно.
«osd_debug_deep_scrub_sleep» — устанавливает режим сна для Deep Scrub. По умолчанию его значение также равно «0», но мы установили его на «0,2».
Значение параметра меняется таким же образом: ceph config set osd osd_debug_deep_scrub_sleep 0.2
Нужно понимать, что настройки Scrub в каждом кластере индивидуальны.
В очень больших кластерах могут не возникать проблемы даже при настройках по умолчанию.
На небольших кластерах это может быть очень заметно.
Но если это небольшой кластер и у него еще очень интенсивный io, то Scrub может стать проблемой.
«osd_scrub_chunk_max» и «osd_scrub_chunk_min» — наиболее важные параметры, определяющие интенсивность сканирования; что-то, что плотно зажимает или отпускает Скраб.
Если установить это значение, то интенсивность продолжающегося скраба упадет в 5 раз — настолько медленнее будут читаться данные.
ceph config set osd osd_scrub_chunk_min 1
ceph config set osd osd_scrub_chunk_max 4
Хотя, скорее всего, вы не заметите никакого эффекта, но будете получать оповещения о том, что группа размещения не успевает завершить Скраб вовремя.
Просто потому, что за одну итерацию берется слишком мало объектов, чтение происходит слишком медленно.
Вы можете поиграть с этими параметрами, задавая разные значения, чтобы добиться того баланса, когда Скраб можно выполнить за неделю и не создает видимой нагрузки.
Они меняются на лету, и вы можете использовать их для ускорения или удержания Scrub в любой момент. «osd_scrub_auto_repair» — еще один интересный параметр.
В начале статьи вы видели ошибку, что группа размещения находилась в несогласованном состоянии.
Если вы установите значение этого параметра на «false», то Ceph запустит восстановление для этой группы размещения, но только если количество ошибок до 5. Если ошибок больше, то он не запустит автоматическое восстановление, а появится ошибка, и вам нужно будет посмотреть, что произошло.
Ceph считает, что поврежденных объектов слишком много для автоматического восстановления.
Нам нужно разобраться, что происходит. «osd_scrub_during_recovery» — относительно новый параметр.
Если он активирован, то Скраб не запустится при выполнении обратной заливки на OSD, то есть идет восстановление io. Если вы когда-нибудь настроите мониторинг текущего количества скрабов, то сможете увидеть, как график скрабов начинает стремительно снижаться во время ребалансировки.
Очистка io пытается не конфликтовать с восстановлением io, что является еще одной причиной, по которой Scrub может задерживаться.
Если вы сделаете сильный ребаланс в течение недели - увеличите количество групп размещения, добавите сервер - Скраб отложится, и через неделю вы получите много сообщений о том, что Скраб не завершился за неделю, и вам нужно будет либо ускорьте его или подождите, пока он «растворится».
Общая рекомендация: если вы видите аномальную проблему с производительностью в кластере и не понимаете, в чем дело, вы всегда можете отключить Scrub, используя следующие флаги: Обычный: ceph osd set noscrub
Глубокий: ceph osd set nodeep-scrub
Кроме того, скраб можно отключить для конкретного пула.
Если у вас несколько пулов и вы хотите отключить очистку для определенного пула, сделать это можно командой: ceph osd pool set {name} noscrub 1
ceph osd pool set {name} nodeep-scrub 1
Флаги будут отражаться на работоспособности кластера: 
Эти флаги блокируют новый Scrub, но уже запущенные сканирования не отклоняются и будут завершены.
После завершения текущих проверок вы сможете оценить, изменилась ли ситуация с производительностью.
Если проблема исчезла, то нужно немного подтянуть Скраб.
Если проблема не исчезнет, значит, проблема не в Scrub; вы можете запустить его еще раз и поискать другую причину ненормальной работы.
Теги: #Хранение данных #Системное администрирование #Администрирование серверов #DevOps #Системы хранения #ceph #scrub #очистка
-
Советы По Созданию Отличного Веб-Сайта
19 Oct, 24 -
Новый Калькулятор Linux 10.9
19 Oct, 24 -
Хороший, Плохой И Модератор
19 Oct, 24
