ProHoster > блог > Администрација > Совети и трикови за работа со Ceph во зафатени проекти

Совети и трикови за работа со Ceph во зафатени проекти

Совети и трикови за работа со Ceph во зафатени проекти

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

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

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

Методите опишани подолу се релевантни за која било верзија на Ceph. Дополнително, ќе се земе предвид фактот дека Ceph може да складира голема количина на податоци: за да се спречи губење на податоци и други проблеми, некои активности ќе се „поделат“ на неколку други.

Предговор за OSD

Бидејќи два од трите дискутирани рецепти се посветени на OSD (Демон за складирање на објекти), пред да се нурне во практичниот дел - накратко за тоа што е во Ceph и зошто е толку важно.

Пред сè, треба да се каже дека целиот Ceph кластер се состои од многу OSD. Колку повеќе има, толку е поголем обемот на слободни податоци во Ceph. Од тука е лесно да се разбере главната функција на OSD: Ги складира податоците за објектот Ceph на датотечните системи на сите јазли на кластерот и обезбедува мрежен пристап до нив (за читање, пишување и други барања).

На исто ниво, параметрите за репликација се поставуваат со копирање на објекти помеѓу различни OSD. И тука можете да наидете на различни проблеми, чии решенија ќе се дискутираат понатаму.

Случај бр.1. Безбедно отстранете го OSD од кластерот Ceph без губење податоци

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

За погодност и за да избегнеме ситуација кога при извршувањето на командите ќе направиме грешка при означување на потребната OSD, ќе поставиме посебна променлива, чија вредност ќе биде бројот на OSD што треба да се избрише. Ајде да ја повикаме ${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

За да започнете отстранување на 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 од СЛОЖЕТЕ карта:

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 во Ceph е првенствено да ги собира објектите на Ceph и дополнително да ги реплицира во OSD. Формулата со која можете да ја пресметате потребната количина на PG е во релевантен дел Ceph документација. Таму се зборува и за ова прашање со конкретни примери.

Значи: еден од вообичаените проблеми при користење на Ceph е небалансираниот број на OSD и PG помеѓу базените во Ceph.

Прво, поради ова, може да се појави ситуација кога премногу PG се наведени во мал базен, што во суштина е ирационално користење на просторот на дискот во кластерот. Второ, во пракса постои посериозен проблем: прелевање на податоци во еден од OSD-овите. Ова подразбира кластерот прво да премине во состојбата HEALTH_WARN, и потоа HEALTH_ERR. Причината за ова е што Ceph, при пресметување на расположливиот број на податоци (можете да го дознаете до MAX AVAIL во командниот излез ceph df за секој базен посебно) се заснова на количината на достапни податоци во ОСД. Ако нема доволно простор во барем еден OSD, не може да се напишат повеќе податоци додека податоците не се распределат правилно меѓу сите OSD.

Вреди да се разјасни дека овие проблеми во голема мера се решаваат во фазата на конфигурација на кластерот Ceph. Една од алатките што можете да ги користите е Ceph PGCalc. Со негова помош јасно се пресметува потребната количина на PG. Сепак, можете да прибегнете кон него и во ситуација кога кластерот на 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-број на стр деградирани“.

Можете исто така да проверите дали сè помина добро користејќи ги командните излези 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

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

Извор: www.habr.com

Додадете коментар