ProHoster > Блог > басқарма > Бос емес жобаларда Цефпен жұмыс істеуге арналған кеңестер мен амалдар

Бос емес жобаларда Цефпен жұмыс істеуге арналған кеңестер мен амалдар

Бос емес жобаларда Цефпен жұмыс істеуге арналған кеңестер мен амалдар

Ceph-ті әртүрлі жүктемелері бар жобаларда желілік сақтау ретінде пайдалану, біз бір қарағанда қарапайым немесе тривиальды болып көрінбейтін әртүрлі тапсырмаларды кездестіруіміз мүмкін. Мысалы:

  • жаңа кластердегі алдыңғы серверлерді ішінара пайдалану арқылы деректерді ескі Ceph-тен жаңасына көшіру;
  • Ceph жүйесінде дискілік кеңістікті бөлу мәселесін шешу.

Осындай проблемаларды шешу үшін біз деректерді жоғалтпай OSD-ны дұрыс жою қажеттілігіне тап болдық, бұл деректердің үлкен көлемімен жұмыс істегенде өте маңызды. Бұл мақалада талқыланады.

Төменде сипатталған әдістер Ceph бағдарламасының кез келген нұсқасына қатысты. Сонымен қатар, Ceph деректердің үлкен көлемін сақтай алатындығы ескерілетін болады: деректердің жоғалуын және басқа мәселелерді болдырмау үшін кейбір әрекеттер бірнеше басқаларға «бөлінеді».

OSD туралы кіріспе

Талқыланған үш рецепттің екеуі OSD-ге арналған (Объектілерді сақтау демоны), практикалық бөлікке кіріспес бұрын - оның Ceph-де не екендігі және оның неге соншалықты маңызды екендігі туралы қысқаша.

Ең алдымен, бүкіл Ceph кластері көптеген OSD-ден тұратынын айту керек. Неғұрлым көп болса, Ceph ішіндегі бос деректер көлемі соғұрлым көп болады. Бұл жерден түсіну оңай негізгі OSD функциясы: Ол Ceph нысанының деректерін барлық кластер түйіндерінің файлдық жүйелерінде сақтайды және оған желілік қатынасты қамтамасыз етеді (оқу, жазу және басқа сұраулар үшін).

Бір деңгейде репликация параметрлері нысандарды әртүрлі экрандық дискілер арасында көшіру арқылы орнатылады. Мұнда сіз әртүрлі мәселелерге тап болуыңыз мүмкін, олардың шешімдері төменде талқыланады.

Іс №1. Деректерді жоғалтпай 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

Экрандық дискіні жоюды бастау үшін біркелкі орындау керек reweight ол бойынша нөлге дейін. Осылайша біз экрандық экрандағы деректердің көлемін басқа экрандық дискілермен теңестіру арқылы азайтамыз. Ол үшін келесі пәрмендерді орындаңыз:

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

... және т.б. нөлге дейін.

Тегіс теңгерім қажетдеректерді жоғалтпау үшін. Бұл әсіресе экрандық дискіде деректердің үлкен көлемі болса дұрыс. Командаларды орындағаннан кейін көз жеткізу үшін reweight бәрі жақсы болды, сіз оны аяқтай аласыз ceph -s немесе бөлек терминал терезесінде іске қосыңыз ceph -w нақты уақыттағы өзгерістерді бақылау үшін.

Экрандық дисплей «босатылған» кезде, оны алып тастау үшін стандартты әрекетті жалғастыруға болады. Ол үшін қалаған OSD күйіне көшіріңіз down:

ceph osd down osd.${ID}

Экрандық дискіні кластерден «тартып алайық»:

ceph osd out osd.${ID}

OSD қызметін тоқтатып, оның бөлімін FS жүйесінен ажыратайық:

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

Экрандық дискіні өшіріңіз CRUSH картасы:

ceph osd crush remove osd.${ID}

OSD пайдаланушысын жойайық:

ceph auth del osd.${ID}

Соңында, экрандық дисплейдің өзін алып тастайық:

ceph osd rm osd.${ID}

ескерту: Ceph Luminous нұсқасын немесе одан жоғары нұсқасын пайдалансаңыз, жоғарыда көрсетілген экрандық дискіні жою қадамдарын екі пәрменге дейін азайтуға болады:

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, сонымен қатар экрандық дискілердің саны мен қол жетімді дискілік кеңістік көлемінің азайғанын көреміз.

Төменде серверді толығымен тоқтатып, сәйкесінше оны Ceph жүйесінен жойғыңыз келсе, қажет болатын қадамдар сипатталады. Бұл жағдайда мұны есте сақтау маңызды Серверді өшірмес бұрын, барлық экрандық дискілерді жою керек осы серверде.

Бұл серверде басқа экрандық дискілер қалмаса, оларды жойғаннан кейін серверді экрандық картадан шығару керек. hv-2келесі пәрменді іске қосу арқылы:

ceph osd crush rm hv-2

Жою mon серверден hv-2төмендегі пәрменді басқа серверде іске қосу арқылы (яғни, бұл жағдайда қосулы hv-1):

ceph-deploy mon destroy hv-2

Осыдан кейін сіз серверді тоқтатып, келесі әрекеттерді бастай аласыз (оны қайта орналастыру және т.б.).

Іс № 2. Құрылған Ceph кластеріндегі дискілік кеңістікті бөлу

Мен екінші әңгімені PG туралы алғы сөзден бастаймын (Орналастыру топтары). Ceph-тегі PG негізгі рөлі, ең алдымен, Ceph нысандарын біріктіру және оларды OSD-де одан әрі көшіру. PG қажетті мөлшерін есептеуге болатын формула бар тиісті бөлім Ceph құжаттамасы. Онда да бұл мәселе нақты мысалдармен талқыланады.

Сонымен: Ceph пайдалану кезіндегі жиі кездесетін мәселелердің бірі - Ceph жүйесіндегі бассейндер арасындағы OSD және PG теңгерімсіз саны.

Біріншіден, осыған байланысты шағын пулда тым көп PG көрсетілген кезде жағдай туындауы мүмкін, бұл кластердегі дискілік кеңістікті ұтымсыз пайдалану болып табылады. Екіншіден, іс жүзінде маңыздырақ мәселе бар: OSD бірінде деректердің толып кетуі. Бұл кластердің бірінші күйге өтуін талап етеді HEALTH_WARN, содан соң HEALTH_ERR. Мұның себебі, Цеф, қол жетімді деректер көлемін есептеу кезінде (оны білуге ​​болады MAX AVAIL пәрмен шығысында ceph df әрбір пул үшін бөлек) экрандық дискідегі қолжетімді деректер көлеміне негізделген. Кем дегенде бір экрандық дискіде орын жеткіліксіз болса, деректер барлық экрандық дискілер арасында дұрыс таратылмайынша, басқа деректер жазылмайды.

Бұл проблемаларды нақтылаған жөн негізінен Ceph кластерін конфигурациялау кезеңінде шешіледі. Сіз қолдануға болатын құралдардың бірі Ceph PGCalc. Оның көмегімен PG қажетті мөлшері нақты есептеледі. Дегенмен, сіз оған Ceph кластері болған жағдайда да жүгіне аласыз қазірдің өзінде қате конфигурацияланған. Түзету жұмыстарының бір бөлігі ретінде сізге PG санын азайту қажет болатынын және бұл мүмкіндік Ceph-тің ескі нұсқаларында қол жетімді емес (ол тек нұсқада пайда болған) екенін түсіндірген жөн. Nautilus).

Сонымен, келесі суретті елестетейік: кластердің мәртебесі бар HEALTH_WARN Экрандық дискінің біреуінің бос орын таусылуына байланысты. Бұл қате арқылы көрсетіледі HEALTH_WARN: 1 near full osd. Төменде бұл жағдайдан шығу алгоритмі берілген.

Ең алдымен, қол жетімді деректерді қалған экрандық дискілер арасында бөлу керек. Біз түйінді «ағызу» кезінде бірінші жағдайда ұқсас операцияны орындадық - жалғыз айырмашылығы, енді аздап азайту керек. reweight. Мысалы, 0.95 дейін:

ceph osd reweight osd.${ID} 0.95

Бұл экрандық дискідегі орынды босатады және 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-саны".

Сондай-ақ, пәрмен шығыстары арқылы бәрі жақсы болғанын тексеруге болады ceph health detail и ceph -s.

Іс №3. Виртуалды машинаны LVM-ден Ceph RBD-ге көшіру

Жоба жалға алынған металл серверлерде орнатылған виртуалды машиналарды пайдаланатын жағдайда, ақауларға төзімді сақтау мәселесі жиі туындайды. Бұл жадта жеткілікті орын болғаны да өте құптарлық... Тағы бір жиі кездесетін жағдай: серверде жергілікті жады бар виртуалды машина бар және дискіні кеңейту керек, бірақ баратын жер жоқ, өйткені ол жерде жоқ. серверде бос дискілік кеңістік қалды.

Мәселені әртүрлі тәсілдермен шешуге болады - мысалы, басқа серверге көшу (бар болса) немесе серверге жаңа дискілерді қосу. Бірақ мұны істеу әрдайым мүмкін емес, сондықтан LVM-ден Цефке көшу бұл мәселенің тамаша шешімі болуы мүмкін. Бұл опцияны таңдау арқылы біз серверлер арасындағы тасымалдаудың одан әрі процесін жеңілдетеміз, өйткені жергілікті жадты бір гипервизордан екіншісіне ауыстырудың қажеті болмайды. Жалғыз нәрсе - жұмыс орындалып жатқанда 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

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

пікір қалдыру