Глава 6. Работа и сопровождение

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

Чтобы визуально рассмотреть всю топологию некоторого кластера Ceph, исполните ceph osd tree. Она отобразит нам за раз всю иерархию сегментов (buckets, корзин) CRUSH, включая само название каждого сегмента, его вес, помечен ли он как поднятый или остановленный, некую регулировку веса и какие- то дополнительные атрибуты primary affinity. Данный кластер был первоначально предоставлен в трёх стойках, причём каждая размещает по 4 хоста с общим числом 12 узлов OSD. Каждый узел OSD (также именуемый хостом, а кроме того ещё называемый сервером) в свою очередь размещает 24 устройства OSD.

# ceph osd tree
ID  WEIGHT    TYPE NAME           UP/DOWN REWEIGHT PRIMARY-AFFINITY
 -1 974.89661 root default
-14 330.76886     rack r1
 -2 83.56099          host data001
  0  3.48199              osd.0       up  1.00000           1.00000
...
 23  3.48199              osd.23      up  1.00000           1.00000
 -3 80.08588          host data002
 24  3.48199              osd.24      up  1.00000           1.00000
 25  3.48199              osd.25      up  1.00000           1.00000
 26  3.48199              osd.26      up  1.00000           1.00000
 27  3.48199              osd.27      up  1.00000           1.00000
 28  3.48199              osd.28      up  1.00000           1.00000
 29  3.48199              osd.29      up  1.00000           1.00000
 30  3.48199              osd.30      up  1.00000           1.00000
 31  3.48199              osd.31      up  1.00000           1.00000
 32  3.48199              osd.32      up  1.00000           1.00000
 34  3.48199              osd.34      up  1.00000           1.00000
 35  3.48199              osd.35      up  1.00000           1.00000
 36  3.48199              osd.36      up  1.00000           1.00000
 37  3.48199              osd.37      up  1.00000           1.00000
 38  3.48199              osd.38      up  1.00000           1.00000
 39  3.48199              osd.39    down        0           1.00000
 40  3.48199              osd.40      up  1.00000           1.00000
 41  3.48199              osd.41      up  1.00000           1.00000
 42  3.48199              osd.42      up  1.00000           1.00000
 43  3.48199              osd.43      up  1.00000           1.00000
 44  3.48199              osd.44      up  1.00000           1.00000
 45  3.48199              osd.45      up  1.00000           1.00000
 46  3.48199              osd.46      up  1.00000           1.00000
 47  3.48199              osd.47      up  1.00000           1.00000
 -4 83.56099          host data003
 48  3.48199              osd.48      up  1.00000           1.00000
...
 -5 83.56099          host data004
 72  3.48199              osd.72      up  1.00000           1.00000
...
 95  3.48199              osd.95      up  1.00000           1.00000
-15 330.76810     rack r2
 -6 83.56099          host data005
 96  3.48199              osd.96      up  1.00000           1.00000
...
 -7 80.08557          host data006
120  3.48199              osd.120     up  1.00000           1.00000
...
 -8 83.56055          host data007
 33  3.48169              osd.33      up  1.00000           1.00000
144  3.48169              osd.144     up  1.00000           1.00000
...
232  3.48169              osd.232     up  1.00000           1.00000
 -9 83.56099          host data008
168  3.48199              osd.168     up  1.00000           1.00000
-16 313.35965     rack r3
-10 83.56099          host data009
192  3.48199              osd.192     up  1.00000           1.00000
...
-11 69.63379          host data010
133  3.48169              osd.133     up  1.00000           1.00000
...
-12 83.56099          host data011
239  3.48199              osd.239     up  1.00000           1.00000
...
-13 76.60388          host data012
...
286  3.48199              osd.286     up  1.00000           1.00000
		

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

После колонок заголовка, наша первая строка представляет:

 -1 974.89661 root default
		

Самым первым столбцом является некий номер ID, который Ceph применяет внутри себя и с которыми нам редко приходится сталкиваться. Второй колонкой под заголовком WEIGHT является определённый вес CRUSH. По умолчанию значение веса CRUSH любого сегмента соответствует его сырой ёмкости в ТБ; в данном случае мы слегка напуганы петабайтом (ПБ) сырого пространства. Мы видим, что этот вес является общей суммой всех сегментов под корнем нашего дерева.

Так как данный кластер применяет обычный множитель репликаций 3, приблизительно 324 ТБ используемого пространства доступно в настоящий момент в данном кластере. Общий баланс данной строки это root default, который сообщает нам, что данный сегмент CRUSH имеет тип root и его названием является default. Сложные кластеры Ceph могут содержать множество корней, однако большинству требуется только один. Мы обсудим эти понятия более глубоко в Главе 8, Архитектура Ceph: под капотом.

Следующая строка такова:

 -14 330.76886 rack r1
		

Она показывает некий тип сегмента стойки с весом примерно в 330 ТБ. Забегая слегка вперёд, мы видим ещё два дополнительных сегмента с весами 330 и 313 каждый. Их общая сумма даёт нам приблизительно 974 ТБ ёмкости (веса) в общем сегменте корня. Когда весы стоек не равны, как это наблюдается в нашем примере, обычно, либо они содержат различное число сегментов хостов (или просто хостов), или, что более часто встречается, их лежащие в основе хосты имеют различные веса.

Далее мы видим следующее:

 -2 83.56099       host data001
		

это указывает на тип сегмента в виде стойки, причём его вес приблизительно равен 330 ТБ. Забегая слегка вперёд мф видим два сегмента стоек с весами 330 и 313 каждый. Их общая сумма предоставляет нам примерно ёмкость в 974 ТБ (вес) общего сегмента корня. Когда веса стоек не равны, как в нашем примере, обычно они либо содержат различное число сегментов хостов (или просто хостов) или, что встречается более часто, лежащие в их основе хосты имеют различные веса.

Далее мы видим следующее:

  -2 83.56099 host data001
		

Это указывает на некий тип сегмента с типомhost и названием data001. Как и в случае сегментов root и rack, их общий вес отражает сырую ёмкость (до репликаций) лежащих в основе их общей иерархии сегментов. Ниже rack1 в нашей иерархии мы видим хосты с названиями data001, data002, data003 и data004. В нашем примере мы видим, что хост data002 представляет нечто с более низким весом, нежели остальные три стойки. Это может означать, что была выполнена оснастка замеса устройств с различными размерами, либо что были пропущены во время первоначального развёртывания некоторые диски. В нашем примере, однако, хост содержит 23 сегмента OSD (или просто OSD) вместо ожидаемых 24. Это отражает факт того, что имелся диск, претерпевший некий отказ и был полностью удалён, либо тот, который не был развёрнут в своём первоначальном местоположении.

В каждом из сегментов host мы видим некоторое число записей OSD.

24 3.48199 osd.24 up 1.00000 1.00000
 	   

В нашем примере все устройства являются SSD SAS, причём каждое примерно имеет номинально 3840 ГБ, что мы описываем в Главе 2, Компоненты и службы Ceph как маркетинговую ёмкость. Данное несоответствие между полученным выводом и значением веса 3.48199 ТБ, предоставляемого в данном месте объясняется рядом факторов:

Также обратите внимание, что одно из устройств, а именно data002 помечено как отключеное. Это может относиться к проблемам убитого процесса или некоторого отказа оборудования. Общий вес CRUSH остаётся неизменным, однако регулировка общего веса установлена в значение 0, что означает, что предварительно назначенные для данного устройства данные были направлены в другое место. Когда мы успешно перезапускаем данный процесс OSD, выравнивания весов возвращаются к нему и осуществляется заполнение данными данного устройства.

Отметим также, что в то время, когда многие команды Ceph будут предоставлять OSD и прочие элементы ранжированными, их идентификаторы (или имена) OSD некоторого определённого хоста или стойки являются зависимостью от истории данного кластера. При последовательном развёртывании общее число растёт инкрементально аккуратно, однако со временем OSD и хосты добавляются и удаляются В приводимом вше примере отметим, что OSD 33 (также именуемый как osd.33) в настоящее время располагается на хосте data007 вместо data002, как можно было бы ожидать исходя из предыдущего шаблона. Это отражается в следующей последовательности событий:

При развёртывании OSD, Ceph обычно выбирает самый нижний не используемый номер, в нашем случае им было значение 33. Нет никакого смысла придерживаться сопровождения какого- то определённого выделенного соглашения номера OSD, оно может изменяться со временем по мере того, как устройства и хосты приходят и уходят, а сам кластер расширяется.

Некоторое число команд состояния Ceph принимают необязательный параметр переключателя json -f или -fjson -pretty, который имеет результат менее воспринимаемый для чтения человеком вывод, однако более просто подверженный синтаксическому разбору кодом. Данный формат команд по умолчанию может изменяться между различными выпусками, однако формат вывода JSON в основном остаётся неизменным. По этой причине сценарии управления и мониторинга стимулируются на применение формата вывода -f json чтобы предоставлять непрерывное исполнение при обновлении самого Ceph.

# ceph osd tree -f json

{"nodes":[{"id":-1,"name":"default","type":"root","type_id":10,"children":[-16,-15,-14]},{"id":-14,"name":"r1","type":"rack","type_id":3,"children":[-5,-4,-3,-2]},{"id":-2,"name":"data001","type":"host","type_id":1,"children": [23,22,21,20,19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0]},{"id":0,"name":"osd.0","type":"osd","type_id":0,"crush_weight":3.481995,"depth":3,"exists":1,"status":"up","reweight":1.000000,"primary_affinity":1.000000},{"id":1,"name":"osd.1","type":"osd","type_id":0,"crush_weight":3.481995,"depth":3,"exists":1,"status":"up","reweight":1.000000,"primary_affinity":1.000000},{"id":2,"name":"osd.2","type":"osd","type_id":0,"crush_weight":3.481995,"depth":3,"exists":1,"status":"up","reweight":1.000000,"primary_affinity":1.000000},{"id":3,"name":"osd.3","type":"osd","type_id":0,"crush_weight":3.481995,"depth":3,"exists":1,"status":"up","reweight":1.000000,"primary_affinity":1.000000},{"id":4,"name":"osd.4","type":"
...
		

Данный формат вывода -f json-pretty является неким компромиссом: он содержит структуру для целей программного синтаксического разбора, но также применяет пробельные символы для того чтобы допускать простой визуальный просмотр оператором.

# ceph osd tree -f json-pretty
{
    "nodes": [
        {
            "id": -1,
            "name": "default",
            "type": "root",
            "type_id": 10,
            "children": [
                 -16,
                 -15,
                 -14
            ]
        },
        {
            "id": -14,
            "name": "1",
            "type": "rack",
            "type_id": 3,
            "children": [
                -5,
                -4,
                -3,
                -2
            ]
        },
        {
            "id": -2,
            "name": "data001",
            "type": "host",
            "type_id": 1,
            "children": [
                23,
                22,
                21,
            ...
		

В качестве примера можно выделить некий список OSD, который имеет некие не установленные по умолчанию значения корректировки весов с применением утилиты jq, которую мы упоминали в Главе 4, Планирование вашего развёртывания. Такой подход уберегает от утомительного и подверженного ошибкам кодирования с применением awk и perl.

# ceph osd tree -f json | jq \
  '.nodes[]|select(.type=="osd")|select(.reweight != 1)|.id'
11
66
		

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

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

Дамп OSD

Команда дампа osd Ceph отображает некое состояние информации нижнего уровня о нашем кластере. Она содержит некий перечень пулов с их атрибутами, а также некий список OSD, причём каждый содержит регулировки выравнивания весов, состояния поднятого/ вовлечённого (up/in) и прочего. Данная команда обычно применяется в необычных ситуациях устранения неполадок.

# ceph osd dump | head
epoch 33291
fsid 3369c9c6-bfaf-4114-9c31-ncc17014d0fe
created 2017-09-06 20:21:06.448220
modified 2017-09-17 21:38:44.530321
flags sortbitwise,require_jewel_osds
pool 1 'rbd' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 16384 pgp_num 16384 last_change 31616 flags hashpspool,nodelete,nopgchange,nosizechange stripe_width 0 removed_snaps [1~3]
max_osd 287
osd.0 up in weight 1 up_from 31886 up_thru 33113 down_at 31884 last_clean_interval [4,31884) 10.8.45.15:6800/116320 10.24.49.15:6828/1116320 10.24.49.15:6829/1116320 10.8.45.15:6829/1116
320 exists,up 34a68621-b8dc-4c3a-b47e-26acaacfc838
osd.1 up in weight 1 up_from 8 up_thru 33108 down_at 0 last_clean_interval [0,0) 10.8.45.15:6802/117132 10.24.49.15:6802/117132 10.24.49.15:6803/117132 10.8.45.15:6803/117132 exists,up f5a3a635-4058-4499-99af-1b340192e321
...
		

Список OSD

Команда Ceph ls просто возвращает некий список всех номеров OSD, в настоящее времы развёрнутых внутри нашего кластера.

# ceph osd ls | head -3
0
1
2
#
ceph osd ls |wc
   280 280 1010
#
		

Данная информация может быть получена птём обработки вывода дерева ceph osd, однако данный вариант является более удобным способом предоставления всего в единой команде.

Поиск OSD

Для локализации местоположения наперёд определённого OSD бесценной является команда ceph osd find.

# ceph osd find 66 { "osd": 66, "ip": "10.8.45.17:6836\/130331", "crush_location": { "host": "data003", "rack":
		

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

Дамп CRUSH

Данная команда предоставляет во многом ту же самую информацию, что и дерево osd ceph, хотя и в другом, JSON формате. Обратите внимание на наличие дополнительных типов сегментов (bucket), которые Ceph предварительно определяет для больших и сложных оснасток. Как и ранее, большинство из приводимых 2899 строк вывода этой команды выданной автору эталонным кластером обрезаны для краткости.

# ceph osd crush dump | more
{
    "devices": [
        {
            "id": 0,
            "name": "osd.0"
        },
        {
            "id": 1,
            "name": "osd.1"
        },
        ...
        {
            "id": 286,
            "name": "osd.286"
        }
    ],
    "types": [
        {
            "type_id": 0,
            "name": "osd"
        },
        {
            "type_id": 1,
            "name": "host"
        },
        {
            "type_id": 2,
            "name": "chassis"
        },
        {
            "type_id": 3,
            "name": "rack"
        },
        {
             "type_id": 4,
             "name": "row"
        },
        {
             "type_id": 5,
             "name": "pdu"
        },
        {
             "type_id": 6,
             "name": "pod"
        },
        {
             "type_id": 7,
             "name": "room"
        },
        {
             "type_id": 8,
             "name": "datacenter"
        },
        {
             "type_id": 9,
             "name": "region"
        },
        {
             "type_id": 10,
             "name": "root"
        }
    ],
    "buckets": [
        {
             "id": -1,
             "name": "default",
             "type_id": 10,
             "type_name": "root",
             "weight": 63890823,
             "alg": "straw",
             "hash": "rjenkins1",
             "items": [
                 {
                      "id": -14,
                      "weight": 21677267,
                      "pos": 0
                 },
                {
                      "id": -15,
                      "weight": 21677218,
                      "pos": 1
                },
                {
                      "id": -16,
                      "weight": 20536338,
                      "pos": 2
                }
             ]
        },
        {
             "id": -2,
             "name": "data001",
             "type_id": 1,
             "type_name": "host",
             "weight": 5476704,
             "alg": "straw",
             "hash": "rjenkins1",
             "items": [
                 {
                      "id": 0,
                      "weight": 228196,
                      "pos": 0
                 },
                 {
                      "id": 1,
                      "weight": 228196,
                      "pos": 1
                 },
                 ...
		

Ceph позволяет нам создавать множество пулов хранения, причём для каждого из них определять размеры и атрибуты в соответствии с их уникальными потребностями. Например, в некоторой оснастке OpenStack можно обнаружить некий большой пул Cinder, пул Glance с размером от среднего до большого и, возможно, ряд пулов для необходимой службы RGW. Мы обсудим дополнительно пулы в прочих главах, а здесь мы всего лишь покажем ряд команд для управления ими.

Чтобы просто выдать перечень предоставляемых пулов:

# rados lspools
rbd
# ceph osd lspools
1 rbd,
		

Порой имеется множество способов выполнения заданной задачи в рамках Ceph. Вот ещё один пример, показывающий значительное созвездие пулов, созданных для OpenStack и определённой службы RADOS GateWay с помощью выпуска Ceph Firefly. та же самая информация может быть также отображена посредством ceph osd pool ls detail.

# ceph osd dump | grep pool
pool 3 'csi-a-cinder-volume-1' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 16384 pgp_num 16384 last_change 261136 stripe_width 0
pool 4 csi-a-glance-image-1' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 16384 pgp_num 16384 last_change 261134 stripe_width 0
pool 5 '.rgw' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 882 stripe_width 0
pool 6 '.rgw.control' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 884 stripe_width 0
pool 7 '.rgw.gc' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 886 stripe_width 0
pool 8 '.log' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 888 stripe_width 0
pool 9 '.intent-log' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 890 stripe_width 0
pool 10 '.usage' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 892 stripe_width 0
pool 11 '.users' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 894 stripe_width 0
pool 12 '.users.email' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 896 stripe_width 0
pool 13 '.users.swift' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 898 stripe_width 0
pool 14 '.users.uid' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 165075 stripe_width 0
pool 15 '.rgw.buckets' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 16384 pgp_num 16384 last_change 902 stripe_width 0
pool 17 'css-a-glance-image-1' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 16384 pgp_num 16384 last_change 906 stripe_width 0
pool 18 '.rgw.root' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change 908 stripe_width 0
pool 19 '.rgw.buckets.index' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 261117 stripe_width 0
pool 20 '' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change
		

Мы видим, что каждый пул настроен на сопровождение трёх копий данных и на продолжение операций обслуживания если активны только два. Указан набор правил CRUSH; в данном случае все пулы применяют тот же самый набор правил, который общепринят при оснастке Ceph. Все три самых больших пула содержат каждый по 16 384 Групп размещения. Мы обсудили некоторые из этих настроек и их далеко идущие последствия в Главе 4, Планирование вашего развёртывания, а также мы погрузимся в остальные в Главе 8, Архитектура Ceph: под капотом.

Да, также присутствует некий пул с каким- то нулевым именем, который является искусственным объектом неверной настройки автоматической инвентаризации. Если у вас также случилось нечто подобное, воспользуйтесь приводимой ниже командой для очистки:

# rados rmpool "" "" --yes-i-really-really-mean-it
successfully deleted pool
		

Ceph действительно желает быть уверенным что мы хотим удалить этот пул, именно поэтому он заставляет нас ввести его название дважды, а также настоятельно просит подтвердить переключение. Начиная с Jewel и последующих редакций присутствует ещё один этап, чтобы мы могли действительно, на самом деле, РЕАЛЬНО убедиться что мы не случайно удаляем некий промышленный пул (а с ним и свои задания).

# ceph osd pool set csi-a-cinder-volume-1 nodelete true
		

Мы обсуждали Мониторы Ceph (также именуемые MON или mon) более подробно в других главах, однако мы также опишем их слегка и здесь для контекста. Мониторы Ceph сопровождают и обслуживают обильную информацию о топологии и состоянии кластера. Таким образом они выступают в роли некоторого центра обмена информацией, принимая соединения и обновления от прочих демонов Ceph, в том числе от прочих MON, OSD и экземпляров MDS.

Мониторы Ceph работают как некий кластер, эксплуатируя алгоритм согласования Paxos для обеспечения гарантии согласованности операций в виде кворума. Жизненно важная информация, собираемая и распространяемая Мониторами включает в себя:

Карта Мониторов и информация о состоянии кворума могут быть отображены посредством команд ceph mon stat и ceph mon dump.

# ceph mon stat
e2: 5 mons at {mon001=10.8.45.10:6789/0,mon002=10.8.45.11:6789/0,mon003=10.8.45.143:6789/0,mon004=10.8.46.10:6789/0,mon005=10.8.46.11:6789/0}, election epoch 24, quorum 0,1,2,3,4 mon001,mon002,mon003,mon004,mon005

# ceph mon dump
dumped monmap epoch 2
epoch 2
fsid 3369c9c6-bfaf-4114-9c31-576afa64d0fe
last_changed 2017-09-06 20:21:09.396928
created 2017-09-06 20:20:42.336193
0: 10.8.45.10:6789/0 mon.mon001
1: 10.8.45.11:6789/0 mon.mon002
2: 10.8.45.143:6789/0 mon.mon003
3: 10.8.46.10:6789/0 mon.mon004
4: 10.8.46.11:6789/0 mon.mon05
		

Получаемый в результате исполнения ceph mon stat может выглядеть аналогично: саму команду ceph status мы изучим позже в данной главе, включая именно эту информацию.

Чтобы проверить состояние MDS Ceph, выполните ceph mds stat или ceph mds dump.

# ceph mds stat
e85: 1/1/1 up {0=ceph-mds001=up:active}

# ceph mds dump
dumped mdsmap epoch 85
epoch 85
flags 0
created 2017-10-20 11:11:11.1138
modified 2017-10-22 13:13:13.1701
tableserver 0
root 0
session_timeout 60
session_autoclose 300
max_file_size 1099511627776
last_failure 0
last_failure_osd_epoch 666
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}
max_mds 1
in 0
up {0=1138}
failed
stopped
data_pools 0
metadta_pool 1
inline_data disabled
1138: 196.168.1.1:6800/2046 'ceph-mds001' mds.0 13 up; active seq 4252
		

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

Демоны и клиенты Ceph при запуске считывают /etc/ceph/ceph.conf чтобы загрузить установки конфигурации и прочую информацию о кластере для самого кластера с названием ceph. Существуют сотни значений, которые могут быть установлены, однако, к счастью, нам в основном потребуется сосредоточиться на гораздо меньшем подмножестве.

Файл настроек загрузки определяет значения, которые необходимы компонентам Ceph для загрузки и поиска всего остального. Многие администраторы Ceph полагают, что этот файл всегда имеет название /etc/ceph/ceph.conf, однако возможны и другие имена. Данный каталог /etc/ceph является определяемым по умолчанию местоположением, однако данная основа имени файла на самом деле является названием некоторого заданного кластера, который сам по себе по умолчанию имеет значение Ceph. Многие установки, в особенности те, которые содержат единственный кластер, оставляют это значение по умолчанию, однако персональные названия становятся всё более популярными.

На протяжении данной книги мы пишем в терминах установленного по умолчанию названия кластера ceph, однако, допустим, мы пожелаем назвать свой кластер как cephelmerman. Наш файл настроек можно будет отыскать в /etc/ceph/cephelmerman.conf. Большинство команд по умолчанию работают с кластером, имеющим название ceph, однако теперь нам понадобится добавлять определённый переключатель --cluster cephelmerman с тем, чтобы они могли отыскивать соответствующие компоненты кластера. Это быстро становится утомительным, однако Ceph снабжает нас сокращением содержимого -- с тем чтобы имеющаяся переменная среды CEPH_ARGS добавлялась к основным командам. Поэтому в нашем примере вместо следующего набора:

# ceph status --cluster cephelmerman
# ceph -s --cluster cephelmerman
# ceph osd tree --cluster cephelmerman
		

мы можем выполнить (с помощью своей оболочки bash):

# export CEPH_ARGS="--cluster cephelmerman"
# ceph status
# ceph -s
# ceph osd tree
		

На самом деле мы рекомендуем применять устанавливаемое по умолчанию наименование кластера, если только у вас нет убедительной причины изменять его. Что касается редакции Jewel, Ceph по- прежнему страдает несколькими ошибками с не устанавливаемыми по умолчанию названиями, а наша утилита ceph-deploy, которую мы рассмотрим позже в данной главе, ещё пока не отдаёт должного внимания CEPH_ARGS.

Также имеется возможность - хотя это и не очень обычно - исполнять более одного логического кластера Ceph на одном и том же наборе оборудования. При запуске системы Ceph попытается запустить демоны для любого файла настройки в /etc/ceph, то есть, любой файл, соответствующий определённому шаблону /etc/ceph/*.conf. Таким образом, в данной не очень распространённой ситуации мы можем наблюдать нечто подобное следующему:

# ls -1 /etc/ceph
ceph.conf
cephelmerman.conf
music.conf
rhythm.conf
		

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

# ls -1 /etc/ceph
ceph.CR1138.conf
ceph.OLD.conf
ceph.conf
ceph.conf.old
ceph.old.conf
ceph.firefly.conf
		

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

Файлы настройки Ceph состоят из множества разделов, причём один глобальный и по одному для каждого основного компонента демона Ceph. Некоторые записи являются обязательными; многие опциональными. Каждый раздел начинается с заключённого в квадратные скобки названия, некоторого соглашения, которое часто именуется как определённый формат INI после его широкого распространённого использования в MS-DOS. давайте пройдём по этим разделам с некоторыми примерами их содержимого. Мы начнём с файла ceph.conf из своего кластера песочницы, который мы изучили в Главе 5, Развёртывание виртуального кластера песочницы.

# cat /etc/ceph/ceph.conf
[global]
fsid = 5591400a-6868-447f-be89-thx1138656b6
max open files = 131072
mon initial members = ceph-mon0
mon host = 192.168.42.10
public network = 192.168.42.0/24
cluster network = 192.168.43.0/24

[client.libvirt]
admin socket = /var/run/ceph/$cluster-$type.$id.$pid.$cctid.asok
log file = /var/log/ceph/qemu-guest-$pid.log
[osd]
osd mkfs type = xfs
osd mkfs options xfs = -f -i size=2048
osd mount options xfs = noatime,largeio,inode64,swalloc
osd journal size = 100

[client.restapi]
public addr = 192.168.42.10:5000
keyring = /var/lib/ceph/restapi/ceph-restapi/keyring
log file = /var/log/ceph/ceph-restapi.log
		

Раздел [global] содержит установки, которые являются общими для всех компонентов некоторой оснастки Ceph. Вводимые здесь установки будут применены ко всем компонентам Ceph только если они не переопределены в последующих, специфичных для компонентов разделах.

Мы немного обсудим fsid в последующих главах; если кратко, это уникальный идентификатор для некоторого данного кластера и должен присутствовать.

Следующие сроки mon initial members и mon host тем не менее обязательны; они разрешают Мониторам Ceph отыскивать друг друга. Эти строки также помогают OSD, RADOS Gateway и прочим демонам Ceph обнаруживать Мониторы кластера.

Определение public network также является необходимым; он определяет некий диапазон сетевых адресов для кластера Мониторов Ceph. Если cluster network присутствует, он определяет некую выделенную сетевую среду IP для обмена репликациями Ceph. Если cluster network не определён, весь обмен будет совместно применять public network.

Раздел [client.libvirt] содержит установки, относящиеся к клиентам виртуализации, таким как QEMU. Здесь данный клиент ожидается имеющим название client.libvirt и должен обладать соответствующим кольцом ключей для успешной аутентификации в данном кластере. Отметим, что данный раздел не должен присутствовать в файлах ceph.conf для узлов MON, OSD и RGW, однако ничего страшного если он там присутствует. Может быть удобным включать все разделы в соответствующий файл ceph.conf для каждого типа узла Ceph; это может более простым в управлении настройкой. В данном примере мы определили некий admin socket к которому можно подключаться для запроса текущего состояния библиотеки клиента внутри нашего гипервизора. Мы обсудим сокеты администратора позже в этой главе. наша вторая строка определяет некий log file, в который наш клиент должен записывать события и прочие сообщения.

Раздел [osd] часто привлекает основное внимание администраторов Ceph. В нашем примере, osd mkfs type указывает, что FileStore OSD должен предоставлять файловую систему XFS вместо EXT4 или btrfs.

Следующая строка sd mkfs options xfs даёт перечень вариантов, которые необходимо определить в данной командной строке когда данный OSD предоставляет исполнение процесса mkfs.xfs. Данная опция в нашем примере дублирует установку по умолчанию, встроенную в Ceph, однако это может быть полезным иметь её настроенной в явном виде с тем, чтобы эти параметры для новых OSD были совершенно ясными. Может показаться привлекательным добавить здесь -n size=65536 чтобы попытаться сберечь такты ЦПУ. Не делайте этого. Варианты применения Ceph не получают выгод от нестандартных настроек в данном месте и автор этих строк свидетельствует, что они принесут вам невыразимые страдания. Установленные по умолчанию значения почти всегда являются наилучшими для всех. Другие варианты возможны, только если вы на самом деле знаете что делаете и понимаете, что возврат обратно требует уничтожения всех созданных с их помощью OSD.

Далее мы видим связанную с osd mount options xfs запись. Здесь вновь лучше работают для почти всех приложений установки Ceph по умолчанию; изменяйте их только если вы тщательно это изучили. В отличии от опций mkfs, опции монтирования могут применяться при каждом монтировании OSD FileStore во время запуска системы, поэтому изменения здесь могут применяться после остановки данных процессов OSD, размонтирования их файловых систем и повторного запуска. Несколько более ядерная, но вполне разумная альтернатива состоит во временной установке имеющегося флага noout и простой перезагрузки данного сервера.

Последним в нашем примере раздела [osd] является osd journal size. Наша песочница не обслуживает реальную рабочую нагрузку поэтому данное значение необычно низко с тем, чтобы не напрягать виртуализацию настольной системы. Предлагаемое в промышленной реализации значение составляет 10240, что выделяет некий раздел в 10 ГБ при совместном размещении журналов FileStore. Это значение рекомендуется в качестве безопасного единого- размера- для- всех. Вы можете никогда не заполнить некий журнал 10 ГБ до его сброса, однако запас прочности это самый простой из компромиссов вместо того чтобы сберечь несколько обычных ГБ для файловой системы FileStore.

Самым последним разделом в нашем примере является [client.restapi]. Этот раздел требуется только при применении API REST для опроса и управления кластерами Ceph извне.

При использовании службы RGW также необходим некий дополнительный раздел для него.

Все демоны Ceph (и клиент, если он включён), осуществляют ожидание в некотором сокете Администрирования запросов для получения или установки информации или для осуществления определённых действий. Мы можем обнаружить эти сокеты в /var/run/ceph; вот примеры для узлов OSD и MON.

osd-1701# ls /var/run/ceph
ceph-osd.0.asok ceph-osd.10.asok ceph-osd.11.asok
ceph-osd.12.asok ceph-osd.13.asok ceph-osd.14.asok
ceph-osd.15.asok ceph-osd.16.asok ceph-osd.17.asok
ceph-osd.18.asok ceph-osd.19.asok ceph-osd.1.asok
ceph-osd.20.asok ceph-osd.21.asok ceph-osd.22.asok
ceph-osd.23.asok ceph-osd.2.asok ceph-osd.3.asok
ceph-osd.4.asok ceph-osd.5.asok ceph-osd.69.asok
ceph-osd.7.asok ceph-osd.8.asok ceph-osd.9.asok

mon-05# ls /var/run/ceph
ceph-mon.mon05.asok
		

Для взаимодействия с osd.69 мы сначала устанавливаем ssh со своей системой osd-1701. Затем мы можем опросить административный сокет машины osd.69 что он может делать для нас.

# ceph daemon osd.69 help
{"
config diff": "dump diff of current config and default config",
"config get": "config get <field>: get the config value",
"config set": "config set <field> <val> [<val> ...]: set a config
variable",
"config show": "dump current config settings",
"dump_blacklist": "dump blacklisted clients and times",
"dump_blocked_ops": "show the blocked ops currently in flight",
"dump_historic_ops": "show slowest recent ops",
"dump_op_pq_state": "dump op priority queue state",
"dump_ops_in_flight": "show the ops currently in flight",
"dump_reservations": "show recovery reservations",
"dump_watchers": "show clients which have active watches, and on which objects",
"flush_journal": "flush the journal to permanent store",
"get_command_descriptions": "list available commands",
"get_heap_property": "get malloc extension heap property",
"get_latest_osdmap": "force osd to update the latest map from the mon",
"getomap": "output entire object map",
"git_version": "get git sha1",
"help": "list available commands",
"injectdataerr": "inject data error to an object",
"injectmdataerr": "inject metadata error to an object",
"log dump": "dump recent log entries to log file",
"log flush": "flush log entries to log file",
"log reopen": "reopen log file",
"objecter_requests": "show in-progress osd requests",
"ops": "show the ops currently in flight",
"perf dump": "dump perfcounters value",
"perf reset": "perf reset <name>: perf reset all or one perfcounter name",
"perf schema": "dump perfcounters schema",
"rmomapkey": "remove omap key",
"set_heap_property": "update malloc extension heap property",
"set_recovery_delay": "Delay osd recovery by specified seconds",
"setomapheader": "set omap header",
"setomapval": "set omap key",
"status": "high-level status of OSD",
"truncobj": "truncate object to length","version": "get ceph version"
}
		

Святые угодники! Для повседневных операций нам нет нужды сразу или даже примерно ознакомиться со всеми этими командами; многие из них полезны в первую очередь для поиска загадочных неисправностей и задач разработки. Наиболее часто применяемые команды находятся в верхней части данного списка.

В данной главе и в Главе 11, Настройка производительности и надёжности мы обсудим ряд установок настоек Ceph. Все команды представленные данным сокетом администрирования делают для нас возможным выделять имеющиеся в настоящее время установки изнутри заданного OSD или MON. Просто смеха ради, давайте посмотрим сколько их имеется на этот раз в системе Ceph Jewel:

# ceph daemon osd.1701 config show | wc -l
1116
		

Чёрт побери! Более тысячи установок. Как мы можем даже надеяться понять как их все тюнинговать? Как мы это подробнее рассмотрим в следующем разделе, большая их часть нам не понадобится. Каждая версия Ceph всё больше улучшает поведение и установки по умолчанию; подавляющее большинство этих настроек лучше оставить в покое, если только у вас нет причины в действительности знать что мы делаем. Среди наиболее часто подлежащих регулировке установок те, которые оказывают влияние на заполнение и перестроение.

# ceph daemon osd.1701 config show | egrep backfill\|recovery
  "osd_max_backfills": "3",
  "osd_min_recovery_priority": "0",
  "osd_backfill_full_ratio": "0.9",
  "osd_backfill_retry_interval": "10",
  "osd_allow_recovery_below_min_size": "true",
  "osd_recovery_threads": "1",
  "osd_backfill_scan_min": "64",
  "osd_backfill_scan_max": "512",
  "osd_recovery_thread_timeout": "30",
  "osd_recovery_thread_suicide_timeout": "300",
  "osd_recovery_sleep": "0",
  "osd_recovery_delay_start": "0",
  "osd_recovery_max_active": "3",
  "osd_recovery_max_single_start": "1",
  "osd_recovery_max_chunk": "8388608",
  "osd_recovery_max_omap_entries_per_chunk": "64000",
  "osd_recovery_forget_lost_objects": "false",
  "osd_scrub_during_recovery": "true",
  "osd_kill_backfill_at": "0",
  "osd_debug_skip_full_check_in_backfill_reservation": "false",
  "osd_debug_reject_backfill_probability": "0",
  "osd_recovery_op_priority": "3",
  "osd_recovery_op_warn_multiple": "16"
		

Снова шьёрт побери! Двадцать три установки только для перестроения и заполнения! И снова, большую их часть лучше не трогать, однако ниже мы объясним некоторые из них, которые обычно подлежат настройке. Лучшая практика для того чтобы узнать что подлежит настройке, а что не следует трогать - это ошибки на той стороне определений по умолчанию, пока не появятся изменения в исследованиях, профессиональных советах и/ или при тщательной проверке.

Другим методом выделения информации из работающих демонов Ceph является команда ceph tell, исполняемая в Мониторе или узле администратора.

# ceph tell osd.* version

osd.0: {
    "version": "ceph version 10.2.6 (656b5b63ed7c43bd014bcafd81b001959d5f089f)"
} 
osd.1: {
    "version": "ceph version 10.2.6 (656b5b63ed7c43bd014bcafd81b001959d5f089f)"
} 
osd.2: {
    "version": "ceph version 10.2.6 (656b5b63ed7c43bd014bcafd81b001959d5f089f)"
}
...
		

Она предлагает более ограниченный набор функциональности в сравнении с той, что предоставляется сокетами администрирования, однако эта версия команды очень полезна когда требуется удостовериться, что все компоненты некоторого кластера работают с ожидаемыми (и обычно теми же самыми) версиями выпуска.

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

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

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

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

Давайте изучим некоторые примеры из реальной жизни такой инъекции значений и также рассмотрим два важных возражения.

Одним распространённым вариантом для инъекции является регулировка установок, которые воздействуют на скорость и распространение операций заполнения и перестроения. Ceph инициирует их по мере требований для сопровождения репликации данных когда OSD поднимаются и падают, либо добавляются или удаляются из данного кластера. Естественным желанием является чтобы данный процесс выполнялся так быстро, как это только возможно, чтобы данный кластер получал оптимальную эластичность. Операции перестроения, однако, могут вступать в единоборство с вводом/ выводом клиента; в процессе интенсивного перестроения пользователи могут заметить значительную деградацию производительности и даже отказ операций.

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

Таблица 6-1.

Параметр	Значение
osd_recovery_max_single_start (эта установка может быть недокументированной в Hammer)	5
osd_max_backfills	10
osd_recovery_op_priority	10
osd_recovery_max_active	15

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

# ceph tell osd.\* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_max_single_start 1 --osd_recovery_op_priority 1'
osd.0: osd_max_backfills = '1' osd_recovery_max_active = '1' (unchangeable) osd_recovery_max_single_start = '1' (unchangeable) osd_recovery_op_priority = '1' (unchangeable)
osd.1: osd_max_backfills = '1' osd_recovery_max_active = '1' (unchangeable) osd_recovery_max_single_start = '1' (unchangeable) osd_recovery_op_priority = '1' (unchangeable)
    ...
		

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

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

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

Важным ограничением инъекции является то, что поскольку она изменяет только текущую конфигурацию и не сохраняется в настройках, изменения могут быть утрачены при любом перезапуске каждого демона или перезапуске любого сервера. Настройка с помощью инъекции неоценима для немедленного изменения с минимальными разрушающими воздействиями, в особенности при проверках действия заданного набора значений. Инъекция помогает нам быстро реагировать на происшествия внутри нашего кластера, а также временно оптимизировать профили поведения на время проведения технического обслуживания. Настройки, которые мы бы хотели сохранять на постоянной основе, должны также записываться в ceph.conf или они будут утрачены при последующих перезапусках серверов.

Многие администраторы Ceph эксплуатируют программное обеспечение управления настройкой чтобы обеспечивать правильность и согласованность приложений пакетов или файлов настроек. Популярные системы включают в Puppet, Chef, Ansible и cfengine. Эти системы бесценны при обеспечении того, чтобы все системы оставались согласованными и актуальными на протяжении всего жизненного цикла, в особенности при изменении настроек конфигурации и приходе/ уходе хостов.

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

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

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

Разрушение данных редко, но случается, некий феномен научно описываемый как деградация бит (bit-rot). Иногда мы делаем на диск запись, а сбой поверхности или ячейки имеет результатом ошибку чтения или считывание не того что мы записали. Ошибка настройки HBA, расслоение расширителя SAS, дефекты архитектуры встроенного программного обеспечения, электронные ошибки устройства, а также сбои поверхности могут разрушать данные. Ошибки поверхности воздействуют примерно как 1 на 10¹⁶ для приблизительно 1 из 1 на 10¹⁴ хранимых на HDD бит. Устройства также могут сбрасываться из- за ошибок оператора или даже из- за грохота погрузчика. Автор этих строк даже встречался с буквальной деградацией бит из- за космических лучей.

Ceph существует для усиленной целостности данных и имеет некий механизм предупреждения нас о подобных ситуациях: выскребания (scrubs, промывка, очистка {Прим. пер.: мы придерживаемся термина выскребание из- за смысловой перегрузки термина очистка, а также полагаем его запоминающимся}). Выскребания является чем- то аналогичным fsck в некоторой файловой системе, а также патрулирующему чтению или сканированию поверхностей, которые исполняют многие HBA. Основная идея состоит в проверке всех копий репликаций данных чтобы убедиться в том, что они взаимно согласованы. Поскольку копии данных распределяются посредством имеющегося кластера, это осуществляется с гранулярностью Групп размещения (PG, Placement Group). Каждый Объект Группы размещения совместно размещается в одном и том же наборе OSD, поэтому он естественно и действенно выскребает их все вместе.

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

Выскребания Ceph, как солнечные очки, бывают двух классов: лёгкие (light) и глубокие (deep).

Лёгкия выскребания, также именуемые как поверхностные (shallow) или просто выскребания (scrubs), являются, по- существу, легковесными и по умолчанию осуществляются для каждой Группы размещения каждый день. Они вычисляют контрольные суммы и сравнивают только метаданные объекта (такие как размер, XATTR и данные omap) и выполняется быстро, а также без потребления больших объёмов ресурсов по своему пути. Ошибки файловой системы и редкие неточности Ceph могут улавливаться поверхностным выскребанием.

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

Многие операторы Ceph полагают, что даже еженедельные прогоны приводят к неприемлемому воздействию и применяют установку параметра osd_deep_scrub_interval в ceph.conf чтобы распространить его на более длинный период. Также имеются опции для выравнивание глубоких выскребаний на нерабочие часы или прочие времена с меньшими клиентскими рабочими нагрузками. Можно также предотвращать в глубоких выскребаниях медленные перестроения (так как Ceph рандомизирует перестроение репликации данных) путём настройки osd_scrub_during_recovery в значение false. Это применяется на уровне гранулярности Групп размещения, не по всему кластеру, и помогает избегать ужасных блокирующих запросов, которые можно получать когда операции выскребания и перестроения выравниваются чтобы разбить досадный обмен пользователя.

Установки выскребания могут регулироваться динамически в имеющемся кластере с помощью механизма инъекций, который мы исследовали ранее в данной главе с указанием необходимого предостережения относительно изменения на постоянной основе. Допустим, наш благословенный кластер стал жертвой собственного успеха и мы находим, что глубокие выскребания становятся через чур агрессивными и мы бы хотели выделять им пространство только по истечению четырёх недель вместо того чтобы навязывать его всего через неделю, однако не хотим последовательно перезапускать сотни демонов OSD. Мы можем установить изменения в ceph.conf, а также сразу обновить работающие настройки (Помните: это значение определяется в секундах; 4 недели x 7 дней x 24 часа x 60 секунд = 2419200).

# ceph tell osd.* injectargs '--osd_deep_scrub_interval 2419200'
		

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

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

# ceph osd set noscrub
set noscrub
# ceph osd set nodeep-scrub
set nodeep-scrub
...
# ceph osd unset noscrub
# ceph osd unset nodeep-scrub
		

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

Вот некий пример ошибок HDD, обусловленных просчётами в архитектуре встроенного программного обеспечения устройств, выливающихся в некую несогласованную Группу размещения. Общий вид таких ошибок меняется в зависимости от типа устройств, дистрибутива Linux, а также версии ядра, однако они схожи в отношении представления данных.

Dec 15 10:55:44 csx-ceph1-020 kernel: end_request: I/O error, dev sdh, sector 1996791104
Dec 15 10:55:44 csx-ceph1-020 kernel: end_request: I/O error, dev sdh, sector 3936989616
Dec 15 10:55:44 csx-ceph1-020 kernel: end_request: I/O error, dev sdh, sector 4001236872
Dec 15 13:00:18 csx-ceph1-020 kernel: XFS (sdh1): xfs_log_force: error 5 returned.
Dec 15 13:00:48 csx-ceph1-020 kernel: XFS (sdh1): xfs_log_force: error 5 returned.
...
		

Здесь мы наблюдаем определённый общий шаблон при котором ошибки устройства приводят в результате к большому числу ошибок файловой системы.

Наш сервер в приведённом выше примере использует некий HBA, который может управляться с помощью утилиты LSI storcli, поэтому давайте посмотрим что мы можем обнаружить относительно того что произошло.

[root@csx-ceph1-020 ~]# /opt/MegaRAID/storcli/storcli64 /c0 /eall /s9 show all | grep Error
Media Error Count = 66
Other Error Count = 1
		

В этих HBA Media Error Count обычно отражает ошибки поверхности (носителя), а Other Error Count отражает нечто более системное, такое как отказы электронных устройств или внезапные сбросы.

Вот некая выборка журнала, которая отображает старательное описание глубокого выскребания Ceph, которое воздействует на реплики данных.

2015-12-19 09:10:30.403351 osd.121 10.203.1.22:6815/3987 10429 : 
[ERR] 20.376b shard 121: soid
a0c2f76b/rbd_data.5134a9222632125.0000000000000001/head//20
candidate had a read error
2015-12-19 09:10:33.224777 osd.121 10.203.1.22:6815/3987 10430 :
[ERR] 20.376b deep-scrub 0 missing, 1 inconsistent objects
2015-12-19 09:10:33.224834 osd.121 10.203.1.22:6815/3987 10431 :
[ERR] 20.376b deep-scrub 1 errors
		

Это впослежствии отображается в получаемом выводе ceph health или ceph status.

root@csx-a-ceph1-001:~# ceph status
  cluster ab84e9c8-e141-4f41-aa3f-bfe66707f388
    health HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
    osdmap e46754: 416 osds: 416 up, 416 in
    pgmap v7734947: 59416 pgs: 59409 active+clean, 1
    active+clean+inconsistent, 6 active+clean+scrubbing+deep

root@csx-a-ceph1-001:~# ceph health detail
HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
pg 20.376b is active+clean+inconsistent, acting [11,38,121]
1 scrub errors
		

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

Процесс исправления некоторой несогласованности Групп размещения обычно начинается с идентификации хворого OSD; приводимое выше сообщение отправляет нас к osd.121. Мы применяем ту процедуру, которая описывается более подробно далее в этой главе для удаления данного OSD из обслуживания. Его удаление может очистить такое несогласованное состояние данной Группы размещения, либо нам понадобится его перестроение вручную.

root@csx-a-ceph1-001:~# ceph pg repair 20.376b
		

Это позволяет Ceph заменить неисправные реплики данных, считывая чистые, заслуживающие доверия копии из тех OSD, которые находятся в распоряжении имеющегося Множества активных (Active Set). {Прим. пер.: см. также пост Проверка Групп размещения (PG) Ceph на непротиворечивость в фоновом режиме и способы перестроения данных}.

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

Ceph может быть настроен на ведение журнала напрямую через имеющуюся центральную службу syslog или rsyslog, однако по умолчанию он осуществляет записи в локальные файлы. Это управляется возможностью имеющейся комплектации Linux logrotate. Вот установленные по умолчанию строфы обращения, которые устанавливает редакция Jewel Ceph.

# cat /etc/logrotate.d/ceph.logrotate
/var/log/ceph/*.log {
    rotate 7
    daily
    compress
    sharedscripts
    postrotate
    killall -q -1 ceph-mon ceph-mds ceph-osd ceph-fuse radosgw || true
    endscript
    missingok
    notifempty
    su root ceph
}
		

Устанавливаемое по умолчанию удержание данных выполняет хранение на протяжении 7 дней, что пишущий этот текст авто считает черезчур коротким. Для увеличения до четырёх недель замените 7 на 30, но убедитесь, что та файловая система, где обретается /var/log имеет достаточное свободное пространство. Как мы отметим далее в этой главе, журналы Ceph могут становиться порой очень большими и скромно снабжаемые системы могут испытывать переполнение файловых систем. Чтобы смягчить такой риск засора журналов (забитых журналов?) может оказаться целесообразным добавление директивы maxsize для записи журналов поверх с начала и их сжатия чаще чем на ежедневной основе в случае роста их размера. Компромисс состоит в том, чтобы протоколируемые сообщения не всегда будут аккуратно делиться на в точности фрагменты по 24 часа, однако zcat и zgrep быстро станут вашими лучшими друзьями.

Мониторы Ceph по умолчанию записывают журналы в /var/log/ceph/ceph-mon.hostname.log. У каждого сервера MON кроме того имеется также некий глобальный журнал кластера, по умолчанию записываемый в /var/log/ceph/ceph.log. Такая скомбинированная информация в последнем поможет соотносить активность во всём созвездии демонов развёрнутых Ceph, поэтому в данной главе мы сосредоточимся на ней. Данные установленные по умолчанию имена файлов являются некоторой функцией имеющегося по умолчанию названия кластера, которым, как вы успели сообразить, является ceph. Хитро, не так ли? Можно настроить некий кластер с применением нестандартного названия; мы кратко обсудим далее это в контексте настройки именования файла настроек. На протяжении данной книги мы в основном пишем исходя из терминологии именования кластера по умолчанию. В основном. Это уменьшает беспорядок в полях текста, который может быть неловко обёрнут. Большинство администраторов Ceph катятся с установленным по умолчанию названием, а, что касается поддержки индивидуальных имён в выпуске Jewel LTS, она всё ещё не выполнена в определённых утилитах.

OSD ведёт протокол в некотором файле, с названием, которое содержит его идентификационный номер. Например, National Creature Consortium может смело работать с кластером Ceph, имеющим нестандартное имя, чьи файлы журнала OSD именуются, скажем, как /var/log/ceph/ncc-osd.1701.log. Давайте укажем те записи, которые можно обнаружить в каждом.

2017-09-15 00:16:55.398807 osd.83 10.8.45.18:6822/127973 788 :
cluster [INF] 0.26c5 deep-scrub starts
2017-09-15 00:16:56.800561 osd.177 10.8.45.148:6818/129314 572 :
cluster [INF] 0.691 deep-scrub ok
2017-09-15 00:17:02.032534 mon.0 10.8.45.10:6789/0 418279 : cluster
[INF] pgmap v372250: 16384 pgs: 2 active+clean+scrubbing, 3
active+clean+scrubbing+deep, 16379 active+clean; 77786 GB data, 228
TB used, 596 TB / 825 TB avail
2017-09-15 00:16:55.958743 osd.142 10.8.45.146:6844/137783 793 :
cluster [INF] 0.3833 scrub starts
2017-09-15 00:17:00.607877 osd.83 10.8.45.18:6822/127973 789 :
cluster [INF] 0.26c5 deep-scrub ok
2017-09-15 00:17:01.329174 osd.88 10.8.45.18:6832/132624 918 :
cluster [INF] 0.19bb scrub ok
 	   

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

2017-09-15 19:23:52.733080 mon.0 10.8.45.10:6789/0 473491 : cluster [INF] pgmap v419600: 16384 pgs: 1 active+clean+scrubbing, 16383 active+clean; 77786 GB data, 228 TB used, 596 TB / 825 TB avail
2017-09-15 19:23:52.749005 mon.0 10.8.45.10:6789/0 473493 : cluster [INF] osdmap e19228: 238 osds: 237 up, 238 in
 	   

Зесь приводятся записи окончания того же самого дня, отображающие суммирование всех osdmap, причем один OSD отключён.

2017-09-15 19:24:00.513677 osd.16 10.8.45.15:6832/131296 808 :
cluster [INF] 0.b0 starting backfill to osd.33 from (0'0,0'0] MAX
to 7447'3975
2017-09-15 19:24:32.733030 mon.0 10.8.45.10:6789/0 473556 : cluster
[INF] HEALTH_WARN; 331 pgs backfill_wait; 93 pgs backfilling; 132
pgs stuck unclean; recovery 1115024/60328695 objects misplaced (1.848%)
2017-09-15 19:24:32.889755 mon.0 10.8.45.10:6789/0 473557 : cluster
[INF] pgmap v419645: 16384 pgs: 331 active+remapped+wait_backfill,
93 active+remapped+backfilling, 15960 active+clean; 77786 GB data,
228 TB used, 599 TB / 828 TB avail; 1113183/60328695 objects
misplaced (1.845%); 15548 MB/s, 3887 objects/s recovering
2017-09-15 19:24:33.922688 mon.0 10.8.45.10:6789/0 473558 : cluster
[INF] osdmap e19237: 238 osds: 238 up, 238 in
2017-09-15 19:24:33.937792 mon.0 10.8.45.10:6789/0 473559 : cluster
[INF] pgmap v419647: 16384 pgs: 331 active+remapped+wait_backfill,
93 active+remapped+backfilling, 15960 active+clean; 77786 GB data,
228 TB used, 599 TB / 828 TB avail; 1112020/60328695 objects
misplaced (1.843%); 8404 MB/s, 2101 objects/s recovering
 	   

Здесь наш osdmap отображает что наш отключённый OSD теперь вернулся обратно и данные были переустановлены с тем, чтобы использовать его. Отметим записи pgmap. Они показывают 93 активно заполняющиеся отдельные Группы размещения и при этом 331 дожидаются своей очереди. В разделе Настройки ранее мы касались установок Ceph, которые ограничивают объём заполнения / перестроения в любой момент времени. Это расширяет наше воздействие для защиты работы пользователей.

2017-09-16 00:16:56.093643 mon.0 10.8.45.10:6789/0 511866 : cluster [INF] pgmap v441064: 16384 pgs: 16384 active+
 	   

Далее давайте проверим записи в журнале osd.8. Так как OSD Ceph намного больше чем Мониторов и они обрабатывают гораздо большее число транзакций, мы обнаружим, что они растут намного быстрее. Обязательно выделите им достаточное пространство. Как и ранее, данный кластер исполняет редакцию Jewel Ceph.

2017-09-18 00:19:08.268212 7fe07b990700 1 leveldb: Compacting 4@0
+ 5@1 files
2017-09-18 00:19:08.327958 7fe07b990700 1 leveldb: Generated table
#14159: 55666 keys, 2129686 bytes
2017-09-18 00:19:08.382062 7fe07b990700 1 leveldb: Generated table
#14160: 52973 keys, 2129584 bytes
2017-09-18 00:19:08.434451 7fe07b990700 1 leveldb: Generated table
#14161: 54404 keys, 2129467 bytes
2017-09-18 00:19:08.488200 7fe07b990700 1 leveldb: Generated table
#14162: 54929 keys, 2129347 bytes
2017-09-18 00:19:08.553861 7fe07b990700 1 leveldb: Generated table
#14163: 53000 keys, 2129511 bytes
2017-09-18 00:19:08.570029 7fe07b990700 1 leveldb: Generated table
#14164: 14956 keys, 600195 bytes
2017-09-18 00:19:08.594003 7fe07b990700 1 leveldb: Generated table
#14165: 17061 keys, 710889 bytes
2017-09-18 00:19:08.594016 7fe07b990700 1 leveldb: Compacted 4@0 +
5@1 files => 11958679 bytes
2017-09-18 00:19:08.595153 7fe07b990700 1 leveldb: compacted to:
files[ 0 7 17 0 0 0 0 ]
2017-09-18 00:19:08.595317 7fe07b990700 1 leveldb: Delete type=2
#14154
 	   

Это обычные контрольно- диспетчерские функции. Наш OSD сопровождает некую внутреннюю базу данных с метаданными, которая периодически высвобождается.

2017-09-18 00:19:53.953129 7fe0b5c2f700 0 --
10.24.49.15:6816/123339 >> 10.24.49.147:6834/1012539
pipe(0x557b7551b400 sd=83 :6816 s=0 pgs=0 cs=0 l=0
c=0x557b76a0ea80).accept connect_seq 15 vs existing 15 state
standby
2017-09-18 00:19:53.953290 7fe0b5c2f700 0 --
10.24.49.15:6816/123339 >> 10.24.49.147:6834/1012539
pipe(0x557b7551b400 sd=83 :6816 s=0 pgs=0 cs=0 l=0
c=0x557b76a0ea80).accept connect_seq 16 vs existing 15 state
standby
2017-09-18 00:19:54.933317 7fe0b07db700 0 --
10.24.49.15:6816/123339 >> 10.24.50.15:6844/135559
pipe(0x557b7f57e000 sd=38 :6816 s=0 pgs=0 cs=0 l=0
c=0x557b7fb54700).accept connect_seq 57 vs existing 57 state
standby
2017-09-18 00:19:54.933774 7fe0b07db700 0 --
10.24.49.15:6816/123339 >> 10.24.50.15:6844/135559
pipe(0x557b7f57e000 sd=38 :6816 s=0 pgs=0 cs=0 l=0
c=0x557b7fb54700).accept connect_seq 58 vs existing 57 state
standby
 	   

OSD решила не скучать, приняв некоторые запросы на соединение.

2017-09-18 00:34:54.052375 7fe0b5c2f700 0 --
10.240.49.15:6816/123339 >> 10.240.49.147:6834/1012539
pipe(0x557b7551b400 sd=83 :6816 s=2 pgs=1045 cs=17 l=0
c=0x557b86d4e600).fault with nothing to send, going to standby
2017-09-18 00:34:55.031169 7fe0b07db700 0 --
10.240.49.15:6816/123339 >> 10.240.50.15:6844/135559
pipe(0x557b7f57e000 sd=38 :6816 s=2 pgs=3948 cs=59 l=0
c=0x557b76c85e00).fault with nothing to send, going to standby
 	   

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

2017-09-18 02:08:51.710567 7fe0e466f700 0 log_channel(cluster) log
[INF] : 1.35da deep-scrub starts
2017-09-18 02:08:52.040149 7fe0e466f700 0 log_channel(cluster) log
[INF] : 1.35da deep-scrub ok
 	   

Вот было запущено глубокое выскребание и оно завершилось успешно. нам нравится когда всё так происходит.

2017-09-18 02:27:44.036497 7fe0926fc700 0 --
10.240.49.15:6816/123339 >> 10.240.50.17:6834/1124935
pipe(0x557b95384800 sd=34 :6816 s=0 pgs=0 cs=0 l=0
c=0x557b80759200).accept connect_seq 4 vs existing 3 state standby
2017-09-18 02:39:53.195393 7fe118064700 -1 osd.8 33380
heartbeat_check: no reply from 0x557b91ccd390 osd.272 since back
2017-09-18 02:39:32.671169 front 2017-09-18 02:39:32.671169 (cutoff
2017-09-18 02:39:33.195374)
2017-09-18 02:39:54.195516 7fe118064700 -1 osd.8 33380
heartbeat_check: no reply from 0x557b91ccd390 osd.272 since back
2017-09-18 02:39:32.671169 front 2017-09-18 02:39:32.671169 (cutoff
2017-09-18 02:39:34.195502)
 	   

Уф! Наш OSD с идентификационным номером 272 получил одиночное заключение. В Главе 8, Архитектура Ceph: под капотом мы обсудим как OSD периодически проверяют друг друга. Эти записи могут отражать тот факт, что имеется некая проблема сетевой среды, переполнение имеющейся таблицы nf_conntrack, либо этот демон osd.272 процесса машины стал призраком. Забежим вперёд и устроим перерыв с чесночными чипсами. Вы не захотите заниматься следующим блоком натощак. Многоточия обозначают пропуски, сделанные для сокращения.

-4> 2017-09-15 21:58:20.149473 7f158d64f700 0
    filestore(/var/lib/ceph/osd/ceph-231) write couldn't open
    meta/#-1:97b6cd72:::osdmap.25489:0#: (117) Structure needs
    cleaning
    -3> 2017-09-15 21:58:20.149536 7f158d64f700 0
    filestore(/var/lib/ceph/osd/ceph-231) error (117) Structure
    needs cleaning not handled on operation 0x55a18d942b88
    (17413.0.1, or op 1, counting from 0)
    -2> 2017-09-15 21:58:20.149544 7f158d64f700 0
    filestore(/var/lib/ceph/osd/ceph-231) unexpected error code
    -1> 2017-09-15 21:58:20.149545 7f158d64f700 0
    filestore(/var/lib/ceph/osd/ceph-231) transaction dump:
    {
      "ops": [
          {
             "op_num": 0,
             "op_name": "write",
             "collection": "meta",
             "oid": "#-1:725cc562:::inc_osdmap.25489:0#",
             "length": 203,
             "offset": 0,
             "bufferlist length": 203
         },
         {
             "op_num": 1,
             "op_name": "write",
             "collection": "meta",
             "oid": "#-1:97b6cd72:::osdmap.25489:0#",
             "length": 404169,
             "offset": 0,
             "bufferlist length": 404169
         },
         {
             "op_num": 2,
             "op_name": "write",
             "collection": "meta",
             "oid": "#-1:7b3f43c4:::osd_superblock:0#",
             "length": 417,
             "offset": 0,
             "bufferlist length": 417
         }
      ]
}
    0> 2017-09-15 21:58:20.152050 7f158d64f700 -1
    os/filestore/FileStore.cc: In function 'void
    FileStore::_do_transaction(ObjectStore::Transaction&,
    uint64_t, int, ThreadPool::TPHandle*)' thread 7f158d64f700
    time 2017-09-15 21:58:20.149608
	
    os/filestore/FileStore.cc: 2920: FAILED assert(0 == "unexpected error")

    ceph version 10.2.6
    (656b5b63ed7c43bd014bcafd81b001959d5f089f)
1: (ceph::__ceph_assert_fail(char const*, char const*, int,
   char const*)+0x8b) [0x55a1826b007b]
2: (FileStore::_do_transaction(ObjectStore::Transaction&,
   unsigned long, int, ThreadPool::TPHandle*)+0xefd)
   [0x55a1823a26ed]
3: (FileStore::_do_transactions
   (std::vector<ObjectStore::Transaction,
   std::allocator<ObjectStore::Transaction> >&, unsigned long,
   ThreadPool::TPHandle*)+0x3b) [0x55a1823a842b]
4: (FileStore::_do_op(FileStore::OpSequencer*,
   ThreadPool::TPHandle&)+0x2b5) [0x55a1823a8715]
5: (ThreadPool::worker(ThreadPool::WorkThread*)+0xa6e)
   [0x55a1826a145e]
6: (ThreadPool::WorkThread::entry()+0x10) [0x55a1826a2340]
7: (()+0x8184) [0x7f159bbff184]
8: (clone()+0x6d) [0x7f1599d28ffd] NOTE: a copy of the
   executable, or `objdump -rdS <executable>` is needed to
   interpret this. --- logging levels --- 0/ 5 none 0/ 0
   lockdep 0/ 0 context 0/ 0 crush 0/ 0 mds 0/ 1 optracker
...
log_file /var/log/ceph/ceph-osd.231.log
--- end dump of recent events --- 2017-09-15 21:58:20.155893 7f158d64f700 -1 *** Caught signal (Aborted) ** in thread 7f158d64f700 thread_name:tp_fstore_op ceph version 10.2.6 (656b5b63ed7c43bd014bcafd81b001959d5f089f)
    1: (()+0x8f3942) [0x55a1825bb942]
    2: (()+0x10330) [0x7f159bc07330]
    3: (gsignal()+0x37) [0x7f1599c61c37]
    4: (abort()+0x148) [0x7f1599c65028]
    5: (ceph::__ceph_assert_fail(char const*, char const*, int,
        char const*)+0x265) [0x55a1826b0255]
    6: (FileStore::_do_transaction(ObjectStore::Transaction&,
        unsigned long, int, ThreadPool::TPHandle*)+0xefd)
        [0x55a1823a26ed]
...
 	   

Вашу Машу! Это явно не обслуживает Ваал! Тут код OSD Ceph обнаружил ошибку, с которой он не может справиться. Обратная трассировка и информация о выполненных операция предоставляются для проведения экспертизы. Мы выделили две строки из приведённых выше десятков чтобы обсудить детали.

Наша первая выделенная строка отображает формулировку кода отказа. Это часто пронзает основную причину, вызывающую данную проблему. В данном случае OSD, до этого именовавшийся как 231, столкнулся с проблемой в коде FileStore. Это почти всегда отражает проблемы с основным оборудованием или, в крайнем случае, что некая файловая система XFS сбилась со своего пути по иной причине.

os/filestore/FileStore.cc: 2920: FAILED assert(0 == "unexpected error")
 	   

В данном конкретном случае журнал самого ядра указывает ошибки ввода/ вывода лежащего в основе устройства SSD.

Переходя далее ко второй выделенной строке мы видим

2017-09-15 21:58:20.155893 7f158d64f700 -1 *** Caught signal (Aborted) ** in thread 7f158d64f700 thread_name:tp_fstore_op
 	   

При выполнении grep (или groping - нащупывания) в объёмных журналах OSD в поисках отказа, может оказаться полезным поиск слова signal чтобы быстро установить начальную отметку в области нашего интереса. Обратите внимание, что демоны Ceph также регистрируют сообщения сигналов когда они нормально закрываются, скажем, для перезагузки сервера.

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

--- logging levels ---
0/ 5 none
0/ 0 lockdep
0/ 0 context
 	   

Ceph позволяет нам, в конце концов, управлять детализацией (verbosity) с которой выдаются в протокол события, состояния и ошибки. Уровни могут независимо устанавливаться для каждой из подсистем чтобы управлять многословностью. Более того, каждая подсистема имеет отдельные уровни детализации для сохранения информации в памяти и для отправки сообщений в файлы журнала или в имеющуюся службу syslog. Более высокие значения поднимают уровень подробностей. Значения уровней вывода и памяти могут устанавливаться независимо, либо раздельно. Например, если наши Мониторы выйдут из под контроля, мы можем добавить следующие строки, как приводимые ниже, в ceph.conf.

[global]
debug ms = 1

[mon]
debug mon = 15/20
debug paxos = 20
debug auth = 20
 	   

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

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

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

Допустим, вчера osd.666 и osd.1701 чокнулись, поэтому мы повышаем уровни своих модулей filestore и osd. Сегодня мы обнаруживаем, что увеличившийся поток регистраций наполовину заполнил файловую систему /var/log узлов этих OSD и необходимо вернуться назад с подробностями. После регистрации в узле osd.666 мы проверяем все настройки, которые активны в настоящий момент в имеющейся конфигурации этого работающего демона.

# ceph daemon osd.666 config show | grep debug
    "debug_none": "0\/5",
    "debug_lockdep": "0\/0",
    "debug_context": "0\/0",
    "debug_crush": "0\/0",
    "debug_mds": "1\/5",
...
    "debug_osd": "10\/10",
    "debug_optracker": "0\/0",
    "debug_objclass": "0\/0",
    "debug_filestore": "10\/10",
...
		

В выпуске Jewel 10.2.6 Ceph это соответствует не менее чем 98 индивидуальным установкам, следовательно многоточие для краткости. Теперь зарегистрируемся в узле администратора или Монитора чтобы выполнить инъекцию этих щенят в подчинение.

# ceph tell osd.666 injectargs '--debug-filestore 0/0 --debug-osd 0/0'debug_filestore=0/0 debug_osd=0/0
		

Бум. Моментальное удовлетворение. Так как мы можем вводить эти значения на лету, мы можем устанавливать их и в ceph.conf впоследствии, а также выполнять инъекции временно увеличивая в полёте, а затем уменьшая по завершению. На самом деле, если наш файл журнала вырос настолько, что у нас даже нет места для его сжатия, мы можем усечь его и открыть вновь, не перезагружая при этом данный демон OSD.

# rm /var/log/ceph/ceph-osd.666.log
# ceph daemon osd.666 log reopen
		

Процитирую своего учителя химии в университете, Разве это не ПРЕКРАСНО!? ТЕПЕРЬ мы готовим на газу!

Ой, подождите, мы забыли про osd.1701. А ещё мы возможно также повышали osd.1864 и ..., мы не помним. Было уже поздно и мы были измучены отсутствием чесночных чипсов. Сегодня утром, после пробуждения соевым чаем мы вспоминаем, что мы можем выполнять инъекцию значений в текущее состояние всех OSD с помощью всего одной команды.

# ceph tell osd.* injectargs '--debug-filestore 0/0 --debug-osd 0/0'
osd.0: debug_filestore=0/0 debug_osd=0/0
osd.1: debug_filestore=0/0 debug_osd=0/0
osd.2: debug_filestore=0/0 debug_osd=0/0
...
		

Бережёного Бог бережёт, сказала монашка одевая презерватив на свечку, лучше иметь уверенность. Инъектированные значения, которые могут оказаться идентичные тем которые уже установлены, являются безопасными и идемпотентными и несомненно не станут ядерной бомбой, уводящей нашу площадку с орбиты.

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

В своей предыдущей главе мы построили полноценный, рабочий кластер Ceph с применением виртуализации и ceph-ansible. Здесь мы суммируем раскрутку Ceph на голом железе с применением того же самого инструментария ceph-ansible, однако без оркестрации Vagrant. Если вы применяете циклы for, как Джек Батлер, вы это делаете зря.

Во- первых, клонируйте имеющийся репозиторий GitHub ceph-ansible в некую систему или в ВМ, которая будет работать в качестве вашего узла администратора.

$ git clone https://github.com/ceph/ceph-ansible/
		

Затем установите Ansible с применением диспетчера управления пакетами своего дистрибутива Linux, pip, или выгрузите с http://docs.ansible.com/ansible/latest/intro_installation.html. Рекомендуется к установке самый последний стабильный выпуск.

После этого заполните файл учёта ресурсов (inventory) Ansible хостами и группами хостов, применив /etc/ansible/hosts в качестве своей стартовой точки. В конечном итоге вы получите некий файл похожий на такой пример:

[mons]
ceph-mon01
ceph-mon02
ceph-mon03

[osds]
ceph-osd001
ceph-osd002
ceph-osd003
ceph-osd004
ceph-osd005
ceph-osd006

[rgws]
ceph-rgw01
[clients]
ceph-client-01
 	   

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

$ ansible all -m ping
10.10.17.01 | success >> {
"changed": false,
"ping": "pong"
}
10.10.11.38 | success >> {
"changed": false,
"ping": "pong"
}
...
		

Если вы испытаете трудности с приведённым выше тестом, проверьте полномочия на свой каталог .ssh и испытайте /etc/ansible/ansible.cfg.

Далее персонализируйте имеющиеся файлы group_vars и site.yml, в точности как мы это делали в своей предыдущей главе.

$ cp group_vars/all.yml.sample group_vars/all.yml
$ cp group_vars/mons.yml.sample group_vars/mons.yml
$ cp group_vars/osds.yml.sample group_vars/osds.yml
$ cp site.yml.sample site.yml
		

Как вы могли догадаться, далее мы редактируем свой файл group_vars/all.yml чтобы он отображал наши локальные условия.

Вначале мы изменяем необходимые записи для public_nework и monitor_interface, чтобы они соответствовали вашим системам. Далее рассмотрите куда вы желаете свалить пакеты установки Ceph и настройте знакомую строку ceph_origin на distro, upstream или local. Когда вы выбираете восходящий поток (upstream) пакетов исходного кода, вы должны обозначить насколько далеко в этот восходящий поток вы желаете заплывать. Безопасным выбором является ceph_stable, а ceph_rhcs разрешён для оснасток RHEL, в то время как бравые сердца могут прокатиться с ceph_dev.

Наша оснастка песочницы не затрагивала подробностей создания OSD, однако для развёртывания на голом железе вы должны отредактировать group_vars/osds.yml и изменить, по крайней мере, самую последнюю строку osd_scenario чтобы выбрать свою стратегию из представленных journal_collocation, bluestore, osd_directory, raw_multi_journal, dmcrypt_journal_collocation, dmcrypt_dedicated_journal. Обратите внимание на синтаксический разбор, с выровненным размещением (collocation) или без него. Прежде чем продолжить, лучше прочесть весь этот файл. Глава 3, Выбор оборудования и сетевой среды и Глава 4, Планирование вашего развёртывания помогут вам с этими решениями. Обратите внимание, что osd_directory в некоторой степени проблематичен и может быть удалён в будущем.

Также отредактируйте те записи devices и raw_journal_devices, которые соответствуют вашему оснащению.

Вы готовы! Снимите с предохранителя, исполнив

$ ansible-playbook site.yml
		

и наслаждайтесь тем, как ceph-ansible делает то, для чего в худшие старые времена нам требовалось исполнять десятки циклов for и индивидуальные команды. Помните, в самом начале этой главы мы предлагали вам не ограничивать историю прокрутки для вашего терминального приложения? А ещё чесночные чипсы? Это время и для первого, и для второго. {Прим. пер.: желающим ознакомиться с деталями того, что делает Ansible ещё раз напоминаем о нашем переводе вышедшего в мае 2017 в издательстве Packt Publishing второго издания Полного руководства Ansible Джесс Китинг.}

В качестве альтернативы вы можете воспользоваться инструментарием ceph-deploy для выполнения задач управления Ceph с меньшей гранулярностью. Если ваша инфраструктура Ceph пока не имеет включённого ceph-deploy, ниже мы кратко инструктируем установку и настройку. Мы обсудим те действия, которые должны быть выполнены; вы должны осуществить их по всем вашим узлам Ceph с применением вашей обычной практики управления серверами.

Во- первых создайте выделенного пользователя для ceph-deploy на всех подлежащих управлению системах. Распространённая документация создаёт для целей этих задач пользователя ceph-server, хотя вы можете остановиться и на другом имени.

$ sudo useradd -d /home/ceph-server -m ceph
$ sudo passwd ceph-server
		

Установка пакетов программного обеспечения, доступ к устройствам и управление службами системы требуют полномочий root. ceph-deploy работает и соединяется с удалёнными системами как наш новый выделенный пользователь и повышает полномочия sudo, когда это требуется, подход, который избегает необходимости включения прав SSH без паролей в ваших узлах кластера. Далее мы разрешим sudo без пароля для пользователя ceph-server без соответствующих привилегий на всех подлежащих управлению узлах.

$ echo "ceph-server ALL = (ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/ceph-server
$ sudo chmod 0440 /etc/sudoers.d/ceph-server
		

После этого настройте доверия SSH без паролей со своего хоста администратора к каждой своей промышленной системе Ceph для своего пользователя ceph-server.

$ sudo -i -u ceph-server
ceph-server$ ssh-keygen
Generating public/private key pair.
Enter file in which to save the key (/home/ceph-server/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ceph-server/.ssh/id_rsa.
Your public key has been saved in /home/ceph-server/.ssh/id_rsa.pub.
		

Распространите эти новые ключи во все промышленные узлы (или воспользуйтесь обычным методом).

$ ssh-copy-id ceph-server@some.node
# apt-get install -y ceph-deploy
		

Теперь установите сам ceph-deploy на вашем узле администратора. Ваш дистрибутив Linux может уже предоставлять этот пакет, либо вы можете выгрузить предварительно построенные пакеты с https://download.ceph.com/. Те, кто склонен к этому, может воспользоваться исходными кодами в https://github.com/ceph/ceph-deploy.

# yum install -y ceph-deploy
		

Это всё что требовалось! Вспомните, что вы настроили для sudo персонального пользователя ceph-server, прежде чем запускать ceph-deploy, вместо того чтобы исполнять его под root.

Ceph имеет ряд флагов, которые обычно применяются для всего кластера в целом. Эти флаги руководят различным поведением Ceph, а будучи заданными выдаются в ceph status.

Наиболее часто применяемым флагом является noout, который указывает Ceph на необходимость не переводить автоматически в состояние out никакие OSD, которые вошли в состояние down. Благодаря тому, что OSD не будут помечаться как out (выведенные) в случае установки данного флага, данный кластер не будет начинать процесс заполнения/ перестроения чтобы обеспечивать оптимальные репликации. Это в особенности полезно для поддержания производительности, в том числе при обычной перезагрузке. Сообщив Ceph Постой, мы скоро вернёмся, мы предотвращаем накладные расходы и крутёж- вертёж автоматического переключения на перемещение данных.

Вот некий пример перезагрузки какого- то узла OSD в рамках кластера Jewel. Вначале мы исполняем ceph -s чтобы проверить общее состояние своего кластера. Это является очень хорошей привычкой заглянуть вовнутрь до, во время и после даже самых простейших работ по сопровождению; если что-то не так, почти всегда лучше сначала восстановить жизнеспособное состояние, прежде чем включать бетономешалку.

# ceph -s
   cluster 3369c9c6-bfaf-4114-9c31-576afa64d0fe
     health HEALTH_OK
     monmap e2: 5 mons at {mon001=10.8.45.10:6789/0,mon002=10.8.45.11:6789/0,mon003=10.8.45.143:6789/0,mon004=10.80.46.10:6789/0,mon005=10.80.46.11:6789/0}
            election epoch 24, quorum 0,1,2,3,4 mon001,mon002,mon003,mon004,mon005
     osdmap e33039: 280 osds: 280 up, 280 in
            flags sortbitwise,require_jewel_osds
      pgmap v725092: 16384 pgs, 1 pools, 0 bytes data, 1 objects
            58364 MB used, 974 TB / 974 TB avail
               16384 active+clean
		

Здесь мы видим, что жизнеспособность нашего кластера HEALTH_OK, а также что все 280 OSD являются и up (поднятыми), и in (в системе). Скрипит чистый, жизнеспособный кластер. Отметим, что уже установлены два флага:sortbitwise и require_jewel_osds. Флаг sortbitwise обозначает, что для определённых новых свойств требуются некие новые свойства сортировки. Флаг require_jewel_osds обходит проблемы совместимости с подключением к кластеру OSD с предшествующими Jewel версиями. Оба флага должны быть всегда установлены в кластере исполняющем Jewel и последующие версии и вам не придётся путаться в случае, если вы не выполнили обновление с более ранних версий.

# ceph osd set noout
set noout
		

Теперь, когда мы убедились в жизнеспособности своего кластера, прежде чем перейти к работе по его сопровождению, мы устанавливаем флаг noout чтобы предвосхитить нежелательные перестроения. Отметим, что жизнеспособность данного кластера принимает состояние HEALTH_WARN и что некая строка добавляется в ceph status, чтобы отразить тот факт, что состояние предупреждает. Как мы изучим в Главе 7, Мониторинг Ceph, HEALTH_WARN обычно означает некое состояние кластера, которое заслуживает внимания, однако скорее всего не критично.

# ceph status
  cluster 3369c9c6-bfaf-4114-9c31-576afa64d0fe
    health HEALTH_WARN
           noout flag(s) set
    monmap e2: 5 mons at {mon001=10.8.45.10:6789/0,mon002=10.8.45.11:6789/0,mon003=10.8.45.143:6789/0,mon004=10.80.46.10:6789/0,mon005=10.80.46.11:6789/0}
           election epoch 24, quorum 0,1,2,3,4 mon001,mon002,mon003,mon004,mon005
    osdmap e33050: 280 osds: 280 up, 280 in
           flags noout,sortbitwise,require_jewel_osds
     pgmap v725101: 16384 pgs, 1 pools, 0 bytes data, 1 objects
           58364 MB used, 974 TB / 974 TB avail
              16384 active+clean
		

На данный момент мы всё ещё имеем все OSD up и in; и мы готовы продолжить.

# ssh osd013 shutdown -r now
		

Мы перезагрузили определённый узел OSD, допустим, чтобы вступило в действие новое ядро или распутать запутавшийся HBA. Ceph быстро помечает все OSD в данной системе как отключённые (down); в настоящий момент на данном узле их присутствует 20. Отметим некую новую строку в выводе состояния, приводимом ниже, которая сообщает об этих отключённых OSD соответствующим выравниванием общего числа поднятых (up) OSD в имеющейся строке osdmap. Легко пропустить разницу в самой записи osdmap, в особенности при использовании шрифтов, в которых имеется схожесть начертания 260 и 280, поэтому мы рады тому, что Ceph напрямую предупреждает нас об имеющей место ситуации.

Данный кластер имеет правила CRUSH, которые требуют копирования данных в случае отсоединения стоек. При установленном по умолчанию значению size репликаций пула и настройке min_size на значение трёх и двух соответственно, все Группы размещения (PG), чьи Множества активных содержат данные OSD помечаются как undersized и degraded. При наличии только выведенной из обслуживания одной реплики Ceph продолжит обслуживание данных без остановки. Данный кластер при мера простаивает, однако для промышленного варианта, когда мы это выполняем, будут присутствовать операции, поступающие в момент останова данного хоста. Эти операции будут отображаться в выводе ceph status как некие дополнительные строки, перечисляющие PG, находящиеся в состоянии backfill_wait. Это указывает что Ceph имеет данные, которые жаждут своей записи в определённые OSD, которые (временно) отключены - down.

Если бы мы не установили свой флаг noout, по истечению краткого периода благоволения Ceph приступил бы к обработке карт с тем, чтобы новые данные (а также все имеющиеся данные, расположенные на тех OSD, которые остановлены - down) потекли на другие OSD в той же самой области отказа. Поскольку некий пул с репликациями в нескольких стойках обычно определяет в качестве области отказа стойку, это бы означало, что все выжившие три хоста в той же самой стойке, что и osd013, должны бы начать приём совместных ресурсов. Затем, когда данный хост (и его OSD) возвращаются обратно, Ceph пометил бы что данные вернулись в своё и большую часть перестроений необходимо было бы отыграть назад. Такое удвоение перемещений данных является излишним, поскольку мы получили данные OSD назад в рамках разумного периода времени.

# ceph status
  cluster 3369c9c6-bfaf-4114-9c31-576afa64d0fe
   health HEALTH_WARN
          3563 pgs degraded
          3261 pgs stuck unclean
          3563 pgs undersized
          20/280 in osds are down
          noout flag(s) set
   monmap e2: 5 mons at {mon001=10.8.45.10:6789/0,mon002=10.8.45.11:6789/0,mon003=10.8.45.143:6789/0,mon004=10.80.46.10:6789/0,mon005=10.80.46.11:6789/0}
          election epoch 24, quorum 0,1,2,3,4 mon001,mon002,mon003,mon004,mon005
   osdmap e33187: 280 osds: 260 up, 280 in; 3563 remapped pgs
          flags noout,sortbitwise,require_jewel_osds
    pgmap v725174: 16384 pgs, 1 pools, 0 bytes data, 1 objects
          70498 MB used, 974 TB / 974 TB avail
             12821 active+clean
              3563 active+undersized+degraded
		

Отметим также, что самое окончание данного вывода подводит итог PG, которые пребывают в некоторых определённых состояниях. Здесь опять 3563 PG вновь помечены как имеющие не надлежащий size, но в то же время активные, поскольку они всё ещё доступны операциям клиента. Общий баланс PG кластера представляется как active+clean. Суммируя эти два числа мы получаем 16384, как об этом и сообщается в строке pgmap.

Мы можем эксплуатировать данные суммы состояний PG как удобную программируемую проверку жизнеспособности кластера. Во время таких действий, как накат перезагрузок, разумно обеспечивать жизнеспособность кластера между последовательными итерациями. Один из способов выполнения этого состоит в сравнении общего числа PG со значением активных. Так как PG могут иметь прочие состояния в одно и то же время, когда они активны, например, active+scrubbing, а также active+scrubbing+deep, нам необходимо суммировать все подобные комбинации. Вот некий пример воспроизведения Ansible, который реализует данную проверку.

- name: wait until clean PG == total PG
 shell: "ceph -s | awk '/active\+clean/ { total += $1 }; END { print total }'"
 register: clean_PG
 until: total_PG.stdout|int == clean_PG.stdout|int
 retries: 20
 delay: 20
 delegate_to: "{{ ceph_primary_mon }}"
 run_once: true
 	   

имеется пространство для улучшений: нам следует применять в качестве ввода хирургически более точное ceph pg stat, а также применять более безопасный формат вывода -f json или -f json-pretty совместно с утилитой jq чтобы оградить себя от изменений между различными версиями. Это, как говорится, мы оставляем в качестве упражнения для читателя.

Хотя мы и отклонили приведённый выше совет, тот узел, который мы перезагрузили, вернулся обратно и наш кластер вновь принял жизнеспособное состояние. Отметим, что предупреждение о 20 выведенных из 280 OSD в отключённое (down) состояние осталось, отражаемое также и в строке osdmap. Текущее состояние жизнеспособности тем не менее продолжает оставаться HEALTH_WARN пока мы имеем некую установку флага, которая ограничивает поведение кластера. Это помогает нам помнить о необходимости удаления временных флагов, когда нам больше не требуется их определённое изменение поведения.

# ceph status
  cluster 3369c9c6-bfaf-4114-9c31-576afa64d0fe
  health HEALTH_WARN
  noout flag(s) set
  monmap e2: 5 mons at {mon001=10.8.45.10:6789/0,mon002=10.8.45.11:6789/0,mon003=10.8.45.143:6789/0,mon004=10.80.46.10:6789/0,mon005=10.80.46.11:6789/0}
         election epoch 24, quorum 0,1,2,3,4 mon001,mon002,mon003,mon004,mon005
  osdmap e33239: 280 osds: 280 up, 280 in
         flags noout,sortbitwise,require_jewel_osds
   pgmap v725292: 16384 pgs, 1 pools, 0 bytes data, 1 objects
         58364 MB used, 974 TB / 974 TB avail
            16384 active+clean
		

Мы продолжим удалением данного флага. Такая команда с двойным отрицанием заставит икнуть вашего учителя грамматики в школе, однако здесь это имеет существенное значение в контексте установки некоторого флага {Прим. пер.: английской грамматики, в русском языке мы вольны выполнять рекурсию отрицаний}.

# ceph osd unset noout
unset noout
		

Теперь, когда мы не должны больше связывать руки Ceph, состояние жизнеспособности нашего кластера возвращается как HEALTH_OK и наше упражнение завершено.

# ceph status
  cluster 3369c9c6-bfaf-4114-9c31-576afa64d0fe
  health HEALTH_OK
  monmap e2: 5 mons at {mon001=10.8.45.10:6789/0,mon002=10.8.45.11:6789/0,mon003=10.8.45.143:6789/0,mon004=10.80.46.10:6789/0,mon005=10.80.46.11:6789/0}
         election epoch 24, quorum 0,1,2,3,4 mon001,mon002,mon003,mon004,mon005
  osdmap e33259: 280 osds: 280 up, 280 in
         flags noout,sortbitwise,require_jewel_osds
   pgmap v725392: 16384 pgs, 1 pools, 0 bytes data, 1 objects
         58364 MB used, 974 TB / 974 TB avail
            16384 active+clean
		

В выпуске Luminous имеющийся формат вывода plain для ceph status был слегка изменён, отображая значение применения формата вывода -f json для задач сценариев.

# ceph -s
  cluster:
  id: 2afa26cb-95e0-4830-94q4-5195beakba930c
  health: HEALTH_OK

  services:
    mon: 5 daemons, quorum mon01,mon02,mon03,mon04,mon05
    mgr: mon04(active), standbys: mon05
    osd: 282 osds: 282 up, 282 in

  data:
    pools: 1 pools, 16384 pgs
    objects: 6125k objects, 24502 GB
    usage: 73955 GB used, 912 TB / 985 TB avail
    pgs: 16384 active+clean
		

# ceph -s
  cluster:
    id: 2af1107b-9950-4800-94a4-51951701a02a930c
    health: HEALTH_WARN
            noout flag(s) set
            48 osds down
            2 hosts (48 osds) down
            Degraded data redundancy: 3130612/18817908 objects degraded (16.636%), 8171 pgs unclean, 8172 pgs degraded, 4071 pgs undersized

  services:
    mon: 5 daemons, quorum mon01,mon02,mon03,mon04,mon05
    mgr: mon04(active), standbys: mon05
    osd: 282 osds: 234 up, 282 in
         flags noout

  data:
    pools: 1 pools, 16384 pgs
    objects: 6125k objects, 24502 GB
    usage: 73941 GB used, 912 TB / 985 TB avail
    pgs: 3130612/18817908 objects degraded (16.636%)
             8212 active+clean
             8172 active+undersized+degraded

  io:
    client: 8010 MB/s wr, 0 op/s rd, 4007 op/s wr
		

# ceph status
  cluster:
    id: 2afa26cb-95e0-4830-94q4-5195beakba930c
    health: HEALTH_WARN
            Degraded data redundancy: 289727/18817908 objects degraded (1.540%), 414 pgs unclean, 414 pgs degraded

  services:
    mon: 5 daemons, quorum mon01,mon02,mon03,mon04,mon05
    mgr: mon04(active), standbys: mon05
    osd: 283 osds: 283 up, 283 in

  data:
    pools: 1 pools, 16384 pgs
    objects: 6125k objects, 24502 GB
    usage: 73996 GB used, 916 TB / 988 TB avail
    pgs: 289727/18817908 objects degraded (1.540%)
             15970 active+clean
             363 active+recovery_wait+degraded
             51 active+recovering+degraded

  io:
    recovery: 1031 MB/s, 258 objects/s
		

Прочими флагами являются noin, norecover, nobackfill и norebalance. Их действие состоит в нюансах, а применяются они редко. Есть возможность выстрелить себе в ногу, поэтому предлагается исследовать их и поэкспериментировать в нагруженном, но не находящемся в промышленной эксплуатации кластере с тем, чтобы получить полное представление об их динамике, прежде чем связываться с ними.

Позже в данной главе мы коснёмся флагов noscrub и nodeepscrub.

Все MON, OSD, RGW, MDS Ceph, а также Диспетчер (ceph-mgr) последнего выпуска являются структурами Linux, выступающими в роли служб. Порой требуется их запуск и останов. Их механика отличается в различных дистрибутивах и даже внутри различных выпусков одного дистрибутива.

Systemd: волна (цунами?) будущего

Давайте вначале изучим управление службами Ceph с помощью основанных на systemd выпусках Linux. Любимый, ненавистный, но никогда не игнорируемый, systemd становится всё более распространённым в основных дистрибутивах Linux. Они влючают в совй состав семейство Red Hat: RHEL 7 и далее, CentOS 7 и последующие, а также Fedora 15 и все выше. Debian приспособил systemd в версии 8 (Jessie), Ubuntu начиная с 16.04 (Xenial), а SUSE в SLES 12.

Установка пакетов Ceph применяет возможности правил udev и собственную систему управления службами для запуска настроенных служб во время загрузки. Мы также можем перечислять их индивидуально или на основе всех хостов.

systemd организует службы в виде единиц (units), которыми мы управляем от имени своего пользователя root с помощью команды systemctl. Для отображения всех настроенных единиц Ceph в некотором хосте мы исполняем:

# systemctl status ceph.target
		

Для осанова всех исполняемых демонов Ceph любого типа в некотором узле, а затем для их запуска назад:

# systemctl stop ceph.target
# systemctl start ceph.target
		

Порой нам требуется управлять службами более тонко, в особенности в конвергентных (AIO) оснащениях. Мы можем управлять классами индивидуальных компонентов демонов Ceph определяя их названия:

# systemctl stop ceph-osd.target
# systemctl start ceph-osd.target

# systemctl stop ceph-mon.target
# systemctl start ceph-mon.target

# systemctl stop ceph-mds.target
# systemctl start ceph-mds.target

# systemctl stop ceph-radosgw.target
# systemctl start ceph-radsogw.target
		

OSD Ceph одновременно являются и наиболее многочисленными, и наиболее изменчивыми компонентами любого кластера, мы часто обнаруживаем потребность хирургического вмешательства в персональные OSD без необходимости беспокойства прочих в том же самом сервере. Это применимо также и к прочим демонам, поэтому мы можем исполнить приведённые выше команды с более точной фокусировкой на индивидуальном экземпляре (instance).

# systemctl stop ceph-osd@instance
# systemctl start ceph-osd@instance

# systemctl stop ceph-mds@instance
# systemctl start ceph-mds@instance
# systemctl stop ceph-mon@instance
# systemctl start ceph-mon@instance
# systemctl stop ceph-radosgw@instance
# systemctl start ceph-radosgw@instance
		

Для OSD экземпляром является просто номер такого OSD;для других служб мы применяем его имя хоста:

# systemctl stop ceph-osd@11
# systemctl start ceph-osd@11

# systemctl stop ceph-mds@monhost-003
# systemctl start ceph-mds@monhost-003

# systemctl stop ceph-mon@monhost-002
# systemctl start ceph-mon@monhost-002

# systemctl stop ceph-radosgw@rgwhost-001
# systemctl start ceph-radosgw@rgwhost-001
		

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

Upstart

Более ранние нежели Xenial выпуски Ubuntu (например, Trusty) применяли систему управления службами Upstart, которая во многом, но не во всём, аналогична systemd. Вот некий список аналогов команд Upstart для всех описанных в предыдущем разделе задач.

Показать все задания и экземпляры Upstart для данной системы:

# initctl list | grep ceph
		

Остановить и запустить все демоны в некотором хосте:

# stop ceph-all
# start ceph-all
		

Остановить и запустить все экземпляры определённого компонента Ceph в некотором заданном хосте:

# stop ceph-osd-all
# start ceph-osd-all

# stop ceph-mon-all
# start ceph-mon-all

# stop ceph-mds-all
# start ceph-mds-all
		

Остановить и запустить индивидуальные экземпляры:

# stop ceph-osd id=11
# start ceph-osd id=11

# stop ceph-mon id=monhost-005
# start ceph-mon id=monhost-005

# stop ceph-mds id=mdshost-001
# stop ceph-mds id=mdshost-001

# stop ceph-radosgw id=rgwhost-003
# start ceph-radosgw id=rgwhost-003
		

sysvinit

Более ранние версии Ceph или более старшие редакции Linux, например, Firefly в CentOS 6 применяют традиционное управление службами sysvinit со сценариями, располагающимися в /etc/init.d. Ниже приводятся все аналоги команд управления службами.

# /etc/init.d/ceph stop
# /etc/init.d/ceph start
# /etc/init.d/ceph stop mon
# /etc/init.d/ceph start mon
# /etc/init.d/ceph stop osd.69
# /etc/init.d/ceph start osd.69
		

В некоторых системах также можно применять команду service.

# service ceph start
# service ceph stop mon
# service ceph start osd.69
		

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

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

На сегодняшний день аппаратные сбои являются наиболее распространёнными причинами данных проблем. Принимая во внимание мириады вариантов систем и компонентов, с которыми можно столкнуться, а также ограниченность объёма для изложения, было бы не практично охватывать все подробности диагностики оборудования. Скорее всего, в вашей организации уже имеются механизмы проверки жизнеспособности диска, состояния устройств питания, отказов HBA, ошибок оперативной памяти и предостережений об отклонениях в параметрах окружающей среды. Если ваши NIC являются связанными, вам также следует убедиться что оба порта вставлены в каждом связывании. Ваши серверы Ceph не менее восприимчивы ко всему такому, чем все прочие системы и всесторонний мониторинг часто может предупреждать вас о проблемах до того как они превратятся в катастрофу.

Возможно, наиболее распространёнными ошибками являются отказы устройств OSD; они являются самыми насыщенными устройствами в вашем оснащении. Контроллеры управления вашими серверами могут предлагать регистрацию ошибок устройств, однако отслеживание сообщений syslog Linux может быть более целесообразным и менее привязанным к оборудованию. Например, в Ubuntu 14.04 с ядром 3.19 ошибки устройств могут выглядеть следующим образом:

2017-09-11T20:21:30 jank11 kernel: [965236] sd 0:0:9:0: [sdk]
FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
2017-09-11T20:21:30 jank11 kernel: [965236] sd 0:0:9:0: [sdk] Sense
Key : Medium Error [current] [descriptor]
2017-09-11T20:21:30 jank11 kernel: [965236] sd 0:0:9:0: [sdk] Add.
Sense: Unrecovered read error
2017-09-11T20:21:30 jank11 kernel: [965236] sd 0:0:9:0: [sdk] CDB:
2017-09-11T20:21:30 jank11 kernel: [965236] Read(16): 88 00 00 00
00 01 33 c9 bf 93 00 00 00 01 00 00
2017-09-11T20:21:30 jank11 kernel: [965236] blk_update_request:
critical medium error, dev sdk, sector 5163827091
2017-09-11T20:21:30 jank11 kernel: [965236] XFS (dm-18): metadata
I/O error: block 0x132895793 ("xfs_trans_read_buf_map") error 61
numblks 1
2017-09-11T20:21:30 jank11 kernel: [965236] XFS (dm-18): page
discard on page ffffea002c9b8340, inode 0x580008bc, offset 0.
 	   

В данном случае номер самого разъёма устройства находится непосредственно в самом сообщении -- slot #9. Для ошибок устройств является обычной практикой предоставлять далее ошибки XFS при применении FileStore. В большинстве случаев этот тип ошибки не будет вызывать сбоя связанного с ним OSD, но он может продолжать находиться в некотором состоянии деградации. Когда некая аппаратная ошибка ясно идентифицирована, обычно лучше будет удалить подвергшийся её воздействию OSD из данного кластера, заменить данное устройство, а затем выполнить переоснащение. Для удаления некоторого OSD из обслуживания следуйте таким этапам:

Обоснование данной команды является преднамеренным. Ошибки устройства или файловой системы могут в результате приводить в подобному зависанию.

В данном разделе мы обсудим стратегии для роста ёмкости с целью соответствия никогда не имеющей конца жажды ваших пользователей в ёмкости для хранения. В Главе 5, Развёртывание виртуального кластера песочницы мы применяли ceph-ansible с помощью Vagrant для добавления дополнительных компонентов в свой кластер; в случае промышленного применения с голым железом следует применять ceph-ansible напрямую для управления многими сторонами расширения кластера. Добавление хостов OSD целиком, а также логических стоек в некий работающий кластер достаточно прямолинейно, однако должно быть тщательно спланировано. Глава 8, Архитектура Ceph: под капотом прошлась по изменению карты CRUSH для добавления логических стоек и узлов OSD.

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

Посетите https://github.com/cernceph/ceph-scripts. Здесь можно найти изобилие полезных инструментов Ceph от прекрасных парней из CERN. Тут нам понадобится выгрузить tools/ceph-gentle-reweight в свой узел администрирования. Примерно в районе 63 строки имеется строка, которая выглядит так, как показано ниже; установите её в комментарий, снабдив символом # в самом начале.

# latency = measure_latency(test_pool)
 	   

В выделенном окне исполните watch ceph -s чтобы следить одним глазом за состоянием кластера.

Теперь установите пакеты Сeph в своих новых системах. Это можно осуществить с помощью ceph-ansible применив соответствующие локальные вызовы yum, apt-get или прочих инструментов управления пакетами. Чтобы установить, допустим, самый последний выпуск Jewel Ceph посредством ceph-deploy, вызовите

$ ceph-deploy install --release jewel mynewhostname
		

Добавьте свой новый хост (хосты) в нашу топологию CRUSH. Наш кластер для данного примера разделён по 12 имеющимся хостам, расположенным в 4 прочных металлических стойках с названиями rack1-iommi, rack2-butler, rack3-ward и rack4-dio. Чтобы обеспечить баланс мы добавляем по 1 хосту к трём имеющимся в каждой стойке. Вначале мы создаём сегменты host.

$ ceph osd crush add-bucket newhost13 host
$ ceph osd crush add-bucket newhost14 host
$ ceph osd crush add-bucket newhost15 host
$ ceph osd crush add-bucket newhost16 host
		

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

Наше окно ceph -s отображает нам наше наполнение OSD.

osdmap e33981: 279 osds: 279 up, 279 in
flags sortbitwise,require_jewel_osds
 	   

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

$ ceph-deploy disk list newhost13 newhost14 newhost15 newhost16
[newhost13][DEBUG ]/dev/sda :
[newhost13][DEBUG ] /dev/sda1 other, linux_raid_member
[newhost13][DEBUG ] /dev/sda2 other, linux_raid_member
[newhost13][DEBUG ]/dev/sdb other, unknown
[newhost13][DEBUG ]/dev/sdc :
[newhost13][DEBUG ] /dev/sdc1 other, unknown
[newhost13][DEBUG ] /dev/sdc2 other, unknown
[...]
		

Для идентификации разделов и монтирования каждого диска также удобна утилита lsblk.

# lsblk
NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                      8:0    0 223.6G 0 disk
├─sda1                   8:1    0   243M 0 part
│ └─md0                  9:0    0 242.8M 0 raid1 /boot
└─sda2                   8:2    0 223.3G 0 part
└─md1                    9:1    0 223.2G 0 raid1
└─vg0-root (dm-0)      252:0    0 223.2G 0 lvm   /
  sdb                    8:16   0   3.5T 0 disk
├─sdb1                   8:17   0   3.5T 0 part  /var/lib/ceph/osd/ceph-0
└─sdb2                   8:18   0    10G 0 part
sdc                      8:32   0   3.5T 0 disk
		

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

$ for i in {b..i} ; do ceph-deploy disk zap newhost13:$i ; cephdeploy disk zap newhost14:$i ; ceph-deploy disk zap newhost15:$i; ceph-deploy disk zap newhost16:$i ; done 
		

Это потребует какого- то времени, но когда мы завершим, мы будем знать, что все наши устройства готовы к оснащению. При создании нового OSD в случае, если ceph-deploy исполняется в каком- бы то ни было существующем разделе, он выразит недовольство и закончится неудачей.

Теперь мы создадим OSD на всех своих новых устройствах. Они будут автоматически размещаться внутри соответствующих сегментов host, которые мы создали заранее. Так как все новые сегменты host всё ещё располагаются вовне нашего корня CRUSH, эти OSD всё ещё не будут принимать никакие данные. Если бы мы предпочли воспользоваться шифрованием dmcrypt или новой основой хранения BlueStore, мы бы могли добавить флаги --dmcrypt и --bluestore , но давайте останемся в основном русле в данный момент.

$ ceph-deploy osd create newhost13:sd{b..i}
[ceph_deploy.cli][INFO ] Invoked (1.5.37): /usr/bin/ceph-deploy osd create newhost13:sdb
[ceph_deploy.cli][INFO ] ceph-deploy options:
[ceph_deploy.cli][INFO ] username : None
[ceph_deploy.cli][INFO ] disk : [('newhost13', '/dev/sdb', None)]
[ceph_deploy.cli][INFO ] dmcrypt : False
[ceph_deploy.cli][INFO ] verbose : False
[ceph_deploy.cli][INFO ] bluestore : None
[ceph_deploy.cli][INFO ] overwrite_conf : False
[ceph_deploy.cli][INFO ] subcommand : create
[ceph_deploy.cli][INFO ] dmcrypt_key_dir : /etc/ceph/dmcrypt-keys
[ceph_deploy.cli][INFO ] quiet : False
[ceph_deploy.cli][INFO ] cd_conf : <ceph_deploy.conf.cephdeploy.Conf instance at 0x7feeb5599998>
[ceph_deploy.cli][INFO ] cluster : ceph
[ceph_deploy.cli][INFO ] fs_type : xfs
[ceph_deploy.cli][INFO ] func : <function osd at 0x7feeb5e641b8>
[ceph_deploy.cli][INFO ] ceph_conf : None
[ceph_deploy.cli][INFO ] default_release : False
[ceph_deploy.cli][INFO ] zap_disk : False
[ceph_deploy.osd][DEBUG ] Preparing cluster ceph disks newhost13:/dev/sdb:
[newhost13][DEBUG ] connection detected need for sudo
[newhost13][DEBUG ] connected to host: newhost13
[newhost13][DEBUG ] detect platform information from remote host
[newhost13][DEBUG ] detect machine type
[newhost13][DEBUG ] find the location of an executable
[newhost13][INFO ] Running command: sudo /sbin/initctl version
[newhost13][DEBUG ] find the location of an executable
[ceph_deploy.osd][INFO ] Distro info: Ubuntu 14.04 trusty
[ceph_deploy.osd][DEBUG ] Deploying osd to newhost13
[newhost13][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf
[ceph_deploy.osd][DEBUG ] Preparing host newhost13 disk /dev/sdb journal None activate True
[newhost13][DEBUG ] find the location of an executable
[newhost13][INFO ] Running command: sudo /usr/sbin/ceph-disk -v prepare --fs-type xfs -- /dev/sdb
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-osd --show-config-value=fsid
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-osd --check-allows-journal -i 0 --setuser ceph --setgroup ceph
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-osd --check-wants-journal -i 0 --setuser ceph --setgroup ceph
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-osd --check-needs-journal -i 0 --setuser ceph --setgroup ceph
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] set_type: Will colocate journal with data on /dev/sdb
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-osd --show-config-value=osd_journal_size
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-conf --name=osd. --lookup osd_mkfs_options_xfs
[newhost13][WARNIN] command: Running command: /usr/bin/ceph-conf --name=osd. --lookup osd_mount_options_xfs
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] ptype_tobe_for_name: name = journal
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] create_partition: Creating journal partition num 2 size 10240 on /dev/sdb
[newhost13][WARNIN] command_check_call: Running command: /sbin/sgdisk --new=2:0:+10240M --change-name=2:ceph journal --partition-guid=2:8733d257-5b21-4574-8537-95a040ae5929 --typecode=2:45b0969e-9b03-4f30-b4c6-b4b80ceff106 --mbrtogpt -- /dev/sdb
[newhost13][DEBUG ] Creating new GPT entries.
[newhost13][DEBUG ] The operation has completed successfully.
[newhost13][WARNIN] update_partition: Calling partprobe on created device /dev/sdb
[newhost13][WARNIN] command_check_call: Running command: /sbin/udevadm settle --timeout=600
[newhost13][WARNIN] command: Running command: /usr/bin/flock -s /dev/sdb /sbin/partprobe /dev/sdb
[newhost13][WARNIN] command_check_call: Running command: /sbin/udevadm settle --timeout=600
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb2 uuid path is /sys/dev/block/8:18/dm/uuid
[newhost13][WARNIN] prepare_device: Journal is GPT partition /dev/disk/by-partuuid/8733d257-5b21-4574-8537-95a040ae5929
[newhost13][WARNIN] prepare_device: Journal is GPT partition /dev/disk/by-partuuid/8733d257-5b21-4574-8537-95a040ae5929
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] set_data_partition: Creating osd partition on /dev/sdb
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] ptype_tobe_for_name: name = data
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] create_partition: Creating data partition num 1 size 0 on /dev/sdb
[newhost13][WARNIN] command_check_call: Running comma_partition: Calling partprobe on created device /dev/sdb
[newhost13][WARNIN] command_check_call: Running command: /sbin/udevadm settle --timeout=600
[newhost13][WARNIN] command: Running command: /usr/bin/flock -s /dev/sdb /sbin/partprobe /dev/sdb
[newhost13][WARNIN] command_check_call: Running command: /sbin/udevadm settle --timeout=600
[newhost13][WARNIN] get_dm_uuid: get_dm_uuid /dev/sdb uuid path is /sys/dev/block/8:16/dm/uuid
[newhost13][WARNIN] get_dm_uuid:size 8192
[newhost13][WARNIN] switching to logical sector size 512
[newhost13][DEBUG ] meta-data=/dev/sdb1 isize=2048 agcount=32,agsize=29220715 blks
[newhost13][DEBUG ] = sectsz=512 attr=2, projid32bit=0
[newhost13][DEBUG ] data = bsize=4096 blocks=935062865,imaxpct=5
[newhost13][DEBUG ] = sunit=0time, nodiratime,inode64,logbsize=256k,delaylog
[newhost13][WARNIN] command_check_call: Running command: /bin/mount -t xfs -o rw,noatime,nodiratime,inode64,logbsize=256k,delaylog -- /dev/sdb1 /var/lib/ceph/tmp/mnt.LjUwTs
[newhost13][WARNIN] populate_data_path: Preparing osd data dir /var/lib/ceph/tmp/mnt.LjUwTs
[newhost13][WARNIN] command: Running command: /bin/chown -R ceph:ceph /var/lib/ceph/tmp/mnt.LjUwTs/ceph_fsid.44648.tmp
[newhost13][WARNIN7-95a040ae5929
[newhost13][WARNIN] command: Running command: /bin/chown -R ceph:ceph /var/lib/ceph/tmp/mnt.LjUwTs
[newhost13][WARNIN] unmount: Unmounting /var/lib/ceph/tmp/mnt.LjUwTs
[newhost13][WARNIN] command_check_call: Running command_check_call: Running command: /sbin/udevadm settle --timeout=600
[newhost13][WARNIN] command_check_call: Running command: /sbin/udevadm trigger --action=add --sysname-match sdb1
[newhost13][INFO ] checking OSD status...
[newhost13][DEBUG ] find the location of an executable
[newhost13][INFO ] Running command: sudo /usr/bin/ceph osd stat --format=json
[newhost13][WARNIN] there is 1 OSD down
[newhost13][DEBUG ] Host newhost13 is now ready for osd use.
   ...
$ ceph-deploy osd create newhost14:sd{b..i}
$ ceph-deploy osd create newhost15:sd{b..i}
$ ceph-deploy osd create newhost16:sd{b..i}
		

Ух ты, прилично прокатились. Вы можете осознать ценность такого инструментария как ceph-deploy для выполнения столь тяжёлого для вас подъёма. Мы не будем останавливаться на каждой строке приведённого выше вывода, но в итоге ceph-deploy обеспечивает вас правильными разделами на диске, создаёт файловую систему XFS, заполняет её необходимыми средствами для службы OSD и вызывает специфичные для Ceph правила udev, которые монтируют и запускают все OSD. Предостерегающее сообщение there is 1 OSD down выглядит тревожащим, но оно безобидно: могут потребоваться одна или две минуты для полной загрузки и регистрации OSD в имеющихся Мониторах.

В своём окне ceph -s мы видим все новые OSD добавленными в общее семейство, причём поднятыми (up), вошедшими (in) и с последовательной нумерацией OSD по мере исполнения.

osdmap e33999: 97 osds: 97 up, 97 in
flags sortbitwise,require_jewel_osds
 	   

Мы можем исполнить ceph osd trees чтобы разглядеть все новые OSD в своём новом хосте. С добавкой нашего номинального 3.84 ТБ устройства вывод выглядит примерно так:

  ...
  -18 3.48199        host
  0   3.48199      osd.96        up  1.00000 1.00000
		

Хотя все наши новые OSD успешно предоставлены, мы всё ещё не можем перемещать на них данные. Вначале мы временно установим их веса CRUSH в значение 0 чтобы предотвратить шипение потока данных прежде чем мы не будем готовы. Вначале мы удостоверимся что вы перехватили все веса CRUSH, отображённые ceph osd tree, так как они понадобятся нам позднее. В узле администратора или Монитора выполните эту команду от имени root с указанием идентификаторов всех своих новых OSD.

# ceph osd crush reweight osd.id 0
		

Теперь будет безопасно переместить все новые хосты с их стадами OSD в их стойки. Поскольку веса самих хостов и OSD сейчас равны 0, никакие новые данные не будут в них пока размещены.

# ceph osd crush move newhost13 rack=rack1-iommi
# ceph osd crush move newhost14 rack=rack2-butler
# ceph osd crush move newhost15 rack=rack3-ward
# ceph osd crush move newhost16 rack=rack4-dio
		

Исполнение ceph osd tree теперь покажет нам наши новые хосты и OSD в каждой из стоек.

Теперь мы будем постепенно увеличивать веса CRUSH своих новых OSD с тем, чтобы Ceph начал добавлять данные. Идя небольшими шагами небольшого число Групп размещения мы избегаем появления громадного оттока и потенциального воздействия на пользователя со стороны лавины данных в наши новые OSD. Заполните перечень новых номеров OSD отображённый ceph osd tree, будьте очень аккуратны при получении необходимых номеров всех (и только их) своих новых OSD, которые в настоящее время имеют вес 0. Для краткости здесь мы будем перечислять только три, но вы обязаны перечислять все. Наши новые OSD должны вернуться к весу 3.48199, однако вы должны быть осторожны чтобы указывать надлежащим образом свои номера. Флаг -r указывает пробный запуск; когда вы удовлетворитесь тем, как исполняется ваш сценарий, снова осуществите выполнение без него.

# ceph-gentle-reweight -b 10 -d 0.01 -t 3.48199 -i 10 -r -o osd.96,osd.97,osd.98
...
# ceph-gentle-reweight -b 10 -d 0.01 -t 3.48199 -i 10 -o osd.96,osd.97,osd.98
		

Пока вы разглядываете эту бесценную утилиту, безопасно взвешивающую ваши OSD для входа в полный рабочий режим, давайте кратко обсудим что происходит. Данный сценарий проверяет текущие веса CRUSH для OSD и следит одним глазом за жизнеспособностью кластера. Когда это безопасно, вес CRUSH каждого OSD последовательно увеличивается на абсолютную величину -d и наш сценарий наблюдает за повторной балансировкой кластера. Никакие дополнительные шаги не предпринимаются до тех пор, пока общее число загрузок Групп размещения не упадёт ниже 10, что определяется имеющимся аргументом -b. Устанавливая его в небольшое, но не нулевое значение, мы сохраняем некоторое время, которое в противном случае было пы потрачено на ожидание исполнения самого последнего бита повторной балансировки. Когда заполнение становится настолько лёгким, будет нормальным добавить в топку ещё. Наш аргумент -t указывает окончательный вес CRUSH, которого мы желаем достичь для своих OSD. В нашем случае понадобится примерно 350 шагов, которые приведут нас к этому показателю, как в басне про Черепаху и Зайца. Окончательный аргумент -i запрашивает данный сценарий дополнительные 10 секунд передышки между шагами, просто в качестве доброй воли.

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

В процессе исполнения и, в особенности, по его завершению, вы можете вызывать ceph df; ceph osd tree в некотором отдельном окне чтобы отслеживать текущую ёмкость своего кластера и медленное но верное увеличение весов CRUSH новых OSD. Общая ёмкость также будет отражаться в вашем окне ceph -s. При выходе из этого сценария вы можете увидеть очень- очень незначительное отличие окончательного веса от того, которое вы имели первоначально. Ceph имеет некий способ отсекания или округления самых последних значащих цифр до двух. Это отличие незначительно и им можно пренебречь.

Теперь мы успешно расширили ёмкость своего кластера на 33% -- возможно и больше, если ваши новые устройства OSD больше первоначальных. Ваши пользователи даже и не заметили того как это произошло. Ceph это всё для победы (FTW).

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

Чем больше растёт число OSD, тем больше возможностей появляется, приближаясь к кривой нормального распределения. Для суммирования применения всех OSD совместно с указанием того, насколько они откланяются от среднего значения можно применять утилиту ceph osd df. Вот некий пример распределения кластер до и после того как мы принимаем действия. Здесь наш самый свободный OSD наполнен на 29%, всего лишь 80% от среднего значения по кластеру, а наиболее загруженный залит на 44%, что составляет 124% от среднего значения кластера.

# ceph status
   cluster ce2bcf60-efd0-1138-bxc5-936beak1s9a7
     health HEALTH_OK
     monmap e1: 5 mons at {mon01=10.7.4.4:6789/0,mon02=10.7.4.5:6789/0,mon03=10.7.4.132:6789/0,mon04=10.7.4.133:6789/0,mon05=10.7.5.4:6789/0}
            election epoch 10, quorum 0,1,2,3,4 mon01,mon02,mon03,mon04,mon05
     osdmap e14922: 285 osds: 285 up, 285 in
            flags sortbitwise,require_jewel_osds
      pgmap v18454754: 16384 pgs, 1 pools, 119 TB data, 32487 kobjects
            353 TB used, 638 TB / 992 TB avail
               16364 active+clean
                  14 active+clean+scrubbing+deep
                   6 active+clean+scrubbing
   client io 814 MB/s rd, 537 MB/s wr, 18375 op/s rd, 7170 op/s wr

# ceph osd df | head -3
ID WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS
  0 3.48199  1.00000 3565G 1250G 2314G 35.08 0.98 169
  1 3.48199  1.00000 3565G 1377G 2187G 38.64 1.08 186

# ceph osd df | sort -n -k 7 | head -6
ID WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS
MIN/MAX VAR: 0.80/1.24 STDDEV: 2.90
               TOTAL 992T  355T  636T 35.85
253 3.48199  1.00000 3565G 1028G 2536G 28.85 0.80 139
208 3.48199  1.00000 3565G 1046G 2518G 29.36 0.82 141
124 3.48199  1.00000 3565G 1051G 2514G 29.48 0.82 142

# ceph osd df | sort -n -k 7 |tail -3
176 3.48199  1.00000 3565G 1542G 2022G 43.27 1.21 208
241 3.48199  1.00000 3565G 1565G 1999G 43.92 1.22 211
283 3.48199  1.00000 3565G 1589G 1975G 44.58 1.24 214
		

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

# ceph osd df | egrep -v WEIGHT\|TOTAL\|MIN\|ID | awk '{print 1, int($7)}' | ./histogram.py -a -b 100 -m 0 -x 100 -p 1
# NumSamples = 285; Min = 0.00; Max = 100.00
# Mean = 35.385965; Variance = 8.587873; SD = 2.930507; Median 35.000000
# each ∎ represents a count of 1
    0.0000 -     1.0000 [     0]:  (0.00%)
    1.0000 -     2.0000 [     0]:  (0.00%)
    2.0000 -     3.0000 [     0]:  (0.00%)
...
   26.0000 -    27.0000 [     0]:  (0.00%)
   27.0000 -    28.0000 [     1]: ∎ (0.35%)
   28.0000 -    29.0000 [     3]: ∎∎∎ (1.05%)
   29.0000 -    30.0000 [     6]: ∎∎∎∎∎∎ (2.11%)
   30.0000 -    31.0000 [    13]: ∎∎∎∎∎∎∎∎∎∎∎∎∎ (4.56%)
   31.0000 -    32.0000 [    29]:
 ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (10.18%)
   32.0000 -    33.0000 [    30]:
 ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (10.53%)
   33.0000 -    34.0000 [    25]:
 ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (8.77%)
   34.0000 -    35.0000 [    37]:
 ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (12.98%)
   35.0000 -    36.0000 [    46]:
 ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
                                                             (16.14%)
   36.0000 -    37.0000 [    32]:
 ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (11.23%)
   37.0000 -    38.0000 [    21]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
                                  (7.37%)
   38.0000 -    39.0000 [    22]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
                                  (7.72%)
   39.0000 -    40.0000 [     7]: ∎∎∎∎∎∎∎ (2.46%)
   40.0000 -    41.0000 [     5]: ∎∎∎∎∎ (1.75%)
   41.0000 -    42.0000 [     2]: ∎∎ (0.70%)
   42.0000 -    43.0000 [     5]: ∎∎∎∎∎ (1.75%)
   43.0000 -    44.0000 [     1]: ∎ (0.35%)
   44.0000 -    45.0000 [     0]: (0.00%)
   45.0000 -    46.0000 [     0]: (0.00%)
   46.0000 -    47.0000 [     0]: (0.00%)
		

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

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

# ceph osd reweight 283 .98000
		

Это выравнивает размещение данных osd.283 до меньшего значения; данные будут перемещены прочь на прочие OSD. Исполнение ceph status отобразит Группы размещения в состоянии remapped в то время, пока наш кластер осуществляет перестроение (recovery) чтобы свести всё к указанному новому распределению данных. Допустимое значение перераспределения веса должно находиться в диапазоне от 0.0 до 1.0 поэтому мы не можем назначать перераспределение веса большее 1 для увеличения использования недозаполненных OSD. Тем самым, мы работаем сверху вниз; действительно - переполненные OSD куда опаснее.

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

Мы можем продолжать данный процесс поступательно пошагово, выпихивая данные из наихудшего претендента, делая возможной ребалансировку своего кластера, а после этого выталкивая своего нового наиболее отклонившегося. Прополоскать, залить, повторить. Однако, это становится похожим на игру Прибей крота (Whack-a-Mole), или как пережимание воздушного шарика {Прим. пер.: Надавил тут, вспучилось рядом}. Более действенным и быстрым процессом является перевзвешивание множества OSD за раз.

Именно здесь вступает в дело инструментарий Ceph ceph osd reweight-by-utilization. Он появился в выпуске Hammer, хотя документация до сих пор не завершена. Его следует вызывать с тремя аргументами:

Поначалу этот процесс был выстрелом в темноту; было трудно предсказать сколько данных будет перемещено и, тем самым, оптимизация размера параметров было сопряжено с догадкой. Jewel ввёл команду test-reweight-by-utilization для моделирования наборов параметров с исполнением вхолостую; это также было продолжено поддерживаться в последующих точечных версиях Hammer.

Вот некий пример холостого прогона в приведённом нами выше кластере. Мы выбираем некий осторожный максимальный вес изменения для исполнения и некую охапку общего числа OSD для регулировки на основе их общего числа в нашем кластере. Было бы неплохо добавить некий вариант для указания этого значения в виде процентного соотношения вместо какого- то абсолютного число, однако у нас нет этого на сегодняшний день. Мы выбираем какую- то консервативную отправную точку для значения порога отсекающего процентного соотношения на сонове перегруженности (overload), которую демонстрирует ceph osd df для наших наиболее наполненных OSD. Ниже мы попытаемся по шагам агрессивно увеличивать значения порога; отметим, что по мере приближения к среднему значению 100% (примерно к 35% заполненности, как указывает ceph osd df), растёт общее число задействованных Групп размещения. Как только мы определим некий набор параметров, который имеет результатом значительную, но допустимую степень выравнивания, мы выстрелим ими по- настоящему.

# ceph osd test-reweight-by-utilization 120 0.01 30
no change
moved 7 / 49152 (0.0142415%)
avg 172.463
stddev 13.9391 -> 13.8722 (expected baseline 13.1095)
min osd.253 with 139 -> 139 pgs (0.805969 -> 0.805969 * mean)
max osd.283 with 214 -> 212 pgs (1.24084 -> 1.22925 * mean)

oload 120
max_change 0.01
max_change_osds 30
average 0.358507
overload 0.430208
osd.283 weight 1.000000 -> 0.990005
osd.241 weight 1.000000 -> 0.990005
osd.176 weight 1.000000 -> 0.990005
osd.144 weight 1.000000 -> 0.990005
osd.19 weight 1.000000 -> 0.990005
osd.158 weight 1.000000 -> 0.990005
		

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

# ceph osd test-reweight-by-utilization 117 0.01 30
no change
moved 10 / 49152 (0.0203451%)
avg 172.463
stddev 13.9391 -> 13.8395 (expected baseline 13.1095)
min osd.253 with 139 -> 139 pgs (0.805969 -> 0.805969 * mean)
max osd.283 with 214 -> 212 pgs (1.24084 -> 1.22925 * mean)

oload 117
max_change 0.01
max_change_osds 30
average 0.358474
overload 0.419415
osd.283 weight 1.000000 -> 0.990005
osd.241 weight 1.000000 -> 0.990005
osd.176 weight 1.000000 -> 0.990005
osd.144 weight 1.000000 -> 0.990005
osd.19 weight 1.000000 -> 0.990005
osd.158 weight 1.000000 -> 0.990005
osd.128 weight 1.000000 -> 0.990005
osd.257 weight 1.000000 -> 0.990005
		

Слегка лучше, но мы можем быть более агрессивными.

# ceph osd test-reweight-by-utilization 114 0.01 30
no change
moved 24 / 49152 (0.0488281%)
avg 172.463
stddev 13.9391 -> 13.7556 (expected baseline 13.1095)
min osd.253 with 139 -> 139 pgs (0.805969 -> 0.805969 * mean)
max osd.283 with 214 -> 212 pgs (1.24084 -> 1.22925 * mean)

oload 114
max_change 0.01
max_change_osds 30
average 0.358479
overload 0.408666
osd.283 weight 1.000000 -> 0.990005
osd.241 weight 1.000000 -> 0.990005
osd.176 weight 1.000000 -> 0.990005
osd.144 weight 1.000000 -> 0.990005
osd.19 weight 1.000000 -> 0.990005
osd.158 weight 1.000000 -> 0.990005
osd.128 weight 1.000000 -> 0.990005
osd.257 weight 1.000000 -> 0.990005
osd.171 weight 1.000000 -> 0.990005
osd.179 weight 1.000000 -> 0.990005
osd.149 weight 1.000000 -> 0.990005
osd.97 weight 1.000000 -> 0.990005
osd.37 weight 1.000000 -> 0.990005
osd.304 weight 1.000000 -> 0.990005

# ceph osd test-reweight-by-utilization 112 0.01 30
no change
moved 28 / 49152 (0.0569661%)
avg 172.463
stddev 13.9391 -> 13.7446 (expected baseline 13.1095)
min osd.253 with 139 -> 139 pgs (0.805969 -> 0.805969 * mean)
max osd.283 with 214 -> 212 pgs (1.24084 -> 1.22925 * mean)

oload 112
max_change 0.01
max_change_osds 30
average 0.358480
overload 0.401497
...
		

Ещё лучше, однако на данном кластере all-SSD мы можем позволить себе откусить ещё больше.

# ceph osd test-reweight-by-utilization 110 0.01 30
no change
moved 44 / 49152 (0.0895182%)
avg 172.463
stddev 13.9391 -> 13.6904 (expected baseline 13.1095)
min osd.253 with 139 -> 139 pgs (0.805969 -> 0.805969 * mean)
max osd.283 with 214 -> 212 pgs (1.24084 -> 1.22925 * mean)

oload 110
max_change 0.01
max_change_osds 30
average 0.358480
overload 0.394328
osd.283 weight 1.000000 -> 0.990005
osd.241 weight 1.000000 -> 0.990005
osd.176 weight 1.000000 -> 0.990005
		

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

Давайте пройдём далее и вызовем данный процесс с этими тремя параметрами.

# ceph osd reweight-by-utilization 110 0.01 30
moved 44 / 49152 (0.0895182%)
avg 172.463
stddev 13.9391 -> 13.6904 (expected baseline 13.1095)
min osd.253 with 139 -> 139 pgs (0.805969 -> 0.805969 * mean)
max osd.283 with 214 -> 212 pgs (1.24084 -> 1.22925 * mean)

oload 110
max_change 0.01
max_change_osds 30
average 0.358437
overload 0.394280
osd.283 weight 1.000000 -> 0.990005
osd.241 weight 1.000000 -> 0.990005
osd.176 weight 1.000000 -> 0.990005
osd.144 weight 1.000000 -> 0.990005
osd.19 weight 1.000000 -> 0.990005
		

Раз значения изменения загруженности изменены, наш кластер сдвигает данные чтобы свести всё к новому соответствию CRUSH. Это эквивалентно вызову 30 отдельных команд ceph osd reweight или, в Luminous, некоторому одному отдельному вызову ceph osd reweightn, действующему на всех за один раз.

Наш кластер теперь вступает в какой- то период заполнения/ перестроения. В вашем верном окне watch ceph status вы наблюдаете рост общего числа и процентного соотношения деградировавших/ неуместных объектов по мере планирования соответствующими Группами размещения их регулировок. Эти значения будут затем поступательно уменьшаться по мере того, как Группы размещения войдут в состояние заполнения, в котором они активно перемещают данные, отражающие наши изменения в их Наборах активных (Acting Sets)

cluster cef00bar40-efd0-11e6-bcc5-936eieiob9a7
     health HEALTH_WARN
            44 pgs backfilling
            recovery 8/100169721 objects degraded (0.000%)
            recovery 157792/100169721 objects misplaced (0.158%)
     monmap e1: 5 mons at {mon01=10.7.4.4:6789/0,mon02=10.7.4.5:6789/0,mon03=10.7.4.132:6789/0,mon04=10.7.4.133:6789/0,mon05=10.7.5.4:6789/0}
            election epoch 10, quorum 0,1,2,3,4 mon01,mon02,mon03,mon04,mon05
     osdmap e15516: 285 osds: 285 up, 285 in; 44 remapped pgs
            flags sortbitwise,require_jewel_osds
      pgmap v18489106: 16384 pgs, 1 pools, 120 TB data, 32578 kobjects
            355 TB used, 636 TB / 992 TB avail
            8/100169721 objects degraded (0.000%)
            157792/100169721 objects misplaced (0.158%)
               16313 active+clean
                  44 active+remapped+backfilling
                  18 active+clean+scrubbing+deep
                   9 active+clean+scrubbing
recovery io 7568 MB/s, 2 keys/s, 2018 objects/s
  client io 1080 MB/s rd, 574 MB/s wr, 27120 op/s rd, 11987 op/s wr
		

Когда работа завершится, наш кластер вернётся в HEALTH_OK и его обновлённая гистограмма покажет, что мы когда угодно очень аккуратно сжимаем наиболее заполненные OSD.

# ceph osd df | sort -n -k 7 | tail -3
128 3.48199  0.99001 3565G 1541G 2023G 43.23 1.21 208
241 3.48199  0.99001 3565G 1565G 1999G 43.92 1.22 211
283 3.48199  0.99001 3565G 1574G 1990G 44.17 1.23 212
		

В приведённом выше выводе мы видим, что самый наполненных OSD теперь залит теперь только на 44.17%, а его отклонение от среднего значения уменьшилось до 123%. osd.283 теперь содержит на 15 ГБ менее того значения, которое было ранее.

cluster cef00bar40-efd0-11e6-bcc5-936eieiob9a7
     health HEALTH_OK
     monmap e1: 5 mons at {mon01=10.7.4.4:6789/0,mon02=10.7.4.5:6789/0,mon03=10.7.4.132:6789/0,mon04=10.7.4.133:6789/0,mon05=10.76.50.4:6789/0}
            election epoch 10, quorum 0,1,2,3,4 mon01,mon02,mon03,mon04,mon05
     osdmap e15559: 285 osds: 285 up, 285 in
            flags sortbitwise,require_jewel_osds
      pgmap v18492138: 16384 pgs, 1 pools, 120 TB data, 32592 kobjects
            355 TB used, 636 TB / 992 TB avail
               16361 active+clean
                  17 active+clean+scrubbing+deep
                   6 active+clean+scrubbing
  client io 996 MB/s rd, 573 MB/s wr, 29542 op/s rd, 14264 op/s wr

# ceph osd df | egrep -v WEIGHT\|TOTAL\|MIN\|ID | awk '{print 1, int($7)}' | ./histogram.py -a -b 100 -m 0 -x 100 -p 1
# NumSamples = 285; Min = 0.00; Max = 100.00
# Mean = 35.392982; Variance = 8.182407; SD = 2.860491; Median 35.000000
# each ∎ represents a count of 1
    0.0000 -     1.0000 [     0]:  (0.00%)
...
   26.0000 -    27.0000 [     0]: (0.00%)
   27.0000 -    28.0000 [     1]: ∎ (0.35%)
   28.0000 -    29.0000 [     2]: ∎∎ (0.70%)
   29.0000 -    30.0000 [     6]: ∎∎∎∎∎∎ (2.11%)
   30.0000 -    31.0000 [    14]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (4.91%)
   31.0000 -    32.0000 [    26]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (9.12%)
   32.0000 -    33.0000 [    32]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (11.23%)
   33.0000 -    34.0000 [    26]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (9.12%)
   34.0000 -    35.0000 [    36]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (12.63%)
   35.0000 -    36.0000 [    45]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (15.79%)
   36.0000 -    37.0000 [    33]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (11.58%)
   37.0000 -    38.0000 [    22]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (7.72%)
   38.0000 -    39.0000 [    25]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (8.77%)
   39.0000 -    40.0000 [     7]: ∎∎∎∎∎∎∎ (2.46%)
   40.0000 -    41.0000 [     3]: ∎∎∎ (1.05%)
   41.0000 -    42.0000 [     2]: ∎∎ (0.70%)
   42.0000 -    43.0000 [     4]: ∎∎∎∎ (1.40%)
   43.0000 -    44.0000 [     1]: ∎ (0.35%)
   44.0000 -    45.0000 [     0]: (0.00%)
		

Приводимая после изменения загруженности гистограмм отражает современные улучшения в расхождениях и стандартных отклонениях. Мы на самом деле сделали больше различий, чем те абсолютные значения, о которых указывает в отчёте ceph osd df; в промежутке времени между первым взглядом на распределение и нашим опросом после выравнивания, наш кластер обзавёлся примерно 2 ТБ данных, которые слегка подталкивали вверх общее процентное наполнение всех OSD, так как каждый принимал новые данные.

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

Обновление некоторого существующего, находящегося в эксплуатации кластера Ceph может быть одновременно и прямолинейной и хитроумной. Например, если вы всё ещё работаете в Firefly, вместо обновления напрямую до Luminous, вам придётся рассмотреть вначале обновление до Hammer, затем до Jewel, и только после этого к Luminous. Данная стратегия полагает, что имеющееся созвездие старой и новой версий настолько велико, что превысят все комбинации всех проверяемых ресурсов.

Каждый выпуск Ceph снабжается замечаниями, которые детализируют наилучший процесс обновления. В некоторых случаях имеются критически важные засады, которые следует рассматривать особым образом. Например, по умолчанию демоны в Jewel и последующих выпусках исполняются как определённый пользователь ceph, вместо root. При обновлении на Jewel с более ранних выпусков следует аккуратно изменить имеющихся владельцев всех файлов внутри каждой файловой системы OSD. Имейте в виду, что понижение до более низкого основного выпуска Ceph обычно не поддерживается. Прежде чем запускать её в промышленную эксплуатацию, попробуйте новую версию в каком- то проверочном кластере.

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

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

Обновление ядра Linux, или даже операционной системы целиком, обычно более прямолинейно, чем обновление выпуска Ceph. Как правило, можно установить пакеты обновления заранее, осуществить все необходимые изменения файлов настройки, а затем последовательно перезагрузить серверы Ceph, опять же, обеспечив их полное вступление в строй и достижения жизнеспособности кластера между каждой перезагрузкой. В этом случае порядок обычно не важен, хотя далеко не редкость следовать той же последовательности MON=>OSD=>RGW=>MDS, что и ранее.

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

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

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

Вот ектенияпрактических приёмов работы с руками центра обработки данных.

В данной главе мы обсудили широкое разнообразие работ и задач сопровождения, которые являются частью жизненного цикла Ceph. Мы изучили топологию кластера, тема, которую мы продолжим в Главе 7, Мониторинг Ceph, а также ведение системных журналов Ceph. Мы также окунулись в ceph.conf для настройки запуска, инъекцию для динамичной настройки времени исполнения, а также сокеты администрирования для жатвы изобилия состояний и подробностей настроек. Также мы коснулись пользы формальных систем управления настройкой, таких как ceph-ansible.

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

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

Для начальной раскрутки кластера мы рекомендуем исключительный проект ceph-ansible, доступный здесь. {Прим. пер.: рискуем надоесть, но ещё раз приведём для полноты ссылку на наш перевод вышедшего в мае 2017 в издательстве Packt Publishing второго издания Полного руководства Ansible Джесс Китинг.}

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

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

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