Глава 7. Мониторинг Ceph

Мониторинг является процессом выборки, сбора и обработки важной значимой информации о некоторой заданной системе. Он позовляет нам понимать общую жизнеспособность (health) данной системы и ей компонентов, а также предоставляет необходимую информацию чтобы предпринять шаги для поиска и устранения возникающих проблем. Система с достойным мониторингом позволит нам знать когда что- то разрушится или будет близко к этому. Оснащение некоторого кластера вовлекает в некий танец оркестрации вокруг сотен, тысяч и даже десятков тысяч взаимодействующих компонентов, включающих разнообразие ядер, процессов, устройств хранения, контроллеров (HBA), сетевых карт (NIC), шасси, коммутаторов, источников электропитания и тому подобного. Каждый из этих компонентов может отказать или деградировать своим собственным, уникальным образом.

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

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

Компоненты и службы сторонних производителей часто предоставляют их собственные средства взаимодействия с мониторингом. Промышленные кластеры Ceph обычно обслуживают большое множество клиентов. Имеющиеся разновидности таких клиентов разнятся в зависимости от того применяются ли образы RBD, тома CephFS и некие серверы Объектного хранения, либо же всё это вместе. Каждая среда развёртывания имеет различные требования относительно надёжности, которые в первую очередь зависят от самого варианта применения. Некоторые кластеры Ceph применяются преимущественно для внутренних клиентов и SLA (Service Level Agreement, Оглашения об уровне обслуживания) с менее чем 99% времени работы может быть достаточно. Прочие обслуживают пользователей, являющихся внешними исполнителями/ потребителями, которые платят за обеспечение более высоких надёжности и времени непрерывной работы. Имеются также кластеры с оснащением смешанных разновидностей клиентов с отдельными уровнями SLA. Также имеются варианты применения Ceph на различных типах систем клиентов, что слишком избыточно для охвата данной главой, поэтому мы не будем пускаться в подробности мониторинга на стороне клиента здесь.

При мониторинге системы Ceph мы в первую очередь будем эксплуатировать внутренние инструменты CLI, которые предоставляются обычными пакетами Ceph. Такие инструменты доступны в качестве подкоманд основной утилиты ceph и выводят отчёты в свой стандартный вывод (stdout). Данные отчёты могут предлагать огромные возможности подробностей и обычно предоставляют обильную информацию в помощь проблемам диагностирования имеющегося состояния вашего кластера, однако не всегда предоставляют всё что требуется для тщательного RCA (root-cause analysis, Анализа основных причин).

По этой причине рекомендуется полагаться на прочие утилиты диагностики, которые предоставляют ваши дистрибутив Linux или производители оборудования. Мы затрагивали некоторые из этих команд Ceph и внешних утилит в предыдущих главах. Жизненно важно добавить к такому особенному для Ceph мониторингу чтобы мы отслеживали основные состояния аппаратуры -- ЦПУ, модулей памяти, NIC, контроллеров устройств, источников электропитания и тому подобного. Мы можем выполнять это посредством самой операционной системы с помощью инструментов, включающих в свой состав mcelog, rsyslog и ipmitool, либо напрямую с помощью возможностей контроллеров управления сервером (BMC) с применением IPMI, Redfish или ловушек SNMP. Некоторые платформы предлагают также богатые проприетарные инструменты, включающие API XML в UCS Cisco. Ваша уже имеющаяся инфраструктура, несомненно, уже эксплуатирует один из таких подходов к могиторингу оборудования и ваша система Ceph должна вставиться прямо в них.

Проверка жизнеспособности является одной из наиболее общих и важных команд, которую системные администраторы Ceph будут часто применять чтобы быть в курсе всех основных проблем. Вывод проверки жизнеспособности даёт некий быстрый обзор на 40 000 футов по поводу того, что ваш кластер работает нормально или он деградировал. Если кластер не является жизнеспособным (uhealthy), мы можем применить ту же самую команду чтобы получить подробный обзор того в чём состоит проблема. Даже хотя она и не всегда способна сообщить нам в чём в точности состоит проблема, мы можем применять её почти в любом случае чтобы сузить сферу обзора и сосредоточить своё исследование на очень определённой области.

Для проверки жизнеспособности своего кластера мы применяем подкоманду health имеющейся утилиты ceph.

root@ceph-client0:~# ceph health
HEALTH_OK
		

Если кластер жизнеспособен, его состоянием будет HEALTH_OK. Во всех прочих случаях команда предоставит некое состояние HEALTH_WARN или HEALTH_ERR с последующим кратким суммированием основных лежащих в основе проблем данного кластера. Ведутся разговоры о введении дополнительных состояний в последующих версиях Ceph, однако когда мы пишем эти строки, их всего три.

Переключатель --format json испускает вывод в формате JSON. Детали простого и прочих форматов могут отличаться, поэтому убедитесь что вы понимаете этот вывод, прежде чем отправлять его для синтаксического анализа.

В настоящее время Ceph делает для нас доступными следующие форматы вывода:

Некий не жизнеспособный кластер, например, может выглядеть следующим образом:

root@ceph-client0:~# ceph health
HEALTH_WARN 71 pgs degraded; 67 pgs stuck unclean; 71 pgs undersized; recovery 57/573 objects degraded (9.948%); mds cluster is degraded; 1/6 in osds are down
		

Самое первое словом в нашем выводе (HEALTH_WARN) указывает текущее состояние жизнеспособности данного кластера. Относительно выпуска кластера Ceph Jewel, значение жизнеспособности некоторого кластера Ceph может быть только в трёх состояниях:

Давайте исследуем свой вывод приводимой выше команды слегка более подробно, расщепляя полученный вывод по отличительным симптомам. Каждый симптом отделяется точкой с запятой {;}.

Всякий кластер строится и настраивается своим собственным способом, причём с различным числом OSD и уникальными установками пула. Таким образом, все приведённые выше проблемы могут не передаваться один-к-одному в вашей установке; мы предоставили их здесь исключительно для некоторого эталонного примера. Однако, если ваш кластер отображает HEALTH_WARN, это означает, что вам необходимо рассмотреть её, даже если эта проблема кажется временной по своей природе.

Существуют и другие подкоманды, которые мы можем применять для отображения имеющегося текущего состояния некоторого кластера Ceph, особо отметим состояние (-s). Полученный вывод этой команды в процессе приведённой выше деградации отображается следующим образом:

root@ceph-client0:~# ceph status
cluster e6d4e4ab-f59f-470d-bb76-511deebc8de3
health HEALTH_WARN
71 pgs degraded
67 pgs stuck unclean
71 pgs undersized
recovery 57/573 objects degraded (9.948%)
1/6 in osds are down
monmap e1: 1 mons at {ceph-mon0=192.168.42.10:6789/0}
election epoch 5, quorum 0 ceph-mon0
fsmap e10989: 1/1/1 up {0=ceph-mds0=up:active}
osdmap e4165: 6 osds: 5 up, 6 in; 71 remapped pgs
flags sortbitwise,require_jewel_osds
pgmap v10881: 128 pgs, 9 pools, 3656 bytes data, 191 objects
1570 MB used, 63763 MB / 65333 MB avail
57/573 objects degraded (9.948%)
71 active+undersized+degraded
57 active+clean
client io 15433 B/s rd, 14 op/s rd, 0 op/s wr
		

Мы обсудим этот вывод своей команды состояния более подробно далее в этой главе.

Иногда полезно вытащит подробную информацию о жизнеспособности кластера. Мы можем передать имеющийся флаг детализации чтобы увидеть исчерпывающий отчёт о деградации. Это особенно полезно когда состояние Ceph выдаёт отчёт о медленных/ блокированных запросах, так как с первого взгляда мы можем определить являются ли они системными, или ограничены определённым OSD:

root@ceph-client0:~# ceph health detail
HEALTH_WARN 71 pgs degraded; 67 pgs stuck unclean; 71 pgs undersized; recovery 57/573 objects degraded (9.948%); 1/6 in osds are down
pg 0.f is stuck unclean for 358.447499, current stateactive+undersized+degraded, last acting [3,2]
pg 8.7 is stuck unclean for 514634.143404, current state active+undersized+degraded, last acting [2,3]
pg 8.6 is stuck unclean for 358.625153, current state active+undersized+degraded, last acting [2,3]
pg 0.d is stuck unclean for 362.888847, current state active+undersized+degraded, last acting [4,3]
pg 8.5 is stuck unclean for 358.446944, current state active+undersized+degraded, last acting [3,2]
pg 0.a is stuck unclean for 362.888290, current state active+undersized+degraded, last acting [4,3]
...
pg 0.38 is active+undersized+degraded, acting [0,4]
pg 0.37 is active+undersized+degraded, acting [3,2]
pg 0.34 is active+undersized+degraded, acting [4,3]pg 0.33 is active+undersized+degraded, acting [4,0]
pg 7.4 is active+undersized+degraded, acting [0,4]
...
recovery 57/573 objects degraded (9.948%)
osd.1 is down since epoch 4160, last address 192.168.42.100:6800/11356
		

Мы уже обсудили некоторое резюме общего итога своего приведённого выше примера вывода. Теперь мы исследуем общий остаток вывода, разбив его вниз на следующие фрагменты:

Мы можем определить переключатель -s в своей утилите ceph чтобы отслеживать события в реальном времени. Мы можем отслеживать все типы сообщений, включая debug (DBG), info (INF), warn (WRN), error (ERR) и security (SEC). Вывод будет непрерывно печататься, по мере того как происходят события пока мы не завершим этот процесс.

root@ceph-client0:~# ceph -w
cluster e6d4e4ab-f59f-470d-bb76-511deebc8de3
health HEALTH_OK
monmap e1: 1 mons at {ceph-mon0=192.168.42.10:6789/0}
election epoch 5, quorum 0 ceph-mon0
fsmap e15527: 1/1/1 up {0=ceph-mds0=up:active}
osdmap e6264: 6 osds: 6 up, 6 in
flags sortbitwise,require_jewel_osds
pgmap v16377: 128 pgs, 9 pools, 3656 bytes data, 191 objects
2102 MB used, 63231 MB / 65333 MB avail
128 active+clean
2017-09-16 23:39:10.225183 mon.0 [INF] pgmap v16377: 128 pgs: 128 active+clean; 3656 bytes data, 2102 MB used, 63231 MB / 65333 MB avail
2017-09-16 23:40:28.009152 mon.0 [INF] osd.1 marked itself down
2017-09-16 23:40:28.087948 mon.0 [INF] osdmap e6265: 6 osds: 5 up, 6 in
2017-09-16 23:40:28.101414 mon.0 [INF] pgmap v16378: 128 pgs: 128 active+clean; 3656 bytes data, 2102 MB used, 63231 MB / 65333 MB avail
2017-09-16 23:40:29.111695 mon.0 [INF] osdmap e6266: 6 osds: 5 up, 6 in
2017-09-16 23:40:32.152057 mon.0 [INF] pgmap v16381: 128 pgs: 71 active+undersized+degraded, 67 active+clean; 3656 bytes data, 2100 MB used, 63233 MB / 65333 MB avail; 57/573 objects degraded (9.948%)
		

Имеющаяся серъёзность для событий знакома тем, кто работал с syslog. Тяжесть DBG является наинизшим уровнем, а ERR самым высоким. Если мы определяем текущим уровень DBG (и в неявном виде все более высокие уровни) при просмотре событий, мы будем отслеживать всё что происходит в нашем кластере. По умолчанию значением для событий устанавливается INF, который выше чем DBG и, таким образом, мы видим весь поток событий за исключением отладочных записей.

Ниже приводятся те уровни, которые мы можем добавлять для построения отчётов о событиях:

Вы можете опознать установленную преамбулу своего вывода ceph -w, также как и для своей команды ceph status

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

root@ceph-client0:~# ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
65333M 63376M 1957M 3.00
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
rbd 0 0 0 21113M 0
cephfs_data 1 0 0 21113M 0
cephfs_metadata 2 2068 0 21113M 20
.rgw.root 3 1588 0 21113M 4
default.rgw.control 4 0 0 21113M 8
default.rgw.data.root 5 0 0 21113M 0
default.rgw.gc 6 0 0 21113M 32
default.rgw.log 7 0 0 21113M 127
default.rgw.users.uid 8 0 0 21113M 0
		

Подкоманда df предоставляет состояние загруженности в двух разделах, глобальном и для каждого пула. Некий отдельный кластер Ceph может иметь множество пулов для служб RBD, RGW и CephFS, причём каждую со своим собственным уровнем использования.

Имеющиеся в разделе GLOBAL колонки предоставляют следующее:

Колонки из раздела POOLS отображают:

Целостный обзор очень важен, в особенности при предсказании роста для всего нашего кластера и планировании расширения. Временами мы можем также захотеть проверить насколько ровно имеющиеся данные внутренне распределены внутри этого кластера и насколько много содержит каждый OSD. Начинающиеся с Hammer выпуски Ceph предоставляют бесценную подкоманду osd df для отображения имеющегося внутреннего распределения, которая делает для нас возможным заметить когда один или более OSD имеют большую ёмкость и, таким образом, рабочую нагрузку. Она аналогична команде Linux df, применяемой для статистик обычной файловой системы.

root@ceph-client0:~# ceph osd df
ID WEIGHT REWEIGHT  SIZE  USE  AVAIL %USE  VAR PGS
0 0.01039 1.00000 10888M 325M 10563M 2.99 1.00 57
3 0.01039 1.00000 10888M 323M 10565M 2.97 0.99 71
1 0.01039 1.00000 10888M 332M 10556M 3.05 1.02 71
5 0.01039 1.00000 10888M 325M 10563M 2.99 1.00 57
2 0.01039 1.00000 10888M 326M 10562M 3.00 1.00 71
4 0.01039 1.00000 10888M 326M 10562M 3.00 1.00 57
TOTAL 65333M 1959M 63374M 3.00
MIN/MAX VAR: 0.99/1.02 STDDEV: 0.03
		

Мы также можем видеть что все OSD почти не задействованы (примерно по 1% каждый) и примерно в равной степени. Давайте обсудим ниже все колонки представленного вывода:

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

Расхождение (variance, отклонение) в использовании OSD критически важно при определении того требуется или нет повторное взвешивание одного или более OSD для выравнивания рабочей нагрузки. Обоснованное единообразное распределение Групп размещения, а таким образом и данных, по всем OSD также важно для тог, чтобы выбросы выделений, значительно превышающие их совместное использование не становились полными. В данном разделе мы объясним данное явление и то, как его отслеживать. В Главе 6, Работа и сопровождение мы уже описывали некий подход для выравнивания неравномерного распределения; здесь мы изучим почему оно происходит и как выравнивать пороговые значения, отвечающие вашим локальным потребностям.

Отклонение для некоторых OSD может увеличиваться когда объекты не выделяются неким сбалансированным образом по всем Группам размещения. Имеющийся алгоритм CRUSH разработан с тем, чтобы воспринимать все Группы размещения как равные и тем самым выполнять распределение на основе количества Групп размещения и веса OSD, однако обычно это не отвечает запросам реального мира. Рабочие нагрузки стороны клиента не осведомлены о Группах размещения и их распространению в кластере; они знают только об объектах S3 или образах блоков RBD. Таким образом, в зависимости от установленного названий конкретных лежащих в основе объектов RADOS, которые составляют все объекты S3 или блочные образы RBD более высокого уровня, эти объекты могут получать соответствие меньшему набору Групп размещения, которые совместно содержат меньший набор OSD. Если такое случается, те OSD, в которых находятся эти Группы размещения, показывают более высокое отклонение и, следовательно, скорее всего более сразу и большую амплитуду ёмкости чем остальные. Итак, нам необходимо отслеживать те OSD, которые демонстрируют значительно более низкие отклонения продолжительное время. Это означает, что такие OSD не извлекают свой вес и должны быть исследованы на предмет того, почему это происходит. OSD, которые имеют отклонение равное или близкое к 1.0 могут рассматриваться как пребывающие в своём оптимальном состоянии.

Веса CRUSH отражают ёмкость устройства, в то время как упомянутое в предыдущей главе повторное взвешивание действует как некое переопределение (или обманный множитель) для обеспечения сбалансированности распределения Групп размещения. Ceph имеет настраиваемые пределы, которые позволяют нам управлять объёмом пространства, подлежащего использованию внутри некоторого OSD и предпринимать действия при достижении этих пределов. Двумя основными параметрами являются mon_osd_nearfull_ratio и mon_osd_full_ratio. Соотношение nearfull действует как предупреждающее; OSD, которые переходят это пороговое значение приводят в результате к тому, что общее состояние кластера Ceph изменяется в HEALTH_WARN с HEALTH_OK. Значение соотношения full предоставляет некий жёсткий порог, выше которого ввод/ вывод клиента не может осуществляться на данный диск, пока его использование не упадёт ниже такой пороговой установки. Эти значения по умолчанию установлены в 85% и 95% от общей ёмкости диска, соответственно.

Жизненно важно отметить, что в отличии от большинства установок Ceph, все скомпилированные значения по умолчанию и любые изменения в ceph.conf предоставляют начальные значения. Однако, когда некий кластер проходит сквозь множество обновлений карты OSD, соотношения nearfull и full в имеющейся карте Групп размещения перезаписываются в их первоначальные значения. Чтобы обеспечить, что установленные пороги всегда соблюдаются для всех устройств в пределах всего кластера, нам необходимо гарантировать, что те значения, которые мы настроили для соотношений nearfull и full соответствуют имеющимся в карте Групп размещения. Мы можем устанавливать такие значения карт Групп размещения следующим образом:

root@ceph-client0:~# ceph pg set_nearfull_ratio 0.85
root@ceph-client0:~# ceph pg set_full_ratio 0.95
		

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

Проверка состояние кластера находится среди самых частых задач любого администратора Ceph; действительно, как и вождение с ручной коробкой передач оно быстро становится рефлексивным. Такое соединение ласточкиным хвостом с необходимой проверкой жизнеспособности мы обсудили ранее. Общее состояние всего кластера может быть проверено путём применения следующей подкоманды ceph status или заменяющего её переключателя -s.

root@ceph-client0:~# ceph status
cluster e6d4e4ab-f59f-470d-bb76-511deebc8de3
health HEALTH_OK
monmap e1: 1 mons at {ceph-mon0=192.168.42.10:6789/0}
election epoch 5, quorum 0 ceph-mon0
fsmap e15527: 1/1/1 up {0=ceph-mds0=up:active}
osdmap e6279: 6 osds: 6 up, 6 in
flags sortbitwise,require_jewel_osds
pgmap v16658: 128 pgs, 9 pools, 3656 bytes data, 191 objects
1962 MB used, 63371 MB / 65333 MB avail
128 active+clean
		

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

Если данный кластер имеет исполняющееся восстановление или ввод/ вывод клиента, это будет отображено как две дополнительные строки в самом конце.

Обычно мы применяем команду состояния для обзора перемещений состояния Групп размещения когда мы выполняем изменения внутри данного кластера, например, изменение взвешивания OSDв процессе некоторых сопроводительных работ или при добавлении новых OSD или хостов. При таком сценарии лучше открыть какое- то выделенное окно, которое непрерывно обновляется с такой информацией критических состояний, вместо того, чтобы мы периодически обновляли текущее отображение изменений в состоянии кластера. По умолчанию watch будет исполнять данную команду каждые 2 секунды, отображая некий временной штамп в своём право верхнем углу. Этот временной штамп сам по себе имеет значение. Если мы заметим, что его значение не обновляется должным образом, скорее всего что наши узлы Монитора кластера испытывают проблемы.

$ watch ceph status
		

Ceph предоставляет аутентификацию с типом Kerberos для всех своих клиентов и демонов данного кластера с применением протокола cephx. Каждая сущность, которая взаимодействует с прочими компонентами кластера нуждается во взаимодействии с использованием своих соответствующих ключей. Любой Монитор может осуществлять аутентификацию некоторого клиента на основании того ключа, который он предоставляет, затем отправляет ему некий ключ сеанса для использования при общении с прочими процессами внутри данного кластера, например, с OSD. Когда данный сеанс истекает, данным клиентам требуется вновь аутентифицироваться в этом кластере прежде чем они смогут возобновить общение с OSD. Общий перечень ключей, которые аутентифицированные клиенты могут применять извлекается с помощью подкоманды auth list.

root@ceph-client0:~# ceph auth list
installed auth entries:
client.admin
key: AQBSdLVZN8DNDBAAIwIhHp/np5uUk9Rftzb5kg==
caps: [mds] allow *
caps: [mon] allow *
caps: [osd] allow *
client.bootstrap-mds
key: AQBSdLVZIC0yMhAAmRka3/+OpszwNPNSXuY5nQ==
caps: [mon] allow profile bootstrap-mds
client.bootstrap-osd
key: AQBSdLVZ99T2FxAAIj54OM3qAVxeLz+ECF3CyA==
caps: [mon] allow profile bootstrap-osd
client.bootstrap-rgw
key: AQBSdLVZPUiDIhAAAPCNfNceDU3eGSvrwYNQUg==
caps: [mon] allow profile bootstrap-rgw
client.restapi
key: AQBUdLVZFVdQLhAA/PxeXrWDHP9c8dtY3Mu2sA==
caps: [mon] allow *
caps: [osd] allow *
client.rgw.ceph-rgw0
key: AQBldrVZ8OmfBhAAw8Uxu3tKJ2uz5OvdR8nu/A==
caps: [mon] allow rw
caps: [osd] allow rwx
		

Подобающий кластер Ceph представлен тремя или более демонами Монитора, в идеале расположенных в различных физических серверах. Как это уже обсуждалось в Главе 4, Планирование вашего развёртывания, множество мониторов рекомендуется для гарантии устойчивости к отказам и сопровождаемости. Если Мониторы кластера не могут сформировать некий кворум, что случается когда недостаточное общее число предоставленных Мониторов является поднятыми (up), тогда новые клиенты не смогут подключаться к данной системе. Что ещё хуже, уже имеющиеся клиенты больше не будут иметь возможности выполнять операции после истечения срока их сеансов. Для жизнеспособности кластера первостепенно иметь большинство Мониторов поднятыми (up) и способными выполнять свои обязанности кворума.

Мы можем извлекать основную информацию обо всех Мониторах в нашем кластере исполняя подкоманду mon stat утилиты ceph. Если наш кластер содержит MON, которые отключены (down) или недоступны и таким образом были временно выбиты из кворума, данная команда выдаст нам предупреждение о данной ситуации с тем, чтобы мы смогли разрешить её.

root@ceph-client0:~# ceph mon stat
e1: 1 mons at {ceph-mon0=192.168.42.10:6789/0}, election epoch 5, quorum 0 ceph-mon0
		

Если нам необходима более подробная информация об имеющемся состоянии карты Мониторов всего кластера, мы можем воспользоваться подкомандой mon dump.

root@ceph-client0:~# ceph mon dump
dumped monmap epoch 1
epoch 1
fsid e6d4e4ab-f59f-470d-bb76-511deebc8de3
last_changed 2017-09-10 20:20:16.458985
created 2017-09-10 20:20:16.458985
0: 192.168.42.10:6789/0 mon.ceph-mon0
		

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

Само понятие кворума является фундаментальным для всех алгоритмов согласования, которые разрабатываются для доступа к информации в неких устойчивых к отказам распределённых системах. Самое минимальное число голосов, необходимое для достижения согласия внутри некоторого набора узлов именуется неким кворумом. Все они должны прийти к согласию в имеющемся общем порядке действий и синхронно регистрировать эти действия. Следовательно, некий активный кворум узлов MON важен для достижения развития. Чтобы сохранять некий кластер в рабочем состоянии, имеющийся кворум (или большинство) узлов MON необходимо для представления в наличии на протяжении всего времени. Математически это означает, что нам потребуется (n/2)+1 узлов MON доступными всё время, где n является общим числом предоставленных Мониторов. Например, если у нас имеется 5 мониторов, нам понадобится по крайней мере (5/2)+1 = 3 Монитора доступными на протяжении всего времени. Ceph рассматривает все Мониторы эквивалентными при проверке большинства и таким образом любые три работающих монитора в приведённом выше примере будут квалифицированы как создающие необходимый кворум.

Мы можем получить состояние кворума своего кластера воспользовавшись имеющейся подкомандой quorum_status своего проверенного ножа Швейцарской армии - утилиты ceph.

root@ceph-client0:~# ceph quorum_status
{
"election_epoch": 6,
"quorum": [
0
],
"quorum_names": [
"ceph-mon0"
],
"quorum_leader_name": "ceph-mon0",
"monmap": {
"epoch": 1,
"fsid": "e6d4e4ab-f59f-470d-bb76-511deebc8de3",
"modified": "2017-09-10 20:20:16.458985",
"created": "2017-09-10 20:20:16.458985",
"mons": [
{
"rank": 0,
"name": "ceph-mon0",
"addr": "192.168.42.10:6789/0"
}
]
}
}
		

Данный вывод отображён в формате JSON. Давайте обсудим далее все поля:

OSD являются рабочими лошадками внутри кластера Ceph; они отвечают за выполнение всей необходимой работы по сохранению и управлению данных клиента. Мониторинг OSD имеет решающее значение, хотя и является сложным из- за их присутствия, как правило, в большом количестве. Данная задача относительно проста в кластерах с очень маленьким размером, при всего лишь от 5 до 10 OSD, но ещё более важна, в особенности, если требуется высокая доступность и долговечность. Мы рассмотрим те команды Ceph, которые доступны для мониторинга OSD.

Если нам требуется быстро взглянуть на текущее состояние и доступность всех OSD, мы будем применять имеющуюся подкоманду osd tree. Эта команда обычно является второй по использованию (или злоупотребляемой) после команды ceph status.

root@ceph-client0:~# ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.06235 root default
-2 0.02078 host ceph-osd1
0 0.01039 osd.0 up 1.00000 1.00000
3 0.01039 osd.3 up 1.00000 1.00000
-3 0.02078 host ceph-osd0
1 0.01039 osd.1 up 1.00000 1.00000
5 0.01039 osd.5 up 1.00000 1.00000
-4 0.02078 host ceph-osd2
2 0.01039 osd.2 up 1.00000 1.00000
4 0.01039 osd.4 up 1.00000 1.00000
		

Давайте далее окунёмся чуть более в предложенном выше выводе колонки и их частности:

Может быть более простым в некотором небольшом кластере определять путём инспекции какой OSD относится к какому хосту. Внутри какого- то кластера большего размера составленного из сотен и тысяч OSD, расположенных в десятках серверов быстрая изоляция некоторой проблемы в определённом хосте при отказе какого- то OSD значительно сложнее и таким образом, её ценность снижается. Ceph снабжает нас подкомандой osd find, которая делает действительно несложной идентификацию того, к какому хосту относится отказавший OSD.

root@ceph-client0:~# ceph osd find 1
{
"osd": 1,
"ip": "192.168.42.100:6802\/4104",
"crush_location": {
"host": "ceph-osd0",
"root": "default"
}
}
		

Данная команда принимает на ввод численные значения идентификатора OSD и печатает некий список важных полей в виде JSON вывода.

Данные счётчики, предоставляющие поднятые (up) и отключённые (down) OSD доступны через подкоманду osd stat, что отображено следующим образом:

root@ceph-client0:~# ceph osd stat
osdmap e7785: 6 osds: 6 up, 6 in
flags sortbitwise,require_jewel_osds
		

Заметим, что приведённая выше информация в точности та же самая, что и представляется в ceph health status, который мы описывали ранее в данной главе. Такой вывод состояния Ceph полезен при визуальном отслеживании проблем, однако если мы желаем обособить только основные состояния OSD, osd stat может оказаться более удобной.

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

Мы можем воспользоваться osd crush dump для отображения всей имеющейся карты CRUSH.

root@ceph-client0:~# ceph osd crush dump
{
"devices": [
{
"id": 0,
"name": "osd.0"
},
...
"rules": [
{
"rule_id": 0,
"rule_name": "replicated_ruleset",
"ruleset": 0,
...
"tunables": {
"choose_local_tries": 0,
"choose_local_fallback_tries": 0,
"choose_total_tries": 50,
"chooseleaf_descend_once": 1,
...
		

Это может быть не всегда полезным в зависимости от искомой информации. Лучшим способом является дамп персональных правил с применением подкоманды osd crush rule dump.

Вначале мы выводим перечень всех правил CRUSH определённых в настоящий момент внутри нашего кластера:

root@ceph-client0:~# ceph osd crush rule ls
[
"replicated_ruleset"
]
		

В данном случае у нас имеется одно правило, и оно имеет название replicated_ruleset. Давайте посмотрим что оно делает.

root@ceph-client0:~# ceph osd crush rule dump replicated_ruleset
{
"rule_id": 0,
"rule_name": "replicated_ruleset",
"ruleset": 0,
"type": 1,
"min_size": 1,
"max_size": 10,
"steps": [
{
"op": "take",
"item": -1,
"item_name": "default"
},
{
"op": "chooseleaf_firstn",
"num": 0,
"type": "host"
},
{
"op": "emit"
}
]
}
		

Данное правило применяется к пулам с репликацией и распространяет одну копию всех объектов в отдельные хосты. Для дополнительных подробностей того как работают наборы правил, пожалуйста, обратитесь к разделу Персонализация CRUSH в Главе 8, Архитектура Ceph: под капотом.

Объекты Ceph сопоставляются с отдельными и уникальными Группами размещения (PG, placement groups), которые сохраняются в OSD. Вся жизнеспособность имеющегося кластера зависит от текущего состояния и жизнеспособности этих Групп размещения, причём как персонально, так и сообща. Если некая Группа размещения деградирует, тогда это оказывает воздействие на жизнеспособность её кластера, даже несмотря на то, что все остальные Группы размещения могут быть жизнеспособными и не испытывать проблем с вводом/ выводом клиента. Состояние определённого кластера будет HEALTH_OK только когда все Группы размещения находятся в состоянии активных и чистых. Некий кластер не являющийся жизнеспособным, выявляет Группы размещения, которые могут быть либо в активном, либо в чистом состоянии, но не в обоих сразу - а возможно и ни в одном из них. Состояние активного необходимо для обслуживания ввода/ вывода клиента, в то время как чистый (clean) указывает что эта Группа размещения не только обслуживает ввод/ вывод, но также соответствует прочим необходимым требованиям, включая репликации.

Мы можем подразделить состояния Групп размещения на три категории: Critical, Warning и Info (Критичные, Предостерегающие и Информационные). Группы размещения в категории указывают на существенные разрушения в данном кластере и должны быть предприняты немедленные действия для разрешения вызвавших их проблем. Например, Если мы вышли за пределы пространства некоторого OSD, мы увидим применение состояния backfill-toofull (заполненный-черезчур). Если некая Группа размещения потеряла все OSD, выделенные для хранения её реплик, тогда она будет помечена как inactive (не активная) и весь ввод/ вывод клиента дойдёт до останова. Группа размещения в Предостерегающей категории указывает, что что- то плохое в данном кластере необходимо исправить, однако, скорее всего, это не решающее воздействие на ввод/ вывод клиента, которое привело бы к его полной остановке. Группы размещения в Информационной категории не указывают на некие проблемы с данным кластером, а вместо этого передают обычную информацию относительно текущего состояния Групп размещения.

Таблица 7-1.

Категория	Состояния PG
Критичная	inactive (не активная), backfill-toofull (черезчур-заполненная)
Предостерегающая	down (отключённая), degraded (деградировавшая), inconsistent (не согласованная), recovering (восстанавливающаяся), backfill (заполняющаяся), backfill-wait (ожидающая заполнения), incomplete (не завершённая), stale (не свежая), remapped (перераспределяемая), undersized (потерявшая репликации)
Информационная	peering (одноранговый обмен), scrubbing (выскребание), scrubbing+deep (глубокое выскребание), active (активная), clean (чистая)

Текущее состояние Групп размещения может отслеживаться с помощью описанных в предыдущих разделах проверок состояния жизнеспособности Ceph. Для отображения только итоговой информации о нашей коллекции Групп размещения и выделения определённых состояний мы можем применять подкоманду pg stat утилиты ceph.

root@ceph-client0:~# ceph pg stat
v40524: 128 pgs: 128 active+clean; 3656 bytes data, 1736 MB used, 63597 MB / 65333 MB avail
		

Порой может быть желательным просматривать имеющиеся состояния и историю всех Групп размещения в вашем кластере. Имеется возможность выполнить дамп полной информации обо всех Группах размещения, включая общее число объектов, общее число содержащихся в них байт, поднятые (up) и активные множества, всех ведущих обоих множеств OSD, а также конкретные временные штампы наиболее последних поверхностных и глубоких выскребаний. Эта избыточная информация может избыточной для человеческого восприятия, поэтому её рекомендуется фильтровать через некий синтаксический анализатор или сценарий, который преобразует его для предоставления ответов на формулируемые людьми вопросы. Мы можем извлекать эти данные применяя подкоманду pg dump своего ceph.

root@ceph-client0:~# ceph pg dump
dumped all in format plain
version 40582
stamp 2017-09-18 00:39:21.452578
last_osdmap_epoch 15487
last_pg_scan 15487
full_ratio 0.95
nearfull_ratio 0.85
pg_stat objects mip degr misp unf bytes log disklog state state_stamp v reported up up_primary acting acting_primary last_scrub scrub_stamp last_deep_scrub deep_scrub_stamp
0.39 0 0 0 0 0 0 0 0 active+clean 2017-09-17 17:52:23.574152 0'0 15424:130 [5,3,4] 5 [5,3,4] 5 0'0 2017-09-17 17:52:23.574107 0'0 2017-09-16 16:32:04.037088
0.38 0 0 0 0 0 0 0 0 active+clean 2017-09-17 22:29:40.588864 0'0 15439:183 [1,0,4] 1 [1,0,4] 1 0'0 2017-09-17 22:29:40.588828 0'0 2017-09-17 22:29:40.588828
0.37 0 0 0 0 0 0 0 0 active+clean 2017-09-17 17:52:41.700284 0'0 15425:178 [1,3,2] 1 [1,3,2] 1 0'0 2017-09-17 17:52:41.700258 0'0 2017-09-10 20:20:17.163705
...
		

Иногда нам желательно знать определённые подробности только о конкретной Группе размещения. Этого можно достичь вызвав pg <pgid> query в ceph. Такая строка pgid является определяющим идентификатором той Группы размещения, которую мы желаем опрашивать. Например:

root@ceph-client0:~# ceph pg 0.39 query
{
"state": "active+clean",
"snap_trimq": "[]",
"epoch": 15502,
"up": [
5,
3,
4
]
,
"acting": [
5,
3,
4
]
,
"actingbackfill": [
"3",
"4",
"5"
],
"info": {
"pgid": "0.39",
"last_update": "0'0",
"last_complete": "0'0",
		

Опрос Групп размещения полезен для поиска и исправления потенциальных проблем с ними. Иногда Группы размещения могут деградировать из- за проблем с имеющимся процессом выскребания, который может вызывать блокировку на существенные промежутки времени. В таких случаях опрос Групп размещения может предоставлять осведомляющую информацию о том, почему данное выскребание заблокировано и в каком OSD. Если мы полагаем, что это некая ошибка с Ceph, а не аппаратный сбой, мы легко можем перезапустить такой OSD чтобы разрешить данную проблему.

Ceph также позволяет нам выдавать перечень всех Групп размещения, которые помечены как unclean (не чистые), inactive (не активные), degraded (деградировавшие), undersized (потерявшие репликации) или stale (потерявшие свежесть). Для данной операции мы применяем подкоманду dump_stuck.

root@ceph-client0:~# ceph pg dump_stuck undersized
pg_stat state up up_primary acting acting_primary
0.f active+undersized+degraded [3,2] 3 [3,2] 3
8.7 active+undersized+degraded [2,3] 2 [2,3] 2
8.6 active+undersized+degraded [2,3] 2 [2,3] 2
...
		

Для дополнительной информации о Группах размещения, пожалуйста, обратитесь к разделу Состояния PG в Главе 8, Архитектура Ceph: под капотом.

Серверы MDS Ceph управляют файловыми системами CephFS. Сервер MDS Ceph может находиться в различных состояниях, включая up (поднятого), down (отключённого), active (активного) и inactive (не активного). Некий сервер MDS должен всегда быть поднятым и активным, когда он пребывает в правильном и работающем состоянии.

Существует две основные команды, которые мы можем применять для отслеживания некоторого работающего кластера MDS. Мы применяем mds stat для получения быстрого представления о текущем состоянии MDS. Вы можете узнать в этом формате вывода то же самое, что представляется ключом fsmap в состоянии самого Ceph.

root@ceph-client0:~# ceph mds stat
e38611: 1/1/1 up {0=ceph-mds0=up:active}
		

Если мы желаем получить более подробный вывод имеющейся карты MDS данного кластера, мы можем воспользоваться имеющейся подкомандой mds dump. Как и все прочие содержащие dump подкоманды, она печатает всю карту MDS, которая содержит подробную информацию об активных демонах MDS, а также прочие состояния.

root@ceph-client0:~# ceph mds dump
dumped fsmap epoch 38611
fs_name cephfs
epoch 38611
flags 0
created 2017-09-10 20:20:28.275607
modified 2017-09-10 20:20:28.275607
tableserver 0
root 0
session_timeout 60
session_autoclose 300
max_file_size 1099511627776
last_failure 0
last_failure_osd_epoch 15221
compat compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=file layout v2}
max_mds 1
in 0
up {0=38784}
failed
damaged
stopped
data_pools 1
metadata_pool 2
inline_data disabled
38784: 192.168.42.70:6800/1630589528 'ceph-mds0' mds.0.38608 up:active seq 5
		

Администраторы системы хранения Ceph могут выполнять большую часть мониторинга и управления кластером с помощью CLI команд, предоставляемых Ceph. Ceph также предоставляет богатый API администрирования, который может применяться для отслеживания и визуализации всего кластера Ceph. Имеются различные проекты с открытым исходным кодом, которые применяют API администрирования REST и предоставляют инструментальные панели с графическим интерфейсом для визуального обозрения всего вашего кластера. Некоторые средства сосредоточены на мониторинге, прочие имеют более широкую сферу и также содержат средства оркестрации (координации) и управления жизненным циклом.

Kraken является инструментальной панелью Ceph с открытым исходным кодом, написанный на Python. Первоначальным разработчиком был Дон Толтон, впоследствии он соединился с Дэвидом Мору Саймардом. Дон имеет более чем двадцатилетний опыт работы с известными компаниями и управляет консалтинговой компанией Merrymack.

Разработка Kraken была вызвана тем, что в то время инструмент Ceph Calamari был доступен только коммерческим подписчиками Inktank. Дон полагал, что желательно иметь хорошую инструментальную панель с открытым исходным кодом для мониторинга кластеров Ceph и их компонентов из некоторого единого окна. Это сделало бы более лучшими управляемость и принятие Ceph. Дон воспользовался RESTful API для извлечения необходимых данных кластера с целью мониторинга и составления отчётов.

Хотя Kraken и не получал обновлений в те два года, на протяжении которых мы пишем эту книгу, вы всё равно можете найти его полезным. Мы можете отыскать страницу GitHub Kraken по адресу https://github.com/krakendash/krakendash. Kraken является продуктом с полностью открытым кодом в соответствии с лицензией BSD.

Kraken применяет некоторые прочие проекты с открытым исходным кодом; подробности можно найти на упомянутой выше странице GitHub. Самое первое издание Изучаем Ceph содержит подробные инструкции по его установке. Поскольку Kraken может находиться в состоянии отсутствия поддержки в настоящее время, заинтересованным читателям остаётся только посетить GitHub, где можно отыскать эти инструкции.

Проект ceph-dash является другой бесплатной инструментальной панелью с открытым исходным кодом приборной доски/ мониторинга, разработанной Кристианом Айхельманном в 1&1 Internet AG, Германия в качестве ведущего программного разработчика. Как и Дон с Kraken, Кристиан начинал этот проект в то время, когда для Ceph было доступно очень мало инструментальных панелей с открытым исходным кодом. Кроме того, прочие доступные инструментальные панели имели сложные архитектуры и плохо работали с большими кластерами. Так же как и Kraken, на момент написания второй редакции Изучаем Ceph, ceph-dash может теперь пребывать в состоянии застоя, хотя в течении предыдущего года отмечались некие фиксации. {Прим. пер.: см. раздел Инструментарий ceph-dash в переводе первого издания.} Мы переносим вперёд этот раздел в сжатом виде, поскольку он может быть полезен и интересен администраторам Ceph.

Домашнюю страницу ceph-dash можно найти по адресу https://github.com/Crapworks/ceph-dash.

Другим интересным средством управления Ceph является Decapod, выпускаемое компанией Mirantis. Decapod строится на популярной инфраструктуре управления ceph-ansible, базирующейся на Ansible. О нём можно прочитать здесь: https://www.mirantis.com/blog/introducing-decapod-easier-way-manage-ceph/.

Rook является юным, но многообещающим инструментом с открытым исходным кодом для распределённого управления хранением в средах с облачной природой. Как и некоторые прочие описанные здесь инструменты, Rook является чем- то большим, чем просто мониторинг; это полномасштабное средство координации. Вы можете прочитать всё о нём на GitHub странице Rook, поддерживаемой сообществом активных разработчиков: https://github.com/rook/rook.

Calamari является платформой управления Ceph, некоторой привлекательной инструментальной панелью для мониторинга и управления вашим кластером Ceph. Она первоначально разрабатывалась Inktank как проприетарное программное обеспечение, которым снабжались Корпоративные продукты Ceph Inktank. Псоле того, как Inktank был приобретён Red Hat, Calamari стал продуктом с открытым исходным кодом и получил дополнительных разработчиков. Основа Calamari применяет Python, SaltStack, ZeroRPC, Graphite, Django и gevent. Сервер Calamari имеет лицензию открытого исходного кода LGPL2+; вы можете найти его репозиторий и изобилие информацмм по ссылке https://github.com/ceph/calamari.

Исключительная документация по Calamari доступна по адресу http://calamari.readthedocs.org. {Прим. пер.: см. также раздел Calamari в нашем переводе первого издания.}

В выпуске Luminous имеется новый демон ceph-mgr ядра, который предлагает многообещающие встраиваемый модуль инструментальной панели, который должен получить существенное внимание со стороны имеющегося сообщества.

Включение этой инструментальной панели достаточно прямолинейно:

Измените ceph.conf на всех узлах, которые исполняют необходимый демон ceph-mgr; обычно это узлв MON. Добавьте следующий раздел:

[mgr]
mgr_modules = dashboard
 	   

Затем настройте IP адресацию для каждого сервера ceph-mgr:

# ceph config-key put mgr/dashboard/server_addr ::
		

Указанное значение :: включает эту интрументальную панель по порту 7000 в каждой системе.

После этого перезапустите соответствующий демон ceph-mgr. В дистрибутивах с systemd это можно выполнить при помощи:

$ systemctl restart ceph-mgr@
		

Вы должны получить возможность просматривать свою инструментальную панель по порту tcp 7000 в своём активном сервере ceph-mgr.

Два самых последних инструмента, которые мы обсудим в данной главе исключительны для общих целей решений мониторинга и тенденций отслеживания. Prometheus является неким гибким инструментом мониторинга и последовательностей во времени для оповещений и отслеживания тенденций всех средств системных данных. Хотя возможна и автономная работа, связь с инструментальной панелью визуализации Grafana обеспечивает визуально привлекательный и дружественный пользователю интерфейс. Prometheus делает возможным гибкий и мощный анализ данных от различных источников. Интеграция с Ceph осуществляется посредством интеллектуального сборщика данных Ceph Exporter.

Вы можете изучить каждый из этих инструментов по соответствующим ссылкам:

Grafana

Prometheus

Ceph Exporter

В данной главе мы обсудили потребности и утилиты мониторинга Ceph. Это включает в себя состояния всего кластера, а также отдельных компонентов, таких как MON OSD и MDS. Мы также исследовали Группы размещения. Все состояния Групп размещения могут изменяться динамически и они требуют закрытого мониторинга. Большая часть происходящих в кластере изменений являются видимой поверхностью изменений в Группах размещения. Данная глава также охватывает определённые проекты инструментальных панелей графического интерфейса с открытым исходным кодом. Некоторые из них управляются и разрабатываются за рамками собственно Ceph, но они всё же являются открытым исходным кодом, поэтому вы свободно можете принимать участие в этих проектах и пользоваться их преимуществами. Мы также выполнили обзор Calamari и новой инструментальной панели ceph-mgr. В нашей следующей главе мы глубже погрузимся в процессы пищеварения Ceph, подробно изучим все моменты CRUSH, репликаций и удаляющего кодирования, а также дополнительные подробности, относящиеся к Группам размещения и потокам данных Ceph.