Le stockage d'objets Ceph doit être compris avant de se connecter

Ceph, en tant que logiciel de stockage distribué open source, peut utiliser les ressources de stockage locales du serveur X86 pour créer un ou plusieurs pools de ressources de stockage et fournir aux utilisateurs des services de stockage unifiés basés sur les pools de ressources, y compris le stockage en bloc et le stockage d'objets. . , le stockage de fichiers, qui répond aux besoins des entreprises en matière de haute fiabilité, de hautes performances et de haute évolutivité du stockage, et est de plus en plus favorisé par les entreprises. Après de nombreuses pratiques de production, il a été prouvé que Ceph disposait de concepts de conception avancés, de fonctions complètes, d'une utilisation flexible et d'une grande flexibilité. Toutefois, ces avantages de Ceph sont également une arme à double tranchant pour les entreprises, si elles sont bien contrôlées, elles peuvent bien servir l'entreprise. Si elles ne sont pas suffisamment compétentes et ne comprennent pas le tempérament de Ceph, cela peut parfois causer beaucoup de problèmes. de problèmes. Ci-dessous, je le ferai. C'est un tel cas que je souhaite partager avec vous.

La société A fournit des services de stockage cloud externes en déployant des clusters de stockage d'objets Ceph et fournit un SDK pour aider les clients à obtenir rapidement des données non structurées telles que des images, des vidéos et des packages d'installation d'apk. Gestion des nuages. Avant le lancement officiel de l'entreprise, suffisamment de tests fonctionnels, de tests d'exceptions et de tests de performances ont été effectués sur Ceph.

La taille du cluster n'est pas très grande. Il utilise la version communautaire 0.80. Il y a un total de 30 serveurs. Chaque serveur est configuré avec 32 Go de mémoire, 10 disques SATA 4T et 1 disque SSD Intel S3700 de 160 Go. 300 disques SATA forment un pool de ressources de données (la configuration par défaut est un pool nommé .rgw.buckets) pour stocker les données d'objet ; 30 disques SSD forment un pool de ressources de métadonnées (la configuration par défaut est un pool nommé . rgw.buckets.index pool) , qui stocke les métadonnées des objets. Les amis qui ont de l'expérience dans l'exploitation et le déploiement de maintenance du stockage d'objets Ceph savent que cette configuration est également une pratique internationale car le stockage d'objets Ceph prend en charge la multi-location lorsque plusieurs utilisateurs METtent des objets dans le même compartiment (un espace logique de l'utilisateur), les métadonnées. de l'objet sera écrit dans l'objet d'index de compartiment. Étant donné que le même objet d'index de compartiment est partagé, cet objet d'index doit être verrouillé lors de l'accès, et l'objet d'index de compartiment sera stocké dans un pool de ressources composé de disque SSD hautes performances. , réduisant Le temps d'accès à chaque objet d'index est amélioré, les performances d'E/S sont améliorées et la concurrence globale du stockage d'objets est augmentée.

Après la mise en ligne du système, les données des clients ont commencé à être stockées en continu dans le cluster de stockage d'objets Ceph. Au cours des trois premiers mois, tout s'est déroulé normalement. Des pannes de disques SATA se sont également produites au cours de cette période, et elles ont été facilement résolues en s'appuyant sur les propres mécanismes de détection et de réparation des pannes de Ceph. Les frères d'exploitation et de maintenance se sont sentis très détendus. Au début du mois de mai, les frères d'exploitation et de maintenance se plaignaient parfois du fait que l'OSD correspondant au disque SSD devenait parfois très lent, provoquant des retards dans l'activité. Face à cette situation, leur moyen simple et efficace était de redémarrer l'OSD et de revenir à la normale. Ce phénomène s'est probablement produit sporadiquement à plusieurs reprises, et le frère chargé de l'exploitation et de la maintenance a demandé s'il y avait un problème avec notre utilisation du SSD. Après analyse, nous pensons qu'il n'y a rien de spécial dans l'application des disques SSD. À l'exception du changement de l'algorithme de planification des disques à date limite, celui-ci a déjà été modifié, nous n'y prêtons donc pas trop attention.

À 21h30 le soir du 28 mai, les frères d'exploitation et de maintenance ont reçu une alarme système sur leurs téléphones portables. Un petit nombre de fichiers n'ont pas pu être écrits. Ils se sont immédiatement connectés au système pour vérifier. et j'ai découvert que c'était à cause de l'OSD correspondant au disque SSD sur un serveur. Causé par une lecture et une écriture lentes. Selon l'expérience précédente, dans de tels cas, le processus OSD peut être restauré à la normale après l'avoir redémarré sans hésitation et attendre que le système revienne à la normale. Mais cette fois, le processus OSD du SSD a démarré très lentement, provoquant le gel du processus OSD du disque SATA sur le même serveur et la perte de son rythme cardiaque. Après un certain temps, il a été découvert que le processus OSD du disque SSD commençait à se bloquer lentement sur d'autres. serveurs. Continuez à redémarrer les processus OSD correspondant aux disques SSD sur d'autres serveurs, et une situation similaire se produit après le redémarrage répété des processus OSD du disque SSD, de plus en plus de processus OSD du disque SSD ne peuvent pas être démarrés. Les frères d'exploitation et de maintenance ont immédiatement signalé la situation au service de recherche et développement technique et ont demandé une assistance immédiate.

Après notre arrivée au bureau, sur la base des retours des frères d'exploitation et de maintenance, nous sommes montés à bord du serveur, avons essayé de démarrer les processus OSD correspondant à plusieurs disques SSD et avons observé à plusieurs reprises le processus de démarrage du processus de comparaison :

1 . Utilisez la commande top pour constater que le processus OSD commence à allouer de la mémoire de manière folle après son démarrage, jusqu'à 20 Go ou parfois 30 Go ; Le processus est finalement réussi, l'OSD est toujours occupé jusqu'à 10 Go de mémoire.

2. Vérifiez le journal OSD et constatez que la sortie du journal s'arrête après être entré dans l'étape FileJournal::_open. Après un long moment (plus de 30 minutes), la sortie entre dans l'étape load_pg ; après être entrée dans l'étape load_pg, il y a une autre longue attente. Bien que load_pg soit terminé, le processus se suicide et se termine.

3. Pendant le long processus de démarrage ci-dessus, utilisez pstack pour afficher les informations de la pile d'appels du processus. La pile d'appels vue dans l'étape FileJournal::_open est la lecture du journal OSD et la suppression de l'enregistrement levelDB est effectuée pendant le traitement de la transaction. ; Les informations sur la pile d'appels vues dans l'étape load_pg utilisent le journal levelDB pour réparer le fichier levelDB.

4. Parfois, un processus OSD de disque SSD démarre avec succès, mais après avoir fonctionné pendant un certain temps, un autre processus OSD de disque SSD s'arrêtera anormalement.

À en juger par ces phénomènes, ils sont tous liés à levelDB. La grande allocation de mémoire est-elle liée à cela ? Après avoir vérifié davantage le code lié à levelDB, nous avons constaté que lorsqu'un itérateur levelDB est utilisé dans une transaction, la mémoire sera continuellement allouée pendant l'accès de l'itérateur aux enregistrements, et toute la mémoire ne sera libérée que lorsque l'itérateur sera épuisé. De ce point de vue, si le nombre d’enregistrements accédés par l’itérateur est très important, une grande quantité de mémoire sera allouée lors du processus d’itération. Sur cette base, nous avons examiné le nombre d'objets dans le compartiment et avons constaté que le nombre d'objets dans plusieurs compartiments atteignait 20 millions, 30 millions et 50 millions, et que les emplacements de stockage de ces grands objets d'index de compartiment se trouvaient être ceux où le problème s'est produit. La raison de la grande consommation de mémoire aurait dû être trouvée. Il s'agit d'une avancée majeure. Il est déjà 21h00 le 30. Au cours des deux derniers jours, les utilisateurs ont commencé à appeler pour se plaindre. un énorme problème". Ils se battent depuis près de 48 heures, et les yeux des frères sont rouges et enflés. Ils doivent s'arrêter et se reposer, sinon certains frères tomberont avant l'aube.

Le 31 à 8h30, les frères repartent au combat.

Il y a un autre problème, c'est-à-dire que certains OSD passent par un long processus de démarrage et finissent par se suicider une fois load_pg terminé. En lisant le code Ceph, il a été confirmé que certains threads se sont suicidés en raison d'un délai d'attente dû au fait qu'ils n'étaient pas planifiés pendant une longue période (peut-être en raison du fait que le thread levelDB occupait le processeur pendant une longue période). Il existe un paramètre filestore_op_thread_suicide_timeout dans la configuration de ceph. Grâce aux tests et à la vérification, définir ce paramètre sur une valeur élevée peut éviter ce type de suicide. Nous avons revu un peu de lumière et l'horloge indiquait 12h30.

Une fois certains processus démarrés, ils occuperont toujours jusqu'à 10 Go de mémoire. Si ce problème n'est pas résolu, même si l'OSD du disque SSD est extrait, le fonctionnement des autres OSD du disque SATA sur le même serveur. sera affecté en raison d’une mémoire insuffisante. Frères, continuez votre bon travail, c'est l'obscurité avant l'aube, vous devez vous en sortir. Certaines personnes ont vérifié les informations, d'autres ont regardé le code et ont finalement trouvé une commande pour forcer la libération de mémoire à partir du document d'information ceph à 14h30 : ceph tell osd.* heap release Cette commande peut être exécutée une fois le processus terminé. a commencé à libérer la mémoire excessive occupée par le processus OSD. Tout le monde était très enthousiaste et a immédiatement testé et vérifié que c'était effectivement efficace.

Après le démarrage et l'exécution d'un OSD de disque SSD pendant un certain temps, le processus OSD des autres disques SSD se terminera. Sur la base de l'analyse et du positionnement ci-dessus, cela est principalement dû à la migration des données. La suppression des informations d'enregistrement associées incite levelDB à supprimer les enregistrements de métadonnées d'objet. Une fois qu'il rencontre un objet d'index de compartiment surdimensionné, levelDB utilise un itérateur pour parcourir les enregistrements de métadonnées de l'objet, ce qui entraînera une consommation excessive de mémoire et entraînera une anomalie du processus OSD sur le serveur.

Sur la base de l'analyse ci-dessus et après près de 2 heures de discussions et de démonstrations répétées, nous avons formulé les mesures d'urgence suivantes :

1 Placez le drapeau noout sur le cluster et n'autorisez pas PG. migration, car une fois la migration du PG effectuée, si le PG est déplacé hors de l'OSD, les données d'objet dans le PG seront supprimées après le déplacement du PG, ce qui déclenchera la suppression par levelDB de l'enregistrement de métadonnées de l'objet s'il existe un compartiment surdimensionné. objet d'index dans le PG, l'itérateur parcourra les métadonnées. La journalisation des données consomme beaucoup de mémoire.

2. Afin de sauvegarder l'OSD correspondant au SSD et de restaurer le système dans les plus brefs délais, lors du démarrage du processus OSD correspondant au SSD, ajoutez le paramètre de démarrage filestore_op_thread_suicide_timeout et définissez une valeur élevée. Lorsque l'OSD défectueux est affiché, une série de processus LevelDB saisira le processeur, provoquant le blocage de la planification des threads. Il existe un mécanisme de détection de blocage de thread dans Ceph. Si le thread n'est toujours pas planifié après le délai configuré par ce paramètre, il est déterminé qu'il s'agit d'un blocage de thread. Afin d'éviter un suicide de processus dû à un blocage de thread, ce paramètre doit être défini.

3. Dans la situation actuelle de mémoire limitée, un démarrage anormal de l'OSD utilisera la partition d'échange. Afin d'accélérer le démarrage du processus OSD, ajustez la partition d'échange sur le disque SSD.

4. Démarrez une tâche planifiée et exécutez régulièrement la commande ceph tell osd.* heap release pour forcer la libération de la mémoire occupée par OSD.

5. Lorsqu'il y a un problème avec l'OSD correspondant au SSD, suivez les étapes ci-dessous :

a) Arrêtez d'abord tous les processus OSD sur le serveur pour libérer toute la mémoire.

b) Ensuite, démarrez le processus OSD et portez le paramètre filestore_op_thread_suicide_timeout, en donnant une valeur élevée, telle que 72000.

c) Observez le processus de démarrage d'OSD. Une fois load_pgs exécuté, vous pouvez immédiatement exécuter manuellement la commande ceph tell osd.N heap release pour libérer de force la mémoire occupée par celui-ci.

d) Observez l'état du cluster. Lorsque l'état de tous les PG revient à la normale, démarrez les processus OSD correspondant aux autres disques SATA.

En suivant les étapes ci-dessus, nous restaurerons les processus OSD un par un à partir de 17h30. Pendant le processus de récupération, le remplissage de plusieurs objets d'index de compartiment très volumineux prendra beaucoup de temps. accès à ce bucket Toutes les requêtes sont bloquées, ce qui entraîne l'expiration du délai d'attente des requêtes métier des applications. Il s'agit également d'un impact négatif causé par le stockage d'un grand nombre d'objets dans un seul bucket.

Le 31 mai à 23h00, tous les processus OSD ont finalement été restaurés. De l'échec à la récupération réussie du système, nous nous sommes battus avec enthousiasme pendant 72 heures. Tout le monde s'est regardé et a souri, trop excité. Nous avons poursuivi nos efforts et discuté et formulé ensemble. Des solutions pour résoudre complètement ce problème :

1. Étendre la mémoire du serveur à 64 Go.

2. Pour les nouveaux buckets, limitez le nombre maximum d'objets de stockage.

3. Une fois la version 0.94 entièrement testée, elle sera mise à niveau vers la version 0.94 pour résoudre le problème des objets d'index à compartiment unique trop volumineux.

4. Optimiser l'utilisation des itérateurs levelDB par Ceph. Dans une transaction volumineuse, via une itération segmentée, un itérateur enregistre sa position d'itération actuelle et la libère après avoir effectué un certain nombre de parcours d'enregistrement. nouvel itérateur et continuez le parcours à partir de la position de la dernière itération, afin que l'utilisation de la mémoire de l'itérateur puisse être contrôlée.

En tant qu'enseignant qui n'oublie jamais le passé et tire les leçons du passé, nous résumons les points suivants :

1 Le système doit être entièrement testé avant d'être mis en ligne

. Entreprise A Avant la mise en ligne du système, bien que Ceph ait été entièrement testé sur ses fonctions, ses performances et ses exceptions, il n'y avait pas de test de résistance sur de grandes quantités de données. Si des dizaines de millions d'objets avaient été testés auparavant dans un seul compartiment, cela était caché. Le danger aurait pu être découvert à l'avance.

2. Chaque anomalie dans le processus d'exploitation et de maintenance doit être prise en compte à temps.

Dans ce cas, quelque temps avant que le problème n'éclate, le service d'exploitation et de maintenance avait déjà signalé le problème. problème d'anomalie SSD. Malheureusement, cela n'a pas attiré notre attention si nous avions mené une analyse approfondie à ce moment-là, nous aurions pu trouver la cause profonde du problème et formuler des mesures d'évitement à l'avance.

3. Découvrez le tempérament de ceph

Tout produit logiciel a des restrictions de spécifications correspondantes, et ceph ne fait pas exception. Si nous pouvons avoir une compréhension approfondie de l'architecture Ceph et de ses principes de mise en œuvre à l'avance, comprendre les impacts négatifs d'un stockage excessif d'un grand nombre d'objets dans un seul bucket et planifier à l'avance, les problèmes rencontrés dans ce cas seront ne se produit pas. RGW dispose d'une prise en charge très complète des quotas, y compris les quotas au niveau de l'utilisateur et du compartiment. Le nombre maximum d'objets autorisés à être stockés dans un seul compartiment peut être configuré.

4. Suivez toujours les derniers progrès de la communauté

Dans la version 0.94 de Ceph, la fonction de partitionnement des objets d'index de compartiment a été prise en charge. Un objet d'index de compartiment peut être divisé en plusieurs objets de partition. pour le stockage, ce qui peut être efficace Réduire le problème des objets d'index à compartiment unique trop volumineux.