Как запускать 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.

Указать данную сеть можно на этапе создания кластера ключом –cluster-network, но предварительно необходимо настроить сетевые интерфейсы на хостах для работы в данной сети.

Например:

[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. Но почему? Мы ведь не просили их запускать.

Ответ следующий – Ceph сам запустил службы Monitor и Mgr, соответствуя своей политике.

Изначально все узлы в кластере считаются равноправными и позволяют запускать любые сервисы – за счет контейнеризации сделать это очень легко. Ceph сам следит за количеством служб Monitor и поддерживает их в количестве 5 шт. Как только мы добавили новые хосты и Ceph определил, что на них можно запускать службы, 4 новых монитора были автоматически добавлены, чтобы довести их общее количество до 5.

Однако, в моем небольшом кластере требуется всего 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 не является сложной задачей. И, как оказалось, сейчас это сделать значительно проще.

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

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

Блочный доступ с помощью RBD (Rados Block Device);

Файловый с помощью CephFS;

Объектный (S3) с помощью RadosGW.

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

Loading

8 thoughts on “Как запускать Ceph в 2022 году?”

  1. Оччень интересно, спасибо. Сделал похожую инсталляцию на Ubuntu 20.04.05, но на 4-х виртуалках до того как прочитать вашу статью. Все шло замечательно , но после установки первого монитора и добавления хостов в кластер, чуда не произошло как в вашем случае. Мониторы не поднялись на добавленных нодах. Возможно , проблема именно в том, что cephadm ожидает 5-ти мониторов . Не думаю, что это связано с docker-ом, которым пользовался вместо podman.
    root@ub4:~/.ssh# ceph orch host ls
    HOST ADDR LABELS STATUS
    ub1 172.21.1.133 _admin _no_schedule
    ub2 172.21.1.134 _admin _no_schedule
    ub3 172.21.1.135 _no_schedule
    ub4 172.21.1.137 _admin
    4 hosts in cluster

    root@ub4:~/.ssh# ceph -s
    cluster:
    id: 9b7e2d9c-4add-11ed-955e-ef594824aeef
    health: HEALTH_WARN
    failed to probe daemons or devices
    OSD count 0 < osd_pool_default_size 3

    services:
    mon: 1 daemons, quorum ub4 (age 25h)
    mgr: ub4.bjsrzq(active, since 25h)
    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:

    root@ub4:~/.ssh# docker ps
    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    5c28ded7af92 quay.io/prometheus/prometheus:v2.33.4 "/bin/prometheus –c…" 21 hours ago Up 21 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-prometheus-ub4
    360a3b6deb4c quay.io/prometheus/alertmanager:v0.23.0 "/bin/alertmanager -…" 21 hours ago Up 21 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-alertmanager-ub4
    1b882049044b quay.io/ceph/ceph-grafana:8.3.5 "/bin/sh -c 'grafana…" 26 hours ago Up 26 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-grafana-ub4
    6429e91f9bb9 quay.io/prometheus/node-exporter:v1.3.1 "/bin/node_exporter …" 26 hours ago Up 26 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-node-exporter-ub4
    020f2c106140 quay.io/ceph/ceph "/usr/bin/ceph-crash…" 26 hours ago Up 26 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-crash-ub4
    4cc3c177cb34 quay.io/ceph/ceph:v17 "/usr/bin/ceph-mgr -…" 26 hours ago Up 26 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-mgr-ub4-bjsrzq
    75c4623dc006 quay.io/ceph/ceph:v17 "/usr/bin/ceph-mon -…" 26 hours ago Up 26 hours ceph-9b7e2d9c-4add-11ed-955e-ef594824aeef-mon-ub4

    1. Спасибо за отзыв.
      Я думаю что в вашем случае дело в метке _no_schedule у остальных узлов.
      Данная метка препятствует запуску служб на узлах и обычно используется если с хостом нужно что-то сделать, например перегрузить.
      https://docs.ceph.com/en/latest/cephadm/host-management/

  2. Пытался установить ceph руками (без контейнеров) на debian – плюнул, так как неделя попыток и развёртывание 50+ ВМ остачертело…=(

    1. Мое мнение, что в контейнерах он смотрится лучше, чем в виде набора служб, как было ранее. Сейчас им управлять значительно проще и это несомненный плюс.

  3. Приветствую. Все сделал по инструкции и все отлично работает.
    Для теста использовал 5 виртуалок
    # Ceph-nodes
    10.10.0.80 ceph-mon-01
    10.10.0.90 ceph-mon-02
    10.10.0.81 ceph-osd-01
    10.10.0.82 ceph-osd-02
    10.10.0.83 ceph-osd-03
    Но есть проблема. Как только я вырубаю виртуалку ceph-mon-01 то сразу зависает сайт админки, хотя должен перекидывать на https://ceph-mon-02:8443/. Вторая проблема – ceph-mon-01 и ceph-mon-02 работаю и все ок. Как только вырубаю ceph-mon-02 то на сервере ceph-mon-01 невозможно выполнить даже команду ceph -s (сервак как будто виснет) и https://ceph-mon-01:8443/ так же перестает быть доступным.
    Во время установки никаких ошибок не было и все установилось отлично. Устанавливал последний –release reef
    Есть ли мысли куда смотреть?

    1. Добрый день.
      Первый момент – у вас используется две службы Ceph Monitor, что в корне неверно. Прочтите еще раз статью:
      “Основное правило – для формирования кворума необходима доступность более 50% служб.”
      Как только вы отключаете один из мониторов, у вас нарушается кворум, поскольку он становится равен 50%, хотя должен быть больше.
      Добавьте еще один монитор и ничего зависать у вас не будет.

      Относительно админки – перекидывать сам он никуда не должен. Когда отключаете один монитор, посмотрите, где работает служба ceph-mgr, к тому узлу и попробуйте подключаться через браузер.

      Но в любом случае, начните с добавления третьего монитора, а затем разнесите ceph-mgr на 3 узла (хотя можно и на 2, ему не принципиально).

      1. Вы правы!!!
        После добавления третьего монитора и менеджера все работает как надо!
        Спасибо огромное за пояснение.

  4. Было бы неплохо если бы вы написали подробный и качественный мануал по добавлении/подключении iSCSI к данному кластеру, а то на большинстве сайтов через N место состряпано. ))

Leave a Reply to PETR Cancel reply

Your email address will not be published. Required fields are marked *