Облачный и расширяемый 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)).
Для удобства будем работать по каноническим именам, если нет своего личного 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 сервера на каждой ноде. Это очень важный шаг, поскольку большинство проблем может возникнуть именно из-за некорректной настройки времени.
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 |
Начнем пожалуй с простого. Сделаем кластер с двумя OSD демонами и одним монитором. После достижения статуса active+clean добавим третий OSD демон в уже работающий кластер, а также резервный MDS и несколько мониторов.
Установим необходимые пакеты и репозитории:
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-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> |
pg_num и pgp_num ставим 128;pg_num и pgp_num ставим 512;pg_num и pgp_num ставим 4096;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
|
Установим 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 |
В файле конфигурации 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 демонов в кластер может занимать несколько шагов, особенно если используется запись на диск и в журнал.
Для листинга дисков ноды используем следующую команду:
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. (Обратите внимание, что необходимо указать разделы диска.)
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.
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”:
ceph mon dumpceph osd dumpactive+clean) и т.д. Для просмотра PG карты необходимо выполнить команду: ceph pg dumpceph osd treeceph mds dumpMetadata 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) — избыточность хранения данных. Фактор репликации является целым числом и показывает, сколько копий одного и того же объекта хранит кластер.