PDA

Bekijk Volledige Versie : CEPH OSD Near Full



bibawa
17/05/17, 22:27
Hoi,

We draaien naar alle tevredenheid een 4 node Ceph cluster.
Sinds een aantal uur staat een van de OSD boven zijn limiet van 85% en geeft daardoor een warning OSD NEAR FULL, als ik de OSD vulling bekijk dan zijn er OSDs die slechts voor 60% gevuld zijn en zijn er andere die dus quasi tegen die limiet van 85% aanlopen..

Wat is nu de beste manier om die toch wat meer equal te verdeelt te krijgen?
Dien ik de OSDs die quasi vol zijn gewoon te 'reweighten' of is dat geen goed idee ?

mvg,

SF-Jeroen
18/05/17, 00:10
Hebben alle OSD nodes dezelfde opslagcapaciteit? En gaat het om een replicated of erasure cluster?

bibawa
18/05/17, 00:33
Alle OSDs zijn 1TB disken met 'n weight van 1..
Replicated pool..


Voor de volledigheid:



root@prox12:~# ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 4.00000 pool distributed-storage
-5 2.00000 rack rack-E10
-2 4.00000 host prox11
0 1.00000 osd.0 up 1.00000 1.00000
1 1.00000 osd.1 up 1.00000 1.00000
2 1.00000 osd.2 up 1.00000 1.00000
3 1.00000 osd.3 up 1.00000 1.00000
-3 4.00000 host prox12
4 1.00000 osd.4 up 1.00000 1.00000
5 1.00000 osd.5 up 1.00000 1.00000
6 1.00000 osd.6 up 1.00000 1.00000
7 1.00000 osd.7 up 1.00000 1.00000
-6 2.00000 rack rack-E13
-4 4.00000 host prox13
8 1.00000 osd.8 up 1.00000 1.00000
9 1.00000 osd.9 up 1.00000 1.00000
10 1.00000 osd.10 up 1.00000 1.00000
11 1.00000 osd.11 up 1.00000 1.00000
-7 4.00000 host prox14
12 1.00000 osd.12 up 1.00000 1.00000
13 1.00000 osd.13 up 1.00000 1.00000
14 1.00000 osd.14 up 1.00000 1.00000
15 1.00000 osd.15 up 1.00000 1.00000

bibawa
18/05/17, 09:44
Nog zoiets geks:



^Croot@prox12:/home/xenius# ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
14888G 4294G 10593G 71.15
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
distributed-storage 5 4867G 65.39 1078G 1375183


Global pool size= 15TB dat kan kloppen 4 nodes met telkens 4x1TB..
De pool distributed-storage heeft pool settings 2/1 wat toch wil zeggen 2 kopies van elk object opslaan. Ik heb nu netto 4.8 Used met nog 1.078TB beschikbaar => 5.878TB totaal netto beschikbaar..
Die 2 kopies zit daar het originele object eigenlijk ook al bij of moet ik dat er ook nog bijtellen wat het totaal aantal kopies op 3 zet ?

Als ik even reken zou ik toch verwachten ergens rond de 7.4TB beschikbaar te moeten hebben totaal...

Wie helpt me er even uit :-)

CharlieRoot
18/05/17, 10:29
Nog zoiets geks:



^Croot@prox12:/home/xenius# ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
14888G 4294G 10593G 71.15
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
distributed-storage 5 4867G 65.39 1078G 1375183


Global pool size= 15TB dat kan kloppen 4 nodes met telkens 4x1TB..
De pool distributed-storage heeft pool settings 2/1 wat toch wil zeggen 2 kopies van elk object opslaan. Ik heb nu netto 4.8 Used met nog 1.078TB beschikbaar => 5.878TB totaal netto beschikbaar..
Die 2 kopies zit daar het originele object eigenlijk ook al bij of moet ik dat er ook nog bijtellen wat het totaal aantal kopies op 3 zet ?

Als ik even reken zou ik toch verwachten ergens rond de 7.4TB beschikbaar te moeten hebben totaal...

Wie helpt me er even uit :-)

Doe eens een df op de OSD's en post de resultaten.

bibawa
19/05/17, 22:08
Big thanks too CharlieRoot foor de hulp [emoji323][emoji898]

Smashmint
20/05/17, 00:11
Wat was uiteindelijk de oplossing?

bibawa
20/05/17, 00:39
De uiteindelijke oplossing was het reweighten van OSDs en een rack, maar het rare is dat er in de crushmap zaken instaan qua weights die ik er nooit heb ingezet..

Zo ben ik er zeker van dat ik beide racks op een weight van 2 gezet hadden, 1 rack stond in de actuele crush nog op 2 terwijl de andere op 7.96 oid stond.. Nu kan ik mij vergissen of mistypen maar dat is nu echt zo'n getal waarvan ik 100% weet dat ik het er nooit heb ingezet.. (we hebben mijn crushmap gevonden die ik toen injected heb en die klopt..)

Dusja dat was de oorzaak van de ellende die crushmap die foutief was om een of andere zeer vage - nog onbekende - reden...

mvg,

CharlieRoot
20/05/17, 12:07
De uiteindelijke oplossing was het reweighten van OSDs en een rack, maar het rare is dat er in de crushmap zaken instaan qua weights die ik er nooit heb ingezet..

Zo ben ik er zeker van dat ik beide racks op een weight van 2 gezet hadden, 1 rack stond in de actuele crush nog op 2 terwijl de andere op 7.96 oid stond.. Nu kan ik mij vergissen of mistypen maar dat is nu echt zo'n getal waarvan ik 100% weet dat ik het er nooit heb ingezet.. (we hebben mijn crushmap gevonden die ik toen injected heb en die klopt..)

Dusja dat was de oorzaak van de ellende die crushmap die foutief was om een of andere zeer vage - nog onbekende - reden...

mvg,

Gelukkig werkt nu alles weer, ik hoop dat de performance ook wat is verbeterd.

Oh en, fijne verjaardag :)

CharlieRoot
20/05/17, 12:11
De uiteindelijke oplossing was het reweighten van OSDs en een rack, maar het rare is dat er in de crushmap zaken instaan qua weights die ik er nooit heb ingezet..
mvg,

Iets meer detail;
Er waren 5 OSD's met een near full melding en 1 OSD die 96% vol zat. Ook kwamen er meldingen "backfill_toofull" die opliepen. Omdat de crushmap was uitgerust met twee racks (failure domains) en die weight's niet klopte bleef hij dus data wegschrijven naar de verkeerde (te volle) hosts.

Mocht iemand dit ooit hebben en moeten oplossen;

Begin met de melding backfill_toofull oplossen door de weights van die betreffende OSD's LANGZAAM IN STAPPEN te verlagen. Bijv van 1 naar 0.97, dan naar 0.95. Bekijk gedurende de recovery goed waar de data naartoe gaat, het kan zijn dat andere OSD's hierdoor namelijk vollopen en daar moet je het zelfde tructje uithalen.

Pas als je error-vrij bent, nieuwe crushmap er in gooien en koffie pakken.