Глава 9. Снабжение хранением Ceph

Как обсуждалось в Главе 2, Компоненты и службы Ceph, клиенты Ceph могут могут быть разделены на три категории с различными интерфейсами, причём каждый из них будет описан в данной главе:

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

Многие оснащения, использующие такие платформы как OpenStack или DigitalOcean осуществляют управление и подключают образы RBD на определённом уровне виртуализации, поэтому они проявляются в их гостевых операционных системах посредством драйверов SCSI или Virtio. Здесь мы также применяем имеющийся драйвер самого ядра Linux в некоторых произвольных, даже выполненных в виде голого железа системах.

RBD (RADOS Block Device) - первоначально именовавшиеся как Ceph Block Device - предоставляют клиентам Ceph постоянное устройство хранения на основе блочных устройств. Такие блочные устройства представляются обычными устройствами в определённой машине клиента. Это устройство может применяться различными способами. Оно может быть использовано как сырое блочное устройство, либо как некоторая файловая система посредством создания в ней раздела, его форматирования и последующего монтирования.

RBD пользуются возможностями библиотеки librbd и сохраняет блоки данных, разделяя их по множеству OSD в некотором кластере Ceph. RBD построен на самом основном уровне Ceph, RADOS. Таким образом, каждое блочное устройство распределяется по множеству узлов Ceph и снабжается высокой производительностью и исключительной надёжностью.

RBD обогащён функциональностью корпоративного уровня, включая динамическое выделение, изменение размера в реальном времени, моментальные снимки Копирование-записью (CoW, Copy-on-Write), а также кэширование стороны клиента. Имеющийся протокол RBD полностью поддерживается в рамках Linux через драйвер ядра основной линии; он также эксплуатируется платформами виртуализации, такими как KVM, QEMU и libvirt чтобы позволять виртуальным машинам получать преимущества Блочных устройств Ceph. Эти свойства делают RBD неким уникальным решением для таких облачных платформ, как OpenStack и CloudStack {Прим. пер.: а также Proxmox}. Теперь мы изучим как создавать и применять Блочные устройства Ceph.

Мы предполагаем, что у вас имеется некая песочница с рабочим кластером Ceph, настроенная с одним или более узлами Мониторов, одним или более узлами OSD, а также, по крайней мере, один узел клиента. Эти узлы могут быть виртуальными машинами если вы исполняете тот кластер, который мы создали в Глава 5, Развёртывание виртуального кластера песочницы, либо они могут быть физическими экземплярами, если вы уже имеете некий работающий кластер. Большая часть приводимых далее действий будет осуществлена на самом узле клиента, однако, если вам необходимо исполнять команду на узле OSD или MON, вы будете об этом уведомлены дополнительно.

Давайте запустим ведение протокола на вашем узле клиента и переключимся на своего пользователя root:

$ vagrant ssh client0
vagrant@ceph-client0:~$ sudo -i
root@ceph-client0:~#
		

Теперь мы можем создать некое блочное устройство RADOS с названием ceph-client1-rbd1. Мы будем применять инструмент командной строки rbd для взаимодействия с Ceph. Эта команда должна уже быть доступной в вашем узле клиента после установки необходимого пакета, которую мы выполнили в Глава 5, Развёртывание виртуального кластера песочницы:

root@ceph-client0:~# rbd create ceph-client1-rbd1 --size 10240
		

Если приведённая выше команда отказывает с ошибкой полномочий, нам потребуется разрешить узлу клиента доступ к своему кластеру Ceph. Для этого будет необходимо добавить некий keyring для пользователя, который имеет права доступа чтения- записи к данному кластеру, помещаемые совместно с основным файлом настроек Ceph. Этот пользователь, который будет получать аутентификацию через данный keyring в предположении, что он разрешённый пользователь с неким подходящим набором полномочий, которые позволяют ему выполнять в данном кластере операции чтения- записи. По причинам безопасности нам следует быть аккуратными и не распространять keyrings с полномочиями чтения/ записи для хостов, которым это не требуется. Если некий хост нуждается только в доступе на чтение данного кластера, тогда мы можем создать некоего отдельного пользователя только с полномочиями чтения.

При применении нашего клиента из Виртуальной Песочницы, мы уже имеем необходимые соответствующие настройки и пользовательский keyring установлен для общения с данным кластером. Его файлы можно обозревать в установленном по умолчанию каталоге /etc/ceph:

root@ceph-client0:~# ls -l /etc/ceph/
total 16
-rw------- 1 ceph ceph 63 Aug 19 02:49 ceph.client.admin.keyring
-rw-r--r-- 1 ceph ceph 1208 Aug 19 02:49 ceph.conf
		

Когда данная команда rbd create успешно завершится, мы должны иметь некий отдельный образ RBD в своём кластере. Давайте просмотрим все имеющиеся образы, относящиеся к ко всем пользователям в нашем кластере, что должно показать нам и тот образ, который мы только что создали:

root@ceph-client0:~# rbd ls
ceph-client1-rbd1
		

Мы можем применить подкоманду info для поиска дополнительной информации о том образе, который мы только что создали, что можно осуществить через атрибуты или метаданные:

root@ceph-client0:~# rbd info ceph-client1-rbd1
rbd image 'ceph-client1-rbd1':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.ac9c238e1f29
format: 2
features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
flags:
		

По умолчанию образы RBD создаются в рамках пула с названием rbd. Вы можете определить другой пул, предоставляя некий параметр пула в своей команде rbd при помощи переключателя -p. Приводимая ниже команда вернёт тот же самый вывод, что и предыдущая команда, однако мы вручную определяем необходимое название пула. Аналогично вы можете создавать образы RBD внутри прочих пулов с помощью данного переключателя -p:

root@ceph-client0:~# rbd -p rbd info ceph-client1-rbd1
rbd image 'ceph-client1-rbd1':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.ac9c238e1f29
format: 2
features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
flags:
		

Теперь, когда мы создали некое блочное устройство, мы будем пошагово работать над доступом к нему. Чтобы воспользоваться необходимым томом, нам понадобится соотнести его с каким- то блочным устройством ядра в нашей операционной системе клиента. После установления соответствия это устройство должно отображаться в вашем узле клиента как /dev/rbd0.

Установка соответствия данного образа RBD некоторому виртуальному диску с помощью драйвера ядра RBD требует какого- то ядра Linux с версией не ниже 2.6.32. Если вы применяете нашу виртуальную песочницу, необходимая версия ядра вашего клиента должна быть по крайней мере не ниже 4.4.0 и, таким образом быть более чем достаточной для данного упражнения. Прежде чем продолжить, нам вначале необходимо загрузить соответствующий модуль ядра rbd:

root@ceph-client0:~# uname -r
4.4.0-92-generic
root@ceph-client0:~# modprobe rbd
		

Теперь мы можем убедиться, что наш модуль rbd загружен правильно. Команда lsmod отобразит все текущие состояния загруженных модулей. Отметим, что загружаемые на оету модули с modprobe не будут сохраняться на постоянной основе между перезагрузками. Это означает, что если вы должны перезагружать данную машину, вам необходимо вновь повторно загружать этот модуль вручную или через некий сценарий запуска операционной системы. Если вы желаете загружать данный модуль rbd при каждой загрузке операционной системы, вам понадобится добавить его в свой файл /etc/modules и обеспечить наличие всех его зависимостей:

root@ceph-client0:~# lsmod | grep rbd
rbd 69632 0
libceph 245760 1 rbd
		

Теперь у нас имеется всё для использования того образа RBD, который мы создали. Наш следующий шаг состоит в установке соответствия этого образа некоторому устройству ядра в нашем узле клиента чтобы мы могли рассматривать его как некий локальный диск или прочее блочное устройство. Вы сновы воспользуемся утилитой командной строки rbd для сздания данного устройства:

root@ceph-client0:~# rbd map ceph-client1-rbd1
/dev/rbd0
		

Данная команда может завершиться неудачей, если то ядро, которое вы применяете не предоставляет поддержку определённых свойств (или атрибутов) образа, которыми должны обладать самые новые образы librbd. Те свойства, которые поддерживает имеющийся драйвер ядра, слегка отстают от драйвера клиента librbd основного потока, так как он сопровождается и управляется независимо. Отказ может выглядеть следующим образом:

root@ceph-client0:~# rbd map ceph-client1-rbd1
rbd: sysfs write failed
RBD image feature set mismatch. You can disable features unsupported by the kernel with "rbd feature disable".
		

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

Мы можем применить имеющуюся подкоманду свойств в своей утилите rbd для обновления имеющегося набора свойств (атрибутов), которыми должен обладать данный образ:

root@ceph-client0:~# rbd info ceph-client1-rbd1
rbd image 'ceph-client1-rbd1':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.ac9c238e1f29
format: 2
features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
flags:
root@ceph-client0:~# rbd feature disable ceph-client1-rbd1 exclusive-lock,object-map,fast-diff,deep-flatten
root@ceph-client0:~# rbd info ceph-client1-rbd1
rbd image 'ceph-client1-rbd1':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.ac9c238e1f29
format: 2
features: layering
flags:
root@ceph-client0:~# rbd map ceph-client1-rbd1
/dev/rbd0
		

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

root@ceph-client0:~# rbd map ceph-client1-rbd1
/dev/rbd0
		

Установка соответствия данного образа некоторому устройству операционной системы (также именуемого устройством узла) помогает нам в доступе к этому образу как обычному блочному устройству. Теперь мы форматируем это устройство с неким типом операционной системы своего предпочтения, например, XFS, EXT4 или даже ZFS. Затем мы можем выполнять обычные файловые операции на этих устройствах, когда мы смонтируем их в некотором произвольном каталоге mountpoint в своей системе.

root@ceph-client0:~# fdisk -l /dev/rbd0
Disk /dev/rbd0: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4194304 bytes / 4194304 bytes

root@ceph-client0:~# mkfs.xfs /dev/rbd0
meta-data=/dev/rbd0
isize=512 agcount=17, agsize=162816 blks
sectsz=512 attr=2, projid32bit=1
crc=1 finobt=1, sparse=0
bsize=4096 blocks=2621440, imaxpct=25
sunit=1024 swidth=1024 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
sectsz=512 sunit=8 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

root@ceph-client0:~# mkdir /mnt/ceph-vol01
root@ceph-client0:~# mount /dev/rbd0 /mnt/ceph-vol01
root@ceph-client0:~# echo "it works!" > /mnt/ceph-vol01/rbd.txt
root@ceph-client0:~# cat /mnt/ceph-vol01/rbd.txt
it works!
		

Поздравляем! Вы оснастили свой первый том хранения Ceph и готовы осуществлять доступ к файлам в нём, например, champ.

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

Блочные устройства Ceph RBD являются томами с динамическим выделением (thin-provision), что означает, что все лежащие в основе физические хранилища в кластере (предоставляемые OSD) не записываются и/ или не выделяются полностью пока конкретный пользователь не записывает на самом деле данные в это устройство. Например, скажем, мы предоставляем некий том 5 ТБ - нечто, что пользователи данного автора выполняют в действительности ежедневно на локальных дисках, тогда все 5 ТБ выделяются немедленно и вся доступная в Ceph ёмкость немедленно уменьшается на 5 ТБ. Это остаётся справедливым когда данный пользователь записывает 5 ТБ данных, только 1 ТБ, или не записывает ничего вовсе. При динамическом выделении почти никакого пространства на лежащих в основе устройствах немедленно не выделяется и доступная ёмкость при этом не значительно снижается. В этом состоит важнейшее отличие между динамически выделяемыми (provisioned) и одновременно выделяемыми (allocated) данными.

Имеет ся множество преимуществ томов с динамическим выделением. Операции создания являются очень быстрыми, так как записываются только новые объекты метаданных (заголовок, идентификатор и/ или журнал) в имеющийся кластер вне зависимости от предоставляемого данному образу размера. Это делает возможным для диспетчеров продуктов избыточно выделять (overprovision, также применяется термин продавать сверх запасов - oversell) имеющуюся ёмкость в кластере с предположении, что не все клиенты или пользователи заполнят или разместят allocate данные в томах на 100% или даже на 50% от предоставленной (provisioned) им ёмкости. при наихудшем сценарии, когда пользователи на самом деле заполняют свои тома, прозрачное масштабирование ёмкости для приведения её в соответствие настолько же просто, как добавление дополнительных узлов или устройств OSD в данный кластер, как это описывалось в Главе 6, Работа и сопровождение.

Как мы уже писали, пишущие данные строки авторы только что встретили определённых пользователей, которые записывают (выделяют) 8 ТБ данных в день в конкретном кластере, который изначально предоставил 330 ТБ используемого пространства. Мы решили это быстрым ростом прозрачно удвоив доступное пространство всего за два дня. Мы последовательно добавляли новые OSD в новые узлы и при этом никак не воздействовали на пользователей, которые даже не догадывались о таком расширении. Несколько лет назад эти же авторы выполняли это же, даже в меньшем масштабе на обычных томах, базирующихся на HBA (картах RAID). Весь этот сервер, который собирал и обрабатывал данные биллинга, полностью завис на семь часов, что привело значительному счёту самой компании и немалой степени конфуза автору. Имеющаяся гибкость управления решений хранения на основе Ceph неоценима, в особенности при сопоставлении с обычными сценариями, подобными приведённому.

Изменение размера блочного устройства RBD Ceph, однако, всего лишь половина дела. Если та файловая система, которая размещена на этом блочном устройстве или в одном из его разделов не поддерживает изменения размера, тогда такой лежащий в основе том бесполезен. К счастью, все распространённые современные файловые системы, включая XFS, EXT4, Btrfs и ZFS поддерживают изменение размера этой установленной файловой системы после того, как сам размер лежащего в основе блочного устройства был изменён. Пожалуйста, обратитесь к документации для выбранной вами файловой системы относительно того, как изменять размер ваших томов, что в большинстве случаев может быть выполнено в режиме реального времени при небольшом разрыве или вовсе без него.

Для некоторого RBD Ceph мы можем как расширять, так и усекать имеющийся размер. Расширение образа RBD является более простым и менее подвергающим воздействию, нежели отсечение, в особенности, если некий образ имеет значительные объёмы данных размещёнными или записанными в нём. Усечение некоего образа является хитроумным: не будучи проведённым должным образом, оно может повлечь к сбросу допустимых блоков в вашем блочном устройстве. Если они имеют записанной в них ценную информацию, тогда она может быть утрачено навсегда при отказе от этих блоков. Всегда тщательно выполняйте свои действия при усечении некоторого образа. В идеале никогда не следует уменьшать имеющийся размер некоторого образа, в который осуществлялась запись, в особенности, если имеющиеся в нём данные очень важны.

Изменение имеющегося размера некоторого образа RBD может быть выполнено с применением подкоманды изменения размера для rbd или с применением GUI, либо такими инструментами CLI, как doctl Openstack Horizon, Cinder и DigitalOcean, либо через панель управления droplet. Мы применим аргумент --size для определения нового размера, который является удвоением имеющегося выделения. Мы будем работать с тем же самым образом, который уже создали, отформатировали и смонтировали ранее:

root@ceph-client0:~# rbd resize ceph-client1-rbd1 --size 20480
Resizing image: 100% complete...done.
root@ceph-client0:~# rbd info ceph-client1-rbd1
rbd image 'ceph-client1-rbd1':
size 20480 MB in 5120 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.ac9c238e1f29
format: 2
features: layering
flags:
		

Из приводимой информации вывода команды вы можете видеть, что данный образ теперь отражает теперь предоставляемый размер, увеличенный на 20 ГБ. Другой способ убедиться, что это изменение было выполнено в имеющемся в основе блочном устройстве состоит в проверке установленного размера, выдаваемого в отчёте операционной системы клиента для поставленных в соответствие блочных устройств. Мы воспользуемся утилитой lsblk, которая установлена по умолчанию в большинстве систем Linux. Этот инструмент удобно отображает информацию обо всех блочных устройствах, представленных в настоящее время в данной системе:

root@ceph-client0:~# lsblk | grep ceph-vol01
rbd0 251:0 0 20G 0 disk /mnt/ceph-vol01
		

Выводимый в четвёртой колонке размер теперь равен 20G , как и ожидалось. Однако, поскольку мы не обновили текущий размер самой операционной системы, мы всё ещё видим, что df продолжает отображать только 10 ГБ, даже несмотря на то, что наш образ RBD увеличился дважды в своём размере:

root@ceph-client0:~# df -h | grep ceph-vol01
/dev/rbd0 10G 33M 10G 1% /mnt/ceph-vol01
		

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

root@ceph-client0:~# xfs_growfs -d /mnt/ceph-vol01
meta-data=/dev/rbd0 isize=512 agcount=17, agsize=162816 blks
sectsz=512 attr=2, projid32bit=1
crc=1 finobt=1 spinodes=0
data =bsize=4096 blocks=2621440, imaxpct=25
sunit=1024 swidth=1024 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
sectsz=512 sunit=8 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2621440 to 5242880
root@ceph-client0:~# df -h | grep ceph-vol01
/dev/rbd0 20G 34M 20G 1% /mnt/ceph-vol01
		

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

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

Чтобы увидеть как некий моментальный снимок Ceph работает и как оседлать его функциональность, давайте создадим некий файл в нашем смонтированном в настоящий момент образе RBD и запишем в него какие- нибудь данные.

root@ceph-client0:~# ls -l /mnt/ceph-vol01/
total 4
-rw-r--r-- 1 root root 10 Aug 19 15:43 rbd.txt
root@ceph-client0:~# echo "Hello Ceph This is snapshot test" /mnt/ceph-vol01/snaptest_file
root@ceph-client0:~# sync
root@ceph-client0:~# cat /mnt/ceph-vol01/snaptest_file
Hello Ceph This is snapshot test
		

Сейчас мы создадим некий моментальный снимок данного образа и назовём его snap1. После того как мы выполним этот моментальный снимок, мы удалим свой файл, который мы только что создали, чтобы имитировать его потерю или порчу данных. Затем мы вернём этот том в его первоначальное состояние, в котором данный файл всё ещё имелся - откатив свой образ обратно к моментальному снимку snap1.

root@ceph-client0:~# rbd snap create rbd/ceph-client1-rbd1@snap1
root@ceph-client0:~# rm -f /mnt/ceph-vol01/snaptest_file
root@ceph-client0:~# cat /mnt/ceph-vol01/snaptest_file
cat: /mnt/ceph-vol01/snaptest_file: No such file or directory
		

Синтаксис определения командной строки для создания моментального снимка таков:

rbd snap create <pool>/<image>@<snap>
		

Указанные параметры пула и образа выбирают определённый имеющийся ресурс с которым работать, а snap является самим названием этого создаваемого нового моментального снимка. Названием того пула, в котором хранятся по умолчанию все образы RBD, является rbd. Наш образ имел название ceph-client1-rbd1, а мы создали моментальный снимок с именем snap1.

После создания данного моментального снимка мы удалили тот файл, который мы создали в своей смонтированной файловой системе и проверяем что он белее не существует.

Теперь мы будем применять свой моментальный снимок RBD для восстановления имеющейся файловой системы в её первоначальное состояние с нашим snaptest_file вновь на своём месте со всеми своими данными. Прежде чем мы инициируем некий откат, мы должны вначале размонтировать данную файловую систему. А затем, после того как мы выполним откат назад, мы монтируем его вновь в том же самом месте et voila! Наш файл вернулся обратно на своё первоначальное место со всеми своими вложенными данными. Это почти так же, как он совсем не удалялся из этой системы:

root@ceph-client0:~# umount /mnt/ceph-vol01
root@ceph-client0:~# rbd snap rollback rbd/ceph-client1-rbd1@snap1
Rolling back to snapshot: 100% complete...done.
root@ceph-client0:~# mount /dev/rbd0 /mnt/ceph-vol01
root@ceph-client0:~# cat /mnt/ceph-vol01/snaptest_file
Hello Ceph This is snapshot test
		

Здесь мы передаём имеющиеся аргументы в rbd snap rollback точно так же, как мы это делали для rbd snap create. Определение имён пула, образа и снимка - все они нужны чтобы корректно выполнить откат назад к необходимому моментальному снимку.

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

Для удаления некоего имеющегося снимка мы применяем команду rbd snap rm:

root@ceph-client0:~# rbd snap rm rbd/ceph-client1-rbd1@snap1
		

Некий образ может иметь более одного моментального снимка, присутствующего в любой заданный момент времени. Если мы желаем удалить все моментальные снимки, мы можем применить подкоманду purge:

root@ceph-client0:~# rbd snap purge rbd/ceph-client1-rbd1
		

Ceph имеет возможность создавать CoW клоны из моментальных снимков RBD. Этот механизм имеет название уровней моментальных снимков. Свойсвто уровней позволяет Ceph создавать множество клонов некоторого образа RBD. Это свойство чрезвычайно полезно зля частных облаков и платформ виртуализации, таких как OpenStack, CloudStack и Qemu/KVM. Такие платформы позволяют нам применять моментальные снимки для защиты образов RBD, которые содержат образы ОС/ ВМ. Такие образы ОС затем могут клонироваться чтобы раскручивать новые экземпляры ВМ. Моментальные снимки Ceph являются доступными только на чтение, в то время как клоны образа перезаписываемые.

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

Клоны аналогичны образам RBD. В них можно осуществлять запись, их размер можно изменять и можно иметь моментальные снимки и даже клоны их самих. Не все образы RBD поддерживают клоны. В Ceph имеются два типа образов RBD: format-1 и format-2. Все свойства моментальных снимков RBD доступны в обоих типах образов format-1 и format-2. Однако все свойства уровней, которые предоставляют поведение CoW, необходимое для клонов, доступно только для образов RBD с format-2. Самые последние версии Ceph создают все новые образы с format-2, устанавливаемым по умолчанию.

Для целей демонстрации мы создадим некий новый образ с названием ceph-client1-rbd2 и делаем его моментальный снимок. Если всё прошло успешно, мы создадим некий клон этого моментального снимка:

root@ceph-client0:~# rbd create ceph-client1-rbd2 --size 10240 --image-feature layering
root@ceph-client0:~# rbd info ceph-client1-rbd2
rbd image 'ceph-client1-rbd2':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.dd832ae8944a
format: 2
features: layering
flags:
root@ceph-client0:~# rbd snap create ceph-client1-rbd2@snap1
root@ceph-client0:~# rbd snap ls ceph-client1-rbd2
SNAPID NAME SIZE
15 snap1 10240 MB
		

Теперь мы начнём свой процесс создания клона из этого моментального снимка. Защита этого моментального снимка, который будет выступать в роли родителя данного клона является существенной, поскольку удаление такого моментального снимка по неосторожности сделает такой клон неприменимым:

root@ceph-client0:~# rbd snap protect ceph-client1-rbd2@snap1
		

Затем мы создадим некий клон из этого моментального снимка. давайте назовём этот клонированный образ ceph-client1-rbd3. Отметим, что мы изменили суффикс rbd3 в самом конце:

root@ceph-client0:~# rbd clone ceph-client1-rbd2@snap1 ceph-client1-rbd3
		

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

root@ceph-client0:~# rbd info ceph-client1-rbd3
rbd image 'ceph-client1-rbd3':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.dd872eb141f2
format: 2
features: layering
flags:
parent: rbd/ceph-client1-rbd2@snap1
overlap: 10240 MB
		

Последние две строки важны в данном месте и являются неким расширением обычного вывода информации исполнения в сравнении с обычным образом. Имеющееся поле родителя (parent) определяет какой моментальный снимок является предком для данного клона. Это также подразумевает, что данный клон всё ещё ссылается на моментальный снимок своего родителя и, таким образом,нуждается в нём для правильной обработки чтений и записей для имеющихся объектов тома. Поле перекрытия (overlap) показывает сколько данных перекрывают этот дочерний клон с его родительским снимком. На самом начальном этапе, когда некий новый клон создаётся, значение перекрытия эквивалентно имеющемуся размеру самого моментального снимка; это ожидаемо, поскольку они оба идентичны. Однако, по мере записи данных, значение перекрытия уменьшается. Если некий клон перезаписывается целиком, с самого начала до своего полного размера выделения, это завершает перекрытие относительно его родительского моментального снимка.

Как мы уже видели ранее, даже если мы имеем некий клонированный образ, который мы можем читать, и в который мы можем записывать (в отличие от моментальных снимков, с которых мы можем осуществлять только чтение), это всё ешё сохраняет ссылки на некий моментальный снимок в данном кластере. Удаление такого моментального снимка будет либо невозможным, либо завершится и удалением самого клона, если мы продолжим его. Иногда это может быть нежелательным, и вы можете удалить такой снимок и воспринимать данный клон как некий отдельный образ. Ceph предоставляет нам возможность выполнять именно это, что применяет процесс с названием выравнивания (flattening). Выравнивание некоторого клона удаляет все имеющиеся ссылки на его предков и создаёт независимые копии всех его объектов. Это потребляет дополнительное пространство, но это также означает и то, что теперь мы можем удалить тот первоначальный снимок, из которого мы породили данный клон без потери каких- либо данных.

Вот как мы выполняем выравнивание какого- то клонированного объекта. Так как данные из родительского моментального снимка необходимо скопировать в его дочерний образ, этот процесс займёт некоторое время, пропорциональное самому размеру данного образа. Когда этот процесс выравнивания завершён, больше нет зависимости между таким клонированным образом и его родительским моментальным снимком.

Мы применяем подкоманду flatten для выполнения выравнивания некоторого клона:

root@ceph-client0:~# rbd flatten ceph-client1-rbd3
Image flatten: 100% complete...done.
root@ceph-client0:~# rbd info ceph-client1-rbd3
rbd image 'ceph-client1-rbd3':
size 10240 MB in 2560 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.dd872eb141f2
format: 2
features: layering
flags:
		

В качестве результата выравнивания своего клона мы можем видеть, что все ссылки на его предков были удалены. Данный клон теперь присутствует как некий независимый, отдельно расположенный образ и его родительский моментальный снимок или образ может быть удалён при необходимости.

Когда мы выполнили обработку некоторого клона какого- то моментального снимка или мы отсоединились от его предка, нам необходимо удалить защиту этого моментального снимка, чтобы позволить его удаление. Удаление защищённости является неким необходимым этапом для удаления, однако вам может быть не нужным удаление всех моментальных снимков со снятой защитой. Когда, тем не менее, необходимо быть уверенным, что некий моментальный снимок не имеет никаких клонов перед тем как с него можно снять защиту:

root@ceph-client0:~# rbd snap unprotect ceph-client1-rbd2@snap1
		

Если мы желаем удалить такой моментальный снимок со снятой защитой, мы также можем сделать это:

root@ceph-client0:~# rbd snap rm ceph-client1-rbd2@snap1
		

Теперь вы должны знать как применять моментальные снимки и клоны Ceph некоторого образа RBD в своих интересах.

Файловая система Ceph также именуется как CephFS. Это некая POSIX- совместимая распределённая файловая система, которая строится поверх уровня RADOS. Для предоставления хранилища файловой системы CephFS нам потребуется по крайней мере один экземпляр Сервера метаданных (MDS, MetaData Server), работающий совместно с остальным кластером Ceph. Чтобы продемонстрировать монтирование и применение файловой системы CepphFS, мы вновь воспользуемся своим кластером виртуальной песочницы, который мы создали в Главе 5, Развёртывание виртуального кластера песочницы. Мы продемонстрируем два различных варианта применения этой файловой системы:

Давайте запустим вначале раскрутку новой машины для нашего MDS. Это процесс теперь должен быть известен, учитывая то, как мы создавали виртуальные машины MON, OSD и Клиента в Главе 5, Развёртывание виртуального кластера песочницы. Вначале давайте проверим работает наш кластер песочницы или нет. Если нет, давайте запустим его:

$ vagrant status
Current machine states:
client0 poweroff (virtualbox)
mon0 poweroff (virtualbox)
osd0 poweroff (virtualbox)
osd1 poweroff (virtualbox)
osd2 poweroff (virtualbox)
$ vagrant up --no-provision --provider=virtualbox
...
$ vagrant status
Current machine states:
client0 running (virtualbox)
mon0 running (virtualbox)
osd0 running (virtualbox)
osd1 running (virtualbox)
osd2 running (virtualbox)
		

Важно исполнить все приведённые выше команды из того каталога ceph-ansible, который мы клонировали в Главе 5, Развёртывание виртуального кластера песочницы. Команда состояния vagrant. не будет работать ожидаемым образом если мы исполняем её из другого местоположения. Теперь у нас имеется поднятый развёрнутый кластер, причём снова в рабочем состоянии, давайте создадим новую виртуальную машину MDS и сделаем её частью данного кластера. Откроем имеющийся файл с названием vagrant_variables.yml в предпочтительном для вас текстовом редакторе и затем изменим значение поля mds_vms на 1. Сохранённый с изменениями файл должен появиться как описано далее: Давайте снова вызовем команду vagrant up чтобы раскрутить новый экземпляр виртуальной машины. Помните, что что определяемое в каждой строке значение определяет сколько виртуальных машин этого типа необходимо создать и запустить. Если мы увеличим его до 2, мы получим 2 новые созданные для MDS виртуальные машины, и так далее.

Поскольку наш кластер служит исключительно целям проверки концепции применения, нам понадобится только один MDS, однако при работе этой службы в промышленной оснастке, нам понадобятся дополнительные экземпляры во избежание наличия единой точки отказа. После завершения исполнения vagrant мы должны увидеть появившийся узел MDS с состоянием поднятого (up). Давайте предоставим это узел для запуска соответствующих служб CephFS. Важно запустить правильные процессы и создать необходимые пулы Ceph, прежде чем мы начнём применять Файловую систему CephFS. По завершению исполнения предоставления, мы должны получить полностью настроенный сервер MDS в рабочем состоянии. Давайте убедимся в этом, зарегистрировавшись в нашем уже имеющемся узле клиента. Мы можем видеть теперь некий сервер MDS с названием ceph-mds0 как часть нашего кластера. Текущее состояние данного узла также отображается как active, что желательно для жизнеспособности кластера.

Давайте теперь попробуем взаимодействовать со своей файловой системой CephFS при помощи имеющегося драйвера ядра Linux. Более ранние чем v2.6.34 ядра Linux не поддерживают CephFS, однако, скорее всего, вы применяете достаточно современный дистрибутив Linux. Наша песочница применяет версию 4.4.0 ядра Linux, которая включает в себя лучшую поддержку CephFS, чем более ранние версии.

Прежде чем мы смонтируем файловую систему CephFS в своей машине клиента, нам необходимы две порции информации:

IP адрес Монитора можно извлечь из имеющегося файла ceph.conf в нашем узле виртуального клиента. Этот IP адрес представлен в явном виде в записи хоста mon, которую мы можем извлечь следующим образом:

root@ceph-client0:~# cat /etc/ceph/ceph.conf | grep 'mon host'
mon host = 192.168.42.10
		

В системе автора текущим IP адресом в имеющемся узле MON является 192.168.42.10. Скорее всего, он будет иным в вашем кластере. Обратите внимание на то значение, которое вы получите исполнив приведённую выше команду. Мы будем применять это значение при монтировании своей файловой системы CephFS.

Затем мы посмотрим на имеющийся путь для keyring администратора. По умолчанию он должен помещаться внутри вашего каталога /etc/ceph в узле клиента:

root@ceph-client0:~# ls -l /etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring -rw ------- 1 ceph ceph 63 Aug 19 02:49 /etc/ceph/ceph.client.admin.keyring
		

Нам понадобится выделить это значение для того ключа, который мы будем применять для своего secret чтобы передать его в необходимую команду монтирования:

root@ceph-client0:~# cat /etc/ceph/ceph.client.admin.keyring
[client.admin]
     key = AQBtuoRZRWixMhAAfVIRFj5fY3nhmfotLHZrmQ==
		

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

root@ceph-client0:~# mkdir /mnt/kernel_cephfs
		

Теперь, когда у нас имеется своя точка монтирования, давайте выполним монтирование гашей файловой системы в ней. Синтаксис команды mount показан в следующей команде:

mount -t ceph <ip address of mon>:6789/ <mount-point> 
      -o <options including name= and secret=>"

root@ceph-client0:~# mount -t ceph 192.168.42.10:6789:/ /mnt/kernel_cephfs -o name=admin,secret=AQBtuoRZRWixMhAAfVIRFj5fY3nhmfotLHZrmQ==
		

Теперь мы видим, что наша команда монтирования отработала, проверив все монтирования в своей системе:

root@ceph-client0:~# mount | grep kernel_cephfs
192.168.42.10:6789:/ on /mnt/kernel_cephfs type ceph (rw,relatime,name=admin,secret=<hidden>,acl)
		

Отлично! Вы должны иметь возможность применения своего каталога /mnt/kernel_cephfs для хранения всех своих файлов, которые автоматически будут определять свой путь в ващем кластере Ceph при полной гарантии долговечности и отказоустойчивости.

Передача в строке secret внутри командной строки не является идеальным в отношении безопасности, имея в виду, что эта выполненная команда может быть выцеплена из истории оболочки, отображена с помощью команды ps, либо может быть зарегистрирована удалённою Более безопасный способ выполнения монтирования состоит в записи необходимого ключа в некий файл с последующей передачей его имени файла в исполняемую команду монтирования. Нам потребуется сохранять только сам ключ, который мы выделим из keyring своего администратора в каком- то новом файле, а затем применить соответствующий путь к файлу в новой опции монтирования с названием secretfile вместо определения самого secret в явном виде в CLI.

Если вы применяете более старую версию ядра Linux {Прим. пер.: или FreeBSD, OpenBSD, NetBSD (как puffs), OpenSolaris, Minix 3, Android, macOS}, может оказаться нецелесообразным {невозможным} применение драйвера ядра. Также может иметь место вариант, когда вам потребуется эксплуатировать новые функции CephFS, которые имеющийся драйвер ядра ещё пока не включил. В этом случае вы можете применить драйвер FUSE CephFS.

Прежде чем осуществлять доступ к CephFS через доступный драйвер FUSE нам понадобится вначале установить его. Проверьте свой дистрибутив ОС или прочие репозитории на наличие пакета с названием ceph-fuse и установите его. Наша среда песочницы поставляется с уже установленным ceph-fuse под наши цели, поэтому нам не понадобится что- либо делать здесь. Правда, отлично?

Давайте создадим отделбную точку монтирования для этой файловой системы:

root@ceph-client0:~# mkdir /mnt/cephfs
		

Это всё что требовалось сделать! Мы теперь уже готовы смонтировать имеющуюся файловую систему:

root@ceph-client0:~# ceph-fuse -m 192.168.42.10:6789 /mnt/cephfs
ceph-fuse[6773]: starting ceph client
ceph-fuse[6773]: starting fuse
		

Отметим, что мы применяем тот же самый IP Монитора, который мы ранее использовали для монтирования своей файловой системы через свой драйвер ядра и что он автоматически указывает на установленного по умолчанию пользователя с правами администратора и полномочия. Мы должны теперь иметь возможность видеть свою файловую систему смонтированной в предназначенном для неё месте.

root@ceph-client0:/mnt/cephfs# mount | grep cephfs
ceph-fuse on /mnt/cephfs type fuse.ceph-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
		

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

Ceph предоставляет нам дополнительные абстракции, отличные от образов RBD и CephFS для хранения и доступа к данным. Одним из наиболее широко применяемых является система хранения объектов. Некая система хранения объектов является тем, куда можно загружать файлы и откуда их можно выгружать с серверов хранения применяя простые и стандартные протоколы, такие как HTTP.

Служба хранения Ceph RGW (RADOS Gateway) имеет целью заполнить данную потребность предоставляя совместимые с Amazon S3 и OpenStack Swift интерфейсы поверх объектов RADOS. Имеется множество клиентов GUI, клиентов командной строки и SDK для всех основных языков программирования, которые поддерживают Amazon S3. Обращающимся к системам хранения объектов клиентам необходимо только знать как применять эти широко распространённые инструменты для хранения и извлечения файлов.

Чтобы продемонстрировать как предоставлять некую службу RGW, мы вновь воспользуемся своим кластером песочницы, который мы создали в Главе 5, Развёртывание виртуального кластера песочницы. При оснащении своего промышленного применения, вы, скорее всего пожелаете настроить свою службу RGW на выделенных физических машинах, в зависимости от ожидаемых рабочих нагрузок. Вначале мы проверяем запущен ли наш кластер Ceph в имеющейся среде песочницы в нашей локальной машине, выполнив следующую команду:

$ vagrant status
Current machine states:
client0                  running (virtualbox)
mon0                     running (virtualbox)
osd0                     running (virtualbox)
osd1                     running (virtualbox)
osd2                     running (virtualbox)
		

Если у вас нет в среде песочницы на вашей локальной машины работающего кластера Ceph, убедитесь, что вы выполнили необходимые шаги из Главе 5, Развёртывание виртуального кластера песочницы для его создания. Это необходимое начальное условие для предоставления обсуждаемой службы RGW, которую мы будем применять в данной главе. Если вы ранее уже создали среду песочницы кластера Ceph, вы можете просто запустить vagrant status из имеющегося каталога ceph-ansible, который вы уже клонировали.

Теперь, когда мы проверили что у нас имеется запущенным существующая среда песочницы кластера Ceph, нам необходимо добавить некую новую виртуальную машину для своей службы RGW. Чтобы сделать это, вновь откройте свой файл vagrant_variables.yml в предпочитаемом вами текстовом редакторе и измените значение rgw_vms с 0 на 1.

# DEFINE THE NUMBER OF VMS TO RUN
mon_vms: 1
osd_vms: 3
mds_vms: 0
rgw_vms: 1
nfs_vms: 0
rbd_mirror_vms: 0
client_vms: 1
 	   

Все значения всех прочих полей должны быть оставлены в прежнем состоянии. После обновления данного значения, сохраните этот файл и выйдите из своего редактора. Теперь выполните vagrant up снова как показано далее, чтобы создать новый экземпляр RGW.

$ vagrant up --no-provision --provider=virtualbox
		

Это создаст некую новую виртуальную машину для RGW и подключит её автоматически к остальному имеющемуся кластеру без необходимости каких- либо дополнительных сетевых настроек. После завершения создания экземпляра RGW, нам понадобится настроить свой экземпляр RGW для создания необходимого пользователя, keyring и пулов хранения, выделенных под хранилище объектов. Это вновь осуществляется путём исполнения предоставления в имеющемся кластере:

$ vagrant provision
		

Экземпляр RGW теперь готов для настройки и применения.

Прежде чем мы внесём изменения в свой экземпляр RGW, чтобы он работал с конкретным вариантом использования, мы регистрируемся в нём и проверяем, что наше первоначальное соединение с Ceph настроено надлежащим образом. Все исполняемые в данном экземпляре RGW команды выполняются от имени пользователя root:

$ vagrant ssh rgw0
vagrant@ceph-rgw0:~$ sudo -i
root@ceph-rgw0:~# ceph --keyring /var/lib/ceph/radosgw/ceph-rgw.ceph
rgw0/keyring --id rgw.ceph-rgw0 -s
    cluster e6d4e4ab-f59f-470d-bb76-511deebc8de3
     health HEALTH_OK
     monmap e1: 1 mons at {ceph-mon0=192.168.42.10:6789/0}
            election epoch 8, quorum 0 ceph-mon0
     osdmap e6914: 6 osds: 6 up, 6 in
            flags sortbitwise,require_jewel_osds
      pgmap v20156: 144 pgs, 11 pools, 17246 kB data, 2842 objects
            645 MB used, 64687 MB / 65333 MB avail
                 144 active+clean
root@ceph-rgw0:~# pidof radosgw
13969
		

Значения keyring и id для данного пользователя нашего настроенного экземпляра необходимо определить таким образом, чтобы инструменты командной строки Ceph были способны выполнять аутентификацию в данном кластере и доступ к его состояниям. Тот пользователь, которого мы будем применять для доступа к нашему кластеру имеет своим идентификатором rgw.ceph-rgw0. Его кольцо с ключами хранится в /var/lib/ceph/radosgw/ceph-<id>. Применяя всегда удобную команду pidof мы убеждаемся что данный процесс RGW на самом деле работает ожидаемым образом.

Теперь мы способны осуществлять доступ к своему кластеру, давайте настроим наш экземпляр RGW на включение протокола S3 для доступа. Для этого нам понадобится выполнить следующие этапы:

Тот процесс RGW, который по умолчанию исполняется на виртуальной машине rgw0, по умолчанию считывает /etc/ceph/ceph.conf для установок настроек во время своего запуска, как это делают и прочие демоны Ceph. Нам необходимо обновить параметры настройки в этом файле чтобы персонализировать необходимые установки RGW для своего варианта применения. Важно отметить, что все значения тех параметров настройки, которые мы выбираем, будут применимы только к нашей среде песочницы и могут отличаться каким- то образом от тех, что требуются для промышленных сред.

Вначале откроем указанный файл настроек /etc/ceph/ceph.conf в вашем любимом текстовом редакторе и перейдём в раздел, начинающийся с [client.rgw.ceph-rgw0]. Перед своим изменением он должен выглядеть примерно так:

...
[client.rgw.ceph-rgw0]
host = ceph-rgw0
keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-rgw0/keyring
rgw socket path = /tmp/radosgw-ceph-rgw0.sock
log file = /var/log/ceph/ceph-rgw-ceph-rgw0.log
rgw data = /var/lib/ceph/radosgw/ceph-rgw.ceph-rgw0
rgw frontends = civetweb port=10.0.2.15:8080 num_threads=50
rgw resolve cname = False
 	   

Нам необходимо выполнить три изменения в данном разделе:

Теперь изменим вышеупомянутый раздел чтобы он выглядел примерно так:

...
[client.rgw.ceph-rgw0]
host = ceph-rgw0
keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-rgw0/keyring
rgw socket path = /tmp/radosgw-ceph-rgw0.sock
log file = /var/log/ceph/ceph-rgw-ceph-rgw0.log
rgw data = /var/lib/ceph/radosgw/ceph-rgw.ceph-rgw0
rgw frontends = civetweb port=80 num_threads=50
rgw dns name = ceph-rgw.objectstorage.example.com
 	   

Как вы можете видеть, мы изменили только строку со значением поля порта, заменив host:port на пару port=80. Остальные строки остались нетронутыми.

Для целей демонстрации мы выбрали имеющееся имя DNS rgw frontends для своего кластера. Можете заменить это название на что- либо ещё, что вы найдёте более подходящим и соответствующим именно вашей настройке, в особенности, если вы выполняете оснащение не в среде песочницы. Если вы не применяете данную настройку для промышленного применения, вы можете оставить это значение как есть.

Когда данные изменения выполнены, сохраните этот файл и перезапустите свой демон radosgw. Это необходимо для того, чтобы данный демон подцепил наши изменения, так как он считывает ceph.conf только при запуске. Данный демон RGW (radosgw) имеет небольшой вес и процесс в основном без изменения состояний, поэтому его перезапуск не является проблематичным, в особенности если он в данный момент не обслуживает обмен:

root@ceph-rgw0:~# systemctl restart ceph-radosgw@rgw.ceph-rgw0.service
root@ceph-rgw0:~# pidof radosgw
14119
		

После перезапуска мы всегда убеждаемся, что данный процесс на самом деле запустил своё исполнение вновь, применяя pidof для отображения текущего идентификатора процесса. Может так случиться, что данный процесс radosgw не сможет запуститься надлежащим образом. В этом случае проверьте дважды ceph.conf чтобы убедиться, что он не содержит ошибок. Неверный ceph.conf может препятствовать корректному запуску radosgw. Нам необходимо создать некоего пользователя, со своим собственным набором полномочий S3, которые содержат ключ доступа S3 и пару ключа секрета. Некий пользователь может иметь дополнительную пару ключа секрета доступа, если это необходимо, но мы начнём с одной. Мы будем осуществлять доступ к Хранилищу Объектов таким образом, как если бы оно располагалось в некоторой удалённой машине, применяя какое- то имя DNS, даже не смотря на то, что в контексте данной главы оно расположено в той же самой системе. Эмуляция удалённого доступа к DNS должно быть очевидной идеей для того, чтобы получить представление как работает доступ RGW в установке, аналогичной промышленной.

Создание пользователя является административной задачей, для которой мы не можем применять какие- либо инструменты из уже применявшихся. Мы воспользуемся новым инструментарием с названием radosgw-admin, который разработан для выполнения всех административных задач в нашем кластере. Этот инструмент является предварительно установленным в вашей виртуальной машине rgw0. Выполните следующую команду radosgw-admin чтобы ознакомиться с теми типами операций, которые вы можете осуществлять в системе хранения объектов Ceph:

$ radosgw-admin help
		

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

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

root@ceph-rgw0:~# export CEPH_ARGS='--keyring /var/lib/ceph/radosgw/ceph-rgw.ceph-rgw0/keyring --id rgw.ceph-rgw0'
		

Теперь мы запускаем процесс создания своего пользователя с помощью подкоманды user create subcommand в radosgw-admin:

root@ceph-rgw0:~# radosgw-admin user create --uid=harshita --display-name='Harshita Bhembre'
{
    "user_id": "harshita",
    "display_name": "Harshita Bhembre",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [],
    "keys": [

      {
            "user": "harshita",
            "access_key": "C24PQKGQ015O4JAFQE5L",
            "secret_key": "LCyKZPr7rHqtxqD586d6YlZs38lzyIwNpql6IRN9"
      }
    ],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
    "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
    "temp_url_keys": []
}
		

Теми двымя параметрами командной строки, которые нам необходимо предоставить являются uid и display-name. Мы можем передать прочие значения, включая eьфшд или max-buckets, однако в этом нет необходимости. Получаемым выводом данной подкоманды user create являются все имеющиеся данные об этом пользователе, которые сохранил Ceph. Они представляются в надёжном структурированном формате JSON, который достаточно легко проанализировать человеку с помощью инструмента командной строки JSON или с применением приложений через клиентскую библиотеку JSON. Когда пользователь создан, мы можем применять имеющиеся полномочия S3 этого пользователя для доступа к хранилищу объектов RGW. Текущие полномочия выделяются из того раздела объекта пользователя, который имеет название keys. Мы изучим как применять такие инструменты как s3cmd в своём следующем разделе. До тех пор, будьте добры, припрячьте копию раздела своих ключей, или, по крайней мере, access_key и secret_key.

Прежде чем мы выполним действия S3 со своим кластером, мы далее убедимся что то имя DNS, которое у нас имеется выбранным для нашего кластера разрешимо нашим клиентом S3 и указывает на наш экземпляр RGW. Обычным способом для этого является покупка имени домена для вашей службы у регистрирующей организации, привлекательного поставщика услуг VPS (Virtual Private Server, Виртуального частного сервера), например, у DigitalOcean, для предоставления какого- то сервера с целью размещения вашей службы, с последующей привязкой имеющегося имени домена к текущему местоположению данного сервера. Однако, поскольку мы оснащаем свою службу в локальной виртуальной машине, у нас нет необходимости беспокоиться о покупке домена, мы можем просто запустить его и применять локально.

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

Чтобы пояснить это более ясно, давайте допустим, что мы осуществляем доступ к некоторой терминальной точке S3 с названием ceph-rgw.objectstorage.example.com. Предположим, мы применяем HTTP (а не HTTPS), тогда URL будет выглядеть так:

http://ceph-rgw.objectstorage.example.com/
 	   

Для доступа к сегменту childhood-videos через приведённую выше конечную точку мы строим URL на основе пути следующим образом:

http://ceph-rgw.objectstorage.example.com/childhood-videos/
 	   

Однако, если мы пожелаем осуществить доступ к тому же самому сегменту с применением URL S3 на основании домена, это будет выглядеть несколько иначе:

http://childhood-videos.ceph-rgw.objectstorage.example.com/
 	   

Таким образом, запись A (или AAAA, если вы применяете IPv6), которую мы добавляем в свой сервер DNS, должна содержать не только зпись для первоначального имени домена, но также и для префикса с групповым символом. Эти две записи должны выглядеть примерно так, применяя адрес локальной закольцовки:

ceph-rgw.objectstorage.example.com              A              127.0.0.1
*.ceph-rgw.objectstorage.example.com            A              127.0.0.1
 	   

К счастью, нам не нужно добавлять в точности эти записи в удалённый сервер DNS, а вместо этого искусный локальный распознаватель (resolver) обслуживает это для нас за сценой. Мы применяем некий сервер с названием dnsmasq, который может быть просто установлен в нашей виртуальной машине RGW. Давайте установим и настроим его чтобы разрешить нам взаимодействие с нашим экземпляром RGW при помощи пользовательского имени DNS:

root@ceph-rgw0:~# apt-get install -y dnsmasq
		

Теперь откройте его файл настроек, расположенный в /etc/dnsmasq.conf и измените ту закомментированную строку, которая указывает на localhost. Изменит самую последнюю строку в приведённом выше разделе с тем, чтобы этот домен стал ceph-rgw.objectstorage.example.com, но всё ещё указывал на localhost:

# Add domains which you want to force to an IP address here.
# The example below send any host in ceph-rgw.objectstorage.example.com to a local
# web-server.
address=/.ceph-rgw.objectstorage.example.com/127.0.0.1
 	   

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

root@ceph-rgw0:~# systemctl restart dnsmasq.service
		

Теперь мы должны иметь возможность общаться со своим экземпляром RGW с применением имени домена, которое мы определили. Убедимся, что такой доступ работает как ожидалось, испробовав следующую команду:

root@ceph-rgw0:~# nslookup ceph-rgw.objectstorage.example.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: ceph-rgw.objectstorage.example.com
Address: 127.0.0.1
root@ceph-rgw0:~# nc -vz ceph-rgw.objectstorage.example.com 80
Connection to ceph-rgw.objectstorage.example.com 80 port [tcp/http] succeeded!
		

Вывод этой команды показывает, что взаимодействие с необходимым портом нашего хоста успешно. Если приведённая выше команда завершится неудачей по какой- либо причине, убедитесь, пожалуйста, что вы вы выполнили все предыдущие шаги с самого начала данной главы и именно в том порядке, как они представлены.

Поздравляем! У вас теперь имеется сервер RGW поднятый и рабочий, а также готовый отвечать за все возможные операции хранения объектов.

Теперь мы применим свой рабочий кластер Ceph вместе с имеющимся экземпляром RGW, который мы установили для осуществления различных видов опреаций хранения объектов. Мы пройдём по настройке своего клиента открытого исходного кода утилитой s3cmd чтобы получить представление о том, как взаимодействовать со своим кластером. Та настройка, которую мы выполнили для включения утилит или SDK S3 с тем, чтобы общаться с Ceph, также перемещается на клиентов и иструменты.

Вначале мы установим инструмент s3cmd на свой экземпляр виртуальной машины rgw0:

root@ceph-rgw0:~# apt-get install -y s3cmd
		

Теперь давайте настроим эту утилиту s3cmd. Данный инструмент командной строки предоставляет прекрасный небольшой мастер, который проводит нас по настройке, устанавливая все необходимые параметры конфигурации. После того как мы выполним эти начальные установки, имеются некие дополнительные изменения, которые нам следует выполнить. Мы применим переключатель --configure чтобы вызвать такой процесс настройки.

root@ceph-rgw0:~# s3cmd --configure
		

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

Убедитесь, что вы избежали тестирования конфигурации прежде чем не завершите дополнительную настройку. По завершению данного процесса у вас будет иметься файл с названием .s3cfg в вашем домашнем каталоге. Давайте откроем его в предпочитаемом вами тесктовом редакторе и перейдём к следующим строкам:

host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
...
 	   

Установленный по умолчанию терминальный пункт host_ определяет службу S3 Amazon. Нам необходимо отрегулировать его, чтобы он теперь указывал на наш локальный экземпляр. Вызов нашего локального экземпляра может осуществляться через имя DNS ceph-rgw.objectstorage.example.com, которое мы настроили для обслуживания в своём dnsmasq. Давайте изменим эти два поля, чтобы они отражали наш индивидуальный домен:

host_base = ceph-rgw.objectstorage.example.com
host_bucket = %(bucket)s.ceph-rgw.objectstorage.example.com
...
 	   

Для строки host_bucket мы оставляем как есть префикс %(bucket)s. Теперь мы сохраняем этот файл и выходим из своего редактора. Теперь мы установили хранилище объектов для отправки запросов к Ceph.

Давайте начнём создание какого- то первого сегмента (busket) в своём только что созданном кластере хранения объектов:

root@ceph-rgw0:~# s3cmd mb s3://first-bucket
Bucket 's3://first-bucket/' created
root@ceph-rgw0:~# s3cmd ls
2017-08-20 20:34 s3://first-bucket
		

Корзины (сегменты) являются простой забавой без сохранения реальных файлов в них. Чтобы поиграть с файлами, давайте создадим некий образец файла и затем поместим его в свой новый сегмент, который мы только что создали:

root@ceph-rgw0:~# echo "RGW works!" > new-file.txt
root@ceph-rgw0:~# s3cmd put new-file.txt s3://first-bucket
upload:'new-file.txt'->'s3://first-bucket/new-file.txt'[1 of 1]
11 of 11    100% in   1s     7.66 B/s done
		

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

root@ceph-rgw0:~# rm new-file.txt
root@ceph-rgw0:~# s3cmd get s3://first-bucket/new-file.txt new-file.txt
download:'s3://first-bucket/new-file.txt'->'new-file.txt'[1 of 1]
 11 of 11   100% in    0s   280.71 B/s done
root@ceph-rgw0:~# cat new-file.txt
RGW works!
		

Это прекрасно! Поздравляем с завершением всей той работы, которая необходима для создания нового экземпляра RGW и хранилища объектов S3! Теперь у вас имеется великолепная новая служба хранения объектов, готовая сохранять все ваши файлы долговечно и надёжно.

RGW Ceph также предлагает некий API RESTful, который совместим со Swift OpenStack. Однако, в отличие от S3, нам необходимо создать какого- то отдельного пользователя для Swift. В номенклатуре Ceph таким пользователем является некий subuser. Этот новый subuser, которого мы создаём для своего первоначального пользователя RGW, предоставит нам доступ к тем же самым объектам и сегментам, которые мы создали для S3, однако с применением интерфейса Swift.

Создание необходимого subuser мы выполним из самой имеющейся виртуальной машины RGW, с того же самого узла, который мы применяли для исполнения приведённых выше команд. Мы применим уже знакомую нам утилиту radosgw-admin для создания некоего subuser чтобы от его имени выполнять вызовы API Swift:

root@ceph-rgw0:~# radosgw-admin subuser create --uid=harshita --subuser=harshita:swift --key-type=swift
{
    "user_id": "harshita",
    "display_name": "Harshita Bhembre",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [
        {
            "id": "harshita:swift",
            "permissions": ""
        }
    ],
    "keys": [
        { 
            "user": "harshita",
            "access_key": "C24PQKGQD15O4JAFQE5L",
            "secret_key": "LCyKZPr7rHCtxqD586d6YlZs38lzyIwNpql6IRN9"
        }
    ],
    "swift_keys": [
        {
            "user": "harshita:swift",
            "secret_key": "m38OvpnOMf8ILNZyfDuKTDTWKC7YCEUH9v4Te64o"
        }
    ],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    },
    "user_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    },
    "temp_url_keys": []
}
		

Здесь мы видим два новых поля, swift_keys и subusers, которые были заполнены новой информацией. Мы применим этот ключ секрета из swift_keys для взаимодействия со своим кластером Ceph с применением интерфейса Swift.

Чтобы осуществлять обмен между Swift и Ceph, мы применим инструмент командной строки, аналогичный утилите s3cmd, применявшейся ри общении с Ceph через API S3. Для текущих целей демонстрации мы применим широко распространённой python-swiftclient, однако мы можем воспользоваться и любой иной имеющейся в интернете альтернативой. Давайте выгрузим и установим этого клиента Swift с тем, чтобы он был готов к применению:

root@ceph-rgw0:~# apt install python-pip
root@ceph-rgw0:~# pip install python-swiftclient
		

Теперь, когда у нас имеется установленным необходимый клиент Swift, давайте применим его для создания нового сегмента в своём объектном хранилище Ceph. Для ясности мы поименуем свой новый сегмент как example-bucket. После завершения создания сегмента, мы перечислим все сегменты своего пользователя, к которым он имеет доступ и убедимся, что все ранее созданные сегменты видны:

root@ceph-rgw0:~# swift -V 1.0 -A http://ceph-rgw.objectstorage.example.com/auth -U harshita:swift -K m38OvpnOMf8ILNZyfDuKTDTWKC7YCEUH9v4Te64o post example-bucket

root@ceph-rgw0:~# swift -V 1.0 -A http://ceph-rgw.objectstorage.example.com/auth -U harshita:swift -K m38OvpnOMf8ILNZyfDuKTDTWKC7YCEUH9v4Te64o list
example-bucket
first-bucket
		

Команды Swift строятся с применением следующего синтаксиса:

swift -V <version> -A <auth-url> -U <subuser> -K <secret-key> <calls>
		

Как мы можем заметить в приводимом выше примере, операция post для создания нового контейнера отработала ожидаемым образом, а также перечислила все имеющиеся сегмент нашего пользователя. Сегмент S3 отображён нам, поскольку он также является неким сегментом, которым владеет данный пользователь, и которому он имеет доступ. Напомним, что S3 и Swift являются двумя различными способами взаимодействия с одной и той же службой, а создаваемые нами сегменты совместимы с обоими.

Предоставление хранилища является наиболее важной операцией, которую администратор осуществляет в своих системах. В отличии от тяжеловесных традиционных систем хранения корпоративного уровня, у нас отсутствуют приобретение, управление, сопровождение и поддержка множества систем хранения для различных видов хранения. Ceph единообразно предоставляет объекты, блоки и файлы в виде абстракций хранения из единой универсальной основы. На данный момент мы узнали как настраивать и предоставлять блочные устройства RADOS, файловые системы CephFS, а также хранилище объектов Ceph. Хорошо известные абстракции блочных устройств и файловых систем существуют уже несколько десятилетий, однако хранение объектов относительно новы и набирают обороты благодаря популярности и гибкости услуг Amazon S3 и OpenStack Swift, которые Ceph предоставляет сразу после установки.