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ТБ может занять у вас неделю.
Создание волюма:
Подробное описание, как подготавливать брики, вы можете прочитать в моём предыдущем посте
Создаем, но не спешим запускать и монтировать, так как нам еще придется применить несколько важных параметров.
Всё выглядит вполне нормально, но есть один нюанс.
Он заключается в записи на брики такого волюма:
Файлы кладутся поочерёдно в сабволюмы, а не равномерно размазываются по ним, следовательно, рано или поздно мы упрёмся в его размер, а не в размер всего волюма. Максимальный размер файла, который мы можем положить в это хранилище, = полезный размер сабволюма минус уже занятое на нём пространство. В моем случае это
Erasure Coding против RAID
На больших объемах данных стандартные политики RAID становятся неэффективными – из-за сложности управления дисковыми группами, перерасхода дисков, проседания производительности, угроз сохранности данных. Алгоритмы Erasure coding (кода избыточности) защищают данные лучше, но за счет усложнения вычислительной надстройки. Зато системы хранения с Erasure Coding хорошо масштабируются, не привязаны к отдельным устройствам хранения и даже площадкам размещения.
Традиционные RAID, аппаратные или программные, работают с зеркальными копиями данных (как в RAID 1), или с данными и четностями (parity), одинарными или двойными (как в RAID 5 или 6). Копирование удваивает число требуемых дисков. RAID с четностями экономнее по расходу дисков, но, чем больше их емкость и масштабнее дисковые группы, тем выше риски потерь данных: реконструкция поврежденного массива может длиться сутками, если не неделями. С увеличением избыточности по дискам растет надежность, но производительность, особенно деградированного массива, остается низкой. Объединение RAID-массивов усложняет администрирование данных, впридачу к перерасходу дисков и проблемам производительности.
Всем известные RAID 5 и 6 – частные, простейшие типы EC. Двадцать лет назад диски вмещали гигабайты данных, чтение диска занимало минуты, а RAID 5 считался надежным и экономичным. Массив на дисках современных емкостей можно вычитывать часами. Когда реконструкция массива длится неделю, за это время можно потерять еще диск или два – не спасет и RAID 6. Erasure coding в разных проявлениях привлекает разработчиков ПО объемного хранения надежностью и экономичностью. Так, на EC построены объектные хранилища Ceph и конвергентные системы Nutanix.
Реализации EC различаются, в том числе производительностью. Но дело не в выборе политик ЕС и наилучшего ПО с EC. Важнее в управлении данными отделить их «горячую часть» от «прохладной» – где это возможно. Обычно речь идет о производственных данных и первичных хранилищах. Где данные активно изменяются и критична производительность – архитектуру хранилища подбирают под якорное приложение, а надежность обеспечивают репликацией данных (двумя, тремя или большим числом копий – в зависимости от ПО и уровня озабоченности владельца).
Данные всех остальных типов стоит объединять в активные архивы – собрания информации продолжительного хранения, с доступом в реальном времени. Производительность для них не так важна как сохранность данных и масштабируемость. Системы активного архива, вероятно, станут основной областью применения Erasure coding.
Напечатать 
Отправить другу
Erasure coding что это
Недавно мы рассказывали про новые функции свежего релиза Apache Hadoop 3.3.1. Сегодня разберем подробнее, что такое Erasure Coding и как эта технология кодирования со стиранием экономит место в распределенной файловой системе HDFS. Также заглянем внутрь EC и рассмотрим, чем алгоритм Рида-Соломона лучше ассоциативной операции XOR для обеспечения отказоустойчивости хранилища больших данных.
Что такое Erasure Coding и зачем это нужно в Hadoop HDFS
Начиная с версии 3.3.1, Apache Hadoop HDFS поддерживает технологию кодирования со стиранием (Erasure Coding, EC), которая экономит место на жестком диске по сравнению с репликацией. Cтандартная схема 3-кратной репликации в HDFS имеет 200% накладных расходов на пространство хранения и пропускную способность сети. Erasure Coding снижает накладные расходы на хранение данных до 50% независимо от коэффициента репликации за счет чередования, которое разделяет логически последовательные данные файла на более мелкие блоки (бит, байт или блок), сохраняя их на разных дисках недорогого RAID-массива. Для каждой полосы исходных ячеек данных вычисляется и сохраняется определенное количество ячеек четности. Этот процесс называется кодированием. Ошибка в любой чередующейся ячейке устраняется через обратную операцию декодирования на основе сохранившихся данных и ячеек четности. Например, файл с 3-кратной репликацией с 6 блоками HDFS без Erasure Coding будет занимать 6*3 = 18 блоков дискового пространства. А с поддержкой EC и 3-мя ячейками четности он занимает в 2 раза меньше дискового пространства – всего 9 блоков [1].
Таким образом, кодирование со стиранием может снизить накладные расходы на хранилище HDFS примерно на 50% по сравнению с репликацией, сохраняя те же гарантии долговечности и позволяя хранить вдвое больше данных на том же объеме хранилища.
Что касается математики, которую реализует технология Erasure Coding, то здесь используется алгоритм Рида-Соломона (Reed-Solomon, RS), который преодолевает ограничение алгоритма XOR. Операция XOR является ассоциативной и генерирует 1 бит четности из произвольного количества битов данных. Например, если данные столбца Y потеряны, то используя данные столбца X и ячейку четности, можно декодировать потерянные данные, сгенерировав Y снова. Но, поскольку алгоритм XOR генерирует только 1 бит четности для любого количества входных ячеек данных, он может выдержать только 1 сбой. Этого недостаточно для обеспечения высокой надежности HDFS, когда необходимо обрабатывать несколько сбоев. Отказоустойчивость алгоритма XOR равна единице, а эффективность хранения составляет 2/3, то есть 67%.
Алгоритм Рида-Соломона использует операцию линейной алгебры для создания нескольких ячеек четности, чтобы выдерживать множественные отказы. Здесь выполняется умножение m ячеек данных на матрицу генератора, чтобы получить расширенное кодовое слово с m ячейками данных и n ячейками четности. Если хранилище выходит из строя, то его можно восстановить, умножая обратную матрицу порождающей матрицы на расширенные кодовые слова до тех пор, пока доступны m из (m + n) ячеек. Отказоустойчивость RS-алгоритма приближается к n, то есть количество ячеек с проверкой четности и эффективность хранения составляет m/(m + n), где m – ячейка данных, а n – ячейка четности [2].
Что не так с технологией EC: ограничения и недостатки
Поскольку любое достоинство имеет свою цену, поддержка Erasure Coding увеличивает расходы на кластер Apache Hadoop по следующим причинам:
Однако, удорожание ИТ-инфраструктуры – не единственный недостаток Erasure Coding. На текущий момент эта технология имеет ряд ограничений, которые можно рассматривать как недостатки. В частности, некоторые операции HDFS (hflush, hsync, concat, setReplication, truncate и append) не поддерживаются для EC-файлов:
Функции hflush() и hsync() из пакета java.io для распределенной файловой системы DFSStripedOutputStream не используются, т.к. не могут гарантировать постоянство данных. Чтобы понять, поддерживает ли OutputStream функции hflush() и hsync(), можно использовать API StreamCapabilities. Этот интерфейс предоставляет способ программно запрашивать возможности, которые поддерживает OutputStream, InputStream или другой класс файловой системы FileSystem. Если необходимо сохранить данные с помощью hflush() и hsync(), можно создать обычные файлы 3-хкратной репликации в каталоге без Erasure Coding или сохранить их в каталог с поддержкой EC с помощью метода replicate() из API FSDataOutputStreamBuilder.
Из-за отмеченных ограничений проекты на базе Apache Hadoop, которые работают с горячими данными, будут использовать старый добрый механизм репликации, который, хоть и занимает больше места в HDFS, но проще и дешевле по сравнению с Erasure Coding. Однако, поскольку EC-технология позволяет экономить место в HDFS, она отлично подойдет для работы с холодными данными, которые используются не так активно [2].
Больше практических деталей про администрирование и эксплуатацию Apache Hadoop для хранения и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Глава 4. Удаляющее кодирование для лучшей эффективности хранения
< Прим. пер.: рекомендуем сразу обращаться к нашему переводу 2 издания вышедшего в феврале 2019 Полного руководства Ceph Ника Фиска >
Содержание
Определяемый по умолчанию в Ceph уровень репликаций предоставляет исключительную защищённость данных от потерь путём хранения трёх копий ваших данных в различных OSD. Вероятность потери данных на всех трёх дисках, которые содержат одни и те же объекты в пределах того периода времени, пока Ceph перестроит отказавший диск, граничит с самой крайней степенью вероятности. Однако, хранение трёх копий данных чрезмерно увеличивает как затраты приобретения, аппаратных средств, так и связано с операционными расходами, такими как электропитание и охлаждение. Более того, сохранение копий также означает, что для любой записи клиента лежащее в основе хранилище должно выполнять запись три раза весь объём данных. В некоторых ситуациях любые из этих обратных сторон могут означать, что Ceph не является приемлемым вариантом.
Для решения такой ситуации спроектировано решение удаляющего кодирования (erasure code). Во многом также как и RAID 5 и 6 предлагает увеличение применяемого пространства хранения в сравнении с RAID 1, удаляющее кодирование позволяет Ceph предоставлять больше используемого пространства с одной и той же сырой ёмкости. Однако в точности так же как и уровни RAID на основании чётности, удаляющее кодирование привносит свои собственные недостатки.
В данной главе вы изучите следующее:
Что такое удаляющее кодирование и как оно работает?
Подробности относительно реализации удаляющего кодирования в Ceph
Как создавать пул RADOS с удаляющим кодированием и регулировать его
Обзор грядущих свойств удаляющего кодирования в выпускаемой в свет редакции Ceph Kraken
Что такое удаляющее кодирование?
В случае возникновения события отказа какого- то OSD, который содержит кусочек объекта, вычисляемый удаляющим кодом, данные считываются с остающихся OSD, которые хранят данные, не подвергшиеся воздействию. Однако, если в случае отказа OSD утрачиваются данные, содержавшие кусочки данных некоторого объекта, Ceph может воспользоваться имеющимся удаляющим кодом для восстановления путём математического вычисления данных из некоторой комбинации кусочков оставшихся данных и удаляющих кодов.
Чем больше кусочков удаляющего кода имеется у вас, тем к большему числу отказов OSD вы можете быть готовыми и всё ещё продолжать успешно считывать данные. Аналогично, имеющееся соотношение K+M кусочков расщепления каждого объекта имеет прямое отношение к процентному соотношению сырого хранилища, которое требуется для каждого объекта.
Конфигурация 3+1 даст вам 75% использования ёмкости но позволит только единственный отказ OSD и по это причине не будет рекомендована. В качестве сравнения, пул реплик с тремя копиями даёт только 33% используемого пространства.
Конфигурация 4+2 предоставит вам применение пространства на 66% и допускает два отказа OSD. Скорее всего, это достаточно хорошая настройка для применения большинством людей.
С другой стороне шкалы 18+2 позволило бы вам использование имеющейся ёмкости на 90% и всё ещё позволяло бы два отказа OSD. На поверхности это звучит как идеальный выбор, однако большее значение общего числа кусочков привносит некую стоимость. Более высокое значение общего числа разбиений имеет отрицательное воздействие на производительность, а также увеличивает потребности в ЦПУ. Один и тот же объект 4МБ, который бы хранился как некий единый объект в каком- то пуле с репликациями, теперь должен будет быть разделённым на 20 x200кБ порций, каждая из которых должна быть препровождена и записана в различные 20 OSD. Шпиндельные диски предоставят большую полосу пропускания измеряемую MBps на операциях ввода/ вывода с большими размерами, однако полоса пропускания коренным образом уменьшится для операций ввода/ вывода меньших размеров. Такие маленькие кусочки создадут большой объём операций ввода/ вывода малого размера и вызовут дополнительную нагрузку в некоторых кластерах.
Кроме того, важно не забывать, что эти кусочки необходимо распространять по различным хостам в соответствии с имеющимися правилами карты CRUSH: никакие кусочки одного и того же объекта не должны храниться на одном и том же хосте с прочими кусочками из того же самого объекта. Некоторые кластеры просто могут не иметь достаточного число хостов чтобы удовлетворить данное требование.
Обратное считывание с такого пула с большой порционностью также является проблемой. В отличии от пула с репликациями, в котором Ceph может просто считывать требуемые данные с любого смещения некоторого объекта, в каком- либо пуле удаляющего кодирования все куочки со всех OSD должны быть считаны прежде чем данный запрос на чтение будет удовлетворён. В нашем примере 18+2 это может массивно расширить общее число требующихся операций дискового чтения и средняя латентность в результате вырастет. Такое поведение является сторонним эффектом, который имеет тенденцию вызывать исключительное воздействие на пулы, использующие некоторое большое число порций. Конфигурация 4+2 во многих экземплярах предоставит потребность в производительности, сравнимую с неким пулом реплик за счёт результата разделения объекта на кусочки. Поскольку данные эффективно чередуются по некоторому числу OSD, каждый из OSD должен записывать меньше данных и при этом отсутствуют вторичные и третичные реплики, подлежащие записи.
Как работает удаляющее кодирование в Ceph?
Как и в случае с репликациями, Ceph имеет некое понятие первичного OSD, которое также имеется и в случае, когда мы применяем пулы с удаляющим кодированием. Такой первичный OSD несёт ответственность за взаимодействие с самим клиентом, вычисление кусочков для удаления, а также отправкой их оставшимся OSD в данном наборе групп размещения (PG). Это иллюстрируется на следующей схеме:
Рисунок 1
Если некий OSD в наборе падает, такой первичный OSD может воспользоваться оставшимися данными и удаляющим кодом для восстановления всех данных прежде чем отправит их обратно запросившему клиенту. В процессе операций чтения такой первичный OSD запрашивает все OSD в данном наборе группы размещения (PG) на отправку их кусочков. Данный первичный OSD использует данные всех порций для построения запрошенных данных, а удаляющие кусочки отвергаются. Существует опция быстрого чтения, которая может быть включена в пулах удаляющего кодирования, которая позволяет имеющемуся первичному OSD строить эти данные из удаляющих кусочков если они возвращаются быстрее чем кусочки данных. Это может помочь снизить общую задержку за счёт стоимости слегка более высокого использования ЦПУ. Следующая схема показывает как Ceph считывает с некоторого пула с удаляющим кодированием:
Рисунок 2
Приводимая далее схема отображает как Ceph читает некий пул удаляющего кодирования когда один из кусочков получаемых данных недоступен. Данные восстанавливаются изменяя направление алгоритма удаления с использованием оставшихся данных и удаляющих кусочков:
Рисунок 3
Алгоритмы и профили
Имеется ряд различных встраиваемых модулей удаляющего кодирования, которые вы можете применять при создании своего пула удаляющего кодирования.
Jerasure
В общем случае данный профиль Jerasure следует предпочесть в большем числе вариантов, если только другой профиль не имеет некоторого основного преимущества, так как он предлагает хорошо сбалансированную производительность и богатую историю тестирования.
Данная библиотека ISA разработана для работы с процессорами Intel и предлагает расширенную производительность. Она также предлагает поддержку как методов Рида- Соломона, так и Коши.
Где я могу применять удаляющее кодирование?
Начиная с редакции Ceph 2014 FireFly появилась возможность создания некоторого пула RADOS с применением удаляющего кодирования. Имеется один важный момент, о котором вы должны быть осведомлены: сама поддержка удаляющего кодирования в RADOS не допускает частичного обновления некоторого объекта. Вы можете делать записи в некий объект в пуле удаляющего кодирования, считывать это обратно и даже переписывать его целиком, но вы не можете обновлять отдельно взятую секцию в нём. Это означает, что пулы с удаляющим кодированием не могут применяться для рабочих нагрузок RBD и CephFS и ограничены предоставлением чистого хранения объектов либо через шлюз RADOS, либо через написанные с применением librados приложениями.
Конкретным решением на данный момент было использование имеющейся возможности многоуровневого кэширования, которое было реализовано примерно в то же время, чтобы действовать поверх некоторого пула с удаляющим кодированием так, чтобы можно было применять RBD. В теории это выглядит великолепной идеей; на практике производительность чрезвычайно низка. Всякий раз, когда некий объект получает запрос на запись, весь объект вначале должен быть Представлен в имеющийся уровень кэширования. Такое действие Представления Представления также вероятно означает, что другой объект где- то в этом пуле кэша был Вытеснен. Наконец, данный объект теперь в самом уровне кэширования может выполнить операцию записи. Весь этот процесс постоянного считывания и записывания данных между двумя пулами означает неприемлемую производительность, если только очень высокий процент таких данных не чвляется простаивающим.
В процессе цикла разработки выпуска Kraken была предложена некая начальная реализация для поддержки прямой перезаписи в каком- либо пуле удаляющего кодирования. Что касается окончательной версии выпуска Kraken, поддержка помечена как экспериментальная и ожидающая отметки стабильная в следующем выпуске. Проверка этой функциональности будет рассмотрена в данной главе позднее.
Создание пула удаляющего кодирования
Пулы удаляющего кодирования управляются при помощи применения профилей удаляющего кодирования; они управляют тем на сколько порций разбивается каждый объект, включая разбиение между порциями данных и избыточного кода. Данные профили также содержат настройки для определения того какой встраиваемый модуль удаляющего кодирования используется для вычисления необходимых хэшей.
К применению доступны следующие встраиваемые модули:
Чтобы просмотреть список имеющихся профилей удаляющего кодирования, выполните следующую команду:
Вы можете увидеть, что имеется некий профиль default в только что выполненной установке Ceph:
Рисунок 4
Давайте посмотрим какие варианты настроек он содержит воспользовавшись такой командой:
Данный профиль default предписывает, что он будет применять встраиваемый модуль Jerasure с кодированием посредством коррекции ошибок Рида- Соломона и будет расщеплять объекты на 2 порции данных и 1 порцию избыточного кода:
Рисунок 5
Это почти идеально для целей нашего тестового кластера, однако для целей данного упражнения мы создадим некий новый профиль воспользовавшись следующей командой:
Как вы можете отметить, был создан наш новый example_profile :
Рисунок 6
Теперь давайте создадим с этим профилем свой пул удаляющего кодирования:
Предыдущая команда предоставит вам следующий вывод:
Рисунок 7
Давайте создадим некий объект с небольшой тестовой строкой внутри него и затем докажем что эти данные были сохранены, считав их обратно:
Это докажет что данный пул удаляющего кодирования работает, но вряд ли у вас перехватило дух от этого открытия:
Рисунок 8
Давайте обратим внимание на то, можем ли мы посмотреть что произошло на некотором нижнем уровне.
Вначале отыщем какая PG содержит тот объект, который мы только что создали:
Рисунок 9
Теперь мы можем взглянуть на структуру данной папки текущего OSD и посмотреть как данный объект был разделён применив следующую команду:
Предыдущая команда предоставит вам следующий вывод:
Рисунок 10
Предыдущая команда предоставит вам следующий вывод:
Рисунок 11
Предыдущая команда предоставит вам следующий вывод:
Рисунок 12
Заметим, что все имена каталогов PG были дополнены соответствующими номерами порций и реплицируемого пула просто чтобы иметь необходимый номер PG в своём имени каталога. Если вы проверите всё содержимое данных файлов объекта, вы обнаружить нашу текстовую строка, которую мы ввели в данный объект при его создании. Однако, из- за малого размера данной текстовой строки Ceph заполнил вторую порцию символами null, а избыточная порция здесь будет содержать то же самое, что и первая порция. Вы можете повторить данный пример с неким новым объектом, содержащим больший объём текста и увидеть как Ceph расщепляет такой текст на необходимые порции и вычисляет свой удаляющий код.
Запись поверх пулов удалённого кодирования при помощи Kraken
Именно впервые предложенная в последнем выпуске Ceph Kraken в качестве экспериментального свойства, новая возможность позволила частичную перезапись в пулах удаляющего кодирования. Поддержка частичной перезаписи (partial overwrite) делает возможным создание томов RBD в пулах удаляющего кодирования, что улучшает использование сырого пространства в имеющемся кластере Ceph.
RAID с избыточными данными, в которых некоторая операции записи не охватывает целиком всю полосу, требуется операция чтения- изменения- записи. Она требуется поскольку изменение порции данных будет означать, что имеющаяся порция избыточного кода теперь будет не верной. Данному контроллеру RAID приходится считывать все имеющиеся текущие порции в данной полосе, изменять и в оперативной памяти, вычислять новую порцию избыточных данных (parity) и, наконец, записывать их обратно на свой диск.
Для Ceph также требуется выполнять такую операцию чтения- изменения- записи, однако его распределённая модель увеличивает сложность данной операции. Когда имеющийся первичный OSD для некоторой группы размещения (PG) получает некий запрос на запись, который частично перезаписывает имеющийся объект, он сначала обрабатывает то, какие порции не будут полностью изменены данным запросом и взаимодействует с относящимся к ним OSD запрашивая некую копию таких порций. Этот первичный OSD затем объединяет такие полученные порции с имеющимися новыми данными и вычисляет необходимую порцию избыточного кода. Наконец, изменённые порции отправляются в соответствующие OSD для их фиксации. Вся эта операция целиком должна соответствовать всем прочим требованиям согласованности, обеспечиваемыми Ceph; это влечёт за собой применение временных объектов в данном OSD с тем, чтобы в случае возникновения некоторого условия, Ceph исполнил необходимость отката назад операции записи.
Такая операция частичной записи, как и можно было ожидать, воздействует на производительность. В общем случае, чем меньше данная операция ввода/ вывода на запись, тем более очевидно воздействие. Такое влияние на производительность является результатом того, что теперь данный путь операции ввода/ вывода будет длиннее и потребует большего числа операций ввода/ вывода диска, а также дополнительных скачков (hops) по сети. Однако, следует отметить, что благодаря эффекту чередования пула удаляющего кодирования, в том сценарии, в котором происходит запись всей полосы, производительность обычно превосходит ту, что имеется в некотором пуле на основе репликаций. Такое снижение в этом случае происходит благодаря меньшему усложнению записи, обусловленному присутствием эффекта чередования. Если данная производительность некоторого пула удаляющего кодирования не удовлетворительна, рассмотрите помещение её под неким уровнем кэширования, выполненным из какого- то пула с репликациями.
Демонстрация
Данная функциональность требует наличие редакции Ceph Kraken или более новой. Если вы развернули свой тестовый кластер при помощи Ansible и была предоставлена его конфигурация, вы будете исполнять редакцию Ceph Jewel. Последующие шаги показывают как применять Ansible для выполнения раскрутки обновления вашего кластера до выпуска Kraken. Мы также включим опции чтобы разрешить экспериментальные параметры, такие как BlueStore и поддержку частичной перезаписи в пулах удаляющего кодирования.
Также добавьте следующее:
А также для исправления некоторой небольшой ошибки при использовании Ansible для развёртывания Ceph Kraken, добавьте debian_ceph_packages
В самом конце данного файла исполните следующий план (playbook) Ansible:
Предыдущая команда даст вам следующий вывод:
Рисунок 13
Когда Ansible завершит свою работу, все этапы должны завершиться успехом, как это показано на снимке экрана внизу:
Рисунок 14
Рисунок 15
В качестве результата того, что вы включили определённые экспериментальные опции в своём файле настроек, всякий раз, когда вы теперь будете исполнять некую команду Ceph, вам будет представляться следующее предупреждение:
Рисунок 16
Оно разработано в целях предупреждения безопасности чтобы вы прекратили применять эти опции в реальной среде, так как они могут вызвать безвозвратную утрату данных. Поскольку мы выполняем это на проверочном кластере, ничего страшного не будет при его игнорировании, однако это должно быть суровым предупреждением для того, чтобы нигде не работать ни с какими реальными данными.
Следующая команда, которую необходимо выполнить, состоит во включении необходимого экспериментального флага, который разрешит частичную перезапись в пулах удаляющего кодирования:
Ни в коем случае не делайте этого в промышленных кластерах.
Частичная перезапись в пулах удаляющего кодирования требует действительной работы BlueStore. Пока работает файловое хранилище, производительность будет безумно плохой.
Поиск неисправностей для ошибки 2147483647
Данный небольшой раздел включён вовнутрь данной главы удаляющего кодирования вместо того чтобы быть размещённым в разделе поиска неисправностей данной книги так как обычно встречается в пулах с удаляющим кодированием и поэтому очень связан с данной главой. В качестве примера данной ошибки продемонстрируем следующий снимок экрана при выполнении команды ceph health detail :
Рисунок 17
Если вы наблюдаете 2147483647 перечисленным в качестве одного из присутствующих OSD для некоторого пула удаляющего кодирования, обычно это означает, что CRUSH не может найти достаточное число OSD для выполнения необходимого процесса однораногового обмена (peering) PG. Обычно это обусловлено тем, что общее число порций K+M будет больше чем общее число хостов в топологии CRUSH. Однако, в некоторых случаях эта ошибка может всё ещё происходить даже когда общее число хостов равно или больше чем общее число порций. В таком случае важно понимать как CRUSH указывает OSD в качесте претендентов для размещения данных. Когда CRUSH применяется для нахождения OSD в качестве кандидата для некоторой PG, он применяет имеющуюся карту CRUSH для поиска соответствующего местоположения в имеющейся топологии CRUSH. В случае когда возвращается тот же самый результат, что и выбранный перед этим OSD, Ceph попытается повторно создать другое соответствие, передавая слегка отличные значения в свой алгоритм CRUSH. В некоторых случаях, если имеется аналогичное общему числу порций избыточных кодов число хостов, CRUSH может завершить работу до того как он надлежащим образом обнаружит правильный OSD, соответствующий всем имющимся порциям. Более новые версии Ceph имеют более исправленной данную проблему за счёт увеличения подстройки choose_total_tries в своём CRUSH.
Воспроизводство данной проблемы
С целью более подробного понимания данной проблемы, последующие шаги продемонстрируют как создать некий профиль удаляющего кодирования, который запросит больше порций, чем может поддерживать наш кластер из трёх узлов.
Теперь создайте при помощи него некий пул:
Предыдущая команда даст вам следующий вывод:
Рисунок 18
Рисунок 19
Вывод ceph health detail демонстрирует причину почему это так, и мы обнаруживаем ошибку 2147483647 :
Рисунок 20
Если вы столкнулись с этой ошибкой и она является неким результатом того, что ваш профиль удаляющего кодирования больше чем имеющееся у вас число хостов или стоек, в зависимости от того как вы спроектировали свою карту CRUSH, тогда единственным практическим решением будет или снижение общего числа порций, или увеличение общего числа хостов.
Выводы
В данной главе вы изучили что такое удаляющее кодирование и как оно реализуется в Ceph. Вы также должны понимать различные возможные варианты настройки при создании пулов с удаляющим кодированием возможность их соответствия различным видам сценариев и рабочих нагрузок.
