rados block device что это

Знакомство с хранилищем Ceph в картинках

Облачные файловые хранилища продолжают набирать популярность, и требования к ним продолжают расти. Современные системы уже не в состоянии полностью удовлетворить все эти требования без значительных затрат ресурсов на поддержку и масштабирование этих систем. Под системой я подразумеваю кластер с тем или иным уровнем доступа к данным. Для пользователя важна надежность хранения и высокая доступность, чтобы файлы можно было всегда легко и быстро получить, а риск потери данных стремился к нулю. В свою очередь для поставщиков и администраторов таких хранилищ важна простота поддержки, масштабируемость и низкая стоимость аппаратных и программных компонентов.

Знакомьтесь: Ceph

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

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

Роли узлов и демоны

Поскольку система программно определяемая и работает поверх стандартных файловых систем и сетевых уровней, можно взять пачку разных серверов, набить их разными дисками разного размера, соединить всё это счастье какой-нибудь сетью (лучше быстрой) и поднять кластер. Можно воткнуть в эти серверы по второй сетевой карте, и соединить их второй сетью для ускорения межсерверного обмена данными. А эксперименты с настройками и схемами можно легко проводить даже в виртуальной среде. Мой опыт экспериментов показывает, что самое долгое в этом процессе — это установка ОС. Если у нас есть три сервера с дисками и настроенной сетью, то поднятие работоспособного кластера с дефолтными настройками займет 5-10 минут (если все делать правильно).

Поверх операционной системы работают демоны Ceph, выполняющие различные роли кластера. Таким образом один сервер может выступать, например, и в роли монитора (MON), и в роли хранилища данных (OSD). А другой сервер тем временем может выступать в роли хранилища данных и в роли сервера метаданных (MDS). В больших кластерах демоны запускаются на отдельных машинах, но в малых кластерах, где количество серверов сильно ограничено, некоторые сервера могут выполнять сразу две или три роли. Зависит от мощности сервера и самих ролей. Разумеется, все будет работать шустрее на отдельных серверах, но не всегда это возможно реализовать. Кластер можно собрать даже из одной машины и всего одного диска, и он будет работать. Другой разговор, что это не будет иметь смысла. Следует отметить и то, что благодаря программной определяемости, хранилище можно поднять даже поверх RAID или iSCSI-устройства, однако в большинстве случаев это тоже не будет иметь смысла.

В документации перечислено 3 вида демонов:

Структура хранения

Для начала коротко и непонятно. Кластер может иметь один или много пулов данных разного назначения и с разными настройками. Пулы делятся на плейсмент-группы. В плейсмент-группах хранятся объекты, к которым обращаются клиенты. На этом логический уровень заканчивается, и начинается физический, потому как за каждой плейсмент-группой закреплен один главный диск и несколько дисков-реплик (сколько именно зависит от фактора репликации пула). Другими словами, на логическом уровне объект хранится в конкретной плейсмент-группе, а на физическом — на дисках, которые за ней закреплены. При этом диски физически могут находиться на разных узлах или даже в разных датацентрах.

Далее подробно & понятно.

Фактор репликации (RF)

Фактор репликации — это уровень избыточности данных. Количество копий данных, которое будет храниться на разных дисках. За этот параметр отвечает переменная size. Фактор репликации может быть разным для каждого пула, и его можно менять на лету. Вообще, в Ceph практически все параметры можно менять на лету, мгновенно получая реакцию кластера. Сначала у нас может быть size=2, и в этом случае, пул будет хранить по две копии одного куска данных на разных дисках. Этот параметр пула можно поменять на size=3, и в этот же момент кластер начнет перераспределять данные, раскладывая еще одну копию уже имеющихся данных по дискам, не останавливая работу клиентов.

Пул — это логический абстрактный контейнер для организации хранения данных пользователя. Любые данные хранятся в пуле в виде объектов. Несколько пулов могут быть размазаны по одним и тем же дискам (а может и по разным, как настроить) с помощью разных наборов плейсмент-групп. Каждый пул имеет ряд настраиваемых параметров: фактор репликации, количество плейсмент-групп, минимальное количество живых реплик объекта, необходимое для работы и т. д. Каждому пулу можно настроить свою политику репликации (по городам, датацентрам, стойкам или даже дискам). Например, пул под хостинг может иметь фактор репликации size=3, а зоной отказа будут датацентры. И тогда Ceph будет гарантировать, что каждый кусочек данных имеет по одной копии в трех датацентрах. Тем временем, пул для виртуальных машин может иметь фактор репликации size=2, а уровнем отказа уже будет серверная стойка. И в этом случае, кластер будет хранить только две копии. При этом, если у нас две стойки с хранилищем виртуальных образов в одном датацентре, и две стойки в другом, система не будет обращать внимание на датацентры, и обе копии данных могут улететь в один датацентр, однако гарантированно в разные стойки, как мы и хотели.

Плейсмент-группа (PG)

Плейсмент-группы — это такое связующее звено между физическим уровнем хранения (диски) и логической организацией данных (пулы).

Каждый объект на логическом уровне хранится в конкретной плейсмент-группе. На физическом же уровне, он лежит в нужном количестве копий на разных физических дисках, которые в эту плейсмент-группу включены (на самом деле не диски, а OSD, но обычно один OSD это и есть один диск, и для простоты я буду называть это диском, хотя напомню, за ним может быть и RAID-массив или iSCSI-устройство). При факторе репликации size=3, каждая плейсмент группа включает в себя три диска. Но при этом каждый диск находится во множестве плейсмент-групп, и для каких то групп он будет первичным, для других — репликой. Если OSD входит, например, в состав трех плейсмент-групп, то при падении такого OSD, плейсмент-группы исключат его из работы, и на его место каждая плейсмент-группа выберет рабочий OSD и размажет по нему данные. С помощью данного механизма и достигается достаточно равномерное распределение данных и нагрузки. Это весьма простое и одновременно гибкое решение.

Мониторы

Монитор — это демон, выполняющий роль координатора, с которого начинается кластер. Как только у нас появляется хотя бы один рабочий монитор, у нас появляется Ceph-кластер. Монитор хранит информацию о здоровье и состоянии кластера, обмениваясь различными картами с другими мониторами. Клиенты обращаются к мониторам, чтобы узнать, на какие OSD писать/читать данные. При разворачивании нового хранилища, первым делом создается монитор (или несколько). Кластер может прожить на одном мониторе, но рекомендуется делать 3 или 5 мониторов, во избежание падения всей системы по причине падения единственного монитора. Главное, чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения сознания (split-brain). Мониторы работают в кворуме, поэтому если упадет больше половины мониторов, кластер заблокируется для предотвращения рассогласованности данных.

OSD (Object Storage Device)

OSD — это юнит хранилища, который хранит сами данные и обрабатывает запросы клиентов, обмениваясь данными с другими OSD. Обычно это диск. И обычно за каждый OSD отвечает отдельный OSD-демон, который может запускаться на любой машине, на которой установлен этот диск. Это второе, что нужно добавлять в кластер, при разворачивании. Один монитор и один OSD — минимальный набор для того, чтобы поднять кластер и начать им пользоваться. Если на сервере крутится 12 дисков под хранилище, то на нем будет запущено столько же OSD-демонов. Клиенты работают непосредственно с самими OSD, минуя узкие места, и достигая, тем самым, распределения нагрузки. Клиент всегда записывает объект на первичный OSD для какой-то плейсмент группы, а уже дальше данный OSD синхронизирует данные с остальными (вторичными) OSD из этой же плейсмент-группы. Подтверждение успешной записи может отправляться клиенту сразу же после записи на первичный OSD, а может после достижения минимального количества записей (параметр пула min_size). Например если фактор репликации size=3, а min_size=2, то подтверждение об успешной записи отправится клиенту, когда объект запишется хотя бы на два OSD из трех (включая первичный).

При разных вариантах настройки этих параметров, мы будем наблюдать и разное поведение.

Если size=3 и min_size=2: все будет хорошо, пока 2 из 3 OSD плейсмент-группы живы. Когда останется всего лишь 1 живой OSD, кластер заморозит операции данной плейсмент-группы, пока не оживет хотя бы еще один OSD.

Если size=min_size, то плейсмент-группа будет блокироваться при падении любого OSD, входящего в ее состав. А из-за высокого уровня размазанности данных, большинство падений хотя бы одного OSD будет заканчиваться заморозкой всего или почти всего кластера. Поэтому параметр size всегда должен быть хотя бы на один пункт больше параметра min_size.

Диск OSD состоит из двух частей: журнал и сами данные. Соответственно, данные сначала пишутся в журнал, затем уже в раздел данных. С одной стороны это дает дополнительную надежность и некоторую оптимизацию, а с другой стороны — дополнительную операцию, которая сказывается на производительности. Вопрос производительности журналов рассмотрим ниже.

Алгоритм CRUSH

В основе механизма децентрализации и распределения лежит так называемый CRUSH-алгоритм (Controlled Replicated Under Scalable Hashing), играющий важную роль в архитектуре системы. Этот алгоритм позволяет однозначно определить местоположение объекта на основе хеша имени объекта и определенной карты, которая формируется исходя из физической и логической структур кластера (датацентры, залы, ряды, стойки, узлы, диски). Карта не включает в себя информацию о местонахождении данных. Путь к данным каждый клиент определяет сам, с помощью CRUSH-алгоритма и актуальной карты, которую он предварительно спрашивает у монитора. При добавлении диска или падении сервера, карта обновляется.

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

Клиент хочет записать некий объект object1 в пул Pool1. Для этого он смотрит в карту плейсмент-групп, которую ему ранее любезно предоставил монитор, и видит, что Pool1 разделен на 10 плейсмент-групп. Далее с помощью CRUSH-алгоритма, который на вход принимает имя объекта и общее количество плейсмент-групп в пуле Pool1, вычисляется ID плейсмент-группы. Следуя карте, клиент понимает, что за этой плейсмент-группой закреплено три OSD (допустим, их номера: 17, 9 и 22), первый из которых является первичным, а значит клиент будет производить запись именно на него. Кстати, их три, потому что в этом пуле установлен фактор репликации size=3. После успешной записи объекта на OSD_17, работа клиента закончена (это если параметр пула min_size=1), а OSD_17 реплицирует этот объект на OSD_9 и OSD_22, закрепленные за этой плейсмент-группой. Важно понимать, что это упрощенное объяснение работы алгоритма.

По умолчанию наша CRUSH-карта плоская, все ноды находятся в одном пространстве. Однако, можно эту плоскость легко превратить в дерево, распределив серверы по стойкам, стойки по рядам, ряды по залам, залы по датацентрам, а датацентры по разным городам и планетам, указав какой уровень считать зоной отказа. Оперируя такой новой картой, Ceph будет грамотнее распределять данные, учитывая индивидуальные особенности организации, предотвращая печальные последствия пожара в датацентре или падения метеорита на целый город. Более того, благодаря этому гибкому механизму, можно создавать дополнительные слои, как на верхних уровнях (датацентры и города), так и на нижних (например, дополнительное разделение на группы дисков в рамках одного сервера).

Кэширование

Ceph предусматривает несколько способов увеличения производительности кластера методами кэширования.

Primary-Affinity
У каждого OSD есть несколько весов, и один из них отвечает за то, какой OSD в плейсмент-группе будет первичным. А, как мы выяснили ранее, клиент пишет данные именно на первичный OSD. Так вот, можно добавить в кластер пачку SSD дисков, сделав их всегда первичными, снизив вес primary-affinity HDD дисков до нуля. И тогда запись будет осуществляться всегда сначала на быстрый диск, а затем уже не спеша реплицироваться на медленные. Этот метод самый неправильный, однако самый простой в реализации. Главный недостаток в том, что одна копия данных всегда будет лежать на SSD и потребуется очень много таких дисков, чтобы полностью покрыть репликацию. Хотя этот способ кто-то и применял на практике, но его я скорее упомянул для того, чтобы рассказать о возможности управления приоритетом записи.

Вынос журналов на SSD
Вообще, львиная доля производительности зависит от журналов OSD. Осуществляя запись, демон сначала пишет данные в журнал, а затем в само хранилище. Это верно всегда, кроме случаев использования BTRFS в качестве файловой системы на OSD, которая может делать это параллельно благодаря технике copy-on-write, но я так и не понял, насколько она готова к промышленному применению. На каждый OSD идет собственный журнал, и по умолчанию он находится на том же диске, что и сами данные. Однако, журналы с четырёх или пяти дисков можно вынести на один SSD, неплохо ускорив операции записи. Метод не очень гибкий и удобный, но достаточно простой. Недостаток метода в том, что при вылете SSD с журналом, мы потеряем сразу несколько OSD, что не очень приятно и вносит дополнительные трудности во всю дальнейшую поддержку, которая скалируется с ростом кластера.

Кэш-тиринг
Ортодоксальность данного метода в его гибкости и масштабируемости. Схема такова, что у нас есть пул с холодными данными и пул с горячими. При частом обращении к объекту, тот как бы нагревается и попадает в горячий пул, который состоит из быстрых SSD. Затем, если объект остывает, он попадает в холодный пул с медленными HDD. Данная схема позволяет легко менять SSD в горячем пуле, который в свою очередь может быть любого размера, ибо параметры нагрева и охлаждения регулируются.

С точки зрения клиента

Ceph предоставляет для клиента различные варианты доступа к данным: блочное устройство, файловая система или объектное хранилище.

Блочное устройство (RBD, Rados Block Device)
Ceph позволяет в пуле данных создать блочное устройство RBD, и в дальнейшем смонтировать его на операционных системах, которые это поддерживают (на момент написания статьи были только различные дистрибутивы linux, однако FreeBSD и VMWare тоже работают в эту сторону). Если клиент не поддерживает RBD (например Windows), то можно использовать промежуточный iSCSI-target с поддержкой RBD (например, tgt-rbd). Кроме того, такое блочное устройство поддерживает снапшоты.

Файловая система CephFS
Клиент может смонтировать файловую систему CephFS, если у него linux с версией ядра 2.6.34 или новее. Если версия ядра старше, то можно смонтировать ее через FUSE (Filesystem in User Space). Для того, чтобы клиенты могли подключать Ceph как файловую систему, необходимо в кластере поднять хотя бы один сервер метаданных (MDS)

Шлюз объектов
С помощью шлюза RGW (RADOS Gateway) можно клиентам дать возможность пользоваться хранилищем через RESTful Amazon S3 или OpenStack Swift совместимое API.

И другие.
Все эти уровни доступа к данным работают поверх уровня RADOS. Список можно дополнить, разработав свой слой доступа к данным с помощью librados API (через который и работают перечисленные выше слои доступа). На данный момент есть биндинги C, Python, Ruby, Java и PHP

RADOS (Reliable Autonomic Distributed Object Store), если в двух словах, то это слой взаимодействия клиентов и кластера.

Википедия гласит, что сам Ceph написан на C++ и Python, а в разработке принимают участие компании Canonical, CERN, Cisco, Fujitsu, Intel, Red Hat, SanDisk, and SUSE.

Впечатления

Зачем я все это написал и нарисовал картинков? Затем что не смотря на все эти достоинства, Ceph либо не очень популярен, либо люди кушают его втихомолку, судя по количеству информации о нем в интернете.

То, что Ceph гибкий, простой и удобный, мы выяснили. Кластер можно поднять на любом железе в обычной сети, потратив минимум времени и сил, при этом Ceph сам будет заботиться о сохранности данных, предпринимая необходимые меры в случае сбоев железа. В том, что Ceph гибкий, простой и масштабируемый сходится множество точек зрения. Однако отзывы о производительности встречаются весьма разнообразные. Возможно кто-то не справился с журналами, кого-то подвела сеть и задержки в операциях ввода/вывода. То есть, заставить кластер работать — легко, но заставить его работать быстро — возможно, сложнее. Посему, я взываю к ИТ-специалистам, которые имеют опыт использования Ceph в продакшене. Поделитесь в комментариях о своих отрицательных впечатлениях.

Источник

Глава 3. Архитектура и компоненты Ceph

В данной главе мы охватим:

Архитектуру системы хранения Ceph

Устройство хранения объектов Ceph (OSD)

Блочное хранилище Ceph

Шлюз объектов Ceph

Содержание

Архитектура системы хранения Ceph

Кластер хранения данных состоит из нескольких различных демонов программного обеспечения. Каждый из этих демонов заботится об уникальной функциональности 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 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 не готова к промышленной эксплуатации, однако она является идеальным кандидатом для РОС тестирования. Ее развитие идет очень высоким темпами мы ожидаем, что она появится в промышленной эксплуатации в кратчайшие сроки.

< Прим. пер.: Это может показаться забавным, однако с некоторых пор стало возможным построение бесплатной среды виртуализации на основе гипервизора Hyper-V с бесплатной же системой хранения Storage Spaces, обладающей современными функциональностью и мощностью сопоставимыми, например, с Ceph. Хотя она и ограничена в масштабировании применением аппаратных технологий SAS/ FC. Остаётся дождаться смещения Storage Spaces Direct (S2D) в сферу халявного применения, чтобы имеющаяся в Непосредственно подключаемых пространствах хранения Программно определяемая шина хранения (Software Storage Bus), заменяющая собой SAS/FC, смогла составить конкуренцию системам хранения уровня Ceph!>

Ceph RADOS

Ceph RADOS ( RADOS, Reliable Autonomic Distributed Object Store ) является сердцем системы хранения Ceph, которая также называется кластером хранения Ceph. RADOS обеспечивает для Ceph различные характеристики, включающие в себя распределенное хранение объектов, высокую доступность, надежность, отсутствие единой точки отказа, самовосстановление, самоуправление и тому подобное. В результате уровень RADOS имеет особое значение в архитектуре хранения Ceph. Методы доступа Ceph, такие как RBD, CephFS, RADOSGW и librados, все работают поверх уровня RADOS.

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

Будучи настроенным с фактором репликаций более одного RADOS, тем самым, обеспечивает мероприятия по сохранности данных. В то же время она реплицирует объекты, создает копии и сохраняет их в различных зонах отказов. Однако, для более индивидуальной настройки и повышения надежности вы должны выполнить тонкую настройку вашего набора правил для приведения их в соответствие вашим потребностям и требованиям среды.

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

RADOS хранит данные в форме объектов внутри пулов. Давайте взглянем на пулы следующим образом:

Вы получите вывод результатов, подобный показанному на следующем моментальном снимке:

Проверьте список объектов в пуле при помощи следующей команды:

Проверьте загруженность кластера следующей командой:

Вывод результатов может отличаться, а может нет, от приводимого нами моментальном снимке:

RADOS состоит из двух основных составляющих, OSD и мониторов. Теперь мы более детально обсудим эти компоненты.

Устройство хранения объектов Ceph

OSD Ceph является одним из самых важных строительных блоков кластера хранения данных Ceph. Оно сохраняет фактические данные на физических накопителях всех узлов кластера в виде объектов. Основную часть работы внутри кластера Ceph осуществляют демоны Ceph OSD. Они являются реальными рабочими лошадками, которые хранят данные пользователей. Теперь мы обсудим значение и обязанности демона Ceph OSD.

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

Основные особенности Ceph, в том числе надежность, выполнение балансировки, восстановления и согласованности привносятся OSD. Основываясь на настроенных размерах репликаций, Ceph обеспечивает надежность за счет тиражирования каждого объекта несколько раз по узлам кластера, что делает объекты весьма доступными и отказоустойчивыми. Каждый объект в OSD имеет одну первичную копию и несколько вторичных копий, которые разбросаны по остальным OSD. Поскольку Ceph является распределенной системой, а объекты распределены по нескольким OSD, каждый OSD выступает первичным OSD для некоторых объектов, и в то же время, он становится вторичным OSD для других объектов. Вторичный OSD остается под контролем основного OSD; однако, они способны стать первичным OSD. Начиная с редакции Ceph Firefly (0.80) был добавлен новый механизм защиты данных, известный как кодирование стирания. Мы подробно ознакомимся с кодированием стирания в последующих главах.

В случае сбоя диска демон Ceph OSD интеллектуально обменивается данными с другими равноправными OSD для выполнения операции восстановления. В течение этого времени хранящие реплицированные копии отказавших объектов вторичные OSD повышают ранг до первичных, и одновременно в ходе операции восстановления OSD создаются новые копии вторичных объектов, причем это полностью прозрачно для клиентов. Данные функции делают кластер Ceph надежным и согласованным. Типичная реализация кластера Ceph создает OSD демон для каждого физического диска в узле кластера, что является рекомендуемой практикой. Тем не менее, OSD поддерживает гибкое развертывание одного OSD на диск, на хост, или на том RAID. Большинство реализаций кластера Ceph в среде JBOD использует один OSD демон на один физический диск.

Файловая система OSD Ceph

Ceph OSD состоит из физического диска, файловой системы Linux поверх него, и службы Ceph OSD. Файловая система Linux существенна для демона OSD Ceph, поскольку она поддерживает расширенные атрибуты ( XATTRs, extended attributes ). Такие расширенные атрибуты файловые предоставляют демону Ceph OSD внутреннюю информацию о состоянии объекта, моментальных снимках, метаданных и ACL, которая помогает в управлении данными. Посмотрите на следующую диаграмму:

Ceph OSD работает поверх физического диска, имеющего допустимый раздел Linux. Раздел Linux может быть либо Btrfs (файловая система B-деревьев), XFS или ext4. Выбор файловой системы является одним из основных критериев для выполнения эталонного тестирования вашего кластера Ceph. В отношении Ceph, эти файловые системы отличаются друг от друга различными свойствами:

XFS : Это надежная, зрелая и очень стабильная файловая система, а следовательно, рекомендуется для использования в промышленных кластерах Ceph. Поскольку Btrfs не готова к промышленному использованию, XFS является наиболее часто используемой файловой системы в системах хранении Ceph и рекомендуется для OSD. Тем не менее, при сравнении с Btrfs XFS располагается ниже. XFS имеет проблемы с производительностью при масштабировании метаданных. Кроме того, XFS является файловой системой с журналированием, то есть, каждый раз, когда клиент отправляет данные на запись в кластер Ceph, они вначале записываются в пространство журналирования, а затем в файловую систему XFS. Это увеличивает издержки записи одних и тех же данных в два раза, и, таким образом, делает производительность XFS более медленной по сравнению с Btrfs, которая не использует журналы.

ext4 : Четвертая расширяемая файловая система также является журналируемой файловой системой, которая является готовой к промышленному использованию файловой системой для Ceph OSD; однако, она не настолько популярна как XFS. С точки зрения производительности ext4 не сопоставима с Btrfs

Журнал OSD Ceph

Для OSD Ceph использует журналируемые файловые системы, такие как Btrfs и XFS. Перед фиксацией данных на устройстве хранения, Ceph вначале записывает данные в отдельную область хранения, называемую журналом, которая является меньшим разделом размера буфера, либо на том же шпиндельном диске, либо на отдельном шпиндельном диске, или на отдельном твердотельном диске (SSD), или даже просто файлом в файловой системе. При подобном механизме Ceph первоначально записывает все в журнал, а затем разгружает в хранилище, как показано на следующей диаграмме:

Журнал выгружается во внешнее хранилище путем синхронизации, по умолчанию выполняемой каждые пять секунд. Обычным размером для журнала является емкость в 10 ГБ, но чем больше размер раздела, тем лучше. Ceph использует журналы для скорости и согласованности. Журнал позволяет Ceph OSD выполнять малые записи быстро; случайные записи вначале вначале выполняются последовательным образом в журнал, а затем сбрасываются в файловую систему. Это позволяет файловой системе объединять операции записи на диск. Относительное увеличение производительности наблюдается, когда журналы создаются в разделах твердотельных дисков. При таком подходе все записи клиентов вначале осуществляются в суперскоростные журналы SSD, а затем сбрасываются на шпиндельные диски.

Использование твердотельных дисков в качестве журналов для OSD поглощает всплески рабочей нагрузки. Однако, если ваши журналы медленнее чем ваши устройства постоянного хранения, это может стать ограничительным фактором в производительности вашего кластера. В качестве рекомендации, вы не должны превышать соотношение OSD к журналу в 4 или 5 OSD на диск журнала при использовании внешнего твердотельного диска для журналов. Превышение указанного количества OSD на журнальный диск может создать узкое место в производительности для вашего кластера. К тому же, если отказывает ваш диск журнала, который обслуживает множество OSD под управлением файловой системы XFS или ext4, вы потеряете OSD и его данные.

Это является случаем, при котором Btrfs имеет преимущество; в случае отказа журнала в файловой системе на основе Btrfs, она откатывает назад по времени, приводя к минимальным потерям данных или совсем избегая их. Btrfs является файловой системой копирования-при-записи, что означает, что если содержимое блока изменено, то измененный блок записывается отдельно, таким образом, старый блок остается нетронутым. В случае происшествия с журналом, данные остаются доступными, поскольку старое содержание все еще доступно. Для дополнительной информации по Btrfs, посетите https://btrfs.wiki.kernel.org.

До сих пор мы обсуждали использование физических дисков для Ceph OSD. Однако, реализации кластеров Ceph также используют в своей основе RAID для OSD. Мы не рекомендуем вам использовать RAID для хранения ваших данных в кластере Ceph по целому ряду причин, которые перечисляются ниже:

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

На производительность кластера Ceph существенное влияние может оказывать RAID со случайными операциями ввода/вывода, при RAID 5 и 6 она будет просто очень низкой.

Существуют случаи применения, при которых RAID может быть полезным. Например, если у вас существует очень большое количество дисков на одно хосте, и вы должны запускать по демону для каждого, вы можете подумать о создании тома RAID путем объединения некоторого количества дисков с последующим запуском OSD поверх такого тома RAID. Это уменьшит количество демонов OSD по сравнению с количеством физических дисков.

Например, если у вас есть насыщенный узел с 64 физическими дисками при низком значении системной оперативной памяти в 24ГБ, рекомендуемая конфигурация OSD, будет требовать 128 ГБ оперативной памяти (2 ГБ на один физический диск) для машин с 64 физическими дисками. Поскольку вы не имеете достаточной емкости системных ресурсов для OSD, вы можете рассмотреть возможность создания групп RAID для ваших физических дисков (шесть RAID групп с 10 физическими дисками на RAID группу плюс четыре запасных диска) и после этого запустить OSD для этих шести групп RAID. Таким образом, вам потребуется примерно 12 ГБ оперативной памяти, которыми вы располагаете.

Недостатком такого подхода будет то, что в случае отказа OSD, вы потеряете данные на всех 10 дисках, (во всей группе RAID), что является большим риском. Следовательно, по возможности пытайтесь избегать групп RAID для OSD.

Команды OSD

Ниже приводится команда проверки состояния OSD для отдельного узла:

Следующая команда проверяет ID OSD:

Далее следует команда для проверки карты OSD и их состояния:

Приводимая ниже команда проверяет дерево OSD:

Мониторы Ceph

Как это следует из названия, мониторы Ceph отвечают за контроль состояния работоспособности всего кластера. Это демоны, которые поддерживают режим членства в кластере путем сохранения важной информации о кластере, состояния одноранговых узлов, а также информации о настройках кластера. Монитор Ceph выполняет свои задачи поддерживая главную копию < Прим. пер.: карты(?) > кластера. Карта кластера содержит карты монитора, OSD, PG, CRUSH и MDS. Все эти карты в совокупности известны как карта кластера. Давайте бросим беглый взгляд на каждую из этих карт:

Карта монитора : Она содержит полную информацию об узле монитора, которая включает в себя ID кластера Ceph, имя хоста монитора, а также IP адрес монитора с номером порта. Она также хранит текущий период (epoch) для создания карты и информацию о последнем изменении. Вы можете проверить карту вашего монитора выполнив:

Карта OSD (устройства хранения объектов): Она хранит некоторые общие поля, такие как ID кластера, период (epoch) создания карты OSD и информацию о последнем изменении; а также информацию, относящуюся к пулам, такую как имена пулов, ID пулов, тип, уровень репликаций и группу размещения. Она также хранит такую информацию OSD, как количество, состояние, вес, интервал последней очистки и информацию о хосте OSD. Вы можете сверить свою карту устройства хранения объекта, выполнив:

Карта PG (групп размещения): Она содержит информацию о версии группы размещения, временной метки, последнем периоде (epoch) карты OSD, полном соотношении и близком к полному соотношению. Она также содержит отслеживание ID каждой группы размещения, количества объектов, состояний, отпечатков состояний, наборов рабочего состояния и действия OSD и, наконец, детали очистки. Для контроля карты групп размещения выполните:

Карта CRUSH (управляемых масштабируемым хешированием репликаций): Она содержит информацию о ваших устройствах хранения кластера, иерархию домена отказов и определенных для домена отказов правил при сохранении данных. Для проверки карты управляемых масштабируемым хешированием репликаций выполните следующую команду:

Карта MDS (сервера метаданных): Она хранит информацию о текущем периоде (epoch) карты MDS, времени создания и изменения карты, ID пула данных и метаданных, количестве серверов метаданных кластера и состоянии MDS. Для сверки состояния карты сервера метаданных выполните:

Монитор Ceph не хранит данные на клиентах и не обслуживает их данные, скорее, он предоставляет обновления карт кластера клиентам и другим узлам кластера. Клиенты и узлы кластера периодически сверяются с мониторами на предмет самых последних карт кластера.

Мониторы являются легкими демонами, которые не требуют огромных системных ресурсов. Для большинства реализаций будет достаточно сервера нижнего уровня с низкой стоимостью с достойными процессором, оперативной памятью и гигабитным Ethernet. Узел монитора должен иметь достаточную емкость диска для хранения журналов кластера, включая журналы OSD, MDS и монитора. Обычный работоспособный кластер создает журналы с размерами протоколов от нескольких МегаБайт до нескольких Гигабайт; однако потребность к емкости резко возрастает для кластера при детальном/ отладочном уровне. Для хранения журналов должно быть предоставлено несколько ГБ дискового пространства.

Важно быть уверенным, что системный диск далек от заполнения, в противном случае кластеры могут сталкиваться с проблемами. Рекомендуются планируемая политика ротации, а также регулярный мониторинг использования файловой системы, в особенности для мониторов с увеличенными отладочными подробностями, которые могут приводить к возникновению огромных журналов со средней скоростью 1 ГБ в час.

Обычный кластер Ceph содержит более одного узла монитора. Архитектура со множеством мониторов создает кворум и обеспечивает согласованность для распределенного принятия решений в кластере с использованием алгоритма Paxos < Прим. пер.: https://ru.wikipedia.org/wiki/Алгоритм_Паксос, https://github.com/kostja/lectures/blob/master/10.paxos.txt >. Количество мониторов в вашем кластере должно быть нечетным числом; абсолютный необходимый минимум состоит из одного узла монитора, а рекомендуемым числом является три. Поскольку мониторы работают в кворуме, более половины общего числа узлов мониторов должно быть всегда доступно чтобы избежать проблем раздвоения сознания, которые наблюдаются в других системах. Это причина, по которой рекомендуется нечетное число мониторов. Из всех этих мониторов кластера один из них выступает в роли ведущего. Другие узлы мониторы имеют право стать ведущими, если монитор- лидер становится недоступным. Находящийся в промышленной эксплуатации кластер должен иметь по крайней мере три узла мониторов для обеспечения высокой доступности.

Предыдущий вывод результатов демонстрирует ceph-node1 в качестве нашего начального монитора и ведущего в кластере. Вывод результатов также объясняет состояние кворума и другие подробности монитора.

Если у вас существуют бюджетные ограничения или вы осуществляете хостинг малого кластера Ceph, демоны монитора могут работать на тех же узлах, что и OSD. Однако при такой реализации мы рекомендуем использовать бОльшие процессоры, оперативную память и системные диски для хранения журналов монитора, если вы планируете запускать службы монитора и OSD на одном общем узле.

Для промышленной среды уровня предприятия мы рекомендуем использовать выделенные узлы монитора. Если вы потеряете узел OSD, вы все еще сможете осуществлять связь с вашим кластером если достаточно мониторов работает на отдельных машинах. На этапе планирования кластера также должно быть рассмотрено физическое расположение в стойках. Вы должны рассредоточить ваши узлы монитора во всех имеющихся у вас областях отказов, например, различные коммутаторы, источники электропитания и физические стойки. Если вы имеете множество центров данных с единой высокоскоростной сетевой средой, ваши узлы монитора должны быть в различных центрах данных.

Команды монитора

Для проверки состояния службы монитора выполните следующую команду:

Источник