Ceph trop de pages par osd: tout ce que vous devez savoir
Je reçois les deux de ces erreurs en même temps. Je ne peux pas diminuer le nombre de pg et je ne peux pas ajouter plus de stockage.
Il s'agit d'un nouveau cluster, et j'ai reçu ces avertissements lorsque j'ai téléchargé environ 40 Go sur celui-ci. Je suppose que radosgw a créé un tas de piscines.
Comment ceph peut-il avoir trop de pages par osd, tout en ayant plus d'objets par page que la moyenne avec une suggestion de pages trop faible?
HEALTH_WARN too many PGs per OSD (352 > max 300);
pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?)
osds: 4 (2 per site 500GB per osd)
size: 2 (cross site replication)
pg: 64
pgp: 64
pools: 11
En utilisant rbd et radosgw, rien d'extraordinaire.
Je vais répondre à ma propre question dans l'espoir que cela jette un peu de lumière sur la question ou des idées fausses similaires sur les internes de ceph.
Correction de HEALTH_WARN trop de PG par OSD (352> max 300) une fois pour toutes
Lorsque équilibrage groupes de placement, vous devez prendre en compte:
Les données dont nous avons besoin
- pgs per osd
- pgs par pool
- piscines par osd
- la carte d'écrasement
- pg et num pgp par défaut raisonnables
- nombre de répliques
J'utiliserai ma configuration comme exemple et vous devriez pouvoir l'utiliser comme modèle pour le vôtre.
Les données dont nous disposons
- num osds: 4
- nombre de sites: 2
- pages par osd: ???
- pgs par pool: ???
- piscines par osd: 10
- nombre de pg et pgp par défaut raisonnable: 64 (... ou est-ce?)
- nombre de répliques: 2 (réplication intersite)
- la carte d'écrasement
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY root ourcompnay site a rack a-esx.0 Host prdceph-strg01 osd.0 up 1.00000 1.00000 osd.1 up 1.00000 1.00000 site b rack a-esx.0 Host prdceph-strg02 osd.2 up 1.00000 1.00000 osd.3 up 1.00000 1.00000
Notre objectif est de remplir le '???' Ci-dessus avec ce dont nous avons besoin pour servir un cluster HEALTH OK. Nos piscines sont créées par la passerelle rados lors de son initialisation. Nous avons un seul default.rgw.buckets.data Où toutes les données sont stockées, les autres pools sont administratifs et internes aux métadonnées et à la comptabilité de cephs.
PG par osd (qu'est-ce qu'un défaut raisonnable de toute façon ???)
La documentation nous obligerait à utiliser ce calcul pour déterminer notre nombre de pg par osd:
(osd * 100)
----------- = pgs UP to nearest power of 2
replica count
Il est indiqué qu'arrondir est optimal. Donc, avec notre configuration actuelle, ce serait:
(4 * 100)
----------- = (200 to the nearest power of 2) 256
2
- osd.1 ~ = 256
- osd.2 ~ = 256
- osd.3 ~ = 256
- osd.4 ~ = 256
Il s'agit du nombre maximal recommandé de pages par osd. Alors ... qu'est-ce que vous avez actuellement? Et pourquoi ça ne marche pas? Et si vous définissez un "défaut raisonnable" et comprenez ce qui précède POURQUOI ÇA NE FONCTIONNE PAS !!! >
== [- Probablement, quelques raisons. Nous devons comprendre ce que ces "défauts raisonnables" ci-dessus signifient réellement, comment ceph les applique et où. On pourrait mal comprendre ce qui précède que je pourrais créer un nouveau pool comme ceci:
ceph osd pool create <pool> 256 256
ou je pourrais même penser que je pourrais jouer en toute sécurité et suivre la documentation qui indique que (128 pgs for < 5 osds) peut utiliser:
ceph osd pool create <pool> 128 128
C'est faux, carrément. Parce que cela n'explique en aucune façon la relation ou l'équilibre entre ce que ceph fait réellement avec ces chiffres, la bonne réponse est:
ceph osd pool create <pool> 32 32
Et laissez-moi vous expliquer pourquoi:
Si comme moi, vous avez provisionné votre cluster avec ces "valeurs par défaut raisonnables" (128 pgs for < 5 osds) Dès que vous avez essayé de faire quoi que ce soit avec les rados, cela a créé tout un tas de pools et votre cluster a éclaté. La raison en est que j'ai mal compris la relation entre tout ce qui est mentionné ci-dessus.
- pools: 10 (créés par rados)
- pages par pool: 128 (recommandé dans les documents)
- osds: 4 (2 par site)
10 * 128 / 4 = 320 pgs per osd
Ce ~320 Pourrait être un nombre de pages par osd sur mon cluster. Mais ceph pourrait les distribuer différemment. C'est exactement ce qui se passe et est bien au-dessus des 256 max par osd indiqué ci-dessus. HEALTH WARN De mon cluster est HEALTH_WARN too many PGs per OSD (368 > max 300).
En utilisant la commande this , nous pouvons mieux voir la relation entre les nombres:
pool :17 18 19 20 21 22 14 23 15 24 16 | SUM
------------------------------------------------< - *total pgs per osd*
osd.0 35 36 35 29 31 27 30 36 32 27 28 | 361
osd.1 29 28 29 35 33 37 34 28 32 37 36 | 375
osd.2 27 33 31 27 33 35 35 34 36 32 36 | 376
osd.3 37 31 33 37 31 29 29 30 28 32 28 | 360
-------------------------------------------------< - *total pgs per pool*
SUM :128 128 128 128 128 128 128 128 128 128 128
Il existe une corrélation directe entre le nombre de pools dont vous disposez et le nombre de groupes d'emplacements qui leur sont affectés. J'ai 11 piscines dans l'extrait ci-dessus et elles ont chacune 128 pages et c'est trop !! Mes valeurs par défaut raisonnables sont 64! Alors, qu'est-ce-qu'il s'est passé??
Je comprenais mal comment les "défauts raisonnables" étaient utilisés. Lorsque j'ai défini ma valeur par défaut sur 64, vous pouvez voir que ceph a pris en compte ma carte d'écrasement lorsque j'ai un domaine d'échec entre le site a et le site b. Le Ceph doit s'assurer que tout ce qui se trouve sur le site a est au moins accessible sur le site b.
FAUX
site a
osd.0
osd.1 TOTAL of ~ 64pgs
site b
osd.2
osd.3 TOTAL of ~ 64pgs
Nous avions besoin d'un grand total de 64 pages par pool donc nos valeurs par défaut raisonnables auraient dû être réglées à 32 à partir de le début!
Si nous utilisons ceph osd pool create <pool> 32 32, Cela revient à dire que la relation entre nos pgs par pool et pgs per osd avec ces "valeurs par défaut raisonnables" et nos recommandations max pgs par osd commencent à avoir un sens:
Vous avez donc cassé votre cluster ^ _ ^
Ne vous inquiétez pas, nous allons le réparer. La procédure ici, je le crains, peut varier en termes de risque et de temps en fonction de la taille de votre cluster. Mais la seule façon de contourner cette modification consiste à ajouter plus de stockage, afin que les groupes de placement puissent redistribuer sur une plus grande surface. OR nous devons tout déplacer vers les pools nouvellement créés.
Je vais vous montrer un exemple de déplacement du pool default.rgw.buckets.data:
old_pool=default.rgw.buckets.data
new_pool=new.default.rgw.buckets.data
créer un nouveau pool, avec le nombre de pg correct:
ceph osd pool create $new_pool 32
copier le contenu de l'ancien pool le nouveau pool:
rados cppool $old_pool $new_pool
supprimer l'ancienne piscine:
ceph osd pool delete $old_pool $old_pool --yes-i-really-really-mean-it
renommer le nouveau pool en 'default.rgw.buckets.data'
ceph osd pool rename $new_pool $old_pool
Maintenant, il pourrait être une valeur sûre de redémarrer vos radosgws.
ENFIN CORRECT
site a
osd.0
osd.1 TOTAL of ~ 32pgs
site b
osd.2
osd.3 TOTAL of ~ 32pgs
Comme vous pouvez le voir, mes numéros de pool ont augmenté car ils sont ajoutés par identifiant de pool et sont de nouvelles copies. Et notre nombre total de pages par osd est bien inférieur à ~ 256 , ce qui nous donne la possibilité d'ajouter des pools personnalisés si nécessaire.
pool : 26 35 27 36 28 29 30 31 32 33 34 | SUM
-----------------------------------------------
osd.0 15 18 16 17 17 15 15 15 16 13 16 | 173
osd.1 17 14 16 15 15 17 17 17 16 19 16 | 179
osd.2 17 14 16 18 12 17 18 14 16 14 13 | 169
osd.3 15 18 16 14 20 15 14 18 16 18 19 | 183
-----------------------------------------------
SUM : 64 64 64 64 64 64 64 64 64 64 64
Vous devez maintenant tester votre cluster ceph avec tout ce qui est à votre disposition. Personnellement, j'ai écrit un tas de python sur boto qui teste l'infrastructure et renvoie les statistiques et les métadonnées des seaux assez rapidement. Ils m'ont assuré que le cluster est de retour en état de marche sans aucun des problèmes dont il a souffert auparavant. Bonne chance!
La correction du pool default.rgw.buckets.data a une fois pour toutes beaucoup plus d'objets par page que la moyenne (trop peu de pages?)
Cela signifie littéralement que vous devez augmenter le nombre de pg et pgp de votre pool. Alors faites-le. Avec tout ce qui précède à l'esprit. Cependant, lorsque vous faites cela, notez que le cluster va démarrer remblayage et vous pouvez regarder ce processus%: watch ceph -s Dans une autre fenêtre ou écran de terminal.
ceph osd pool set default.rgw.buckets.data pg_num 128
ceph osd pool set default.rgw.buckets.data pgp_num 128
Armé des connaissances et de la confiance dans le système fournies dans le segment ci-dessus, nous pouvons clairement comprendre la relation et l'influence d'un tel changement sur le cluster.
pool : 35 26 27 36 28 29 30 31 32 33 34 | SUM
----------------------------------------------
osd.0 18 64 16 17 17 15 15 15 16 13 16 | 222
osd.1 14 64 16 15 15 17 17 17 16 19 16 | 226
osd.2 14 66 16 18 12 17 18 14 16 14 13 | 218
osd.3 18 62 16 14 20 15 14 18 16 18 19 | 230
-----------------------------------------------
SUM : 64 256 64 64 64 64 64 64 64 64 64
Pouvez-vous deviner quel identifiant de pool est default.rgw.buckets.data? haha ^ _ ^
Dans Ceph Nautilus (v14 ou version ultérieure), vous pouvez activer "PG Autotuning". Voir cette documentation et cette entrée de blog pour plus d'informations.
J'ai accidentellement créé des pools avec des données en direct que je n'ai pas pu migrer pour réparer les PG. Il a fallu quelques jours pour récupérer, mais les PG ont été ajustés de manière optimale sans aucun problème.