En utilisant Ceph comme stockage en réseau dans différents projets de chargement, nous pouvons rencontrer diverses tâches qui, à première vue, ne semblent ni simples ni triviales. Par exemple :
- migration des données d'un ancien Ceph vers un nouveau, en utilisant partiellement les anciens serveurs dans le nouveau cluster ;
- résolution du problème de distribution de l'espace disque dans Ceph.
En traitant de telles tâches, nous faisons face à la nécessité d'extraire correctement un OSD sans perte de données, ce qui est particulièrement pertinent pour de grands volumes de données. C'est ce dont nous allons parler dans cet article.
Les méthodes décrites ci-dessous sont pertinentes pour toutes les versions de Ceph. De plus, il sera tenu compte du fait que Ceph peut stocker un grand volume de données : pour éviter les pertes de données et d'autres problèmes, certaines actions seront « fragmentées » en plusieurs autres.
Préface sur l'OSD
Puisque deux des trois recettes abordées concernent l'OSD (), avant de plonger dans la partie pratique — un bref aperçu de ce que c'est dans Ceph et pourquoi il est si important.
Tout d'abord, il convient de dire que tout le cluster Ceph est composé de nombreux OSD. Plus il y en a, plus le volume de données libre dans Ceph est important. Il est donc facile de comprendre la fonction principale de l'OSD: il sauvegarde les données des objets Ceph sur les systèmes de fichiers de tous les nœuds du cluster et fournit un accès réseau à ceux-ci (pour la lecture, l'écriture et d'autres demandes).
À ce même niveau, les paramètres de réplication sont établis par la copie des objets entre différents OSD. Et c'est ici que l'on peut être confronté à divers problèmes, dont la résolution sera abordée plus loin.
Cas n°1. Extraction sécurisée d'un OSD du cluster Ceph sans perte de données
La nécessité d'extraire un OSD peut être provoquée par le retrait d'un serveur du cluster — par exemple, pour le remplacer par un autre serveur — ce qui est arrivé dans notre cas et a servi de raison pour écrire cet article. Ainsi, l'objectif final des manipulations est d'extraire tous les OSD et les mon de ce serveur pour qu'il puisse être arrêté.
Pour plus de commodité et pour éviter une situation où nous nous tromperions dans la désignation du bon OSD en cours d'exécution des commandes, nous allons définir une variable distincte, dont la valeur sera le numéro de l'OSD à supprimer. Nous l'appellerons ${ID} — ici et par la suite, cette variable remplace le numéro de l'OSD avec lequel nous travaillons.
Examinons l'état avant le début des travaux :
root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.46857 root default
-3 0.15619 host hv-1
-5 0.15619 host hv-2
1 ssd 0.15619 osd.1 up 1.00000 1.00000
-7 0.15619 host hv-3
2 ssd 0.15619 osd.2 up 1.00000 1.00000 Pour initier la suppression de l'OSD, il sera nécessaire d'effectuer un rééquilibrage de celui-ci jusqu'à zéro. Ainsi, nous réduisons la quantité de données dans l'OSD en les équilibrant vers d'autres OSD. Pour cela, les commandes suivantes sont exécutées :
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78… et ainsi de suite jusqu'à zéro.
Un équilibrage progressif est nécessaire, afin de ne pas perdre de données. Cela est particulièrement pertinent si l'OSD contient un grand volume de données. Pour s'assurer précisément qu'après l'exécution des commandes rééquilibrage tout s'est bien passé, on peut exécuter ceph -s ou bien dans une fenêtre de terminal séparée lancer ceph -w pour observer les changements en temps réel.
Lorsque l'OSD est « vidé », il est possible de procéder à l'opération standard de sa suppression. Pour cela, transférons l'OSD nécessaire dans l'état down:
ceph osd down osd.${ID}« Retirer » l'OSD du cluster :
ceph osd out osd.${ID}Arrêtons le service OSD et démontons sa partition dans le FS :
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Supprimons l'OSD de la :
ceph osd crush remove osd.${ID}Supprimons l'utilisateur de l'OSD :
ceph auth del osd.${ID}Et enfin, supprimons l'OSD lui-même :
ceph osd rm osd.${ID}Remarque: si vous utilisez la version Ceph Luminous ou supérieure, les actions décrites ci-dessus pour supprimer l'OSD peuvent être réduites à deux commandes :
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Si après avoir exécuté les actions décrites ci-dessus, la commande ceph osd tree, vous devriez voir que sur le serveur où les travaux ont été réalisés, il n'y a plus d'OSD pour lesquels les opérations ci-dessus ont été effectuées :
root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.46857 root default
-3 0.15619 host hv-1
-5 0.15619 host hv-2
-7 0.15619 host hv-3
2 ssd 0.15619 osd.2 up 1.00000 1.00000 Au passage, nous noterons que l'état du cluster Ceph passera à HEALTH_WARN, et nous observerons également une diminution du nombre d'OSD et du volume d'espace disque disponible.
Les actions qui seront nécessaires si vous souhaitez totalement arrêter le serveur et, par conséquent, le supprimer de Ceph seront décrites ci-dessous. Dans ce cas, il est important de se rappeler que avant de déconnecter le serveur, il est nécessaire d'extraire tous les OSD sur ce serveur.
S'il ne reste plus d'OSD sur ce serveur, alors après leur suppression, il faut exclure le serveur de la carte OSD hv-2, en exécutant la commande suivante :
ceph osd crush rm hv-2 Nous supprimons mon du serveur hv-2, en lançant la commande ci-dessous sur un autre serveur (c'est-à-dire dans ce cas — sur hv-1):
ceph-deploy mon destroy hv-2Après cela, vous pouvez arrêter le serveur et passer aux étapes suivantes (son redéploiement, etc.).
Cas n°2. Répartition de l'espace disque dans un cluster Ceph déjà créé
Je commencerai la deuxième histoire par une préface sur les PG (). Le rôle principal des PG dans Ceph est d'agréger d'abord les objets Ceph puis de les répliquer dans les OSD. La formule pour calculer le nombre nécessaire de PG se trouve dans de la documentation Ceph. Cette question y est également abordée avec des exemples concrets.
Ainsi : l'un des problèmes courants lors de l'utilisation de Ceph est le déséquilibre entre le nombre d'OSD et de PG dans les pools Ceph.
Tout d'abord, cela peut entraîner une situation où un nombre trop élevé de PG est spécifié dans un petit pool, ce qui est en réalité une utilisation irrationnelle de l'espace disque dans le cluster. Deuxièmement, cela pose un problème plus sérieux dans la pratique : le débordement de données dans l'un des OSD. Cela entraîne le passage du cluster d'abord dans un état HEALTH_WARN, puis dans HEALTH_ERR. La cause en est que Ceph, lors du calcul de l'espace de données disponible (que vous pouvez connaître grâce à MAX AVAIL dans la sortie de la commande ceph df pour chaque pool séparément) se base sur le volume de données disponibles dans les OSD. S'il y a un manque d'espace dans au moins un OSD, il ne sera pas possible d'écrire plus de données tant qu'elles ne seront pas correctement réparties entre tous les OSD.
Il convient de préciser que ces problèmes sont principalement résolus au stade de la configuration du cluster Ceph. L'un des outils que vous pouvez utiliser est . Cet outil permet de calculer visuellement le nombre nécessaire de PG. Toutefois, il peut également être utilisé dans une situation où le cluster Ceph déjà n'est pas correctement configuré. Il est important de noter que dans le cadre des travaux de correction, vous aurez probablement besoin de réduire le nombre de PG, et cette option n'est pas disponible dans les anciennes versions de Ceph (elle n'est apparue qu'à partir de la version ).
Donc, imaginons le scénario suivant : le statut du cluster est HEALTH_WARN en raison du fait que l'espace dans un des OSD s'épuise. Cela sera signalé par l'erreur HEALTH_WARN: 1 near full osd. Ci-dessous se trouve l'algorithme pour sortir d'une telle situation.
Tout d'abord, il est nécessaire de répartir les données existantes entre les autres OSD. Nous avons déjà effectué ce type d'opération dans le premier cas, lorsque nous avons « asséché » le nœud, avec juste la différence que maintenant, il faudra légèrement diminuer rééquilibrage. Par exemple, à 0.95 :
ceph osd reweight osd.${ID} 0.95Cela libère de l'espace disque dans l'OSD et corrige l'erreur dans ceph health. Cependant, comme déjà mentionné, ce problème survient principalement en raison d'une configuration incorrecte de Ceph au début : il est très important de procéder à une reconfiguration pour éviter qu'il ne se reproduise à l'avenir.
Dans notre cas spécifique, tout dépendait de :
- une valeur trop élevée
replication_countdans l'un des pools, - trop de PG dans un pool et trop peu dans l'autre.
Utilisons le calculateur déjà mentionné. Il montre clairement ce qu'il faut entrer et, en principe, ce n'est pas compliqué. En entrant les paramètres nécessaires, nous obtenons les recommandations suivantes :
Remarque: si vous configurez un cluster Ceph à partir de zéro, une autre fonctionnalité utile du calculateur sera la génération de commandes qui créeront des pools à partir de zéro avec les paramètres indiqués dans le tableau.
Le dernier colonne aide à s'orienter — Suggested PG Count. Dans notre cas, le deuxième est également utile, où le paramètre de réplication est indiqué, car nous avons décidé de modifier également le multiplicateur de réplication.
Ainsi, il faudra d'abord modifier les paramètres de réplication — cela doit être fait en premier, car en diminuant le multiplicateur, nous libérerons de l'espace disque. Pendant l'exécution de la commande, on peut remarquer que la valeur de l'espace disque disponible va augmenter :
ceph osd pool $pool_name set $replication_size Et après son achèvement — nous modifions les valeurs des paramètres pg_num et pgp_num comme suit :
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberImportant: nous devons successivement modifier le nombre de PG dans chaque pool et ne pas modifier les valeurs dans d'autres pools tant que les avertissements n'ont pas disparu « Degraded data redundancy » et « n-number of pgs degraded ».
Vous pouvez également vérifier que tout s'est bien passé en consultant les résultats des commandes ceph health detail et ceph -s.
Cas n°3. Migration d'une machine virtuelle de LVM vers Ceph RBD
Dans les projets utilisant des machines virtuelles installées sur des serveurs bare-metal loués, la question d'un stockage résilient se pose souvent. Il est également souhaitable que cet espace de stockage soit suffisamment grand... Une autre situation courante : il y a une machine virtuelle avec un stockage local sur le serveur et il est nécessaire d'augmenter le disque, mais il n'y a plus d'espace disque disponible sur le serveur.
Le problème peut être résolu de différentes manières — par exemple, en migrant vers un autre serveur (s'il en existe un) ou en ajoutant de nouveaux disques au serveur. Mais ce n'est pas toujours possible, donc la migration de LVM vers Ceph peut constituer une excellente solution à ce problème. En choisissant cette option, nous simplifions également le processus de migration entre les serveurs, car il ne sera pas nécessaire de déplacer le stockage local d'un hyperviseur à un autre. La seule difficulté est qu'il faudra arrêter la VM pendant les travaux.
Comme recette suivante, nous prenons , dont les instructions ont été mises à l'épreuve. À propos, il y est également décrit un moyen de migration sans frais, mais dans notre cas, cela n'était tout simplement pas nécessaire, donc nous ne l'avons pas vérifié. Cependant, si cela est critique pour votre projet — nous serions heureux d'apprendre les résultats dans les commentaires.
Passons à la partie pratique. Dans cet exemple, nous utilisons virsh et, par conséquent, libvirt. Pour commencer, assurez-vous que le pool Ceph dans lequel les données seront migrées est connecté à libvirt :
virsh pool-dumpxml $ceph_poolLa description du pool doit contenir les données de connexion à Ceph avec les informations d'autorisation.
L'étape suivante consiste à convertir l'image LVM en Ceph RBD. Le temps d'exécution dépend principalement de la taille de l'image :
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameAprès la conversion, une image LVM restera, qui sera utile si la migration de la VM vers RBD échoue et qu'il faut annuler les modifications. De plus — pour permettre un retour rapide en arrière — nous ferons une sauvegarde du fichier de configuration de la machine virtuelle :
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml … et nous éditerons l'original (vm_name.xml). Trouvons le bloc avec la description du disque (il commence par la ligne <disk type='file' device='disk'> et se termine par </disk>) et le formater comme suit :
Examinons certains détails :
- Dans le protocole
sourcel'adresse du stockage Ceph RBD est spécifiée (il s'agit de l'adresse avec le nom du pool Ceph et de l'image RBD, qui a été défini à l'étape précédente). - Dans le bloc
secretle type est spécifiéceph, ainsi que l'UUID du secret pour s'y connecter. Son UUID peut être obtenu en utilisant la commandevirsh secret-list. - Dans le bloc
hostles adresses des moniteurs Ceph sont indiquées.
Après avoir modifié le fichier de configuration et terminé la conversion de LVM en RBD, vous pouvez appliquer le fichier de configuration modifié et démarrer la machine virtuelle :
virsh define $vm_name.xml
virsh start $vm_name Il est temps de vérifier si la machine virtuelle a démarré correctement : cela peut être fait, par exemple, en s'y connectant par SSH ou via virsh.
Si la machine virtuelle fonctionne correctement et que vous n'avez détecté aucun autre problème, vous pouvez supprimer l'image LVM qui n'est plus utilisée :
lvremove main/$vm_image_nameConclusion
Nous avons rencontré toutes les situations décrites en pratique — nous espérons que les instructions aideront d'autres administrateurs à résoudre des problèmes similaires. Si vous avez des commentaires ou d'autres histoires similaires de votre expérience avec Ceph, nous serions ravis de les voir dans les commentaires !
P.S.
Lisez aussi dans notre blog :
- «»;
- «»;
- «»;
- «».
Source : habr.com
