Ceph: Настройка scrub и снижение его влияния на производительность
Обычно не пишу о том, что и так известно почти всем или если это хорошо освещено. Но недавно в одном популярном русскоязычном telegram-чате посвященном Ceph обсуждалась проблема scrubbing’а и я понял, что все таки знаю кое что, что еще не известно всем) Решил написать заметку посвященную данной теме.
Scrub — служебный механизм призванный проверять целостность копий данных в кластере RADOS. Процесс scrubbing’а идет фоном и циклически перебирает все данные сравнивая одну копию данных на одной OSD с другой копией на другой(или других) OSD.
Проверок бывает два типа: простая(scrubbing) и глубокая(scrubbing+deep)
В рамках простой проверки сверяются только атрибуты фалов и их размер, этот тип проверки безобиден и практически ни оказывает никакого влияния на работу кластера и по этому проводится с частотой в сутки.
При глубокой проверке(scrubbing+deep) проверяемые данные считываются с дисков, считается их контрольная сума и сверяется. Собственно чтение данных и есть проблема. Такие проверки идут с интервалом в неделю.
Естественно проверки не запускаются разом на все данные. В таком случае все вставало бы колом) Разные PG проверяются в разное время. Этот процесс идет не прерывно, сейчас одни проверяются, затем другие а через время опять первые и так без конца.
Так вот когда в кластере появляется нормальное количество данных и они активно используются то вы заметите влияние scrubbing’а даже без мониторинга)
Под нормальным объемом данных я подразумеваю не какой то общий объем данных в кластере а заполненность используемых дисков. Например если у вас диски размером в 2Tb и они заполнены на 50-60 или более процентов то у вас много данных в Ceph, даже если дисков всего шесть). Это моя субъективная метрика но по моему 3-х летнему опыту работы с Ceph в проде — это самый важный критерий.
Собственно когда наши диски достигли такой утилизации мы стали замечать просадки производительности и повышенные задержки во время идущего scrubbing’а. Возможно если бы у нас были SSD мы жили бы счастливо но у нас обычные SATA диски с журналами на SSD.
Так вот, scrubbing. Когда во время идущего скраббинга приходит пользовательская нагрузка на те же OSD что в процессе скраббирга, не заметить это сложно, особенно если у вас есть внешний мониторинг.
Изменение расписания scrubbing’а
Первое что можно сделать это задать расписание для scrubbing’а, отведя для него время где нибудь ночью, например с 00.00-08.00.
Задать в рантайме(без рестарта OSD):
Это сразу изменит ситуацию к лучшему но не надолго. Опять же если у вас много данных то они просто не будут успевать проходить scarbbing в отведенное время. Если какие то PG не успеют пройти scrubbing за 7 дней то он будет запущен принудительно в любое время. Так мы увидели идущий скраббинг в дневное время). Увеличивать установленное время без скраббинга нельзя т.к. он очень важен для сохранности данных. Так мы кстати еще раз получили подтверждение, что у нас много данных.
Раз скраббинг все же идет в итоге в дневное время и мешает нормальной работе сервиса то ничего не остается как искать пусти его ограничения.
Снижение приоритета с помощью CFQ
Необходимо сменить планировщик у всех OSD-дисков на CFQ:
и установить следующие параметры для всех OSD:
Задать в рантайме(без рестарта OSD):
Этот подход используют очень многие и кому то он помогает. Нам он не помог практически ни как. Мы довольно долго его тестировали но периодические просадки производительности и взлет летенси никуда не делись.
Уменьшение порции данных одного scrubbing’а
Это то ради чего написана эта заметка. Я нигде не видел статей или обсуждений на эту тему, но это то что избавило нас от проблем связанных со скраббингом.
Суть в том, что бы позволить scrubbing’у идти круглые сутки но читать данные очень мелкими порциями максимально снижая нагрузку на OSD в момент времени.
Задать в рантайме(без рестарта OSD):
При использовании этого подхода, на мой взгляд лучше сменить планировщик на deadline.
Данный подход представлен в этой статье как один из вариантов и возможно для вас окажется не таким эффективным как для нас. В общем попробуйте и решите сами.
Тестирование производительности HP P2000 MSA G3
В одной из наших прошлых статей, посвященной производительности дисковых систем серверов, мы рассказали о методике тестирования и подборе инструмента.
Сейчас же, решили сравнить производительность СХД начального уровня и массива на контроллере P410. Напомню, что интересующие нас параметры: IOPS — количество дисковых операций в секунду (чем больше, тем лучше) и latency — время обработки операции (чем меньше, тем лучше).
Тестировали все той же утилитой fio под Debian GNU/Linux по методике, описанной в предыдущей статье, используя тот же самый инструментарий. Все так же обращаемся к raw-device через libaio.
Конфигурация следующая: объем LUN’ов равен объему Vdisk’a и во всех конфигурациях используется RAID10, включен multipathing, подключение через Fiber Channel.
Тестировали с наращиванием количества потоков от 16 до 256, дабы отловить, где начинаются нехватки производительности. Длительность каждого теста 40 минут.
Итак, рассмотрим результаты на примере профиля OLTP-DB, проиллюстрировав зависимость IOPS и отзывчивости системы от количества потоков:
Размер блока 4KB, 70%/30% чтение/запись, 100% случайный доступ
Глядя на верхний график, становится понятно, как можно оценить производительность системы в отрыве от latency: как только рост количества IOPS застопорился, мы получили результат и дальше расти будет только latency.
Неожиданным оказалось, что массив из восьми дисков показывает куда более высокую производительность чем СХД с тем же количеством носителей, и особенно хорошо это заметно с ростом нагрузки. MSA P2000 забуксовала на 64 потоках, тогда как рост количества IOPS’ов на контроллере P410 прекратился на 128.
Также прекрасно видна зависимость производительности системы от количества жестких дисков в массиве. Здесь, думаю комментарии излишни.
А вывод из этого можно сделать следующий: данную СХД имеет смысл использовать, когда требуется большая гибкость по распределению дискового пространства между виртуальными или физическими серверами и нужна возможность подключить большое количество жестких дисков, в том числе и через полки расширения. Однако, надеяться на то, что все это будет работать быстрее локального дискового массива сервера с тем же количеством дисков, увы, не приходится.
И, как всегда, выкладываем детальный файл с результатами.
Конфигурируем дисковые системы HP StorageWorks MSA 2000sa
Виртуальные диски
Объем виртуального диска может превышать 2 Гбайт, поэтому, создавая диски большого объема в массивах RAID с контролем четности, число служебных дисков можно сократить, однако в общем случае для работы с логическими томами объемом свыше 2 Тбайт могут потребоваться специальные версии операционных систем, адаптеров НВА и поддержка прикладных программ.
Кстати, устройство MSA2000sa поддерживает виртуальные диски объемом до 16 Тбайт. В RAID 0,3,5,6, 10 может быть до 16 дисков (1 Тбайт на устройство SATA, или всего 16 Тбайт). В RAID 50 может быть до 32 дисков (1 Тбайт на устройство SATA, или всего 32 Тбайт).
При организации больших объемов внешней памяти следует тщательно взвесить преимущества и недостатки нескольких укрупненных виртуальных дисков по сравнению с большим числом менее «емких» виртуальных дисков с меньшим количеством накопителей. Чтобы увеличить КПД дисковой памяти (но не производительность), можно создать виртуальные диски объемом больше 2 Тбайт и разделить их на несколько логических томов объемом до 2 Тбайт. Максимально поддерживаемый объем виртуального диска определяется произведением количества дисковых устройств в данной конфигурации RAID на наибольший объем одного устройства.
Лучше всего добавлять виртуальные диски, распределяя их равномерно по обоим контроллерам. Если к каждому контроллеру подсоединить хотя бы по одному виртуальному диску, контроллеры начинают работать по принципy «активный-активный» (active-active). Подобная конфигурация обеспечивает эффективность использования ресурсов в случае применения двух контроллеров в системе хранения MSA2000sa. Кроме того, для предотвращения потери данных при отказе дисковой полки (shelf enclosure) надо целиком сделать «страйпинг» (stripe) виртуальных дисков по нескольким дисковым полкам. Виртуальный диск с конфигурацией RAID 1,10,3,5,50 в зависимости от числа задействованных дисковых полок может противостоять угрозе потери данных при выходе из строя целой дисковой полки.
Рекомендуется устанавливать размер непрерывного фрагмента равным размеру блока данных, которым оперирует приложение.
Выбор уровня RAID для массива зависит от цели оптимизации конфигурации: повышение отказоустойчивости или повышение производительности. Если не требуется отказоустойчивость или производительность, обеспечиваемые применением групп RAID, то разумно воспользоваться конфигурациями без избыточности.
vdisk scrub job failed
I have an MSA2312sa and I am receiving the following critical error:
Vdisk scrub job failed. (vdisk: vdisk00, SN: 00c0ffd8224d0000e26f844a00000000) 1 parity mismatches were detected. It is imperative that you contact technical support. DATA MAY BE AT RISK!
I have update the firmware to R25 and have deletete and recreated the vdisk and still getting the error.
Any help would be appreciated.
We got this error on two MSA2312fc that was recently upgraded to R25. Like the message says I would recommend that you contact HP Support. In our case the solution was to run the following command using CLI: «verify vdisk vd01 fix yes»
The command was run without stopping host access. Just make sure ther is no scrub activity or else it will fail.
I have used the above commands succesfully in the past before, but we upgraded to the latest firmware version (M112R14-02) not so long ago.
After typing the ‘verfiy vdisk fix yes’ I receive a message saying:
«This command will verify data on the array and make parity match the data in all
cases.
Please refer to the Reference Guide (Best Practices for Handling Scrub Issues) for details.
To continue please enter the passcode found in the user documentation. ( =
abort | proper passcode=continue)»
So I have searched all three documents from the User Guide, the CLI User guide and the Reference Guide to no avail. I assume this was added because of the bug with a few firmware versions ago that I myself experienced where there were erroneous ‘errors’ with this parity mis-match.
So where can I find this code or what it is? Or is there a new CLI line to do a ‘force fix’ as it were to a vdisk verify?
Эксплуатация Ceph: что такое Scrub и как им управлять
Scrub — это процесс фоновой проверки консистентности данных в Ceph. Он позволяет выявить и устранить несоответствия в копиях, а также найти рассыпающиеся диски, чтобы вовремя их заменить. При этом сам Scrub может создавать высокую нагрузку на кластер и мешать другим процессам. Сегодня расскажем о настройках, которые помогут оптимизировать его работу и сделать нагрузку практически незаметной.
Статья подготовлена на основе лекции Александра Руденко, ведущего инженера в группе разработки «Облака КРОК». Лекция доступна в рамках курса по Ceph в «Слёрме».
Как работает Scrub
Scrub или scrubbing — это специальный фоновый процесс, который проверяет консистентность данных в placement group. Например, есть пул с тройной репликацией, то есть одна placement group в нём имеет три копии. Данные в этих копиях должны быть полностью идентичны, что и проверяет Scrub.
Если Scrub обнаруживает расхождения (например, в какой-то placement group объект имеет контрольную сумму не такую, как на двух других, либо вообще отсутствует), то возникает ошибка, администратор о ней узнаёт и может исправить.
В Erasure coded pool нет копий, но принцип тот же: Scrub выявляет расхождения в данных, неконсистентность, возникшую по тем или иным причинам. Одна из основных причин — «тихие» повреждения магнитных дисков. Вчера вы записали данные, а сегодня некоторые секторы на диске посыпались и данные оказались повреждены.
Scrub бывает двух типов: обычный и глубокий.
В примере на скриншоте четыре placement groups находятся в состоянии scrubbing, и они же находятся в состоянии scrubbing+deep. «Deep» — это значит глубокий Scrub.
Сначала всегда выполняется обычный Scrub, и только если он завершился успешно, запускается глубокий.
Обычный Scrub проверяет атрибуты и размер объектов. Он проходит быстро и незаметно с точки зрения нагрузки.
Глубокий Scrub читает практически каждый байтик объектов и сверяет их на всех OSD в рамках проверки одной placement group. То есть все данные читаются, проверяются их контрольные суммы и контрольные суммы сверяются. Это достаточно затратный по ресурсам процесс. Он может затрагивать несколько placement group сразу. В примере выше параллельно проверяются данные четырёх placement groups.
Максимальная частота проверки одной placement group — раз в сутки, чаще Scrub не запускается. При этом у процесса есть дедлайн: одна placement group должна быть проверена в течение недели. То есть Scrub может проходить раз в сутки, но не реже раза в семь дней. Если placement group не проверялась больше семи дней, то возникает сообщение об ошибке.
Пример такого сообщения на скриншоте. Здесь показано, сколько placement group не успело пройти проверку в отведённые 7 дней.
Когда Scrub находит различие в данных в одной placement group, возникает такая ошибка:
Первая строчка показывает, что есть ошибки scrub error, и сколько их. Вторая строчка говорит, в скольки placement group обнаружена неконсистентность данных. Такие алерты может выдавать только Scrub. По-другому вы не узнаете, что placement group в неконсистентном состоянии.
Фактически алерт говорит: по какой-то причине данные некорректно записались на одну OSD и нужно запустить процесс repair — восстановление консистентности.
Мы считаем процесс Scrub очень важным ещё и потому, что он позволяет выявлять повреждения дисков.
Во время проверки данные placement group читаются целиком. То есть в течение 7 дней 100% данных кластера оказываются прочитаны и сверены на разных OSD. В результате мы получаем проверку состояния дисков: способны ли они отдавать данные, работает ли чтение с них.
Scrub читает данные, которые пользователь, возможно, не читал несколько месяцев и не будет читать ещё год. Если при чтении на диске возникает проблема (например, сектор магнитного диска отказал), то это провоцирует ошибку.
В логе ядра Linux мы видим ошибку типа input/output error. Ceph сообщает, что возникла ошибка при проверке. В мониторинге появляется алерт, в котором фигурирует идентификатор диска. Мы понимаем, что на нём возникли input/output-ошибки, внимательно его смотрим и практически всегда меняем.
Управление проверкой
Если Scrub заканчивается с ошибкой, нужно выяснить детали: какая именно placement group в неконсистентном состоянии и на каких OSD она сейчас находится. Сделать это можно следующей командой:
Вывод будет примерно такой:
После этого можно пойти в логи ядра конкретной OSD и проверить. Скорее всего там обнаружится ошибка ввода/вывода и станет понятно, что диск нужно менять.
Чтобы узнать, какую именно ошибку выдал Scrub, используйте команду:
В длинном выводе будет примерно такая секция, как на скриншоте ниже. В ней показаны OSD и состояния проблемного объекта на них.
На скриншоте видно, что на двух OSD (875 и 925), в том числе и на primary, объект есть, у него есть есть контрольная сумма, а вот на третьей (463) его просто нет.
Когда есть primary-копия, и она корректная, можно запустить восстановление командой:
Процесс repair может идти несколько часов. После этого в логе Ceph можно будет найти эту placement group по id и увидеть результат восстановления. Там будет написано, сколько ошибок исправлено, а сколько нет. Но когда большинство данных в порядке и повреждена только одна копия, процесс repair без проблем восстанавливает объект, беря его из primary OSD.
Оптимизация проверки
При всей полезности у скраббинга есть недостаток — он создаёт большую нагрузку. Когда идёт глубокий Scrub, данные из placement group читаются, чтение этих данных никак не отражается в системах мониторинга (это внутреннее io) и этот идущий Scrub может создавать нагрузку сам по себе. Раньше это была колоссальная нагрузка.
Кластеры на более ранних версиях сильно страдали от проверки. Scrub был невероятной проблемой. Можно было встретить много статей, как его лимитировать, чтобы он шёл медленнее и не создавал такую нагрузку.
Сейчас Scrub в Ceph стал более интеллектуальным, к нему прикрутили много параметров, которые позволяют его оптимизировать и практически в любом кластере сделать так, чтобы нагрузка от него не была сильно заметна.
Рассмотрим некоторые из этих параметров. Посмотрим на osd параметры, в которых есть слово “scrub”, так увидим все связанные с ним настройки.
“osd_max_scrubs” — определяет, сколько placement group может параллельно «скрабить» одна OSD. По умолчанию стоит значение “1”, то есть Scrub максимально зажат.
Есть параметры, которые полезно настроить с самого начала:
“osd_scrub_begin_hour” и “osd_scrub_end_hour”. В нашем примере в первом параметре стоит значение “0”, во втором “24”, то есть процессу разрешено идти в любое время.
Поменяем значения: поставим время начала “02”, время окончания “08”:
Таким образом мы задаём желательный интервал времени для проверки.
Но есть важный момент: это будет работать хорошо только поначалу. Как только какие-то placement group не смогут из-за этого интервала успевать «скрабиться» в течение недели, Scrub будет запускаться сразу по истечении недельного срока, независимо от ограничений по времени. Дедлайн для Scrub критичнее, чем эти интервалы.
Иными словами, этими параметрами вы задаёте время, когда вы хотели бы, чтобы Ceph делал Scrub, если он может это делать. Если у него настал дедлайн для какой-то placement group, то он проигнорирует интервалы, потому что дедлайн критичен.
“osd_scrub_sleep” — ещё один важный параметр. Для обычного скраба его значение “0.00000”. Можно задать “0.1”, хотя для обычного Scrub это не особо важно.
“osd_debug_deep_scrub_sleep” — задаёт sleep для Deep Scrub. По умолчанию его значение тоже “0”, но мы его у себя ставим “0.2”.
Меняется значение параметра аналогично:
Нужно понимать, что настройки Scrub в каждом кластере индивидуальны. Очень большие кластеры могут даже с дефолтными настройками не испытывать проблем. На кластерах меньшего размера он может быть заметен сильно. А если это кластер небольшого размера и у него ещё очень интенсивное io, то Scrub может быть проблемой.
“osd_scrub_chunk_max” и “osd_scrub_chunk_min” — это самые важные параметры, определяющие интенсивность проверки; то, что сильно зажимает или отпускает Scrub.
Если задать такое значение, то интенсивность идущего скраба упадёт в 5 раз — настолько медленнее будут читаться данные.
Хотя скорее всего, вы не заметите никакого эффекта, но получите алерты о том, что placement group не успевают пройти Scrub вовремя. Просто потому что слишком мало объектов берётся за одну итерацию, слишком медленное чтение.
Этими параметрами вы можете играть, задавая различные значения, чтобы достигнуть того баланса, когда Scrub успевает проходить за неделю и при этом не создаёт видимой нагрузки. Они меняются на лету, и вы можете ими в любой момент ускорять или зажимать Scrub.
“osd_scrub_auto_repair” — ещё один интересный параметр. В начале статьи вы видели ошибку о том, что placement group в состоянии inconsistent. Если в значении этого параметра поставить “false”, то Ceph запустит repair на эту placement group, но только если количество ошибок до 5. Если ошибок больше, то он не запустит автоматический repair, будет висеть ошибка, и вам надо будет посмотреть, что же произошло. Ceph считает, что повреждённых объектов слишком много, чтобы их автоматически чинить. Нужно разобраться, в чём дело.
“osd_scrub_during_recovery” — это относительно новый параметр. Если он активирован, то Scrub не будет запускаться, когда на OSD запущен backfilling, то есть идёт recovery io. Если у вас будет настроен когда-нибудь мониторинг текущего количества скрабов, то вы сможете увидеть, как во время запущенного rebalance график скрабов начинает стремительно снижаться.
Scrubbing io старается не конфликтовать с recovery io, и это ещё одна причина, по которой Scrub может откладываться. Если вы в течение недели делаете сильный rebalance — увеличиваете число placement group, добавляете сервер — Scrub откладывается, и через неделю вы получите множество сообщений о том, что Scrub не успел пройти за неделю, и вам нужно будет его либо ускорить, либо ждать, пока он «рассосётся».
Общая рекомендация: если вы видите проблему аномальной производительности в кластере и не понимаете, в чём дело, вы всегда можете отключить Scrub с помощью флагов:
Кроме того, скраб можно отключать для конкретного пула. Если у вас несколько пулов, и вы хотите для конкретного пула отключить скраб, то это можно сделать командой:
Флаги отразятся в claster health:
Эти флаги блокируют новый Scrub, но уже запущенные проверки не отклоняются и будут завершены. Когда текущие проверки закончатся, вы сможете оценить, изменилась ли ситуация с производительностью.
Если проблема исчезла, значит вам нужно немного зажать Scrub. Если сохранилась, то дело не в Scrub, его можно запускать снова и искать другую причину аномальной производительности.
