🥇Tips & tricks til arbejde med Ceph i belastede projekter

Ved at bruge Ceph som netværkslagring i forskellige belastningsprojekter kan vi støde på forskellige opgaver, som ved første øjekast ikke synes simple eller trivielle. For eksempel:

migration af data fra gammel Ceph til ny med delvis brug af tidligere servere i den nye klynge;
løsning af problemet med partitionering af diskplads i Ceph.

Når vi beskæftiger os med sådanne opgaver, støder vi på nødvendigheden af korrekt at udtrække OSD uden datatab, hvilket er særligt relevant ved store datamængder. Det handler denne artikel om.

De metoder, der er beskrevet nedenfor, er relevante for alle versioner af Ceph. Derudover vil der blive taget højde for, at Ceph kan opbevare store datamængder: for at forhindre datatab og andre problemer, vil nogle handlinger blive "opdelt" i flere andre.

Forord om OSD

Da to ud af de tre betragtede opskrifter er dedikeret til OSD (Object Storage Daemon), før vi går ind i den praktiske del — kort om, hvad det overhovedet 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 de er, jo større er den frie datamængde i Ceph. Herfra er det let at forstå den primære funktion af OSD: den gemmer Ceph-objekter på filsystemerne på alle nodernes klynge og giver netværksadgang til dem (for læsning, skrivning og andre forespørgsler).

På dette niveau indstilles replikeringsparametrene ved at kopiere objekter mellem forskellige OSD. Og her kan man støde på forskellige problemer, som vi vil tale om nedenfor.

Case Nr. 1. Sikker udtrækning af OSD fra Ceph-klyngen uden datatab.

Nødvendigheden af at udtrække OSD kan være forårsaget af udtrækning af serveren fra klyngen — for eksempel til udskiftning med en anden server, — som skete for os, hvilket blev grundlaget for at skrive artiklen. Således er det endelige mål med manipulationerne at udtrække alle OSD'er og mon'er på denne server, så den kan stoppes.

For bekvemmelighedens skyld og for at undgå en situation, hvor vi i løbet af kommandokørslen laver fejl med at angive den nødvendige OSD, lad os definere en separat variabel, hvis værdi vil være nummeret på den OSD, der skal fjernes. Lad os kalde den ${ID} — her og fremover erstatter en sådan variabel nummeret på den OSD, vi arbejder med.

Lad os se på tilstanden før påbegyndelse af arbejdet:

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     op     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     op     1.00000  1.00000

For at starte sletningen af OSD, skal vi gradvist reweight den til nul. På den måde reducerer vi mængden af data i OSD ved at balancere til andre OSD. For dette udføres 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 ned til nul.

Gradvis balancering er nødvendig, for ikke at miste data. Dette er især relevant, hvis OSD indeholder en stor mængde data. For at være sikker på, at efter udførelsen af kommandoerne reweight det hele er gået godt, kan man udføre ceph -s eller i et separat terminalvindue starte ceph -w for at overvåge ændringer i realtid.

Når OSD er "tømt", kan vi påbegynde den standardoperation, der kræves for at slette den. For at gøre dette vil vi sætte den ønskede OSD i tilstanden down:

ceph osd down osd.${ID}

"Tage" OSD ud af klyngen:

ceph osd out osd.${ID}

Stoppe OSD-tjenesten og afmontere dens partition i FS:

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

Fjerne OSD fra CRUSH-kortet:

ceph osd crush remove osd.${ID}

Fjerne OSD-brugeren:

ceph auth del osd.${ID}

Og til sidst fjerne selve OSD:

ceph osd rm osd.${ID}

Bemærk: Hvis du bruger Ceph Luminous-versionen eller højere, kan de ovenfor beskrevne skridt for at slette OSD reduceres til to kommandoer:

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

Hvis du efter at have udført de beskrevne skridt udfører kommandoen ceph osd tree, skal du kunne se, at der ikke længere er OSD på serveren, hvor arbejdet blev udført, for hvilke operationer ovenfor 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    op     1.00000  1.00000

Samtidig bemærker vi, at tilstanden af Ceph-klyngen vil ændre sig til HEALTH_WARN, og vi vil også se en reduktion i antallet af OSD og den tilgængelige diskplads.

Dernæst vil jeg beskrive de handlinger, der er nødvendige, hvis du ønsker at stoppe serveren helt og dermed fjerne den fra Ceph. I så fald er det vigtigt at huske, at før serveren slås fra, skal alle OSD på denne server fjernes.

Hvis der ikke længere er OSD tilbage på denne server, skal serveren derefter undgås fra OSD-kortet hv-2, ved at udføre følgende kommando:

ceph osd crush rm hv-2

Fjerne mon fra serveren hv-2, ved at køre kommandoen nedenfor på en anden server (dvs. i dette tilfælde — på hv-1):

ceph-deploy mon destroy hv-2

Efter dette kan serveren stoppe, og man kan gå videre til de næste skridt (som genudrulning osv.).

Case nr. 2. Fordeling af diskplads i et allerede oprettet Ceph-kluster

Den anden historie begynder med en introduktion til PG (Placement Groups). Den primære rolle af PG i Ceph er først og fremmest at aggregere Ceph-objekter og efterfølgende replikere dem i OSD. Formlen, som bruges til at beregne det nødvendige antal PG, findes i den relevante sektion af Ceph-dokumentationen. Her bliver spørgsmålet også behandlet med konkrete eksempler.

Så: et af de almindelige problemer under driften af Ceph er, at antallet af OSD og PG er ubalanceret mellem puljerne i Ceph.

For det første kan det føre til en situation, hvor der angives for mange PG i en lille pulje, hvilket i princippet er en irrationel udnyttelse af diskpladsen i klustret. For det andet opstår der i praksis et mere alvorligt problem: overbelastning af data i et af OSD'erne. Dette medfører, at klustret først går ind i tilstanden HEALTH_WARN, og derefter HEALTH_ERR. Årsagen til dette er, at Ceph ved beregning af den tilgængelige datamængde (den kan findes ved at bruge MAX AVAIL i udgangen af kommandoen ceph df for hver pulje individuelt) baserer sig på mængden af tilgængelige data i OSD. Hvis der i et OSD ikke er tilstrækkelig plads, kan der ikke skrives flere data, før dataene er fordelt korrekt mellem alle OSD.

Det er værd at præcisere, at disse problemer i højere grad løses i konfigurationsfasen af Ceph-klusteret. Et af de værktøjer, man kan bruge, er Ceph PGCalc. Med det kan man visuelt beregne det nødvendige antal PG. I øvrigt kan man også ty til det i situationer, hvor Ceph-klusteret allerede er konfigureret forkert. Her skal det præciseres, at i forbindelse med arbejdet med at rette problemerne, vil det højst sandsynligt være nødvendigt at reducere antallet af PG, men denne mulighed er ikke tilgængelig i gamle versioner af Ceph (den kom først med version Nautilus).

Forestil dig nu følgende billede: klusteret har en status HEALTH_WARN fordi der i en af OSD'erne er ved at være plads. Dette vil blive indikeret ved fejlen HEALTH_WARN: 1 near full osd. Nedenfor er algoritmen for at komme ud af en sådan situation.

Først og fremmest skal de nuværende data fordeles mellem de resterende OSD. Denne operation har vi allerede udført i det første tilfælde, da vi "tømte" noden - med den eneste forskel, at vi nu skal reducere en smule. reweight. For eksempel til 0.95:

ceph osd reweight osd.${ID} 0.95

Dette frigør diskplads i OSD og retter fejlen i ceph health. Men som tidligere nævnt opstår dette problem hovedsageligt på grund af forkert konfiguration af Ceph i de tidlige faser: det er meget vigtigt at foretage en rekonstruktion, så det ikke viser sig i fremtiden.

I vores specifikke tilfælde handlede det om:

for stort et værdi replication_count i en af puljerne,
for højt antal PG i en pulje og for lavt - i en anden.

Lad os bruge den allerede nævnte kalkulator. Den viser tydeligt, hvad der skal indtastes, og der er i princippet ikke noget kompliceret ved det. Ved at angive de nødvendige parametre får vi følgende anbefalinger:

Bemærk: hvis du konfigurerer et Ceph-cluster fra bunden, vil en anden nyttig funktion i kalkulatoren være genereringen af kommandoer, der opretter puljer fra bunden med de parametre, der er angivet i tabellen.

Det sidste kolonne hjælper med orienteringen - Suggested PG Count. I vores tilfælde er den anden også nyttig, hvor replikeringsparameteren er angivet, da vi har besluttet at ændre og replikeringsfaktoren.

Så først skal vi ændre replikeringsparametrene - dette bør gøres først, da vi ved at reducere faktoren frigør diskplads. Under udførelsen af kommandoen kan det bemærkes, at værdien af den tilgængelige diskplads vil stige:

ceph osd pool $pool_name set $replication_size

Og efter at den er afsluttet - ændrer vi værdierne af parametrene pg_num og pgp_num som følger:

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

Det er vigtigt: vi skal sekventielt ændre antallet af PG i hver pulje og ikke ændre værdierne i andre puljer, indtil advarslerne forsvinder «Degraded data redundancy» og «n-number of pgs degraded».

For at kontrollere, at alt er gået godt, kan man også se på output fra kommandoerne ceph health detail og ceph -s.

Case nr. 3. Migration af virtuel maskine fra LVM til Ceph RBD

I situationer, hvor der anvendes virtuelle maskiner, der er installeret på leasede bare-metal servere, opstår ofte spørgsmålet om fejltolerance lager. Og det er også meget ønskeligt, at der er tilstrækkelig plads i dette lager… En anden almindelig situation er, at der er en virtuel maskine med lokalt lager på serveren, og det er nødvendigt at udvide diskens størrelse, men der er ikke plads, da der ikke er ledig diskplads på serveren.

Problemet kan løses på forskellige måder — for eksempel ved at migrere til en anden server (hvis en sådan findes) eller ved at tilføje nye diske til serveren. Men det er ikke altid muligt, så migration fra LVM til Ceph kan være en fremragende løsning på dette problem. Ved at vælge denne mulighed forenkler vi også den videre migrationsproces mellem serverne, da det ikke vil være nødvendigt at flytte det lokale lager fra en hypervisor til en anden. Den eneste hage er, at det bliver nødvendigt at stoppe VM'en i løbet af arbejdet.

Som det følgende opskrift er der taget en artikel fra denne blog, hvis instruktioner er blevet afprøvet i praksis. Forresten, er der også beskrevet en metode til migrations uden nedetid, men i vores tilfælde var det simpelthen ikke nødvendigt, så vi har ikke testet det. Hvis dette er kritisk for dit projekt, ville vi være glade for at høre om resultaterne i kommentarerne.

Lad os gå i gang med den praktiske del. I eksemplet bruger vi virsh og dermed libvirt. Først skal du sikre dig, at Ceph-poolen, hvortil dataene vil blive migreret, er tilsluttet libvirt:

virsh pool-dumpxml $ceph_pool

I beskrivelsen af poolen skal der være forbindelsesdata til Ceph med autentificeringsoplysninger.

Det næste trin indebærer, at LVM-billedet konverteres til Ceph RBD. Udførelsestiden afhænger primært af størrelsen på billedet:

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

Efter konverteringen vil der være et LVM-billede tilbage, hvilket vil være nyttigt, hvis det ikke lykkes at migrere VM'en til RBD, og ændringerne skal rulles tilbage. Derudover — for at kunne rulle ændringer hurtigt tilbage — vil vi tage en backup af konfigurationsfilen for den virtuelle maskine:

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

… og redigere originalen (vm_name.xml). Vi finder blokken med beskrivelsen af disken (den begynder med linjen <disk type='file' device='disk'> og slutter med </disk>) og bringe det til følgende form:

Lad os se på nogle detaljer:

I protokollen source angives adressen til lageret i Ceph RBD (dette er adressen med angivelse af navnet på Ceph-poolen og RBD-igenstanden, som blev defineret i det første trin).
I blokken hemmelig angives typen ceph, samt UUID'et for hemmeligheden til at oprette forbindelse til den. Dens uuid kan findes ved at bruge kommandoen virsh secret-list.
I blokken host opgives adresserne til Ceph-moniitorerne.

Efter redigering af konfigurationsfilen og afslutning af konverteringen fra LVM til RBD kan den ændrede konfigurationsfil anvendes og den virtuelle maskine startes:

virsh define $vm_name.xml
virsh start $vm_name

Det er nu tid til at tjekke, om den virtuelle maskine startede korrekt: det kan f.eks. gøres ved at oprette forbindelse via SSH eller gennem virsh.

Hvis den virtuelle maskine fungerer korrekt, og du ikke har opdaget andre problemer, kan LVM-igenstanden, som ikke længere bruges, slettes:

lvremove main/$vm_image_name

Konklusion

Vi har stødt 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 erfaringen med Ceph — vil vi være glade for at se dem i kommentarerne!