Խորհուրդներ և հնարքներ Ceph-ի հետ զբաղված նախագծերում աշխատելու համար

Օգտագործելով Ceph-ը որպես ցանցային պահեստ տարբեր բեռներով նախագծերում, մենք կարող ենք հանդիպել տարբեր խնդիրների, որոնք առաջին հայացքից պարզ կամ աննշան չեն թվում: Օրինակ:

• տվյալների միգրացիան հին Ceph-ից նորը նոր կլաստերում նախորդ սերվերների մասնակի օգտագործմամբ.
• Ceph-ում սկավառակի տարածքի բաշխման խնդրի լուծում.

Նման խնդիրների հետ առնչվելով՝ մենք բախվում ենք OSD-ն առանց տվյալների կորստի ճիշտ հեռացնելու անհրաժեշտության, ինչը հատկապես կարևոր է մեծ քանակությամբ տվյալների հետ գործ ունենալիս: Սա կքննարկվի հոդվածում:

Ստորև նկարագրված մեթոդները տեղին են Ceph-ի ցանկացած տարբերակի համար: Բացի այդ, հաշվի կառնվի այն փաստը, որ Ceph-ը կարող է մեծ քանակությամբ տվյալներ պահել. տվյալների կորստի և այլ խնդիրների կանխարգելման համար որոշ գործողություններ «կբաժանվեն» մի քանի ուրիշների:

Նախաբան OSD-ի մասին

Քանի որ քննարկված երեք բաղադրատոմսերից երկուսը նվիրված են OSD-ին (Օբյեկտների պահպանման Daemon), նախքան գործնական մասի մեջ մտնելը. հակիրճ այն մասին, թե ինչ է այն Ceph-ում և ինչու է այն այդքան կարևոր:

Նախ, պետք է ասել, որ ամբողջ Ceph կլաստերը բաղկացած է բազմաթիվ OSD-ներից։ Որքան շատ լինեն, այնքան մեծ կլինի Ceph-ի անվճար տվյալների ծավալը: Այստեղից հեշտ է հասկանալ հիմնական OSD գործառույթըԱյն պահում է Ceph օբյեկտի տվյալները բոլոր կլաստերային հանգույցների ֆայլային համակարգերում և ապահովում է ցանցային մուտք դեպի դրանք (կարդալու, գրելու և այլ հարցումների համար):

Նույն մակարդակում, կրկնօրինակման պարամետրերը սահմանվում են տարբեր OSD-ների միջև օբյեկտների պատճենմամբ: Եվ այստեղ դուք կարող եք հանդիպել տարբեր խնդիրների, որոնց լուծումները կքննարկվեն ստորև։

Գործ թիվ 1. Ապահով հեռացրեք OSD-ն Ceph կլաստերից՝ առանց տվյալների կորստի

OSD-ի հեռացման անհրաժեշտությունը կարող է առաջանալ սերվերը կլաստերից հեռացնելու պատճառով, օրինակ՝ այն փոխարինելու մեկ այլ սերվերով, ինչն էլ տեղի ունեցավ մեզ հետ՝ հիմք տալով այս հոդվածի գրմանը: Այսպիսով, մանիպուլյացիայի վերջնական նպատակը տվյալ սերվերի վրա բոլոր OSD-ները և մոնոները հանելն է, որպեսզի այն հնարավոր լինի դադարեցնել:

Հարմարության և իրավիճակից խուսափելու համար, երբ հրամանները կատարելիս սխալ ենք թույլ տալիս նշելով անհրաժեշտ OSD-ը, մենք կսահմանենք առանձին փոփոխական, որի արժեքը կլինի ջնջվող OSD-ի թիվը։ Եկեք զանգենք նրան ${ID} — այստեղ և ներքևում նման փոփոխականը փոխարինում է OSD-ի համարը, որի հետ մենք աշխատում ենք:

Աշխատանքն սկսելուց առաջ նայենք վիճակին.

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-ի հեռացումը սկսելու համար դուք պետք է սահուն կատարեք reweight դրա վրա զրոյի: Այս կերպ մենք նվազեցնում ենք տվյալների քանակը OSD-ում` այն հավասարակշռելով այլ OSD-ների հետ: Դա անելու համար գործարկեք հետևյալ հրամանները.

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

... և այսպես մինչև զրոյի:

Պահանջվում է հարթ հավասարակշռումորպեսզի չկորցնեք տվյալները: Սա հատկապես ճիշտ է, եթե OSD-ն պարունակում է մեծ քանակությամբ տվյալներ: Համոզվելու համար, որ հրամանները կատարելուց հետո reweight ամեն ինչ լավ է անցել, կարող եք ավարտին հասցնել ceph -s կամ առանձին տերմինալի պատուհանում գործարկել ceph -w փոփոխությունները իրական ժամանակում դիտարկելու համար:

Երբ OSD-ը «դատարկվում է», կարող եք անցնել ստանդարտ գործողության՝ այն հեռացնելու համար: Դա անելու համար ցանկալի OSD-ն փոխանցեք պետությանը down:

ceph osd down osd.${ID}

Եկեք «հանենք» OSD-ը կլաստերից.

ceph osd out osd.${ID}

Եկեք դադարեցնենք OSD ծառայությունը և ապամոնտաժենք դրա բաժանումը FS-ում.

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

Հեռացնել OSD-ից CRUSH քարտեզ:

ceph osd crush remove osd.${ID}

Եկեք ջնջենք OSD օգտվողին.

ceph auth del osd.${ID}

Եվ վերջապես, եկեք հանենք ինքնին OSD-ը.

ceph osd rm osd.${ID}

ՆշումԵթե ​​դուք օգտագործում եք Ceph Luminous տարբերակը կամ ավելի բարձր, ապա վերը նշված OSD-ի հեռացման քայլերը կարող են կրճատվել մինչև երկու հրաման.

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

Եթե ​​վերը նկարագրված քայլերն ավարտելուց հետո գործարկեք հրամանը ceph osd tree, ապա պետք է պարզ լինի, որ սերվերի վրա, որտեղ կատարվել է աշխատանքը, այլևս չկան OSD-ներ, որոնց համար կատարվել են վերը նշված գործողությունները.

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

Ճանապարհին նշեք, որ Ceph կլաստերի վիճակը կգնա HEALTH_WARN, և մենք կտեսնենք նաև OSD-ների քանակի և սկավառակի հասանելի տարածքի նվազում:

Հետևյալը նկարագրելու է այն քայլերը, որոնք կպահանջվեն, եթե ցանկանում եք ամբողջովին դադարեցնել սերվերը և, համապատասխանաբար, հեռացնել այն Ceph-ից: Այս դեպքում կարևոր է հիշել դա Նախքան սերվերը անջատելը, դուք պետք է հեռացնեք բոլոր OSD-ները այս սերվերի վրա:

Եթե ​​այս սերվերում այլևս OSD-ներ չեն մնացել, ապա դրանք հեռացնելուց հետո պետք է սերվերը բացառել OSD քարտեզից: hv-2գործարկելով հետևյալ հրամանը.

ceph osd crush rm hv-2

Ջնջել mon սերվերից hv-2գործարկելով ստորև նշված հրամանը մեկ այլ սերվերի վրա (այսինքն՝ այս դեպքում՝ վրա hv-1):

ceph-deploy mon destroy hv-2

Դրանից հետո դուք կարող եք դադարեցնել սերվերը և սկսել հետագա գործողությունները (վերաբաշխել այն և այլն):

Գործ թիվ 2. Սկավառակի տարածության բաշխում արդեն ստեղծված Ceph կլաստերում

Երկրորդ պատմությունը կսկսեմ PG-ի մասին նախաբանով (Տեղաբաշխման խմբեր) PG-ի հիմնական դերը Ceph-ում հիմնականում Ceph օբյեկտների համախմբումն է և դրանք OSD-ում հետագայում կրկնօրինակելը: Բանաձևը, որով կարող եք հաշվարկել PG-ի պահանջվող քանակությունը, կա համապատասխան բաժինը Ceph փաստաթղթեր. Այդ հարցը նույնպես քննարկվում է այնտեղ՝ կոնկրետ օրինակներով։

Այսպիսով, Ceph-ի օգտագործման ժամանակ տարածված խնդիրներից մեկը OSD-ի և PG-ի անհավասարակշռված քանակն է Ceph-ի լողավազանների միջև:

Նախ, դրա պատճառով կարող է առաջանալ մի իրավիճակ, երբ չափից շատ PG-ներ նշված են փոքր լողավազանում, ինչը, ըստ էության, կլաստերի սկավառակի տարածության իռացիոնալ օգտագործում է: Երկրորդ, գործնականում ավելի լուրջ խնդիր կա՝ տվյալների գերհոսք OSD-ներից մեկում: Սա ենթադրում է կլաստերի առաջին անցում դեպի վիճակ HEALTH_WARN, եւ հետո HEALTH_ERR. Սրա պատճառն այն է, որ Ceph-ը տվյալների առկա քանակությունը հաշվարկելիս (կարող եք իմանալ՝ ըստ MAX AVAIL հրամանի ելքում ceph df յուրաքանչյուր լողավազանի համար առանձին) հիմնված է OSD-ում առկա տվյալների քանակի վրա: Եթե ​​առնվազն մեկ OSD-ում բավարար տեղ չկա, այլ տվյալներ չեն կարող գրվել, մինչև տվյալները պատշաճ կերպով բաշխվեն բոլոր OSD-ների միջև:

Արժե պարզաբանել, որ այս խնդիրները հիմնականում որոշվում են Ceph կլաստերի կազմաձևման փուլում. Գործիքներից մեկը, որը կարող եք օգտագործել, այն է Ceph PGCalc. Նրա օգնությամբ հստակ հաշվարկվում է ՊԳ-ի պահանջվող քանակությունը։ Այնուամենայնիվ, դուք կարող եք նաև դիմել այն իրավիճակում, երբ Ceph կլաստերը արդեն սխալ կազմաձևված: Այստեղ արժե պարզաբանել, որ որպես վերանորոգման աշխատանքների մաս, ամենայն հավանականությամբ, ձեզ անհրաժեշտ կլինի նվազեցնել PG-ների քանակը, և այս հատկությունը հասանելի չէ Ceph-ի հին տարբերակներում (այն հայտնվեց միայն տարբերակում: Nautilus).

Այսպիսով, եկեք պատկերացնենք հետևյալ պատկերը՝ կլաստերն ունի կարգավիճակ HEALTH_WARN OSD-ներից մեկի տարածքը սպառվելու պատճառով: Սա կնշվի սխալմամբ HEALTH_WARN: 1 near full osd. Ստորև ներկայացված է այս իրավիճակից դուրս գալու ալգորիթմ:

Նախևառաջ անհրաժեշտ է հասանելի տվյալները բաշխել մնացած OSD-ների միջև: Մենք արդեն կատարել ենք նմանատիպ գործողություն առաջին դեպքում, երբ մենք «ցամաքել ենք» հանգույցը, միայն այն տարբերությամբ, որ այժմ մեզ անհրաժեշտ կլինի մի փոքր նվազեցնել reweight. Օրինակ, մինչև 0.95:

ceph osd reweight osd.${ID} 0.95

Սա ազատում է սկավառակի տարածությունը OSD-ում և ուղղում ceph-ի առողջության սխալը: Սակայն, ինչպես արդեն նշվեց, այս խնդիրը հիմնականում առաջանում է սկզբնական փուլերում Ceph-ի սխալ կազմաձևման պատճառով. շատ կարևոր է կատարել վերակազմավորում, որպեսզի այն հետագայում չհայտնվի:

Մեր կոնկրետ դեպքում ամեն ինչ հանգեցրեց հետևյալին.

• արժեքը չափազանց բարձր է replication_count լողավազաններից մեկում,
• չափազանց շատ PG մի լողավազանում, իսկ մյուսում՝ շատ քիչ:

Եկեք օգտագործենք արդեն նշված հաշվիչը։ Այն հստակ ցույց է տալիս, թե ինչ է պետք մուտքագրել, և, սկզբունքորեն, ոչ մի բարդ բան չկա։ Սահմանելով անհրաժեշտ պարամետրերը, մենք ստանում ենք հետևյալ առաջարկությունները.

ՆշումԵթե ​​դուք զրոյից տեղադրում եք Ceph կլաստեր, ապա հաշվիչի մեկ այլ օգտակար գործառույթ է հրամանների ստեղծումը, որոնք զրոյից աղյուսակում նշված պարամետրերով կստեղծեն լողավազաններ:

Վերջին սյունակը օգնում է ձեզ նավարկելու. Առաջարկվող PG հաշվարկ. Մեր դեպքում օգտակար է նաև երկրորդը, որտեղ նշված է կրկնօրինակման պարամետրը, քանի որ մենք որոշել ենք փոխել կրկնօրինակման բազմապատկիչը։

Այսպիսով, նախ դուք պետք է փոխեք կրկնօրինակման պարամետրերը. դա արժե նախ անել, քանի որ կրճատելով բազմապատկիչը, մենք կազատենք սկավառակի տարածքը: Երբ հրամանը կատարվում է, դուք նկատում եք, որ սկավառակի հասանելի տարածքը կավելանա.

ceph osd pool $pool_name set $replication_size

Եվ դրա ավարտից հետո մենք փոխում ենք պարամետրերի արժեքները pg_num и pgp_num հետեւյալ կերպ.

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

Կարեւոր է,Մենք պետք է հաջորդաբար փոխենք PG-ների քանակը յուրաքանչյուր լողավազանում և չփոխենք արժեքները մյուս լողավազաններում, մինչև նախազգուշացումները չվերանան: «Դեգրադացված տվյալների ավելորդություն» и «n-pgs-ի դեգրադացված թիվը».

Կարող եք նաև ստուգել, ​​որ ամեն ինչ լավ է անցել՝ օգտագործելով հրամանի ելքերը ceph health detail и ceph -s.

Գործ թիվ 3. Վիրտուալ մեքենայի տեղափոխում LVM-ից Ceph RBD

Իրավիճակում, երբ նախագիծը օգտագործում է վիրտուալ մեքենաներ, որոնք տեղադրված են վարձակալված մերկ մետաղական սերվերների վրա, հաճախ առաջանում է անսարքության հանդուրժող պահեստավորման խնդիրը: Նաև շատ ցանկալի է, որ այս պահեստում բավականաչափ տեղ լինի... Մեկ այլ սովորական իրավիճակ՝ սերվերում կա վիրտուալ մեքենա՝ տեղական պահեստով և պետք է ընդլայնել սկավառակը, բայց գնալու տեղ չկա, քանի որ չկա. սերվերի վրա թողնված ազատ սկավառակի տարածություն:

Խնդիրը կարող է լուծվել տարբեր ձևերով, օրինակ՝ տեղափոխելով այլ սերվեր (եթե այդպիսին կա) կամ սերվերին նոր սկավառակներ ավելացնելով: Բայց դա միշտ չէ, որ հնարավոր է անել, ուստի LVM-ից Ceph տեղափոխելը կարող է հիանալի լուծում լինել այս խնդրի համար: Ընտրելով այս տարբերակը՝ մենք նաև պարզեցնում ենք սերվերների միջև միգրացիայի հետագա գործընթացը, քանի որ տեղային պահեստը մեկ հիպերվիզորից մյուսը տեղափոխելու կարիք չի լինի։ Միակ բանը այն է, որ դուք ստիպված կլինեք դադարեցնել VM-ն, մինչ աշխատանքը կատարվում է:

Հետևյալ բաղադրատոմսը վերցված է հոդված այս բլոգից, որի հրահանգները փորձարկվել են գործողության մեջ։ Իմիջայլոց, այնտեղ նկարագրված է նաև անհանգիստ միգրացիայի մեթոդը, սակայն, մեր դեպքում դա պարզապես պետք չէր, ուստի մենք չստուգեցինք։ Եթե ​​սա կարևոր է ձեր նախագծի համար, մենք ուրախ կլինենք մեկնաբանություններում լսել արդյունքների մասին:

Անցնենք գործնական մասին։ Օրինակում մենք օգտագործում ենք virsh և, համապատասխանաբար, libvirt: Նախ, համոզվեք, որ Ceph լողավազանը, որին կտեղափոխվեն տվյալները, միացված է libvirt-ին.

virsh pool-dumpxml $ceph_pool

Լողավազանի նկարագրությունը պետք է պարունակի Ceph-ի միացման տվյալներ՝ թույլտվության տվյալներով:

Հաջորդ քայլն այն է, որ LVM պատկերը վերածվում է Ceph RBD-ի: Կատարման ժամանակը հիմնականում կախված է պատկերի չափից.

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

Փոխարկումից հետո LVM պատկերը կմնա, որը օգտակար կլինի, եթե VM-ի տեղափոխումը RBD ձախողվի, և դուք ստիպված լինեք հետ գլորել փոփոխությունները: Նաև, որպեսզի կարողանանք արագորեն հետաձգել փոփոխությունները, եկեք կրկնօրինակենք վիրտուալ մեքենայի կազմաձևման ֆայլը.

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

... և խմբագրել բնօրինակը (vm_name.xml) Եկեք գտնենք սկավառակի նկարագրությամբ բլոկ (սկսվում է տողով <disk type='file' device='disk'> և ավարտվում է </disk>) և կրճատել այն հետևյալ ձևով.

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

Դիտարկենք որոշ մանրամասներ.

1. Արձանագրությանը source նշվում է Ceph RBD-ում պահեստի հասցեն (սա այն հասցեն է, որը ցույց է տալիս Ceph լողավազանի անվանումը և RBD պատկերը, որը որոշվել է առաջին փուլում):
2. Բլոկում secret տեսակը նշված է ceph, ինչպես նաև դրան միանալու գաղտնիքի UUID-ը։ Նրա uuid-ը կարելի է գտնել հրամանի միջոցով virsh secret-list.
3. Բլոկում host նշված են Ceph մոնիտորների հասցեները:

Կազմաձևման ֆայլը խմբագրելուց և LVM-ի RBD-ի փոխարկումն ավարտելուց հետո կարող եք կիրառել փոփոխված կազմաձևման ֆայլը և գործարկել վիրտուալ մեքենան.

virsh define $vm_name.xml
virsh start $vm_name

Ժամանակն է ստուգել, ​​որ վիրտուալ մեքենան ճիշտ է գործարկվել. կարող եք պարզել, օրինակ, միանալով դրան SSH կամ միջոցով virsh.

Եթե ​​վիրտուալ մեքենան ճիշտ է աշխատում, և դուք որևէ այլ խնդիր չեք գտել, ապա կարող եք ջնջել LVM պատկերը, որն այլևս չի օգտագործվում.

lvremove main/$vm_image_name

Ամփոփում

Մենք գործնականում հանդիպեցինք նկարագրված բոլոր դեպքերին. հուսով ենք, որ հրահանգները կօգնեն այլ ադմինիստրատորներին լուծել նմանատիպ խնդիրները: Եթե ​​դուք ունեք մեկնաբանություններ կամ նմանատիպ այլ պատմություններ Ceph-ի օգտագործման ձեր փորձից, մենք ուրախ կլինենք տեսնել դրանք մեկնաբանություններում:

PS

Կարդացեք նաև մեր բլոգում.

• «Մեր ձեռքերը ձանձրույթի համար չեն. K8s-ում Rook կլաստերի վերականգնում";
• «Ռուկ, թե ոչ Ռուկ, դա է հարցը";
• «Rook - «ինքնասպասարկման» տվյալների պահեստ Kubernetes-ի համար";
• «Համառ պահեստավորման ստեղծում Kubernetes-ում մատակարարմամբ՝ հիմնված Ceph-ի վրա.

Source: www.habr.com