🥇Tips & tricks voor het werken met Ceph in drukke projecten

Door Ceph te gebruiken als netopslag in projecten met verschillende belasting, kunnen we geconfronteerd worden met verschillende taken die op het eerste gezicht niet eenvoudig of triviaal lijken. Bijvoorbeeld:

de migratie van gegevens van oude Ceph naar nieuwe met gedeeltelijk gebruik van de vorige servers in het nieuwe cluster;
het oplossen van het probleem van de verdeling van schijfruimte in Ceph.

Bij het aanpakken van dergelijke taken komen we de noodzaak tegen om OSD's correct te extraheren zonder gegevensverlies, wat vooral relevant is bij grote hoeveelheden gegevens. Dit zal het onderwerp van het artikel zijn.

De hieronder beschreven methoden zijn van toepassing op alle versies van Ceph. Daarnaast zal rekening worden gehouden met het feit dat Ceph een grote hoeveelheid gegevens kan opslaan: om gegevensverlies en andere problemen te voorkomen, zullen sommige acties 'opgedeeld' worden in andere.

Inleiding over OSD

Aangezien twee van de drie besproken recepten over OSD (Object Storage Daemon) gaan, willen we in het kort uitleggen wat dit eigenlijk is in Ceph en waarom het zo belangrijk is, voordat we in de praktische zaken duiken.

Allereerst moet worden opgemerkt dat het volledige Ceph-cluster uit vele OSD's bestaat. Hoe meer OSD's er zijn, hoe meer beschikbare gegevensruimte in Ceph. Het is gemakkelijk te begrijpen de belangrijkste functie van OSD's: het slaat objectgegevens van Ceph op de bestandssystemen van alle knooppunten in het cluster op en biedt netwerktoegang voor lezen, schrijven en andere verzoeken.

Op hetzelfde niveau worden de replicatie-instellingen geplaatst door objecten tussen verschillende OSD's te kopiëren. Hier kunnen verschillende problemen optreden, waarvan we verderop in het artikel zullen spreken.

Case #1. Veilige extractie van OSD's uit het Ceph-cluster zonder gegevensverlies

De noodzaak om OSD's te extraheren kan voortkomen uit het verwijderen van een server uit het cluster - bijvoorbeeld ter vervanging door een andere server - wat bij ons is gebeurd en de aanleiding vormde voor het schrijven van dit artikel. De uiteindelijke doelstelling van de manipulaties is om alle OSD's en mon's op deze server te extraheren, zodat deze kan worden gestopt.

Voor de gemak en om een situatie te vermijden waarin we tijdens het uitvoeren van opdrachten de juiste OSD verkeerd aanwijzen, stellen we een aparte variabele in, waarvan de waarde het nummer van de te verwijderen OSD zal zijn. We noemen deze: ${ID} - hier en verder vervangt zo'n variabele het nummer van de OSD waarmee we werken.

Laten we kijken naar de toestand voordat we aan het werk gaan:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Om de OSD te verwijderen, moet deze langzaam worden uitgevoerd herpositioneren tot nul. Zo verminderen we de hoeveelheid gegevens in de OSD door deze naar andere OSD's te balanceren. Hiervoor worden de volgende opdrachten uitgevoerd:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

… en zo verder tot nul.

Een geleidelijke balans is noodzakelijk, om gegevensverlies te voorkomen. Dit is vooral relevant als er een grote hoeveelheid gegevens in de OSD staat. Om er zeker van te zijn dat de opdrachten zijn uitgevoerd herpositioneren succesvol, kan men uitvoeren ceph -s of in een apart terminalvenster ceph -w uitvoeren om wijzigingen in realtime te volgen.

Wanneer de OSD 'leeg' is, kan de gebruikelijke verwijdering worden uitgevoerd. Hiervoor zetten we de relevante OSD in de status down:

ceph osd down osd.${ID}

We 'halen' de OSD uit de cluster:

ceph osd out osd.${ID}

We stoppen de OSD-service en sluiten de schijfpartitie van het FS af:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

We verwijderen de OSD uit de CRUSH-map:

ceph osd crush remove osd.${ID}

Verwijder de OSD-gebruiker:

ceph auth del osd.${ID}

En tenslotte verwijderen we de OSD zelf:

ceph osd rm osd.${ID}

Opmerking: als u versie Ceph Luminous of hoger gebruikt, kunnen de bovenstaande verwijderingshandelingen worden beperkt tot twee opdrachten:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Als u na het uitvoeren van de bovenstaande opdrachten de opdracht uitvoert ceph osd tree, zou zichtbaar moeten zijn dat er geen OSD meer op de server is waar de werkzaamheden zijn uitgevoerd, waarvoor de bovenstaande handelingen zijn uitgevoerd:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Merk ook op dat de status van de Ceph-cluster zal veranderen in HEALTH_WARN, en dat we een afname van het aantal OSD's en de beschikbaarheid van schijfruimte zullen zien.

Hierna worden de stappen beschreven die nodig zijn als u de server volledig wilt stoppen en dus uit Ceph wilt verwijderen. In dat geval is het belangrijk om te onthouden dat u alle OSD's moet extraheren op deze server voordat u de server uitschakelt.

Als er geen OSD's meer op deze server zijn, moet na hun verwijdering de OSD-server hv-2, worden uitgesloten met de volgende opdracht:

ceph osd crush rm hv-2

Verwijder mon van de server hv-2, door het onderstaande commando op een andere server uit te voeren (d.w.z. in dit geval - op hv-1):

ceph-deploy mon destroy hv-2

. Na dit kan de server worden gestopt en kan begonnen worden met de volgende stappen (zoals herinstallatie, enz.).

Casus #2. Verdelen van schijfruimte in een reeds gemaakte Ceph-cluster

Ik begin het tweede verhaal met een inleiding over PG (Placement Groups). De belangrijkste rol van PG in Ceph is in de eerste plaats het aggregeren van Ceph-objecten en de daaropvolgende replicatie naar OSD. De formule waarmee je het benodigde aantal PG kunt berekenen, is te vinden in de relevante sectie de documentatie van Ceph. Hier wordt deze kwestie ook behandeld met concrete voorbeelden.

Dus: een van de veel voorkomende problemen tijdens het gebruik van Ceph is een ongebalanceerd aantal OSD en PG tussen de pools in Ceph.

Ten eerste kan hierdoor een situatie ontstaan waarin te veel PG wordt opgegeven in een pool met een klein volume, wat in feite een inefficiënt gebruik van schijfruimte in de cluster is. Ten tweede ontstaat er in de praktijk een ernstiger probleem: datavolume-overbelasting in een van de OSD. Dit leidt er eerst toe dat de cluster in de status HEALTH_WARN, en daarna in HEALTH_ERR. De schuldige is dat Ceph bij het berekenen van de beschikbare datavolume (deze kan worden achterhaald via MAX AVAIL in de uitvoer van het commando ceph df voor elke pool afzonderlijk) vertrouwt op de beschikbare data in OSD. Als er in zelfs maar één OSD onvoldoende ruimte is, kan er geen data meer worden geschreven totdat de data correct zijn verdeeld over alle OSD.

Het is belangrijk op te merken dat deze problemen overwegend worden opgelost tijdens de configuratiefase van de Ceph-cluster.Een van de tools die hiervoor kan worden gebruikt is Ceph PGCalc. Hiermee kan het benodigde aantal PG visueel worden berekend. Echter, dit kan ook worden toegepast in situaties waarin de Ceph-cluster al onjuist is ingesteld. Hierbij is het belangrijk op te merken dat je tijdens de herstelwerkzaamheden waarschijnlijk het aantal PG zult moeten verlagen, en deze mogelijkheid is niet beschikbaar in oudere versies van Ceph (dit kwam pas beschikbaar met versie Nautilus).

Stel je de volgende situatie voor: de cluster heeft de status HEALTH_WARN omdat de ruimte in een van de OSD opraakt. Dit zal worden aangegeven door de foutmelding HEALTH_WARN: 1 near full osd. Hieronder staat een algoritme om uit een dergelijke situatie te komen.

Allereerst moeten we de beschikbare gegevens verdelen over de andere OSD's. Een dergelijke operatie hebben we al uitgevoerd in de eerste case, toen we de knoop "leegmaakten" - met het enige verschil dat we nu een lichte vermindering moeten doorvoeren. herpositioneren. Bijvoorbeeld, tot 0,95:

ceph osd reweight osd.${ID} 0,95

Hierdoor wordt de schijfruimte in de OSD vrijgemaakt en wordt de fout in ceph health gecorrigeerd. Zoals eerder vermeld, ontstaat dit probleem voornamelijk door een onjuiste configuratie van Ceph in de beginfase: het is erg belangrijk om opnieuw te configureren, zodat dit probleem in de toekomst niet optreedt.

In ons specifieke geval was alles gebaseerd op:

een te hoge waarde replication_count in een van de pools,
een te hoog aantal PG in één pool en een te laag aantal in een andere.

Laten we gebruikmaken van de eerder genoemde rekentool. Hierin is duidelijk weergegeven wat je moet invoeren, en in principe is er niets moeilijk aan. Door de vereiste parameters in te voeren, krijgen we de volgende aanbevelingen:

Opmerking: als je een Ceph-cluster vanaf nul configureert, zal een andere nuttige functie van de rekentool het genereren van commando's zijn die de pools vanaf nul met de in de tabel aangegeven parameters zullen maken.

Het laatste kolom helpt je te oriënteren - Suggested PG Count. In ons geval is de tweede ook nuttig, waar de replicatieparameter wordt aangegeven, aangezien we besloten hebben om de replicatiefactor te wijzigen.

Dus, eerst moeten we de replicatieparameters wijzigen - dit moet als eerste worden gedaan, omdat door het verlagen van de factor, we schijfruimte vrijmaken. Tijdens het uitvoeren van het commando kun je merken dat de waarde van de beschikbare schijfruimte toeneemt:

ceph osd pool $pool_name set $replication_size

En na voltooiing wijzigen we de parameterwaarden pg_num en pgp_num het als volgt:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Belangrijk: we moeten in elke pool de aantal PG's zorgvuldig aanpassen en de waarden in andere pools niet wijzigen totdat de waarschuwingen verdwijnen "Degraded data redundancy" en "n-number of pgs degraded".

Je kunt ook de uitvoer van de commando's controleren om te zien of alles succesvol is verlopen ceph health detail en ceph -s.

Case №3. Migratie van een virtuele machine van LVM naar Ceph RBD

In situaties waarin virtuele machines worden gebruikt die zijn geïnstalleerd op gehuurde bare-metal servers, komt vaak de vraag naar voren over een fault-tolerant opslag. En het is ook zeer wenselijk dat er voldoende ruimte in deze opslag is... Een andere veel voorkomende situatie: er is een virtuele machine met lokale opslag op de server en de schijf moet worden uitgebreid, maar er is niets beschikbaar omdat er geen vrij schijfruimte meer op de server is.

Dit probleem kan op verschillende manieren worden opgelost - bijvoorbeeld door migratie naar een andere server (als die beschikbaar is) of door nieuwe schijven aan de server toe te voegen. Maar het is niet altijd mogelijk om dit te doen, daarom kan migratie van LVM naar Ceph een uitstekende oplossing voor dit probleem zijn. Door deze optie te kiezen, vereenvoudigen we ook het verdere migratieproces tussen servers, omdat we de lokale opslag niet van de ene hypervisor naar de andere hoeven te verplaatsen. De enige horde is dat we de VM tijdelijk moeten stoppen tijdens de werkzaamheden.

Als recept voor wat volgt, nemen we een artikel van deze blog, waarvan de instructies in de praktijk zijn getest. Trouwens, daar is ook een manier van migratie zonder downtime beschreven, maar in ons geval was dat gewoon niet nodig, dus hebben we het niet getest. Als dit echter kritisch is voor uw project, horen we graag de resultaten in de opmerkingen.

Laten we beginnen met het praktische gedeelte. In het voorbeeld gebruiken we virsh en dus libvirt. Zorg er eerst voor dat de Ceph-pool, waar de gegevens naar worden gemigreerd, is aangesloten op libvirt:

virsh pool-dumpxml $ceph_pool

In de beschrijving van de pool moeten de verbindingsgegevens naar Ceph staan met de gegevens voor autorisatie.

De volgende stap is dat de LVM-image wordt geconverteerd naar Ceph RBD. De uitvoeringstijd is in de eerste plaats afhankelijk van de grootte van de image:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Na conversie blijft de LVM-image over, die nuttig zal zijn in het geval dat migreren van de VM naar RBD niet mogelijk is en we de wijzigingen moeten terugdraaien. Ook - om snel wijzigingen terug te draaien - maken we een back-up van het configuratiebestand van de virtuele machine:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

… en we zullen het origineel bewerken (vm_name.xml). We zoeken de sectie met de schijfbeschrijving (begint met de regel <disk type='file' device='disk'> en eindigt op </disk>) en we brengen het naar de volgende vorm:

Laten we enkele details bekijken:

In het protocol source wordt het adres naar de opslag in Ceph RBD aangegeven (dit is het adres met de naam van de Ceph-pool en de RBD-image, die in de eerste stap werd gedefinieerd).
In het blok secret wordt het type ceph, evenals de UUID van het geheim voor de verbinding ermee. Zijn uuid kan worden achterhaald met behulp van het commando virsh secret-list.
In het blok host de adressen naar de Ceph-monitors worden aangegeven.

Na het bewerken van het configuratiebestand en het voltooien van de conversie van LVM naar RBD kan het gewijzigde configuratiebestand worden toegepast en kan de virtuele machine worden gestart:

virsh define $vm_name.xml
virsh start $vm_name

Het is tijd om te controleren of de virtuele machine correct is opgestart: dit kan bijvoorbeeld worden gecontroleerd door verbinding te maken via SSH of via virsh.

Als de virtuele machine goed werkt en je geen andere problemen hebt ontdekt, dan kan je de LVM-image verwijderen die niet meer in gebruik is:

lvremove main/$vm_image_name

Conclusie

Al deze situaties zijn we in de praktijk tegengekomen - we hopen dat de instructies ook andere beheerders helpen soortgelijke problemen op te lossen. Als je opmerkingen of andere soortgelijke verhalen hebt uit je ervaring met Ceph - we horen ze graag in de comments!