Как запускать Ceph в 2022 году?

Последний раз мне довелось поработать с Ceph релиза Nautilus (14), несколько лет назад.
С тех пор изменились некоторые моменты в процедуре создания и управления распределенным хранилищем, а знания мои достаточно устарели.
В данной статье я планирую освежить их и начну с первичного запуска кластера Ceph на примере релиза Quincy (17).

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

Про сайзинг Ceph можно написать не одну статью, поэтому коротко про основные компоненты Monitor и OSD:

Процессор:

Monitor – не является активным потребителем процессорных ресурсов. Рекомендуется минимум 2 ядра.

Обязательно нужно учесть, что на хосте могут и, скорее всего, будут работать другие службы, например, Manager, которому так же потребуются процессорные ресурсы;

OSD – 1 процессорное ядро на одну службу BlueStore OSD. При интенсивных нагрузках может понадобиться и по 2 ядра. Одна служба OSD это, обычно, один диск, на котором размещаются данные. Если в сервере 12 дисков, скорее всего это будет 12 служб OSD.

Оперативная память:

Monitor – чем больше – тем лучше. В кластере средних размеров будет достаточно 64GB на сервер. В больших кластерах с количеством OSD больше 300 – 128GB;

OSD – от 4 до 8GB оперативной памяти на одну службу BlueStore  OSD, где 4GB приемлемый минимум.

Диски:

Здесь правила скорее общие.

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

Рекомендуется использовать диски объемом не ниже 1TB, учитывая при этом соотношение стоимости за гигабайт.

К выбору количества дисков на сервер и их размеру нужно так же подходить внимательно и учитывать домен отказа. Сервер с большим количеством дисков по 8TB может и будет стоить дешевле, но вот выход из строя такого сервера будет гораздо неприятнее, чем выход из строя сервера с меньшим количеством дисков и меньшим объемом.

Для увеличения производительности, желательно иметь некоторое количество установленных SSD в сервере и размещать на них WAL+DB.

Сеть:

Здесь рекомендация простая – минимум 10Gbps, больше – лучше. Быстрая сеть обеспечивает большую скорость доступа к данным, более быструю репликацию и восстановление.  Но нужно понимать, что 100Gbps серверу с 12 HDD может и не понадобиться. Думаю, особо объяснять не нужно.

Желательно рассмотреть вариант организации отдельной сети для клиентского доступа и отдельной сети для задач кластера.

Конфигурация кластера:

Первое с чем стоит определиться – количество служб Monitor. Основное правило – для формирования кворума необходима доступность более 50% служб. Поэтому делать их общее количество четным не имеет смысла.

Например, имеется два кластера – в одном 5 мониторов, в другом 6. При потере двух, в первом остается 3 монитора (>50%), во втором остается 4 монитора (>50%). При потере третьего монитора в первом кластере общее количество уже <50% (5-3=2), в то время, как во втором кластере оно =50% от изначального (6-3=3).

Поскольку для формирования кворума требуется более 50% доступных служб, не будет работать ни первый ни второй кластер, при этом второму кластеру выделено больше ресурсов.

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

Теперь про OSD.

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

Таким образом мы плавно приходим к тому, какой Replication Factor следует использовать (иначе – pool size). Replication Factor – количество копий наших данных в кластере, а точнее в пуле. В зависимости от настроек, Ceph следит за размещением дополнительных копий данных. Они могут быть разнесены как между серверами, так, например, и между стойками в ЦОД.

RF-1 – одна копия данных. Вышел из строя любой диск или сервер в кластере – данные безвозвратно утеряны;

RF-2 – две копии данных, соответственно. Вышел из строя сервер, вторая копия данных имеется на другом сервере. Данные сохранены и доступны пользователям, начинается процесс создания второй копии других серверах;

RF-3 – три копии данных в трех разных местах.

Что выбрать? RF-1 рассматривать не будем вообще, потому что мы ценим свои данные.

При использовании RF-2 и RF-3, или еще больше, нужно понимать, что 100GB данных в первом случае в кластере займут 200GB, во втором – 300GB (Да, можно использовать Erasure Coding, но сейчас не про это).

Многих неподготовленных часто повергает в шок объем потребляемого пространства для вторых и третьих копий. «Мы купили три сервера по 50TB каждый, почему мы можем загрузить на них только 50TB данных?».

Затем говорят – «давайте использовать RF-2, поскольку место жалко». Потом из строя выходит один сервер, в процессе репликации почему-то умерло еще два диска на других серверах, данные подпорчены.

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

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

Настало время заняться установкой.

Скажу прямо – данную часть я писал два раза, поскольку первый раз пытался запустить кластер по старинке, но во второй раз, разобравшись с новым функционалом, который предоставляет cephadm, получилось лучше 🙂

Мой стенд:

У меня в тесте участвует 6 виртуальных машин под управлением Rocky Linux 8.6 в минимальной версии. 3 машины я планирую задействовать под системные службы Monitor и Manager, а вторую половину под OSD. К машинам с OSD добавлено по 3 дополнительных диска объемом по 100GB каждый.

На всех хостах выполнено обновление ОС и пакетов до актуальных версий, настроена и работает синхронизация времени через Chrony. Для доступа в интернет прописан прокси сервер в /etc/environments с соответствующими исключениями.

Для всех хостов созданы записи в DNS, все машины взаимодействуют как по короткому имени, так и по FQDN. При этом в hostname используется короткое имя, а не FQDN (это важно).

Первым шагом устанавливаем на всех серверах Python3 и Docker, либо Podman, поскольку службы Ceph теперь запускаются в контейнерах.

Учитывая, что Rocky Linux растет от Red Hat Enterprise Linux, Podman в моем случае будет предпочтительнее, к тому же он доступен в штатных репозиториях.

Выполняем процедуру установки на всех машинах, которые планируется использовать в Ceph:

[root@ceph-node1/2/3/4/5/6 ~]# dnf install python39
[root@ceph-node1/2/3/4/5/6 ~]# python3 --version
Python 3.9.7

[root@ceph-node1/2/3/4/5/6 ~]# dnf install podman
[root@ceph-node1/2/3/4/5/6 ~]# podman -v
podman version 4.0.2

Все дальнейшие операции выполняются с первой машины. В моем случае это ceph-mon-01.

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

[root@ceph-mon-01 ceph]# curl --silent --remote-name --location https://github.com/ceph/ceph/raw/quincy/src/cephadm/cephadm
[root@ceph-mon-01 ceph]# chmod +x cephadm
[root@ceph-mon-01 ceph]# ./cephadm add-repo --release quincy
Writing repo to /etc/yum.repos.d/ceph.repo...
Enabling EPEL...
Completed adding repo.
[root@ceph-mon-01 ceph]# ./cephadm install
Installing packages ['cephadm']...

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

Начнем процедуру создания кластера с помощью cephadm bootstrap. Данная команда запускает ряд сервисов на указанной в параметре ноде, включая первый Monitor, создает кластер, генерирует ключи, конфигурационный файл и многое другое.

Процедуру я выполняю с первой ноды. В качестве параметра mon-ip указываю ее адрес:

[root@ceph-mon-01 ~]# cephadm bootstrap --mon-ip 10.10.11.13

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

Verifying podman|docker is present...
Verifying lvm2 is present...
Verifying time synchronization is in place...
Unit chronyd.service is enabled and running
Repeating the final host check...
podman (/usr/bin/podman) version 4.0.2 is present
systemctl is present
lvcreate is present
Unit chronyd.service is enabled and running
Host looks OK

Создает кластер:

Cluster fsid: 2178c624-0901-11ed-ba0a-005056a97edd

Жалуется, что я не указал cluter_network – сеть, которую используют OSD для репликации:

Internal network (--cluster-network) has not been provided, OSD replication will default to the public_network

В продуктивной среде хорошей практикой будет использование отдельной сети для процедуры репликации данных между OSD.

[root@ceph-mon-01 ~]# cephadm bootstrap --mon-ip 10.10.11.13 --cluster-network 192.168.1.0/24

Затем cehpadm добавляет в конфигурацию новый хост и запускает на нем ряд сервисов:

Adding host ceph-mon-01...
Deploying mon service with default placement...
Deploying mgr service with default placement...
Deploying crash service with default placement...
Deploying prometheus service with default placement...
Deploying grafana service with default placement...
Deploying node-exporter service with default placement...
Deploying alertmanager service with default placement...
Enabling the dashboard module...

В заключении мы получаем доступ в Ceph Dashboard:

Ceph Dashboard is now available at:

            URL: https://ceph-mon-01:8443/
            User: admin
            Password: 2sd2nk9asdsad

Посмотрим на список запущенных контейнеров на первом хосте:

[root@ceph-mon-01 ~]# podman ps
CONTAINER ID  IMAGE                                                                                      COMMAND               CREATED         STATUS             PORTS       NAMES
82270951dfc8  quay.io/ceph/ceph:v17                                                                      -n mgr.ceph-mon-0...  12 minutes ago  Up 12 minutes ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-mgr-ceph-mon-01-khfosw
8bc3f08c8b38  quay.io/ceph/ceph@sha256:b4e95ad6b1a4fb02b3d5c3fc8cbdb91431d03fdf5c6d904f8a5cf1efb4053f27  -n client.crash.c...  11 minutes ago  Up 11 minutes ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-crash-ceph-mon-01
b022602ab737  quay.io/prometheus/node-exporter:v1.3.1                                                    --no-collector.ti...  11 minutes ago  Up 11 minutes ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-node-exporter-ceph-mon-01
2b9102d79329  quay.io/ceph/ceph-grafana:8.3.5                                                            /bin/bash             10 minutes ago  Up 10 minutes ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-grafana-ceph-mon-01
1d89b90b1274  quay.io/prometheus/alertmanager:v0.23.0                                                    --cluster.listen-...  4 minutes ago   Up 4 minutes ago               ceph-2178c624-0901-11ed-ba0a-005056a97edd-alertmanager-ceph-mon-01
18cd469af50f  quay.io/prometheus/prometheus:v2.33.4                                                      --config.file=/et...  4 minutes ago   Up 4 minutes ago               ceph-2178c624-0901-11ed-ba0a-005056a97edd-prometheus-ceph-mon-01
bd12dfd8dd37  quay.io/ceph/ceph:v17                                                                      -n mon.ceph-mon-0...  17 seconds ago  Up 18 seconds ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-mon-ceph-mon-01

Один сервис – один контейнер.

Для того, чтобы посмотреть статус кластера и продолжить его настройку, установим дополнительный пакет ceph-common:

[root@ceph-mon-01 ~]# cephadm install ceph-common
[root@ceph-mon-01 ~]# ceph -s
  cluster:
    id:     2178c624-0901-11ed-ba0a-005056a97edd
    health: HEALTH_WARN
            OSD count 0 < osd_pool_default_size 3

  services:
    mon: 1 daemons, quorum ceph-mon-01 (age 2m)
    mgr: ceph-mon-01.khfosw(active, since 36s)
    osd: 0 osds: 0 up, 0 in

  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   0 B used, 0 B / 0 B avail
    pgs:

Примитивный кластер. Один монитор, ноль OSD.

Теперь начинаются отличия в процессе установки по сравнению с устаревшим ceph-deploy.

Поскольку управлять кластером я планирую с первой ноды, на пяти остальных разместим сертификат для доступа к ним по SSH. Сертификат был ранее сгенерирован автоматически с помощью cephadm и размещен в /etc/ceph.

Копирую его на все 5 нод:

[root@ceph-mon-01 ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mon-02
[root@ceph-mon-01 ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mon-03
[root@ceph-mon-01 ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd-01
[root@ceph-mon-01 ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd-02
[root@ceph-mon-01 ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd-03

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

[root@ceph-mon-01 ~]# ceph orch host add ceph-mon-02
Added host 'ceph-mon-02' with addr '10.10.11.14'
[root@ceph-mon-01 ~]# ceph orch host add ceph-mon-03
Added host 'ceph-mon-03' with addr '10.10.11.15'
[root@ceph-mon-01 ~]# ceph orch host add ceph-osd-01
Added host 'ceph-osd-01' with addr '10.10.11.16'
[root@ceph-mon-01 ~]# ceph orch host add ceph-osd-02
Added host 'ceph-osd-02' with addr '10.10.11.17'
[root@ceph-mon-01 ~]# ceph orch host add ceph-osd-03
Added host 'ceph-osd-03' with addr '10.10.11.18'

Посмотреть список всех добавленных хостов можно с помощью ceph orch host ls:

[root@ceph-mon-01 ~]# ceph orch host ls
HOST         ADDR         LABELS  STATUS
ceph-mon-01  10.10.11.13  _admin
ceph-mon-02  10.10.11.14
ceph-mon-03  10.10.11.15
ceph-osd-01  10.10.11.16
ceph-osd-02  10.10.11.17
ceph-osd-03  10.10.11.18
6 hosts in cluster

Теперь не торопимся.

Проверим статус кластера:

[root@ceph-mon-01 ~]# ceph -s
  cluster:
    id:     2178c624-0901-11ed-ba0a-005056a97edd
    health: HEALTH_WARN
            OSD count 0 < osd_pool_default_size 3

  services:
    mon: 2 daemons, quorum ceph-mon-01,ceph-mon-02 (age 108s)
    mgr: ceph-mon-01.khfosw(active, since 5m), standbys: ceph-mon-02.cfeaei
    osd: 0 osds: 0 up, 0 in

  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   0 B used, 0 B / 0 B avail
    pgs:

  progress:
    Updating mon deployment (+3 -> 5) (0s)
      [............................]

Можно заметить, что у нас уже 2 монитора. К тому же интересная запись:

Updating mon deployment (+3 -> 5) (0s)

Проверим статус через минуту:

[root@ceph-mon-01 ~]# ceph -s
  cluster:
    id:     2178c624-0901-11ed-ba0a-005056a97edd
    health: HEALTH_WARN
            OSD count 0 < osd_pool_default_size 3

  services:
    mon: 5 daemons, quorum ceph-mon-01,ceph-mon-02,ceph-mon-03,ceph-osd-01,ceph-osd-02 (age 99s)
    mgr: ceph-mon-01.khfosw(active, since 7m), standbys: ceph-mon-02.cfeaei,
    osd: 0 osds: 0 up, 0 in

  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   0 B used, 0 B / 0 B avail
    pgs:

У нас 5 активных служб Monitor и 2 активные службы Mgr. Но почему? Мы ведь не просили их запускать.

Однако, в моем небольшом кластере требуется всего 3 монитора, поэтому меняю изначальные значения и указываю хосты, где они должны быть запущены:

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

Теперь результат соответствует изначальным требованиям:

  services:
    mon: 3 daemons, quorum ceph-mon-01,ceph-mon-02,ceph-mon-03 (age 5s)
    mgr: ceph-mon-01.khfosw(active, since 10m), standbys: ceph-mon-02.cfeaei
    osd: 0 osds: 0 up, 0 in

Запустим службы OSD.

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

Указываем хосты, затем перечисляем через запятую список дисков, которые будут использованы службами OSD:

[root@ceph-mon-01 ~]# ceph orch daemon add osd ceph-osd-01:/dev/sdb,/dev/sdc,/dev/sdd
Created osd(s) 0,1,2 on host 'ceph-osd-01'
[root@ceph-mon-01 ~]# ceph orch daemon add osd ceph-osd-02:/dev/sdb,/dev/sdc,/dev/sdd
Created osd(s) 3,4,5 on host 'ceph-osd-02'
[root@ceph-mon-01 ~]# ceph orch daemon add osd ceph-osd-03:/dev/sdb,/dev/sdc,/dev/sdd
Created osd(s) 6,7,8 on host 'ceph-osd-03'

Это самый простой вариант для моего лабораторного окружения. В продуктивной среде, где рекомендуется выносить DB и WAL (Write-ahead log) на SSD, может пригодиться следующая команда:

ceph orch daemon add osd host:data_devices=/dev/sdb,/dev/sdc,db_devices=/dev/sdd,osds_per_device=2

Где data_devices – sdb и sdc – жесткие диски, а db_devices – sdd – твердотельный.

Проверим состояние добавленных OSD:

[root@ceph-mon-01 ~]# ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME             STATUS  REWEIGHT  PRI-AFF
-1         0.87918  root default
-3         0.29306      host ceph-osd-01
 0    hdd  0.09769          osd.0             up   1.00000  1.00000
 1    hdd  0.09769          osd.1             up   1.00000  1.00000
 2    hdd  0.09769          osd.2             up   1.00000  1.00000
-5         0.29306      host ceph-osd-02
 3    hdd  0.09769          osd.3             up   1.00000  1.00000
 4    hdd  0.09769          osd.4             up   1.00000  1.00000
 5    hdd  0.09769          osd.5             up   1.00000  1.00000
-7         0.29306      host ceph-osd-03
 6    hdd  0.09769          osd.6             up   1.00000  1.00000
 7    hdd  0.09769          osd.7             up   1.00000  1.00000
 8    hdd  0.09769          osd.8             up   1.00000  1.00000

Три хоста, на каждом из которых работает по три службы Ceph OSD.

Лирическое отступление: WEIGHT определяет приоритет размещения данных в кластере. Диски с большим значением будут иметь больший приоритет для записи, соответственно и будут заполняться быстрее. При добавлении OSD, значение WEIGHT выставляется автоматически и соответствует размеру диска. Диск размером в 1TB будет иметь значение WEIGHT = 1.

Вес хоста = суммарный вес OSD, относящихся к данному хосту. Соответственно, при равных весах, заполнение узлов и дисков в кластере должно быть равномерным.

Стоит упомянуть, что вес всегда можно изменить при особой необходимости.

Взглянем на список запущенных контейнеров на хосте с OSD:

[root@ceph-osd-03 ~]# podman ps
CONTAINER ID  IMAGE                                                                                      COMMAND               CREATED         STATUS             PORTS       NAMES
c2c6670eca1d  quay.io/ceph/ceph@sha256:b4e95ad6b1a4fb02b3d5c3fc8cbdb91431d03fdf5c6d904f8a5cf1efb4053f27  -n client.crash.c...  9 minutes ago   Up 9 minutes ago               ceph-2178c624-0901-11ed-ba0a-005056a97edd-crash-ceph-osd-03
170ae3e83a8d  quay.io/prometheus/node-exporter:v1.3.1                                                    --no-collector.ti...  8 minutes ago   Up 8 minutes ago               ceph-2178c624-0901-11ed-ba0a-005056a97edd-node-exporter-ceph-osd-03
621e6391bccc  quay.io/ceph/ceph@sha256:b4e95ad6b1a4fb02b3d5c3fc8cbdb91431d03fdf5c6d904f8a5cf1efb4053f27  -n osd.6 -f --set...  50 seconds ago  Up 51 seconds ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-osd-6
1518b7c2a14d  quay.io/ceph/ceph@sha256:b4e95ad6b1a4fb02b3d5c3fc8cbdb91431d03fdf5c6d904f8a5cf1efb4053f27  -n osd.7 -f --set...  44 seconds ago  Up 44 seconds ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-osd-7
ea1dc5ea5ddf  quay.io/ceph/ceph@sha256:b4e95ad6b1a4fb02b3d5c3fc8cbdb91431d03fdf5c6d904f8a5cf1efb4053f27  -n osd.8 -f --set...  35 seconds ago  Up 36 seconds ago              ceph-2178c624-0901-11ed-ba0a-005056a97edd-osd-8

Ожидаемо, каждая служба OSD запущена в отдельном контейнере.

После добавления OSD я встретил один баг и предупреждение:

[root@ceph-mon-01 ~]# ceph -s
  cluster:
    id:     2178c624-0901-11ed-ba0a-005056a97edd
    health: HEALTH_WARN
            1 stray daemon(s) not managed by cephadm

Лечится просто, перезагружаем активную службу ceph-mgr. В моем случае на 1 ноде:

[root@ceph-mon-01 ~]# ceph orch daemon restart mgr.ceph-mon-01.khfosw

Проверим статус кластера:

[root@ceph-mon-01 ~]# ceph -s
  cluster:
    id:     2178c624-0901-11ed-ba0a-005056a97edd
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum ceph-mon-01,ceph-mon-02,ceph-mon-03 (age 53m)
    mgr: ceph-mon-02.cfeaei(active, since 48m), standbys: ceph-mon-01.khfosw
    osd: 9 osds: 9 up (since 50m), 9 in (since 50m)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   185 MiB used, 900 GiB / 900 GiB avail
    pgs:     1 active+clean

Настройка завершена. Как и требовалось – в нашем кластере работает 3 службы Ceph Monitor, 2 службы Ceph Manager, имеется 9 OSD, суммарным объемом в 900GB и доступен Ceph Dashboard.

Вот, собственно, и все. Запустить небольшой кластер Ceph не является сложной задачей. И, как оказалось, сейчас это сделать значительно проще.

Можно начинать выдавать дисковые ресурсы клиентам.

Осталось определиться с протоколами, по которым планируется выделение дисковых ресурсов:

Но об этом в другой раз.