Глава 5. Мониторинг кластеров Ceph с применением Calamari

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

Будучи администратором системы хранения, вам необходимо отслеживать ваш кластер хранения Ceph и выяснять что происходит в нём в данный момент. Регулярное и дисциплинированное отслеживание держит вас в курсе о состоянии вашего кластера. На основании уведомлений мониторинга вы получите небольшой зазор по времени для принятия необходимых мер до отключения службы.

Наблюдение за кластером Ceph является повседневной задачей, которая включает в себя мониторинг MON, OSD, MDS, PG, а также подготовку служб хранения таких, как RBD, Radosgw, CephFS и клиентов Ceph. По умолчанию Ceph поставляется с богатым набором инструментария командной строки и API для выполнения наблюдения за этими компонентами. Кроме того, существуют проекты с открытым исходным кодом которые интенсивно развиваются для целей мониторинга кластеров Ceph в инструментальной панели единого обзора с GUI. В следующем рецепте мы сосредоточимся на инструментах CLI Ceph для мониторинга кластера.

В этом рецепте мы будем изучать команды, применяемые для мониторинга всего кластера Ceph.

Здесь мы распространяемся о мониторинге вашего кластера Ceph. Далее шаги раскрываются в поясняющих темах.

Проверка жизнеспособности кластера

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

# ceph health
	   

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

	[root@ceph-node1 ~]# ceph health 
	HEALTH_WARN 64 pgs degraded; 1408 pgs stuck unclean; recovery 1/5744 objects degraded (0.017%) 
	[root@ceph-node1 ~]# 
	   

Первый раздел вывода показывает что ваш кластер находится в состоянии предостережения, HEALTH_WARN, поскольку 64 группы размещения (PG, placement groups) деградировали. Второй раздел представляет, что 1408 PG не очищены, третий раздел вывода представляет, что кластер выполняет восстановление 1 из 5744 объектов и этот кластер на 0.017% деградировал. Если ваш кластер жизнеспособен, вы получите вывод, что HEALTH_OK.

Для получения дополнительных деталей по состоянию вашего кластера примените команду ceph health detail. Эта команда сообщит вам обо всех PG, которые не активны и не очищены, т.е. здесь будут выведены с подробностями все PG, которые не очищены, не согласованы и деградировали. Если ваш кластер в жизнеспособен, вы получите вывод, что HEALTH_OK.

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

	[root@ceph-node2 ceph]# ceph health detail 
	HEALTH_ERR 61 pgs degraded; 6 pgs inconsistent; 1312 pgs stuck unclean; recovery 3/5746 objects degraded (0.052%); 8 scrub errors 
	pg 9.76 is stuck unclean since forever, current state active+remapped, last acting [7,3,2] 
	pg 8.77 is stuck unclean since forever, current state active+remapped, last acting [4,6,8] 
	pg 7.78 is stuck unclean for 788849.714074, current state active+remapped, last acting [6,5,1] 
	pg 6.79 is stuck unclean since forever, current state active+remapped, last acting [4,7,8] 
	pg 5.7a is stuck unclean since forever, current state active+remapped, last acting [7,4,2] 
	pg 4.7b is stuck unclean since forever, current state active+remapped, last acting [7,3,1] 
	pg 11.74 is stuck unclean for 788413.925336, current state active+remapped, last acting [4,7,8] 
	pg 10.75 is stuck unclean for 788412.797947, current state active+remapped, last acting [7,3,0] 
	   

Мониторинг событий кластера

Вы можете наблюдать за событиями кластера применяя команду ceph с параметром -w. Эта команда высветит сообщения обо всех событиях вашего кластера, включая информационные (INF), предостерегающие (WRN) и сообщения об ошибках (ERR) в реальном времени. Вывод данной команды будет непрерывным, изменяемым кластеров вживую; для возврата в оболочку вы можете применить Ctrl + C:

# ceph -w

	[root@ceph-node1 ~]# ceph -w 
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc 
	     health HEALTH_OK 
	     monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 640, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3 
	     mdsmap e68: 1/1/1 up {0=ceph-node2=up:active} 
	     osdmap e1821: 9 osds: 9 up, 9 in 
	      pgmap v20731: 1628 pgs, 45 pools, 2422 MB data, 3742 objects 
	            7605 MB used, 127 GB / 134 GB avail 
	                1628 active+clean 
	
	2015-06-06 20:13:27.047075 mon.0 [INF] pgmap v20731: 1628 pgs: 1628 active+clean; 2422 MB data, 7605 MB used, 127 GB / 134 GB avail; 7931 kB/s, 1 objects/s recovering 
	2015-06-06 20:14:25.958762 mon.0 [INF] from.'client.? 192.168.1.103:0/1008239' entity='cli ent.admin' cmd.[{"prefix": "pg repair", "pgid": "43.29"}]: dispatch 
	2015-06-06 20:14:32.031029 mon.0 [INF] pgmap v20732: 1628 pgs: 1628 active+clean; 2422 MB data, 7605 MB used, 127 GB / 134 GB avail 
	2015-06-06 20:14:57.541278 mon.0 [INF] pgmap v20733: 1628 pgs: 1628 active+clean; 2422 MB data, 7621 MB used, 127 GB / 134 GB avail 
	2015-06-06 20:15:02.371735 mon.0 [INF] pgmap v20734: 1628 pgs: 1628 active+clean; 2422 MB data, 7633 MB used, 127 GB / 134 GB avail 
	   

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

Статистика использования кластера

Чтобы узнать статистику использования пространства вашего кластера примените команду ceph с параметром df. Эта команда покажет общий размер кластера, доступный размер, используемый размер и проценты. Она также высветит информацию о пулах, такую как имя пула, идентификатор, использование и число объектов в каждом пуле:

# ceph df

	[root@ceph-node1 ..]# ceph df 
	GLOBAL:
	    SIZE     AVAIL      RAW USED       %RAW USED
		134G       127G        7440M            5.39
	POOLS: 
	    NAME                              ID      USED      %USED     MAX AVAIL     OBJECTS 
	    rbd                               0         114M     0.08        42924M        2629 
	    images                            1       53002k     0.04        42924M          12 
	    volumes                           2           47        0        42924M           8 
	    vms                               3         208M     0.15        42924M          31 
	    .rgw.root                         4          162        0        42924M           2 
	    .rgw.control                      5            0        0        42924M           8 
	    .rgw                              6         2731        0        42924M          15 
	    .rgw.gc                           7            0        0        42924M          32 
	    .users.uid                        8          736        0        42924M           4 
	    .users.email                      9            8        0        42924M           1 
	    .users                            10          16        0        42924M           2 
	    .users.swift                      11           8        0        42924M           1 
	    .rgw.buckets.index                12           0        0        42924M           9 
	    .rgw.buckets                      13        1744        0        42924M           4 
	   

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

Проверка состояния кластера является наиболее общей и наиболее частой операцией при управлении кластером Ceph. Вы можете проверить состояние вашего кластера с применением команды ceph и status в качестве параметра:

# ceph status
	   

Вместо подкоманды status вы можете применить более короткую версию, -s, как опцию:

# ceph -s
	   

Следующий снимок экрана покажет состояние нашего кластера:

	[root@ceph-node1 ~]# ceph -s 
	    cluster 9609b429-eee2-4e23-af31-28a24fcf5cbc 
	    health HEALTH_OK 
	    monmap e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3=192.168.1.103:6789/0}, election epoch 640, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3 
	    mdsmap e73: 1/1/1 up {0=ceph-node2=up:active} 
	    osdmap el823: 9 osds: 9 up, 9 in 
	     pgmap v20762: 1628 pgs, 45 pools, 2422 MB data, 3742 objects 
	           7440 MB used, 127 GB / 134 GB avail 
	               1628 active+clean 
	[root@ceph-node1 ~]# 
	   

Эта команда выводит на экран массу полезной информации для вашего кластера Ceph:

Записи аутентификации вашего кластера

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

# ceph auth list
	   

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

Мы сосредоточимся сейчас на командах для наблюдения за мониторами. Шаги будут раскрываться в поясняющих темах.

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

Для отображения состояния монитора кластера и карты MAP воспользуйтесь командой ceph с дополнительным параметром либо mon stat либо mon dump:

# ceph mon stat
# ceph mon dump
	   

Следующий снимок экрана отображает вывод этих команд:

	[root@ceph-node1 ~]# ceph mon stat 
	e3: 3 mons at {ceph-node1=192.168.1.101:6789/0,ceph-node2=192.168.1.102:6789/0,ceph-node3 =192.168.1.103:6789/0}, election epoch 640, quorum 0,1,2 ceph-node1,ceph-node2,ceph-node3 
	[root@ceph-node1 ~]# 
	[root@ceph-node1 ~]# ceph mon dump 
	dumped monmap epoch 3 
	epoch 3 
	fsid 9609b429-eee2-4e23-af31-28a24fcf5cbc 
	last_changed 2015-03-18 00:20:07.092486 
	created 0.000000 
	0: 192.168.1.101:6789/0 mon.ceph-node1 
	1: 192.168.1.102:6789/0 mon.ceph-node2 
	2: 192.168.1.103:6789/0 mon.ceph-node3 
	[root@ceph-node1 ~]# 
	   

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

Для поддержания кворума между мониторами Ceph кластер всегда должен иметь более половины доступных в кластере мониторов. Проверка состояния кворума вашего кластера очень полезна во время определения проблем с мониторами. Вы можете проверить состояние кворума при помощи команды ceph с подкомандой quorum_status:

# ceph quorum_status -f json-pretty
	   

Следующий снимок отображает вывод этой команды:

	[root@ceph-node1 ~]# ceph quorum_status -f json-pretty 
	
	{ "election_epoch": 640, 
	  "quorum": [ 
	        0, 
	        1, 
	        2], 
	  "quorum_names": [ 
	        "ceph-node1", 
	        "ceph-node2", 
	        "ceph-node3"], 
	  "quorum_leader_name": "ceph-node1", 
	  "monmap": { "epoch": 3, 
	      "fsid": "9609b429-eee2-4e23-af31-28a24fcf5cbc", 
	      "modified": "2015-03-18 00:20:07.092486, 
	      "created": "0.000000", 
	      "mons": [
		        { "rank": 0, 
	              "name": "ceph-node1", 
	              "addr": "192.168.1.101:6789\/0"}, 
	            { "rank": 1, 
				  "name": "ceph-node2", 
	              "addr": "192.168.1.102:6789\/0}, 
	            { "rank": 2, 
	              "name": "ceph-node3", 
	              "addr": "192.168.1.103:6789\/0"}]}} 
	[root@ceph-node1 ~]# 
	   

Состояние кворума высвечивает election_epoch, что является номером версии выборов и quorum_leader_name, которое обозначает имя вашего хоста, руководящего кворумом. Оно также отображает эпоху карты монитора и идентификатор кластера. Каждому монитору кластера выделяется ранг. Для операций ввода/ вывода клиенты вначале соединяются с ведущим монитором кворума; если ваш ведущий монитор недоступен, клиент тогда соединяется со следующим по рангу монитором.

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

Мы сосредоточимся сейчас на командах для наблюдения за OSD. Шаги будут раскрываться в последующих поясняющих темах:

Обзор дерева OSD

Обзор дерева OSD очевидно полезен для получения информации о состояниях OSD таких как IN или OUT и UP или DOWN. Обзор дерева OSD отображает все узлы со всеми их OSD и их местоположение в карте CRUSH. Вы можете попробовать отображение своего дерева OSD с применением следующей команды:

# ceph osd tree

	[root@ceph-node1 ~]# ceph osd tree 
	# id    weight  type name       up/down reweight 
	-1      0.08995 root default 
	-2      0.02998         host ceph-node1 
	0       0.009995                        osd.0   up      1 
	1       0.009995                        osd.1   up      1 
	2       0.009995                        osd.2   up      1 
	-3      0.02998         host ceph-node2 
	3       0.009995                        osd.3   up      1 
	4       0.009995                        osd.4   up      1 
	5       0.009995                        osd.5   up      1 
	-4      0.02998         host ceph-node3 
	6       0.009995                        osd.6   up      1 
	7       0.009995                        osd.7   up      1 
	8       0.009995                        osd.8   up      1 
[root@ceph-node1 ~]# 
	   

эта команда отображает различную полезную информацию для OSD Ceph, такую как вес, состояние UP/DOWN и IN/OUT. Выдача будет прекрасно отформатирована в виде вашей карты Ceph CRUSH. Если вы сопровождаете большой кластер, этот формат даст вам преимущества определения местоположения OSD и его сервера хоста в длинном перечне.

Статистика OSD

Чтобы проверить статистику OSD, примените # ceph osd stat; эта команда поможет вам получить эпоху карты, общее число OSD и их состояния IN и UP.

Для получения подробной информации о кластере Ceph и OSD выполните следующую команду:

# ceph osd dump
	   

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

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

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

# ceph osd blacklist ls
	   

Проверка вашей карты CRUSH

Вы можете запрашивать свою карту CRUSH непосредственно из команд # ceph osd. Утилита командной строки карты CRUSH может сохранить много времени системного администратора, по сравнению с обычным способом просмотра и её редактирования после декомпиляции вашей карты CRUSH:

Следующий рисунок отображает вывод нашего запроса карты CRUSH:

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

Если вы управляете большим кластером с несколькими сотнями OSD, иногда бывает трудно найти местоположение определённого OSD в карте CRUSH. Это также трудно сделать, если ваша карта CRUSH содержит множественную иерархию сегментов (bucket). Вы можете воспользоваться ceph osd find для поиска некоего OSD и определении его местоположения в карте CRUSH:

# ceph osd find <Numeric_OSD_ID>

	[root@ceph-node1 ~]# ceph osd find 4 
	{ "osd": 4, 
	  "ip": "192.168.1.102:6811\/3897", 
	  "crush_location": { "host": "ceph-node2", 
	      "root": "default}}
	[root@ceph-node1 ~]# 
	[root@ceph-node1 ~]#
	   

Мониторинг PG

OSD хранят PG, причём каждая PG содержит объекты. Общая жизнеспособность кластера в основном зависит от PG. Кластер будет оставаться в состоянии HEALTH_OK только если все PG находятся в состоянии active + clean. Если ваш кластер Ceph испытывает проблемы с жизнеспособностью, то существует вероятность, что ваши группы размещения не active + clean. Группы размещения могут существовать в различных состояниях, и даже в комбинации состояний. Вот некоторые состояния, в которых могут находиться PG:

Вы можете пронаблюдать за PG применив следующие команды:

Серверы метаданных используются исключительно для CephFS, которая пока не готова к промышленному применению на настоящий момент. Сервер метаданных имеет различные состояния, такие как, UP, DOWN, ACTIVE и INACTIVE. При выполнении мониторинга MDS вам следует проверять что состояние MDS UP и ACTIVE. Следующие команды помогут вам получит информацию связанную с MDS Ceph.

Мы сосредоточимся сейчас на командах для наблюдения за OSD. Шаги будут раскрываться в последующих поясняющих темах:

Calamari является платформой управления для Ceph; привлекательной инструментальной панелью для мониторинга и управления вашим кластером Ceph. Она была изначально разработана компанией Inktank как проприетарное программное обеспечение, и была продуктом Inktank Ceph Enterprise, который предлагался их пользователям. Сразу после приобретения Inktank компанией Red Hat, она стала открытым исходным кодом Red Hat, 30 мая 2014. Calamari имеет различные великолепные наборы функциональности, а их последующая дорожная карта весьма впечатляет. Calamari имеет две части, причём каждая часть имеет свои собственные репозитории:

Calamari имеет хорошую документацию доступную на http://calamari.readthedocs.org; являетесь ли вы оператором или разработчиком, работающим над Calamari или разработчиком, применяющим Calamati REST API, эта документация является хорошим источником информации для начала вашей работы с Calamari. Как и Ceph, Calamari разрабатывается как восходящий продукт; вы можете включиться в Calamari на IRC по адресу irc://irc.oftc.net/ceph, зарегистрироваться в почтовой рассылке на ceph-calamari@ceph.com, или послав запрос на учётную запись Calamari GitHub на https://github.com/ceph/calamari и https://github.com/ceph/calamariclients.

В настоящее время Calamari не предоставляет готовых к установке пакетов, поэтому вам придётся построить их для своей среды. В этом рецепте мы изучим построение пакетов сервера Calamari Ceph из исходных кодов. Построение таких пакетов иногда является серъёзным вызовом, поскольку вы можете не выполнить его одним ударом. Поэтому, чтобы уменьшить сложность, я построил такие пакеты для вас и вы можете их загрузить с https://github.com/ksingh7/cephcalamari-packages, поэтому можете пропустить следующие два рецепта, напрямую перескочив на необходимые условия для установки. Для тех, кому интересно построение пакетов из исходных кодов, давайте приступим. {Прим. пер.: также см. Глава 15. Инструменты разработки в нашем переводе "Как работает Linux" Брайана Варда}.

Calamari предоставляет готовую к применению конфигурацию Vagrant для некоторых типов ОС. Определите тип вашего работающего хоста Calamari, для которого вы хотите построить пакеты; в нашем случае это CentOS7.

В этом рецепте мы изучим построение пакетов клиента Calamari. Большинство шагов аналогичны тому, что мы делали в предыдущем разделе, то есть при построении пакета сервера.

В последних рецептах мы скомпилировали необходимые для Calamari пакеты, которые включают в себя calamari-server, calamari-client и diamond. Если вы не компилировали эти пакеты, вы можете загрузить их из моего репозитория GitHub: https://github.com/ksingh7/ceph-calamari-packages/tree/master/CentOS-el7:

На данный момент у нас есть работающий главный сервер Calamari. Чтобы наблюдать за вашим кластером Ceph при помощи Calamari, нам нужно добавить узлы Ceph в Calamari. Давайте начнём это.

Теперь выполняем эти шаги на ceph-node1, ceph-node2, а также как и на ceph-node3:

Наблюдение за кластером Ceph из инструментальной панели Calamari достаточно непосредственное. Давайте посмотрим как:

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