Utilisation de l'espace brut du CEPH


8

Je ne peux pas comprendre l'utilisation de l'espace brut de 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 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 sont utilisés au total, ceph montre que 33702 Go sont utilisés. Si j'ai 2 copies, cela doit être ~ 22 To, mais maintenant j'ai 33,7 To utilisés - 11 To manqués.

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

Réponses:


6

Une source possible de confusion est GB vs GiB / TB vs 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 rapporte 16 To utilisés, pas 20. Mais 16 To est plus que la somme du contenu "actif" de vos systèmes de fichiers soutenus par RBD, qui n'est que d'environ 11 To, comme vous le dites. Plusieurs choses à noter:

Lorsque vous supprimez des fichiers dans vos systèmes de fichiers RBD, les systèmes de fichiers marqueront en interne les blocs comme libres, mais n'essaieront généralement pas de les "renvoyer" au périphérique de bloc sous-jacent (RBD). Si votre version RBD du noyau est assez récente (3.18 ou plus récente), vous devriez pouvoir utiliser fstrimpour 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 indiquée par df. Outre les «superblocs» et d'autres structures de données internes au système de fichiers, une certaine surcharge est à prévoir de la granularité à laquelle RBD alloue les données. Je pense que RBD allouera toujours des morceaux de 4 Mo, même si seule une partie de celui-ci est utilisée.


Et je suis d'accord avec Simon. Je suppose que nos deux réponses ensemble en font une complète. btw. allez au diable. Question de 20 heures et vous m'avez battu pour répondre par 35 secondes? : D
Fox

Merci à vous deux pour les réponses. Maintenant, je comprends où est mon problème et comment le résoudre.
virgisme

Options possibles: 1. mise à niveau vers le noyau Linux> 3.18 et montage avec option de suppression; (J'ai testé avec le noyau 3.19.0-1.el6.elrepo.x86_64, mais j'avais des blocages tous les jours); 2. Recréez des 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.
virgisme du

1
Peut confirmer que cela fonctionne bien. Mis à jour le noyau de ma machine client Ceph à 3.19 le week-end dernier dans Ubuntu LTS 14.04.3 ( sudo apt-get install --install-recommends linux-generic-lts-vivid), redémarré, remappé et monté mes volumes rbd, exécuté un fstrimsur chacun d'eux et récupéré collectivement 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 l' discardoption.
Brian Cline

5

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

Les appareils bloc ne sont pas montés sans discardoption. Ainsi, toutes les données que vous écrivez et supprimez n'apparaissent pas sur le système de fichiers ( /mnt/part1), mais comme elles ont été écrites et non découpées, elles restent sur le système de fichiers sous-jacent.

Si vous recherchez USEDvos pools et les ajoutez ensemble, vous obtenez 16777 Go, ce qui équivaut à ce qui ceph -ss'affiche. Et si vous multipliez cela par deux (deux copies), vous obtenez 33554 Go, ce qui est à peu près l'espace utilisé.


1
Je suis d'accord avec la réponse de Fox (qui a été écrite en même temps que la mienne ci-dessous :-). discardet "trim" sont des mots fondamentalement différents pour le même mécanisme qui peuvent être utilisés pour renvoyer des blocs inutilisés à un périphérique de bloc. Le montage avec l' discardoption devrait avoir l'effet souhaité. Certaines personnes préfèrent s'exécuter périodiquement fstrimpour éviter la surcharge des rejets continus 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 du noyau RBD fait cela depuis Linux 3.18 - voir tracker.ceph.com/issues/190 .
Sleinen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.