Глава 4. Ceph изнутри

Каждый элемент данных в Ceph хранится в виде объекта внутри пула. Пул Ceph является логическим разделом для хранения объектов, что обеспечивает организованный способ хранения. Позже в данной главе мы узнаем больше подробностей о пулах. А сейчас мы обсудим объекты, которые являются наименьшей единицей хранения данных в Ceph. После развертывания кластера Ceph, он создает некоторые пулы хранения по умолчанию в качестве пулов данных, метаданных и RBD (блочного устройства RADOS). После развертывания MDS (сервера метаданных) на одном из узлов Ceph, он создает создает объекты внутри пула метаданных, которые требуются CephFS для надлежащей функциональности. Поскольку ранее в нашей книге мы уже развернули кластер, давайте исследуем эти объекты:

1. Проверьте состояние вашего кластера Ceph с применением следующей команды в pgmap. Вы найдете три пула и некоторые объекты:

   # ceph -s

   [root@ceph-node1 ceph]# ceph -s
       cluster ffa7c0e4-6368-4032-88a4-5fb6a3fb383c
        health HEALTH_OK
        monmap e9: 3 mons at {ceph-node1=192.168.57.101:6789/0,ceph-node2=192.168.57.102:6789/0,
   ceph-node3=192.168.57.103:6789/0}, election epoch 76, quorum 0,1,2 ceph-node1,ceph-node2,ceph
   -node3
        mdsmap e25: 1/1/1 up {0=ceph-node2=up:active}
        osdmap e281: 9 osds: 9 up, 9 in
         pgmap v603: 192 pgs, 3 pools, 9470 bytes data, 21 objects
               345 MB used, 45635 MB / 45980 MB avail
                    192 active+clean

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

   # rados lspools

   [root@ceph-node1 /]# rados 1 spools
   data
   metadata
   rbd
   [root@ceph node1 /]#

   Наконец, выведите список объектов из пула метаданных. Вы найдете в этом пуле созданные системой объекты:

   # rados -p metadata ls

   [root@ceph-node1 /]# rados -p metadata ls
   1.00000000.inode
   100.00000000
   100.00000000.inode
   1.00000000
   2.00000000
   200.00000000
   200.00000001
   600.00000000
   601.00000000
   602.00000000
   603.00000000
   604.00000000
   605.00000000
   606.00000000
   607.00000000
   608.00000000
   609.00000000
   mds0_inotable
   mds0_sessionmap
   mds_anchortable
   mds_snaptable
   [root@ceph-node1 /]#

Механизм CRUSH работает таким образом, что нагрузка вычислений метаданных распределена и выполняется только при возникновении необходимости в них. Процесс вычисления метаданных также известен как нахождение (lookup) CRUSH, а имеющаяся в настоящее время вычислительная аппаратура достаточно мощна для быстрого и эффективного выполнения операций нахождения CRUSH. Уникальным моментом в нахождении CRUSH является то, что он системно- независим. Ceph предоставляет клиентам достаточную гибкость для выполнения по запросу вычисления метаданных, то есть, осуществления нахождения CRUSH на своих собственных системных ресурсах, тем самым исключая централизованное местоположение.

Для выполнения операций чтения-и-записи в кластере Ceph, первоначально клиенты общаются с монитором Ceph и получают копию карты кластера. Карта кластера помогает клиентам знать состояние и конфигурацию кластера Ceph. Данные преобразуются в объекты с именами/ идентификаторами объектов и пулов. Затем объекты хешируются номером группы размещения для создания окончательной группы размещения (PG, placement group) внутри необходимого пула Ceph. Вычисленная группа размещения затем следует найденным CRUSH для определения местоположения первичного OSD (устройства хранения объектов) для сохранения или получения данных. После вычисления точного идентификатора OSD, клиент взаимодействует с OSD напрямую и выполняет операцию с данными. Все эти операции вычислений выполняются клиентами, следовательно они не влияют на производительность кластера. Когда данные записаны на первичное OSD, этот же узел выполняет операцию нахождения CRUSH и вычисляет местоположение для вторичных групп размещения (PG) и OSD, тем самым выполняя репликацию данных в кластере для высокой доступности. Рассмотрим следующий пример нахождения CRUSH и размещения объекта в OSD.

Прежде всего к имени объекта и номеру группы размещения кластера применяется хеш- функция и степень (основание) идентификатора пула; таким образом создается идентификатор группы размещения, PGID. Затем по этому PGID выполняется нахождение CRUSH для поиска первичного и вторичных OSD для записи данных.

CRUSH полностью осведомлён об инфраструктуре и является абсолютно настраиваемым со стороны пользователя; он устанавливает вложенную иерархию для всех компонентов вашей инфраструктуры. Список устройств CRUSH обычно содержит диск, узел, стойка, ряд, коммутатор, цепь электропитания, зал, центр обработки данных и тому подобное. Эти компоненты известны как зоны отказа или сегменты (bucket) CRUSH. Карта CRUSH содержит перечень доступных сегментов для преобразования устройств в физические местоположения. Она также содержит список правил, которые сообщают CRUSH как выполнять репликацию данных для различных пулов Ceph. Следующая диаграмма даст вам представление о том, как выглядит CRUSH в вашей физической инфраструктуре:

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

В случае отказа любого компонента из зоны отказа Ceph ожидает по умолчанию 300 секунд перед тем, чтобы пометить OSD вышедшим из строя, после чего начинает операцию восстановления. Этой установкой можно управлять при помощи параметра mon osd down out interval в файле настроек Ceph. Во время операции восстановления Ceph запускает регенерацию утраченных данных, которые размещались отказавшем узле.

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

Когда в кластер добавляется новый хост или диск, CRUSH запускает операцию повторной балансировки, в процессе которой он перемещает данные с существующих хостов/ дисков на новые хосты/ диски. Ребалансировка выполняется для сохранения заполненности дисков в одной пропорции, что увеличивает производительность кластера и сохраняет его работоспособность. Например, если кластер Ceph содержит 2000 OSD (устройств хранения объектов) и добавляется новая система с 20 новыми OSD, будет перемещён только один процент данных в процессе выполнения операции повторной балансировки, причём все существующие OSD будут выполнять работу по перемещению данных одновременно, помогая операции быстро завершиться. Однако для кластеров Ceph, находящихся под высокой нагрузкой рекомендуется добавлять новые OSD со значением параметра веса 0 и затем плавно увеличивать их вес до наивысшего значения, соответствующего их размеру. При таком подходе новое OSD будет прилагать меньшую нагрузку повторной балансировки на кластеры Ceph и избежит проблемы уменьшения производительности.

Когда мы развернули Ceph с использованием ceph-deploy, команда создала карту CRUSH по умолчанию для нашей конфигурации. Карта CRUSH по умолчанию идеальна при тестировании и в среде песочницы, однако если вы планируете разворачивать кластер Ceph в большой промышленной среде, вам следует проанализировать возможность разработки индивидуальной карты CRUSH для вашей среды. Следующий процесс поможет вам скомпилировать новую карту CRUSH:

1. Выделите вашу существующую карту CRUSH. При помощи параметра -o Ceph выведет в указанный вами файл скомпилированную карту CRUSH:

   # ceph osd getcrushmap -o crushmap.txt

2. Декомпилируйте вашу карту CRUSH. При помощи параметра -d Ceph декомпилирует вашу карту CRUSH и выведет в файл, указанный в -o:

   # crushtool -d crushmap.txt -o crushmap-decompile

3. Отредактируйте карту CRUSH любым редактором:

   # vi crushmap-decompile

4. Скомпилируйте новую карту CRUSH:

   # crushtool -c crushmap-decompile -o crushmap-compiled

5. Установите новую карту CRUSH в кластер Ceph:

   # ceph osd setcrushmap -i crushmap-compiled

Индивидуальная настройка компоновки кластера является одним из самых важных шагов к построению прочного и надёжного кластера хранения Ceph. Одинаково важно установить кластерное оборудование в отказоустойчивой зоне и включить его в высоко доступную схему с точки зрения перспективы программного обеспечения Ceph. Развёртыванию Ceph по умолчанию ничего не известно о компонентах, не имеющих обратной связи, таких как стойки, ряды, центры обработки данных. После проведения начальной установки нам необходимо выполнить индивидуальные настройки схемы компоновки в соответствии с нашими требованиями. Например, если вы выполните команду ceph osd tree, она уведомит вас только о том, что она имеет хосты и OSD, перечисленные под root, что является поведением по умолчанию. Давайте попробуем разместить эти хосты по стойкам:

1. Выполните ceph osd tree для получения имеющейся в настоящее время схемы кластера:

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

2. Добавьте несколько стоек в компоновку вашего кластера Ceph:

   # ceph osd crush add-bucket rack01 rack
   # ceph osd crush add-bucket rack02 rack
   # ceph osd crush add-bucket rack03 rack

3. Переместите каждый хост в определенную стойку:

   # ceph osd crush move ceph-node1 rack=rack01
   # ceph osd crush move ceph-node2 rack=rack02
   # ceph osd crush move ceph-node3 rack=rack03

4. Теперь переместите все стойки в root default:

   # ceph osd crush move rack03 root=default
   # ceph osd crush move rack02 root=default
   # ceph osd crush move rack01 root=default

5. Проверьте вашу новую компоновку. Вы заметите, что все ваши хосты теперь размещены в определённых стойках. Таким образом вы можете индивидуально настраивать вашу компоновку CRUSH для приведения в соответствие с физическим размещением установленного оборудования:

   [root@ceph-node1 ~]# ceph osd tree
   # id	weight	type name	up/dcwn reweight			
   -1	0	root default				
   -7	0	        rack rack03			
   -4	0		        host ceph-node3		
   6	0			        osd.6   up	1
   7	0			        osd.7	up	1
   8	0			        osd.8	up	1
   -6	0	        rack rack02			
   -3	0		        host ceph-node2		
   3	0			        osd.3	up	1
   4	0			        osd.4	up	1
   5	0			        osd.5	up	1
   -5	0	        rack rack01			
   -2	0		        host ceph-nodel		
   0	0			        osd.O	up	1
   1	0			        osd.l	up	1
   2	0			        osd.2	up	1

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

Формула для вычисления общего числа групп размещения для кластера Ceph следующая:

		Total PGs = (Total_number_of_OSD * 100) / max_replication_count

Результат должен быть округлён вверх до ближайшего числа степени 2. Например, если кластер Ceph имеет 160 OSD и число репликаций равно 3, то общее число групп размещения получается 5333.3, и, округляя его вверх до ближайшей степени 2 мы получаем конечное значение 8192 PG.

Мы также должны провести вычисления для того, чтобы найти общее число PG на пул в кластере Ceph. Формула для такого вычисления следующая:

		Total PGs = ((Total_number_of_OSD * 100) / max_replication_count)
		/ pool count

Мы рассмотрим тот же пример, который мы использовали ранее. Общее число OSD равно 160, уровень репликаций 3, а общее число пулов равно трём. Исходя из этих предположений, формула выдаёт 1777.7. Наконец, округляя значение вверх до степени 2 мы получаем 2048 PG на пул.

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

Если вы управляете кластером Ceph, в определённый момент времени вам может потребоваться изменение значений PG и PGP для вашего пула. Прежде чем приступить к изменению PG и PGP, давайте разберёмся с тем, что такое PGP.

PGP это группы размещения для целей расположения (Placement Group for Placement purpose), которое должно оставаться равным общему числу групп размещения (pg_num). Если вы увеличивает число групп размещения для пула Ceph, то есть pg_num, то вы должны также увеличить pgp_num до того же целочисленного значения, равного pg_num, следовательно кластер начнет процесс ребалансировки. Скрытый механизм ребалансировки можно пояснить следующим образом.

Значение pg_num определяет число групп размещения, которое отображается на OSD (устройства хранения объектов). Когда значение pg_num увеличивается для любого пула, каждая PG этого пула разделяется пополам, однако они все по прежнему отображаются на свои родительские OSD. До этого момента времени Ceph не начинает ребалансировку. Теперь, когда вы увеличиваете значение pgp_num для того же самого пула, PG начинают миграцию с родительских на некоторые другие OSD и начинается ребалансировка. Таким образом, PGP играет важную роль в ребалансировке кластера. Теперь давайте узнаем как изменить pg_num и pgp_num:

1. Получите текущие значения числа PG и PGP:

   # ceph osd pool get data pg_num
   # ceph osd pool get data pgp_num

   [root@ceph-node1 /]#
   [root@ceph-node1 /]# ceph osd pool get data pg_num
   pg_num: 64
   [root@ceph-node1 /]# ceph osd pool get data pgp_num
   pgp_num: 64
   [root@ceph-node1 /]#

2. Определите уровень репликаций выполнив следующую команду и получив значение для rep size:

   # ceph osd dump | grep size

   [root@ceph node1 /]# ceph osd durp grep -i size
   pool 3 'rbd' rep size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 452 owner 0
   pool 4 'data' rep size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 454 owner 0
   pool 5 ’metadata' rep size 2 min_size 1 crush ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 456 owner 0
   [root@ceph-node1 /]#

3. Вычислите новое число групп размещения для нашей установки с использованием {следующих значений}:

   Total OSD = 9, Replication pool level (rep size) = 2, pool
   count = 3

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

4. Изменяем PG и PGP для пула {данных}:

   # ceph osd pool set data pg_num 256
   # ceph osd pool set data pgp_num 256

   [root@ceph-node1 /]# ceph osd pool set data pg_num 256
   set pool 6 pg_num to 256
   [root@ceph-node1 /]#
   [root@ceph-nodel /]# ceph osd pool set data pgp_num 256
   set pool 6 pgp_num to 2S6
   [root@ceph-node1 /]#

5. Аналогично изменяем значения PG и PGP для пулов метаданных и RBD (блочного устройства RADOS, Безотказного автономного распределённого хранилища объектов - Reliable Autonomic Distributed Object Store)):

   [root@ceph-node1 /]# ceph osd pool get data pg_num
   pg_num: 256				
   [root$ceph-node1 /]# ceph osd pool get data pgp_num
   pgp_num: 256				
   [root@ceph-node1 /]# ceph osd pool get metadata pg_num
   pg_num: 256				
   [root@ceph-node1 /]# ceph osd pool get metadata pgp_num
   pgp_num: 256				
   [rootQceph-node1 /]# ceph osd pool get rbd pg_num
   pg_num: 256				
   [rootOceph node1 /]# ceph osd pool get rbd pgp_num
   pgp_num: 256
   [root@ceph-node1 /]#

Демон Ceph OSD выполняет равноправные операции обмена (peering operation) состояний всех объектов и их метаданных для конкретных групп размещения, которые включают в себя согласование межу хранящими группу размещения OSD (устройствами хранения объектов). Кластер хранения Ceph сохраняет множество копий любых объектов во множестве PG (групп хранения), которые затем записываются в множестве OSD. Эти OSD называются первичными, вторичными, третичными и т.д. Действующий (acting) набор относится к группе OSD, ответственной за PG. Первичный OSD называется первым OSD из действующего набора и он отвечает за операции равноправного обмена для каждой PG со своими вторичными / третичными OSD. Первичное OSD является единственным OSD, которое принимает записывает операции от клиента. Находящееся в рабочем состоянии OSD остаётся в действующем состоянии. Ели вдруг первичное OSD выходит из строя, оно сначала удаляется из набора включённых (up); вторичное OSD повышается до первичного OSD. Ceph восстанавливает PG отказавшего OSD новым OSD и добавляет его в наборы включённых (up) и действующих (acting) для обеспечения высокой доступности.

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

В предыдущем примере действующий набор содержит три OSD (osd.24, osd.72 и osd.11). Из них osd.24 является первичным OSD, а osd.72 и osd.11 являются вторичным и третичным OSD, соответственно. Поскольку osd.24 является первичным OSD, оно заботится о равноправных операциях обмена для всех PG, существующих на этих трёх OSD. Таким образом Ceph гарантирует, что PG всегда доступны и непротиворечивы.

Выполнение операций с пулом Ceph одна из повседневных работ для администратора Ceph. Ceph предоставляет богатый инструментарий cli для создания пулов и управления ими. В следующем разделе мы узнаем о работе с пулами Ceph.