Нашите ръце не са за скука: възстановяване на клъстера Rook в K8s

Ние говорихме, как/почему ни харесва Rook: значително улеснява работата с хранилищата в Kubernetes клъстери. Но с тази простота идват и определени предизвикателства. Надяваме се, че новият материал ще помогне да разберете подобни трудности преди те да се проявят.

А за да е по-интересно да четете, ще започнем с последиците от хипотетичен проблем в клъстера.

„Всичко е загубено!”

Представете си, че веднъж сте настроили и стартирали Rook в своя K8s клъстер, той работи безпроблемно, но в някой „прекрасен“ момент следващото се случва:

• Нови pod’ове не могат да монтират RBD изображения от Ceph.
• Команди като lsblk и df не работят на Kubernetes възлите. Това автоматично означава: „нещо не е наред“ с монтираните RBD изображения. Не може да се прочете, което показва на недостъпност на мониторите...
• Да, в клъстера няма работещи монитори. Освен това - няма дори pod’ове с OSD, нито pod на MGR.

Когато бе стартиран pod rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Първата стъпка е да поемем по интересния по-дълъг път, извършвайки внимателно разследване на „вътрешността“ на Rook и стъпка по стъпка възстановяване на неговите компоненти. Разбира се, има и по-кратък и верен път: използването на резервни копия. Както знаем, администраторите са два типа: тези, които не правят резервни копия, и тези, които вече ги правят... Но за това - след разследването.

Малко практика, или Дългият път

Нека да се огледаме и възстановим мониторите

И така, нека погледнем списъка на ConfigMap-овете: там има нужните за резервиране rook-ceph-config и rook-config-override. Те се появяват при успешен деплой на клъстера.

NB: В новите версии, след приемането на този PR, ConfigMap-овете вече не са показател за успешността на деплоя на клъстера.

За извършване на по-нататъшни действия е необходимо рязко рестартиране на всички сървъри, на които са монтирани RBD изображения (ls /dev/rbd*). То трябва да се извърши чрез sysrq (или „пешком“ в центъра за данни). Това изискване произтича от необходимостта да се отсъединят монтираните RBD, за което обикновеното рестартиране няма да сработи (ще се опитат неуспешно да се отмонтират нормално).

Театърът започва от закачалката, а Ceph клъстера - от мониторите. Нека да ги разгледаме.

Rook монтира в пода на монитора такива обекти:

Обеми:
 rook-ceph-config:
   Тип:      ConfigMap (том, заполняемый ConfigMap)
   Имя:      rook-ceph-config
 rook-ceph-mons-keyring:
   Тип:        Secret (том, заполняемый Secret)
   ИмяСекрета:  rook-ceph-mons-keyring
 rook-ceph-log:
   Тип:          HostPath (обычный каталог хоста)
   Путь:          \/var\/lib\/rook\/kube-rook\/log
 ceph-daemon-data:
   Тип:          HostPath (обычный каталог хоста)
   Путь:          \/var\/lib\/rook\/mon-a\/data
Монтажи:
  \/etc\/ceph из rook-ceph-config (ro)
  \/etc\/ceph\/keyring-store\/ из rook-ceph-mons-keyring (ro)
  \/var\/lib\/ceph\/mon\/ceph-a из ceph-daemon-data (rw)
  \/var\/log\/ceph из rook-ceph-log (rw)

Да видим, что в секрете. rook-ceph-mons-keyring:

тип: Secret\nданные:\n keyring: LongBase64EncodedString=

Декодируем, и получаем обычный keyring с правами для администратора и мониторов:

[mon.]
       ключ = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       права mon = "разрешить *"
[client.admin]
       ключ = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       права mds = "разрешить *"
       права mon = "разрешить *"
       права osd = "разрешить *"
       права mgr = "разрешить *"

Запомним. А теперь взглянем на keyring в секрете. rook-ceph-admin-keyring:

тип: Secret\nданные:\n keyring: anotherBase64EncodedString=

Что в нем?

[client.admin]
       ключ = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       права mds = "разрешить *"
       права mon = "разрешить *"
       права osd = "разрешить *"
       права mgr = "разрешить *"

Тот же. Давайте посмотрим ещё… Вот, например, секрет. rook-ceph-mgr-a-keyring:

[mgr.a]
       ключ = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       права mon = "разрешить *"
       права mds = "разрешить *"
       права osd = "разрешить *"

В итоге мы находим еще несколько секретов в ConfigMap. rook-ceph-mon:

тип: Secret\nданные:\n admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==\n cluster-name: a3ViZS1yb29r\n fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==\n mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

И это изначальный список keyring’ов, откуда берутся все вышеописанные секреты.

Как известно (см. dataDirHostPath в документацията), Rook хранит такие данные в двух местах. Поэтому давайте проверим узлы, чтобы взглянуть на keyring’и, лежащие в каталогах, что примонтированы в поды с мониторами и OSD. Для этого найдём на узлах /var/lib/rook/mon-a/data/keyring и увидим:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

Внезапно тут секрет оказался другим — не как в ConfigMap.

А что насчет административного keyring? Он тоже у нас есть:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Вот в чем проблема. Произошел сбой: кластер был пересоздан… но в действительности нет.

Становится ясно, что в секретах хранятся вновь сгенерированные keyring’и, и они не от нашего старого кластера. Поэтому:

• берем keyring от монитора из файла /var/lib/rook/mon-a/data/keyring (либо из резервной копии);
• изменяем keyring в секрете rook-ceph-mons-keyring;
• указываем keyring от администратора и монитора в ConfigMap rook-ceph-mon;
• удаляем контроллеры подов с мониторами.

Чудо не заставит себя долго ждать: мониторы появятся и запустятся. Ура, начало положено!

Восстановим OSD

Заходим в под rook-operator: вызов ceph mon dump показывает, что все мониторы на месте, а ceph -s — на това, че те са в квора. Въпреки това, ако погледнем на дървото OSD (ceph osd tree), ще видим нещо странно: OSD'чета започнаха да се появяват, но те са празни. Значи, трябва да ги възстановим по някакъв начин. Но как?

В същото време, в ConfigMap'ите се появиха толкова нужните ни rook-ceph-config и rook-config-override, както и много други ConfigMap'и с имена от вида rook-ceph-osd-$nodename-config. Нека да погледнем в тях:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Всичко не е така, всичко е объркано!

Намаляваме до нула pod оператор, изтриваме генерираните Deployment'и на pod'овете с OSD и поправяме тези ConfigMap'и. Но откъде да вземем правилната карта OSD по възли?

• Опитваме отново да разгледаме директориите /mnt/osd[1-2] на възлите — с надежда, че можем да се закачим за нещо там.
• В директорията /mnt/osd1 има 2 подкаталога: osd0 и osd16. Последният — това е точно този ID, който е указан в ConfigMap (16)?
• Проверяваме по размерите и виждаме, че osd0 е много по-голям osd16.

Пристигаме до заключението, че osd0 — това е нужния OSD, който е указан като /mnt/osd1 в ConfigMap (все пак използваме directory based osd.)

Стъпка по стъпка проверяваме всички възли и поправяме ConfigMap'ите. След всички указания можем да стартираме pod Rook оператора и да прочетем логовете му. А в тях всичко е чудесно:

• аз съм оператор на клъстера;
• аз намерих дисковете на възлите;
• аз открих мониторите;
• мониторите се свързаха, т.е. образуваха квора;
• стартирам деплойментите на OSD…

Отново влизаме в pod оператора Rook и проверяваме жизнеността на клъстера… да, малко се объркахме с изводите за имената на OSD на някои възли! Няма проблем: поправихме отново ConfigMap'ите, изтрихме излишните каталози от новите OSD и достигнахме до дългоочакваното състояние HEALTH_OK!

Проверяваме образите в пула:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Всичко е на мястото си — клъстерът е спасен!

Аз съм мързелив и правя бекъпи, или Бързият път

Ако бекъпите за Rook са направени, процедурата по възстановяване става значително по-лесна и се свежда до следните стъпки:

1. Масштабиране до нула на деплоймента на Rook оператора;
2. Изтриваме всички деплойменти, освен Rook оператора;
3. Възстановяваме от бекъпа всички secret'и и ConfigMap'и;
4. Възстановяваме съдържанието на директорите /var/lib/rook/mon-* на възлите;
5. Възстановяваме (ако случайно сме загубили) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Обратно увеличаваме деплоймента на Rook оператора до 1.

Полезни съвети

Правете бекъпи!

А за да избегнете ситуации, когато ще се наложи възстановяване от тях:

1. Преди мащабни операции с клъстера, свързани с ребут на сървъри, намалете до нула Rook оператора, за да не прави излишно.
2. На мониторите предварително добавяйте nodeAffinity.
3. Обърнете внимание на предварителната настройка на таймаутите ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

Вместо заключение

Не може да се спори, че Rook, като допълнителен „слой“ (в общата схема на организация на хранилищата в Kubernetes), както опростява много, така и добавя нови усложнения и потенциални проблеми в инфраструктурата. Изборът остава на вас: да направите внимателен, обоснован избор между тези рискове от една страна и ползата, която решението носи в конкретния случай, от друга.

Впрочем, наскоро в документацията на Rook беше добавен раздел „Adopt an existing Rook Ceph cluster into a new Kubernetes cluster“. В него е подробно описано какво трябва да се направи, за да се прехвърлят съществуващите данни в нов Kubernetes клъстър или да се възстанови работата на клъстера, който е бил разрушен по някаква причина.

P.S.

Прочетете също в нашия блог:

• «Rook или не Rook — това е въпросът»;
• «Rook е „самообслужваща се“ система за съхранение на данни за Kubernetes»;
• «Longhorn, разпределено хранилище за K8s от Rancher, е предадено на CNCF».
• «Създаваме постоянно хранилище с provisioning в Kubernetes на база Ceph».

Източник: habr.com