Савети и трикови за рад са Цепх-ом у заузетим пројектима

Користећи Цепх као мрежно складиште у пројектима са различитим оптерећењем, можемо наићи на разне задатке који на први поглед не делују једноставно или тривијално. На пример:

• миграција података са старог Цепх-а на нови уз делимично коришћење претходних сервера у новом кластеру;
• решење проблема алокације простора на диску у Цепх-у.

Суочавајући се са оваквим проблемима, суочавамо се са потребом да исправно уклонимо ОСД без губитка података, што је посебно важно када се ради са великим количинама података. О томе ће бити речи у чланку.

Методе описане у наставку су релевантне за било коју верзију Цепх-а. Поред тога, биће узета у обзир чињеница да Цепх може да складишти велику количину података: да би се спречио губитак података и други проблеми, неке акције ће бити „поделе“ на неколико других.

Предговор о ОСД-у

Пошто су два од три разматрана рецепта посвећена ОСД (Демон за складиштење објеката), пре него што пређемо на практични део - укратко о томе шта је то у Цепх-у и зашто је толико важно.

Пре свега, треба рећи да се цео Цепх кластер састоји од много ОСД-а. Што их је више, већи је обим бесплатних података у Цепх-у. Одавде је лако разумети главна ОСД функција: Чува податке Цепх објеката на системима датотека свих чворова кластера и обезбеђује приступ мрежи (за читање, писање и друге захтеве).

На истом нивоу, параметри репликације се постављају копирањем објеката између различитих ОСД-ова. И овде можете наићи на различите проблеме, чија решења ће бити размотрена у наставку.

Случај број 1. Безбедно уклоните ОСД из Цепх кластера без губитка података

Потреба за уклањањем ОСД-а може бити узрокована уклањањем сервера из кластера – на пример, да бисмо га заменили другим сервером – што нам се и догодило, што је довело до писања овог чланка. Дакле, крајњи циљ манипулације је да се извуку сви ОСД-ови и монс на датом серверу тако да се може зауставити.

Ради погодности и да бисмо избегли ситуацију у којој направимо грешку у одређивању потребног ОСД-а током извршавања команди, поставићемо посебну променљиву, чија ће вредност бити број ОСД-а који треба да се обрише. Хајде да је позовемо ${ID} — овде и испод, таква променљива замењује број ОСД-а са којим радимо.

Погледајмо стање пре почетка рада:

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 у циљу посматрања промена у реалном времену.

Када се ОСД „испразни“, можете наставити са стандардном операцијом да га уклоните. Да бисте то урадили, пренесите жељени ОСД у стање down:

ceph osd down osd.${ID}

Хајде да „извучемо“ ОСД из кластера:

ceph osd out osd.${ID}

Зауставимо ОСД услугу и искључимо њену партицију у ФС:

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

Уклоните ОСД из ЦРУСХ мап:

ceph osd crush remove osd.${ID}

Хајде да избришемо ОСД корисника:

ceph auth del osd.${ID}

И на крају, уклонимо сам ОСД:

ceph osd rm osd.${ID}

Приметити: Ако користите Цепх Луминоус верзију или новију, горе наведени кораци за уклањање ОСД-а могу се свести на две команде:

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

Ако, након што завршите горе описане кораке, покренете команду ceph osd tree, онда би требало да буде јасно да на серверу на коме је посао обављен више не постоје ОСД за које су извршене горе наведене операције:

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

Успут, имајте на уму да ће стање Цепх кластера ићи у HEALTH_WARN, а такође ћемо видети смањење броја ОСД-ова и количине доступног простора на диску.

У наставку ће бити описани кораци који ће бити потребни ако желите да потпуно зауставите сервер и, сходно томе, уклоните га са Цепх-а. У овом случају, важно је то запамтити Пре искључивања сервера, морате уклонити све ОСД-ове на овом серверу.

Ако на овом серверу нема више ОСД-ова, онда након што их уклоните, морате искључити сервер са ОСД мапе hv-2покретањем следеће команде:

ceph osd crush rm hv-2

Избриши mon са сервера hv-2покретањем наредбе испод на другом серверу (тј. у овом случају, на hv-1):

ceph-deploy mon destroy hv-2

Након тога, можете зауставити сервер и започети следеће радње (поновно постављање, итд.).

Случај број 2. Дистрибуција простора на диску у већ креираном Цепх кластеру

Другу причу започећу предговором о ПГ (Групе пласмана). Главна улога ПГ-а у Цепх-у је првенствено да агрегира Цепх објекте и даље их реплицира у ОСД-у. Формула помоћу које можете израчунати потребну количину ПГ је унутра релевантног одељка Цепх документација. Тамо се и о овом питању говори на конкретним примерима.

Дакле: један од уобичајених проблема при коришћењу Цепх-а је неуравнотежен број ОСД-а и ПГ-а између скупова у Цепх-у.

Прво, због тога може настати ситуација када је превише ПГ-ова наведено у малом скупу, што је у суштини нерационално коришћење простора на диску у кластеру. Друго, у пракси постоји озбиљнији проблем: преливање података у једном од ОСД-а. Ово подразумева да кластер прво прелази у стање HEALTH_WARN, и онда HEALTH_ERR. Разлог за то је што Цепх, приликом израчунавања расположиве количине података (можете то сазнати на MAX AVAIL у излазу команде ceph df за сваки скуп посебно) заснива се на количини доступних података у ОСД-у. Ако нема довољно простора у најмање једном ОСД-у, више података се не може писати док се подаци правилно не распореде међу свим ОСД-има.

Вреди појаснити да су ови проблеми се углавном одлучују у фази конфигурације Цепх кластера. Један од алата који можете користити је Цепх ПГЦалц. Уз његову помоћ, потребна количина ПГ је јасно израчуната. Међутим, можете да прибегнете томе иу ситуацији када је кластер Цепх већ погрешно конфигурисана. Овде је вредно појаснити да ћете као део поправке највероватније морати да смањите број ПГ-ова, а ова функција није доступна у старијим верзијама Цепх-а (појавила се само у верзији наутилус).

Дакле, замислимо следећу слику: кластер има статус HEALTH_WARN због тога што је једном од ОСД-а понестало простора. Ово ће бити назначено грешком HEALTH_WARN: 1 near full osd. Испод је алгоритам за излазак из ове ситуације.

Пре свега, потребно је да расподелите доступне податке између преосталих ОСД-ова. Већ смо извршили сличну операцију у првом случају, када смо „исушили“ чвор - са једином разликом што ћемо сада морати мало да смањимо reweight. На пример, до 0.95:

ceph osd reweight osd.${ID} 0.95

Ово ослобађа простор на диску у ОСД-у и поправља грешку у здрављу цепх-а. Међутим, као што је већ поменуто, овај проблем се углавном јавља због нетачне конфигурације Цепх-а у почетним фазама: веома је важно извршити реконфигурацију како се не би појавио у будућности.

У нашем конкретном случају, све се свело на:

• вредност превисока replication_count у једном од базена,
• превише ПГ у једном базену и премало у другом.

Хајде да користимо већ поменути калкулатор. Јасно показује шта треба унети и, у принципу, нема ништа компликовано. Након постављања потребних параметара, добијамо следеће препоруке:

Приметити: Ако постављате Цепх кластер од нуле, још једна корисна функција калкулатора је генерисање команди које ће креирати групе од нуле са параметрима наведеним у табели.

Последња колона вам помаже да се крећете - Предложени број ПГ. У нашем случају је користан и други, где је назначен параметар репликације, пошто смо одлучили да променимо множилац репликације.

Дакле, прво морате да промените параметре репликације - ово је вредно урадити прво, јер ћемо смањењем множитеља ослободити простор на диску. Како се команда извршава, приметићете да ће се расположиви простор на диску повећати:

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

То је важно: морамо мењати број ПГ секвенцијално у сваком скупу и не мењати вредности ​​​​у другим групама док упозорења не нестану „Деградирана редундантност података“ и "н-број деградираних стр.".

Такође можете проверити да ли је све прошло добро користећи излазе команде ceph health detail и ceph -s.

Случај број 3. Миграција виртуелне машине са ЛВМ на Цепх РБД

У ситуацији када пројекат користи виртуелне машине инсталиране на изнајмљеним серверима, често се јавља питање складиштења отпорног на грешке. Такође је веома пожељно да у овом складишту има довољно простора... Још једна уобичајена ситуација: на серверу постоји виртуелна машина са локалним складиштем и треба да проширите диск, али нема где да идете, јер нема слободан простор на диску који је остао на серверу.

Проблем се може решити на различите начине - на пример, миграцијом на други сервер (ако постоји) или додавањем нових дискова на сервер. Али то није увек могуће учинити, тако да миграција са ЛВМ-а на Цепх може бити одлично решење за овај проблем. Избором ове опције поједностављујемо и даљи процес миграције између сервера, јер неће бити потребе за премештањем локалног складишта са једног хипервизора на други. Једина квака је у томе што ћете морати да зауставите ВМ док се посао обавља.

Следећи рецепт је преузет из чланак са овог блога, чија су упутства тестирана на делу. Између осталог, тамо је такође описан метод миграције без проблема, међутим, у нашем случају то једноставно није било потребно, па га нисмо проверавали. Ако је ово критично за ваш пројекат, биће нам драго да чујемо о резултатима у коментарима.

Пређимо на практични део. У примеру користимо вирсх и, сходно томе, либвирт. Прво, уверите се да је Цепх група у коју ће подаци бити мигрирани повезана са либвирт-ом:

virsh pool-dumpxml $ceph_pool

Опис базена мора да садржи податке о вези са Цепх-ом са подацима о ауторизацији.

Следећи корак је да се ЛВМ слика конвертује у Цепх РБД. Време извршења зависи првенствено од величине слике:

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

Након конверзије, ЛВМ слика ће остати, што ће бити корисно ако миграција ВМ-а на РБД не успе и морате да вратите промене. Такође, да бисмо могли брзо да вратимо промене, направимо резервну копију конфигурационе датотеке виртуелне машине:

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 назначена је адреса складишта у Цепх РБД (ово је адреса која означава назив Цепх базена и РБД слику, која је одређена у првој фази).
2. У блоку secret тип је назначен ceph, као и УУИД тајне за повезивање са њом. Његов ууид се може пронаћи помоћу команде virsh secret-list.
3. У блоку host назначене су адресе Цепх монитора.

Након што уредите конфигурациону датотеку и завршите конверзију ЛВМ у РБД, можете применити измењену конфигурациону датотеку и покренути виртуелну машину:

virsh define $vm_name.xml
virsh start $vm_name

Време је да проверите да ли је виртуелна машина исправно покренута: можете сазнати, на пример, повезивањем на њу преко ССХ или преко virsh.

Ако виртуелна машина ради исправно и нисте пронашли друге проблеме, онда можете да избришете ЛВМ слику која се више не користи:

lvremove main/$vm_image_name

Закључак

У пракси смо се сусрели са свим описаним случајевима - надамо се да ће упутства помоћи другим администраторима да реше сличне проблеме. Ако имате коментаре или друге сличне приче из свог искуства коришћења Цепх-а, биће нам драго да их видимо у коментарима!

ПС

Прочитајте и на нашем блогу:

• «Наше руке нису за досаду: враћање Роок кластера у К8с";
• «Топу или не Топу - то је питање";
• «Роок - „самоуслужно“ складиште података за Кубернетес";
• «Креирање трајног складишта са обезбеђивањем у Кубернетесу заснованом на Цепх-у'.

Извор: ввв.хабр.цом