Ved at bruge Ceph som netværkslager i projekter med forskellig belastning, kan vi støde på forskellige opgaver, der ved første øjekast ikke virker enkle eller trivielle. For eksempel:
- migrering af data fra gammel Ceph til ny med delvis brug af tidligere servere i den nye klynge;
- løsning på problemet med diskpladsallokering i Ceph.
Når vi håndterer sådanne problemer, står vi over for behovet for at fjerne OSD korrekt uden at miste data, hvilket er særligt vigtigt, når vi håndterer store mængder data. Dette vil blive diskuteret i artiklen.
Metoderne beskrevet nedenfor er relevante for enhver version af Ceph. Derudover vil det faktum, at Ceph kan gemme en stor mængde data, blive taget i betragtning: For at forhindre tab af data og andre problemer vil nogle handlinger blive "opdelt" i flere andre.
Forord om OSD
Da to af de tre diskuterede opskrifter er dedikeret til OSD (), inden du dykker ned i den praktiske del - kort om, hvad det er i Ceph, og hvorfor det er så vigtigt.
Først og fremmest skal det siges, at hele Ceph-klyngen består af mange OSD'er. Jo flere der er, jo større er den frie datamængde i Ceph. Det er let at forstå herfra hoved OSD-funktion: Den gemmer Ceph-objektdata på filsystemerne i alle klynge noder og giver netværksadgang til dem (til læsning, skrivning og andre anmodninger).
På samme niveau indstilles replikeringsparametre ved at kopiere objekter mellem forskellige OSD'er. Og her kan du støde på forskellige problemer, hvis løsninger vil blive diskuteret nedenfor.
Sag nr. 1. Sikker fjernelse af OSD fra Ceph cluster uden at miste data
Behovet for at fjerne OSD'en kan være forårsaget af fjernelse af serveren fra klyngen - for eksempel for at erstatte den med en anden server - hvilket er, hvad der skete for os, hvilket gav anledning til at skrive denne artikel. Det ultimative mål med manipulation er således at udtrække alle OSD'er og mons på en given server, så den kan stoppes.
For nemheds skyld og for at undgå en situation, hvor vi, mens vi udfører kommandoer, laver en fejl ved at angive den nødvendige OSD, vil vi indstille en separat variabel, hvis værdi vil være nummeret på den OSD, der skal slettes. Lad os ringe til hende ${ID} — her og nedenfor erstatter en sådan variabel nummeret på den OSD, som vi arbejder med.
Lad os se på tilstanden før arbejdet påbegyndes:
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
For at starte OSD-fjernelse skal du udføre problemfrit reweight på den til nul. På denne måde reducerer vi mængden af data i OSD'en ved at balancere dem med andre OSD'er. For at gøre dette skal du køre følgende kommandoer:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... og så videre indtil nul.
Glat afbalancering påkrævetfor ikke at miste data. Dette gælder især, hvis OSD'en indeholder en stor mængde data. For at sikre, at efter at have udført kommandoerne reweight alt gik godt, du kan fuldføre det ceph -s eller i et separat terminalvindue ceph -w for at observere ændringer i realtid.
Når OSD'en er "tømt", kan du fortsætte med standardhandlingen for at fjerne den. For at gøre dette skal du overføre den ønskede OSD til staten down:
ceph osd down osd.${ID}Lad os "trække" OSD'en ud af klyngen:
ceph osd out osd.${ID}Lad os stoppe OSD-tjenesten og afmontere dens partition i FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Fjern OSD fra :
ceph osd crush remove osd.${ID}Lad os slette OSD-brugeren:
ceph auth del osd.${ID}Og endelig, lad os fjerne selve OSD:
ceph osd rm osd.${ID}Bemærk: Hvis du bruger Ceph Luminous version eller højere, så kan ovenstående OSD-fjernelsestrin reduceres til to kommandoer:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Hvis du, efter at have fuldført de ovenfor beskrevne trin, kører kommandoen ceph osd tree, så skulle det være klart, at på serveren, hvor arbejdet blev udført, er der ikke længere OSD'er, for hvilke ovenstående operationer blev udført:
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
Undervejs skal du bemærke, at Ceph-klyngens tilstand vil gå til HEALTH_WARN, og vi vil også se et fald i antallet af OSD'er og mængden af ledig diskplads.
Det følgende vil beskrive de trin, der kræves, hvis du helt vil stoppe serveren og følgelig fjerne den fra Ceph. I dette tilfælde er det vigtigt at huske det Før du lukker serveren ned, skal du fjerne alle OSD'er på denne server.
Hvis der ikke er flere OSD'er tilbage på denne server, skal du efter at have fjernet dem udelukke serveren fra OSD-kortet hv-2ved at køre følgende kommando:
ceph osd crush rm hv-2
Slet mon fra serveren hv-2ved at køre kommandoen nedenfor på en anden server (dvs. i dette tilfælde på hv-1):
ceph-deploy mon destroy hv-2Herefter kan du stoppe serveren og begynde efterfølgende handlinger (geninstallere den osv.).
Sag nr. 2. Fordeling af diskplads i en allerede oprettet Ceph-klynge
Jeg starter den anden historie med et forord om PG (). Hovedrollen for PG i Ceph er primært at aggregere Ceph-objekter og yderligere replikere dem i OSD. Formlen, med hvilken du kan beregne den nødvendige mængde PG, er i Ceph dokumentation. Dette spørgsmål diskuteres også der med konkrete eksempler.
Så: et af de almindelige problemer ved brug af Ceph er det ubalancerede antal OSD og PG mellem pools i Ceph.
For det første kan der derfor opstå en situation, hvor for mange PG'er er specificeret i en lille pulje, hvilket i det væsentlige er en irrationel brug af diskplads i klyngen. For det andet er der i praksis et mere alvorligt problem: dataoverløb i en af OSD'erne. Dette medfører, at klyngen først overgår til staten HEALTH_WARN, og så HEALTH_ERR. Årsagen til dette er, at Ceph, når man beregner den tilgængelige mængde data (du kan finde ud af det ved MAX AVAIL i kommandoudgangen ceph df for hver pulje separat) er baseret på mængden af tilgængelige data i OSD. Hvis der ikke er plads nok i mindst én OSD, kan der ikke skrives flere data, før dataene er korrekt fordelt blandt alle OSD'er.
Det er værd at præcisere, at disse problemer afgøres stort set på Ceph-klyngekonfigurationsstadiet. Et af de værktøjer du kan bruge er . Med dens hjælp beregnes den nødvendige mængde PG klart. Du kan dog også ty til det i en situation, hvor Ceph-klyngen allerede konfigureret forkert. Det er værd at præcisere her, at som en del af rettelsesarbejdet vil du højst sandsynligt blive nødt til at reducere antallet af PG'er, og denne funktion er ikke tilgængelig i ældre versioner af Ceph (den dukkede kun op i version ).
Så lad os forestille os følgende billede: klyngen har en status HEALTH_WARN på grund af at en af OSD'erne løber tør for plads. Dette vil blive angivet med en fejl HEALTH_WARN: 1 near full osd. Nedenfor er en algoritme til at komme ud af denne situation.
Først og fremmest skal du fordele de tilgængelige data mellem de resterende OSD'er. Vi udførte allerede en lignende operation i det første tilfælde, da vi "drænede" knudepunktet - med den eneste forskel, at nu bliver vi nødt til at reducere lidt reweight. For eksempel op til 0.95:
ceph osd reweight osd.${ID} 0.95Dette frigør diskplads i OSD'en og retter fejlen i ceph-sundhed. Men som allerede nævnt opstår dette problem hovedsageligt på grund af forkert konfiguration af Ceph i de indledende faser: det er meget vigtigt at foretage en omkonfiguration, så den ikke vises i fremtiden.
I vores særlige tilfælde kom det hele til:
- værdi for høj
replication_counti en af bassinerne, - for meget PG i en pulje og for lidt i en anden.
Lad os bruge den allerede nævnte lommeregner. Det viser tydeligt, hvad der skal indtastes, og i princippet er der ikke noget kompliceret. Efter at have indstillet de nødvendige parametre, får vi følgende anbefalinger:
Bemærk: Hvis du opsætter en Ceph-klynge fra bunden, er en anden nyttig funktion af lommeregneren generering af kommandoer, der vil skabe puljer fra bunden med de parametre, der er angivet i tabellen.
Den sidste kolonne hjælper dig med at navigere - Foreslået PG-antal. I vores tilfælde er den anden også nyttig, hvor replikationsparameteren er angivet, da vi besluttede at ændre replikeringsmultiplikatoren.
Så først skal du ændre replikeringsparametrene - dette er værd at gøre først, da vi ved at reducere multiplikatoren frigør diskplads. Når kommandoen udføres, vil du bemærke, at den tilgængelige diskplads vil stige:
ceph osd pool $pool_name set $replication_size
Og efter afslutningen ændrer vi parameterværdierne pg_num и pgp_num som følger:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberDet er vigtigt: vi skal ændre antallet af PG'er sekventielt i hver pulje og ikke ændre værdierne i andre puljer, før advarslerne forsvinder "Forringet dataredundans" и "n-antal sider nedbrudt".
Du kan også kontrollere, at alt gik godt ved hjælp af kommandoudgangene ceph health detail и ceph -s.
Sag nr. 3. Migrering af en virtuel maskine fra LVM til Ceph RBD
I en situation, hvor et projekt bruger virtuelle maskiner installeret på lejede bare-metal-servere, opstår ofte problemet med fejltolerant lagring. Det er også meget ønskeligt, at der er plads nok i dette lager... En anden almindelig situation: der er en virtuel maskine med lokal lagring på serveren, og du skal udvide disken, men der er ingen steder at gå hen, fordi der ikke er nogen ledig diskplads tilbage på serveren.
Problemet kan løses på forskellige måder - for eksempel ved at migrere til en anden server (hvis der er en) eller tilføje nye diske til serveren. Men det er ikke altid muligt at gøre dette, så migrering fra LVM til Ceph kan være en glimrende løsning på dette problem. Ved at vælge denne mulighed forenkler vi også den videre proces med migrering mellem servere, da der ikke er behov for at flytte lokal lagring fra en hypervisor til en anden. Den eneste fangst er, at du bliver nødt til at stoppe VM'en, mens arbejdet udføres.
Følgende opskrift er taget fra , hvis instruktioner er blevet testet i aktion. I øvrigt, metoden til problemfri migration er også beskrevet der, men i vores tilfælde var det simpelthen ikke nødvendigt, så vi tjekkede det ikke. Hvis dette er kritisk for dit projekt, vil vi være glade for at høre om resultaterne i kommentarerne.
Lad os gå videre til den praktiske del. I eksemplet bruger vi virsh og følgelig libvirt. Først skal du sørge for, at Ceph-puljen, som dataene vil blive migreret til, er forbundet til libvirt:
virsh pool-dumpxml $ceph_poolPuljebeskrivelsen skal indeholde tilslutningsdata til Ceph med autorisationsdata.
Det næste trin er, at LVM-billedet konverteres til Ceph RBD. Udførelsestiden afhænger primært af billedets størrelse:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameEfter konverteringen forbliver et LVM-billede, hvilket vil være nyttigt, hvis migreringen af VM'en til RBD mislykkes, og du skal rulle ændringerne tilbage. Lad os også lave en sikkerhedskopi af den virtuelle maskine-konfigurationsfil for hurtigt at kunne rulle ændringer tilbage:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... og rediger originalen (vm_name.xml). Lad os finde en blok med en beskrivelse af disken (starter med linjen <disk type='file' device='disk'> og slutter med </disk>) og reducer det til følgende form:
<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>Lad os se på nogle detaljer:
- Til protokollen
sourceadressen til lageret i Ceph RBD er angivet (dette er adressen, der angiver navnet på Ceph-puljen og RBD-billedet, som blev bestemt i første fase). - I blokken
secrettype er angivetceph, samt UUID for hemmeligheden til at oprette forbindelse til den. Dens uuid kan findes ved hjælp af kommandoenvirsh secret-list. - I blokken
hostadresser til Ceph-skærme er angivet.
Efter at have redigeret konfigurationsfilen og fuldført LVM til RBD-konverteringen, kan du anvende den ændrede konfigurationsfil og starte den virtuelle maskine:
virsh define $vm_name.xml
virsh start $vm_name
Det er tid til at tjekke, at den virtuelle maskine startede korrekt: det kan du f.eks. finde ud af ved at oprette forbindelse til den via SSH eller via virsh.
Hvis den virtuelle maskine fungerer korrekt, og du ikke har fundet andre problemer, kan du slette det LVM-billede, der ikke længere bruges:
lvremove main/$vm_image_nameKonklusion
Vi stødte på alle de beskrevne tilfælde i praksis - vi håber, at instruktionerne vil hjælpe andre administratorer med at løse lignende problemer. Hvis du har kommentarer eller andre lignende historier fra din oplevelse med Ceph, vil vi være glade for at se dem i kommentarerne!
PS
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com