Ceph является проектом с открытым кодом,
который предоставляет определяемые программным обеспечением унифицированные решения для хранения данных.
Ceph является распределенной системой хранения, которая является массивно масштабируемой и
высокопроизводительной и при этом не имеет единой точки отказа. С самого начала она разрабатывалась
для высокой масштабируемости, до уровней эксабайт и выше, при работе на общеупотребимых аппаратных средствах.
Подробно о внутренней Кухне CEPH
Подробно о внутренней Кухне CEPH
Демоны
Mon - демон монитора
Монитор — это демон, выполняющий роль координатора, с которого
начинается кластер. Как только у нас появляется хотя бы один рабочий
монитор, у нас появляется Ceph-кластер. Монитор хранит информацию о
здоровье и состоянии кластера, обмениваясь различными картами с другими
мониторами. Клиенты обращаются к мониторам, чтобы узнать, на какие OSD
писать/читать данные. При разворачивании нового хранилища, первым делом
создается монитор (или несколько). Кластер может прожить на одном
мониторе, но рекомендуется делать 3 или 5 мониторов, во избежание
падения всей системы по причине падения единственного монитора. Главное,
чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения
сознания (split-brain). Мониторы работают в кворуме, поэтому если упадет
больше половины мониторов, кластер заблокируется для предотвращения
рассогласованности данных.
OSD - демон хранилища
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.
Если size=1, кластер будет работать, но смерть любой OSD будет означать безвозвратную потерю данных. Ceph дозволяет выставить этот параметр в единицу, но даже если администратор делает это с определенной целью на короткое время, он риск берет на себя.
Диск OSD состоит из двух частей: журнал и сами данные. Соответственно, данные сначала пишутся в журнал, затем уже в раздел данных. С одной стороны это дает дополнительную надежность и некоторую оптимизацию, а с другой стороны — дополнительную операцию, которая сказывается на производительности. Вопрос производительности журналов рассмотрим ниже.
При разных вариантах настройки этих параметров, мы будем наблюдать и разное поведение.
Если size=3 и min_size=2: все будет хорошо, пока 2 из 3 OSD плейсмент-группы живы. Когда останется всего лишь 1 живой OSD, кластер заморозит операции данной плейсмент-группы, пока не оживет хотя бы еще один OSD.
Если size=min_size, то плейсмент-группа будет блокироваться при падении любого OSD, входящего в ее состав. А из-за высокого уровня размазанности данных, большинство падений хотя бы одного OSD будет заканчиваться заморозкой всего или почти всего кластера. Поэтому параметр size всегда должен быть хотя бы на один пункт больше параметра min_size.
Если size=1, кластер будет работать, но смерть любой OSD будет означать безвозвратную потерю данных. Ceph дозволяет выставить этот параметр в единицу, но даже если администратор делает это с определенной целью на короткое время, он риск берет на себя.
Диск OSD состоит из двух частей: журнал и сами данные. Соответственно, данные сначала пишутся в журнал, затем уже в раздел данных. С одной стороны это дает дополнительную надежность и некоторую оптимизацию, а с другой стороны — дополнительную операцию, которая сказывается на производительности. Вопрос производительности журналов рассмотрим ниже.
MDS - сервер метаданных (для CephFS)
Фактор репликации (RF)
Фактор репликации — это уровень избыточности данных. Количество копий
данных, которое будет храниться на разных дисках. За этот параметр
отвечает переменная size. Фактор репликации может быть разным для
каждого пула, и его можно менять на лету. Вообще, в Ceph практически все
параметры можно менять на лету, мгновенно получая реакцию кластера.
Сначала у нас может быть size=2, и в этом случае, пул будет хранить по
две копии одного куска данных на разных дисках. Этот параметр пула можно
поменять на size=3, и в этот же момент кластер начнет перераспределять
данные, раскладывая еще одну копию уже имеющихся данных по дискам, не
останавливая работу клиентов.
Пул
Пул — это логический абстрактный контейнер для организации хранения
данных пользователя. Любые данные хранятся в пуле в виде объектов.
Несколько пулов могут быть размазаны по одним и тем же дискам (а может и
по разным, как настроить) с помощью разных наборов плейсмент-групп.
Каждый пул имеет ряд настраиваемых параметров: фактор репликации,
количество плейсмент-групп, минимальное количество живых реплик объекта,
необходимое для работы и т. д. Каждому пулу можно настроить свою
политику репликации (по городам, датацентрам, стойкам или даже дискам).
Например, пул под хостинг может иметь фактор репликации size=3, а зоной
отказа будут датацентры. И тогда Ceph будет гарантировать, что каждый
кусочек данных имеет по одной копии в трех датацентрах. Тем временем,
пул для виртуальных машин может иметь фактор репликации size=2, а
уровнем отказа уже будет серверная стойка. И в этом случае, кластер
будет хранить только две копии. При этом, если у нас две стойки с
хранилищем виртуальных образов в одном датацентре, и две стойки в
другом, система не будет обращать внимание на датацентры, и обе копии
данных могут улететь в один датацентр, однако гарантированно в разные
стойки, как мы и хотели.
Плейсмент-группа (PG)
Плейсмент-группы — это такое связующее звено между физическим уровнем хранения (диски) и логической организацией данных (пулы).
Каждый объект на логическом уровне хранится в конкретной плейсмент-группе. На физическом же уровне, он лежит в нужном количестве копий на разных физических дисках, которые в эту плейсмент-группу включены (на самом деле не диски, а OSD, но обычно один OSD это и есть один диск, и для простоты я буду называть это диском, хотя напомню, за ним может быть и RAID-массив или iSCSI-устройство). При факторе репликации size=3, каждая плейсмент группа включает в себя три диска. Но при этом каждый диск находится во множестве плейсмент-групп, и для каких то групп он будет первичным, для других — репликой. Если OSD входит, например, в состав трех плейсмент-групп, то при падении такого OSD, плейсмент-группы исключат его из работы, и на его место каждая плейсмент-группа выберет рабочий OSD и размажет по нему данные. С помощью данного механизма и достигается достаточно равномерное распределение данных и нагрузки. Это весьма простое и одновременно гибкое решение.
Каждый объект на логическом уровне хранится в конкретной плейсмент-группе. На физическом же уровне, он лежит в нужном количестве копий на разных физических дисках, которые в эту плейсмент-группу включены (на самом деле не диски, а OSD, но обычно один OSD это и есть один диск, и для простоты я буду называть это диском, хотя напомню, за ним может быть и RAID-массив или iSCSI-устройство). При факторе репликации size=3, каждая плейсмент группа включает в себя три диска. Но при этом каждый диск находится во множестве плейсмент-групп, и для каких то групп он будет первичным, для других — репликой. Если OSD входит, например, в состав трех плейсмент-групп, то при падении такого OSD, плейсмент-группы исключат его из работы, и на его место каждая плейсмент-группа выберет рабочий OSD и размажет по нему данные. С помощью данного механизма и достигается достаточно равномерное распределение данных и нагрузки. Это весьма простое и одновременно гибкое решение.
Команды
ceph df
ceph osd stat
ceph osd dump
ceph osd tree
ceph mds stat
ceph fs dump
Комментариев нет:
Отправить комментарий