Ved å bruke Ceph som nettverkslagring i prosjekter med ulik belastning, kan vi møte ulike oppgaver som ved første øyekast ikke virker enkle eller trivielle. For eksempel:
- migrering av data fra gammel Ceph til ny med delvis bruk av tidligere servere i den nye klyngen;
- løsning på problemet med tildeling av diskplass i Ceph.
Når vi håndterer slike problemer, står vi overfor behovet for å fjerne OSD-en på riktig måte uten å miste data, noe som er spesielt viktig når vi arbeider med store datamengder. Dette vil bli diskutert i artikkelen.
Metodene beskrevet nedenfor er relevante for alle versjoner av Ceph. I tillegg vil det tas hensyn til at Ceph kan lagre en stor mengde data: for å forhindre tap av data og andre problemer, vil noen handlinger bli "delt" i flere andre.
Forord om OSD
Siden to av de tre oppskriftene som er diskutert er dedikert til OSD (), før du dykker ned i den praktiske delen - kort om hva det er i Ceph og hvorfor det er så viktig.
Først av alt skal det sies at hele Ceph-klyngen består av mange OSD-er. Jo flere det er, jo større er ledig datavolumet i Ceph. Det er lett å forstå herfra hoved OSD-funksjon: Den lagrer Ceph-objektdata på filsystemene til alle klyngenoder og gir nettverkstilgang til den (for lesing, skriving og andre forespørsler).
På samme nivå settes replikeringsparametere ved å kopiere objekter mellom forskjellige OSD-er. Og her kan du støte på forskjellige problemer, løsningene som vil bli diskutert nedenfor.
Sak nr. 1. Fjern OSD trygt fra Ceph-klyngen uten å miste data
Behovet for å fjerne OSD-en kan være forårsaket av å fjerne serveren fra klyngen - for eksempel for å erstatte den med en annen server - som er det som skjedde med oss, og ga opphav til skrivingen av denne artikkelen. Dermed er det endelige målet med manipulasjon å trekke ut alle OSD-er og mons på en gitt server slik at den kan stoppes.
For enkelhets skyld og for å unngå en situasjon der vi, mens vi utfører kommandoer, gjør en feil ved å angi ønsket OSD, vil vi sette en separat variabel, hvis verdi vil være nummeret på OSD som skal slettes. La oss ringe henne ${ID} — her og nedenfor erstatter en slik variabel nummeret på OSD-en vi jobber med.
La oss se på tilstanden før du starter arbeidet:
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 å starte OSD-fjerning, må du utføre jevnt arbeid reweight på den til null. På denne måten reduserer vi mengden data i OSD-en ved å balansere den til andre OSD-er. For å gjøre dette, kjør 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 til null.
Glatt balansering krevesfor ikke å miste data. Dette gjelder spesielt hvis OSD-en inneholder en stor mengde data. For å sikre at etter å ha utført kommandoene reweight alt gikk bra, du kan fullføre det ceph -s eller i en separat terminalvindukjøring ceph -w for å observere endringer i sanntid.
Når OSD er "tømt", kan du fortsette med standardoperasjonen for å fjerne den. For å gjøre dette, overfør ønsket OSD til staten down:
ceph osd down osd.${ID}La oss "trekke" OSD ut av klyngen:
ceph osd out osd.${ID}La oss stoppe OSD-tjenesten og avmontere partisjonen i FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Fjern OSD fra :
ceph osd crush remove osd.${ID}La oss slette OSD-brukeren:
ceph auth del osd.${ID}Og til slutt, la oss fjerne selve OSD:
ceph osd rm osd.${ID}Note: Hvis du bruker Ceph Luminous versjon eller høyere, kan trinnene ovenfor for fjerning av OSD reduseres til to kommandoer:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Hvis du, etter å ha fullført trinnene beskrevet ovenfor, kjører kommandoen ceph osd tree, så bør det være klart at på serveren der arbeidet ble utført er det ikke lenger OSD-er som de ovennevnte operasjonene ble utført for:
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
Underveis, merk at tilstanden til Ceph-klyngen vil gå til HEALTH_WARN, og vi vil også se en nedgang i antall OSD-er og mengden tilgjengelig diskplass.
Følgende vil beskrive trinnene som vil være nødvendige hvis du vil stoppe serveren fullstendig og følgelig fjerne den fra Ceph. I dette tilfellet er det viktig å huske det Før du slår av serveren, må du fjerne alle OSD-er på denne serveren.
Hvis det ikke er flere OSD-er igjen på denne serveren, må du ekskludere serveren fra OSD-kartet etter å ha fjernet dem hv-2ved å kjøre følgende kommando:
ceph osd crush rm hv-2
Slett mon fra serveren hv-2ved å kjøre kommandoen nedenfor på en annen server (dvs. i dette tilfellet på hv-1):
ceph-deploy mon destroy hv-2Etter dette kan du stoppe serveren og begynne påfølgende handlinger (re-distribuere den osv.).
Sak nr. 2. Distribusjon av diskplass i en allerede opprettet Ceph-klynge
Jeg starter den andre historien med et forord om PG (). Hovedrollen til PG i Ceph er først og fremst å samle Ceph-objekter og replikere dem ytterligere i OSD. Formelen som du kan beregne den nødvendige mengden PG med, er i Ceph dokumentasjon. Denne problemstillingen diskuteres også der med konkrete eksempler.
Så: et av de vanlige problemene ved bruk av Ceph er det ubalanserte antallet OSD og PG mellom bassengene i Ceph.
For det første, på grunn av dette, kan det oppstå en situasjon når for mange PG-er er spesifisert i et lite basseng, som i hovedsak er en irrasjonell bruk av diskplass i klyngen. For det andre er det i praksis et mer alvorlig problem: dataoverflyt i en av OSD-ene. Dette innebærer at klyngen først går over til staten HEALTH_WARN, og så HEALTH_ERR. Grunnen til dette er at Ceph, når du beregner den tilgjengelige mengden data (du kan finne det ut av MAX AVAIL i kommandoutgangen ceph df for hver gruppe separat) er basert på mengden tilgjengelige data i OSD. Hvis det ikke er nok plass i minst én OSD, kan ikke flere data skrives før dataene er riktig fordelt mellom alle OSD-er.
Det er verdt å presisere at disse problemene avgjøres i stor grad på Ceph-klyngekonfigurasjonsstadiet. Et av verktøyene du kan bruke er . Med dens hjelp beregnes den nødvendige mengden PG tydelig. Du kan imidlertid også ty til det i en situasjon hvor Ceph-klyngen allerede konfigurert feil. Det er verdt å presisere her at som en del av reparasjonsarbeidet vil du mest sannsynlig trenge å redusere antall PG-er, og denne funksjonen er ikke tilgjengelig i eldre versjoner av Ceph (den dukket bare opp i versjon ).
Så la oss forestille oss følgende bilde: klyngen har en status HEALTH_WARN på grunn av at en av OSD-ene går tom for plass. Dette vil bli indikert med en feil HEALTH_WARN: 1 near full osd. Nedenfor er en algoritme for å komme ut av denne situasjonen.
Først av alt må du fordele de tilgjengelige dataene mellom de gjenværende OSD-ene. Vi utførte allerede en lignende operasjon i det første tilfellet, da vi "tømte" noden - med den eneste forskjellen at nå må vi redusere litt reweight. For eksempel opptil 0.95:
ceph osd reweight osd.${ID} 0.95Dette frigjør diskplass i OSD-en og fikser feilen i ceph-helse. Men som allerede nevnt, oppstår dette problemet hovedsakelig på grunn av feil konfigurasjon av Ceph i de innledende stadiene: det er veldig viktig å foreta en rekonfigurasjon slik at den ikke vises i fremtiden.
I vårt spesielle tilfelle kom alt ned til:
- verdi for høy
replication_counti et av bassengene, - for mye PG i ett basseng og for lite i et annet.
La oss bruke den allerede nevnte kalkulatoren. Det viser tydelig hva som må legges inn, og i prinsippet er det ikke noe komplisert. Etter å ha satt de nødvendige parameterne, får vi følgende anbefalinger:
Note: Hvis du setter opp en Ceph-klynge fra bunnen av, er en annen nyttig funksjon av kalkulatoren generering av kommandoer som vil lage bassenger fra bunnen av med parameterne spesifisert i tabellen.
Den siste kolonnen hjelper deg med å navigere - Foreslått antall PG. I vårt tilfelle er den andre også nyttig, der replikeringsparameteren er indikert, siden vi bestemte oss for å endre replikeringsmultiplikatoren.
Så først må du endre replikeringsparametrene - dette er verdt å gjøre først, siden ved å redusere multiplikatoren vil vi frigjøre diskplass. Når kommandoen kjøres, vil du legge merke til at tilgjengelig diskplass vil øke:
ceph osd pool $pool_name set $replication_size
Og etter at den er fullført, endrer vi parameterverdiene 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 viktig: vi må endre antall PG-er sekvensielt i hver pool og ikke endre verdiene i andre bassenger før advarslene forsvinner "Degradert dataredundans" и "n-antall sider degradert".
Du kan også sjekke at alt gikk bra ved å bruke kommandoutgangene ceph health detail и ceph -s.
Sak nr. 3. Migrering av en virtuell maskin fra LVM til Ceph RBD
I en situasjon der et prosjekt bruker virtuelle maskiner installert på leide bare-metal-servere, oppstår ofte problemet med feiltolerant lagring. Det er også veldig ønskelig at det er nok plass i denne lagringen... En annen vanlig situasjon: det er en virtuell maskin med lokal lagring på serveren og du må utvide disken, men det er ingen steder å gå, fordi det er ingen ledig diskplass igjen på serveren.
Problemet kan løses på forskjellige måter - for eksempel ved å migrere til en annen server (hvis det er en) eller legge til nye disker på serveren. Men det er ikke alltid mulig å gjøre dette, så migrering fra LVM til Ceph kan være en utmerket løsning på dette problemet. Ved å velge dette alternativet forenkler vi også den videre prosessen med migrering mellom servere, siden det ikke vil være behov for å flytte lokal lagring fra en hypervisor til en annen. Den eneste haken er at du må stoppe VM mens arbeidet utføres.
Følgende oppskrift er hentet fra , hvis instruksjoner er testet i bruk. Forresten, metoden for problemfri migrering er også beskrevet der, men i vårt tilfelle var det rett og slett ikke nødvendig, så vi sjekket det ikke. Hvis dette er kritisk for prosjektet ditt, vil vi gjerne høre om resultatene i kommentarfeltet.
La oss gå videre til den praktiske delen. I eksemplet bruker vi virsh og følgelig libvirt. Først må du sørge for at Ceph-bassenget som dataene skal migreres til er koblet til libvirt:
virsh pool-dumpxml $ceph_poolBassengbeskrivelsen skal inneholde koblingsdata til Ceph med autorisasjonsdata.
Neste trinn er at LVM-bildet konverteres til Ceph RBD. Utførelsestiden avhenger først og fremst av størrelsen på bildet:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameEtter konverteringen vil et LVM-bilde forbli, noe som vil være nyttig hvis migrering av VM til RBD mislykkes og du må rulle tilbake endringene. For å raskt kunne rulle tilbake endringer, la oss ta en sikkerhetskopi av konfigurasjonsfilen for den virtuelle maskinen:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... og rediger originalen (vm_name.xml). La oss finne en blokk med en beskrivelse av disken (starter med linjen <disk type='file' device='disk'> og avsluttes med </disk>) og reduser den 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>La oss se på noen detaljer:
- Til protokollen
sourceadressen til lagringen i Ceph RBD er angitt (dette er adressen som indikerer navnet på Ceph-bassenget og RBD-bildet, som ble bestemt i første fase). - I blokken
secrettype er angittceph, samt UUID-en til hemmeligheten for å koble til den. Dens uuid kan bli funnet ved å bruke kommandoenvirsh secret-list. - I blokken
hostadresser til Ceph-monitorer er angitt.
Etter å ha redigert konfigurasjonsfilen og fullført konverteringen fra LVM til RBD, kan du bruke den endrede konfigurasjonsfilen og starte den virtuelle maskinen:
virsh define $vm_name.xml
virsh start $vm_name
Det er på tide å sjekke at den virtuelle maskinen startet riktig: du kan finne ut for eksempel ved å koble til den via SSH eller via virsh.
Hvis den virtuelle maskinen fungerer som den skal og du ikke har funnet noen andre problemer, kan du slette LVM-bildet som ikke lenger brukes:
lvremove main/$vm_image_nameKonklusjon
Vi møtte alle de beskrevne tilfellene i praksis - vi håper at instruksjonene vil hjelpe andre administratorer med å løse lignende problemer. Hvis du har kommentarer eller andre lignende historier fra din erfaring med Ceph, vil vi gjerne se dem i kommentarene!
PS
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com