Глава 3. Архитектура и компоненты 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 по целому ряду причин, которые перечисляются ниже:

Замечание

Существуют случаи применения, при которых 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 для отдельного узла:

# service ceph status osd

[root@ceph-node1 ~]# service ceph status osd
===== osd. 2 ===
osd.2: running {"version":"0.72.2"}
=== osd.l ===
osd.1: running {"version":"0.72.2"}
=== osd.O =
osd.O: running {"version":"0.72.2"}
[root@ceph-node1 ~]#

Приводимая далее команда проверяет состояние всего кластера. Имейте в виду, что для того, чтобы управлять всем кластером OSD из одного узла, файл ceph.conf должен иметь информацию обо всех OSD с именами их хостов. Для достижения этой цели вы должны обновлять файл ceph.conf. Это понятие объясняется в последующих главах.

# service ceph -a status osd

[root@ceph-node1 ~]# service ceph -a status osd
== osd. 2 ===
osd.2: running {"version”:"0.72.2"}
=== osd.1 ===
osd.1: running {"version":"0.72.2"}
=== osd.0 ===
osd.O: running {"version”:"0.72.2"}
=== osd.3 ===
osd.3: running {"version":"0.72.2"}
=== osd.4 ===
osd.4: running {"version":"0.72.2"}
== osd. 5 ===
osd.5: running {"version":"0.72.2"}
=== osd.6 ===
osd.6: running {"version":"0.72.2"}
=== osd.7 ===
osd.7: running {"version":"0.72.2"}
=== osd.8 ===
osd.8: running {"version":"0.72.2"}
[root@ceph-node1 ~]# _

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

# ceph osd ls

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

# ceph osd stat

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

# ceph osd tree

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

# service ceph status mon

Существует множество способов ознакомления с состоянием монитора, например такие:

# ceph mon stat
# ceph mon_status
# ceph mon dump

Взгляните на следующий скриншот:

[root@ceph-node1 -]# ceph mon stat
e9: 3 mons at {ceph-node1=192.168.57.101:6789/0,ceph-node2=192.168.5
7.102:6789/0,ceph-node3=192.168.57.103:6789/0}, election epoch 152,
quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3
[root@ceph-node1 ~]#
[root@ceph-node1 ~]# ceph mon_status
{"name":"ceph-node1","rank":0,"state":"leader","election_epoch":152,
"quorum":[0,1,2],"outside_quorum":[],"extra_probe_peers":[],"sync_pr
ovider":[],"monmap":{"epoch":9,"fsid":"ffa7c0e4-6368-4032-88a4-5fb6a
3fb383c","modified":"2014-04-15 23:16:08.649712","created":"0.000000
","mons":[{"rank":0,"name":"ceph-node1","addr":"192.168.57.101:6789\
/0"},{"rank":1,"name":"ceph-node2","addr":"192.168.57.102:6789\/0"},
{"rank":2,"name":"ceph-node3","addr":"192.168.57.103:6789\/0"}]}}
[root@ceph-node1 ~]#
[root@ceph-node1 ~]# ceph mon dump
dumped monmap epoch 9
epoch 9
fsid ffa7c0e4-6368-4032-88a4-5fb6a3fb383c
last_changed 2014-04-15 23:16:08.649712
created 0.000000
0: 192.168.57.101:6789/0 mon.ceph-node1
1: 192.168.57.102:6789/0 mon.ceph-node2
2: 192.168.57.103:6789/0 mon.ceph-node3

[root@ceph-node1 ~]#

librados является естественной библиотекой C, которая позволяет приложениям напрямую работать с RADOS, минуя другие уровни интерфейса для взаимодействия с кластером Ceph. librados является библиотекой для RADOS, которая предлагает богатую поддержку API, которая позволяет приложениям выполнять прямые и одновременные запросы к кластерам без HTTP заголовков. Приложения имеют возможность расширять свои собственные протоколы для получения доступа к RADOS через соединения librados. Аналогичные библиотеки доступны,чтобы расширить поддержку для C++, Java, Python, Ruby и PHP. librados выступает в качестве основы для других служебных интерфейсов, которые строятся поверх собственного интерфейса librados, который включает в себя блочные устройства Ceph, файловую систему CephFS и шлюз Ceph RADOS. librados поддерживает богатые подмножества API, эффективное хранение ключ / значение внутри объекта. API поддерживает транзакции с единым объектом-атомом путем совместного обновления данных, ключей и атрибутов. Межклиентское взаимодействие осуществляется через объекты.

Прямое взаимодействие с кластерами RADOS через библиотеку librados резко повышает производительность, надежность и эффективность приложений. librados предлагает очень мощный библиотечный набор, который может предоставить дополнительные преимущества облачным решениям Платформа-как-Служба (PaaS) и Программное-обеспечение-как-служба (SaaS).

Блочные хранилища являются одним из наиболее распространенных форматов для хранения данных в корпоративных средах. Блочные устройства Ceph известны также как блочные устройства RADOS (RBD, RADOS block device). Они предоставляют решения блочного хранения физическим гипервизорам и виртуальным машинам. Драйвер Ceph RBD был интегрирован в ядро Linux основной линии (2.6.39 и выше) и поддерживается QEMU/ KVM, обеспечивая бесшовный доступ к блочному устройству Ceph.

Хосты Linux расширяют полную поддержку Ядра RBD (KRBD, Kernel RBD) и карт блочных устройств Ceph с применением librados. RADOS затем сохраняет объекты блочных устройств Ceph по всем кластерам распределенным образом. Будучи включенным в состав карты на хосте Linux, блочное устройство Ceph может использоваться как сырой (RAW) раздел или может быть помечен в файловой системе с последующим монтированием.

С самого начала Ceph был тесно интегрирован в облачные платформы, подобные OpenStack. Для Cinder и Glance, которые являются программами томов и образов для OpenStack, Ceph предоставляет сервера блочных устройств для хранения томов виртуальных машин и образов операционных систем. Эти тома и образы являются динамично выделяемыми (thin provisioning) {Прим. пер.: http://en.wikipedia.org/wiki/Thin_provisioning, http://habrahabr.ru/post/170389/}. Должны сохраняться только измененные объекты; это помогает сохранять в OpenStack значительное пространство хранения. Свойства Ceph копирования-при-записи (copy-on-write {Прим. пер.: при изменении новых данных эти данные вначале копируются в новую область}) и мгновенного клонирования (instant cloning) помогают OpenStack помогают раскручивать сотни экземпляров виртуальных машин за меньшее время. RBD также поддерживает моментальные снимки, тем самым быстро сохраняя состояние виртуальной машины, которое в последующем может быть клонировано для создания виртуальной машины того же типа и использоваться для восстановления временных точек. Ceph работает как обычный сервер для виртуальных машин, и таким образом помогает виртуальным машинам осуществлять миграцию, поскольку все виртуальные машины могут осуществлять доступ к кластеру хранения Ceph. Контейнеры виртуализации, такие как QEMU, KVM и XEN могут быть настроены для загрузки виртуальных машин с томов, хранящихся в кластере Ceph.

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

Ceph RBD затмевает и заменяет дорогостоящие решения SAN для хранения данных, предоставляя возможности корпоративного класса, такие как динамичное выделение, копирование-при-записи моментальных снимков и клонирования, реверсивных снимков, доступных только для чтения, а также поддерживает облачные платформы, такие как OpenStack и CloudStack. В последующих главах мы узнаем больше о блочных устройствах Ceph.

Шлюз объектов Ceph, также известный как шлюз RADOS, является прокси, который преобразовывает запросы HTTP в запросы RADOS и наоборот, предоставляя объектное хранилище RESTful, которое является совместимым с S3 и Swift. Объектное хранилище Ceph использует демон шлюза объектов Ceph (radosgw) для взаимодействия с библиотекой librgw и кластером Ceph, librados. Он реализован как модуль FastCGI при помощи libfcgi, и может использоваться любым FastCGI- совместимым веб- сервером. Хранилище объектов Ceph поддерживает три интерфейса:

Следующая диаграмма показывает различные методы доступа, которые используют шлюз RADOS и librados для хранения объектов.

Шлюз объектов Ceph имеет свое собственное управление пользователями. И S3, и Swift API используют общее пространство имен внутри кластера Ceph, следовательно вы можете записывать данные одним API, а получать их другим. Для быстрой обработки он может использовать память для эффективного кэширования метаданных. Также вы можете использовать более одного шлюза и оставлять их под управлением балансировщика нагрузки для эффективного управления нагрузкой на ваше хранилище объектов. Улучшение производительности достигается за счет разбиения больших объектов REST на меньшие по размеру объекты RADOS. Взамен S3 и Swift API, ваше приложение может обойти шлюз RADOS и получить прямой одновременный доступ к librados, т.е. к кластеру Ceph. Это может быть эффективно использовано в индивидуальных корпоративных приложениях, которые требуют с точки зрения хранилища экстремальной производительности, путем удаления дополнительных уровней. Ceph допускает прямой доступ к своему кластеру. Это поднимает над другими решениями хранения данных, которые являются жесткими и имеют ограничения в интерфейсе.