En utilisant Ceph comme stockage réseau dans des projets avec des charges différentes, nous pouvons rencontrer diverses tâches qui, à première vue, ne semblent ni simples ni triviales. Par exemple:
- migration des données de l'ancien Ceph vers le nouveau avec utilisation partielle des serveurs précédents dans le nouveau cluster ;
- solution au problème de l'allocation d'espace disque dans Ceph.
Face à de tels problèmes, nous sommes confrontés à la nécessité de supprimer correctement l'OSD sans perdre de données, ce qui est particulièrement important lorsqu'il s'agit de grandes quantités de données. Ceci sera discuté dans l’article.
Les méthodes décrites ci-dessous sont pertinentes pour n’importe quelle version de Ceph. De plus, le fait que Ceph puisse stocker une grande quantité de données sera pris en compte : pour éviter les pertes de données et autres problèmes, certaines actions seront « divisées » en plusieurs autres.
Préface sur l'OSD
Puisque deux des trois recettes évoquées sont dédiées à l'OSD (), avant de plonger dans la partie pratique - brièvement sur ce que c'est dans Ceph et pourquoi c'est si important.
Tout d'abord, il faut dire que l'ensemble du cluster Ceph est constitué de nombreux OSD. Plus il y en a, plus le volume de données gratuites dans Ceph est important. C'est facile à comprendre d'ici fonction OSD principale: Il stocke les données des objets Ceph sur les systèmes de fichiers de tous les nœuds du cluster et y fournit un accès réseau (pour la lecture, l'écriture et d'autres requêtes).
Au même niveau, les paramètres de réplication sont définis en copiant des objets entre différents OSD. Et ici, vous pouvez rencontrer divers problèmes, dont les solutions seront discutées ci-dessous.
Cas n°1. Supprimez en toute sécurité l'OSD du cluster Ceph sans perdre de données
La nécessité de supprimer l'OSD peut être provoquée par la suppression du serveur du cluster - par exemple, pour le remplacer par un autre serveur - ce qui nous est arrivé et a donné lieu à la rédaction de cet article. Ainsi, le but ultime de la manipulation est d'extraire tous les OSD et mons d'un serveur donné afin de pouvoir l'arrêter.
Pour plus de commodité et pour éviter une situation où, lors de l'exécution de commandes, nous commettons une erreur en indiquant l'OSD requis, nous définirons une variable distincte dont la valeur sera le numéro de l'OSD à supprimer. Appelons-la ${ID} — ici et ci-dessous, une telle variable remplace le numéro de l'OSD avec lequel nous travaillons.
Regardons l'état avant de commencer les 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 lancer la suppression de l'OSD, vous devrez effectuer en douceur reweight dessus à zéro. De cette façon, nous réduisons la quantité de données dans l'OSD en l'équilibrant avec d'autres OSD. Pour ce faire, exécutez les commandes suivantes :
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.
Équilibrage en douceur requisafin de ne pas perdre de données. Cela est particulièrement vrai si l'OSD contient une grande quantité de données. Pour vous assurer qu'après avoir exécuté les commandes reweight tout s'est bien passé, vous pouvez le terminer ceph -s ou dans une fenêtre de terminal séparée, exécutez ceph -w afin d'observer les changements en temps réel.
Lorsque l'OSD est « vidé », vous pouvez procéder à l'opération standard pour le supprimer. Pour ce faire, transférez l'OSD souhaité à l'état down:
ceph osd down osd.${ID}"Sortons" 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}Supprimer l'OSD de :
ceph osd crush remove osd.${ID}Supprimons l'utilisateur OSD :
ceph auth del osd.${ID}Et enfin, supprimons l'OSD lui-même :
ceph osd rm osd.${ID}Noter: Si vous utilisez la version Ceph Luminous ou supérieure, les étapes de suppression de l'OSD ci-dessus peuvent être réduites à deux commandes :
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Si, après avoir effectué les étapes décrites ci-dessus, vous exécutez la commande ceph osd tree, alors il doit être clair que sur le serveur sur lequel le travail a été effectué, 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
En cours de route, notez que l'état du cluster Ceph passera à HEALTH_WARN, et nous verrons également une diminution du nombre d’OSD et de la quantité d’espace disque disponible.
Ce qui suit décrira les étapes qui seront nécessaires si vous souhaitez arrêter complètement le serveur et, par conséquent, le supprimer de Ceph. Dans ce cas, il est important de rappeler que Avant d'arrêter le serveur, vous devez supprimer tous les OSD sur ce serveur.
S'il n'y a plus d'OSD sur ce serveur, après les avoir supprimés, vous devez exclure le serveur de la carte OSD. hv-2en exécutant la commande suivante :
ceph osd crush rm hv-2
Effacer mon du serveur hv-2en exécutant 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 commencer les actions suivantes (le redéployer, etc.).
Cas n°2. Répartition de l'espace disque dans un cluster Ceph déjà créé
Je vais commencer la deuxième histoire par une préface sur PG (). Le rôle principal de PG dans Ceph est principalement d'agréger les objets Ceph et de les répliquer davantage dans OSD. La formule avec laquelle vous pouvez calculer la quantité requise de PG est en Documentation Ceph. Cette question y est également abordée avec des exemples précis.
Donc : l'un des problèmes courants lors de l'utilisation de Ceph est le nombre déséquilibré d'OSD et de PG entre les pools dans Ceph.
Premièrement, à cause de cela, une situation peut survenir lorsque trop de PG sont spécifiés dans un petit pool, ce qui constitue essentiellement une utilisation irrationnelle de l'espace disque dans le cluster. Deuxièmement, en pratique, il existe un problème plus grave : un débordement de données dans l'un des OSD. Cela implique que le cluster passe d'abord à l'état HEALTH_WARNpuis HEALTH_ERR. La raison en est que Ceph, lors du calcul de la quantité de données disponibles (vous pouvez la découvrir en MAX AVAIL dans la sortie de la commande ceph df pour chaque pool séparément) est basé sur la quantité de données disponibles dans l'OSD. S'il n'y a pas assez d'espace dans au moins un OSD, plus aucune donnée ne peut être écrite jusqu'à ce qu'elles soient correctement réparties entre tous les OSD.
Il convient de préciser que ces problèmes sont en grande partie décidés au stade de la configuration du cluster Ceph. L'un des outils que vous pouvez utiliser est . Avec son aide, la quantité requise de PG est clairement calculée. Cependant, vous pouvez également y recourir dans une situation où le cluster Ceph déjà mal configuré. Il convient de préciser ici que dans le cadre du travail de correction, vous devrez probablement réduire le nombre de PG, et cette fonctionnalité n'est pas disponible dans les anciennes versions de Ceph (elle n'apparaissait que dans la version ).
Imaginons donc l'image suivante : le cluster a un statut HEALTH_WARN en raison d'un manque d'espace sur l'OSD. Ceci sera indiqué par une erreur HEALTH_WARN: 1 near full osd. Vous trouverez ci-dessous un algorithme pour sortir de cette situation.
Tout d'abord, vous devez répartir les données disponibles entre les OSD restants. Nous avons déjà effectué une opération similaire dans le premier cas, lorsque nous avons « vidé » le nœud - à la seule différence que nous devrons maintenant réduire légèrement reweight. Par exemple, jusqu'à 0.95 :
ceph osd reweight osd.${ID} 0.95Cela libère de l'espace disque dans l'OSD et corrige l'erreur de santé de Ceph. Cependant, comme déjà mentionné, ce problème se produit principalement en raison d'une configuration incorrecte de Ceph dans les étapes initiales : il est très important de procéder à une reconfiguration afin qu'elle n'apparaisse pas dans le futur.
Dans notre cas particulier, tout se résumait à :
- valeur trop élevée
replication_countdans l'une des piscines, - trop de PG dans un pool et pas assez dans un autre.
Utilisons la calculatrice déjà mentionnée. Il montre clairement ce qui doit être saisi et, en principe, il n'y a rien de compliqué. Après avoir défini les paramètres nécessaires, nous obtenons les recommandations suivantes :
Noter: Si vous configurez un cluster Ceph à partir de zéro, une autre fonction utile de la calculatrice est la génération de commandes qui créeront des pools à partir de zéro avec les paramètres spécifiés dans le tableau.
La dernière colonne vous aide à naviguer - Nombre de PG suggéré. Dans notre cas, le second est également utile, où le paramètre de réplication est indiqué, puisque nous avons décidé de modifier le multiplicateur de réplication.
Donc, vous devez d'abord modifier les paramètres de réplication - cela vaut la peine de le faire en premier, car en réduisant le multiplicateur, nous libérerons de l'espace disque. Au fur et à mesure de l'exécution de la commande, vous remarquerez que l'espace disque disponible augmentera :
ceph osd pool $pool_name set $replication_size
Et après son achèvement, nous modifions les valeurs des paramètres pg_num и pgp_num comme suit:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberIl est important: il faut changer le nombre de PG de manière séquentielle dans chaque pool et ne pas changer les valeursdans les autres pools jusqu'à ce que les avertissements disparaissent "Redondance des données dégradée" и "n-nombre de pages dégradées".
Vous pouvez également vérifier que tout s'est bien passé à l'aide des sorties de commande ceph health detail и ceph -s.
Cas n°3. Migration d'une machine virtuelle de LVM vers Ceph RBD
Dans une situation où un projet utilise des machines virtuelles installées sur des serveurs nus loués, la question du stockage tolérant aux pannes se pose souvent. Il est également très souhaitable qu'il y ait suffisamment d'espace dans ce stockage... Autre situation courante : il y a une machine virtuelle avec stockage local sur le serveur et vous devez étendre le disque, mais il n'y a nulle part où aller, car il n'y a pas espace disque libre restant 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 existe) ou en ajoutant de nouveaux disques au serveur. Mais cela n’est pas toujours possible, donc migrer de LVM vers Ceph peut être une excellente solution à ce problème. En choisissant cette option, nous simplifions également le processus ultérieur de migration entre les serveurs, puisqu'il ne sera pas nécessaire de déplacer le stockage local d'un hyperviseur à un autre. Le seul problème est que vous devrez arrêter la VM pendant que le travail est en cours.
La recette suivante est tirée de , dont les instructions ont été testées en action. D'ailleurs, la méthode de migration sans tracas y est également décrite, cependant, dans notre cas, ce n'était tout simplement pas nécessaire, nous ne l'avons donc pas vérifié. Si cela est critique pour votre projet, nous serons heureux de connaître les résultats dans les commentaires.
Passons à la partie pratique. Dans l'exemple, nous utilisons virsh et, par conséquent, libvirt. Tout d'abord, assurez-vous que le pool Ceph vers lequel les données seront migrées est connecté à libvirt :
virsh pool-dumpxml $ceph_poolLa description du pool doit contenir des données de connexion à Ceph avec des données 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, ce qui sera utile si la migration de la VM vers RBD échoue et que vous devez annuler les modifications. De plus, pour pouvoir annuler rapidement les modifications, effectuons 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 modifiez l'original (vm_name.xml). Trouvons un bloc avec une description du disque (commence par la ligne <disk type='file' device='disk'> et se termine par </disk>) et réduisez-le sous la forme suivante :
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Regardons quelques détails :
- Au protocole
sourcel'adresse du stockage dans Ceph RBD est indiquée (il s'agit de l'adresse indiquant le nom du pool Ceph et de l'image RBD, qui a été déterminée lors de la première étape). - Dans le bloc
secretle type est indiquéceph, ainsi que l'UUID du secret pour s'y connecter. Son uuid peut être trouvé à l'aide de 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 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 que la machine virtuelle a bien démarré : vous pouvez le savoir, par exemple, en vous y connectant via SSH ou via virsh.
Si la machine virtuelle fonctionne correctement et que vous n'avez trouvé aucun autre problème, alors vous pouvez supprimer l'image LVM qui n'est plus utilisée :
lvremove main/$vm_image_nameConclusion
Nous avons rencontré tous les cas décrits dans la 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 concernant votre expérience d'utilisation de Ceph, nous serons heureux de les voir dans les commentaires !
PS
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com