Vinkkejä ja temppuja työskentelyyn Cephin kanssa kiireisissä projekteissa

Käyttämällä Cephiä verkkotallennusna eri kuormittavissa projekteissa saatamme kohdata erilaisia ​​tehtäviä, jotka eivät ensi silmäyksellä vaikuta yksinkertaisilta tai triviaaleilta. Esimerkiksi:

• datan siirtäminen vanhasta Cephistä uuteen käyttämällä osittaista aiempia palvelimia uudessa klusterissa;
• ratkaisu levytilan varausongelmaan Cephissa.

Tällaisten ongelmien käsittelyssä kohtaamme tarpeen poistaa OSD oikein menettämättä tietoja, mikä on erityisen tärkeää käsiteltäessä suuria tietomääriä. Tästä keskustellaan artikkelissa.

Alla kuvatut menetelmät koskevat kaikkia Ceph-versioita. Lisäksi otetaan huomioon se, että Ceph voi tallentaa suuren määrän tietoa: tietojen katoamisen ja muiden ongelmien estämiseksi jotkin toiminnot "jaetaan" useisiin muihin.

Esipuhe OSD:stä

Koska kaksi kolmesta käsitellystä reseptistä on omistettu OSD:lle (Object Storage Daemon), ennen kuin sukeltaa käytännön osaan - lyhyesti siitä, mitä se on Cephissä ja miksi se on niin tärkeä.

Ensinnäkin on todettava, että koko Ceph-klusteri koostuu useista OSD:istä. Mitä enemmän niitä on, sitä suurempi on Cephin vapaa datamäärä. Se on helppo ymmärtää täältä OSD-päätoiminto: Se tallentaa Ceph-objektitiedot kaikkien klusterisolmujen tiedostojärjestelmiin ja tarjoaa pääsyn verkkoon (lukemista, kirjoittamista ja muita pyyntöjä varten).

Samalla tasolla replikointiparametrit asetetaan kopioimalla objekteja eri OSD:iden välillä. Ja täällä voit kohdata erilaisia ​​​​ongelmia, joiden ratkaisuja käsitellään alla.

Tapaus nro 1. Poista OSD turvallisesti Ceph-klusterista menettämättä tietoja

OSD:n poistamisen tarve voi johtua palvelimen poistamisesta klusterista - esimerkiksi sen korvaamiseksi toisella palvelimella - mikä meille tapahtui, mikä aiheutti tämän artikkelin kirjoittamisen. Siten manipuloinnin perimmäinen tavoite on purkaa kaikki tietyn palvelimen OSD:t ja monit, jotta se voidaan pysäyttää.

Mukavuuden vuoksi ja välttääksemme tilanteen, jossa komentoja suoritettaessa erehdymme ilmoittamaan vaadittua OSD:tä, asetamme erillisen muuttujan, jonka arvo on poistettavan OSD:n numero. Soitetaan hänelle ${ID} — Tässä ja alla tällainen muuttuja korvaa sen OSD:n numeron, jonka kanssa työskentelemme.

Katsotaanpa tilannetta ennen työn aloittamista:

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

OSD-poiston aloittamiseksi sinun on suoritettava sujuvasti reweight siinä nollaan. Tällä tavalla vähennämme OSD:n datan määrää tasapainottamalla sitä muiden OSD:iden kanssa. Voit tehdä tämän suorittamalla seuraavat komennot:

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

... ja niin edelleen nollaan asti.

Tarvitaan tasainen tasapainotusjotta et menetä tietoja. Tämä pätee erityisesti, jos OSD sisältää suuren määrän dataa. Varmistaaksesi, että komentojen suorittamisen jälkeen reweight kaikki meni hyvin, voit suorittaa sen ceph -s tai erillisessä pääteikkunassa ceph -w jotta voit seurata muutoksia reaaliajassa.

Kun OSD on "tyhjennetty", voit jatkaa sen poistamiseksi normaalilla toiminnolla. Voit tehdä tämän siirtämällä haluamasi OSD tilaan down:

ceph osd down osd.${ID}

"Vedetään" OSD ulos klusterista:

ceph osd out osd.${ID}

Lopetetaan OSD-palvelu ja irrotetaan sen osio FS:stä:

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

Poista OSD CRUSH kartta:

ceph osd crush remove osd.${ID}

Poistetaan OSD-käyttäjä:

ceph auth del osd.${ID}

Ja lopuksi, poistetaan itse OSD:

ceph osd rm osd.${ID}

Huomata: Jos käytät Ceph Luminous -versiota tai uudempaa, yllä olevat OSD-poistovaiheet voidaan lyhentää kahteen komentoon:

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

Jos suoritat komennon yllä kuvattujen vaiheiden suorittamisen jälkeen ceph osd tree, silloin pitäisi olla selvää, että palvelimella, jossa työ suoritettiin, ei ole enää OSD:itä, joille yllä olevat toiminnot suoritettiin:

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

Huomaa matkan varrella, että Ceph-klusterin tila menee HEALTH_WARN, ja näemme myös OSD:iden määrän ja käytettävissä olevan levytilan määrän vähenevän.

Seuraavassa kuvataan vaiheet, joita tarvitaan, jos haluat pysäyttää palvelimen kokonaan ja vastaavasti poistaa sen Cephista. Tässä tapauksessa on tärkeää muistaa se Ennen palvelimen sammuttamista sinun on poistettava kaikki OSD:t tällä palvelimella.

Jos tällä palvelimella ei ole enää OSD:itä jäljellä, niiden poistamisen jälkeen sinun on poistettava palvelin OSD-kartalta hv-2suorittamalla seuraava komento:

ceph osd crush rm hv-2

Poistaa mon palvelimelta hv-2suorittamalla alla oleva komento toisella palvelimella (eli tässä tapauksessa on hv-1):

ceph-deploy mon destroy hv-2

Tämän jälkeen voit pysäyttää palvelimen ja aloittaa myöhempiä toimia (uudelleenkäyttöönoton jne.).

Tapaus nro 2. Levytilan jakaminen jo luodussa Ceph-klusterissa

Aloitan toisen tarinan esipuheella PG:stä (Sijoitteluryhmät). PG:n päärooli Cephissä on ensisijaisesti koota Ceph-objekteja ja kopioida niitä edelleen OSD:ssä. Kaava, jolla voit laskea tarvittavan määrän PG:tä, on tässä asiaankuuluva osio Ceph-dokumentaatio. Myös tätä asiaa käsitellään siellä konkreettisin esimerkein.

Joten: yksi yleisimmistä ongelmista Cephin käytössä on OSD:n ja PG:n epätasapainoinen määrä Ceph-poolien välillä.

Ensinnäkin tästä johtuen voi syntyä tilanne, kun liian monta PG:tä määritellään pienessä poolissa, mikä on pohjimmiltaan irrationaalista levytilan käyttöä klusterissa. Toiseksi, käytännössä on vakavampi ongelma: tietojen ylivuoto yhdessä OSD:ssä. Tämä edellyttää klusterin siirtymistä ensin tilaan HEALTH_WARN, ja sitten HEALTH_ERR. Syynä tähän on se, että Ceph laskeessaan käytettävissä olevaa datamäärää (voit selvittää sen käyttämällä MAX AVAIL komennon ulostulossa ceph df jokaiselle poolille erikseen) perustuu OSD:ssä käytettävissä olevan tiedon määrään. Jos vähintään yhdessä kuvaruutunäytössä ei ole tarpeeksi tilaa, tietoja ei voida kirjoittaa enempää, ennen kuin tiedot on jaettu oikein kaikkien OSD:iden kesken.

On syytä selventää, että nämä ongelmat päätetään suurelta osin Ceph-klusterin määritysvaiheessa. Yksi työkaluista, joita voit käyttää, on Ceph PGCalc. Sen avulla lasketaan selkeästi tarvittava määrä PG:tä. Voit kuitenkin turvautua siihen myös tilanteessa, jossa Ceph-klusteri jo määritetty väärin. Tässä on syytä selventää, että osana korjaustyötä joudut todennäköisesti vähentämään PG:iden määrää, eikä tämä ominaisuus ole saatavilla Cephin vanhemmissa versioissa (se ilmestyi vain versiossa Nautilus).

Joten kuvitellaan seuraava kuva: klusterilla on tila HEALTH_WARN koska jokin kuvaruutunäytöstä on loppumassa. Tämä ilmaistaan ​​virheenä HEALTH_WARN: 1 near full osd. Alla on algoritmi tilanteesta selviämiseksi.

Ensinnäkin sinun on jaettava käytettävissä olevat tiedot jäljellä olevien OSD:iden kesken. Teimme jo samanlaisen toimenpiteen ensimmäisessä tapauksessa, kun "tyhjensimme" solmun - sillä ainoalla erolla, että nyt meidän on pienennettävä hieman reweight. Esimerkiksi 0.95 asti:

ceph osd reweight osd.${ID} 0.95

Tämä vapauttaa levytilaa OSD:ssä ja korjaa Ceph-kunnossa olevan virheen. Kuitenkin, kuten jo mainittiin, tämä ongelma johtuu pääasiassa Cephin virheellisestä konfiguroinnista alkuvaiheessa: on erittäin tärkeää tehdä uudelleenkonfigurointi, jotta sitä ei ilmene tulevaisuudessa.

Meidän tapauksessamme kaikki johtui siitä, että:

• arvo liian korkea replication_count yhdessä altaista,
• liian paljon PG:tä yhdessä altaassa ja liian vähän toisessa.

Käytetään jo mainittua laskinta. Se osoittaa selvästi, mitä on syötettävä, eikä periaatteessa ole mitään monimutkaista. Kun tarvittavat parametrit on asetettu, saamme seuraavat suositukset:

Huomata: Jos asennat Ceph-klusterin tyhjästä, toinen laskimen hyödyllinen toiminto on komentojen luominen, jotka luovat pooleja alusta alkaen taulukossa määritetyillä parametreilla.

Viimeinen sarake auttaa navigoinnissa - Suositeltu PG-määrä. Meidän tapauksessamme toinen on myös hyödyllinen, jossa on ilmoitettu replikointiparametri, koska päätimme muuttaa toisinnuskerrointa.

Joten ensin sinun on muutettava replikointiparametreja - tämä kannattaa tehdä ensin, koska vähentämällä kerrointa vapautamme levytilaa. Kun komento suoritetaan, huomaat, että käytettävissä oleva levytila ​​kasvaa:

ceph osd pool $pool_name set $replication_size

Ja sen valmistumisen jälkeen muutamme parametrien arvoja pg_num и pgp_num seuraavasti:

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

On tärkeää: meidän on muutettava PG:iden lukumäärää peräkkäin kussakin poolissa, emmekä muuta arvoja muissa poolissa ennen kuin varoitukset katoavat "Heikentynyt datan redundanssi" и "n-määrä huonontunutta sivua".

Voit myös tarkistaa, että kaikki meni hyvin käyttämällä komentolähtöjä ceph health detail и ceph -s.

Tapaus nro 3. Virtuaalikoneen siirto LVM:stä Ceph RBD:hen

Tilanteessa, jossa projektissa käytetään virtuaalikoneita, jotka on asennettu vuokratuille paljasmetallipalvelimille, herää usein kysymys vikasietoisesta tallennustilasta. On myös erittäin toivottavaa, että tässä tallennustilassa on tarpeeksi tilaa... Toinen yleinen tilanne: palvelimella on virtuaalikone, jossa on paikallista tallennustilaa ja sinun täytyy laajentaa levyä, mutta ei ole minne mennä, koska ei ole palvelimelle jää vapaata levytilaa.

Ongelma voidaan ratkaista eri tavoin - esimerkiksi siirtymällä toiseen palvelimeen (jos sellainen on) tai lisäämällä palvelimelle uusia levyjä. Mutta tämä ei ole aina mahdollista, joten siirtyminen LVM:stä Cephiin voi olla erinomainen ratkaisu tähän ongelmaan. Valitsemalla tämän vaihtoehdon yksinkertaistamme myös jatkosiirtoprosessia palvelimien välillä, koska paikallista tallennustilaa ei tarvitse siirtää hypervisorista toiseen. Ainoa saalis on, että joudut pysäyttämään VM:n työn suorittamisen ajaksi.

Seuraava resepti on otettu artikkeli tästä blogista, jonka ohjeet on testattu toiminnassa. Muuten, siellä kuvataan myös vaivaton siirtomenetelmä, meidän tapauksessamme sitä ei yksinkertaisesti tarvittu, joten emme tarkistaneet sitä. Jos tämä on kriittistä projektisi kannalta, kuulemme mielellämme tuloksista kommenteissa.

Siirrytään käytännön osaan. Esimerkissä käytämme virsh ja vastaavasti libvirt. Varmista ensin, että Ceph-pooli, johon tiedot siirretään, on yhdistetty libvirtiin:

virsh pool-dumpxml $ceph_pool

Poolikuvauksen tulee sisältää yhteystiedot Cephiin valtuutustietojen kera.

Seuraava vaihe on, että LVM-kuva muunnetaan Ceph RBD:ksi. Suoritusaika riippuu ensisijaisesti kuvan koosta:

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

Muuntamisen jälkeen jäljelle jää LVM-kuva, josta on hyötyä, jos VM:n siirto RBD:hen epäonnistuu ja muutokset on palautettava. Jotta muutokset voidaan peruuttaa nopeasti, tehdään varmuuskopio virtuaalikoneen määritystiedostosta:

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

... ja muokkaa alkuperäistä (vm_name.xml). Etsitään lohko, jossa on kuvaus levystä (alkaa rivillä <disk type='file' device='disk'> ja päättyy </disk>) ja pienennä se seuraavaan muotoon:

<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>

Katsotaanpa joitain yksityiskohtia:

1. Protokollaan source osoitetaan Ceph RBD:ssä olevan tallennuspaikan osoite (tämä on osoite, joka osoittaa Ceph-poolin ja RBD-kuvan nimen, joka määritettiin ensimmäisessä vaiheessa).
2. Lohkossa secret tyyppi on merkitty ceph, sekä salaisuuden UUID, jolla voit muodostaa yhteyden siihen. Sen uuid löytyy komennolla virsh secret-list.
3. Lohkossa host Ceph-valvojien osoitteet on ilmoitettu.

Kun olet muokannut asetustiedostoa ja suorittanut LVM:n muuntamisen RBD:ksi, voit ottaa muokatun määritystiedoston käyttöön ja käynnistää virtuaalikoneen:

virsh define $vm_name.xml
virsh start $vm_name

On aika tarkistaa, onko virtuaalikone käynnistynyt oikein: sen saat selville esimerkiksi muodostamalla yhteyden siihen SSH:n kautta tai virsh.

Jos virtuaalikone toimii oikein etkä ole löytänyt muita ongelmia, voit poistaa LVM-kuvan, jota ei enää käytetä:

lvremove main/$vm_image_name

Johtopäätös

Olemme kohdanneet kaikki kuvatut tapaukset käytännössä - toivomme, että ohjeet auttavat muita ylläpitäjiä ratkaisemaan samanlaisia ​​ongelmia. Jos sinulla on kommentteja tai muita vastaavia tarinoita kokemuksistasi Cephin käytöstä, näemme ne mielellämme kommenteissa!

PS.

Lue myös blogistamme:

• «Kädemme eivät ole ikävystymistä varten: Rook-klusterin palauttaminen K8:ssa";
• «Rookille vai ei Rookille - se on kysymys";
• «Rook - "itsepalvelu" tietovarasto Kubernetesille";
• «Pysyvän tallennustilan luominen Ceph-pohjaisen Kubernetesin provisioinnin avulla'.

Lähde: will.com