Ceph и подключение клиентов. Файловый доступ с помощью CephFS

Этой статьей я закрываю цикл, посвященный основам развертывания Ceph. Ранее мы рассмотрели, как развернуть Ceph, как предоставляется блочный доступ и объектный с помощью S3 протокола.

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

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

Мое лабораторное окружение построено на базе Ceph Reef (18). Кластер состоит из 6 узлов, 3 из которых отведены под служебные сервисы, такие как Ceph Monitor и Ceph Manager, а 3 оставшихся узла задействованы под Ceph OSD. Все системы, включая клиента, на базе Rocky Linux 9.

Приступим к настройке со стороны Ceph. Все процедуры я провожу с управляющего узла. В данном случае это ceph-mon-01.

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

Создать Ceph Pool. Один из которых используется для метаданных CephFS, а второй, для хранения данных;
Запустить службы Ceph MDS.

Начнем с первого пункта и создадим требуемые пулы:

[root@ceph-mon-01 ~]# ceph osd pool create cephfs_metadata
pool 'cephfs_metadata' created

[root@ceph-mon-01 ~]# ceph osd pool create cephfs_data
pool 'cephfs_data' created

Как обычно, по умолчанию пулы создаются с двумя дополнительными копиями каждого объекта:

[root@ceph-mon-01 ~]# ceph osd pool get cephfs_metadata size
size: 3
[root@ceph-mon-01 ~]# ceph osd pool get cephfs_metadata min_size
min_size: 2

[root@ceph-mon-01 ~]# ceph osd pool get cephfs_data size
size: 3
[root@ceph-mon-01 ~]# ceph osd pool get cephfs_data min_size
min_size: 2

Теперь попробуем запустить CephFS, с указанием двух ранее созданных пулов:

[root@ceph-mon-01 ~]# ceph fs new vmik_share cephfs_metadata cephfs_data
  Pool 'cephfs_data' (id '10') has pg autoscale mode 'on' but is not marked as bulk.
  Consider setting the flag by running
    # ceph osd pool set cephfs_data bulk true
  new fs with metadata pool 9 and data pool 10

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

Так же Ceph рекомендует отметить вновь созданный пул как bulk:

[root@ceph-mon-01 ~]# ceph osd pool set cephfs_data bulk true
set pool 10 bulk to true

Посмотрим список созданных файловых систем:

[root@ceph-mon-01 ~]# ceph fs ls
name: vmik_share, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Из вывода мы видим какой пул используется для метаданных, а также пул, в котором размещаются данные.

Обратим внимание на текущий статус кластера:

[root@ceph-mon-01 ~]# ceph -s
health: HEALTH_ERR
     1 filesystem is offline
     1 filesystem is online with fewer MDS than max_mds
services:
     mds: 0/0 daemons up

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

Запустим три службы, по одной на каждом из служебных узлов (ceph-mon):

[root@ceph-mon-01 ~]# ceph orch apply mds cephfs --placement="3 ceph-mon-01 ceph-mon-02 ceph-mon-03"
Scheduled mds.cephfs update...

Если вывести список служб в кластере, можно будет заметить новые – mds:

[root@ceph-mon-01 ~]# ceph orch ls
NAME                     PORTS                 RUNNING  REFRESHED  AGE  PLACEMENT
alertmanager             ?:9093,9094               1/1  0s ago     2w   count:1
ceph-exporter                                      8/8  7m ago     2w   *
crash                                              8/8  7m ago     2w   *
grafana                  ?:3000                    1/1  0s ago     2w   count:1
ingress.rgw.s3.vmik.lab  10.10.10.22:443,1967      4/4  6m ago     2d   ceph-rgw-01;ceph-rgw-02
mds.cephfs                                         3/3  1s ago     11s  ceph-mon-01;ceph-mon-02;ceph-mon-03;count:3
mgr                                                3/3  1s ago     2w   ceph-mon-01;ceph-mon-02;ceph-mon-03;count:3
mon                                                3/3  1s ago     2w   ceph-mon-01;ceph-mon-02;ceph-mon-03;count:3
node-exporter            ?:9100                    8/8  7m ago     2w   *
osd                                                  9  7m ago     -    <unmanaged>
prometheus               ?:9095                    1/1  0s ago     2w   count:1
rgw.s3.vmik.lab          ?:8080                    2/2  6m ago     2d   count-per-host:1;label:rgw

Теперь статус кластера не выдает каких-либо ошибок:

cluster:
    health: HEALTH_OK
services:
    mds: 1/1 daemons up, 2 standby

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

Удалим ранее созданную файловую систему:

[root@ceph-mon-01 ~]# ceph fs volume rm vmik_share --yes-i-really-mean-it
metadata pool: cephfs_metadata data pool: ['cephfs_data'] removed

Обратите внимание, что при удалении, так же удаляются пулы, которые были выделены под CephFS.

Все вышеописанные действия можно выполнить одной командой:

[root@ceph-mon-01 ~]# ceph fs volume create vmik_share

Что делает данная команда? – Она создает пулы, корневую файловую систему – Volume, а также автоматически запускает службы Ceph MDS. Удобно.

Пулы же создаются по названию файловой системы:

[root@ceph-mon-01 ~]# ceph fs volume create vmik_share
11 cephfs.vmik_share.meta
12 cephfs.vmik_share.data

Важно: если вы идете по статье сверху вниз, старые службы MDS удалены не были. При этом команда выше автоматически запустила еще две службы на доступных узлах. Здесь потребуется ручное вмешательство – одни службы остановить, а вторые перенести на другие узлы.

Немного терминологии, хотя, если честно, я сам ее немного не понимаю.

Volume – уровень абстракции над Ceph File System. Возможно, это будет ошибочная трактовка, но я бы описал данный уровень как файловый сервер, внутри которого размещается некоторое количество общих директорий. Или же как корневую директорию. Техническая возможность смонтировать ее с клиентской стороны так же имеется.

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

Subvolume groups – группа Subvolume, позволяющая накладывать различного рода политики.

Внутри Volume, мы можем создавать Subvolumes, и Subvolume groups. Если Volume – это дерево, то Subvolumes – это ветви дерева.

Для начала создадим Subvolume group под названием data:

[root@ceph-mon-01 ~]# ceph fs subvolumegroup create vmik_share data

В, принципе, можно и не создавать, но в таком случае, все Subvolume будут попадать в группу по-умолчанию _nogroup. И это будет не совсем красиво.

Теперь создадим два Subvolume, размером по 1Gb каждый:

[root@ceph-mon-01 ~]# ceph fs subvolume create vmik_share data1 --group_name data --size 1073741824

[root@ceph-mon-01 ~]# ceph fs subvolume create vmik_share data2 --group_name data --size 1073741824

Здесь мы указываем названием Volume, в котором хотим создать Subvolume, название группы, а также размер в байтах. Ну и название Subvolume, соответственно. В данном случае это data1 и data2.

Мы можем легко посмотреть список Subvolume относящихся к конкретной группе конкретного FS:

[root@ceph-mon-01 ~]# ceph fs subvolume ls vmik_share --group_name data
[
    {
        "name": "data2"
    },
    {
        "name": "data1"
    }
]

Теперь выдадим права доступа к двум нашим Subvolume. Для data1 пользователю vmik1, для data2 пользователю vmik2:

[root@ceph-mon-01 ~]# ceph fs subvolume authorize vmik_share --group_name data data1 vmik1 --access-level=rw

[root@ceph-mon-01 ~]# ceph fs subvolume authorize vmik_share --group_name data data2 vmik2 --access-level=rw

Обратите внимание, что создавать учетные записи предварительно не требуется. Команда автоматически создает учетные записи и выдает требуемый для доступа уровень прав:

[root@ceph-mon-01 ~]# ceph auth ls
client.vmik1
        key: AQDp0d5lO7xfLhAAWZ8bSFW1YB5heNgoVTaQAw==
        caps: [mds] allow rw path=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7
        caps: [mon] allow r
        caps: [osd] allow rw pool=cephfs.vmik_share.data
client.vmik2
        key: AQD20d5lDBwNCRAAj8HHVF/I8zAzdnkjWRYUlA==
        caps: [mds] allow rw path=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37
        caps: [mon] allow r
        caps: [osd] allow rw pool=cephfs.vmik_share.data

В выводе выше нас интересует название учетной записи, поле key, а также поле path.

Все это пригодится при дальнейшем монтировании файловой системы со стороны клиента.

Кстати, получить путь до «шары» можно командой ниже:

[root@ceph-mon-01 ~]# ceph fs subvolume getpath vmik_share data1 --group_name data
/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7

[root@ceph-mon-01 ~]# ceph fs subvolume getpath vmik_share data2 --group_name data
/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37

Итак, на текущий момент мы выполнили следующие действия:

Запустили CephFS;
Создали Volume – Subvolume Group – Subvolume;
Выдали соответствующие RW права на Subvolume;
Определились с данными, которые необходимо собрать и передать клиенту.

Переходим к клиенту. В данном случае мы будем использовать для подключения Kernel Driver, доступный во всех современных ядрах. Ceph-Fuse рассматриваться не будет.

Для начала со стороны клиента необходимо подключить репозитории Ceph:

[root@ceph-client-fs ~]# vi /etc/yum.repos.d/ceph.repo
[Ceph]
name=Ceph $basearch
baseurl=https://download.ceph.com/rpm-reef/el9/$basearch
enabled=1
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.gpg

[Ceph-noarch]
name=Ceph noarch
baseurl=https://download.ceph.com/rpm-reef/el9/noarch
enabled=1
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.gpg

[Ceph-source]
name=Ceph SRPMS
baseurl=https://download.ceph.com/rpm-reef/el9/SRPMS
enabled=1
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.gpg

Подключить репозиторий Epel:

[root@ceph-client-fs ~]# dnf install epel-release

И установить пакет ceph-common:

[root@ceph-client-fs ~]# dnf install ceph-common

Создадим директории для монтирования:

[root@ceph-client-fs ~]# mkdir -p /vmik_data1 /vmik_data2

И смонтируем привычной командой mount:

[root@ceph-client-fs /]# mount -t ceph vmik1@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7 /vmik_data1/ -o mon_addr=ceph-mon-01:6789/ceph-mon-02:6789/ceph-mon-03:6789 -o secret=AQDp0d5lO7xfLhAAWZ8bSFW1YB5heNgoVTaQAw==

[root@ceph-client-fs /]# mount -t ceph vmik2@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37 /vmik_data2/ -o mon_addr=ceph-mon-01:6789/ceph-mon-02:6789/ceph-mon-03:6789 -o secret=AQD20d5lDBwNCRAAj8HHVF/I8zAzdnkjWRYUlA==

Выглядит очень пугающее. Попробую объяснить:

mount –t ceph – указываем, что монтируем файловую систему Ceph;
Далее мы указываем учетную запись, для которой выдавались права – vmik1 или vmik2;
Через @ мы указываем FSID кластера. Получить его можно из вывода команды ceph –s с управляющего узла;
После FSID кластера идет обязательный символ точки (.). За данным символом следует название файловой системы или же Volume;
Далее идет =, за которым указывается полный путь Subvolume. Как его получить было описано выше;
Следующим, мы указываем директорию, в которую будет смонтирована файловая система;
После ключа –o мы перечисляем адреса Ceph Monitor, разделенные символом /, а также значение secret для пользователя.

Вот такой действительно длинной командой можно смонтировать CephFS:

[root@ceph-client-fs /]# df -h
Filesystem                                                                                                      Size  Used Avail Use% Mounted on
vmik1@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7  1.0G     0  1.0G   0% /vmik_data1
vmik2@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37  1.0G     0  1.0G   0% /vmik_data2

Если попробовать смонтировать раздел под пользователем, у которого отсутствую права, можно получить следующую ошибку:

[root@ceph-client-fs /]# mount -t ceph vmik1@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37 /vmik_data2/ -o mon_addr=ceph-mon-01:6789/ceph-mon-02:6789/ceph-mon-03:6789 -o secret=AQD20d5lDBwNCRAAj8HHVF/I8zAzdnkjWRYUlA==
mount error: no mds server is up or the cluster is laggy

Если при работе с CephFS вы получаете подобную ошибку – проверьте права.

Упростим задачу и сократим размер команды. Для сокращения, на клиентской машине необходимо следующее:

Разместить на клиентской машине минимальный конфигурационный файл Ceph, в котором будут указаны адреса Ceph Monitor, а также FSID кластера;
Разместить на клиентской машине keyring файл пользователя, от имени которого выполняется подключение к файловому серверу.

Обычно, вышеуказанные данные должен передать администратор. Но в данном примере запросим данные самостоятельно.

Запросим через SSH конфигурационный файл кластера:

[root@ceph-client-fs /]# mkdir -p /etc/ceph
[root@ceph-client-fs /]# ssh root@ceph-mon-01 "ceph config generate-minimal-conf" | tee /etc/ceph/ceph.conf
# minimal ceph.conf for 24c20e62-c4da-11ee-ba95-005056aad62a
[global]
        fsid = 24c20e62-c4da-11ee-ba95-005056aad62a
        mon_host = [v2:10.10.10.13:3300/0,v1:10.10.10.13:6789/0] [v2:10.10.10.14:3300/0,v1:10.10.10.14:6789/0] [v2:10.10.10.15:3300/0,v1:10.10.10.15:6789/0]

А также keyring файлы для пользователей vmik1 и vmik2:

[root@ceph-client-fs /]# ssh root@ceph-mon-01 "ceph auth get-or-create client.vmik1" | tee /etc/ceph/ceph.client.vmik1.keyring
[client.vmik1]
        key = AQDp0d5lO7xfLhAAWZ8bSFW1YB5heNgoVTaQAw==

[root@ceph-client-fs /]# ssh root@ceph-mon-01 "ceph auth get-or-create client.vmik2" | tee /etc/ceph/ceph.client.vmik2.keyring
[client.vmik2]
        key = AQD20d5lDBwNCRAAj8HHVF/I8zAzdnkjWRYUlA==

Обратите внимание на название keyring файла. Формат желательно сохранить.

Теперь в директории /etc/ceph должны находиться файлы ceph.conf и два keyring файла:

[root@ceph-client-fs /]# ls /etc/ceph/
ceph.client.vmik1.keyring  ceph.client.vmik2.keyring  ceph.conf  rbdmap

Смонтируем файловые шары:

[root@ceph-client-fs /]# mount -t ceph vmik1@.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7 /vmik_data1/

[root@ceph-client-fs /]# mount -t ceph vmik2@.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37 /vmik_data2/

[root@ceph-client-fs /]# df -h
Filesystem                                                                                                      Size  Used Avail Use% Mounted on
vmik1@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7  1.0G     0  1.0G   0% /vmik_data1
vmik2@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37  1.0G     0  1.0G   0% /vmik_data2

Как можно заметить, формат команды достаточно сократился. Обратите внимание на данную конструкцию – vmik1@.

Ранее после точки мы указывали FSID кластера. Сейчас, когда у нас есть ceph.conf делать этого не нужно, однако, точка все еще должна сохраняться.

Пытливый читатель спросит? А можно ли автоматически подключаться после перезагрузки ОС? – Да, можно. Формат файла fstab следующий:

### CephFS FSTAB
vmik1@.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7 /vmik_data1/ ceph    _netdev 0 2
vmik2@.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37 /vmik_data2/ ceph    _netdev 0 2

Работает это, конечно, когда в системе есть файлы ceph.conf и keyring.

[root@ceph-client-fs /# reboot

[root@ceph-client-fs /]# df -h
Filesystem                                                                                                      Size  Used Avail Use% Mounted on
vmik2@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37  1.0G     0  1.0G   0% /vmik_data2
vmik1@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7  1.0G     0  1.0G   0% /vmik_data1

На этом про подключение клиента, в принципе, все.

Немного про права доступа.

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

[root@ceph-mon-01 ~]# ceph fs subvolume authorized_list vmik_share data2 --group_name data
[
    {
        "vmik2": "rw"
    }
]

Как забрать права?

[root@ceph-mon-01 ~]# ceph fs subvolume deauthorize vmik_share data2 --group_name data vmik2

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

Есть еще интересная команда – evict. Ограничивает все текущие действия пользователя:

[root@ceph-mon-01 ~]# ceph fs subvolume evict vmik_share data2 --group_name data vmik2

После выполнения данной команды пользователь не сможет выполнять дальнейшие действия в смонтированном ресурсе:

[root@ceph-client-fs /]# ls -la
ls: cannot access 'vmik_data2': Permission denied

Однако, он может его отмонтировать, смонтировать обратно и работать как раньше.

Немного про управление.

Изменять размер Subvolume мы можем в режиме онлайн:

[root@ceph-mon-01 ~]# ceph fs subvolume resize vmik_share data1 2073741824 --group_name data
[
    {
        "bytes_used": 0
    },
    {
        "bytes_quota": 2073741824
    },
    {
        "bytes_pcent": "0.00"
    }
]

Пользователь моментально увидит изменения:

vmik1@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data1/c4a84311-514d-4517-9e70-e3e9a1078df7  2.0G     0  2.0G   0% /vmik_data1

Можно также задать размер меньше, чем текущая утилизация, но зачем так делать?

[root@ceph-mon-01 ~]# ceph fs subvolume resize vmik_share data2 73741824 --group_name data
[
    {
        "bytes_used": 104857600
    },
    {
        "bytes_quota": 73741824
    },
    {
        "bytes_pcent": "142.20"
    }
]

vmik2@24c20e62-c4da-11ee-ba95-005056aad62a.vmik_share=/volumes/data/data2/988e03e8-4db8-4586-b47f-9547020e9d37   68M   68M     0 100% /vmik_data2

Чтобы избежать ситуации, при которой мы задаем размер меньше, чем текущая утилизация, можно указать опцию –no_shrink, которая предотвратит изменение размеров при необходимости:

[root@ceph-mon-01 ~]# ceph fs subvolume resize vmik_share data2 73741824 --group_name data --no_shrink
Error EINVAL: Can't resize the subvolume. The new size '73741824' would be lesser than the current used size '104857600'

Ну и в завершении удалим Subvolume:

[root@ceph-mon-01 ~]# ceph fs subvolume rm vmik_share data2 --group_name data

В качестве заключения:

До недавнего времени я не работал с CephFS ввиду отсутствия необходимости. Но статью по данной теме просили и в комментариях, и по почте, поэтому не осветить данный функционал Ceph я не мог.

CephFS действительно очень богат на функционал и то, что описано в статье даже не вершина айсберга. Как и было сказано в начале – остальное читайте в документации. Я, пожалуй, тоже почитаю.

Leave a Reply Cancel reply