Erasure coding в схд что это
Glusterfs + erasure coding: когда надо много, дешево и надежно
Гластер в России мало у кого есть, и любой опыт интересен. У нас он большой и промышленный и, судя по дискуссии в прошлом посте, востребованный. Я рассказывал о самом начале опыта переноса бекапов с Enterprise хранилища на Glusterfs.
Это недостаточно хардкорно. Мы не остановились и решили собрать что-то более серьёзное. Поэтому здесь речь пойдёт о таких вещах, как erasure coding, шардинг, ребалансировка и её троттлинг, нагрузочное тестирование и так далее.
Что хотели
Задача простая: собрать дешёвый, но надёжный сторадж. Дешёвый насколько можно, надёжный — чтобы не было страшно хранить на нём наши собственные файлы прода. Пока. Потом, после долгих тестов и бекапов на другую систему хранения — ещё и клиентские.
Применение (последовательное IO):
Как и прошлый раз, главное требование — скорость сети между инстансами Гластера. 10G поначалу — нормально.
Теория: что такое dispersed volume?
Dispersed volume основан на технологии erasure coding (EC), что обеспечивает достаточно эффективную защиту от сбоев дисков или серверов. Это как RAID 5 или 6, но не совсем. Он хранит закодированный фрагмент файла для каждого брика таким образом, что для восстановления файла требуется только подмножество фрагментов, хранящихся на оставшихся бриках. Количество бриков, которые могут быть недоступны без потери доступа к данным, настраивается администратором во время создания тома.
Что такое сабволюм (subvolume)?
Сущность сабволюма в терминологии GlusterFS проявляется вместе с distributed волюмами. В distributed-disperced erasure coding будет работать как раз в рамках сабволюма. А в случае, например, с distributed-replicated данные будут реплицироваться в рамках сабволюма.
Каждый из них разнесён на разные сервера, что позволяет их свободно терять или выводить на синк. На рисунке зелёным отмечены сервера (физические), пунктиром — сабволюмы. Каждый из них представлен как диск (том) серверу приложений:
Было решено, что конфигурация distributed-dispersed 4+2 на 6 нодах выглядит достаточно надежно, мы можем потерять 2 любых сервера или по 2 диска в рамках каждого сабволюма, продолжая иметь доступ к данным.
В нашем распоряжении было 6 стареньких DELL PowerEdge R510 с 12 дисковыми слотами и 48×2ТБ 3.5 SATA дисков. В принципе, если есть сервера с 12 дисковыми слотами, и имея на рынке диски до 12тб мы можем собрать хранилку размером до 576тб полезного пространства. Но не забывайте, что хоть максимальные размеры HDD продолжают из года в год расти, их производительность стоит на месте и ребилд диска размером 10-12ТБ может занять у вас неделю.
Создание волюма:
Подробное описание, как подготавливать брики, вы можете прочитать в моём предыдущем посте
Создаем, но не спешим запускать и монтировать, так как нам еще придется применить несколько важных параметров.
Всё выглядит вполне нормально, но есть один нюанс.
Он заключается в записи на брики такого волюма:
Файлы кладутся поочерёдно в сабволюмы, а не равномерно размазываются по ним, следовательно, рано или поздно мы упрёмся в его размер, а не в размер всего волюма. Максимальный размер файла, который мы можем положить в это хранилище, = полезный размер сабволюма минус уже занятое на нём пространство. В моем случае это
Резервное копирование с Software-defined Storage и Erasure Coding – стоит ли игра свеч?
По мере роста активности программ-вымогателей, таких как Petya или BadRabbit, а также в связи с ужесточением требований законодательства (например, как раз вступившим в силу №187-ФЗ «О защите критической информационной инфраструктуры») объемы данных для резервного копирования постоянно увеличиваются. В результате растет стоимость инфраструктуры хранения резервных копий. Такие технологии как Erasure Coding могут кардинально снизить затраты на их хранение. Сегодня мы расскажем насколько именно и о том, как построить Backup на базе Erasure Coding.
Про коды Рида-Соломона, как наиболее эффективный метод хранения больших объемов информации в программно-определяемых СХД (software-defined storage — SDS), говорили и писали уже очень много. Но резервное копирование – это один из идеальных сценариев для использования Erasure Coding (EC), так как резервная копия представляет собой большой по объему файл, который записывается и читается последовательно. Несмотря на все большее распространение SDS, их не так часто используют для хранения резервных копий, так как SDS по умолчанию используют традиционную репликацию для защиты пользовательских данных, что требует в 2 или 3 раза больше места на дисках по сравнению с «чистым» объемом информации. Как следствие, такое решение задачи крайне неэффективно.
В распределенных системах хранения, к которым относится и наш Virtuozzo Storage, а также любые современные программно-определяемые СХД, для каждого блока данных создается одна или две копии, и все они размещаются на разных серверах в зависимости от нагрузки, близости к источнику данных и других факторов, влияющих на производительность и отказоустойчивость. При использовании Erasure Coding данные разбиваются на несколько блоков, распределяются между узлами кластера. Кроме этого создаются две или три контрольные суммы, что дает возможность так же, как и при использовании реплик, сохранить данные даже при отказе двух серверов или дисков одновременно, но при этом сэкономив дисковое пространство, уменьшая избыточную емкость в несколько раз.
Например, при наличии кластера из 5 северов, для того, чтобы обезопасить себя от выхода из строя двух из них, вам потребуется использовать либо 3 реплики в случае репликации, либо Erasure Coding по схеме 3 (блока) +2 (хеша). Допустим, вы сохраняете 100ГБ, тогда ваши данные вместе с репликами займут целых 300ГБ, а при использовании EC эта емкость будет сокращена примерно до 170ГБ. И чем больше в вашем кластере серверов, тем больше вы экономите места. Например, в случае кластера из 20 серверов, избыточное использование диска будет всего лишь около 20%.
Да, в некоторых сценариях использование Erasure Coding ведет к снижению производительности приложений, но, как оказалось, в случае резервного копирования все наоборот – это приводит к увеличению скорости создания резервной копии. И учитывая, что в коммерческих решениях Erasure Coding часто является платной опцией, а производительность его все еще остается под вопросом, далеко не все решаются попробовать программно-определяемую СХД для хранения резервных копий. И мы сейчас покажем, что совершенно напрасно.
И все же, что там с производительностью?
Мы провели тестирование скорости резервного копирования при использовании Erasure Coding в двух конфигурациях – на кластере #1, состоящем из 6 узлов и на кластере #2, составленном из 12 узлов. Применение схемы Erasure Coding происходило на базе стандартного функционала Virtuozzo Storage, а конфигурации серверов были следующими:
В первом кластере, который был запущен на 6 узлах, разместились 42 жестких диска (chunk service), по 7 дисков в каждом сервере. Мы использовали стандартные диски SATA со скоростью вращения шпинделя 7200 об/мин. Для каждого из них был создан журнал на SSD дисках NVMe по 32 Гб (всего 224 ГБ на сервер), а размер клиентского кэша для данного кластера составил 64 ГБ на каждую точку монтирования. В качестве ПО резервного копирования мы использовали встроенное решение из Virtuozzo 7.
Результаты измерений показали, что пропускная способность такого кластера из 6 узлов для задачи резервного копирования при использовании Erasure Coding оказывается в 1,6 раза выше по сравнению с традиционной репликацией.
По мере увеличения кластера эффект только усиливается, даже если вы берете более производительные жесткие диски. Так, кластер #2 состоял уже из 12 узлов, в каждом из которых было расположено по 11 высокоскоростных дисков SAS со скоростью вращения шпинделя 15 000 об/мин. В связи с этим был уменьшен размер журналов на SSD дисках NVMe (16 ГБ на chunk service или 176 ГБ на узел). Однако результаты показали, что пропускная способность (а значит и скорость) резервного копирования в кластере оказалась втрое выше при использовании EC, чем при репликации данных.
Почему так происходит? На самом деле ответ прост: в отличие от других, быть может, более сложных задач, резервное копирование представляет собой фактически последовательную запись данных (Sequential write). И в случае с EC кластеру нужно записать меньше лишних данных. При использовании стандартной схемы репликации с 3 репликами требуется трижды записать информацию (оригинальный блок и две копии), а Erasure Coding записывает всего на 20% больше данных, чем размер исходного файла. И чем больше будут потоки данных, тем более заметным окажется эффект от использования Erasure Coding.
Более того, в распределенных системах хранения именно сетевые интерфейсы часто оказываются самым узким местом. Ведь канал в 1 Гбит/с может обеспечить передачу данных со скоростью 110-120 Мбайт/с, что приблизительно соответствует возможностям только одного жесткого диска при последовательной записи/чтении. Поэтому использование EC оправдывает себя как средство повышения эффективности кластера, снижая нагрузку на сетевую подсистему именно в сценариях резервного копирования. Для хранения небольших объемов не высоко востребованных данных можно использовать сетевые адаптеры 1 Гбит/с, хотя для продуктивных нагрузок мы, конечно, рекомендуем сетевые адаптеры 10 Гбит/с.
Используйте бесплатно
Вопрос с производительностью решен – Erasure Coding действительно справляется с резервным копированием быстрее, чем репликация, при этом существенно экономя дисковое пространство, а значит – ресурсы серверов, дисков и сетевых портов. Сколько это стоит? В случае с Virtuozzo Storage вы можете использовать Erasure Coding бесплатно – он включен в нашу стандартную лицензию. Erasure Coding это всего лишь опция при создании тома данных для контейнеров и виртуальных машин Virtuozzo, iSCSI, NFS или объектного хранилища. Если у вас уже используется Virtuozzo Storage, включить EC можно моментально и сразу же получить все преимущества от использования технологии. А если вы используете Virtuozzo вместе с Virtuozzo Storage, то и само ПО резервного копирования уже включено в вашу лицензию.
Как мы смогли убедиться на примерах, приведенных выше, при необходимости защищать большие объемы данных, Erasure Coding помогает одновременно и сэкономить, и уменьшить время, затрачиваемое на создание резервных копий. Если же вы активно используете объектное хранение, например, Amazon S3-совместимый Object Storage, то Erasure Coding тем более становится лучшим выбором для такого рода нагрузок. И не забывайте, никто не отменял возможность одновременно использовать репликацию для наиболее горячих данных.
Object Storage — Ближайшее будущее систем хранения данных
Девять лет назад «Международный день телекоммуникаций» был переименован в «Международный день телекоммуникаций и информационного общества». Для золотого миллиарда будущее уже наступило: интернет стал одной из важнейших частей нашей жизни. Ежесекундно по всему миру создаются и потребляются колоссальные объёмы информации, а рынок всевозможных онлайн-сервисов является одним из самых быстрорастущих.
Одной из главных тенденций последнего времени стало развитие облачных технологий. Они используются повсеместно, от файлообменников и видеохостингов до мобильных приложений, сервисов заказа услуг и внутренних корпоративных систем. Подавляющее большинство подобных проектов оперируют неструктурированной информацией, причём ёмкость файловых хранилищ ежегодно увеличивается примерно на 53%. И с ростом объёмов генерируемой и хранимой информации трансформируются и требования к системам хранения данных.
По прогнозу компании Cisco, в 2016 году объём мирового интернет-трафика достигнет 1,1 зеттабайта (в среднем 91,3 экзабайта в месяц). И к 2018 году половина мирового интернет-трафика придётся на сети доставки контента. Мобильный сегмент также переживает этап бурного развития. По данным той же Cisco, в 2014 году мобильный трафик вырос на 69%, достигнув 2,5 экзабайт. И уже в 2012 году половину мобильного трафика составляло видео.
С ростом объёмов хранимой и передаваемой информации на первый план, помимо надёжности, выходят простота архитектуры, лёгкость масштабирования и высокая производительность. Однако сложность архитектур (блокировки, репликация, высокая доступность) и доступа в распределённых сетях, большое разнообразие оборудования и технологий, предназначенных для хранения разных типов данных, снижают эффективность традиционных файловых СХД и делают их слишком дорогими в обслуживании и масштабировании.
Например, при хранении текстовой и визуальной информации (графика, видео) обычно используют две базы данных: отдельно для текста и для контента. Но при размере в сотни терабайт производительность и отказоустойчивых контентных БД существенно снижается.
В результате всё большую популярность обретают объектные СХД, лишённые недостатков файловых хранилищ, обеспечивающие высокую производительность и отказоустойчивость при работе с большим объёмом неструктурированных данных. Одним из подобных решений является EMC Elastic Cloud Storage (ECS).
Архитектура Elastic Cloud Storage
EMC ECS — это программно-определяемое хранилище, которое может поставляться как в виде программного решения, так и программно-аппаратной системы.
В основе системы лежит программный модуль хранения неструктурированных данных. Он может устанавливаться на любое стандартное оборудование. На данный момент модуль хранения обеспечивает управление объектными данными и HDFS.
Важными особенностями ECS является неограниченная масштабируемость системы с помощью простого добавления новых узлов. А за счёт исключения единой точки отказа обеспечивается высокая доступность.
В ECS обеспечивается одновременный доступ к данным через различные интерфейсы, а также совместимость с такими API, как Amazon S3, OpenStack Swift, EMC Atmos и Centera CAS. Кроме того, поддерживаются и расширения API: Byte-Range updates, Atomic appends, Rich ACLs и т.д.
Модуль хранения данных может вести журналирование, делать снэпшоты и отслеживать версионность. Все данные хранятся в логических контейнерах — чанках (chunk). Размер каждого чанка составляет 128 Мб. При этом все операции защиты данных осуществляются с чанками, а не с самими объектами.
Информация о хранящихся объектах — их имена и адреса чанков — хранится в индексе. При этом каждый объект получает уникальное имя, а само пространство имён является единым для всех узлов системы, где бы они ни находились. Индекс также хранится в чанках, а его актуальные копии доступны на каждом узле системы.
Алгоритмы записи, чтения и обновления данных
Давайте рассмотрим подробнее, как в ECS осуществляется запись, чтение и обновление данных.
Здесь всё просто: после получения запроса на чтение, модуль хранения получает из индекса информацию о расположении объекта, считывает его и отправляет пользователю.
Поскольку в ECS данные не перезаписываются и не изменяются, то обновление уже имеющихся объектов осуществляется в диапазоне байтов. После этого модуль хранения обновляет информацию об объекте в индексе, а старая версия помечается для последующего фонового удаления.
Процесс Erasure code
Этот процесс применяется только к полностью заполненным чанкам. Он осуществляет кодирование данных для защиты от потерь и снижения избыточности. Не кодируется только индекс, поскольку система постоянно обращается к нему. Поэтому защита индекса осуществляется с помощью трёхкратной репликации в разные чанкы и кэширования в памяти.
В основе Erasure process лежит алгоритм Рида-Соломона. Чанк разбивается на 16 модулей, — 12 модулей данных и 4 модуля кода, — которые записываются на разные узлы. При этом чем больше количество узлов, те выше отказоустойчивость. Обратите внимание, что блоки записываются в одном экземпляре.
Процедура декодирования используется только для восстановления после сбоев, для операций чтения этого не требуется. Более того, для чтения небольших объектов системе даже не нужно обращаться ко всем содержащим его чанкам. Всё это положительно сказывается на общей производительности системы.
Защита данных и доступ с нескольких площадок
В ECS применена распределённая защита данных, состоящая из двух компонентов: модуля защиты и механизма управления избыточностью. Для защиты от сбоя на площадке используется резервное копирование каждого чанка:
Механизм управления избыточностью работает в фоновом режиме. Для уменьшения количества копий между площадками применяется сжатие данных с помощью операции XOR.
После создания набора данных Е, исходные наборы A и D удаляются. В случае возникновения сбоя на одной из площадок, извлекается тот набор данных, что стал недоступен. Для этого второй из исходных наборов снова пересылается на площадку, где хранится сжатый набор. Восстановленный из копии набор копируется на другую площадку.
В отличие от традиционных систем, в которых данные реплицируются на несколько площадок, в ECS избыточность снижается по мере увеличения количества площадок.
В результате всех применяемых мер, данные сохраняются даже при выходе из строя одной площадки целиком. А в системе из 8 и более площадок возможен безболезненный выход из строя двух узлов на каждой площадке. Также каждая площадка позволяет осуществить локальный ребилд, что позволяет снизить нагрузку на сеть и увеличить производительность в случае сбоя.
Механизм распределённой защиты, помимо своей основной функции, в сочетании с глобальным пространством имён позволяет записывать и читать данные с любой из площадок, вне зависимости от их реального расположения. При этом в ECS обеспечивается строгая консистентность данных между всеми площадками.
ECS Appliance
Зачастую многие компании создают объектные хранилища своими силами, на базе типового оборудования и Open Source-продуктов. Причина очевидна — экономия. Однако максимальная дешевизна может обернуться низкой надёжностью. Кроме того, поддержка работоспособности как оборудования, так и Open Source-решений целиком и полностью ложится на самих пользователей.
Как уже упоминалось, ECS может поставляться в виде программно-аппаратного комплекса ECS Appliance. Он полностью изготовлен из типовых элементов: 4 server nodes in 2U и 3,5-дюймовых SATA-дисков. Притом доступно 2 конфигурации.
U-Series – диски с данными находятся в подключенных дисковых полках.
Доступны пять конфигураций, различающиеся количеством серверов и дисков.
C-Series – диски с данными находятся в самих серверах. Расширение производится однотипными 2U модулями.
При данном типе поставки осуществляется поддержка как программного обеспечения, так и оборудования. Масштабирование СХД возможно, как путём простого добавления новых стоек ECS Appliance, так и стороннего оборудования. Однако в последнем случае развёртывание и настройку ECS делает сам пользователь.
Эксплуатация Ceph: как распределять пулы по разным типам (HDD/SSD) и группам серверов
В Ceph можно распределять пулы с данными по разным типам серверов: «горячие» данные хранить и реплицировать на SSD, «холодные» — на HDD. Кроме того, пулы одного кластера можно разделять физически. В статье расскажем, как это сделать.
Статья подготовлена на основе лекции Александра Руденко, ведущего инженера группы разработки «Облака КРОК». Лекция доступна в рамках курса по Ceph в «Слёрме». Тема была добавлена уже после релиза видеокурса, в январе 2021. Также в январе в рамках развития курса появились новые практические задания:
Зачем распределять пулы по разным устройствам и группам устройств
Размещение пулов на разных устройствах (HDD/SSD) нужно, чтобы использовать оборудование более эффективно. Например, когда в кластере есть и магнитные диски, и SSD, логично разместить индексный пул или пул с метаданными файловой системы на SSD, а пулы с данными — на HDD.
Физическое размещение пулов на разных серверах используют, когда нужно, чтобы у каждого пула был разный домен отказа, а также когда надо распределить данные по разным серверам одного типа. Например, кластер состоит из магнитных дисков, но часть из них это небольшие SAS-диски с 15000 RPS, а другая часть — большие и медленные диски с черепичной записью. На быстрых размещают «горячие» данные, на медленных — «холодные».
Второй сценарий менее распространённый, поэтому начнём с него.
Физическое размещение пулов на разных серверах
Для примера возьмём кластер с простой CRUSH-топологией: есть root — так называемый корневой элемент, внутри него есть 3 хоста и какое-то количество OSD. Стоек и дата-центров нет. Это простая дефолтная топология, которая появляется при создании кластера.
Есть пулы, часть которых RGV создал сам, часть созданы вручную.
Что такое пул в Ceph
В Ceph при создании кластера и пулов нет возможности сказать: «создай мне кластер вот на этих серверах» или «используй диски с этих серверов, чтобы размещать данные этого пула». Потому что пул в Ceph — это высокоуровневый каталог с практически плоским пространством объектов. Есть группировка по стойкам, дата-центрам и OSD, но в целом это единое пространство или группа object stores.
В некоторых других системах хранения сначала создаётся пул, а потом в него добавляются ресурсы. Пользователь говорит: «добавь вот этот диск вот в этот пул, добавь вот этот сервер вот в этот пул» — то есть пул как бы собирается из какого-то количества ресурсов. Это более понятная концепция.
В Ceph всё иначе. Здесь пул — это просто каталог, который нельзя настроить так, чтобы он задействовал только часть ресурсов. Созданные пулы по умолчанию «размазываются» по всем дискам серверов. Внутри кластера могут быть медленные диски, SSD, серверы с 60-ю дисками — неважно, данные пула размажутся по всем серверам и OSD в зависимости от веса.
Разместить пул на выделенных серверах в Ceph нельзя. Предположим, нужно добавить в кластер 3 сервера и разместить на них особый пул, данные которого не будут попадать на соседние серверы. Доступным инструментарием Ceph сделать это невозможно. Да, можно отредактировать CRUSH, но это сложно и чревато разрушением кластера, поэтому делать так не рекомендуют. Рассмотрим более безопасный способ.
Как изолировать пул на группе хостов:
Посмотрим на примере: допустим, есть хост, и на этом хосте нужно разместить определённый пул. Для начала создадим объект хоста.
В нашем примере нужно создать объект с именем node 4 и типом host.
Объект создан, он появился вне дефолтного дерева.
Теперь надо создать новый root. Синтаксис команды тот же, меняется только имя и тип объекта.
Новый root появляется на том же уровне, что и host — вне дефолтного дерева.
Созданы две сущности, которые никак друг с другом не связаны, но в нормальной иерархии host находится внутри root. Чтобы их связать, надо переместить хост node4 в новый root.
Новый сервер добавлен и правильно размещен в иерархии, значит можно добавить OSD с этого сервера.
У нас есть готовый диск (называется “vdb”), из которого можно сделать OSD.
Сначала сотрём заголовки:
Получим бутстрапный ключ. Он нужен, чтобы сгенерировать персональный ключ для создания OSD.
Запустим создание OSD:
При создании OSD автоматически включается в CRUSH-иерархию: её хост добавляется в CRUSH-дерево. То есть можно было просто запустить создание OSD, и она бы создала запись в CRUSH для себя и своего хоста. Возможно, он был бы в дефолтном root’е, и нам бы пришлось его перемещать, но это не проблема.
OSD появилась в списке. Обратите внимание: ей присвоен следующий по счёту номер (в нашем случае — 9). То есть это не какое-то новое исчисление OSD, пространство идентификаторов OSD остаётся единым.
В нашем примере создан только один хост, так как для эксперимента больше не нужно. Но в принципе можно добавить сколько угодно хостов, OSD и получить отдельные, совершенно независимые деревья.
Для проверки выполним команду:
Новая OSD зарегистрирована, и у нее ноль плейсмент групп (placement groups, PGS).
Новая OSD содержит ноль placement groups, потому что из первого дерева они ей не передаются. Разные root’ы — это физически разная топология. У них общие только мониторы и менеджеры.
Placement groups появляются вместе с пулами, в этом root’е мы ещё не создавали пулы, поэтому их нет.
CRUSH-топология создана. Теперь нужна политика репликации — распределения данных по этой топологии.
Как создать политику репликации
Дефолтная политика — это репликация по хостам, но можно задать репликацию по стойкам, дата-центрам и т. д.
Создадим политику для root’а через правило распределения данных:
new_root_rule — название политики,
new_root — нужный root,
host — то, как реплицировать данные, в нашем случае по хостам.
Новое правило создано, теперь надо создать новый пул.
В команде надо указать созданное ранее правило ( new_root_rule ) и сколько нужно создавать PGS: первая цифра — количество PGS, вторая цифра — сколько из них доступно для аллокации ( 32 32 ). В Ceph часть placement groups пула могут быть закрыты для аллокации. Например, в пуле 128 PGS, а открыты для аллокации только 32. В нашем примере открыты 32 из 32 групп.
В текущем new_root только одна политика, которая говорит реплицировать данные по хостам. Однако можно создать несколько. Создавая новый пул, надо указывать политику. Таким образом новый пул связывается с конкретным root’ом, который использован в этой политике.
Теперь на OSD аллоцированы все 32 placement groups, которые были заданы.
Все они в статусе undersized и inactive.
Placement group неактивны, так как им недостаточно ресурсов. Новый пул создался с дефолтными правилами, а среди дефолтных глобальных параметров Ceph есть правило “osd_pool_default_size”, и его параметр равен 3. Таким образом пул создался с числом реплик 3.
Затем уменьшить собственно размер:
В результате получится пул с replicated size 1.
Предупреждения о том, что placement groups находятся в статусе inactive и undersized, исчезли. Правда, появилось новое предупреждение: у пула выключена репликация. Но мы не будем на этом останавливаться.
В результате создана всего одна OSD и один хост, но это полностью рабочая конфигурация (рабочая в том смысле, что она может работать, а не в том, что она где-то применима; к счастью, никто не запускает Ceph для одного хоста).
Мы разграничили пулы, но при этом сохранили их в одном пространстве. Если что-то сломается в одном дереве, это никак не зааффектит другое дерево.
Важно: Старайтесь проводить манипуляции с пулами и распределением по классам устройств на этапе создания кластера, когда в нем еще мало данных. Потому что позже, когда кластер заполнен продакшн-данными, при смене классов устройств и перераспределении пулов между ними, у вас будет массивная ребалансировка.
Распределение пулов на разных устройствах
Раньше в Ceph не было понятия «класс устройства». В кластере могли быть SSD и магнитные диски, но нельзя было поместить один пул на SSD, другой на HDD. Относительно недавно ситуация изменилась. Теперь Ceph понимает, что есть HDD и есть SSD, и позволяет назначать на разные устройства разные пулы.
Тип устройства Ceph определяет автоматически, используя параметр rotational (вращающийся). Все, что rotational, он автоматически помечает как HDD, не rotational — как SSD.
В примере используется виртуальная среда, здесь все диски виртуальные, они все rotational, то есть HDD.
Но даже если диски не определяются как SSD автоматически, можно руками снять класс HDD и назначить класс SSD.
В рамках эксперимента пометим как SSD по одному из дисков на каждом сервере.
Для этого надо удалить с них класс HDD, это можно делать сразу для многих дисков:
Класс HDD удалился. Обратите внимание: класс удалился, но репликация не запустилась. Это произошло, потому что в руте по умолчанию используется дефолтное правило, которое не учитывает классы. Все пулы, созданные по дефолтному crush-правилу, будут размещаться по HDD и SSD равномерно. Это важно учитывать.
После удаления класса HDD назначим класс SSD:
Назначенный класс останется даже после рестарта OSD.
Устройства с классом SSD созданы. Теперь переходим к правилам. Все правила можно посмотреть командой:
replicated_rule — дефолтное правило.
new_root_rule — правило для другого root, созданное нами.
replicated_ssd — имя правила.
default — имя root’а.
host — тип репликации (репликация по хостам).
ssd — класс устройств (SSD или HDD).
Вот как выглядит созданное правило.
О применении правил поговорим чуть позже, сначала разберёмся с erasure-coding.
Создание erasure-code профиля
Для erasure coding все немного иначе. Создается не CRUSH-правило, а erasure code профиль. Синтаксис немного другой, но принцип тот же.
ec21 — имя.
host — по какому уровню реплицировать дерево.
SSD — класс устройств.
Нужно задать уровень CRUSH-дерева для репликации данных и класс устройства. В результате получается:
При создании replicated пулов указывают crush rule, которое описывает топологию репликации и устройство. При создании erasure-coding пула указывают профиль, который в принципе является тем же самым, только в нём ещё заданы “k” и “m”.
Посмотреть созданное правило:
Таким образом создан новый erasure-code профиль с размещением на SSD и новый пул, который будет использовать этот профиль.
Применение правил для replicated пулов
Переназначим CRUSH-правило для конкретного пула.
Среди пулов (просмотреть список можно с помощью ceph df ) есть пул с метаданными файловой системы и rgw.meta, который нужно разместить на SSD.
Команда для размещения пулов на SSD:
fs1_meta — название пула.
replicated_SSD — название правила.
После выполнения команды запускается rebalance: те два пула, которым был назначен новый профиль, полностью переезжают на SSD.
Важно: дефолтное правило позволяет остальным пулам аллоцироваться и на SSD, и на HDD. Поэтому на SSD будут placement groups в том числе тех пулов, которые должны быть на магнитных дисках. Их нужно переместить на соответствующие устройства, применив правило для HDD. Опять же, если делать это на этапе, когда в кластере много данных, то случится большой rebalance.
Переместим на HDD несколько пулов:
Как удалять правила
Для пример удалим дефолтное правило “ replicated_rule ”.
В нашем случае команда не сработала, так как правило используется — “is in use”.
Посмотреть, какой пул использует это правило:
В открывшемся списке надо найти параметр “crush_rule”.
Нас интересует crush_rule 0 (т. к. дефолтное правило получает индекс 0). Находим, какой пул использует это правило, перемещаем его на другое правило:
Теперь можно удалить:
Как проверить, что placement groups находятся на правильном классе устройств
У каждого пула есть идентификатор (колонка ID). Все placement groups конкретного пула начинаются с идентификатора этого пула. Например, ec1 мы создали на SSD.
Посмотрим, на каких устройствах размещаются его placement groups. Ищем по идентификатору пула — 9.
На скрине все placement groups пула ec1. Они находятся именно на тех трёх OSD, которые мы раньше специально пометили как SSD — 0, 2 и 4. То есть все данные находятся на правильном классе устройств.