Строим свое облачное и расширяемое хранилище на базе Ceph

Облачный и расширяемый open-source сервис хранения данных

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

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

Коротко о демонах

OSD (object storage daemon) — в каждой ноде кластера может быть несколько дисков и на каждый диск нужен отдельный демон OSD.

Демоны Ceph OSD сохраняют данные в виде объектов в плоском пространстве имён, то есть без иерархии в виде каталогов. Объекты обладают идентификаторами, бинарными данными и метаданными в виде ключ-значение, которые использует MDS сохраняя владельца файла, время создания, время модификации и так далее. Идентификатор объекта уникален в пределах кластера.

Демон OSD в составе кластера постоянно сообщает о своём статусе - up или down. Если по ряду причин OSD демон не сообщает о своём состоянии, демон монитора периодически сам проверяет статус OSD демонов и уполномочен обновлять кластерную карту и уведомлять других демонов мониторов о состоянии OSD демонов.

Metadata server (MDS) — вспомогательный демон для обеспечения синхронного состояния файлов в точках монтирования CephFS. В один момент времени работает только один MDS в пределах кластера, а другие находятся в режиме ожидания и кто-то станет активным, если текущий MDS упадёт.

Мониторы Ceph (Ceph Monitors) поддерживают главную копию (master copy) кластерной карты (cluster map), по которой клиенты Ceph могут определить расположение всех мониторов, OSD демонов и серверов Metadata (MDS). До того как клиенты начнут что-либо писать или читать у OSD или MDS, они должны впервую очередь связаться с монитором Ceph.

С текущей кластерной картой и алгоритмом CRUSH, клиенты могут вычислить расположение любого объекта. Эта способность позволяет клиентам напрямую общаться с OSD, что является важным аспектом в архитектуре Ceph и его способности к высокой доступности и производительности.

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

Кластерная карта - это комплексная карта. Она состоит из карты мониторов (monitor map), карты OSD (OSD map), карты плейсмент-группы (placement group map) и карты MDS (metadata server map).

Приступим.
Выполняем установку ОС на сервера и базовую настройку сети, также отключаем IPv6 и SElinux.

Установку системы производим на один диск, загрузчик ставим туда же, никаких RAID не собираем (тоже самое касается аппаратного RAID - только RAID 0 (JBOD)).

• Ceph-node-admin [192.168.2.67]
• Ceph-node-mon [192.168.2.68]
• Ceph-node-00 [192.168.2.69]
• Ceph-node-01 [192.168.2.70]
• Ceph-node-02 [192.168.2.71]

Для удобства будем работать по каноническим именам, если нет своего личного DNS-сервера, то не забываем внести соответствующие настройки в файл /etc/hosts на каждом сервере.

192.168.2.67 Ceph-node-admin
192.168.2.68 Ceph-node-mon
192.168.2.69 ceph-node-00
192.168.2.70 ceph-node-01
192.168.2.71 ceph-node-02

Настройка NTP

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

Установим NTP

sudo yum install ntp ntpdate
sudo ntpdate ntp2.stratum2.ru
sudo systemctl enable ntpd.service
sudo systemctl start ntpd.service

Вносим изменения в конфигурационный файл /etc/ntp.conf.

server ntp2.stratum2.ru
server ntp3.stratum2.ru
server ntp4.stratum2.ru
server ntp5.stratum2.ru

disable monitor
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1

Выполним настройку временной зоны, если это не было сделано при установке системы.

Создаем нового пользователя

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

Изменим файл /etc/sudoers на каждом сервере и добавим в него следующую строчку, что позволит выполнять sudo команды без запроса пароля. Либо создадим в папке /etc/sudoers.d/ файл с именем пользователя, в который добавим тоже самое.

echo "{USERNAME} ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph && sudo chmod 0440 /etc/sudoers.d/ceph

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

ssh-keygen

Теперь скопируем его на все используемые сервера.

ssh-copy-id {ceph user}@{hostname}

Например:

ssh-copy-id ceph@ceph-node-admin
ssh-copy-id ceph@ceph-node-mon
ssh-copy-id ceph@ceph-node-00
ssh-copy-id ceph@ceph-node-01
ssh-copy-id ceph@ceph-node-02

Настройка ядра системы

При наличии большого количества OSD, возможно создание огромного количества тредов (threads), особенно в процессе восстановления или же при повторной балансировке. Изменим в Linux значение по умолчанию на необходимое нам.

kernel.pid_max служит для поддержки большего значения тредов (threads). В теории, максимум это - 4,194,303.

Внесем изменения в файл /etc/sysctl.conf, добавив строчку:

kernel.pid_max = 4194303

Применяем параметры “на лету”:

sudo sysctl -p

Настроим правила на файрволле

Для Firewalld

sudo firewall-cmd --zone=public --add-port=6789/tcp --permanent
sudo firewall-cmd --zone=public --add-service=ceph-mon --permanent
sudo firewall-cmd --zone=public --add-service=ceph --permanent
sudo firewall-cmd --reload

Для Iptables

sudo iptables -A INPUT -i {iface} -p tcp -s {ip-address}/{netmask} --dport 6789 -j ACCEPT

Также установим пакет yum-plugin-priorities, чтобы менеджер пакетов устанавливал предпочтительные пакеты.

sudo yum install yum-plugin-priorities

Установка Ceph Storage Cluster с помощью ceph-deploy

Начнем пожалуй с простого. Сделаем кластер с двумя OSD демонами и одним монитором. После достижения статуса active+clean добавим третий OSD демон в уже работающий кластер, а также резервный MDS и несколько мониторов.

Выполним установку ceph-deploy

Установим необходимые пакеты и репозитории:

sudo yum install -y yum-utils && sudo yum-config-manager --add-repo https://dl.fedoraproject.org/pub/epel/7/x86_64/ && sudo yum install --nogpgcheck -y epel-release && sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 && sudo rm /etc/yum.repos.d/dl.fedoraproject.org*

Подключим репозиторий Ceph /etc/yum.repos.d/ceph.repo:

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

Заменим {distro} на наш дистрибутив, в данном случае el7.
Заменим {ceph-release} на стабильную версию Ceph.
На момент написания статьи это infernalis.

После всех этих действий установим пакет ceph-deploy:

sudo yum update && sudo yum install ceph-deploy

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

mkdir ceph-admin
cd ceph-admin

Очень важно!
Не выполняйте команду ceph-deploy с sudo или же от root, если авторизованы под другим пользователем.

На некоторых дистрибутивах, в частности CentOS, при выполнении команды ceph-deploy возможны ошибки, для этого измените параметр Defaults requiretty с помощью sudo visudo в /etc/sudoers.d/ceph на Defaults:ceph !requiretty для того, чтобы ceph-deploy мог подключаться с помощью пользователя ceph и выполнять команды с sudo.

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

ceph-deploy purgedata {ceph-node} [{ceph-node}]
ceph-deploy forgetkeys

Для удаления пакетов:

ceph-deploy purge {ceph-node} [{ceph-node}]

Если выполнялась команда purge, то необходимо переустановить пакеты Ceph.

Создаем кластер Ceph Storage Cluster

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

ceph-deploy new {initial-monitor-node(s)}

Например:

ceph-deploy new ceph-node-mon

После этого в папке появится конфигурационный файл и ключ монитора. Убедитесь в этом.
По умолчанию имя кластера будет ceph. Если вы хотите на одном и том же оборудовании использовать несколько кластеров, то для каждого из них нужно задавать имя, используя ceph-deploy –cluster {cluster-name} new …

Изменим значение по умолчанию для количества реплик в Ceph. По умолчанию значение равно 3, изменим его на 2, чтобы Ceph мог достичь статуса Active+Clean с помощью двух OSD. Добавим следующую строку в директиву [global] файла ceph.conf.

osd_pool_default_size = 3
osd_pool_default_min_size = 2

Зададим значения для плейсмент групп (Placement Groups) и плейсмент групп для размещения (Placement Groups for Placement) в директиве [global]. Для небольших кластеров (менее 5 OSDs) рекомендуется 128 плейсмент группы.

osd_pool_default_pg_num = <n>
osd_pool_default_pgp_num = <n>

• менее 5 OSD - значение pg_num и pgp_num ставим 128;
• от 5 до 10 OSD - значение pg_num и pgp_num ставим 512;
• от 10 до 50 OSD - значение pg_num и pgp_num ставим 4096;
• от 50 OSD и выше параметры pg_num и pgp_num рассчитываем по следующей формуле:

             (OSDs * 100)
Total PGs =  ------------
              pool size

osd_pool_default_size значение, которое мы устанавливали на предыдущем шаге.

Установим максимальное количество плейсмент груп на OSD. По умолчанию это значение равно 300. Несколько пулов могут использовать один и тот же набор правил CRUSH. Когда OSD имеют слишком много плейсмент групп это может сказаться на производительности.

mon_pg_warn_max_per_osd

Установка типа CRUSH для отказоустойчивости. По умолчанию это значение равно 1. Если мы хотим сделать как минимум для 3-х объектов реплики, то необходимо изменить параметр на 3.

osd_crush_chooseleaf_type = 3

• Тип 0 - osd
• Тип 1 - host
• Тип 2 - chassis
• Тип 3 - rack
• Тип 4 - row
• Тип 5 - pdu
• Тип 6 - pod
• Тип 7 - room
• Тип 8 - datacenter
• Тип 9 - region
• Тип 10 - root

Установим max_open_files для того чтобы задать максимальное значение открытых дескрипторов файлов на уровне ОС:

max_open_files = 131072

XATTR параметры используются с файловой системой ext4 для улучшения производительности.

filestore_xattr_use_omap = true

Как уже и говорилось в начале статьи, рекомендуется правильная настройка времени на сервере.

mon_clock_drift_allowed = .15
mon_clock_drift_warn_backoff = 30
mon_osd_down_out_interval = 300
mon_osd_report_timeout = 300

Установим full_ratio и near_full_ratio на приемлемые значения. Полную мощность на 95% и почти заполненную на 85%.

mon_osd_full_ratio = .75
mon_osd_nearfull_ratio = .65
osd_backfill_full_ratio = .65

Пример ceph.conf

[global]
fsid = {cluster-id}
mon initial members = {hostname}[, {hostname}]
mon host = {ip-address}[, {ip-address}]

#All clusters have a front-side public network.
#If you have two NICs, you can configure a back side cluster 
#network for OSD object replication, heart beats, backfilling,
#recovery, etc.
public network = {network}[, {network}]
#cluster network = {network}[, {network}] 

#Clusters require authentication by default.
auth cluster required = cephx
auth service required = cephx
auth client required = cephx

#Choose reasonable numbers for your journals, number of replicas
#and placement groups.
osd journal size = {n}
osd pool default size = {n}  # Write an object n times.
osd pool default min size = {n} # Allow writing n copy in a degraded state.
osd pool default pg num = {n}
osd pool default pgp num = {n}

#Choose a reasonable crush leaf type.
#0 for a 1-node cluster.
#1 for a multi node cluster in a single rack
#2 for a multi node, multi chassis cluster with multiple hosts in a chassis
#3 for a multi node cluster with hosts across racks, etc.
osd crush chooseleaf type = {n}

Если на сервере имеется и используется больше одного сетевого интерфейса, то добавим public_network в секцию [global] конфигурационного файла Ceph. ( Подробнее о сетевой конфигурации )

Установим Ceph:

ceph-deploy install {ceph-node}[{ceph-node} ...]

Например:

ceph-deploy install ceph-node-admin ceph-node-mon ceph-node-00 ceph-node-01

В процессе установки может появиться следующая ошибка:

[ceph-node-admin][WARNIN] warning: /etc/yum.repos.d/ceph.repo created as /etc/yum.repos.d/ceph.repo.rpmnew
[ceph-node-admin][WARNIN] ensuring that /etc/yum.repos.d/ceph.repo contains a high priority
[ceph_deploy][ERROR ] RuntimeError: NoSectionError: No section: 'ceph'

Устраняем проблему командой:

sudo mv /etc/yum.repos.d/ceph.repo /etc/yum.repos.d/ceph-deploy.repo

Настройка CRUSH карты с SSD кэшированием

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

osd_crush_update_on_start = false

Сохраним текущую карту и переведем её в текстовый формат:

ceph osd getcrushmap -o map.running
crushtool -d map.running -o map.decompile

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable straw_calc_version 1

# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
device 6 osd.6
device 7 osd.7
device 8 osd.8
device 9 osd.9
device 10 osd.10
device 11 osd.11
device 12 osd.12

# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root

# buckets
host ceph-node-00-ssd-cache {
    id -2       # do not change unnecessarily
    # weight 5.659
    alg straw
    hash 0  # rjenkins1
    item osd.0 weight 1.000
}
host ceph-node-01-ssd-cache {
    id -3       # do not change unnecessarily
    # weight 16.550
    alg straw
    hash 0  # rjenkins1
    item osd.1 weight 1.000
}
host ceph-node-02-ssd-cache {
    id -4       # do not change unnecessarily
    # weight 5.659
    alg straw
    hash 0  # rjenkins1
    item osd.2 weight 1.000
}

host ceph-node-00-hdd {
    id -102     # do not change unnecessarily
    # weight 5.659
    alg straw
    hash 0  # rjenkins1
    item osd.11 weight 1.000
    item osd.12 weight 1.000
}
host ceph-node-01-hdd {
    id -103     # do not change unnecessarily
    # weight 16.550
    alg straw
    hash 0  # rjenkins1
    item osd.3 weight 1.000
    item osd.4 weight 1.000
    item osd.5 weight 1.000
    item osd.6 weight 1.000
    item osd.7 weight 1.000
    item osd.8 weight 1.000
}
host ceph-node-02-hdd {
    id -104     # do not change unnecessarily
    # weight 5.659
    alg straw
    hash 0  # rjenkins1
    item osd.9 weight 1.000
    item osd.10 weight 1.000
}

root ssd-cache {
    id -1       # do not change unnecessarily
    # weight 27.868
    alg straw
    hash 0  # rjenkins1
    item ceph-node-00-ssd-cache weight 5.659
    item ceph-node-01-ssd-cache weight 16.550
    item ceph-node-02-ssd-cache weight 5.659
}

root hdd {
    id -100     # do not change unnecessarily
    # weight 27.868
    alg straw
    hash 0  # rjenkins1
    item ceph-node-00-hdd weight 5.659
    item ceph-node-01-hdd weight 16.550
    item ceph-node-02-hdd weight 5.659
}

# rules
rule ssd-cache {
    ruleset 0
    type replicated
    min_size 1
    max_size 10
    step take ssd-cache
    step chooseleaf firstn 0 type host
    step emit
}

rule hdd {
    ruleset 1
    type replicated
    min_size 1
    max_size 10
    step take hdd
    step chooseleaf firstn 0 type host
    step emit
}
# end crush map

Обратите внимание на то, что я создал два root для SSD и HDD, а также два правила ruleset.

Скомпилируем обратно и запустим CRUSH-карту

crushtool -c map.decompile -o map.new
ceph osd setcrushmap -i map.new

Добавим первоначальные мониторы и соберем ключи

Для обеспечения высокой доступности необходимо запустить Ceph как минимум с 3-мя мониторами. Ceph использует алгоритм, который требует консенсуса среди большинства мониторов в кворуме.
Подсчет мониторов осуществляется приблизительно следующим образом: 1:1, 2:3, 3:4, 3:5, 4:6, etc. Необязательно, но желательно, чтобы количество мониторов в кластере было нечётным числом для улучшения работы алгоритма Paxos при сохранении кворума.

В идеале, разработчики Ceph советуют ноды-мониторы не совмещать с нодами OSD, так как мониторы активно используют fsync() и это пагубно влияет на производительность OSD.

ceph-deploy mon create-initial

После выполнения данного процесса в локальной директории ceph-admin проверим наличие всех ключей:

{cluster-name}.client.admin.keyring
{cluster-name}.bootstrap-osd.keyring
{cluster-name}.bootstrap-mds.keyring
{cluster-name}.bootstrap-rgw.keyring

Например:

[ceph@ceph-node-admin ceph-admin]$ ls -lah
total 228K
drwxrwxr-x. 2 ceph ceph 4.0K Feb 29 13:30 .
drwx------. 4 ceph ceph 4.0K Feb 29 12:46 ..
-rw-------  1 ceph ceph   71 Feb 29 13:30 ceph.bootstrap-mds.keyring
-rw-------  1 ceph ceph   71 Feb 29 13:30 ceph.bootstrap-osd.keyring
-rw-------  1 ceph ceph   71 Feb 29 13:30 ceph.bootstrap-rgw.keyring
-rw-------  1 ceph ceph   63 Feb 29 13:30 ceph.client.admin.keyring
-rw-rw-r--  1 ceph ceph  260 Feb 29 13:12 ceph.conf
-rw-rw-r--. 1 ceph ceph 180K Feb 29 13:30 ceph.log
-rw-------  1 ceph ceph   73 Feb 29 13:11 ceph.mon.keyring

Добавление OSD

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

Добавление и удаление OSD демонов в кластер может занимать несколько шагов, особенно если используется запись на диск и в журнал.

Для листинга дисков ноды используем следующую команду:

ceph-deploy disk list {node-name [node-name]...}

Например:

[ceph@ceph-node-admin ceph-admin]$ ceph-deploy disk list ceph-node-00
[ceph_deploy.conf][DEBUG ] found configuration file at: /home/ceph/.cephdeploy.conf
[ceph_deploy.cli][INFO  ] Invoked (1.5.31): /usr/bin/ceph-deploy disk list ceph-node-00
[ceph_deploy.cli][INFO  ] ceph-deploy options:
[ceph_deploy.cli][INFO  ]  username                      : None
[ceph_deploy.cli][INFO  ]  verbose                       : False
[ceph_deploy.cli][INFO  ]  overwrite_conf                : False
[ceph_deploy.cli][INFO  ]  subcommand                    : list
[ceph_deploy.cli][INFO  ]  quiet                         : False
[ceph_deploy.cli][INFO  ]  cd_conf                       : <ceph_deploy.conf.cephdeploy.Conf instance at 0xfa61b8>
[ceph_deploy.cli][INFO  ]  cluster                       : ceph
[ceph_deploy.cli][INFO  ]  func                          : <function disk at 0xf9ac08>
[ceph_deploy.cli][INFO  ]  ceph_conf                     : None
[ceph_deploy.cli][INFO  ]  default_release               : False
[ceph_deploy.cli][INFO  ]  disk                          : [('ceph-node-00', None, None)]
[ceph-node-00][DEBUG ] connection detected need for sudo
[ceph-node-00][DEBUG ] connected to host: ceph-node-00 
[ceph-node-00][DEBUG ] detect platform information from remote host
[ceph-node-00][DEBUG ] detect machine type
[ceph-node-00][DEBUG ] find the location of an executable
[ceph_deploy.osd][INFO  ] Distro info: CentOS Linux 7.2.1511 Core
[ceph_deploy.osd][DEBUG ] Listing disks on ceph-node-00...
[ceph-node-00][DEBUG ] find the location of an executable
[ceph-node-00][INFO  ] Running command: sudo /usr/sbin/ceph-disk list
[ceph-node-00][DEBUG ] /dev/dm-0 other, xfs, mounted on /
[ceph-node-00][DEBUG ] /dev/dm-1 swap, swap
[ceph-node-00][DEBUG ] /dev/sda :
[ceph-node-00][DEBUG ]  /dev/sda2 other, LVM2_member
[ceph-node-00][DEBUG ]  /dev/sda1 other, xfs, mounted on /boot
[ceph-node-00][DEBUG ] /dev/sdb other, unknown
[ceph-node-00][DEBUG ] /dev/sdc other, unknown
[ceph-node-00][DEBUG ] /dev/sr0 other, unknown

Затираем диски

Определившись с дисками затираем все данные на них (в т.ч. таблицу разделов) и подготовим для использования Ceph.

ceph-deploy disk zap {osd-server-name}:{disk-name}

Например:

ceph-deploy disk zap ceph-node-00:sdb ceph-node-00:sdc ceph-node-01:sdb ceph-node-01:sdc

Подготовим диски

Разработчики Ceph рекомендуют использовать файловую систему XFS. ( см. Ceph Docs ), поэтому позаботьтесь о том, чтобы пакет xfsprogs был установлен на всех нодах кластера.

При подготовке дисков ceph-deploy автоматически форматирует диски в XFS. Если установка производится на разделы, то отформатировать его можно командой sudo mkfs.xfs -i size=512 /dev/sdX.

ceph-deploy osd prepare {node-name}:{data-disk}[:{journal-disk}]
ceph-deploy osd prepare osdserver1:sdb:/dev/ssd
ceph-deploy osd prepare osdserver1:sdc:/dev/ssd

ceph-deploy osd prepare ceph-node-00:sdb ceph-node-00:sdc ceph-node-01:sdb ceph-node-01:sdc

После создания кластера и установки Ceph пакетов, а также создания ключей, можем выполнить подготовку OSD и развернуть их на OSD нодах. Команда prepare только подготовит OSD!

Активация OSD

После успешной подготовки дисков активируем OSD. (Обратите внимание, что необходимо указать разделы диска.)

ceph-deploy osd activate {node-name}:{data-disk-partition}[:{journal-disk-partition}]
ceph-deploy osd activate osdserver1:sdb1:/dev/ssd1
ceph-deploy osd activate osdserver1:sdc1:/dev/ssd2

Например:

ceph-deploy osd activate ceph-node-00:sdb1:/dev/sdb2 ceph-node-00:sdc1:/dev/sdc2 ceph-node-01:sdb1:/dev/sdb2 ceph-node-01:sdc1:/dev/sdc2

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

ceph-deploy osd create ceph-node-00:sdb1:/dev/sdb2 ceph-node-00:sdc1:/dev/sdc2 ceph-node-01:sdb1:/dev/sdb2 ceph-node-01:sdc1:/dev/sdc2

Скопируем ключи и конфигурационный файл на ноды:

ceph-deploy admin {admin-node} {ceph-node}

Например:

ceph-deploy admin ceph-node-admin ceph-node-mon ceph-node-00 ceph-node-01

Убедимся в корректных привилегиях ceph.client.admin.keyring:

sudo chmod +r /etc/ceph/ceph.client.admin.keyring

Проверяем состояние:

ceph status

Получаем статус Ceph:

[ceph@ceph-node-admin ceph-admin]$ ceph status
    cluster ca89dd68-e6d7-4f62-b947-62abcc111ac0
     health HEALTH_OK
     monmap e1: 1 mons at {ceph-node-mon=192.168.2.68:6789/0}
            election epoch 2, quorum 0 ceph-node-mon
     osdmap e19: 5 osds: 4 up, 4 in
            flags sortbitwise
      pgmap v48: 64 pgs, 1 pools, 0 bytes data, 0 objects
            133 MB used, 61262 MB / 61395 MB avail
                  64 active+clean

При получении предупреждения, например:

[ceph@ceph-node-admin ceph-admin]$ ceph status
    cluster fb82947c-7b0d-4b7d-8bd9-c0386f48c152
     health HEALTH_WARN
            64 pgs stuck inactive
            64 pgs stuck unclean
            too few PGs per OSD (16 < min 30)
     monmap e1: 1 mons at {ceph-node-mon=192.168.2.68:6789/0}
            election epoch 1, quorum 0 ceph-node-mon
     osdmap e13: 4 osds: 4 up, 4 in
            flags sortbitwise
      pgmap v18: 64 pgs, 1 pools, 0 bytes data, 0 objects
            130 MB used, 61265 MB / 61395 MB avail
                  64 creating

Ищем решение Ceph Troubleshooting.

Создание OSD с SSD кэшированием

ceph osd pool create ssd-cache 128
ceph osd pool set ssd-cache min_size 1
ceph osd pool set ssd-cache size 2
ceph osd pool create one 512
ceph osd pool set one min_size 1
ceph osd pool set one size 2

ceph osd pool set ssd-cache crush_ruleset 0
ceph osd pool set one crush_ruleset 1

ceph osd tier add one ssd-cache
ceph osd tier cache-mode ssd-cache writeback
ceph osd tier set-overlay one ssd-cache

# Включаем фильтр bloom
ceph osd pool set ssd-cache hit_set_type bloom
# Сколько обращений к объекту что бы он считался горячим
ceph osd pool set ssd-cache hit_set_count 4
# Сколько времени объект будет считаться горячим
ceph osd pool set ssd-cache hit_set_period 1200

# Сколько байтов должно заполниться прежде чем включится механизм очистки кэша
ceph osd pool set ssd-cache target_max_bytes 200000000000
# Процент заполнения хранилища, при котором начинается операция промывания
ceph osd pool set ssd-cache cache_target_dirty_ratio 0.4
# Процент заполнения хранилища, при котором начинается операция выселения
ceph osd pool set ssd-cache cache_target_full_ratio 0.8 
# Минимальное количество времени прежде чем объект будет промыт
ceph osd pool set ssd-cache cache_min_flush_age 300 
# Минимальное количество времени прежде чем объект будет выселен
ceph osd pool set ssd-cache cache_min_evict_age 300

К сожалению OSD автоматически в конфигурационный файл не запишутся. Кроме того даже после записи в конфигурацию автоматическое монтирование этих точек тоже не работает.
Чтобы поднять OSD демон при загрузке необходим файл ключ, который лежит на не примонтированном разделе. Поэтому дополняем конфигурационный файл ceph.conf:

...
[osd.0]
host = ceph-node-00

[osd.1]
host = ceph-node-00

[osd.2]
host = ceph-node-01

[osd.3]
host = ceph-node-01

Кроме этого смотрим на каждом узле где есть osd:

mount | grep ceph
...
/dev/sdc1 on /var/lib/ceph/osd/ceph-2 type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sdb1 on /var/lib/ceph/osd/ceph-1 type xfs (rw,relatime,attr2,inode64,noquota)

Добавляем записи в /etc/fstab для надежности:

/dev/sdb1 /var/lib/ceph/osd/ceph-1 rw,noatime,attr2,inode64,noquota
/dev/sdc1 /var/lib/ceph/osd/ceph-2 rw,noatime,attr2,inode64,noquota

Перезаписываем конфигурацию:

ceph-deploy --overwrite-conf admin ceph-node-admin ceph-node-mon ceph-node-00 ceph-node-01

На текущем моменте у нас есть кластер с единственным и пока не настроенным пулом.

ceph osd lspools

Получаем:

0 rbd,

RBD можно считать некоторым аналогом жесткого диска на котором необходимо будет нарезать разделы.
Например для Opennebula потребуется три пула: files, system и images.

ceph osd pool create images 64 64

Цифра в конце команды - количество PG и PGP для пула. Можно считать, что PG это минимальный реплицирующийся кусок пространства, в которое мы можем запихнуть обьект (файл) или кусок от него. PGP - максимальное количество PG групп для пула.
По мануалам есть формула общего количество PG (указано выше): ((количество OSD)100)/(osd pool default size). То есть 3100/2 = 150. полученное число ещё необходимо округлить вверх до степени двойки - то есть у нас получается 256. Делим это число на количество пулов, округляем вверх до степени 2 - получаем искомую настройку. 256/2 (system,rbd)=128.

Получаем информацию о плейсмент группах:

ceph osd pool get rbd pg_num
pg_num: 64

Задаем значения PG вручную:

ceph osd pool set rbd pg_num 512
ceph osd pool set rbd pgp_num 512

Ceph находится в зависимости от Ceph клиентов и Ceph OSD демонов, будучи осведомленных о кластерной топологии, которые включают в себя 5 отдельных карт, коллективно называемых как “Cluster Map”:

1. Монитор: Содержит FSID кластера, положение, адреса и порт каждого монитора. Он так же указывает на текущую версию сервера монитора, когда карта была создана и когда в последний раз изменялась. Чтобы просмотреть карту монитора необходимо выполнить команду: ceph mon dump

2. OSD: Содержит FSID кластера, когда карта была создана и последние изменения, список пулов, размер репликаций, количество PGs, список OSD и их текущее состояние. Для просмотра OSD карты необходимо выполнить команду: ceph osd dump

3. PG: Содержит версию PG, его метки времени, последнию версию OSD, полные соотношения и подробную информацию о каждой группе размещения, такие как PG ID, состояние PG (например active+clean) и т.д. Для просмотра PG карты необходимо выполнить команду: ceph pg dump

4. CRUSH: Содержит список устройств хранения, отказоустойчивую иерархию домена (device,host,rack,row,room,datacenter) и правила для иерархий при хранений данных. Для просмотра структуры CRUSH алгоритма необходимо выполнить команду: ceph osd tree

5. MDS: Содержит текущую MDS версию карты, когда карта была создана и когда в последний момент изменялась. Так же содержится pool для хранения метаданных, список серверов метаданных и какие сервера включены и выключены. Для просмотра MDS карты, необходимо выполнить ceph mds dump

Терминология

Metadata server (MDS) — вспомогательный демон для обеспечения синхронного состояния файлов в точках монтирования CephFS. Работает по схеме активная копия + резервы, причем активная копия в пределах кластера только одна.

Mon (Monitor) — элемент инфраструктуры Ceph, который обеспечивает адресацию данных внутри кластера и хранит информацию о топологии, состоянии и распределении данных внутри хранилища. Клиент, желающий обратиться к блочному устройству rbd или к файлу на примонтированной cephfs, получает от монитора имя и положение rbd header — специального объекта, описывающего положение прочих объектов, относящихся к запрошенной абстракции (блочное устройство или файл) и далее общается со всеми OSD, участвующими в хранении файла.

Объект (Object) — блок данных фиксированного размера (по умолчанию 4 Мб). Вся информация, хранимая в Ceph, квантуется такими блоками. Чтобы избежать путаницы подчеркнем — это не пользовательские объекты из Object Storage, а объекты, используемые для внутреннего представления данных в Ceph.

OSD (object storage daemon) — сущность, которая отвечает за хранение данных, основной строительный элемент кластера Ceph. На одном физическом сервере может размещаться несколько OSD, каждая из которых имеет под собой отдельное физическое хранилище данных.

Карта OSD (OSD Map) — карта, ассоциирующая каждой плейсмент-группе набор из одной Primary OSD и одной или нескольких Replica OSD. Распределение placement groups (PG) по нодам хранилища OSD описывается срезом карты osdmap, в которой указаны положения всех PG и их реплик. Каждое изменение расположения PG в кластере сопровождается выпуском новой карты OSD, которая распространяется среди всех участников.

Плейсмент-группа (Placement Group, PG) — логическая группа, объединяющая множество объектов, предназначенная для упрощения адресации и синхронизации объектов. Каждый объект состоит лишь в одной плейсмент группе. Количество объектов, участвующих в плейсмент-группе, не регламентировано и может меняться.

Primary OSD — OSD, выбранная в качестве Primary для данной плейсмент-группы. Клиентское IO всегда обслуживается той OSD, которая является Primary для плейсмент группы, в которой находится интересующий клиента блок данных (объект). rimary OSD в асинхронном режиме реплицирует все данные на Replica OSD.

RADOS Gateway (RGW) — вспомогательный демон, исполняющий роль прокси для поддерживаемых API объектных хранилищ. Поддерживает географически разнесенные инсталляции (для разных пулов, или, в представлении Swift, регионов) и режим active-backup в пределах одного пула.

Replica OSD (Secondary) — OSD, которая не является Primary для данной плейсмент-группы и используется для репликации. Клиент никогда не общается с ними напрямую.

Фактор репликации (RF) — избыточность хранения данных. Фактор репликации является целым числом и показывает, сколько копий одного и того же объекта хранит кластер.

Список используемых материалов

1. http://docs.ceph.com/docs/master/start/quick-ceph-deploy/
2. https://access.redhat.com/documentation/en/red-hat-ceph-storage/
3. http://onreader.mdl.ru/LearningCeph/content/index.html
4. http://tracker.ceph.com/
5. https://habrahabr.ru/company/performix/blog/218065/
6. Channel #ceph on irc.oftc.net/6667