Nos mains ne sont pas faites pour s'ennuyer : restauration du cluster Rook dans K8s

Nous avons déjà parlé, comment/pourquoi nous aimons Rook : il simplifie notablement le travail avec les stockages dans les clusters Kubernetes. Cependant, cette simplicité entraîne également certaines complexities. Nous espérons que ce nouveau matériel aidera à mieux comprendre ces complexités avant qu'elles ne se manifestent.

Et pour rendre la lecture plus intéressante, commençons par les conséquences d'un problème hypothétique dans le cluster.

«Tout est perdu!»

Imaginez que vous ayez un jour configuré et lancé Rook dans votre cluster K8s, il vous a satisfait par son fonctionnement, mais à un moment «merveilleux», il se passe ce qui suit :

• De nouveaux pods ne peuvent pas monter des images RBD à partir de Ceph.
• Des commandes telles que lsblk et df ne fonctionnent pas sur les nœuds Kubernetes. Cela signifie automatiquement : «quelque chose ne va pas» avec les images RBD montées sur les nœuds. Elles ne peuvent pas être lues, ce qui indique l'indisponibilité des moniteurs...
• Oui, il n'y a pas de moniteurs opérationnels dans le cluster. De plus - il n'y a même aucun pod OSD, ni de pod MGR.

Lorsque le pod a été lancé : parmi les changements significatifs dans la version Rook 1.0.0 liés à Ceph, on peut noter la prise en charge de Ceph Nautilus et la possibilité d'utiliser NFS pour les buckets CephFS ou RGW. Parmi les autres, on observe la « maturation » de la prise en charge d'EdgeFS au niveau bêta.? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Pour commencer, nous allons prendre un chemin plus long et intéressant, en menant une enquête approfondie sur les «entrailles» de Rook et une récupération étape par étape de ses composants. Bien sûr, il y a aussi un chemin plus court et correct : utiliser des sauvegardes. Comme on le sait, les administrateurs se divisent en deux types : ceux qui ne font pas de sauvegardes, et ceux qui en font déjà... Mais nous en parlerons après l'enquête.

Un peu de pratique, ou le long chemin

Regardons autour de nous et restaurons les moniteurs

Alors, examinons la liste des ConfigMaps : il y a ceux nécessaires pour la sauvegarde rook-ceph-config et rook-config-override. Ils apparaissent lors du déploiement réussi du cluster.

NB: Dans les nouvelles versions, après l'acceptation de ce PR, les ConfigMaps ont cessé d'être un indicateur de réussite du déploiement du cluster.

Pour effectuer les actions suivantes, nous avons besoin d'un redémarrage complet de tous les serveurs où des images RBD montées sont présentes (ls /dev/rbd*). Cela doit être fait via sysrq (ou à pied vers le centre de données). Cette exigence est due à la nécessité de détacher les RBD montés, pour quoi un redémarrage standard ne conviendra pas (il sera sans succès d'essayer de les démonter normalement).

Le théâtre commence par le portant, et un cluster Ceph commence par les moniteurs. Jetons un coup d'œil à ceux-ci.

Rook monte dans le pod du moniteur de telles entités :

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (un volume peuplé par un ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (un volume peuplé par un Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (volume de répertoire hôte brut)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (volume de répertoire hôte brut)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

Regardons ce qu'il y a dans le secret rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Déchiffrons et nous obtiendrons un keyring normal avec des droits pour l'admin et les moniteurs :

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Retenons cela. Et maintenant, regardons le keyring dans le secret rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Qu'est-ce qu'il contient ?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Le même. Regardons encore... Voici, par exemple, un secret rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

En fin de compte, nous trouvons encore quelques secrets dans le ConfigMap rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

Et voici la liste originale des keyrings, d'où proviennent tous les secrets décrits ci-dessus.

Comme nous le savons (voir dataDirHostPath dans documentation), Rook stocke ces données à deux endroits. Alors allons voir les nœuds pour examiner les keyrings situés dans les répertoires montés dans les pods avec les moniteurs et OSD. Pour cela, cherchons sur les nœuds /var/lib/rook/mon-a/data/keyring et voyons :

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

Soudainement ce secret s'est avéré être différent — pas comme dans les ConfigMaps.

Et qu'en est-il du keyring de l'administrateur ? Nous l'avons aussi :

# 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 *"

Voici le problème. Un certain échec s'est produit : le cluster a été recréé… mais en réalité, ce n'est pas le cas.

Il devient clair que les secrets contiennent des keyrings nouvellement générés, et ils ne sont de notre ancien cluster. Donc :

• nous prenons le keyring du moniteur à partir du fichier /var/lib/rook/mon-a/data/keyring (ou à partir d'une sauvegarde) ;
• nous modifions le keyring dans le secret rook-ceph-mons-keyring;
• nous écrivons le keyring de l'administrateur et du moniteur dans le ConfigMap rook-ceph-mon;
• nous supprimons les contrôleurs des pods avec les moniteurs.

Le miracle ne tardera pas : les moniteurs apparaîtront et démarreront. Hourra, le commencement est donné !

Rétablissons OSD

Entrons dans le pod rook-operator: appel ceph mon dump montre que tous les moniteurs sont en place, et ceph -s — sur le fait qu'ils sont en quorum. Cependant, si nous regardons l'arbre OSD (ceph osd tree), nous verrons quelque chose de étrange : les OSD ont commencé à apparaître, mais ils sont vides. Il semble que nous devions également les restaurer d'une certaine manière. Mais comment ?

Pendant ce temps, les ConfigMaps tant nécessaires sont apparues rook-ceph-config et rook-config-override, ainsi que de nombreux autres ConfigMaps avec des noms du type rook-ceph-osd-$nodename-config. Jetons un œil à leur contenu :

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

Ce n'est pas ça, tout est mélangé !

Redémarrons le pod de l'opérateur, supprimons les déploiements générés des pods OSD et corrigons ces ConfigMaps. Mais d'où obtenir la bonne carte OSD par nœud ?

• Essayons à nouveau d'explorer les répertoires /mnt/osd[1-2] sur les nœuds — en espérant que nous pourrons nous y accrocher.
• Dans le répertoire /mnt/osd1 il existe 2 sous-répertoires : osd0 et osd16. Le dernier, c'est bien l'ID qui est mentionné dans le ConfigMap (16) ?
• Vérifions les tailles et voyons que osd0 c'est beaucoup plus osd16.

Nous concluons que osd0 — c'est le bon OSD qui était indiqué comme /mnt/osd1 dans le ConfigMap (puisque nous utilisons directory based osd.)

Pas à pas, nous vérifions tous les nœuds et corrigeons les ConfigMaps. Après toutes les instructions, nous pouvons lancer le pod de l'opérateur Rook et lire ses journaux. Et tout y est :

• je suis l'opérateur de cluster;
• j'ai trouvé des disques sur les nœuds;
• j'ai trouvé des moniteurs;
• les moniteurs se sont liés, c'est-à-dire qu'ils ont formé un quorum;
• je lance les déploiements OSD…

Nous allons à nouveau dans le pod de l'opérateur Rook et vérifions la santé du cluster… oui, nous avons un peu mal jugé les noms des OSD sur certains nœuds ! Pas de problème : nous avons à nouveau corrigé les ConfigMaps, supprimé les répertoires superflus des nouveaux OSD et atteint l'état tant attendu HEALTH_OK!

Vérifions les images dans le pool :

# 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
…

Tout est en ordre — le cluster est sauvé !

Je suis paresseux pour faire des sauvegardes, ou un chemin rapide

Si les sauvegardes pour Rook ont été effectuées, la procédure de restauration devient beaucoup plus simple et se résume à ce qui suit :

1. Nous réduisons à zéro le déploiement de l'opérateur Rook ;
2. Nous supprimons tous les déploiements sauf celui de l'opérateur Rook ;
3. Nous restaurons tous les secrets et ConfigMaps à partir de la sauvegarde ;
4. Nous restaurons le contenu des répertoires /var/lib/rook/mon-* sur les nœuds ;
5. Nous restaurons (si nous avons perdu) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Nous redimensionnons à nouveau le déploiement de l'opérateur Rook à 1.

Conseils utiles

Faites des sauvegardes !

Et pour éviter des situations où une restauration serait nécessaire :

1. Avant les travaux d'envergure sur le cluster, impliquant le redémarrage des serveurs, redimensionnez à zéro l'opérateur Rook pour qu'il ne fasse pas de tâches inutiles.
2. Ajoutez à l'avance nodeAffinity.
3. Faites attention à la préparation configuration des délais d'attente ROOK_MON_HEALTHCHECK_INTERVAL et ROOK_MON_OUT_TIMEOUT.

En conclusion

Il est indéniable que Rook, en tant que couche supplémentaire dans l'architecture des systèmes de stockage Kubernetes, simplifie certains aspects tout en introduisant de nouvelles complexités et des problèmes potentiels d'infrastructure. La décision revient à peser soigneusement ces risques d'un côté et les avantages que cette solution peut apporter dans votre cas particulier de l'autre.

D'ailleurs, récemment, la documentation de Rook a été mise à jour avec une section intitulée «Adopter un cluster Rook Ceph existant dans un nouveau cluster Kubernetes». Elle décrit plus en détail ce qu'il faut faire pour migrer des données existantes vers le nouveau cluster Kubernetes ou pour restaurer un cluster qui a été endommagé pour une raison quelconque.

P.S.

Lisez aussi dans notre blog :

• «Rook ou ne pas Rook — telle est la question»;
• «Rook - un stockage de données « auto-géré » pour Kubernetes»;
• «Longhorn, un stockage distribué pour K8s de Rancher, a été transféré à la CNCF».
• «Créons un stockage permanent avec provisioning dans Kubernetes basé sur Ceph».

Source : habr.com