Mon no data available ceph как быть

Как запускать 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. В своей практике я периодически встречал ситуации, когда при выходе из строя одного монитора, на короткое время пропадал еще один. В этой ситуации кластер с 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.

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

Author vmik Posted on 22/07/2022 22/07/2022 Categories Ceph, Linux, Storage

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

PETR says:

Оччень интересно, спасибо. Сделал похожую инсталляцию на 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

vmik says:

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

Юрок says:

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

vmik says:

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

Владимир says:

Приветствую. Все сделал по инструкции и все отлично работает.
Для теста использовал 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
Есть ли мысли куда смотреть?

vmik says:

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

Владимир says:

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

Владимир says:

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

ПРИМЕНЕНИЕ CEPH В СОВРЕМЕННЫХ ОБЛАЧНЫХ ИНСТАЛЛЯЦИЯХ Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Ильин Виктор Георгиевич, Цынгалёв Павел Сергеевич, Боронников Антон Сергеевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

USING CEPH IN MODERN CLOUD INSTALLATION

To date, the use of control systems for dynamic clusters of block devices is one of the integral parts of progressive cloud installations. These technologies avoid problems in disk management and configuration, such as inconsistency, unstructured and low availability of data storage. Actual software solutions to these problems have long been known to everyone, but today, taking into account modern realities, it is necessary to select analogues of such systems that are freely distributed and have an open source code. Ceph is such software. This product has a standard set of functions of this class of programs and has a large number of unique useful methods, which makes it a worthy analogue for use in cloud installations. Thus, the purpose of this article is to popularize the use of Ceph clusters. The paper describes typical installations for running a Ceph cluster on them and how to deploy it. Testing was carried out on tasks close to real ones that users may encounter, and an analysis of the results obtained was carried out. The article will be useful, first of all, both for presenting an analogue of control systems for dynamic clusters of block devices in existing cloud installations, and for selecting a system as a solution for newly created installations. This article provides a glimpse of what Ceph can do without physically deploying the necessary infrastructure, which will save potential users time and resources.

Текст научной работы на тему «ПРИМЕНЕНИЕ CEPH В СОВРЕМЕННЫХ ОБЛАЧНЫХ ИНСТАЛЛЯЦИЯХ»

Применение Ceph в современных облачных

В.Г. Ильин, П.С. Цынгалев, А.С. Боронников

Аннотация— На сегодняшний день применение систем управления динамических кластеров блочных устройств является одной из неотъемлемых частей прогрессивных облачных инсталляций. Данные технологии позволяют избежать проблем при управлении и конфигурации дисков, например, таких как несогласованность, неструктурированность и низкая доступность хранилища данных. Несмотря на наличие известных программных решений данных задач, на сегодняшний день, с учетом современных реалий, необходимо подбирать аналоги систем, которые свободно распространяются и имеют открытый программный код. Таким программным обеспечением является Ceph. Данный продукт обладает стандартным набором функций подобного класса программ и имеет большое число уникальных полезных методов, что делает его достойным аналогом для использования в облачных инсталляциях.

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

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

Ключевые слова— Ceph, облачные вычисления, Private Cloud Solution, Elastic Block Storage, кластер, виртуальная машина, облачная инфраструктура.

На сегодняшний день в нашей стране крайне актуальна проблема использования проприетарного прикладного программного обеспечения. Большинство

Статья получена 21 октября 2022.

Виктор Георгиевич Ильин, Кафедра вычислительной техники, МИРЭА - Российский технологический университет, Москва, Россия (e-mail: vgilyin@yahoo.com).

Павел Сергеевич Цынгалёв, Кафедра вычислительной техники, МИРЭА - Российский технологический университет, Москва, Россия (e-mail: pstsyngalev@mail.ru).

Антон Сергеевич Боронников, Кафедра вычислительной техники, МИРЭА - Российский технологический университет, Москва, Россия (e-mail: boronnikov-anton@mail.ru).

компаний, которые его поставляют, либо вовсе ушли с российского рынка, либо существенно ограничили свою деятельность. Такие же ограничения коснулись программ, которые позволяют проектировать отказоустойчивые системы хранения данных для управления большим количеством блочных устройств [12-19].

Например, лидер по проектированию и поставке программного обеспечения компания DELL с продуктом ScaleIO также ограничила деятельность на территории Российской Федерации. В связи с чем у компаний, использующих данное решение, возникли проблемы при обращении в поддержку и лицензирования программного обеспечения.

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

Отметим, что Ceph может работать в двух основных режимах — в режиме объектного хранилища (object storage) и в качестве системы управления блочными устройствами (block device). В данной статье будет рассмотрено использование Ceph в качестве менеджера блочных устройств.

Таким образом, целью данного исследования является популяризация программного обеспечения Ceph для решения конкретного класса прикладных задач [14-17].

II. Конфигурация тестового стенда

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

На сегодняшний день рабочими серверными решениями являются продукты компании Dell и IBM. Рассмотрим несколько серверов, которые подойдут в качестве кандидатов для тестового стенда.

В ходе поставленной задачи были описаны основные общие характеристики абстрактного сервера, который в последующем использовался в качестве тестового стенда. В таблице 1 указаны минимальные требования к узлам Ceph-кластера из официальной документации [3].

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

России. Анализ рынка показал, что данными компаниями являются "Samsung" и "Huawei". Среди продуктов данных компаний осуществлялся выбор блочных устройств.

Таблица 1. Минимальные требования к узлам Ceph-кластера

На основе документации Ceph к требованиям блочных устройств [1] описаны минимальные требования: размер диска - 1 терабайт; интерфейсы подключения - SAS, SATA. Количество операций ввода/вывода зависит от размера самого диска.

Перейдем к описанию спецификаций сервера, на основе которых будет проводиться тестирование Ceph-кластера:

- Процессор: Intel E5-2698v3 (2.3GHz, 16C, 35MB, 9.6GT/s QPI, 120W);

- Оперативная память: 32*8 Gb PC4 DDR4 ECC RDIMM;

- HDD диски: 600GB 2.5" SAS 6Gbps HS 15k;

- SSD диски: 2TB 2.5" Near Line SAS 12Gbps HS 7.2k;

- Raid контроллер: 1Gb RAID controller (0,1,10,5,50);

- Модуль управления: IMM2 Advanced (KVM);

- Основной адаптер: 4x1 Gb Integrated Ethernet Card;

- Блоки питания: 900W Platinum Hot-swap Power

Supply (x3650 M5).

Также стоит упомянуть операционную систему, на базе которой проектировался кластер Ceph. Была выбрана CentOS 7.5 [7, 9] благодаря стабильной версии пакетов и ядра Linux. Разработчики Ceph также рекомендуют использовать CentOS. Тестирование проходило на виртуальных машинах с типом гипервизора QEMU KVM [8, 10]. Использовалась версия Ceph 14 Nautilus, так как на данный момент она является наиболее стабильной и на сегодняшний день имеет поддержку. Выбор поставщиков комплектующих, указанных ранее, зависит от размера бюджета компании для реализации Ceph-кластера и от ситуации на рынке.

III. Основы функционирования кластера Ceph

Перед развертыванием самого кластера необходимо описать принципы работы Ceph-кластера, из каких узлов (частей) он состоит и как узлы между собой взаимодействуют [11]. Ceph - это файловая система [2] для управления хранилищ облачных инстанций. Ceph-кластер включает в себя 4 основных сущности: монитор (monitor), менеджер (manager), демон объектного хранилища (object storage demon - OSD), сервер метаданных (MDS - metadata server). Далее рассмотрим функционал каждой сущности.

Monitor - сущность-наблюдатель, которая работает независимо от других сущностей кластера и необходима для сбора информации. Информацию хранит в так называемых картах (manager map, OSD map, MDS map, CRUSH map). Данные карты описывают правила хранения log-файлов (файлы журнала событий) каждой из сущности, представляя собой критическое состояние кластера, необходимое демонам Ceph для координации друг с другом. Мониторы также отвечают за управление аутентификацией между демонами и клиентами.

Manager - сущность Ceph, которая работает в фоновом режиме и отвечает за отслеживание показателей времени выполнения и текущего состояния кластера Ceph, включая использование хранилища, текущие показатели производительности и загрузку системы. Данные сущности могут размещать модули на основе Python [4] для управления и предоставления информации о кластере Ceph, например Ceph Dashboard [5].

Компонент кластера Ceph Компонент Минимальные требования

ceph-osd Процессор 1 core minimum 1 core per 200-500 MB/s 1 core per 1000-3000 IOPS Results are before replication. Results may vary with different CPU models and Ceph features. (erasure coding, compression, etc) ARM processors specifically may require additional cores. Actual performance depends on many factors including drives, net, and client throughput and latency. Benchmarking is highly recommended.

Оперативная память 4GB+ per daemon (more is better) 2-4GB often functions (may be slow) Less than 2GB not recommended

Блочное устройство 1x storage drive per daemon

DW/WAL 1x SSD partition per daemon (optional)

Сеть 1x 1GbE+ NICs (10GbE+ recommended)

ceph-mon Процессор 2 cores minimum

Оперативная память 2-4GB+ per daemon

Объем диска 60GB per daemon

Сеть 1x 1GbE+ NICs

ceph-mds Процессор 2 cores minimum

Оперативная память 2GB+ per daemon

Объем диска 1 MB per daemon

Сеть 1x 1GbE+ NICs

OSD - сущность объектного хранилища, которая, как и Manager, работает в фоновом режиме. Отвечает за хранение данных, обработку репликации данных, восстановление, повторную балансировку и предоставляет некоторую информацию мониторинга для мониторов и менеджеров Ceph, проверяя другие сущности OSD Ceph на предмет доступности. Для каждого диска существует минимум одна OSD-сущность. Обычно физический диск представляет собой одну или несколько OSD сущностей. Затем OSD сущности объединяются в группы размещения (placement group - pg), что позволяет обеспечить высокую доступность, а также упорядочить структуру объектного хранилища для размещения данных.

MDS - сущность, которая хранит метаданные (данные о содержимом узлов кластера) от имени файловой системы Ceph (блочные устройства Ceph и хранилище объектов Ceph не используют MDS). Сущности хранения метаданных Ceph позволяют пользователям с файловой системы, поддерживающей POSIX-стандарты, выполнять операции командной строки, не создавая огромной нагрузки на кластер хранения Ceph.

Ceph хранит данные как объекты в логических пулах хранения. Используя CRUSH (Controlled Replication Under Scalable Hashing - алгоритм, использующий хэширование для расчета хранения и извлечения данных в распределенных системах на основе кластерного типа хранения), Ceph вычисляет, какая группа размещения должна содержать объект, и к какой группе размещения принадлежит конкретная OSD. Алгоритм CRUSH позволяет кластеру хранения Ceph динамически масштабироваться, перебалансироваться и

IV. Особенности развертывания кластеров Ceph

При развертывании кластеров Ceph процесс установки необходимо выполнить самостоятельно, в отличие от процесса установки проприетарного программного обеспечения. На сегодняшний день существуют два наиболее эффективных решения для развертывания Ceph-кластера — установка из Ansible playbook (желаемое состояние каких-либо сущностей с использованием файла конфигурации на языке yaml: в данном файле прописываются количества узлов кластера и их характеристики), который можно получить с официального сайта Ceph, и полностью ручная установка.

Поэтому развертывание Ceph полностью вручную не требуется, так как существует Ansible playbook, который при минимальной настройке конфигурационных файлов способен развернуть Ceph-кластер. Однако при большом масштабировании кластера процесс развертывания может быть усложнен. Поэтому в данной ситуации может быть полезна ручная установка. К основным причинам можно отнести:

- безопасность при развертывании большой системы;

- меньше зависимость от других разработчиков

- более гибкая настройка, что позволяет получить

более точную желаемую конфигурацию.

V. Тестирование кластеров Ceph

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

- 1 виртуальная машина, 1 диск — данный пример

позволяет отобразить максимальную

производительность 1 диска при использовании в нескольких виртуальных машинах.

- 1 виртуальная машина, 4 диска — данный случай

является самым распространённым при конфигурации 1 виртуальной машины, так как позволяет реализовывать структуру RAID 10, что обеспечивает отказоустойчивость хранения данных при оптимальной производительности;

- 10 виртуальных машин, 1 диск —

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

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

A. Тестирование при конфигурации 1 виртуальная

машина, 1 диск (1VM-1D)

Данный тест позволяет определить максимальную производительность одного блочного устройства (диска) при полностью простаивающем кластере. Более высокой производительности навряд ли удастся достигнуть при иной конфигурации. При тестировании дисков использовалась утилита "fio" [6, 13] со следующими ключевыми параметрами:

- ioengine — тип engine составляющей утилиты "fio",

который содержит основные команды и инструкции для проведения тестирования на чтение/запись. Был использован стандартный engine "libaio", как рекомендуют сами разработчики данной утилиты;

- buffered 0 — буферизированный ввод отключен,

значит что файловая система не будет использовать кэш, что позволит минимизировать влияние системы на производительность диска и провести более точное тестирование;

- bs — размер блока операций чтения, записи;

- rw randrw — данные будут записываться и читаться

- rwmixread 60 — смешанное чтение, запись, 60%

процентов операций при тестировании будут приходится на чтение, 40 на запись;

- iodepth — глубина очереди.

Результаты тестов для размера блока записи 4 килобайт показаны в таблицах 2-3.

Таблица 2. Результаты тестирования при конфигурации 1VM-1D на 3 серверах, 6 SSD-дисков с размером диска 64 Гбайт, блок записи 4 Кбайт

Таблица 3. Результаты тестирования при конфигурации 1VM-1D на 3 серверах, 6 ИББ-дисков с размером диска 64 Гбайт, блок записи 4 Кбайт

Результаты тестов для размера блока записи 64 Кбайт показаны в таблицах 4-5.

Таблица 4. Результаты тестирования при конфигурации 1VM-1D на 3 серверах, 6 88Б-дисков с размером диска 64 Гбайт, блок записи 64 Кбайт

Таблица 5. Результаты тестирования при конфигурации 1VM-1D на 3 серверах, 6 ИББ-дисков с размером диска 64 Гбайт, блок записи 64 Кбайт

Анализ результатов тестирования описан в разделе

B. Тестирование при конфигурации 1 виртуальная машина, 4 диска (1VM-4D)

Данный случай является самым распространённым, при конфигурации одной виртуальной машины, так как позволяет реализовывать RAID 10, что обеспечивает отказоустойчивость хранения данных при оптимальной производительности. Результаты тестов для размера блока записи 4 Кбайт показаны в таблицах 6-7.

Таблица 6. Результаты тестирования при конфигурации 1VM-4D на 3 серверах, 6 SSD-дисков с размером диска 64 Гбайт, блок записи 4 Кбайт

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Таблица 7. Результаты тестирования при конфигурации 1УМ-4Б а на 3 серверах, 6 ИББ-дисков с размером диска 64 Гбайт, блок записи 4 Кбайт

Результаты тестов для размера блока записи 64 Кбайт показаны в таблицах 8-9.

Таблица 8. Результаты тестирования при конфигурации 1VM-4D на 3 серверах, 6 SSD-дисков с размером диска 64 Гбайт, блок записи 64 Кбайт

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

16 11200 375 25

32 20500 625 30

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

Глубина очереди IOPS, кол-во операций ввода/вывода в секунду Пропускная способность, Мбит/с Общая задержка, мс

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

Таблица 9. Результаты тестирования при Таблица 12. Результаты тестирования при конфигурации 1VM-4D на 3 серверах, 6 HDD-дисков конфигурации 10VM-1D на 3 серверах, 6 SSD-дисков с размером диска 64 Гбайт, блок записи 64 Кбайт с размером диска 64 Гбайт, блок записи 64 Кбайт

Глубина IOPS, кол-во Пропускная Общая Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка, очереди операций способность, задержка,

ввода/вывода Мбит/с мс ввода/вывода Мбит/с мс

в секунду в секунду

4 1700 90 13 4 5400 169 8

8 1900 92 14 8 6400 200 8

16 2100 95 14 16 7500 234 9

32 2000 95 15 32 8000 250 8

Анализ результатов тестирования описан в разделе У1.Б.

С. Тестирование при конфигурации 10 виртуальных машин, 1 диск (10УМ-Ю)

В данном случае необходимо разделение дискового пространства для доступа некоторого числа виртуальных машин к одному конкретному разделу диска для совместной записи/ чтения. Результаты тестов для размера блока записи 4 Кбайт показаны в таблицах 10-11. Результаты тестов для размера блока записи 64 Кбайт показаны в таблицах 12-13. Анализ результатов тестирования описан в разделе УТ.С.

Таблица 13. Результаты тестирования при конфигурации 10VM-1D на 3 серверах, 6 HDD-дисков с размером диска 64 Гбайт, блок записи 64 Кбайт

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

Таблица 10. Результаты тестирования при конфигурации 10VM-1D на 3 серверах, 6 SSD-дисков с размером диска 64 Гбайт, блок записи 4 Кбайт

Таблица 11. Результаты тестирования при конфигурации 10VM-1D на 3 серверах, 6 HDD-дисков с размером диска 64 Гбайт, блок записи 4 Кбайт

VI. Анализ результатов тестирования

Для упрощения представления результатов тестов разобьем их по размерам блоков чтения и записи — 4 Кбайт и 64 Кбайт соответственно.

A. Тестирование при конфигурации 1 виртуальная машина, 1 диск

Данный тест позволил узнать максимальную производительность диска.

Результаты тестирования при размере блока 4 Кбайт:

- Среднее значение на SSD: 10475 IOPS;

- Среднее значение на HDD: 5625 IOPS.

Результаты тестирования при размере блока 64 Кбайт:

- Среднее значение на SSD: 2150 IOPS;

- Среднее значение на HDD: 1475 IOPS.

B. Тестирование при конфигурации 1 виртуальная машина, 4 диска

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

Результаты тестирования при размере блока 4 Кбайт:

- Среднее значение на SSD: 5925 IOPS;

- Среднее значение на HDD: 4175 IOPS.

Результаты тестирования при размере блока 64 Кбайт:

- Среднее значение на SSD: 3050 IOPS;

- Среднее значение на HDD: 1925 IOPS.

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Глубина IOPS, кол-во Пропускная Общая

очереди операций способность, задержка,

ввода/вывода Мбит/с мс

C. Тестирование при конфигурации 10 виртуальных машин, 1 диск

Распространенный случай организации общего хранилища данных среди множества вычислительных устройств. При тестировании операции чтения/записи выполнялись одновременно с десяти машин.

Результаты тестирования при размере блока 4 Кбайт:

- Среднее значение на SSD: 7050 IOPS;

- Среднее значение на HDD: 4950 IOPS.

Результаты тестирования при размере блока 64 Кбайт:

- Среднее значение на SSD: 6825 IOPS;

- Среднее значение на HDD: 4100 IOPS.

D. Утилизация CPURBD серверов

Разработчики Ceph утверждают о достаточности двух

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

E. Общая оценка результатов тестирования

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

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

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

В зависимости от потребностей эксплуататора Ceph способен предоставить хорошую производительность при превосходном уровне защиты консистентности данных.

Также в пользу Ceph играет фактор свободы от лицензирования. Не произойдет той ситуации, когда инфраструктура не сможет быть обновлена до актуальной версии продукта.

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

программного обеспечения делает Ceph лучшим

решением для частных облачных инсталляций.

[1] Ceph Block Device. - URL: https://docs.ceph.com/en/quincy/rbd/ (дата обращения: 25.09.2022)

[2] Ceph File System. - URL: https://docs.ceph.com/en/quincy/cephfs/ (дата обращения: 26.09.2022)

[3] Installing Ceph. - URL: https://docs.ceph.com/en/quincy/install/ (дата обращения: 28.09.2022)

[4] Ceph Dashboard. - URL: https://docs.ceph.com/en/quincy/mgr/dashboard/ (дата обращения: 29.09.2022)

[5] API Documentation. - URL: https://docs.ceph.com/en/quincy/api/ (дата обращения: 30.09.2022)

[6] FIO's documentation. - URL: https://fio.readthedocs.io/en/latest/ (дата обращения: 2.10.2022)

[7] CentOS Documentation. - URL: https://docs.centos.org/en-US/docs/ (дата обращения: 4.10.2022)

[8] J. Cannon, "Docker: A Project-Based Approach to Learning Kindle Edition", p.298

[9] А.М. Кенин, Д.Н. Колисниченко., Самоучитель системного администратора, 6-е изд - СПб.: БХВ-Петербург, 2021. - 608 с.

[10] V. Dakic, H.D. Chirammal, Prasad Mukhedkar, "Mastering KVM Virtualization", 2020, p. 686

[11] Ceph network configuration. - URL: https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/5/html/configuration_guide/ceph-network-configuration (дата обращения: 6.10.2022)

[12] Analyzing Ceph cluster optimize storage cost. - URL: https://www.intel.com/content/dam/www/public/us/en/documents/ref erence-architectures/120315-analyzing-ceph-cluster-optimize-storage-costs.pdf (дата обращения: 25.09.2022)

[13] HDD testing prerequisites. - URL: https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/hard-disk-drive-testing-prerequisites

[14] X. Zhang, Ya. Wang, Q. Wang, X. Zhao, "A New Approach to Double I/O performance for Ceph Distributed File System in Cloud Computing," in 2019 2nd International Conference on Data Intelligence and Security (ICDIS), pp. 68-75.

[15] H. Li, Sh. Zhang, Z. Guo; Z. Huang, L. Qian, "Test and Optimization of Large-scale Ceph System," in 2020 IEEE 3rd International Conference of Safe Production and Informatization (IICSPI), pp. 237-241.

[16] K. Jeong, C. Duffy, J-S. Kim, J. Lee, "Optimizing the Ceph Distributed File System for High Performance Computing," in 2019 27th Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP), pp. 446-451.

[17] M. Hilmi, E. Mulyana, H. Hendrawan, A. Taniwidjaja, "Analysis of Network Capacity Effect on Ceph Based Cloud Storage Performance," in 2019 IEEE 13th International Conference on Telecommunication Systems, Services, and Applications (TSSA), pp. 22-24.

[18] M. Oh, S. Park, J. Yoon, S. Kim, K. Lee, S. Weil. H.Y. Yeom, M. Jung, "Design of Global Data Deduplication for a Scale-Out Distributed Storage System," in 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS), pp. 10631073.

[19] M. Oh, J. Eom, J. Yoon, J.Y. Yun, S. Kim, H.Y. Yeom, "Performance Optimization for All Flash Scale-Out Storage," in 2016 IEEE International Conference on Cluster Computing (CLUSTER), pp. 316-325.

International Journal of Open Information Technologies ISSN: 2307-8162 vol. 11, no. 2, 2023

Using Ceph in modern Cloud installation

V.G. Ilyin, P.S. Tsyngalev, A.S. Boronnikov

Abstract — To date, the use of control systems for dynamic clusters of block devices is one of the integral parts of progressive cloud installations. These technologies avoid problems in disk management and configuration, such as inconsistency, unstructured and low availability of data storage. Actual software solutions to these problems have long been known to everyone, but today, taking into account modern realities, it is necessary to select analogues of such systems that are freely distributed and have an open source code. Ceph is such software. This product has a standard set of functions of this class of programs and has a large number of unique useful methods, which makes it a worthy analogue for use in cloud installations.

Thus, the purpose of this article is to popularize the use of Ceph clusters. The paper describes typical installations for running a Ceph cluster on them and how to deploy it. Testing was carried out on tasks close to real ones that users may encounter, and an analysis of the results obtained was carried out. The article will be useful, first of all, both for presenting an analogue of control systems for dynamic clusters of block devices in existing cloud installations, and for selecting a system as a solution for newly created installations.

This article provides a glimpse of what Ceph can do without physically deploying the necessary infrastructure, which will save potential users time and resources.

Keywords — Ceph, Cloud Computing, Private Cloud Solution, Elastic Block Storage, cluster, virtual machine, cloud infrastructure.

[13] HDD testing prerequisites [Online]. Available: https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/hard-disk-drive-testing-prerequisites

[1] Ceph Block Device [Online]. Available: https://docs.ceph.com/en/quincy/rbd/

[2] Ceph File System [Online]. Available: https://docs.ceph.com/en/quincy/cephfs/

[3] Installing Ceph [Online]. Available: https://docs.ceph.com/en/quincy/install/

[4] Ceph Dashboard [Online]. Available: https://docs.ceph.com/en/quincy/mgr/dashboard/

[5] API Documentation [Online]. Available: https://docs.ceph.com/en/quincy/api/

[6] FIO's documentation [Online]. Available: https://fio.readthedocs.io/en/latest/

[7] CentOS Documentation [Online]. Available: https://docs.centos.org/en-US/docs/

[8] J. Cannon, "Docker: A Project-Based Approach to Learning Kindle Edition", p.298

[9] A.M. Kenin, D.N. Kolisnichenko., System administrator tutorial, 6 edition. - SP.: BHV-Peterburg, 2021. - 608 c.

[10] V. Dakic, H.D. Chirammal, Prasad Mukhedkar, "Mastering KVM Virtualization", 2020, p. 686

Rookio Ceph cluster : mon c is low on available space message [closed]

Closed. This question is not about programming or software development. It is not currently accepting answers.

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Closed 3 months ago .

I have setup RookIO 1.4 cluster in Kubernetes 1.18. with 3 nodes allocated 1TB storage on each of them. after creating cluster. when I run the ceph status cluster status shows as HEALTH_WARN with mon c is low on available space . There is no data stored yet. why status how low on available space? How to clear this error?

[root@rook-ceph-tools-6bdcd78654-sfjvl /]# ceph status cluster: id: ad42764d-aa28-4da5-a828-2d87205aff08 health: HEALTH_WARN mon c is low on available space services: mon: 3 daemons, quorum a,b,c (age 37m) mgr: a(active, since 36m) osd: 3 osds: 3 up (since 37m), 3 in (since 37m) data: pools: 1 pools, 1 pgs objects: 0 objects, 0 B usage: 3.0 GiB used, 3.6 TiB / 3.6 TiB avail pgs: 1 active+clean

All three node has same size storage:

sdb 8:16 0 1.2T 0 disk └─ceph--a6cd601d--7584--4b1f--bf82--48c95437f351-osd--data--ae1bc856--8ded--4b1e--8c87--30ca0f0959a3 253:3 0 1.2T 0 lvm sdb 8:16 0 1.2T 0 disk └─ceph--ccaf7144--d6a0--441c--bcd5--6a09d056bd7a-osd--data--36a9b28c--7207--400a--936b--edfb3255ce0b 253:3 0 1.2T 0 lvm sdb 8:16 0 1.2T 0 disk └─ceph--53e9b8a9--8925--4b21--a6ea--f8e17a322d5c-osd--data--6b1e779c--a18a--4e4d--960e--73ca9473d02f 253:3 0 1.2T 0 lvm

Предварительная настройка Ceph

Перед подключением хранилища Ceph к кластеру VMmanager необходимо провести предварительную настройку узлов кластера Ceph. В этой статье приведена общая информация об установке. Рекомендуем создавать кластер Ceph в соответствии с официальной документацией.

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

Узлы и кластеры хранилища Ceph не являются узл ами и кластерами VMmanager.

Рекомендуем использовать программное обеспечение Ceph версии не ниже 13.2.0.

Требования к узлам кластера

В составе кластера должны быть следующие физические или виртуальные серверы:

сервер с данными (OSD);
не менее трёх серверов-мониторов (MON);
административный сервер (ADM);
сервис мониторинга (MGR);
сервер метаданных (MDS). Необходим, если вы используете файловую систему CephFS.

Серверы должны отвечать следующим требованиям:

В качестве узла кластера не может использоваться сервер с платформой VMmanager.
Не рекомендуется использовать узлы кластера VMmanager. Это приводит к высокой нагрузке на сервер и усложняет процесс его восстановления в случае выхода из строя.
Рекомендуем использование серверов, находящихся в одной стойке и в одном сегменте сети.
Рекомендуем использовать высокоскоростное сетевое подключение между узлами кластера.
На всех серверах должна быть установлена одна операционная система.
На серверах-мониторах должен быть открыт доступ к порту 6789/TCP, на серверах с данными — к диапазону портов 6800..7300/TCP.
На всех узлах кластера должен быть непримонтированный раздел или диск для установки программного обеспечения (ПО) Ceph.

Пример подготовки узлов кластера

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

ceph-cluster-1 с IP-адресом 172.31.245.51. Назначение — MON, OSD, ADM, MGR.
ceph-cluster-2 с IP-адресом 172.31.246.77. Назначение — MON, OSD.
ceph-cluster-3 с IP-адресом 172.31.246.82. Назначение — MON, OSD.

Если при выполнении команды ceph-deploy появляется ошибка "RuntimeError: NoSectionError: No section: 'ceph'", выполните команду повторно.

На всех серверах

Установите ПО Ceph. Для этого:

Выполните команду:

yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

[ceph-noarch] name=Ceph noarch packages baseurl=https://download.ceph.com/rpm-nautilus/el7/noarch enabled=1 gpgcheck=1 type=rpm-md gpgkey=https://download.ceph.com/keys/release.asc

yum update

yum install ntp ntpdate ntp-doc

useradd -d /home/ceph -m ceph passwd ceph echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph chmod 0440 /etc/sudoers.d/ceph

172.31.245.51 ceph1.example.com ceph1 172.31.246.77 ceph2.example.com ceph2 172.31.246.82 ceph3.example.com ceph3

firewall-cmd --zone=public --add-service=ceph-mon --permanent firewall-cmd --zone=public --add-service=ceph --permanent firewall-cmd --reload

На административном сервере

Установите пакеты ceph-deploy и python-setuptools:

yum install ceph-deploy python-setuptools

ssh-keygen ssh-copy-id ceph@ceph1 ssh-copy-id ceph@ceph2 ssh-copy-id ceph@ceph3

Host ceph1 Hostname ceph1 User ceph Host ceph2 Hostname ceph2 User ceph Host ceph3 Hostname ceph3 User ceph

mkdir my-cluster cd my-cluster

ceph-deploy new ceph1 ceph2 ceph3

Mon no data available ceph как быть

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

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

ПРИМЕНЕНИЕ CEPH В СОВРЕМЕННЫХ ОБЛАЧНЫХ ИНСТАЛЛЯЦИЯХ Текст научной статьи по специальности «Компьютерные и информационные науки»

USING CEPH IN MODERN CLOUD INSTALLATION

Текст научной работы на тему «ПРИМЕНЕНИЕ CEPH В СОВРЕМЕННЫХ ОБЛАЧНЫХ ИНСТАЛЛЯЦИЯХ»

Rookio Ceph cluster : mon c is low on available space message [closed]

Предварительная настройка Ceph

Требования к узлам кластера

Пример подготовки узлов кластера

На всех серверах

На административном сервере

Добавить комментарий Отменить ответ