ceph - полезные команды

Thank you for reading this post, don't forget to subscribe!

Основные термины

OSD (Object Storage Daemon) - устрой­ство хра­не­ния объ­ек­тов в Ceph. Обра­ба­ты­ва­ет такие состо­я­ния PG как replicationrecoverybackfillingrebalancing. Так же предо­став­ля­ет инфор­ма­цию для мони­то­рин­га Ceph. Как пра­ви­ло, один демон OSD соот­вет­ству­ет одно­му физи­че­ско­му диску.

Mon (Monitor) - отсле­жи­ва­ет состо­я­ние все­го кла­сте­ра путём хра­не­ния кар­ты состо­я­ния кла­сте­ра, вклю­чая кар­ты OSDPG и CRUSH.

MDS (Metadata Server) - хра­нит мета­дан­ные фай­ло­вой систе­мы CephFSMDS дела­ет воз­мож­ным обра­ба­ты­вать запро­сы поль­зо­ва­те­лей POSIX-фай­ло­вой систе­мы, не нагру­жая кластер.

CRUSH Map - содер­жит спи­сок OSD и buckets для объ­еди­не­ния OSD, а так же спи­сок пра­вил, кото­рые гово­рят CRUSH, как он дол­жен реп­ли­ци­ро­вать дан­ные в пулах кла­сте­ра Ceph.

Primary OSD - OSD устрой­ство, кото­рое обра­ба­ты­ва­ет запро­сы от клиентов.

Replica OSD - OSD устрой­ство, кото­рое исполь­зу­ет­ся толь­ко для созда­ния реплик от Primary OSD.

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

PG (Placement Groups) - груп­па раз­ме­ще­ния или логи­че­ская кол­лек­ция объ­ек­тов в Ceph, кото­рые реп­ли­ци­ру­ют­ся в OSD. Одна груп­па может сохра­нять дан­ные на несколь­ко OSD, в зави­си­мо­сти уров­ня слож­но­сти систе­мы. Фор­му­ла для вычис­ле­ния групп раз­ме­ще­ния для Ceph следующая:

При этом резуль­тат дол­жен быть округ­лён до бли­жай­шей сте­пе­ни двой­ки (напри­мер, по фор­му­ле = 700, после округ­ле­ния = 512).

PGP (Placement Group for Placement purpose) - груп­пы раз­ме­ще­ния для целей рас­по­ло­же­ния. Коли­че­ство долж­но быть рав­ным обще­му чис­лу групп размещения.

Pool - логи­че­ский раз­дел для хра­не­ния объ­ек­тов. Каж­дый пул содер­жит опре­де­лён­ное коли­че­ство групп раз­ме­ще­ния, кото­рые содер­жат объ­ек­ты кла­сте­ри­зо­ван­ные на OSD. Кон­цеп­ция пула обес­пе­чи­ва­ет устой­чи­вость. При созда­нии пула мож­но выбрать толь­ко один тип доступ­но­сти дан­ных - репли­ка­ции или коды уда­ле­ния. Пул при запи­си дан­ных руко­вод­ству­ет­ся набо­ра­ми пра­вил CRUSH.

RADOS (Reliable Autonomic Distributed Object Store) - без­от­каз­ное авто­ном­ное рас­пре­де­лён­ное хра­ни­ли­ще объ­ек­тов. Име­ет воз­мож­ность мас­шта­би­ро­ва­ния до одной тыся­чи устройств путем исполь­зо­ва­ния про­грамм­но­го обес­пе­че­ния на каж­дом из отдель­ных узлов хранения.

RBD (RADOS Block Device) - про­грамм­ное обес­пе­че­ние с откры­тым исход­ным кодом для хра­не­ния дан­ных на осно­ве блоч­но­го устрой­ства в рас­пре­де­лен­ных систе­мах хранения.

CephFS (Ceph File System) - фай­ло­вая систе­ма, сов­ме­сти­мая с POSIX (Portable Operating System Interface), исполь­зу­ю­щая для хра­не­ния дан­ных кла­стер CephCephFS исполь­зу­ет для хра­не­ния блоч­ные устрой­ства CBD (Ceph Block Device) осно­ван­ные на RBD.

Состояния Placement Groups

  • Active - в этом состо­я­нии Ceph может обра­ба­ты­вать запро­сы к этой группе.
  • Backfill - ска­ни­ро­ва­ние и син­хро­ни­за­ция все­го содер­жи­мо­го PG без исполь­зо­ва­ния жур­на­ла опе­ра­ций. Это част­ный слу­чай восстановления.
  • Backfill-toofull - состо­я­ние backfill в ожи­да­нии, пото­му что OSD назна­че­ния име­ет высо­кий коэф­фи­ци­ент заполнения.
  • Clean - дан­ные груп­пы раз­ме­ще­ния реп­ли­ци­ро­ва­лись нуж­ное коли­че­ство раз.
  • Creating - состо­я­ние созда­ния группы.
  • Degraded - PG име­ет нере­п­ли­ци­ро­ван­ные данные.
  • Down - отсут­ству­ет репли­ка с необ­хо­ди­мы­ми данными.
  • Incomplete - состо­я­ние в кото­ром Ceph обна­ру­жил в PG отсут­ству­ю­щую инфор­ма­цию о запи­си или “боль­ные” копии объекта.
  • Inconsistent - обна­ру­же­ны несо­от­вет­ствия в одной или несколь­ких репли­ках объ­ек­та в PG.
  • Recovering - син­хро­ни­за­ция объ­ек­тов и их реплик.
  • Repair - про­вер­ка груп­пы на несо­от­вет­ствия и вос­ста­нов­ле­ние най­ден­ных несо­от­вет­ствий, если это возможно.
  • Replay - груп­па ждёт кли­ен­тов, что­бы повто­рить опе­ра­ции после крэ­ша OSD.
  • Peered - состо­я­ние, в кото­ром PG не может обра­бо­тать запро­сы кли­ен­та, так как не име­ет доста­точ­но реплик объект.
  • Peering - про­цесс при­ве­де­ния всех OSD одной груп­пы раз­ме­ще­ния в согла­ше­ние о состо­я­нии всех объ­ек­тов и их мета­дан­ных в этой PG.
  • Remapped - PG вре­мен­но отоб­ра­жа­ет­ся в дру­гие OSD, в отли­чие от тех, что ука­за­ны в кар­ту CRUSH.
  • Scrubbing - PG про­ве­ря­ет­ся на несоответствия.
  • Splitting - состо­я­ние рас­щеп­ле­ния одной PG на несколь­ко PG.
  • Stale - PG нахо­дит­ся в неиз­вест­ном состо­я­нии, так как мони­то­ры не полу­чи­ли обнов­ле­ния от неё и её отоб­ра­же­ние изменилось.
  • Undersized - PG содер­жит мень­ше копий, чем уста­нов­лен­ный раз­мер пула.
  • Wait-backfill - в оче­ре­ди на состо­я­ние backfill.

Порядок обновления Ceph

  1. Мони­тор
  2. OSD
  3. MDS
  4. Шлюз RADOS

Информационные команды

Отобразить дерево OSD

Отобразить черный список клиентов

Отобразить текущие значения PG и PGP

Отобразить информацию о размере реплики

Отобразить существующие пулы

Показать карту OSD для объектов пула

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

Проверить состояние кластера (live-режим)

Проверить статус мониторов

Проверить статус мониторов

Отобразить список дисков

Отобразить статистику кластера

Отобразить список ключей авторизации

Отобразить состояние мониторов

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

Отобразить карту CRUSH

Отобразить состояние PG

Отобразить состояние MDS

Команды модификации кластера

Создать блочное устройство RADOS

Изменить размер устройства RBD


смот­рим все rbd:
rbd ls
после изме­ня­ем размер:
rbd resize --size 2048 monitor_influx
Resizing image: 100% complete…done.
Смот­рим как назы­ва­ет­ся наша rbd
df -h | grep influx
/dev/rbd13           1.0G  961M  916M  100% /var/lib/docker/plugins/01f2c3bdcc5ec7fc609f26a6a9c60ba613f16c45d6716b34db6c7f1c469bf780/propagated-mount/volumes/monitor_influx

пере­чи­ты­ва­ем её размер:
[root@bl8-swarmnode1-146-11 ~]# resize2fs /dev/rbd13
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/rbd13 is mounted on /var/lib/docker/plugins/01f2c3bdcc5ec7fc609f26a6a9c60ba613f16c45d6716b34db6c7f1c469bf780/propagated-mount/volumes/monitor_influx; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1

The filesystem on /dev/rbd13 is now 524288 blocks long.

Всё ок, проверяем:
df -h | grep influx
/dev/rbd13           2.0G  961M  916M  52% /var/lib/docker/plugins/01f2c3bdcc5ec7fc609f26a6a9c60ba613f16c45d6716b34db6c7f1c469bf780/propagated-mount/volumes/monitor_influx

Установить новые значения PG и PGP для пула

Создать новый пул

Создать моментальный снепшот пула

Переименовать пул

Установить новый уровень репилкации (по умолчанию = 3)

что­бы кон­фи­гу­ра­ция при­ме­ни­лась, необ­хо­ди­мо попра­вить кон­фиг файл на ноде отку­да про­из­во­ди­лась установка:
/var/ceph-admin/ceph.conf доба­вив строку:
osd pool default size = 2
после чего выпол­нить команду:
[ceph@node1 ceph-admin]$ ceph-deploy --overwrite-conf config push node1 node2 node3

и выпол­ним сле­ду­ю­щие команды:
[root@node1 ceph-admin]# ceph osd pool set ИМЯ_ПУЛА size 2
[root@node1 ceph-admin]# ceph osd pool set ИМЯ_ПУЛА min_size 1

после чего пере­за­пус­ка­ем все сер­ви­сы на нодах:
systemctl restart ceph\*.service
systemctl restart ceph\*.target

Так­же запускаем:
systemctl status rbdmap.service

Удалить OSD из карты CRUSH

Удалить ключ авторизации OSD

Исключить OSD из кластера

Полное удаление OSD из кластера

В иде­а­ле мы хотим, что­бы все OSD были оди­на­ко­вы­ми с точ­ки зре­ния про­из­во­ди­тель­но­сти и мощ­но­сти, но это не все­гда воз­мож­но. Когда OSD отли­ча­ют­ся по сво­им клю­че­вым атри­бу­там, исполь­зуй­те ceph osd crush reweight, что­бы изме­нить их вес в CRUSH кар­те, что­бы кла­стер был пра­виль­но сба­лан­си­ро­ван, а OSD раз­ных типов полу­чи­ли пра­виль­но настро­ен­ное коли­че­ство запро­сов ввода/вывода и данных.

Распределение места на ceph:

Име­ет­ся кла­стер, мы делим его попо­лам с пра­ви­ла­ми дробления(crush map), 116/2 = 58, с репли­кой 4, 58/4 = 14,5. Таким обра­зом, у вас оста­ёт­ся 13 для данных.