Ceph: разбираем базовые операции в кластере на примере интеграции с Hashicorp Nomad

в 8:32, , рубрики: ceph, nomad, selectel, СХД, хранение данных
Ceph: разбираем базовые операции в кластере на примере интеграции с Hashicorp Nomad - 1

Привет! Я Владимир Иванов, системный администратор выделенных серверов в Selectel. Мы довольно часто экспериментируем с подходами, процессами и решениями. В одном из экспериментов добрались до Ceph: сделали тренажер, в котором можно «потыкать» основной функционал хранилища, проверить гипотезы, что-то сломать/починить, не собирая при этом железный кластер. В случае фейла этот тренажер можно развернуть заново в пару консольных команд.

Так и появилась идея написать эту статью. Я покажу, как подключить Ceph к оркестратору Nomad, чтобы получить постоянное хранилище для контейнеров. Если хотите поближе познакомиться с примерами эксплуатации и обслуживания Ceph, прошу под кат! А если уже знакомы — прошу в комментарии, поделитесь своим опытом.

Ceph — программно определяемая система хранения данных (SDS, Software Defined Storage). Если коротко, он объединяет несколько дисков обычной сетью, лучше от 10 GbE. Хранилище устойчиво к выходу из строя отдельных дисков, серверов, стоек или даже дата-центров. В отличие от большинства вендорных СХД, Ceph разворачивается почти на любом железе и поддерживает несколько протоколов доступа к данным: объектный, файловый и блочный. В рамках статьи я рассмотрю последний из них.

При подготовке этой статьи я исхожу из того, что вы знакомы с общепринятыми терминами и сокращениями. Архитектура хранилища Ceph подробно описана в документации, на Хабре есть статья с картинками, а у СЛЁРМ — классный курс.

Nomad — это планировщик для ваших приложений. Ближайший аналог — Kubernetes. В Nomad значительно легче вкатиться: он прост в установке и подготовке к работе. Разработчики, компания Hashicorp, поддерживают автоматическую интеграцию основных инструментов экосистемы между собой: Nomad, Consul, Vault и Terraform. Если у вас есть опыт работы с любым из этих инструментов, разобраться с синтаксисом заданий не составит большого труда.

Используйте навигацию, если не хотите читать текст полностью:

Зачем подключать Ceph к Nomad
Подготовка стенда
Добавление OSD
Создание и настройка пула хранения
Настройка авторизации клиента кластера
Разворачиваем Nomad
Где хранятся настройки Ceph
Обслуживание кластера
Заключение

Зачем подключать Ceph к Nomad


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

Ceph: разбираем базовые операции в кластере на примере интеграции с Hashicorp Nomad - 2

Общая схема взаимодействия компонентов между собой.

Вместо Nomad может быть K8s, выделенный сервер или платформа виртуализации. Отличаться будет только интерфейс предоставления блочного доступа к данным: CSI, RBD, iSCSI или NVME-OF. Nomad использует CSI Driver (Container Storage Interface Driver). Это унифицированный интерфейс, в котором описано взаимодействие между Nomad и системой хранения.

Ceph-CSI состоит из двух компонентов:

  • Ceph-CSI Controller — работает непосредственно с Ceph, создает и удаляет тома, назначает права доступа и т. д.;
  • Ceph-CSI Node — запускается на каждом узле и монтирует выделенные для задачи тома.

При подготовке этой статьи мы реализовали ChefCookbook, который автоматизирует деплой кластера Ceph и в несколько команд настраивает виртуальное окружение test-kitchen. С его помощью можно развернуть тестовый кластер у себя на ноутбуке в пару консольных команд. При запуске стенда развернем четыре виртуальные машины: три под кластер Ceph и одну для клиента кластера. У нас этим клиентом будет Nomad. Инструкция по настройке «тренажера» описана в репозитории.

Ceph: разбираем базовые операции в кластере на примере интеграции с Hashicorp Nomad - 3

Подготовка стенда


Вкратце, все сводится к установке необходимых зависимостей и запуску test-kitchen:

# Деплой локального кластера
:~$ kitchen converge
# Логинимся на первую ноду кластера
:~$ kitchen login node1
# Разбираем кластер, удаляем данные виртуальных машин
:~$ kitchen destroy

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

vagrant@node1:~# ceph -s
  cluster:
    id:     6ba7d13c-642b-11ee-b8b2-c70be95e3c50
    health: HEALTH_WARN
            OSD count 0 < osd_pool_default_size 3
  services:
    mon: 3 daemons, quorum node1,node2,node3 (age 28m)
    mgr: node1.cauksk(active, since 44m), standbys: node2.ecffgz
    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:

# Если вы не меняли адресацию в файле kitchen.yml Ceph Dashboard будет доступна с вашего локального хоста.
Ceph Dashboard - https://192.168.56.6:8443/ или https://192.168.56.5:8443/ (в зависимости от того, где работает сервис mgr)
Креды по умолчанию: login - ceph-admin, pass - pa$$w0rd

Из вывода выше мы видим, что кластер развернут и состоит из:

  • трех сервисов мониторов (mon), которые поддерживают кворум между собой;
  • двух сервисов менеджеров, один активен, второй «на подхвате»;
  • ноля сервисов OSD.

Данных в кластере нет, никакие сервисные флаги не установлены. А отсутствие сервисов OSD — причина, по которой кластер находится в состоянии warning.

Добавление OSD


Сервисы Ceph крутятся в контейнерах под управлением systemd. У хранилища есть инструмент ceph orch, с помощью которого можно настраивать практически все сервисы кластера, чем мы и займемся. В принципе, добавление OSD можно автоматизировать в рамках рецептов кукбука, но я намеренно этого не делаю, чтобы мы могли все потрогать и покрутить своими руками.

Кластер состоит из трех нод, у каждой помимо системного есть по два дополнительных диска. Мы можем инициализировать сервисы OSD на всех из них, выбрать некоторые из конкретных узлов или передать спецификацию YAML, указав в ней правило добавления дисков.

Мы используем все свободные диски кластера под сервисы OSD, потому что так быстрее, но в производственной среде стоит подумать, какие из них и по каким правилам будем добавлять в кластер. Так же инструмент ceph orch позволяет разворачивать и другие сервисы Ceph.

# Вывести все диски кластера
root@node1:~# ceph orch device ls

HOST   PATH      TYPE  DEVICE ID                           SIZE  AVAILABLE  REFRESHED  REJECT REASONS  
node1  /dev/sdb  hdd   VBOX_HARDDISK_VBaa3afe84-dcde44b9  6000M  Yes        18m ago                    
node1  /dev/sdc  hdd   VBOX_HARDDISK_VB6cfb6cfd-cbfff2b2  6000M  Yes        18m ago                    
node2  /dev/sdb  hdd   VBOX_HARDDISK_VB9a0de133-d4c47481  6000M  Yes        2m ago                     
node2  /dev/sdc  hdd   VBOX_HARDDISK_VB17ff3e6d-ff3a778d  6000M  Yes        2m ago                     
node3  /dev/sdb  hdd   VBOX_HARDDISK_VBef988c66-7de380c8  6000M  Yes        24s ago                    
node3  /dev/sdc  hdd   VBOX_HARDDISK_VBb42afeb2-1643e145  6000M  Yes        24s ago                    

# Развернуть сервисы OSD на всех доступных дисках
root@node1:~# ceph orch apply osd --all-available-devices
Scheduled osd.all-available-devices update...

# Посмотреть состояние сервисов osd
root@node1:~# ceph orch ps --daemon_type osd
NAME   HOST   PORTS  STATUS         REFRESHED  AGE  MEM USE  MEM LIM  VERSION  IMAGE ID      CONTAINER ID  
osd.0  node3         running (1m)     1m ago  1m    26.9M    4096M  18.2.2   7b46ae09e5dc  c20a9a449e32  
osd.1  node2         running (1m)     1m ago  1m    35.5M    4096M  18.2.2   7b46ae09e5dc  d6a3d414084b  
osd.2  node1         running (1m)     1m ago  1m    23.8M    4096M  18.2.2   7b46ae09e5dc  baae22c434b9  
osd.3  node3         running (1m)     1m ago  1m    28.5M    4096M  18.2.2   7b46ae09e5dc  5cb04e5d04b4  
osd.4  node2         running (1m)     1m ago  1m    27.6M    4096M  18.2.2   7b46ae09e5dc  c2ad3d47caf5  
osd.5  node1         running (1m)     1m ago  1m    24.8M    4096M  18.2.2   7b46ae09e5dc  0c1ae30543fc

Создание и настройка пула хранения


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

Начнем с настройки политик. С их помощью мы можем, например, настроить распределение пулов на разных типах носителей, тем самым определить их производительность. В нашем кластере отсутствуют устройства SSD, поэтому переопределим класс некоторых дисков. Данная операция может потребоваться и на боевом кластере, если ваши SSD прячутся за HBA-контроллером и определяются ОС как HDD.

root@node1:~# ceph osd crush rm-device-class osd.2 osd.1 osd.0
done removing class of osd(s): 0,1,2
root@node1:~# ceph osd crush set-device-class ssd osd.2 osd.1 osd.0
set osd(s) 0,1,2 to class 'ssd'
root@node1:~# ceph osd df tree
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP  META     AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME     
-1         0.03415         -   35 GiB  266 MiB  3.8 MiB   0 B  262 MiB   35 GiB  0.74  1.00    -          root default  
-7         0.01138         -   12 GiB   89 MiB  1.3 MiB   0 B   88 MiB   12 GiB  0.74  1.00    -              host node1
 5    hdd  0.00569   1.00000  5.9 GiB   62 MiB  948 KiB   0 B   61 MiB  5.8 GiB  1.04  1.40    1      up          osd.5 
 2    ssd  0.00569   1.00000  5.9 GiB   26 MiB  368 KiB   0 B   26 MiB  5.8 GiB  0.44  0.60    0      up          osd.2 
-3         0.01138         -   12 GiB   89 MiB  1.3 MiB   0 B   88 MiB   12 GiB  0.74  1.00    -              host node2
 4    hdd  0.00569   1.00000  5.9 GiB   62 MiB  948 KiB   0 B   61 MiB  5.8 GiB  1.04  1.40    1      up          osd.4 
 1    ssd  0.00569   1.00000  5.9 GiB   26 MiB  356 KiB   0 B   26 MiB  5.8 GiB  0.44  0.60    0      up          osd.1 
-5         0.01138         -   12 GiB   89 MiB  1.3 MiB   0 B   88 MiB   12 GiB  0.74  1.00    -              host node3
 3    hdd  0.00569   1.00000  5.9 GiB   62 MiB  936 KiB   0 B   61 MiB  5.8 GiB  1.04  1.40    1      up          osd.3 
 0    ssd  0.00569   1.00000  5.9 GiB   26 MiB  356 KiB   0 B   26 MiB  5.8 GiB  0.44  0.60    0      up          osd.0 
                       TOTAL   35 GiB  266 MiB  3.8 MiB   0 B  262 MiB   35 GiB  0.74                                   
MIN/MAX VAR: 0.60/1.40  STDDEV: 0.30

В листинге выше видно, что OSD. [0-2] находятся на разных узлах в дереве с корнем default. Кстати, с помощью политик можно создавать несколько корней и за счет этого хранить данные в одном кластере, но на разных хостах, стойках или дата-центрах. Ниже создадим пул данных и применим к нему политику размещения «только на SSD», а далее укажем, что данный пул будем использовать под RBD-образы.

Создаем политику для реплицированных пулов с именем replicated_ssd. Данные будут иметь домен отказа host, а размещаться — на SSD.

root@node1:~# ceph osd crush rule create-replicated replicated_ssd default host ssd

Посмотреть настройки политик можно этой командой:

root@node1:~# ceph osd crush rule dump

Создаем реплицированный пул nomad, «нарезанный» на 32 кусочка (PG, или placement group).

root@node1:~# ceph osd pool create nomad 32 32 replicated
pool 'nomad' created

Назначаем пулу crush правило SIC. Эту настройку необходимо выполнить до того, как залили пул клиентскими данными, иначе подобные действия приведут к их перемещению внутри кластера, что снизит производительность для клиентов.

root@node1:~# ceph osd pool set nomad crush_rule replicated_ssd
set pool 2 crush_rule to replicated_ssd

Указываем, что данный пул будет использоваться под блочные устройства (RBD):

root@node1:~# ceph osd pool application enable nomad rbd
enabled application 'rbd' on pool 'nomad'

Смотрим на дерево кластера. Видно, что OSD.[0-2] содержат по 32 PG:

root@node1:~# ceph osd df tree
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA      OMAP  META     AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME     
-1         0.03415         -   35 GiB  267 MiB   4.3 MiB   0 B  262 MiB   35 GiB  0.74  1.00    -          root default  
-7         0.01138         -   12 GiB   89 MiB   1.4 MiB   0 B   88 MiB   12 GiB  0.74  1.00    -              host node1
 5    hdd  0.00569   1.00000  5.9 GiB   62 MiB  1020 KiB   0 B   61 MiB  5.8 GiB  1.04  1.40    1      up          osd.5 
 2    ssd  0.00569   1.00000  5.9 GiB   27 MiB   440 KiB   0 B   26 MiB  5.8 GiB  0.44  0.60   32      up          osd.2 
-3         0.01138         -   12 GiB   89 MiB   1.4 MiB   0 B   88 MiB   12 GiB  0.74  1.00    -              host node2
 4    hdd  0.00569   1.00000  5.9 GiB   62 MiB  1020 KiB   0 B   61 MiB  5.8 GiB  1.04  1.40    1      up          osd.4 
 1    ssd  0.00569   1.00000  5.9 GiB   27 MiB   440 KiB   0 B   26 MiB  5.8 GiB  0.44  0.60   32      up          osd.1 
-5         0.01138         -   12 GiB   89 MiB   1.4 MiB   0 B   88 MiB   12 GiB  0.74  1.00    -              host node3
 3    hdd  0.00569   1.00000  5.9 GiB   62 MiB  1020 KiB   0 B   61 MiB  5.8 GiB  1.04  1.40    1      up          osd.3 
 0    ssd  0.00569   1.00000  5.9 GiB   27 MiB   440 KiB   0 B   26 MiB  5.8 GiB  0.44  0.60   32      up          osd.0 
                       TOTAL   35 GiB  267 MiB   4.3 MiB   0 B  262 MiB   35 GiB  0.74                                   
MIN/MAX VAR: 0.60/1.40  STDDEV: 0.30

Детально посмотрим на настройку пулов и проверим, что все в порядке. Запись replicated size 3 — настройка по умолчанию, которая указывает, что все данные будут храниться в кластере в трех экземплярах. Ниже я ее называю «размер пула». Также обратите внимание, что у каждого пула есть свой id.

root@node1:~# ceph osd pool ls detail
pool 1 '.mgr' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 1 pgp_num 1 autoscale_mode on last_change 21 flags hashpspool stripe_width 0 pg_num_max 32 pg_num_min 1 application mgr read_balance_score 6.00
pool 2 'nomad' replicated size 3 min_size 2 crush_rule 1 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 43 flags hashpspool stripe_width 0 application rbd read_balance_score 1.22

Команда выводит служебную информацию о PG: где находятся primary- и secondary-данные, в каком состоянии PG, когда выполнялась проверка целостности. PG начинается с id пула, частью которого она является:

root@node1:~# ceph pg ls
PG    OBJECTS  DEGRADED  MISPLACED  UNFOUND  BYTES   OMAP_BYTES*  OMAP_KEYS*  LOG  LOG_DUPS  STATE         SINCE  VERSION  REPORTED  UP         ACTING     SCRUB_STAMP                      DEEP_SCRUB_STAMP                 LAST_SCRUB_DURATION  SCRUB_SCHEDULING                                          
1.0         2         0          0        0  590368            0           0  413         0  active+clean     9h   27'413   43:1099  [3,5,4]p3  [3,5,4]p3  2024-04-04T23:01:31.874678+0000  2024-04-04T23:01:31.874678+0000                    0  periodic scrub scheduled @ 2024-04-05T23:57:41.643668+0000
...
...
2.1e        0         0          0        0       0            0           0    0         0  active+clean    18m      0'0     43:21  [1,2,0]p1  [1,2,0]p1  2024-04-05T17:34:39.443193+0000  2024-04-05T17:34:39.443193+0000                    0  periodic scrub scheduled @ 2024-04-07T05:09:41.113721+0000
2.1f        0         0          0        0       0            0           0    0         0  active+clean    18m      0'0     43:22  [2,0,1]p2  [2,0,1]p2  2024-04-05T17:34:39.443193+0000  2024-04-05T17:34:39.443193+0000                    0  periodic scrub scheduled @ 2024-04-06T18:34:58.287296+0000

Еще раз посмотрим на состояние кластера и проверим, что все в порядке:

root@node1:~# ceph -s
  cluster:
    id:     6ba7d13c-642b-11ee-b8b2-c70be95e3c50
    health: HEALTH_OK
 
  services:
    mon: 3 daemons, quorum node1,node2,node3 (age 19h)
    mgr: node1.cauksk(active, since 20h), standbys: node2.ecffgz
    osd: 6 osds: 6 up (since 9h), 6 in (since 19h)
 
  data:
    pools:   2 pools, 33 pgs
    objects: 2 objects, 577 KiB
    usage:   267 MiB used, 35 GiB / 35 GiB avail
    pgs:     33 active+clean

Настройка авторизации клиента кластера


Авторизация в Ceph подробно описана в документации. Отмечу, что какой бы тип сервиса или клиента ни использовался, Ceph хранит в себе данные о них в виде объектов RADOS. У каждого из них есть определенный ряд возможностей (caps), а также определен уровень доступа к объектам и пулам хранения. Утилиты Ceph ищут файл с ключом авторизации по пути /etc/ceph/ceph.client.{name}.keyring.

Подготовим пользователя для клиента Nomad CSI:

# создаем клиента nomad с правами, определенными преднастроенным профилем rbd, с полным доступом к пулу nomad.
root@node1:~# ceph auth get-or-create client.nomad mon 'profile rbd' osd 'profile rbd pool=nomad' mgr 'profile rbd pool=nomad'
[client.nomad]
	key = AQA4PxBmD0uiARAAP5M3DrAyNNlr7CjjX6PnNw==

# вывести информацию о настроеных разрешениях клиента можно командой:
root@node1:~# ceph auth get client.nomad
[client.nomad]
	key = AQA4PxBmD0uiARAAP5M3DrAyNNlr7CjjX6PnNw==
	caps mgr = "profile rbd pool=nomad"
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=nomad"

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

Если вам необходимо зашифровать данные, сделать это следует до их отправки в кластер.

Разворачиваем Nomad


Трех узлов, которые у нас есть, недостаточно, чтобы запустить Nomad в кластерном режиме. Но так как мы не собираемся крутить все компоненты инфраструктуры на одних и тех же хостах, запустим Nomad в режиме разработчика на четвертом хосте стенда. Кстати, листинг команд ниже иллюстрирует примеры менеджмента узлов кластера Ceph:

# кластер состоит из трех узлов.
root@node1:~# ceph orch host ls
HOST   ADDR          LABELS  STATUS  
node1  192.168.56.5  _admin          
node2  192.168.56.6                  
node3  192.168.56.7                  


# эта команда разместит ключ администратора на узле кластера node2 и предоставит возможности администратора.
root@node1:~# ceph orch host  label add node2 _admin
Added label _admin to host node2
root@node1:~# ceph orch host ls
HOST   ADDR          LABELS  STATUS  
node1  192.168.56.5  _admin          
node2  192.168.56.6  _admin          
node3  192.168.56.7                  
3 hosts in cluster

# С помощью служебных и пользовательских лейблов можно управлять деплоем сервисов Ceph. Следующая команда запретит размещать любые сервисы Ceph на ноде, кроме OSD. Может быть полезно при обслуживании узла.
root@node1:~# ceph orch host label add node3 _no_schedule 
Added label _no_schedule to host node3

root@node1:~# ceph orch ps node3
NAME   HOST   PORTS  STATUS        REFRESHED  AGE  MEM USE  MEM LIM  VERSION  IMAGE ID      CONTAINER ID  
osd.0  node3         running (3d)    40s ago   3d    42.5M    4096M  18.2.2   7b46ae09e5dc  c20a9a449e32  
osd.3  node3         running (3d)    40s ago   3d    31.2M    4096M  18.2.2   7b46ae09e5dc  5cb04e5d04b4  

root@node1:~# ceph orch ps node2
NAME                 HOST   PORTS             STATUS        REFRESHED  AGE  MEM USE  MEM LIM  VERSION  IMAGE ID      CONTAINER ID  
ceph-exporter.node2  node2                    running (4d)    48s ago   4d    7531k        -  18.2.2   7b46ae09e5dc  518802272a35  
crash.node2          node2                    running (4d)    48s ago   4d    2883k        -  18.2.2   7b46ae09e5dc  5e8b2fba0923  
mgr.node2.ecffgz     node2  *:8443,9283,8765  running (4d)    48s ago   4d     128M        -  18.2.2   7b46ae09e5dc  2b8bb882c8b0  
mon.node2            node2                    running (4d)    48s ago   4d    78.2M    2048M  18.2.2   7b46ae09e5dc  a42e6d5b346e  
node-exporter.node2  node2  *:9100            running (4d)    48s ago   4d    13.3M        -  1.5.0    0da6a335fe13  27be86a587c0  
osd.1                node2                    running (3d)    48s ago   3d    39.4M    4096M  18.2.2   7b46ae09e5dc  d6a3d414084b  
osd.4                node2                    running (3d)    48s ago   3d    27.7M    4096M  18.2.2   7b46ae09e5dc  c2ad3d47caf5  

# При этом сам кластер будет себя отлично чувствовать:
root@node1:~# ceph health detail
HEALTH_OK

Подробнее об управлении хостами, как всегда, написано в документации.

Перейдем к настройке Nomad. Для этого с локального хоста выполним вход на четвертый узел стенда. Установим Nomad и Consul, а также настроим их запуск в режиме разработчика как systemd-сервисы. Обратите внимание: мы разрешаем Nomad запускать контейнеры в привилегированном режиме. Это необходимо для работы Ceph-CSI Node. Consul — это инструмент от Hashicorp, который позволяет искать службы servicemesh и хранить данные в виде key/value.

:~$kitchen login node4

# Установка репозиториев и пакетов Consul/Nomad
root@node4:~# wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
root@node4:~# echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/hashicorp.list
root@node4:~# apt-get update && sudo apt-get install nomad consul
root@node4:~# cat <<EOF >>/etc/systemd/system/consul.service 
[Unit]
Description=consul agent
Requires=network-online.target
After=network-online.target

[Service]
User=root
Group=root
Restart=on-failure
ExecStart=/usr/bin/consul agent -dev
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT

[Install]
WantedBy=multi-user.target
EOF

root@node4:~# cat <<EOF >>/etc/systemd/system/nomad.service 
[Unit]
Description=nomad agent
Requires=network-online.target
After=network-online.target

[Service]
User=root
Group=root
Restart=on-failure
ExecStart=/usr/bin/nomad agent -dev -config=/etc/nomad.d/nomad.hcl
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT

[Install]
WantedBy=multi-user.target
EOF

# скачиваем набор драйверов CNI
root@node4:~# wget https://github.com/containernetworking/plugins/releases/download/v1.4.1/cni-plugins-linux-amd64-v1.4.1.tgz
root@node4:~# mkdir -p /opt/cni/bin && tar -C /opt/cni/bin -xvf ./cni-plugins-linux-amd64-v1.4.1.tgz
# Разрешаем запуск привилегированных контейнеров
root@node4:~# cat >>/etc/nomad.d/nomad.hcl<<EOF
plugin "docker" {
  config {
    allow_privileged = true
  }
}
EOF

# Включаем модуль ядра rbd
root@node4:~# modprobe rbd

root@node4:~# systemctl daemon-reload
root@noed4:~# systemctl start nomad consul

#Проверяем, что все работает.
root@node4:~# consul members
Node   Address         Status  Type    Build   Protocol  DC   Partition  Segment
node4  127.0.0.1:8301  alive   server  1.18.1  2         dc1  default    <all>
root@node4:~# nomad node status
ID        Node Pool  DC   Name   Class   Drain  Eligibility  Status
69e42712  default    dc1  node4  <none>  false  eligible     ready

# Если вы не меняли адресацию в файле kitchen.yml, веб-панель Nomad будет доступна с вашего локального хоста.
Nomad - http://192.168.56.8:4646

Теперь перейдем к настройке коннектора к Ceph. Создадим файлы плагинов Ceph-CSI и запустим их. Нам понадобится информация об адресах сервисов MON и UUID-кластера (поля clusterID, monitors). По сути, мы описываем в этих файлах, из каких контейнеров собрать задания плагинов, какие порты открыть, как подключиться к Ceph, какие драйверы использовать.

Итак, сперва создаем файл ceph-csi-plugin-controller.nomad с таким содержимым:

job "ceph-csi-plugin-controller" {
  datacenters = ["dc1"]
  group "controller" {
    network {
      port "metrics" {}
    }
    task "ceph-controller" {
      template {
        data        = <<EOF
[{
    "clusterID": "6ba7d13c-642b-11ee-b8b2-c70be95e3c50",
    "monitors": [
        "192.168.56.5",
        "192.168.56.6",
        "192.168.56.7"
    ]
}]
EOF
        destination = "local/config.json"
        change_mode = "restart"
      }
      driver = "docker"
      config {
        image = "quay.io/cephcsi/cephcsi:v3.3.1"
        volumes = [
          "./local/config.json:/etc/ceph-csi-config/config.json"
        ]
        mounts = [
          {
            type     = "tmpfs"
            target   = "/tmp/csi/keys"
            readonly = false
            tmpfs_options = {
              size = 1000000 # size in bytes
            }
          }
        ]
        args = [
          "--type=rbd",
          "--controllerserver=true",
          "--drivername=rbd.csi.ceph.com",
          "--endpoint=unix://csi/csi.sock",
          "--nodeid=${node.unique.name}",
          "--instanceid=${node.unique.name}-controller",
          "--pidlimit=-1",
          "--logtostderr=true",
          "--v=5",
          "--metricsport=$${NOMAD_PORT_metrics}"
        ]
      }
      resources {
        cpu    = 500
        memory = 256
      }
      service {
        name = "ceph-csi-controller"
        port = "metrics"
        tags = [ "prometheus" ]
      }
      csi_plugin {
        id        = "ceph-csi"
        type      = "controller"
        mount_dir = "/csi"
      }
    }
  }
}

Затем — файл ceph-csi-plugin-nodes.nomad:

job "ceph-csi-plugin-nodes" {
  datacenters = ["dc1"]
  type        = "system"
  group "nodes" {
    network {
      port "metrics" {}
    }
    task "ceph-node" {
      driver = "docker"
      template {
        data        = <<EOF
[{
    "clusterID": "6ba7d13c-642b-11ee-b8b2-c70be95e3c50",
    "monitors": [
        "192.168.56.5",
        "192.168.56.6",
        "192.168.56.7"
    ]
}]
EOF
        destination = "local/config.json"
        change_mode = "restart"
      }
      config {
        image = "quay.io/cephcsi/cephcsi:v3.3.1"
        volumes = [
          "./local/config.json:/etc/ceph-csi-config/config.json"
        ]
        mounts = [
          {
            type     = "tmpfs"
            target   = "/tmp/csi/keys"
            readonly = false
            tmpfs_options = {
              size = 1000000 # size in bytes
            }
          }
        ]
        args = [
          "--type=rbd",
          "--drivername=rbd.csi.ceph.com",
          "--nodeserver=true",
          "--endpoint=unix://csi/csi.sock",
          "--nodeid=${node.unique.name}",
          "--instanceid=${node.unique.name}-nodes",
          "--pidlimit=-1",
          "--logtostderr=true",
          "--v=5",
          "--metricsport=$${NOMAD_PORT_metrics}"
        ]
        privileged = true
      }
      resources {
        cpu    = 500
        memory = 256
      }
      service {
        name = "ceph-csi-nodes"
        port = "metrics"
        tags = [ "prometheus" ]
      }
      csi_plugin {
        id        = "ceph-csi"
        type      = "node"
        mount_dir = "/csi"
      }
    }
  }
}

Запускаем плагины ceph-csi и проверяем, что все работает:

root@node4:~# nomad job run ceph-csi-plugin-controller.nomad
root@node4:~# nomad job run ceph-csi-plugin-nodes.nomad

root@node4:~# nomad plugin status ceph-csi
ID                   = ceph-csi
Provider             = rbd.csi.ceph.com
Version              = v3.3.1
Controllers Healthy  = 1
Controllers Expected = 1
Nodes Healthy        = 1
Nodes Expected       = 1

Allocations
ID        Node ID   Task Group  Version  Desired  Status   Created    Modified
e191676d  e895f83f  nodes       0        run      running  3m8s ago   2m57s ago
b1224cdf  e895f83f  controller  0        run      running  3m25s ago  3m14s ago

# в веб интерфейсе также появится информация об этих заданиях.
http://192.168.56.8:4646/ui/jobs

Теперь перейдем к volume.hcl. Данный конфигурационный файл описывает размер диска, параметры монтирования, а также где и под какой учетной записью создать сам диск.

root@node4:~# cat ./prom-volume.hcl
id = "ceph-prometheus-volume"
name = "ceph-prometheus-volume"
type = "csi"
plugin_id = "ceph-csi"
capacity_max = "2G"
capacity_min = "1G"

capability {
  access_mode     = "single-node-writer"
  attachment_mode = "file-system"
}

secrets {
  userID  = "nomad"
  userKey = "AQA4PxBmD0uiARAAP5M3DrAyNNlr7CjjX6PnNw=="
}

parameters {
  clusterID = "6ba7d13c-642b-11ee-b8b2-c70be95e3c50"
  pool = "nomad"
  imageFeatures = "layering"
  mkfsOptions = "-t ext4"
}

# Создаем диск.
root@node4:~# nomad volume create ./prom-volume.hcl

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

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

# Собственно, сам файл задания. Подробно все описано в документации Nomad.
root@node4:~# cat ./prometheus.nomad 
job "prometheus-server" {
  datacenters = ["dc1"]
  type        = "service"
  group "prometheus-server" {
    count = 1
    //Наш volume, который описывали выше//
    volume "ceph-prometheus-volume" {
      type      = "csi"
      attachment_mode = "file-system"
      access_mode     = "single-node-writer"
      read_only = false
      source    = "ceph-prometheus-volume"
    }
    //Используем CNI драйвер и мапим порты//
    network {
      mode = "bridge"
      port "prometheus" {
        static = 9090
        to     = 9090
      }
    }
    //Параметры рестарта задания, если что-то идет не так//
    restart {
      attempts = 10
      interval = "5m"
      delay    = "25s"
      mode     = "delay"
    }
    //Настройки самой таски. Имя, драйвер, куда монтировать сетевой диск, из какого образа собрать, какие конфиги прокинуть внутрь, сколько ресурсов выделить//
    task "prometheus-server" {
      driver = "docker"
      volume_mount {
        volume      = "ceph-prometheus-volume"
        destination = "/prometheus"
        read_only   = false
      }

      env {
        MY_ENV_VARS = "HelloWorld"
      }
      config {
        image = "prom/prometheus:latest"
        args  = []
        ports = ["prometheus"]
        volumes = [ "local/prometheus.yml:/etc/prometheus/prometheus.yml" ]
      }
      template {
        data = file("/root/prometheus.yml")
        destination = "local/prometheus.yml"
      }
      resources {
        cpu    = 500
        memory = 256
      }
      service {
        name = "prometheus-server"
        port = "prometheus"
        check {
          path     = "/-/helthy"
          type     = "tcp"
          interval = "10s"
          timeout  = "2s"
        }
      }
    }
  }
}

# Файл конфига Prometheus. Указываем на наш кластер и экспортеры.
root@node4:~# cat prometheus.yml 
global:
  scrape_interval: 10s
  scrape_timeout: 10s
  evaluation_interval: 10s
scrape_configs:
- job_name: node
  honor_timestamps: true
  scrape_interval: 5s
  scrape_timeout: 5s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  enable_http2: true
  http_sd_configs:
  - follow_redirects: true
    enable_http2: true
    refresh_interval: 1m
    url: http://192.168.56.6:8765/sd/prometheus/sd-config?service=node-exporter
- job_name: ceph
  scrape_interval: 5s
  scrape_timeout: 5s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  enable_http2: true
  http_sd_configs:
  - follow_redirects: true
    enable_http2: true
    refresh_interval: 1m
    url: http://192.168.56.6:8765/sd/prometheus/sd-config?service=mgr-prometheus
- job_name: ceph-exporter
  scrape_interval: 5s
  scrape_timeout: 5s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  enable_http2: true
  http_sd_configs:
  - follow_redirects: true
    enable_http2: true
    refresh_interval: 1m
    url: http://192.168.56.6:8765/sd/prometheus/sd-config?service=ceph-exporter

# Ну и, наконец, запускаем задание.
root@node4:~# nomad job run prometheus.nomad 
==> 2024-04-11T22:33:00Z: Monitoring evaluation "16580069"
    2024-04-11T22:33:00Z: Evaluation triggered by job "prometheus-server"
    2024-04-11T22:33:00Z: Evaluation within deployment: "fa62c7ea"
    2024-04-11T22:33:00Z: Allocation "0d02495c" created: node "e895f83f", group "prometheus-server"
    2024-04-11T22:33:00Z: Evaluation status changed: "pending" -> "complete"
==> 2024-04-11T22:33:00Z: Evaluation "16580069" finished with status "complete"
==> 2024-04-11T22:33:00Z: Monitoring deployment "fa62c7ea"
  ✓ Deployment "fa62c7ea" successful
    
    2024-04-11T22:33:18Z
    ID          = fa62c7ea
    Job ID      = prometheus-server
    Job Version = 0
    Status      = successful
    Description = Deployment completed successfully
    
    Deployed
    Task Group         Desired  Placed  Healthy  Unhealthy  Progress Deadline
    prometheus-server  1        1       1        0          2024-04-11T22:43:16Z

Нагляднее всего будет перейти в веб-интерфейс Nomad и посмотреть, как это все работает. Можете удалить это задание, а затем запустить его еще раз. Тем не менее, сам Prometheus будет писать данные в сетевое хранилище, что можно увидеть по росту количества объектов в кластере и числу метрик TSDB.

http://192.168.56.8:4646/ui/jobs
http://192.168.56.8:9090/tsdb-status

root@node1:~# ceph -s
...
  data:
    pools:   2 pools, 33 pgs
    objects: 28 objects, 46 MiB
    usage:   499 MiB used, 35 GiB / 35 GiB avail
    pgs:     33 active+clean
 
  io:
    client:   27 KiB/s wr, 0 op/s rd, 4 op/s wr

Где хранятся настройки Ceph


Раньше все параметры и значения объявлялись в /etc/ceph/ceph.conf. Сейчас от этого подхода отказались, так как файл становится нечитаемым из-за большого количества этих параметров у каждого из сервиса Ceph.

Сейчас настройки принято хранить внутри базы сервисов монитора:

# Команда вернет переопределенные параметры сервисов.
root@node1:~# ceph config dump
WHO     MASK  LEVEL     OPTION                                 VALUE                                                                                      RO
global        advanced  cluster_network                        192.168.56.0/24                                                                            * 
global        basic     container_image                        quay.io/ceph/ceph@sha256:06ddc3ef5b66f2dcc6d16e41842d33a3d7f497849981b0842672ef9014a96726  * 
mon           advanced  auth_allow_insecure_global_id_reclaim  false                                                                                        
mon           advanced  public_network                         192.168.56.0/24                                                                            * 
mgr           advanced  mgr/cephadm/container_init             True                                                                                       * 
mgr           advanced  mgr/cephadm/migration_current          6                                                                                          * 
mgr           advanced  mgr/dashboard/ALERTMANAGER_API_HOST    http://node1:9093                                                                          * 
mgr           advanced  mgr/dashboard/GRAFANA_API_SSL_VERIFY   false                                                                                      * 
mgr           advanced  mgr/dashboard/GRAFANA_API_URL          https://192.168.56.5:3000                                                                  * 
mgr           advanced  mgr/dashboard/PROMETHEUS_API_HOST      http://node1:9095                                                                          * 
mgr           advanced  mgr/dashboard/ssl_server_port          8443                                                                                       * 
mgr           advanced  mgr/orchestrator/orchestrator          cephadm                                                                                      
osd           advanced  osd_memory_target_autotune             true

Для каждой опции есть описание, а также указано, может ли она быть применена «на лету». Если это невозможно, MON самостоятельно уведомит сервис о необходимости перезапуска.

root@node1:~# ceph config help osd_memory_target
osd_memory_target - When tcmalloc and cache autotuning is enabled, try to keep this many bytes mapped in memory.
  (size, basic)
  Default: 4294967296
  Minimum: 939524096
  Maximum:
  Can update at runtime: true
  See also: [bluestore_cache_autotune,osd_memory_cache_min,osd_memory_base,osd_memory_target_autotune]
 
The minimum value must be at least equal to osd_memory_base + osd_memory_cache_min.

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

# Пример использования административного сокета.
root@node1:~# ceph daemon /var/run/ceph/6ba7d13c-642b-11ee-b8b2-c70be95e3c50/ceph-osd.2.asok config show | grep debug_osd
    "debug_osd": "1/5",

root@node1:~# ceph daemon /var/run/ceph/6ba7d13c-642b-11ee-b8b2-c70be95e3c50/ceph-osd.7.asok config set debug_osd 10
{
    "success": ""
}

# Пример использования ceph tell. Применим debug_osd=10 ко всем сервисам.
root@node1:~# ceph tell osd.* injectargs "--debug_osd 10"

Если вы задали какие-то настройки в /etc/ceph/ceph.conf, Ceph не позволит их поменять через базу монитора, так как файл конфигурации имеет больший приоритет.

Обслуживание кластера


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

# Переводим кластер в режим обслуживания.
root@node1:~# ceph orch host maintenance enter node3
Daemons for Ceph cluster 6ba7d13c-642b-11ee-b8b2-c70be95e3c50 stopped on host node3. Host node3 moved to maintenance mode


root@node1:~# ceph orch host ls
HOST   ADDR          LABELS  STATUS       
node1  192.168.56.5  _admin               
node2  192.168.56.6  _admin               
node3  192.168.56.7  _admin  Maintenance  
3 hosts in cluster

root@node1:~# ceph -s
  cluster:
    id:     6ba7d13c-642b-11ee-b8b2-c70be95e3c50
    health: HEALTH_WARN
            1 host is in maintenance mode
            1/3 mons down, quorum node1,node2
            2 osds down
            1 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
            1 host (2 osds) down
            Degraded data redundancy: 124/372 objects degraded (33.333%), 32 pgs degraded
 
  services:
    mon: 3 daemons, quorum node1,node2 (age 17s), out of quorum: node3
    mgr: node2.ecffgz(active, since 7h), standbys: node1.cauksk
    osd: 6 osds: 4 up (since 16s), 6 in (since 5h)
 
  data:
    pools:   2 pools, 33 pgs
    objects: 124 objects, 397 MiB
    usage:   2.2 GiB used, 33 GiB / 35 GiB avail
    pgs:     124/372 objects degraded (33.333%)
             32 active+undersized+degraded
             1  active+undersized
 
  io:
    client:   4.0 KiB/s wr, 0 op/s rd, 0 op/s wr

В выводе команды видим, что кластер в статусе WARN, а чуть ниже причины.

  • Недоступен один сервис монитора MON и нарушен кворум (в идеале сервисов MON должно быть пять, но мало кто делает больше трех. Кстати, их все-таки лучше держать на отдельных узлах, если у вас большая инсталляция).
  • Два сервиса OSD находятся в состоянии down.
  • Один узел в состоянии down.
  • 33% данных в деградированном состоянии (на данный момент в кластере отсутствует часть данных).

Обратите внимание, что клиентский ввод/вывод не остановился. Заглянув в веб-панель Nomad и Prometheus, вы в этом легко убедитесь.

Вернем как было и посмотрим, что произойдет:

# Выводим узел из режима обслуживания.
root@node1:~# ceph orch host maintenance exit node3
Ceph cluster 6ba7d13c-642b-11ee-b8b2-c70be95e3c50 on node3 has exited maintenance mode

# После запуска всех сервисов на узле в кластере запускается процесс восстановления данных
root@node1:~# ceph -s
  cluster:
    id:     6ba7d13c-642b-11ee-b8b2-c70be95e3c50
    health: HEALTH_WARN
            Reduced data availability: 10 pgs peering
 
  services:
    mon: 3 daemons, quorum node1,node2,node3 (age 8s)
    mgr: node2.ecffgz(active, since 7h), standbys: node1.cauksk
    osd: 6 osds: 6 up (since 4s), 6 in (since 6h)
 
  data:
    pools:   2 pools, 33 pgs
    objects: 124 objects, 397 MiB
    usage:   2.5 GiB used, 33 GiB / 35 GiB avail
    pgs:     69.697% pgs not active
             23 peering
             10 active+clean
 
  io:
    client:   1.7 MiB/s rd, 22 op/s rd, 0 op/s wr
    recovery: 685 KiB/s, 0 objects/s

# Через какое-то время node3 догоняет изменения, если они были, и кластер вновь работает.
root@node1:~# ceph -s
  cluster:
    id:     6ba7d13c-642b-11ee-b8b2-c70be95e3c50
    health: HEALTH_OK
 
  services:
    mon: 3 daemons, quorum node1,node2,node3 (age 20s)
    mgr: node2.ecffgz(active, since 7h), standbys: node1.cauksk
    osd: 6 osds: 6 up (since 16s), 6 in (since 6h)
 
  data:
    pools:   2 pools, 33 pgs
    objects: 124 objects, 397 MiB
    usage:   2.2 GiB used, 33 GiB / 35 GiB avail
    pgs:     33 active+clean
 
  io:
    client:   24 KiB/s wr, 0 op/s rd, 3 op/s wr
    recovery: 196 KiB/s, 0 objects/s

А что, если нам надо заменить диск? В первую очередь, отмотаем немного назад и вспомним, каким образом мы развернули сервисы OSD. Мы указали, что используем все незанятые диски кластера. Для того, чтобы новые диски не добавлялись в кластер автоматически, необходимо повесить флаг --unmanaged.

ceph orch apply osd --all-available-devices --unmanaged=true

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

root@node1:~# ceph orch osd rm 0 --replace
Scheduled OSD(s) for removal.
VG/LV for the OSDs won't be zapped (--zap wasn't passed).
Run the `ceph-volume lvm zap` command with `--destroy` against the VG/LV if you want them to be destroyed.

root@node1:~# ceph orch osd rm status
OSD  HOST   STATE     PGS  REPLACE  FORCE  ZAP    DRAIN STARTED AT            
0    node3  draining   32  True     False  False  2024-04-12 15:02:05.987153

Мы ожидали, что все PG на удаляемом OSD будут эвакуированы и диск будет удален, но этого не произошло, так как путей для эвакуации нет. В настройках пула (по умолчанию) Nomad указано, что его размер равен трем. Когда все в порядке, в кластере должно быть минимум три копии данных, а минимальный размер— две копии.

root@node1:~# ceph osd pool ls detail
...
pool 2 'nomad' replicated size 3 min_size 2 crush_rule 1 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 131 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd read_balance_score 1.78

Мы можем обойти это двумя путями. Первый — сменить класс устройства osd.3 на SSD, размещенный на той же ноде. Второй — уменьшить размер пула до двух. Попробуем именно этот вариант, но лишь потому, что классы менять мы уже научились (хотя в проде так, конечно, лучше не делать).

root@node1:~# ceph osd pool set nomad size 2
set pool 2 size to 2

Все PG были удалены. В кластере прошел процесс remap, то есть перераспределение PG:

root@node1:/home/vagrant# ceph -s
  cluster:    id:     6ba7d13c-642b-11ee-b8b2-c70be95e3c50
    health: HEALTH_OK
...
    pgs:     122/372 objects misplaced (32.796%)
             32 active+clean+remapped
             1  active+clean

Удалим разметку, чтобы эмулировать замену диска, на котором был размещен osd.0. Кстати, а какой это диск? Сейчас выясним. Это легко делать с помощью утилиты ceph-volume. Зайдем на node3 и удалим разметку:

root@node3:~# apt install ceph-volume -y
root@node3:~# ceph-volume lvm list
====== osd.0 =======
  [block]       /dev/ceph-28366058-ad51-452c-af65-3a0114b4a2f0/osd-block-d6b1004d-bdfe-4d01-b010-31940432d912
      block device              /dev/ceph-28366058-ad51-452c-af65-3a0114b4a2f0/osd-block-d6b1004d-bdfe-4d01-b010-31940432d912
      block uuid                mkuCJu-wyBv-YiFn-hTlp-tzy5-p503-73Y328
      cephx lockbox secret      
      cluster fsid              6ba7d13c-642b-11ee-b8b2-c70be95e3c50
      cluster name              ceph
      crush device class        
      encrypted                 0
      osd fsid                  d6b1004d-bdfe-4d01-b010-31940432d912
      osd id                    0
      osdspec affinity          all-available-devices
      type                      block
      vdo                       0
      devices                   /dev/sdb

root@node3:~# ceph-volume lvm zap /dev/sdb
--> Zapping: /dev/sdb
--> Zapping lvm member /dev/sdb.

Затем — обновим список доступных устройств:

root@node1:~# ceph orch device ls node3 --refresh
HOST   PATH      TYPE  DEVICE ID                           SIZE  AVAILABLE  REFRESHED  REJECT REASONS                                                           
node3  /dev/sdb  hdd   VBOX_HARDDISK_VBef988c66-7de380c8  6000M  Yes        0s ago                                                                              
node3  /dev/sdc  hdd   VBOX_HARDDISK_VBb42afeb2-1643e145  6000M  No         0s ago     Has a FileSystem, Insufficient space (<10 extents) on vgs, LVM detected

Снимем флаг unmaneged и увеличим размер пула до трех. Видно, что PG в кластере снова «поехали»: в этот раз запустился процесс ребалансировки. Кроме того, пул nomad разъехался равномерно по трем дискам.

root@node1:~# ceph osd df tree class ssd
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME     
-1         0.03415         -   18 GiB  1.4 GiB  763 MiB    4 KiB  625 MiB   16 GiB   7.71  1.00    -          root default  
-7         0.01138         -  5.9 GiB  379 MiB  259 MiB    4 KiB  120 MiB  5.5 GiB   6.32  0.82    -              host node1
 2    ssd  0.00569   1.00000  5.9 GiB  379 MiB  259 MiB    4 KiB  120 MiB  5.5 GiB   6.32  0.82   19      up          osd.2 
-3         0.01138         -  5.9 GiB  714 MiB  252 MiB      0 B  461 MiB  5.2 GiB  11.90  1.54    -              host node2
 1    ssd  0.00569   1.00000  5.9 GiB  714 MiB  252 MiB      0 B  461 MiB  5.2 GiB  11.90  1.54   24      up          osd.1 
-5         0.01138         -  5.9 GiB  295 MiB  251 MiB      0 B   44 MiB  5.6 GiB   4.92  0.64    -              host node3
 0    ssd  0.00569   1.00000  5.9 GiB  295 MiB  251 MiB      0 B   44 MiB  5.6 GiB   4.92  0.64   21      up          osd.0 
                       TOTAL   18 GiB  1.4 GiB  763 MiB  4.2 KiB  625 MiB   16 GiB   7.71

После восстановления размера пула ожидаем вновь равномерного распределения, по 32 PG на OSD.

root@node1:~# ceph osd pool set nomad size 3
set pool 2 size to 3

Опять произошел процесс recovery, все PG восстановились в трех экземплярах:

root@node1:~# ceph osd df tree class ssd
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME     
-1         0.03415         -   18 GiB  1.7 GiB  1.1 GiB    4 KiB  630 MiB   16 GiB   9.85  1.00    -          root default  
-7         0.01138         -  5.9 GiB  484 MiB  380 MiB    4 KiB  104 MiB  5.4 GiB   8.08  0.82    -              host node1
 2    ssd  0.00569   1.00000  5.9 GiB  484 MiB  380 MiB    4 KiB  104 MiB  5.4 GiB   8.08  0.82   32      up          osd.2 
-3         0.01138         -  5.9 GiB  842 MiB  380 MiB      0 B  461 MiB  5.0 GiB  14.04  1.43    -              host node2
 1    ssd  0.00569   1.00000  5.9 GiB  842 MiB  380 MiB      0 B  461 MiB  5.0 GiB  14.04  1.43   32      up          osd.1 
-5         0.01138         -  5.9 GiB  446 MiB  380 MiB      0 B   65 MiB  5.4 GiB   7.43  0.75    -              host node3
 0    ssd  0.00569   1.00000  5.9 GiB  446 MiB  380 MiB      0 B   65 MiB  5.4 GiB   7.43  0.75   32      up          osd.0 
                       TOTAL   18 GiB  1.7 GiB  1.1 GiB  4.2 KiB  630 MiB   16 GiB   9.85                                   
MIN/MAX VAR: 0.75/1.43  STDDEV: 2.97

Кластер перешел в состояние OK, клиентский ввод/вывод не прекращался, задание в NOMAD не падало, хранилище Prometheus не отключалось. Последнее видно на графике метрики и в uptime задания Prometheus:

root@node4:~# nomad alloc exec -it -task prometheus-server 0d02495c /bin/sh
/prometheus $ uptime
 15:51:33 up 3 days,  4:47,  0 users,  load average: 0.33, 0.41, 0.42

Заключение


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

Автор: Иванов Владимир

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js