Nous avons
déjà expliqué comment / pourquoi nous aimons Rook: dans une large mesure, il simplifie l'utilisation du stockage dans les clusters Kubernetes. Cependant, avec cette simplicité, certaines difficultés surviennent. Nous espérons que le nouveau matériel aidera à mieux comprendre ces difficultés avant même qu'elles ne se manifestent.
Et pour le lire c'était plus intéressant, on commence par les
conséquences d'un problème hypothétique dans le cluster.
"Tout est parti!"
Imaginez que vous ayez une fois configuré et lancé Rook dans votre cluster K8s, il était satisfait de son travail, mais à un moment «merveilleux», les événements suivants se produisent:
- Les nouveaux pods ne peuvent pas monter de RBD Ceph.
- Les commandes comme
lsblk et df ne fonctionnent pas sur les hôtes Kubernetes. Cela signifie automatiquement «quelque chose ne va pas» avec les images RBD montées sur le nœud. Je ne peux pas les lire, ce qui indique l'inaccessibilité des moniteurs ... - Oui, il n'y a aucun moniteur opérationnel dans le cluster. De plus - il n'y a même pas de pods avec OSD, ni de pods de MGR.
Quand a été lancé le pod
rook-ceph-operator ? Il n'y a pas si longtemps qu'il était déployé. Pourquoi? L'opérateur tour a décidé de créer un nouveau cluster ... Comment pouvons-nous maintenant restaurer le cluster et les données qu'il contient?
Pour commencer, allons
plus loin, après avoir mené une enquête approfondie sur les «internes» de Rook et une restauration étape par étape de ses composants. Bien sûr, il existe une méthode correcte
plus courte : utiliser les sauvegardes. Comme vous le savez, les administrateurs sont divisés en deux types: ceux qui ne font pas de sauvegardes et ceux qui les font déjà ... Mais plus à ce sujet après l'enquête.
Un peu de pratique ou un long chemin
Jetez un œil et restaurez les moniteurs
Alors, regardons la liste des ConfigMaps: il y a
rook-ceph-config et
rook-config-override nécessaires pour la sauvegarde. Ils apparaissent lors du déploiement réussi du cluster.
NB : Dans les nouvelles versions, après l'adoption de ce PR , ConfigMaps a cessé d'être un indicateur de la réussite d'un déploiement de cluster.Pour effectuer d'autres actions, nous avons besoin d'un redémarrage matériel de tous les serveurs qui ont monté des images RBD (
ls /dev/rbd* ). Cela doit être fait via sysrq (ou "à pied" jusqu'au centre de données). Cette exigence est causée par la tâche de déconnecter les RBD montés, pour laquelle un redémarrage régulier ne fonctionnera pas (il tentera sans succès de les démonter normalement).
Le théâtre commence par un cintre et le cluster Ceph commence par des moniteurs. Regardons-les.
Rook monte les entités suivantes dans le module moniteur:
Volumes: rook-ceph-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: rook-ceph-config rook-ceph-mons-keyring: Type: Secret (a volume populated by a Secret) SecretName: rook-ceph-mons-keyring rook-ceph-log: Type: HostPath (bare host directory volume) Path: /var/lib/rook/kube-rook/log ceph-daemon-data: Type: HostPath (bare host directory volume) 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)
Voyons quel est le secret de
rook-ceph-mons-keyring :
kind: Secret data: keyring: LongBase64EncodedString=
Nous décodons et obtenons le trousseau de clés habituel avec des droits pour l'administrateur 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 *"
N'oubliez pas. Regardez maintenant le trousseau de clés dans le trousseau secret
rook-ceph-admin-keyring :
kind: Secret data: keyring: anotherBase64EncodedString=
Qu'y a-t-il dedans?
[client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Le même. Voyons plus ... Voici, par exemple, le secret de
rook-ceph-mgr-a-keyring :
[mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *"
En fin de compte, nous trouvons quelques secrets de plus dans ConfigMap
rook-ceph-mon :
kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
Et voici la liste initiale avec porte-clés, d'où viennent tous les secrets décrits ci-dessus.
Comme vous le savez (voir
dataDirHostPath dans la
documentation ), Rook stocke ces données à deux endroits. Par conséquent, allons aux nœuds pour examiner le trousseau de clés se trouvant dans les répertoires montés dans des pods avec des moniteurs et OSD. Pour ce faire, recherchez les nœuds
/var/lib/rook/mon-a/data/keyring et voyez:
# cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *"
Soudain, le secret s'est avéré différent - pas comme dans ConfigMap.
Et le trousseau d'admin? Nous l'avons également:
# 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. Il y a eu un échec: le cluster a été recréé ... mais en réalité non.
Il devient clair que le trousseau de clés nouvellement généré est stocké dans des secrets, et ils
ne sont
pas de notre ancien cluster. Par conséquent:
- nous prenons le trousseau de clés du moniteur à partir du fichier
/var/lib/rook/mon-a/data/keyring (ou de la sauvegarde); - changer le trousseau de clés dans le trousseau de clés secret
rook-ceph-mons-keyring ; - enregistrer le trousseau de clés de l'administrateur et du moniteur dans ConfigMap'e
rook-ceph-mon ; - supprimer les contrôleurs de pod avec des moniteurs.
Le miracle ne prendra pas longtemps: des moniteurs apparaîtront et démarreront. Hourra, un début!
Restaurer l'OSD
Nous allons dans l'
rook-operator pod: appeler
ceph mon dump montre que tous les moniteurs sont en place, et
ceph -s qu'ils sont dans un quorum. Cependant, si vous regardez l'arborescence OSD (arborescence
ceph osd tree ), vous verrez quelque chose d'étrange: l'OSD a commencé à apparaître, mais ils sont vides. Il s'avère qu'ils doivent également être en quelque sorte restaurés. Mais comment?
Pendant ce temps,
rook-ceph-config et
rook-config-override , ainsi que de nombreux autres ConfigMap avec des noms comme
rook-ceph-osd-$nodename-config , sont apparus dans ConfigMap si nécessaire. Regardons-les:
kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
Tout va mal, tout est mélangé!
Redimensionnez le module opérateur à zéro, supprimez les modules de déploiement générés de l'OSD et corrigez ces cartes de configuration. Mais où obtenir la
bonne carte OSD par nœuds?
- Essayons de fouiller à nouveau dans les répertoires
/mnt/osd[1-2] sur les nœuds - dans l'espoir que nous pourrons y attraper quelque chose. - Il existe 2 sous-répertoires dans le répertoire
/mnt/osd1 : osd0 et osd16 . Le dernier est juste cet ID qui est spécifié dans ConfigMap (16)? - Vérifions
osd0 taille et voyons que osd0 beaucoup plus grand que osd16 .
Nous concluons que
osd0 est l'OSD requis, qui a été spécifié comme
/mnt/osd1 dans ConfigMap (car nous utilisons
osd basé sur un répertoire .)
Étape par étape, nous vérifions tous les nœuds et modifions ConfigMap. Après toutes les instructions, vous pouvez exécuter le pod de l'opérateur Rook et lire ses journaux. Et tout est merveilleux en eux:
- Je suis un opérateur de cluster;
- J'ai trouvé des disques sur des nœuds;
- J'ai trouvé des moniteurs;
- les moniteurs sont devenus amis, c'est-à-dire formé un quorum;
- exécution de déploiements OSD ...
Revenons au pod de l'opérateur Rook et vérifions la vivacité du cluster ... oui, nous avons fait une petite erreur avec les conclusions sur les noms OSD sur certains nœuds! Peu importe: ils ont à nouveau corrigé les ConfigMaps, supprimé les répertoires supplémentaires des nouveaux OSD et sont arrivés à l'état tant attendu de
HEALTH_OK !
Vérifiez les images dans la piscine:
Tout est en place - le cluster est enregistré!
Je suis paresseux à faire des sauvegardes ou la voie rapide
Si des sauvegardes ont été effectuées pour Rook, la procédure de récupération devient beaucoup plus simple et se résume à ce qui suit:
- Évoluer vers un déploiement nul de l'opérateur Rook;
- Nous supprimons tous les déploiements à l'exception de l'opérateur Rook;
- Nous restaurons tous les secrets et ConfigMaps à partir de la sauvegarde;
- Restaurez le contenu des
/var/lib/rook/mon-* sur les nœuds; - Restaurer (si soudainement perdu) CRD
CephCluster , CephFilesystem , CephBlockPool , CephNFS , CephObjectStore ; - Redimensionnez le déploiement de l'opérateur Rook à 1.
Conseils utiles
Faites des sauvegardes!
Et pour éviter les situations où vous devez vous remettre d'eux:
- Avant de travailler à grande échelle avec le cluster, consistant en des redémarrages du serveur, mettez à l'échelle l'opérateur Rook à zéro afin qu'il n'en fasse pas trop.
- Sur les moniteurs, ajoutez à l'avance nodeAffinity .
- Faites attention à
ROOK_MON_HEALTHCHECK_INTERVAL les délais d'attente ROOK_MON_HEALTHCHECK_INTERVAL et ROOK_MON_OUT_TIMEOUT .
Au lieu d'une conclusion
Il ne sert à rien de prétendre que Rook, étant une «couche» supplémentaire (dans le schéma général d'organisation du stockage dans Kubernetes), autant simplifie, il ajoute également de nouvelles difficultés et des problèmes potentiels dans l'infrastructure. La chose reste «petite»: faire un choix équilibré et éclairé entre ces risques d'une part et les avantages que la solution apporte dans votre cas particulier, d'autre part.
Par ailleurs, la section «Adopter un cluster Rook Ceph existant dans un nouveau cluster Kubernetes» a récemment
été ajoutée à la documentation Rook. Il décrit plus en détail ce qui doit être fait pour déplacer les données existantes vers un nouveau cluster Kubernetes ou pour restaurer un cluster qui s'est effondré pour une raison ou une autre.
PS
Lisez aussi dans notre blog: