Als we Ceph gebruiken als netwerkopslag in projecten met verschillende belastingen, kunnen we verschillende taken tegenkomen die op het eerste gezicht niet eenvoudig of triviaal lijken. Bijvoorbeeld:
- migratie van gegevens van de oude Ceph naar de nieuwe met gedeeltelijk gebruik van eerdere servers in het nieuwe cluster;
- oplossing voor het probleem van de toewijzing van schijfruimte in Ceph.
Bij het omgaan met dergelijke problemen worden we geconfronteerd met de noodzaak om de OSD correct te verwijderen zonder gegevens te verliezen, wat vooral belangrijk is bij het omgaan met grote hoeveelheden gegevens. Dit zal in het artikel worden besproken.
De hieronder beschreven methoden zijn relevant voor elke versie van Ceph. Bovendien zal er rekening mee worden gehouden dat Ceph een grote hoeveelheid gegevens kan opslaan: om gegevensverlies en andere problemen te voorkomen, zullen sommige acties in verschillende andere worden “opgesplitst”.
Voorwoord over OSD
Aangezien twee van de drie besproken recepten gewijd zijn aan OSD (), voordat we ingaan op het praktische gedeelte - kort over wat het in Ceph is en waarom het zo belangrijk is.
Allereerst moet worden gezegd dat het hele Ceph-cluster uit veel OSD's bestaat. Hoe meer er zijn, hoe groter het gratis datavolume in Ceph. Vanaf hier is het gemakkelijk te begrijpen belangrijkste OSD-functie: Het slaat Ceph-objectgegevens op de bestandssystemen van alle clusterknooppunten op en biedt er netwerktoegang toe (voor lezen, schrijven en andere verzoeken).
Op hetzelfde niveau worden replicatieparameters ingesteld door objecten tussen verschillende OSD's te kopiëren. En hier kunt u verschillende problemen tegenkomen, waarvan de oplossingen hieronder worden besproken.
Zaak nr. 1. Verwijder veilig OSD uit het Ceph-cluster zonder gegevensverlies
De noodzaak om de OSD te verwijderen kan worden veroorzaakt door het verwijderen van de server uit het cluster (bijvoorbeeld door deze te vervangen door een andere server), wat bij ons is gebeurd en aanleiding gaf tot het schrijven van dit artikel. Het uiteindelijke doel van manipulatie is dus om alle OSD's en mons op een bepaalde server te extraheren, zodat deze kunnen worden gestopt.
Voor het gemak en om te voorkomen dat we bij het uitvoeren van opdrachten een fout maken bij het aangeven van de vereiste OSD, zullen we een afzonderlijke variabele instellen, waarvan de waarde het nummer is van de OSD die moet worden verwijderd. Laten we haar bellen ${ID} — hier en hieronder vervangt zo'n variabele het nummer van de OSD waarmee we werken.
Laten we eens kijken naar de toestand voordat we met het werk beginnen:
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-verwijdering te starten, moet u dit soepel uitvoeren reweight erop naar nul. Op deze manier verminderen we de hoeveelheid gegevens in de OSD door deze te balanceren met andere OSD's. Om dit te doen, voert u de volgende opdrachten uit:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... enzovoort tot nul.
Soepel balanceren vereistom geen gegevens te verliezen. Dit geldt vooral als het OSD een grote hoeveelheid gegevens bevat. Om ervoor te zorgen dat na het uitvoeren van de opdrachten reweight alles is goed gegaan, je kunt het voltooien ceph -s of in een afzonderlijk terminalvenster ceph -w om veranderingen in realtime waar te nemen.
Wanneer de OSD “leeg” is, kunt u doorgaan met de standaardhandeling om deze te verwijderen. Om dit te doen, brengt u de gewenste OSD over naar de staat down:
ceph osd down osd.${ID}Laten we de OSD uit het cluster halen:
ceph osd out osd.${ID}Laten we de OSD-service stoppen en de partitie in de FS ontkoppelen:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Verwijder OSD uit :
ceph osd crush remove osd.${ID}Laten we de OSD-gebruiker verwijderen:
ceph auth del osd.${ID}En tot slot, laten we de OSD zelf verwijderen:
ceph osd rm osd.${ID}Noot: Als u de Ceph Luminous-versie of hoger gebruikt, kunnen de bovenstaande OSD-verwijderingsstappen worden teruggebracht tot twee opdrachten:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Als u, na het voltooien van de hierboven beschreven stappen, de opdracht uitvoert ceph osd tree, dan moet het duidelijk zijn dat er op de server waar de werkzaamheden zijn uitgevoerd geen OSD's meer aanwezig zijn waarvoor 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 onderweg op dat de toestand van het Ceph-cluster zal veranderen HEALTH_WARN, en we zullen ook een afname zien in het aantal OSD's en de hoeveelheid beschikbare schijfruimte.
Hieronder worden de stappen beschreven die nodig zijn als u de server volledig wilt stoppen en dienovereenkomstig van Ceph wilt verwijderen. In dit geval is het belangrijk om dat te onthouden Voordat u de server afsluit, moet u alle OSD's verwijderen op deze server.
Als er geen OSD's meer op deze server staan, moet u na het verwijderen ervan de server uitsluiten van de OSD-kaart hv-2door het volgende commando uit te voeren:
ceph osd crush rm hv-2
Verwijderen mon van de server hv-2door de onderstaande opdracht uit te voeren op een andere server (in dit geval dus on hv-1):
ceph-deploy mon destroy hv-2Hierna kunt u de server stoppen en daaropvolgende acties starten (opnieuw implementeren, enz.).
Zaak nr. 2. Verdeling van schijfruimte in een reeds aangemaakt Ceph-cluster
Ik begin het tweede verhaal met een voorwoord over PG (). De belangrijkste rol van PG in Ceph is voornamelijk het aggregeren van Ceph-objecten en deze verder te repliceren in OSD. De formule waarmee je de benodigde hoeveelheid PG kunt berekenen, staat erin Ceph-documentatie. Ook dit onderwerp wordt daar besproken met concrete voorbeelden.
Dus: een van de meest voorkomende problemen bij het gebruik van Ceph is het onevenwichtige aantal OSD en PG tussen pools in Ceph.
Ten eerste kan hierdoor een situatie ontstaan waarin te veel PG's in een kleine pool worden gespecificeerd, wat in wezen een irrationeel gebruik van schijfruimte in het cluster is. Ten tweede is er in de praktijk een ernstiger probleem: dataoverflow in een van de OSD's. Dit houdt in dat het cluster eerst overgaat naar de status HEALTH_WARN, en dan HEALTH_ERR. De reden hiervoor is dat Ceph bij het berekenen van de beschikbare hoeveelheid gegevens (je kunt dit achterhalen door MAX AVAIL in de opdrachtuitvoer ceph df voor elke pool afzonderlijk) is gebaseerd op de hoeveelheid beschikbare gegevens in de OSD. Als er niet voldoende ruimte is in ten minste één OSD, kunnen er geen gegevens meer worden geschreven totdat de gegevens correct zijn verdeeld over alle OSD's.
Het is de moeite waard om te verduidelijken dat deze problemen bestaan worden grotendeels beslist in de Ceph-clusterconfiguratiefase. Een van de hulpmiddelen die u kunt gebruiken is . Met zijn hulp wordt de benodigde hoeveelheid PG duidelijk berekend. U kunt er echter ook uw toevlucht toe nemen in een situatie waarin de Ceph-cluster reeds verkeerd geconfigureerd. Het is de moeite waard hier te verduidelijken dat je als onderdeel van het herstelwerk hoogstwaarschijnlijk het aantal PG's moet verminderen, en deze functie is niet beschikbaar in oudere versies van Ceph (deze verscheen alleen in versie ).
Laten we ons dus het volgende beeld voorstellen: het cluster heeft een status HEALTH_WARN omdat een van de OSD's onvoldoende ruimte heeft. Dit wordt aangegeven door een fout HEALTH_WARN: 1 near full osd. Hieronder vindt u een algoritme om uit deze situatie te komen.
Allereerst moet u de beschikbare gegevens verdelen over de resterende OSD's. We hebben in het eerste geval al een soortgelijke operatie uitgevoerd, toen we het knooppunt "leegmaakten" - met het enige verschil dat we nu iets moeten verkleinen reweight. Tot 0.95 bijvoorbeeld:
ceph osd reweight osd.${ID} 0.95Dit maakt schijfruimte vrij in het OSD en verhelpt de fout in de ceph-gezondheid. Zoals eerder vermeld, treedt dit probleem echter voornamelijk op als gevolg van een onjuiste configuratie van Ceph in de beginfase: het is erg belangrijk om een herconfiguratie uit te voeren zodat deze in de toekomst niet verschijnt.
In ons specifieke geval kwam het allemaal neer op:
- waarde te hoog
replication_countin een van de zwembaden, - te veel PG in het ene zwembad en te weinig in het andere.
Laten we de reeds genoemde rekenmachine gebruiken. Er staat duidelijk in wat er moet worden ingevoerd en er is in principe niets ingewikkelds aan. Nadat we de noodzakelijke parameters hebben ingesteld, krijgen we de volgende aanbevelingen:
Noot: Als u een Ceph-cluster helemaal opnieuw opzet, is een andere nuttige functie van de rekenmachine het genereren van opdrachten die helemaal opnieuw pools creëren met de parameters die in de tabel zijn gespecificeerd.
De laatste kolom helpt u bij het navigeren - Aanbevolen PG-telling. In ons geval is de tweede ook nuttig, waar de replicatieparameter wordt aangegeven, omdat we besloten hebben de replicatievermenigvuldiger te wijzigen.
Dus eerst moet je de replicatieparameters wijzigen - dit is de moeite waard om eerst te doen, omdat we door het verminderen van de vermenigvuldiger schijfruimte vrijmaken. Terwijl de opdracht wordt uitgevoerd, zult u merken dat de beschikbare schijfruimte toeneemt:
ceph osd pool $pool_name set $replication_size
En na voltooiing veranderen we de parameterwaarden pg_num и pgp_num следующим обрахом:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberHet is belangrijk: we moeten het aantal PG's in elke pool opeenvolgend veranderen en de waarden in andere pools niet veranderen totdat de waarschuwingen verdwijnen "Verslechterde gegevensredundantie" и "n-aantal pgs verslechterd".
U kunt ook controleren of alles goed is gegaan met behulp van de opdrachtuitvoer ceph health detail и ceph -s.
Zaak nr. 3. Een virtuele machine migreren van LVM naar Ceph RBD
In een situatie waarin een project virtuele machines gebruikt die zijn geïnstalleerd op gehuurde bare-metal-servers, doet zich vaak het probleem van fouttolerante opslag voor. Het is ook zeer wenselijk dat er voldoende ruimte is in deze opslag... Een andere veel voorkomende situatie: er staat een virtuele machine met lokale opslag op de server en je moet de schijf uitbreiden, maar je kunt nergens heen, want er is geen vrije schijfruimte op de server.
Het probleem kan op verschillende manieren worden opgelost, bijvoorbeeld door naar een andere server te migreren (als die er is) of door nieuwe schijven aan de server toe te voegen. Maar het is niet altijd mogelijk om dit te doen, dus migreren van LVM naar Ceph kan een uitstekende oplossing voor dit probleem zijn. Door voor deze optie te kiezen, vereenvoudigen we ook het verdere migratieproces tussen servers, omdat het niet nodig is om lokale opslag van de ene hypervisor naar de andere te verplaatsen. Het enige probleem is dat u de VM moet stoppen terwijl het werk wordt uitgevoerd.
Het volgende recept is afkomstig van , waarvan de instructies in actie zijn getest. Trouwens, ook de werkwijze voor een probleemloze migratie wordt daar beschrevenIn ons geval was het echter simpelweg niet nodig, dus we hebben het niet gecontroleerd. Als dit van cruciaal belang is voor uw project, horen we graag de resultaten in de opmerkingen.
Laten we verder gaan met het praktische gedeelte. In het voorbeeld gebruiken we virsh en dienovereenkomstig libvirt. Zorg er eerst voor dat de Ceph-pool waarnaar de gegevens zullen worden gemigreerd, is verbonden met libvirt:
virsh pool-dumpxml $ceph_poolDe zwembadbeschrijving moet verbindingsgegevens met Ceph met autorisatiegegevens bevatten.
De volgende stap is dat het LVM-beeld wordt geconverteerd naar Ceph RBD. De uitvoeringstijd hangt voornamelijk af van de grootte van de afbeelding:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameNa de conversie blijft er een LVM-image achter, wat handig kan zijn als het migreren van de VM naar RBD mislukt en u de wijzigingen moet terugdraaien. Om de wijzigingen snel terug te kunnen draaien, maken we ook 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 bewerk het origineel (vm_name.xml). Laten we een blok zoeken met een beschrijving van de schijf (begint met de regel <disk type='file' device='disk'> en eindigt met </disk>) en reduceer het tot de volgende vorm:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Laten we eens kijken naar enkele details:
- Naar het protocol
sourcehet adres naar de opslag in Ceph RBD wordt aangegeven (dit is het adres dat de naam van de Ceph-pool en het RBD-beeld aangeeft, dat in de eerste fase werd bepaald). - In het blok
secretsoort is aangegevenceph, evenals de UUID van het geheim om er verbinding mee te maken. De uuid kan worden gevonden met behulp van de opdrachtvirsh secret-list. - In het blok
hostadressen voor Ceph-monitoren worden aangegeven.
Nadat u het configuratiebestand hebt bewerkt en de conversie van LVM naar RBD hebt voltooid, kunt u het gewijzigde configuratiebestand toepassen en de virtuele machine starten:
virsh define $vm_name.xml
virsh start $vm_name
Het is tijd om te controleren of de virtuele machine correct is gestart: u kunt dit bijvoorbeeld achterhalen door er verbinding mee te maken via SSH of via virsh.
Als de virtuele machine correct werkt en u geen andere problemen heeft gevonden, kunt u de LVM-image verwijderen die niet langer wordt gebruikt:
lvremove main/$vm_image_nameConclusie
We zijn alle beschreven gevallen in de praktijk tegengekomen - we hopen dat de instructies andere beheerders zullen helpen soortgelijke problemen op te lossen. Als u opmerkingen of andere soortgelijke verhalen heeft over uw ervaring met het gebruik van Ceph, zien we deze graag in de opmerkingen terug!
PS
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com