Глава 11. Восстановление после сбоев

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

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

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

Убедитесь что вы следуете некоторым основным принципам, также упоминавшимся в Главе 1, Планирование Ceph. Не применяйте опции настроек подобные nobarrier и строго рассматривайте тот уровень репликаций, который вы применяете в Ceph для защиты своих данных. Ваши шансы на потерю данных сильно увязаны с тем уровнем избыточности, который вы настроили в Ceph, поэтому здесь предлагается тщательное планирование.

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

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

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

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

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

При наличии некоторой реплицированной копии ваших образов RBD в некотором отдельном кластере вы можете впечатляюще снизить как RTO (Recovery Time Objective, Целевое время восстановления), так и RPO (Recovery Point Objective, Директивный срок восстановления). RTO является показателем того, сколько времени пройдёт с момента начала восстановления до того момента, когда данный станут доступными. RPO это наихудший вариант измерения времени между каждой точкой данных и описывает ожидаемую потерю данных. Ежедневное резервное копирование имело бы некий RPO в 24 часа; например, потенциально любые данные, записанные до 24 часов с момента последнего резервного копирования будут потеряны если вам придётся их восстанавливать из резервной копии.

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

После всего сказанного, давайте взглянем ближе на то как работает зеркалирование RBD.

Одним из ключевых компонентов при зеркалировании RBD является сам журнал. Именно журнал зеркалирования RBD сохраняет все записи в данный RBD и отправляет подтверждения клиенту когда они совершены. Эти записи затем переписываются в свой первичный образ RBD. Такой журнал сам по себе хранится как объекты RADOS, аналогично предваряя то, чем являются образы RBD. Отдельно, удалённый демон rbd-mirror опрашивает настроенные зеркала RBD и вытаскивает самые новые записанные в журнал объекты на весь свой целевой кластер и воспроизводит их в своём целевом RBD.

Демон rbd-mirror отвечает за воспроизведение всего содержимого имеющегося журнала в некий целевой RBD в другом кластере Ceph. На данном целевом кластере должен исполняться только один демон rbd-mirror, только если вы не выполняете репликацию в обе стороны, в таком случае потребуется исполнение в обоих кластерах.

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

Требующийся Vagrantfile очень похож на тот, что мы использовали в Главе 2, Развёртывание Ceph для развёртывания вашего первоначального тестового кластера; вся части хостов в верхней части должны теперь выглядеть так:

nodes = [
 { :hostname => 'ansible', :ip => '192.168.0.40', :box => 'xenial64' },
  { :hostname => 'site1-mon1', :ip => '192.168.0.41', :box => 'xenial64' },
  { :hostname => 'site2-mon1', :ip => '192.168.0.42', :box => 'xenial64' },
  { :hostname => 'site1-osd1', :ip => '192.168.0.51', :box => 'xenial64', :ram => 1024, :osd => 'yes' },
  { :hostname => 'site2-osd1', :ip => '192.168.0.52', :box => 'xenial64', :ram => 1024, :osd => 'yes' }
]
 	   

Для настройки Ansible мы будем сопровождать два отдельных экземпляра настройки Ansible с тем, чтобы каждый кластер мог быть развёрнут отдельно. Затем мы будем сопровождать отдельные файлы хостов для экземпляров, которые мы определим, когда мы исполним план (playbook). Для выполнения этого мы не будем копировать свои файлы ceph-ansible в etc/ansible, а придержим их в соответствующем домашнем каталоге.

Склонируйте git https://github.com/ceph/ceph-ansible.git.

cp -a ceph-ansible ~/ceph-ansible2
 	   

Создайте точно такие же файлы с именами all и Ceph в своём каталоге group_vars, как мы это делали в Главе 2, Развёртывание Ceph. Это необходимо сделать в обеих копиях ceph-ansible:

Важно отметить, что зеркалирование RBD работает через систему извлечения (pull). Имеющийся демон rbd-mirror необходим для исполнения на том кластере, на который вы желаете зеркально отобразить свой RBD; он затем соединится со своим кластером источником и извлечёт все RBD. Если вы намереваетесь реализовать двустороннюю репликацию при которой каждый кластер Ceph реплицируется друг на друга, тогда вам необходимо исполнять такой демон rbd-mirror в обоих кластерах. Имея это в виду, давайте разрешим и запустим имеющуюся службу systemd для rbd-mirror на вашем целевом хосте:

udo systemctl enable ceph-rbd-mirror@admin
sudo systemctl start ceph-rbd-mirror@admin
 	   

Данный демон rbd-mirror теперь начнёт обрабатывать все имеющиеся образы RBD настроенные на зеркалирование в вашем первичном кластере.

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

sudo rbd --cluster remote mirror pool status rbd –verbose
 	   

Из предыдущего снимка экрана мы можем увидеть, что наш RBD mirror_test находится в состоянии up+replaying, это означает, что зеркалирование работает и мы можем видеть через entries_behind_master что он в настоящее время новейший.

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

Наш кластер источник показан здесь:

А вот и целевой кластер:

Прежде чем мы отработаем отказ своего RBD на имеющийся у нас второй кластер, давайте установим его соответствие, создадим некую файловую систему и поместим в него какой- нибудь файл, таким образом мы сможем подтвердить, что наше зеркалирование работает правильно. Так как в ядре Linux 4.11 имеющийся драйвер ядра RBD не поддерживает необходимую для зеркалирования RBD функцию журналирования имеющегося RBD, это означает, что вы не можете поставить в соответствие (map) данный RBD воспользовавшись имеющимся клиентом RBD ядра. Раз так, нам необходимо воспользоваться утилитой rbd-nbd, которая применяет драйвер librbd в комбинации с устройствами Linux nbd чтобы поставить в соответствие RBD через пространство пользователя. Хотя имеется множество вещей, которые могут заставить Ceph испытывать низкую производительность, вот один из самых вероятных вариантов:

sudo rbd-nbd map mirror_test
 	   

sudo mkfs.ext4 /dev/nbd0
 	   

sudo mount /dev/nbd0 /mnt
echo This is a test | sudo tee /mnt/test.txt
sudo umount /mnt
sudo rbd-nbd unmap /dev/nbd0
Now lets demote the RBD on the primary cluster and promote it on the
secondary
sudo rbd --cluster ceph mirror image demote rbd/mirror_test
sudo rbd --cluster remote mirror image promote rbd/mirror_test
 	   

Теперь поставим в соответствие и смонтируем свой RBD в нашем втором кластере, и мы должны иметь возможность прочитать свой проверочный текстовый файл, который вы создали в своём первичном кластере:

Мы можем отчётливо видеть, что данный RBD был успешно зеркалирован в наш второй кластер и всё содержимое файловой системы в точности такое же как мы оставили её в своём первичном кластере.

Это завершает наш раздел, посвящённый зеркалированию RBD.

При возникновении события, когда ряд OSD отказал, а вы не способны восстановить их с применением инструмента ceph-object-store, ваш кластер скорее всего будет в состоянии при котором большая часть, если не все, образов RBD являются недоступными. Однако всё ещё имеется вероятность что у вас будет возможность восстановить данные RBD с имеющихся в вашем кластере Ceph дисков. Существуют инструменты, которые могут осуществлять поиск по всей структуре данных OSD, выявлять файлы объектов, относящиеся к RBD, а затем собирать эти объекты обратно в некий образ диска, похожий на имевшийся первоначальный образ RBD.

В данном разделе мы сосредоточимся на инструменте Леннара Бэйдера (Lennart Bader) для восстановления некоторого тестового образа RBD из своего проверочного кластера. Данный инструмент позволяет восстанавливать образы RBD из имеющегося содержимого OSD Ceph без какого либо требования чтобы этот OSD был в рабочем и используемом состоянии. Следует отметить, что если данный OSD был разрушен вследствие разрушения лежащей в его основе файловой системы, имеющееся содержимое данного образа RBD может всё ещё быть разрушенным. Данный инструмент восстановления можно найти по адресу в следующем репозитории github: https://gitlab.lbader.de/kryptur/ceph-recovery.

Прежде чем мы приступим, убедитесь что у вас имеется небольшой тестовый RBD с действующей файловой системой, созданной в вашем кластере Ceph. Из- за того размера дисков в тестовой среде, которую мы создали в Главе 2, Развёртывание Ceph, рекомендуется чтобы ваш RBD был размеров всего в один гигабайт.

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

В данном примере мы смонтируем необходимое содержимое удалённого OSD через sshfs, который позволит вам удалённо монтировать каталоги через ssh. Однако в реальной жизни ничто не останавливает вас от физического монтирования дисков в другой сервер или какого- либо другого метода, если он потребуется. Данному инструменту всего лишь необходимо видеть все каталоги данных этого OSD:

На этом наш процесс восстановления образов RBD из умерших OSD Ceph завершён.

В данном разделе текущей главы мы рассмотрим сценарий, в котором некоторое число OSD может отключиться на некий непродолжительный промежуток времени, оставив некоторые объекты без достаточного числа копий репликаций. Важно заметить, что существует некая разница между неким объектом у которого совсем не осталось копий и объектом, который имеет остающуюся копию, однако он информирован, что другая копия должна иметь более поздние записи. Последний случай обычно наблюдается, когда мы исполняем свой кластер с установленным в 1 значением min_size.

Чтобы продемонстрировать как восстанавливать некий объект, который имеет просроченную копию данных, давайте выполним некую последовательность шагов для разрушения своего кластера:

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

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

В данном случае это pg 0.31, которая находится в деградированном состоянии, так как она имеет некий не обнаруженный объект. Давайте сделаем запрос к этой PG:

ceph pg 0.31 query
 	   

Заглянем в раздел восстановления; мы можем обнаружить, что Ceph попытался попробовать "osd": "0" для данного объекта, однако он down. Он попытался попробовать для этого объекта "osd": "1", но по некоторой причине он не был задействован, хотя мы и знаем что истинная причина состоит в устаревшей копии.

Теперь давайте взглянем некоторые дополнительные подробности утраченного объекта:

sudo ceph pg 0.31 list_missing
 	   

Строки need и have раскрывают причину. У нас имеется epoch 383'5, однако действующая копия данного объекта присутствует в 398'6; именно поэтому min_size=1 очень плохо. Вы можете оказаться в положении, когда у вас имеется только единственная действующая копия некоторого объекта. Если это было вызвано неким отказом диска, вы бы имели ещё большие проблемы.

Чтобы восстановиться в данном случае у нас имеются два варианта: мы можем либо выбрать применение более старой копии своего объекта, либо просто удалить его. Следует отметить, что если этот объект новее и некая более старая копия отсутствует в оставшихся OSD, это также удалит данный объект.

Чтобы удалить данный объект выполните это:

sudo ceph pg 0.31 list_missing
 	   

Для возврата выполните следующее:

ceph pg 0.31 mark_unfound_lost revert
 	   

На этом мы заканчиваем обсуждение восстановление не обнаруженных объектов.

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

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

Чтобы иметь возможность доступа к каждому OSD в нашем кластере для перестроения базы данных нашего монитора необходим инструментарий ceph-objectstore; в данном примере мы применим некий сценарий, который соединяется через ssh для доступа к нужным нам данным OSD. Так как все данные OSD не доступны любому пользователю, нам понадобится воспользоваться пользователем root чтобы зарегистрироваться во всех хостах OSD. По умолчанию большинство дистрибутивов Linux не допускают удалённую регистрацию root на основе пароля, поэтому убедимся что вы скопировали свой общедоступный ключ ssh для своих пользователей root в некоторые удалённые узлы OSD.

Приводимый ниже сценарий соединит с каждым из имеющихся узлов OSD, определённых в переменной hosts и выделит все те данные, которые необходимы для построения базы данных нашего монитора:

#!/bin/bash
hosts="osd1 osd2 osd3"
ms=/tmp/mon-store/
mkdir $ms
# collect the cluster map from OSDs
for host in $hosts; do
  echo $host
  rsync -avz $ms root@$host:$ms
  rm -rf $ms
  ssh root@$host <<EOF
    for osd in /var/lib/ceph/osd/ceph-*; do
      ceph-objectstore-tool --data-path \$osd --op update-mon-db --mon-store-path $ms
    done
EOF
  rsync -avz root@$host:$ms $ms
done
 	   

Этот код создаст в каталоге /tmp/mon-store следующее содержимое:

Нам также понадобится назначить новые полномочия через keyring:

sudo ceph-authtool /etc/ceph/ceph.client.admin.keyring --create-keyring --gen-key -n client.admin --cap mon 'al
 	   

sudo ceph-authtool /etc/ceph/ceph.client.admin.keyring --gen-key -n mon. --cap mon 'allow *'
sudo cat /etc/ceph/ceph.client.admin.keyring
 	   

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

sudo mv /var/lib/ceph/mon/ceph-mon1/store.db /var/lib/ceph/mon/ceph-mon1/store.bak
 	   

Теперь скопируем свою построенную вновь версию

sudo mv /tmp/mon-store/store.db /var/lib/ceph/mon/ceph-mon1/store.db
sudo chown -R ceph:ceph /var/lib/ceph/mon/ceph-mon1
 	   

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

sudo ceph-mon -i mon1 --extract-monmap /tmp/monmap
 	   

Проверьте содержимое monmap:

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

sudo monmaptool /tmp/monmap --rm noname-b
sudo monmaptool /tmp/monmap --rm noname-c
 	   

Теперь проверим вновь, чтобы удостовериться, что они ушли окончательно:

sudo monmaptool /tmp/monmap –print
 	   

sudo monmaptool /tmp/monmap –print
 	   

Перезапустите все свои OSD, таким образом они повторно присоединятся к нашему кластеру; затем мы получим возможность успешно запрашивать состояние данного кластера и обнаружим, что ваши данные всё ещё там:

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

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

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

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

Утверждения (assertions) применяются в Ceph чтобы гарантировать, что в процессе исполнения данного кода все предположения, которые были сделаны относительно его среды работы остаются верными. Такие декларации разбросаны по всему коду Ceph и разработаны с целью обнаружения любых условий которые могут вызвать дальнейшие проблемы если данный код не остановить.

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

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

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

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

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

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

2017-03-02 22:41:32.338290 7f8bfd6d7700 -1 osd/ReplicatedPG.cc: In function 'void ReplicatedPG::hit_set_trim(ReplicatedPG::RepGather*, unsigned int)' thread 7f8bfd6d7700 time 2017-03-02 22:41:32.335020

osd/ReplicatedPG.cc: 10514: FAILED assert(obc)


ceph version 0.94.7 (d56bdf93ced6b80b07397d57e3fa68fe68304432)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x85) [0xbddac5]
 2: (ReplicatedPG::hit_set_trim(ReplicatedPG::RepGather*, unsigned int)+0x75f) [0x87e48f]
 3: (ReplicatedPG::hit_set_persist()+0xedb) [0x87f4ab]
 4: (ReplicatedPG::do_op(std::tr1::shared_ptr<OpRequest>&)+0xe3a) [0x8a0d1a]
 5: (ReplicatedPG::do_request(std::tr1::shared_ptr<OpRequest>&, ThreadPool::TPHandle&)+0x68a) [0x83be4a]
 6: (OSD::dequeue_op(boost::intrusive_ptr<PG>, std::tr1::shared_ptr<OpRequest>, ThreadPool::TPHandle&)+0x405) [0x69a5c5]
 7: (OSD::ShardedOpWQ::_process(unsigned int, ceph::heartbeat_handle_d*)+0x333) [0x69ab33]
 8: (ShardedThreadPool::shardedthreadpool_worker(unsigned int)+0x86f) [0xbcd1cf]
 9: (ShardedThreadPool::WorkThreadSharded::entry()+0x10) [0xbcf300]
 10: (()+0x7dc5) [0x7f8c1c209dc5]
 11: (clone()+0x6d) [0x7f8c1aceaced]
 	   

Верхняя часть утверждения отображает ту функцию, из которой данное утверждение было эскалировано, а также сам номер строки и файл, где было обнаружено данное утверждение. В данном примере наша функция hit_set_trim предположительно вызвала данное утверждение. Мы можем заглянуть в файл ReplicatePG.cc вокруг строки 10514 чтобы попытаться понять что могло произойти. Отметим версию выпуска Ceph (0.94.7), так как номер строки в GitHub будет соответствовать искомому только если вы просматривате ту же самую версию.

Из просмотра кода становится очевидно, что данное возвращаемое значение из вызова функции get_object_context напрямую передаётся в другую функцию assert. Если это значение являются нулём, это указывает на то, что данный объект, содержащий подлежащий подрезке hitset, не может быть обнаружен, в этом сучае данный OSD выставляет утверждение. Основываясь на данной информации, имеется вероятность, что можно провести расследование почему данный объект утрачен и восстановить его. Или же данная команда assert может быть скрыта комментарием с целью посмотреть позволит ли это данному OSD продолжить работу. В данном примере разрешение такому OSD продолжить работу, скорее всего, не вызовет некую проблему, однако в другом случае некое утверждение может быть единственной вещью, останавливающей от возникновения более серьёзного разрушения. Если вы не понимаете на 100% почему нечто вызывает некое утверждение, а также воздействие любого потенциального изменения, которое вы можете сделать, обратитесь за помощью прежде чем продолжить.

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