Système de fichiers distribué Ceph¶
On décembre 12, 2021 by adminCeph est un système de fichiers réseau distribué conçu pour fournir de bonnes performances, une bonne fiabilité et une bonne évolutivité.
Les caractéristiques de base comprennent :
- Sémantique POSIX
- Mise à l’échelle transparente de 1 à plusieurs milliers de nœuds
- Haute disponibilité et fiabilité. Pas de point de défaillance unique.
- Réplication à sens unique des données sur les nœuds de stockage
- Recouvrement rapide des pannes de nœuds
- Rééquilibrage automatique des données lors de l’ajout ou du retrait de nœuds
- Déploiement facile : la plupart des composants FS sont des démons en espace utilisateur
Aussi,
- Affichages instantanés flexibles (sur n’importe quel répertoire)
- Comptabilité récursive (fichiers imbriqués, répertoires, octets)
Contrairement aux systèmes de fichiers en grappe comme GFS, OCFS2 et GPFS qui s’appuient sur un accès symétrique de tous les clients aux périphériques de blocs partagés, Cephséparent la gestion des données et des métadonnées dans des grappes de serveurs indépendants, similaires à Lustre. Contrairement à Lustre, cependant, les nœuds de métadonnées et de stockage fonctionnent entièrement comme des démons en espace utilisateur. Les données des fichiers sont réparties sur les nœuds de stockage en gros morceaux pour distribuer la charge de travail et faciliter les débits élevés. Lorsque les nœuds de stockage tombent en panne, les données sont répliquées de manière distribuée par les nœuds de stockage eux-mêmes (avec une coordination minimale d’un moniteur de cluster), ce qui rend le système extrêmement efficace et évolutif.
Les serveurs de métadonnées forment effectivement un grand cache en mémoire cohérent et distribué au-dessus de l’espace de noms de fichiers qui est extrêmement évolutif, redistribue dynamiquement les métadonnées en réponse aux changements de la charge de travail et peut tolérer des pannes de nœuds arbitraires (enfin, non byzantines). Le serveur de métadonnées adopte une approche quelque peu non conventionnelle du stockage des métadonnées afin d’améliorer considérablement les performances des charges de travail courantes. En particulier, les inodes n’ayant qu’un seul lien sont des indirects intégrés, permettant à des répertoires entiers de dentries et d’inodes d’être chargés dans son cache en une seule opération d’entrée/sortie. Le contenu de répertoires extrêmement volumineux peut être fragmenté et géré par des serveurs de métadonnées indépendants, ce qui permet un accès simultané évolutif.
Le système offre un rééquilibrage/migration automatique des données lors de la mise à l’échelle d’un petit cluster de quelques nœuds à plusieurs centaines, sans qu’un administrateur ait à découper l’ensemble des données en volumes statiques ou à passer par le processus fastidieux de migration des données entre les serveurs.Lorsque le système de fichiers approche de la saturation, de nouveaux nœuds peuvent être facilement ajoutés et les choses » fonctionneront tout simplement «
Ceph inclut un mécanisme flexible de snapshot qui permet à un utilisateur de créer un snapshot sur n’importe quel sous-répertoire (et son contenu imbriqué) dans le système. La création et la suppression d’un instantané sont aussi simples que ‘mkdir.snap/foo’ et ‘rmdir .snap/foo’.
Ceph fournit également une certaine comptabilité récursive sur les répertoires pour les fichiers et les octets imbriqués. C’est-à-dire qu’un ‘getfattr -d foo’ sur n’importe quel répertoire du système révélera le nombre total de fichiers réguliers imbriqués et de sous-répertoires, ainsi qu’une somme de toutes les tailles de fichiers imbriqués. Cela rend l’identification des gros consommateurs d’espace disque relativement rapide, car aucun ‘du’ ou analyse récursive similaire du système de fichiers n’est nécessaire.
Enfin, Ceph permet également de définir des quotas sur n’importe quel répertoire du système.Le quota peut restreindre le nombre d’octets ou le nombre de fichiers stockés sous ce point dans la hiérarchie du répertoire. Les quotas peuvent être définis à l’aide d’attributs étendus ‘ceph.quota.max_files’ et ‘ceph.quota.max_bytes’, par exemple :
setfattr -n ceph.quota.max_bytes -v 100000000 /some/dirgetfattr -n ceph.quota.max_bytes /some/dir
Une limitation de l’implémentation actuelle des quotas est qu’elle repose sur lacoopération du client montant le système de fichiers pour arrêter les écrivains quand alimit est atteint. Un client modifié ou adverse ne peut pas être empêché d’écrire autant de données que nécessaire.
Options de montage¶
ip=A.B.C.D Spécifiez l’IP et/ou le port auquel le client doit se lier localement.Il n’y a normalement pas beaucoup de raisons de le faire. Si l’IP n’est pas spécifiée, l’adresse IP du client est déterminée en regardant l’adresse d’où provient sa connexion au moniteur. wsize=X Spécifiez la taille maximale d’écriture en octets. Valeur par défaut : 64 Mo. rsize=X Spécifiez la taille maximale de lecture en octets. Valeur par défaut : 64 Mo. rasize=X Indiquez la taille maximale de lecture en octets. Valeur par défaut : 8 Mo. mount_timeout=X Spécifiez la valeur du délai d’attente pour le montage (en secondes), dans le cas d’un système de fichiers Ceph non réactif. La valeur par défaut est de 60 secondes. caps_max=X Spécifiez le nombre maximum de captures à conserver. Les caps inutilisés sont libérés lorsque le nombre de caps dépasse la limite. La valeur par défaut est 0 (pas de limite) rbytes Lorsque stat() est appelé sur un répertoire, la valeur de st_size est ‘rbytes’, la somme des tailles de tous les fichiers imbriqués sous ce répertoire. C’est la valeur par défaut. norbytes Lorsque stat() est appelé sur un répertoire, définissez st_size sur le nombre d’entrées dans ce répertoire. nocrc Désactive le calcul CRC32C pour les écritures de données. Si cette option est activée, le nœud de stockage doit s’appuyer sur la correction d’erreurs de TCP pour détecter la corruption des données dans les données utiles. dcache Utilisez le contenu du dcache pour effectuer des recherches négatives et lire le répertoire lorsque le client a le contenu entier du répertoire dans son cache. (Cela ne modifie pas l’exactitude ; le client utilise les métadonnées mises en cache uniquement lorsqu’un bail ou une capacité garantit leur validité). nodcache Ne pas utiliser le dcache comme ci-dessus. Cela permet d’éviter une quantité significative de code complexe, en sacrifiant les performances sans affecter l’exactitude, et est utile pour traquer les bogues. noasyncreaddir Ne pas utiliser le dcache comme ci-dessus pour readdir. noquotadf Rapporter l’utilisation globale du système de fichiers dans statfs au lieu d’utiliser le quota du répertoire racine. nocopyfrom Ne pas utiliser l’opération ‘copy-from’ de RADOS pour effectuer des copies d’objets distants. Actuellement, elle est uniquement utilisée dans copy_file_range, qui reviendra à l’implémentation VFS par défaut si cette option est utilisée. recover_session=<no|clean>Définit le mode de reconnexion automatique dans le cas où le client est bloqué. Les modes disponibles sont « no » et « clean ». Le défaut est « no ».
- no : ne jamais tenter de se reconnecter lorsque le client détecte qu’il a étéblocklisted. Les opérations échoueront généralement après avoir été bloquées.
- clean : le client se reconnecte automatiquement au cluster ceph lorsqu’ildétecte qu’il a été bloqué. Pendant la reconnexion, le client abandonne les données/métadonnées sales, invalide les caches de pages et les poignées de fichiers inscriptibles.Après la reconnexion, les verrous de fichiers deviennent périmés car le MDS en perd la trace. Si un inode contient des verrous de fichiers périmés, la lecture/écriture sur l’inode n’est pas autorisée jusqu’à ce que les applications libèrent tous les verrous de fichiers périmés.
Laisser un commentaire