Часть 19: Архитектура Ceph SDS - github2wiki/SPBSUT_KURS GitHub Wiki

Кластер хранения данных состоит из нескольких различных демонов программного обеспечения. Каждый из этих демонов заботится об уникальной функциональности Ceph и добавляет ценность для своих соответствующих компонент. Каждый из этих демонов отделен от других. Это одна из причин, которая позволяет удерживать стоимость кластера Ceph ниже при сопоставлении с корпоративными, фирменными системами хранения, представляющими собой черный ящик.

Следующая диаграмма кратко выделяет функции каждого компонента Ceph:

Немного о компонентах

Безотказное автономное распределённое хранилище объектов (RADOS, Reliable Autonomic Distributed Object Store) является основой хранения данных кластера Ceph. Все в Ceph хранится в виде объектов, а хранилище объектов RADOS отвечает за хранение этих объектов, независимо от их типа данных. Слой RADOS гарантирует, что данные всегда остаётся в согласованном состоянии. Для согласованности данных он выполняет репликацию данных, обнаружение отказов и восстановление данных, а также миграцию данных и изменение баланса в узлах кластера.

Как только ваше приложение выполняет операцию записи на ваш кластер Ceph, данные сохраняются в виде объектов в устройстве хранения объектов Ceph (OSD, Object Storage Device). Это единственная составляющая кластера Ceph в которой хранятся фактические данные пользователя, и эти же данные получаются клиентом, когда он выполняет операцию чтения. Как правило, один OSD демон связан с одним физическим диском вашего кластера. Следовательно, обычно, общее число физических дисков в вашем кластере Ceph совпадает с количеством демонов OSD, которые выполняют работу по хранению пользовательских данных в тесном взаимодействии со своим физическим диском.

Мониторы Ceph (MON, Ceph monitor) отслеживает состояние всего кластера путем хранения карты состояния кластера, которая включает в себя карты OSD, MON, PG и CRUSH. Все узлы кластера сообщают узлам монитора и делают общедоступной информацию обо всех изменениях в своих состояниях. Монитор поддерживает отдельную карту информации для каждого компонента. Монитор не хранит фактические данные; это является работой OSD.

Библиотека librados является удобным способом получения доступа к RADOS с поддержкой языков программирования PHP, Ruby, Java, Python, C и C++. Она предоставляет собственный интерфейс для кластера хранения данных Ceph, RADOS, и является основанием для других служб, таких как RBD, RGW а также интерфейса POSIX для CephFS. librados API поддерживает прямой доступ к RADOS и позволяет создать свой собственный интерфейс к хранилищу кластера Ceph.

Блочное устройство Ceph (Ceph Block Device, известное также как RADOS block device, RBD) предоставляет блочное хранилище, которое может отображаться, форматироваться и монтироваться в точности как любой другой диск в сервере. Блочное устройство Ceph имеет функциональность корпоративных хранилищ, такую как динамичное выделение и моментальные снимки.

Шлюз объектов Ceph (Ceph Object Gateway), также известный как шлюз RADOS (RGW), обеспечивает RESTful интерфейс API совместимый с Amazon S3 (Simple Service Storage) и хранилищами объектов OpenStack API (SWIFT). RGW также поддерживает множественных владельцев и службу проверки подлинности OpenStack Keystone.

Сервер метаданных Ceph (MDS, Metadata Server) отслеживает метаданные файловой иерархии и сохраняет их только для CephFS. Блочное устройство Ceph и шлюз RADOS не требуют метаданных, следовательно, они не нуждаются в демоне Ceph MDS. MDS не предоставляет данные непосредственно клиентам, тем самым устраняя единую точку отказа в системе.

Файловая система Ceph (CephFS, Ceph File System) предлагает POSIX-совместимую распределенную файловую систему любого размера. CephFS опирается на CephFS MDS, т.е. метаданные, для хранения иерархии. В настоящее время CephFS не готова к промышленной эксплуатации, однако она является идеальным кандидатом для РОС тестирования. Ее развитие идет очень высоким темпами и мы ожидаем, что она появится в промышленной эксплуатации в кратчайшие сроки.

Далее мы поговорим о каждом из компонентов более подробно, а сейчас давайте посмотрим на удаляющее кодирование

Что такое удаляющее кодирование?

Удаляющее кодирование (Erasure coding) позволяет Ceph достигать даже большей используемости ёмкости хранения или увеличения устойчивости к отказам дисков при том же самом числе дисков при сопоставлении со стандартным методом репликаций. Удаляющее кодирование достигает этого расщеплением имеющегося объекта на некоторое число частей с последующим вычислением какого-то типа CRC (cyclic redundancy check, Циклического избыточного кода), удаляющего кода (erasure code) с последующим сохранением всех результатов в одной или более дополнительных частей. Каждая часть затем сохраняется в отдельном OSD. Эти части имеют название порций (chunks) K и M, где K обозначает общее число кусочков самих данных, а M обозначает общее число кусочков удаляющего кода. Как и в случае с RAID, это может быть выражено в формуле K+M, например, 4+2.

В случае возникновения события отказа какого-то 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). Это иллюстрируется на следующей схеме:

Если некий OSD в наборе падает, такой первичный OSD может воспользоваться оставшимися данными и удаляющим кодом для восстановления всех данных прежде чем отправит их обратно запросившему клиенту. В процессе операций чтения такой первичный OSD запрашивает все OSD в данном наборе группы размещения (PG) на отправку их кусочков. Данный первичный OSD использует данные всех порций для построения запрошенных данных, а удаляющие кусочки отвергаются. Существует опция быстрого чтения, которая может быть включена в пулах удаляющего кодирования, которая позволяет имеющемуся первичному OSD строить эти данные из удаляющих кусочков если они возвращаются быстрее чем кусочки данных. Это может помочь снизить общую задержку за счёт стоимости слегка более высокого использования ЦПУ. Слудующая схема показывает как Ceph считывает с некоторого пула с удаляющим кодированием:

Приводимая далее схема отображает как Ceph читает некий пул удаляющего кодирования когда один из кусочков получаемых данных недоступен. Данные восстанавливаются изменяя направление алгоритма удаления с использованием оставшихся данных и удаляющих кусочков: