ProHoster > Blog > administratë > Këshilla dhe truket për të punuar me Ceph në projekte të ngarkuara

Këshilla dhe truket për të punuar me Ceph në projekte të ngarkuara

Këshilla dhe truket për të punuar me Ceph në projekte të ngarkuara

Duke përdorur Ceph si ruajtje në rrjet në projekte me ngarkesa të ndryshme, mund të hasim detyra të ndryshme që në shikim të parë nuk duken të thjeshta apo të parëndësishme. Për shembull:

  • migrimi i të dhënave nga Ceph i vjetër në një të ri me përdorim të pjesshëm të serverëve të mëparshëm në grupin e ri;
  • zgjidhja e problemit të ndarjes së hapësirës në disk në Ceph.

Duke u marrë me probleme të tilla, ne përballemi me nevojën për të hequr saktë OSD-në pa humbur të dhëna, gjë që është veçanërisht e rëndësishme kur kemi të bëjmë me sasi të mëdha të dhënash. Kjo do të diskutohet në artikull.

Metodat e përshkruara më poshtë janë të rëndësishme për çdo version të Ceph. Për më tepër, do të merret parasysh fakti që Ceph mund të ruajë një sasi të madhe të dhënash: për të parandaluar humbjen e të dhënave dhe probleme të tjera, disa veprime do të "ndahen" në disa të tjera.

Parathënie rreth OSD

Meqenëse dy nga tre recetat e diskutuara i dedikohen OSD (Daemon i ruajtjes së objekteve), përpara se të zhyteni në pjesën praktike - shkurtimisht se çfarë është në Ceph dhe pse është kaq e rëndësishme.

Para së gjithash, duhet thënë se i gjithë grupi Ceph përbëhet nga shumë OSD. Sa më shumë të ketë, aq më i madh është vëllimi i të dhënave falas në Ceph. Është e lehtë të kuptosh nga këtu funksioni kryesor OSD: Ruan të dhënat e objektit Ceph në sistemet e skedarëve të të gjitha nyjeve të grupimit dhe siguron akses në rrjet në to (për lexim, shkrim dhe kërkesa të tjera).

Në të njëjtin nivel, parametrat e replikimit vendosen duke kopjuar objekte midis OSD-ve të ndryshme. Dhe këtu mund të hasni probleme të ndryshme, zgjidhjet e të cilave do të diskutohen më poshtë.

Rasti nr. 1. Hiqni në mënyrë të sigurt OSD nga grupi Ceph pa humbur të dhëna

Nevoja për të hequr OSD-në mund të shkaktohet nga heqja e serverit nga grupi - për shembull, për ta zëvendësuar atë me një server tjetër - gjë që ndodhi me ne, duke shkaktuar shkrimin e këtij artikulli. Kështu, qëllimi përfundimtar i manipulimit është nxjerrja e të gjitha OSD dhe mons në një server të caktuar në mënyrë që të mund të ndalet.

Për lehtësi dhe për të shmangur një situatë kur gjatë ekzekutimit të komandave, ne bëjmë një gabim duke treguar OSD-në e kërkuar, do të vendosim një variabël të veçantë, vlera e së cilës do të jetë numri i OSD-së që do të fshihet. Le ta thërrasim atë ${ID} — këtu dhe më poshtë, një variabël i tillë zëvendëson numrin e OSD-së me të cilën po punojmë.

Le të shohim gjendjen para fillimit të punës:

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

Për të nisur heqjen e OSD, do t'ju duhet ta kryeni pa probleme reweight mbi të në zero. Në këtë mënyrë ne zvogëlojmë sasinë e të dhënave në OSD duke e balancuar atë me OSD të tjera. Për ta bërë këtë, ekzekutoni komandat e mëposhtme:

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

... dhe kështu me radhë deri në zero.

Kërkohet balancim i qetënë mënyrë që të mos humbasin të dhënat. Kjo është veçanërisht e vërtetë nëse OSD përmban një sasi të madhe të dhënash. Për tu siguruar që pas ekzekutimit të komandave reweight gjithçka shkoi mirë, mund ta plotësoni ceph -s ose në një dritare të veçantë terminali ceph -w për të vëzhguar ndryshimet në kohë reale.

Kur OSD është "zbrazur", mund të vazhdoni me operacionin standard për ta hequr atë. Për ta bërë këtë, transferoni OSD-në e dëshiruar në gjendje down:

ceph osd down osd.${ID}

Le të "tërheqim" OSD nga grupi:

ceph osd out osd.${ID}

Le të ndalojmë shërbimin OSD dhe të çmontojmë ndarjen e tij në FS:

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

Hiq OSD nga SHKRYMJE harta:

ceph osd crush remove osd.${ID}

Le të fshijmë përdoruesin OSD:

ceph auth del osd.${ID}

Dhe së fundi, le të heqim vetë OSD:

ceph osd rm osd.${ID}

Shënim: Nëse jeni duke përdorur versionin Ceph Luminous ose më të lartë, atëherë hapat e mësipërm të heqjes së OSD mund të reduktohen në dy komanda:

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

Nëse, pasi të keni përfunduar hapat e përshkruar më sipër, ekzekutoni komandën ceph osd tree, atëherë duhet të jetë e qartë se në serverin ku është kryer puna nuk ka më OSD për të cilat janë kryer operacionet e mësipërme:

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

Gjatë rrugës, vini re se gjendja e grupit Ceph do të shkojë HEALTH_WARN, dhe do të shohim gjithashtu një ulje të numrit të OSD-ve dhe sasisë së hapësirës së disponueshme në disk.

Më poshtë do të përshkruajnë hapat që do të kërkohen nëse dëshironi të ndaloni plotësisht serverin dhe, në përputhje me rrethanat, ta hiqni atë nga Ceph. Në këtë rast, është e rëndësishme të mbani mend këtë Përpara se të mbyllni serverin, duhet të hiqni të gjitha OSD-të në këtë server.

Nëse nuk ka më OSD të mbetura në këtë server, atëherë pasi t'i hiqni ato, duhet të përjashtoni serverin nga harta OSD hv-2duke ekzekutuar komandën e mëposhtme:

ceph osd crush rm hv-2

hequr mon nga serveri hv-2duke ekzekutuar komandën më poshtë në një server tjetër (d.m.th. në këtë rast, në hv-1):

ceph-deploy mon destroy hv-2

Pas kësaj, mund të ndaloni serverin dhe të filloni veprimet pasuese (ri-vendosja e tij, etj.).

Rasti nr. 2. Shpërndarja e hapësirës në disk në një grup Ceph të krijuar tashmë

Do ta filloj tregimin e dytë me një parathënie rreth PG (Grupet e vendosjes). Roli kryesor i PG në Ceph është kryesisht për të grumbulluar objekte Ceph dhe për t'i përsëritur më tej ato në OSD. Formula me të cilën mund të llogaritni sasinë e kërkuar të PG është në seksioni përkatës Dokumentacioni Ceph. Aty diskutohet edhe kjo çështje me shembuj konkretë.

Pra: një nga problemet e zakonshme kur përdorni Ceph është numri i pabalancuar i OSD dhe PG midis pishinave në Ceph.

Së pari, për shkak të kësaj, mund të lindë një situatë kur shumë PG specifikohen në një grup të vogël, që në thelb është një përdorim irracional i hapësirës në disk në grup. Së dyti, në praktikë ekziston një problem më serioz: tejmbushja e të dhënave në një nga OSD-të. Kjo kërkon që grupi së pari të kalojë në gjendje HEALTH_WARN, dhe pastaj HEALTH_ERR. Arsyeja për këtë është se Ceph, kur llogarit sasinë e disponueshme të të dhënave (mund ta zbuloni me MAX AVAIL në daljen e komandës ceph df për çdo grup veç e veç) bazohet në sasinë e të dhënave të disponueshme në OSD. Nëse nuk ka hapësirë ​​të mjaftueshme në të paktën një OSD, nuk mund të shkruhen më të dhëna derisa të dhënat të shpërndahen siç duhet në të gjitha OSD.

Vlen të sqarohet se këto probleme vendosen kryesisht në fazën e konfigurimit të grupit Ceph. Një nga mjetet që mund të përdorni është Ceph PGCalc. Me ndihmën e tij, sasia e kërkuar e PG llogaritet qartë. Sidoqoftë, ju gjithashtu mund t'i drejtoheni asaj në një situatë ku grupi Ceph tashmë konfiguruar gabimisht. Vlen të sqarohet këtu se si pjesë e punës së rregullimit, me shumë mundësi do t'ju duhet të zvogëloni numrin e PG-ve dhe kjo veçori nuk është e disponueshme në versionet më të vjetra të Ceph (ai u shfaq vetëm në versionin Nautilus).

Pra, le të imagjinojmë foton e mëposhtme: grupi ka një status HEALTH_WARN për shkak të mungesës së hapësirës së njërës nga OSD. Kjo do të tregohet nga një gabim HEALTH_WARN: 1 near full osd. Më poshtë është një algoritëm për të dalë nga kjo situatë.

Para së gjithash, ju duhet të shpërndani të dhënat e disponueshme midis OSD-ve të mbetura. Ne kemi kryer tashmë një operacion të ngjashëm në rastin e parë, kur "kulluam" nyjen - me të vetmin ndryshim që tani do të duhet të zvogëlojmë pak reweight. Për shembull, deri në 0.95:

ceph osd reweight osd.${ID} 0.95

Kjo liron hapësirën në disk në OSD dhe rregullon gabimin në shëndetin e ceph. Sidoqoftë, siç është përmendur tashmë, ky problem kryesisht ndodh për shkak të konfigurimit të gabuar të Ceph në fazat fillestare: është shumë e rëndësishme të bëhet një rikonfigurim në mënyrë që të mos shfaqet në të ardhmen.

Në rastin tonë të veçantë, gjithçka erdhi në:

  • vlera shumë e lartë replication_count në një nga pishinat,
  • shumë PG në një pishinë dhe shumë pak në një tjetër.

Le të përdorim kalkulatorin e përmendur tashmë. Tregon qartë se çfarë duhet të futet dhe, në parim, nuk ka asgjë të komplikuar. Duke vendosur parametrat e nevojshëm, marrim rekomandimet e mëposhtme:

Shënim: Nëse po krijoni një grup Ceph nga e para, një funksion tjetër i dobishëm i kalkulatorit është gjenerimi i komandave që do të krijojnë grupe nga e para me parametrat e specifikuar në tabelë.

Kolona e fundit ju ndihmon të lundroni - Numri i sugjeruar i PG. Në rastin tonë, i dyti është gjithashtu i dobishëm, ku tregohet parametri i përsëritjes, pasi vendosëm të ndryshojmë shumëzuesin e përsëritjes.

Pra, së pari ju duhet të ndryshoni parametrat e përsëritjes - kjo ia vlen të bëhet së pari, pasi duke zvogëluar shumëzuesin, ne do të çlirojmë hapësirën në disk. Ndërsa komanda ekzekutohet, do të vini re se hapësira e disponueshme e diskut do të rritet:

ceph osd pool $pool_name set $replication_size

Dhe pas përfundimit të tij, ne ndryshojmë vlerat e parametrave pg_num и pgp_num si më poshtë:

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

Është e rëndësishme: duhet të ndryshojmë numrin e PG-ve në mënyrë sekuenciale në çdo grup dhe të mos ndryshojmë vlerat në grupe të tjera derisa paralajmërimet të zhduken "Teprica e degraduar e të dhënave" и "n-numri i fqeve të degraduara".

Ju gjithashtu mund të kontrolloni nëse gjithçka shkoi mirë duke përdorur rezultatet e komandës ceph health detail и ceph -s.

Rasti nr. 3. Migrimi i një makine virtuale nga LVM në Ceph RBD

Në një situatë kur një projekt përdor makina virtuale të instaluara në serverë metalikë të zhveshur me qira, shpesh lind çështja e ruajtjes tolerante ndaj gabimeve. Është gjithashtu shumë e dëshirueshme që të ketë hapësirë ​​të mjaftueshme në këtë memorie... Një situatë tjetër e zakonshme: ekziston një makinë virtuale me ruajtje lokale në server dhe ju duhet të zgjeroni diskun, por nuk ka ku të shkoni, sepse nuk ka hapësirë ​​e lirë në disk e mbetur në server.

Problemi mund të zgjidhet në mënyra të ndryshme - për shembull, duke migruar në një server tjetër (nëse ka një) ose duke shtuar disqe të reja në server. Por nuk është gjithmonë e mundur ta bësh këtë, kështu që migrimi nga LVM në Ceph mund të jetë një zgjidhje e shkëlqyer për këtë problem. Duke zgjedhur këtë opsion, ne gjithashtu thjeshtojmë procesin e mëtejshëm të migrimit midis serverëve, pasi nuk do të ketë nevojë të zhvendoset memoria lokale nga një hipervizor në tjetrin. E vetmja pengesë është se do t'ju duhet të ndaloni VM-në ndërsa puna është duke u kryer.

Receta e mëposhtme është marrë nga artikull nga ky blog, udhëzimet e së cilës janë testuar në veprim. Meqe ra fjala, Aty përshkruhet edhe metoda e migrimit pa probleme, megjithatë, në rastin tonë thjesht nuk ishte e nevojshme, kështu që ne nuk e kontrolluam atë. Nëse kjo është kritike për projektin tuaj, do të jemi të lumtur të dëgjojmë për rezultatet në komente.

Le të kalojmë në pjesën praktike. Në shembull ne përdorim virsh dhe, në përputhje me rrethanat, libvirt. Së pari, sigurohuni që grupi Ceph në të cilin do të migrohen të dhënat është i lidhur me libvirt:

virsh pool-dumpxml $ceph_pool

Përshkrimi i pishinës duhet të përmbajë të dhëna lidhjeje me Ceph me të dhëna autorizimi.

Hapi tjetër është që imazhi LVM të konvertohet në Ceph RBD. Koha e ekzekutimit varet kryesisht nga madhësia e imazhit:

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

Pas konvertimit, do të mbetet një imazh LVM, i cili do të jetë i dobishëm nëse migrimi i VM-së në RBD dështon dhe ju duhet të riktheni ndryshimet. Gjithashtu, për të qenë në gjendje të kthejmë shpejt ndryshimet, le të bëjmë një kopje rezervë të skedarit të konfigurimit të makinës virtuale:

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

... dhe modifikoni origjinalin (vm_name.xml). Le të gjejmë një bllok me një përshkrim të diskut (fillon me rreshtin <disk type='file' device='disk'> dhe përfundon me </disk>) dhe zvogëlojeni atë në formën e mëposhtme:

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

Le të shohim disa detaje:

  1. Tek protokolli source tregohet adresa e ruajtjes në Ceph RBD (kjo është adresa që tregon emrin e pishinës Ceph dhe imazhin RBD, i cili u përcaktua në fazën e parë).
  2. Në bllok secret tregohet lloji ceph, si dhe UUID e sekretit për t'u lidhur me të. Uuid-i i tij mund të gjendet duke përdorur komandën virsh secret-list.
  3. Në bllok host tregohen adresat e monitorëve Ceph.

Pas redaktimit të skedarit të konfigurimit dhe përfundimit të konvertimit LVM në RBD, mund të aplikoni skedarin e modifikuar të konfigurimit dhe të nisni makinën virtuale:

virsh define $vm_name.xml
virsh start $vm_name

Është koha për të kontrolluar nëse makina virtuale filloi saktë: mund ta zbuloni, për shembull, duke u lidhur me të përmes SSH ose përmes virsh.

Nëse makina virtuale po punon si duhet dhe nuk keni gjetur ndonjë problem tjetër, atëherë mund të fshini imazhin LVM që nuk përdoret më:

lvremove main/$vm_image_name

Përfundim

Ne kemi hasur në të gjitha rastet e përshkruara në praktikë - shpresojmë që udhëzimet do të ndihmojnë administratorët e tjerë të zgjidhin probleme të ngjashme. Nëse keni komente ose histori të tjera të ngjashme nga përvoja juaj duke përdorur Ceph, do të jemi të lumtur t'i shohim ato në komente!

PS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Shto një koment