Question Utilisation brute de l'espace par le CEPH


Je ne comprends pas l'utilisation de l'espace brut Ceph.

J'ai 14 disques durs (14 OSD) sur 7 serveurs, 3 To chaque disque dur ~ 42 To d'espace brut au total.

ceph -s 
     osdmap e4055: 14 osds: 14 up, 14 in
      pgmap v8073416: 1920 pgs, 6 pools, 16777 GB data, 4196 kobjects
            33702 GB used, 5371 GB / 39074 GB avail

J'ai créé 4 périphériques de bloc, 5 To chacun:

df -h
 /dev/rbd1       5.0T  2.7T  2.4T  54% /mnt/part1
/dev/rbd2       5.0T  2.7T  2.4T  53% /mnt/part2
/dev/rbd3       5.0T  2.6T  2.5T  52% /mnt/part3
/dev/rbd4       5.0T  2.9T  2.2T  57% /mnt/part4

df montre que 10,9 To est utilisé au total, ceph indique que 33702 Go est utilisé. Si j'ai 2 copies, il faut environ 22 To, mais maintenant j'ai 33,7 To utilisées - 11 To manquées.

ceph osd pool get archyvas size
size: 2


ceph df
GLOBAL:
    SIZE       AVAIL     RAW USED     %RAW USED
    39074G     5326G       33747G         86.37
POOLS:
    NAME          ID     USED      %USED     MAX AVAIL     OBJECTS
    data          0          0         0         1840G           0
    metadata      1          0         0         1840G           0
    archyvas      3      4158G     10.64         1840G     1065104
    archyvas2     4      4205G     10.76         1840G     1077119
    archyvas3     5      3931G     10.06         1840G     1006920
    archyvas4     6      4483G     11.47         1840G     1148291

Bloquer les appareils et OSD FS - XFS


7
2018-04-17 16:40


origine




Réponses:


Une source de confusion possible est le rapport GB / GiB / TB / TiB (base 10 / base 2), mais cela ne peut pas expliquer toute la différence ici.

Ceph / RBD essaiera d’allouer «paresseusement» de l’espace pour vos volumes. C'est pourquoi, bien que vous ayez créé quatre volumes de 5 To, il indique 16 To utilisés, et non 20. Mais 16 To représente plus que la somme du contenu "actif" de vos systèmes de fichiers sauvegardés par RBD, ce qui ne représente qu'environ 11 To, comme vous dites. Plusieurs points à noter:

Lorsque vous supprimez des fichiers dans vos systèmes de fichiers sauvegardés par RBD, les systèmes de fichiers marquent en interne les blocs comme étant libres, mais n'essayent généralement pas de les "restituer" au périphérique de bloc sous-jacent (RBD). Si votre version RBD du noyau est suffisamment récente (3.18 ou plus récente), vous devriez pouvoir utiliser fstrim renvoyer les blocs libérés à RBD. Je soupçonne que vous avez créé et supprimé d'autres fichiers sur ces systèmes de fichiers, non?

Il existe également une surcharge du système de fichiers au-delà de l’utilisation nette des données qui est indiquée par df. Outre les "superblocs" et d'autres structures de données internes au système de fichiers, il faut s'attendre à une surcharge de la granularité à laquelle RBD attribue les données. Je pense que RBD allouera toujours des blocs de 4 Mo, même si une partie seulement est utilisée.


5
2018-04-18 12:43



Et je suis d'accord avec Simon. Devinez nos deux réponses ensemble pour en faire une complète. btw. allez au diable. 20 heures vieille question et vous me bat de répondre par 35 secondes? :RÉ - Fox
Merci à vous deux pour les réponses. Maintenant, je comprends où se trouve mon problème et comment le résoudre. - virgism
Options possibles: 1. Mise à niveau vers le noyau Linux> 3.18 et option de montage avec suppression; (J'ai testé avec le noyau 3.19.0-1.el6.elrepo.x86_64, mais il y avait des blocages tous les jours); 2. Recréez les périphériques de bloc avec une taille <5 To (ne peut pas réduire XFS). 3. Ajoutez un disque dur et créez des OSD supplémentaires. - virgism
Peut confirmer que cela fonctionne bien. Mise à niveau du noyau de ma machine client Ceph vers la version 3.19 le week-end dernier dans Ubuntu LTS 14.04.3 (sudo apt-get install --install-recommends linux-generic-lts-vivid), redémarré, re-mappé et monté mes volumes rbd, a exécuté un fstrim sur chacun d’eux, et collectivement récupéré 450 Go sur un petit cluster de 25 To. Une fois la mise à niveau effectuée, assurez-vous de commencer à monter vos volumes rbd avec le discardoption. - Brian Cline


Je ne suis pas un expert en ceph mais laissez-moi deviner un peu.

Les dispositifs de blocage ne sont pas montés sans discard option. Ainsi, les données que vous écrivez et supprimez n'apparaissent pas sur le système de fichiers (/mnt/part1), mais comme il a été écrit et non coupé, il reste sur le système de fichiers sous-jacent.

Si vous regardez USED pour vos piscines et les ajouter, vous obtenez 16777GB, ce qui équivaut à ce que ceph -s spectacles. Et si vous multipliez cela par deux (deux copies), vous obtenez 33554 Go, ce qui correspond à peu près à l'espace utilisé.


5
2018-04-18 12:44



Je suis d'accord avec la réponse de Fox (qui a été écrite en même temps que la mienne ci-dessous :-). discard et "trim" sont fondamentalement des mots différents pour le même mécanisme qui peuvent être utilisés pour renvoyer des blocs inutilisés à un périphérique bloc. Montage avec le discard l'option devrait avoir l'effet désiré. Certaines personnes préfèrent exécuter périodiquement fstrim pour éviter la surcharge de rejet continuels par le système de fichiers. Notez que pour que tout cela fonctionne, votre pilote RBD doit prendre en charge TRIM / discard. Comme je l’ai dit, le pilote de noyau RBD fait cela depuis Linux 3.18 - voir tracker.ceph.com/issues/190. - sleinen