Ha a Ceph-t hálózati tárolóként használjuk különböző terhelésű projektekben, számos olyan feladattal találkozhatunk, amelyek első pillantásra nem tűnnek egyszerűnek vagy triviálisnak. Például:
- adatok migrálása a régi Ceph-ről az újra az új fürt korábbi szervereinek részleges használatával;
- megoldás a lemezterület elosztásának problémájára a Ceph-ben.
Az ilyen problémák kezelésekor azzal kell szembesülnünk, hogy helyesen távolítsuk el az OSD-t adatvesztés nélkül, ami különösen fontos nagy mennyiségű adat kezelésekor. Erről a cikkben lesz szó.
Az alább leírt módszerek a Ceph bármely verziójára vonatkoznak. Ezenkívül figyelembe veszik azt a tényt is, hogy a Ceph nagy mennyiségű adatot képes tárolni: az adatvesztés és más problémák megelőzése érdekében egyes műveleteket több másikra osztanak fel.
Előszó az OSD-ről
Mivel a tárgyalt három recept közül kettő az OSD-nek van szentelve (), mielőtt belevágnánk a gyakorlati részbe – röviden arról, hogy mi ez Cephben, és miért olyan fontos.
Először is el kell mondani, hogy a teljes Ceph-klaszter sok OSD-ből áll. Minél több van, annál nagyobb a szabad adatmennyiség a Ceph-ben. Innen könnyű megérteni fő OSD funkció: Ceph objektumadatokat tárol az összes fürtcsomópont fájlrendszerén, és hálózati hozzáférést biztosít hozzá (olvasáshoz, íráshoz és egyéb kérésekhez).
Ugyanezen a szinten a replikációs paraméterek beállítása objektumok különböző OSD-k közötti másolásával történik. És itt különféle problémákkal találkozhat, amelyek megoldásait az alábbiakban tárgyaljuk.
1. számú ügy. Biztonságosan távolítsa el az OSD-t a Ceph-fürtből adatvesztés nélkül
Az OSD eltávolításának szükségességét okozhatja a kiszolgáló eltávolítása a fürtből – például azért, hogy egy másik szerverre cseréljük –, ami velünk is megtörtént, és ennek a cikknek a megírására ad okot. Így a manipuláció végső célja az összes OSD és mons kinyerése egy adott szerveren, hogy le lehessen állítani.
A kényelem kedvéért és annak elkerülése érdekében, hogy a parancsok végrehajtása közben hibásan jelezzük a szükséges OSD-t, beállítunk egy külön változót, melynek értéke a törölni kívánt OSD száma lesz. Hívjuk fel ${ID} — itt és lent egy ilyen változó helyettesíti annak az OSD-nek a számát, amellyel dolgozunk.
Nézzük meg a munka megkezdése előtti állapotot:
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
Az OSD eltávolításának elindításához zökkenőmentesen kell végrehajtania reweight rajta nullára. Ily módon csökkentjük az OSD-ben lévő adatok mennyiségét azáltal, hogy kiegyensúlyozzuk a többi OSD-vel. Ehhez futtassa a következő parancsokat:
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 nulláig.
Sima kiegyensúlyozás szükségeshogy ne vesszenek el adatok. Ez különösen igaz, ha az OSD nagy mennyiségű adatot tartalmaz. Hogy megbizonyosodjon arról, hogy a parancsok végrehajtása után reweight minden rendben ment, befejezheti ceph -s vagy egy külön terminál ablakban fut ceph -w a változások valós idejű megfigyelése érdekében.
Amikor az OSD „kiürült”, folytathatja a normál művelettel az eltávolításához. Ehhez vigye át a kívánt OSD-t állapotba down:
ceph osd down osd.${ID}„Húzzuk ki” az OSD-t a klaszterből:
ceph osd out osd.${ID}Állítsuk le az OSD szolgáltatást, és válasszuk le a partícióját az FS-ben:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Távolítsa el az OSD-t :
ceph osd crush remove osd.${ID}Töröljük az OSD felhasználót:
ceph auth del osd.${ID}És végül távolítsuk el magát az OSD-t:
ceph osd rm osd.${ID}Megjegyzés: Ha Ceph Luminous vagy újabb verziót használ, akkor a fenti OSD eltávolítási lépések két parancsra redukálhatók:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Ha a fent leírt lépések végrehajtása után lefuttatja a parancsot ceph osd tree, akkor egyértelműnek kell lennie, hogy azon a szerveren, ahol a munkát elvégezték, már nincsenek olyan OSD-k, amelyeknél a fenti műveleteket végrehajtották:
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
Útközben vegye figyelembe, hogy a Ceph-klaszter állapota a következőre fog menni HEALTH_WARN, és az OSD-k száma és a rendelkezésre álló lemezterület mennyisége is csökkenni fog.
Az alábbiakban leírjuk azokat a lépéseket, amelyek akkor szükségesek, ha teljesen le szeretné állítani a kiszolgálót, és ennek megfelelően el kívánja távolítani a Ceph-ből. Ebben az esetben fontos megjegyezni A szerver leállítása előtt el kell távolítania az összes OSD-t ezen a szerveren.
Ha nincs több OSD ezen a szerveren, akkor azok eltávolítása után ki kell zárni a szervert az OSD térképről hv-2a következő parancs futtatásával:
ceph osd crush rm hv-2
eltávolítás mon a szerverről hv-2az alábbi parancs futtatásával egy másik szerveren (azaz ebben az esetben a hv-1):
ceph-deploy mon destroy hv-2Ezt követően leállíthatja a kiszolgálót, és megkezdheti a további műveleteket (újratelepítés stb.).
2. számú ügy. Lemezterület elosztása egy már létrehozott Ceph-fürtben
A második történetet a PG-ről szóló előszóval kezdem (). A PG fő szerepe a Ceph-ben elsősorban az, hogy összesítse a Ceph objektumokat, és tovább replikálja azokat az OSD-ben. A képlet, amellyel kiszámíthatja a szükséges mennyiségű PG-t, benne van Ceph dokumentáció. Ezt a kérdést ott konkrét példákkal is tárgyalják.
Tehát: a Ceph használatakor az egyik gyakori probléma az OSD és a PG kiegyensúlyozatlan száma a Ceph készletei között.
Először is, emiatt olyan helyzet állhat elő, amikor túl sok PG van megadva egy kis készletben, ami lényegében a fürt lemezterületének irracionális kihasználása. Másodszor, a gyakorlatban van egy komolyabb probléma: adattúlcsordulás az egyik OSD-ben. Ez azt jelenti, hogy a klaszter először átáll az állapotba HEALTH_WARN, és akkor HEALTH_ERR. Ennek az az oka, hogy a Ceph a rendelkezésre álló adatmennyiség kiszámításakor (megtudhatja a MAX AVAIL a parancs kimenetében ceph df minden egyes készlethez külön) az OSD-ben rendelkezésre álló adatok mennyiségén alapul. Ha nincs elég hely legalább egy OSD-n, nem írható több adat mindaddig, amíg az adatok megfelelően el nem oszlanak az összes OSD között.
Érdemes tisztázni, hogy ezek a problémák nagyrészt a Ceph-fürt konfigurációs szakaszában döntenek. Az egyik használható eszköz az . Segítségével egyértelműen kiszámítható a szükséges PG mennyiség. Azonban olyan helyzetben is igénybe veheti, amikor a Ceph-klaszter már rosszul konfigurálva. Itt érdemes tisztázni, hogy a javítási munka részeként nagy valószínűséggel csökkentenie kell a PG-k számát, és ez a funkció a Ceph régebbi verzióiban nem érhető el (csak a verzióban jelent meg ).
Tehát képzeljük el a következő képet: a klaszternek van állapota HEALTH_WARN mert az egyik OSD-ből kifogyott a hely. Ezt egy hiba jelzi HEALTH_WARN: 1 near full osd. Az alábbiakban bemutatunk egy algoritmust, amellyel ki lehet jutni ebből a helyzetből.
Először is el kell osztania a rendelkezésre álló adatokat a fennmaradó OSD-k között. Az első esetben már végrehajtottunk hasonló műveletet, amikor „leeresztettük” a csomópontot - azzal a különbséggel, hogy most kissé csökkenteni kell reweight. Például 0.95-ig:
ceph osd reweight osd.${ID} 0.95Ez lemezterületet szabadít fel az OSD-ben, és kijavítja a ceph-állapot hibáját. Azonban, mint már említettük, ez a probléma elsősorban a Ceph kezdeti szakaszban történő helytelen konfigurációja miatt jelentkezik: nagyon fontos újrakonfigurálni, hogy a jövőben ne jelenjen meg.
A mi konkrét esetünkben minden a következőből fakadt:
- érték túl magas
replication_countaz egyik medencében, - túl sok PG az egyik medencében és túl kevés a másikban.
Használjuk a már említett számológépet. Világosan mutatja, hogy mit kell beírni, és elvileg nincs semmi bonyolult. A szükséges paraméterek beállítása után a következő ajánlásokat kapjuk:
Megjegyzés: Ha a Ceph-fürtöt a semmiből állítja be, a számológép másik hasznos funkciója olyan parancsok generálása, amelyek a táblázatban megadott paraméterekkel a nulláról hoz létre készleteket.
Az utolsó oszlop segít a navigálásban - Javasolt PG-szám. Esetünkben hasznos a második is, ahol a replikációs paramétert tüntettük fel, mivel a replikációs szorzó megváltoztatása mellett döntöttünk.
Tehát először meg kell változtatnia a replikációs paramétereket - először ezt érdemes megtenni, mivel a szorzó csökkentésével lemezterületet szabadítunk fel. A parancs végrehajtása során észre fogja venni, hogy a rendelkezésre álló lemezterület megnő:
ceph osd pool $pool_name set $replication_size
Befejezése után pedig megváltoztatjuk a paraméterértékeket pg_num и pgp_num az alábbiak szerint:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberFontos: egymás után módosítanunk kell a PG-k számát minden készletben, és nem módosítanunk kell az értékeket más készletekben, amíg a figyelmeztetések el nem tűnnek "Csökkent adatredundancia" и "n-szám leromlott oldal".
A parancskimenetek segítségével is ellenőrizheti, hogy minden rendben ment-e ceph health detail и ceph -s.
3. számú ügy. Virtuális gép migrálása LVM-ről Ceph RBD-re
Abban a helyzetben, amikor egy projekt bérelt csupasz fém szerverekre telepített virtuális gépeket használ, gyakran felmerül a hibatűrő tárolás kérdése. Az is nagyon kívánatos, hogy legyen elég hely ebben a tárolóban... Egy másik gyakori helyzet: van egy virtuális gép helyi tárhellyel a szerveren és bővíteni kell a lemezt, de nincs hova menni, mert nincs szabad lemezterület maradt a szerveren.
A probléma többféleképpen is megoldható - például egy másik kiszolgálóra való migrációval (ha van ilyen), vagy új lemezek hozzáadásával a szerverhez. De ez nem mindig lehetséges, így az LVM-ről a Ceph-re való átállás kiváló megoldás lehet erre a problémára. Ennek az opciónak a kiválasztásával leegyszerűsítjük a szerverek közötti migráció további folyamatát is, mivel nem kell a helyi tárhelyet egyik hypervisorról a másikra áthelyezni. Az egyetlen bökkenő az, hogy le kell állítania a virtuális gépet, amíg a munka folyik.
A következő recept innen származik , amelynek utasításait működés közben teszteltük. Apropó, ott le van írva a problémamentes migráció módszere is, azonban esetünkben egyszerűen nem volt rá szükség, ezért nem ellenőriztük. Ha ez kritikus fontosságú az Ön projektje szempontjából, szívesen hallunk az eredményekről a megjegyzésekben.
Térjünk át a gyakorlati részre. A példában a virsh-t és ennek megfelelően a libvirt-t használjuk. Először győződjön meg arról, hogy az a Ceph-készlet, amelybe az adatokat migrálni fogja, csatlakozik a libvirthez:
virsh pool-dumpxml $ceph_poolA készletleírásnak tartalmaznia kell a Ceph kapcsolati adatait engedélyezési adatokkal együtt.
A következő lépés az LVM kép konvertálása Ceph RBD-vé. A végrehajtási idő 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_nameAz átalakítás után egy LVM lemezkép marad, ami akkor lesz hasznos, ha a virtuális gép RBD-re migrálása meghiúsul, és vissza kell vonnia a változtatásokat. Ezenkívül a módosítások gyors visszaállítása érdekében készítsünk 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 szerkessze az eredetit (vm_name.xml). Keressünk egy blokkot a lemez leírásával (a sorral kezdődik <disk type='file' device='disk'> és azzal végződik </disk>), és csökkentse a következő formára:
<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ünk néhány részletet:
- A protokollhoz
sourcea Ceph RBD-ben található tárhely címe van feltüntetve (ez a cím jelzi a Ceph pool és az RBD kép nevét, amelyet az első szakaszban határoztak meg). - A blokkban
secrettípusa van feltüntetveceph, valamint a titkosság UUID-jét a hozzá való csatlakozáshoz. Az uuid a paranccsal található megvirsh secret-list. - A blokkban
hosta Ceph monitorok címei vannak feltüntetve.
A konfigurációs fájl szerkesztése és az LVM RBD konverzió befejezése után alkalmazhatja a módosított konfigurációs fájlt, és elindíthatja 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 megfelelően indult-e: ezt megtudhatja például úgy, hogy SSH-n keresztül csatlakozik hozzá virsh.
Ha a virtuális gép megfelelően működik, és nem talált más problémát, akkor törölheti a már nem használt LVM-képet:
lvremove main/$vm_image_nameKövetkeztetés
Az összes leírt esettel találkoztunk a gyakorlatban - reméljük, hogy az utasítások segítenek más rendszergazdáknak hasonló problémák megoldásában. Ha vannak megjegyzései vagy más hasonló történetei a Ceph használatával kapcsolatos tapasztalatairól, szívesen látjuk őket a megjegyzésekben!
PS
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com