🥇Tippek & trükkök a Ceph használatáról nagy terhelésű projektekben

A Ceph használatával hálózati tárolóként különböző terhelésű projektekben különféle feladatokkal találkozhatunk, amelyek első pillantásra nem tűnnek egyszerűnek vagy triviálisnak. Például:

adatok migrálása régi Ceph-ből újba, részlegesen a korábbi szerverek felhasználásával az új klaszterben;
a Ceph lemezterület elosztásának problémái.

Ezekkel a feladatokkal foglalkozva elengedhetetlen, hogy helyesen távolítsuk el az OSD-t adatvesztés nélkül, ami különösen fontos nagy adatmennyiségek esetén. Erről fog szólni a cikk.

Az alább leírt módszerek minden Ceph verzióra érvényesek. Emellett figyelembe vesszük, hogy a Ceph-ben nagy mennyiségű adat is tárolható: az adatvesztés és egyéb problémák megelőzése érdekében egyes műveleteket "darabokra" osztunk.

Bevezető az OSD-ről

Mivel a három vizsgált recept közül kettő az OSD-nek szól (Object Storage Daemon), a gyakorlati részbe való merülés előtt röviden arról, hogy ez mi is a Ceph-ben és miért ilyen fontos.

Először is meg kell említeni, hogy az egész Ceph klaszter számos OSD-ből áll. Minél több van belőlük, annál nagyobb a szabad adatkapacitás Ceph-ben. Itt könnyen megérthetjük az OSD fő funkcióját: az OSD a Ceph objektumait tárolja a klaszter összes csomópontjának fájlrendszerén, és hálózati hozzáférést biztosít számukra (olvasásra, írásra és egyéb kérésekre).

Ez a szinten állapítják meg a replikációs paramétereket, mivel a különböző OSD-k között objektumok másolásával valósulnak meg. Itt különböző problémákkal találkozhatunk, amelyek megoldásáról a továbbiakban szó lesz.

1. eset: Biztonságos OSD eltávolítása a Ceph klaszterből adatvesztés nélkül

Az OSD eltávolításának szükségességét a szerver klaszterből való kivonása okozhatja - például másik szerverre való cserélés céljából - ami nálunk is megtörtént, és ami miatt ezt a cikket írtuk. Így a manipulációk végső célja az, hogy eltávolítsuk az összes OSD-t és a monokat ezen a szerveren, hogy le lehessen állítani.

A kényelem és a olyan helyzetek elkerülése érdekében, amikor a parancsok végrehajtása során hibázunk a szükséges OSD megadásakor, megadunk egy külön változót, amelynek értéke az eltávolítandó OSD számát fogja képviselni. Hívjuk ezt ${ID} — ez a változó helyettesíti a számot az OSD-nél, amellyel dolgozunk.

Nézzük meg az állapotot a munka megkezdése előtt:

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

A OSD eltávolításának kezdeményezéséhez fokozatosan kell végrehajtani a súlyozását nullára. Ezzel csökkentjük az OSD-ben lévő adatok mennyiségét, mivel azokat más OSD-kre egyensúlyozzuk. Ehhez a következő parancsokat kell végrehajtani:

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

… és így tovább egészen nulláig.

A fokozatos egyensúlyozás szükséges, hogy ne veszítsenek el adatokat. Ez különösen fontos, ha nagy mennyiségű adat található az OSD-ben. Annak érdekében, hogy biztosak legyünk abban, hogy a parancsok végrehajtása után a súlyozását minden rendben zajlott, a következőket hajthatjuk végre: ceph -s vagy egy külön terminálablakban futtathatjuk a ceph -w parancsot, hogy valós időben figyelemmel kísérhessük a változásokat.

Amikor az OSD „kiürített”, megkezdhetjük a törlés standard műveletét. Ehhez állítsuk az adott OSD-t az down:

állapotba: ceph osd down osd.${ID}

„Kivesszük” az OSD-t a klaszterből:

ceph osd out osd.${ID}

Leállítjuk az OSD szolgáltatást és leválasztjuk a partíciót a fájlrendszerről:

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

Eltávolítjuk az OSD-t a CRUSH térképből::

ceph osd crush remove osd.${ID}

Eltávolítjuk az OSD felhasználót:

ceph auth del osd.${ID}

Végül pedig eltávolítjuk magát az OSD-t:

ceph osd rm osd.${ID}

Megjegyzés: ha a Ceph Luminous vagy újabb verziót használ, akkor a fenti OSD eltávolítási lépéseket két parancsra lehet egyszerűsíteni:

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

Ha a fenti lépések után a parancsot hajtjuk végre, ceph osd tree, látnunk kell, hogy azon a szerveren, ahol a műveleteket végeztük, már nincsenek OSD-k, amelyekre alkalmazták a fenti műveleteket:

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

Ekkor észrevesszük, hogy a Ceph klaszter állapota átkerül a HEALTH_WARN, és azt is láthatjuk, hogy csökkent az OSD-k száma és a rendelkezésre álló tárolókapacitás.

A következőkben leírásra kerülnek azok a lépések, amelyek szükségesek, ha teljesen le szeretné állítani a szervert, és ezzel eltávolítani azt a Ceph-ből. Ebben az esetben fontos megjegyezni, hogy a szerver kikapcsolása előtt minden OSD-t el kell távolítani azon a szerveren.

Ha ezen a szerveren már nem maradt OSD, akkor eltávolításuk után ki kell venni az OSD térképből a szervert hv-2, az alábbi parancs végrehajtásával:

ceph osd crush rm hv-2

Eltávolítjuk mon a szerverről hv-2, egy másik szerveren futtatva a lent található parancsot (azaz ebben az esetben - a hv-1):

ceph-deploy mon destroy hv-2

. Ezt követően leállítható a szerver, és folytathatók a további lépések (újra telepítés, stb.).

2. eset: A már létrehozott Ceph klaszter lemezterületének elosztása

A második történetet a PG-ről (Placement Groups). A PG alapvető szerepe a Ceph-ben elsősorban a Ceph objektumok aggregálása és azok OSD-kbe történő további replikálása. A szükséges PG-k számának kiszámítására szolgáló képlet a megfelelő részben Ceph dokumentációban található. Ott ez a kérdés konkrét példákkal is tárgyalva van.

Nos, az egyik leggyakoribb probléma a Ceph üzemeltetése során a közötti OSD-k és PG-k egyensúlyának hiánya a Ceph tárolók között.

Először is, emiatt előfordulhat, hogy túl nagy számú PG-t adunk meg egy kisméretű tárolóban, ami lényegében pazarlás a klaszter lemezterületével. Másodszor, a gyakorlatban komolyabb probléma adódik: az egyik OSD tele lesz. Ez azt eredményezi, hogy a klaszter először HEALTH_WARN, majd pedig HEALTH_ERR. Ennek oka, hogy a Ceph a rendelkezésre álló adatmennyiség (melyet a MAX AVAIL a parancs kimenetében ceph df segítségével lehet ellenőrizni a különböző tárolók esetében) kiszámításakor az OSD-ben lévő szabad helyre támaszkodik. Ha akár csak egy OSD-ben sincs elegendő hely, akkor új adatokat írni nem lehet, amíg az adatok megfelelően nem kerülnek elosztásra az összes OSD között.

Érdemes tisztázni, hogy ezek a problémák nagyobb részben a Ceph klaszter konfigurálásakor kezelhetők.Az egyik eszköz, amelyet használhatunk, a Ceph PGCalc. Ezzel vizuálisan számítható a szükséges PG-k száma. Egyébként ezt a helyzetet akkor is figyelembe kell venni, ha a Ceph klaszter már nincs megfelelően konfigurálva. Fontos megjegyezni, hogy a hibák javítása során valószínűleg csökkenteni kell a PG-k számát, ami a régebbi Ceph verziókban nem lehetséges (ez csak a Nautilus).

verziótól érhető el). HEALTH_WARN Képzeljük el a következő helyzetet: a klaszter állapota mert az egyik OSD-ben kifogy a hely. Ezt a hiba jelzi,HEALTH_WARN: 1 near full osd

Elsősorban el kell osztani a meglévő adatokat a többi OSD között. Ilyen műveletet már végeztünk az első esetnél, amikor 'kiürítettük' a csomópontot - azzal a különbséggel, hogy most kissé csökkenteni kell. a súlyozását. Például 0.95-re:

ceph osd reweight osd.${ID} 0.95

Így felszabadul a lemezterület az OSD-ben, és javul a ceph health. Azonban, mint már említettük, ez a probléma főként a Ceph helytelen beállítása miatt merül fel a kezdeti szakaszokban: nagyon fontos a rekonszolidáció elvégzése, hogy a jövőben ne jelentkezzen.

A mi konkrét esetünknél minden a következőkre vezethető vissza:

túl magas érték replication_count az egyik medencében,
túl sok PG egy medencében és túl kevés - a másikban.

Használjuk az említett kalkulátort. Ebben szemléletesen látható, hogy mit kell bevinni, és alapvetően semmi bonyolult nincsen. A szükséges paraméterek megadása után a következő ajánlásokat kapjuk:

Megjegyzés: ha új Ceph klasztert állít be, a kalkulátor egy másik hasznos funkciója, hogy generál parancsokat, amelyek létrehozzák a medencéket a nulláról a táblázatban megadott paraméterekkel.

Az utolsó oszlop segít orientálódni - Suggested PG Count. A mi esetünkben hasznos a második is, ahol a replikációs paraméter található, mivel úgy döntöttünk, hogy megváltoztatjuk a replikációs szorzót.

Tehát először a replikációs paramétereket kell megváltoztatni - ezt érdemes elsőként megtenni, mivel a szorzó csökkentésével felszabadítunk lemezterületet. A parancs végrehajtása során észlelni lehet, hogy a rendelkezésre álló lemezterület növekszik:

ceph osd pool $pool_name set $replication_size

A parancs befejezése után - módosítjuk a következő paraméterek értékeit: pg_num és pgp_num így:

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

Fontos: minden medencében fokozatosan meg kell változtatnunk a PG-k számát, és nem szabad megváltoztatnunk az értékeket más medencékben, amíg a figyelmeztetések el nem tűnnek. «Degraded data redundancy» és «n-number of pgs degraded».

Ellenőrizheti, hogy minden sikeresen ment-e a parancsok kimenetében: ceph health detail és ceph -s.

3. eset. Virtuális gép migrálása LVM-ből Ceph RBD-be.

A virtuális gépeket használó projektek esetében gyakran felmerül a kérdés a megbízható tárolás szükségességéről, különösen, ha a tárolónak elegendő helyet kell biztosítania... Egy másik gyakori helyzet, amikor egy virtuális gép helyi tárolóval rendelkezik a szerveren és meg kellene növelni a lemezt, de nem lehetséges, mivel a szerveren nincs szabad lemezterület.

A problémát különböző módokon lehet megoldani — például migrálással egy másik szerverre (ha van ilyen) vagy új lemezek hozzáadásával a szerverhez. De nem mindig lehet így eljárni, ezért az LVM-ből Ceph-re való migráció remek megoldás lehet a problémára. Ennek a választásnak a előnye, hogy egyszerűsíti a további migrációs folyamatokat is, mivel nem szükséges a helyi tárolót egyik hipervizorról a másikra áthelyezni. Az egyetlen bökkenő, hogy a migrációs munka idejére le kell állítani a virtuális gépet.

A következő recepthez e blog cikkét vettük alapul,amelynek az utasításait már teszteltük. Érdemes megjegyezni, hogy ott említve van a zökkenőmentes migráció módja,de a mi esetünkben ez egyszerűen nem volt szükséges, ezért nem ellenőriztük. Ha azonban ez kritikus a projektje számára, örömmel várjuk a visszajelzéseket a kommentekben.

Kezdjük a gyakorlati résszel. Az példában virsh-t és ennek megfelelően libvirt-ot használunk. Először győződjön meg arról, hogy a Ceph pool, ahová az adatokat migrálni fogjuk, csatlakoztatva van a libvirt-hoz:

virsh pool-dumpxml $ceph_pool

A pool leírásában a Ceph-hez való kapcsolódási adatoknak, beleértve a hitelesítési adatokat is, szerepelniük kell.

A következő lépés a LVM kép Ceph RBD-be való konvertálása. A végrehajtás ideje elsősorban a kép méretétől függ:

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

A konvertálás után megmarad az LVM kép, amely hasznos lehet, ha a virtuális gépet nem tudjuk migrálni az RBD-be, és vissza kell vonni a változtatásokat. Emellett, hogy lehetőséget biztosítsunk a gyors visszaállításra, készítsünk egy biztonsági másolatot a virtuális gép konfigurációs fájljáról:

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

… és módosítjuk az eredetit (vm_name.xml). Keressük meg a lemez leírásának blokkát (amely a következő sorral kezdődik: <disk type='file' device='disk'> és az alábbi sort zárja le. </disk>) és az alábbi formátumra alakítjuk:

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

Nézzük meg néhány részletet:

A protokoll forrás meghatározza a Ceph RBD tároló címét (ez a cím a Ceph-tó és az RBD-kép nevét tartalmazza, amelyet az első lépésben adtunk meg).
A blokkban secret megadja a típust ceph, valamint a csatlakozáshoz szükséges titkosítvány UUID-ját. Az UUID-t a következő parancs segítségével lehet lekérdezni: virsh secret-list.
A blokkban host a Ceph monitorok címeit megjeleníti.

A konfigurációs fájl szerkesztése és az LVM RBD-vé alakítása után alkalmazhatjuk a módosított konfigurációs fájlt, és elindíthatjuk a virtuális gépet:

virsh define $vm_name.xml
virsh start $vm_name

Itt az ideje ellenőrizni, hogy a virtuális gép helyesen indult-e: ezt például SSH-n keresztül, vagy a virsh.

Ha a virtuális gép működik, és nem talál más problémát, törölheti az LVM-képet, amely már nem használatos:

lvremove main/$vm_image_name

Zárás

Minden leírt esetet a gyakorlatban tapasztaltunk — reméljük, hogy az útmutatók más adminisztrátorok számára is segítenek hasonló problémák megoldásában. Ha van megjegyzése vagy más hasonló tapasztalata a Ceph használatával kapcsolatban, szívesen látjuk őket a kommentek között!