ProHoster > Blogs > Administrācija > Padomi un ieteikumi darbam ar Ceph aizņemtos projektos

Padomi un ieteikumi darbam ar Ceph aizņemtos projektos

Padomi un ieteikumi darbam ar Ceph aizņemtos projektos

Izmantojot Ceph kā tÄ«kla krātuvi projektos ar dažādu slodzi, mēs varam saskarties ar dažādiem uzdevumiem, kas no pirmā acu uzmetiena neŔķiet vienkārÅ”i vai triviāli. Piemēram:

  • datu migrÄ“Å”ana no vecā Ceph uz jaunu, daļēji izmantojot iepriekŔējos serverus jaunajā klasterÄ«;
  • risinājums diska vietas pieŔķirÅ”anas problēmai Ceph.

Risinot Ŕādas problēmas, mēs saskaramies ar nepiecieÅ”amÄ«bu pareizi noņemt OSD, nezaudējot datus, kas ir Ä«paÅ”i svarÄ«gi, strādājot ar lielu datu apjomu. Tas tiks apspriests rakstā.

Tālāk aprakstÄ«tās metodes attiecas uz jebkuru Ceph versiju. Turklāt tiks ņemts vērā fakts, ka Ceph var uzglabāt lielu datu apjomu: lai novērstu datu zudumu un citas problēmas, dažas darbÄ«bas tiks ā€œsadalÄ«tasā€ vairākās citās.

PriekŔvārds par OSD

Tā kā divas no trim apspriestajām receptēm ir veltÄ«tas OSD (Objektu glabāŔanas dēmons), pirms iedziļināties praktiskajā daļā - Ä«sumā par to, kas tas ir Ceph un kāpēc tas ir tik svarÄ«gi.

Pirmkārt, jāsaka, ka viss Ceph klasteris sastāv no daudziem OSD. Jo vairāk to ir, jo lielāks ir bezmaksas datu apjoms Ceph. No Å”ejienes to ir viegli saprast galvenā OSD funkcija: tas saglabā Ceph objektu datus visu klasteru mezglu failu sistēmās un nodroÅ”ina tiem piekļuvi tÄ«klam (lasÄ«Å”anai, rakstÄ«Å”anai un citiem pieprasÄ«jumiem).

Tajā paŔā lÄ«menÄ« replikācijas parametri tiek iestatÄ«ti, kopējot objektus starp dažādiem OSD. Un Å”eit jÅ«s varat saskarties ar dažādām problēmām, kuru risinājumi tiks apspriesti tālāk.

Lieta Nr.1. DroÅ”i noņemiet OSD no Ceph klastera, nezaudējot datus

NepiecieÅ”amÄ«bu noņemt OSD var izraisÄ«t servera noņemÅ”ana no klastera, piemēram, lai to aizstātu ar citu serveri. Tas ir tas, kas notika ar mums, un tāpēc tika izveidots Å”is raksts. Tādējādi manipulācijas galvenais mērÄ·is ir iegÅ«t visus OSD un mons uz dotā servera, lai to varētu apturēt.

ĒrtÄ«bas labad un lai izvairÄ«tos no situācijas, kad, izpildot komandas, kļūdāmies, norādot vajadzÄ«go OSD, iestatÄ«sim atseviŔķu mainÄ«go, kura vērtÄ«ba bÅ«s dzÄ“Å”amā OSD numurs. Sauksim viņu ${ID} ā€” Å”eit un tālāk Ŕāds mainÄ«gais aizstāj OSD numuru, ar kuru mēs strādājam.

Apskatīsim stāvokli pirms darba sākŔanas:

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

Lai sāktu OSD noņemÅ”anu, jums bÅ«s jārÄ«kojas vienmērÄ«gi reweight par to uz nulli. Tādā veidā mēs samazinām datu apjomu OSD, lÄ«dzsvarojot to ar citiem OSD. Lai to izdarÄ«tu, palaidiet Ŕādas komandas:

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

... un tā tālāk līdz nullei.

NepiecieÅ”ama vienmērÄ«ga balansÄ“Å”analai nezaudētu datus. Tas jo Ä«paÅ”i attiecas uz gadÄ«jumiem, kad OSD satur lielu datu apjomu. Lai pārliecinātos, ka pēc komandu izpildes reweight viss gāja labi, jÅ«s varat to pabeigt ceph -s vai atseviŔķā termināļa logā palaist ceph -w lai novērotu izmaiņas reāllaikā.

Kad OSD ir ā€œiztukÅ”otsā€, varat turpināt standarta darbÄ«bu, lai to noņemtu. Lai to izdarÄ«tu, pārsÅ«tiet vēlamo OSD uz stāvokli down:

ceph osd down osd.${ID}

ā€œIzvilksimā€ OSD no klastera:

ceph osd out osd.${ID}

Apturēsim OSD pakalpojumu un atvienosim tā nodalījumu FS:

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

Noņemiet OSD no CRUSH karte:

ceph osd crush remove osd.${ID}

Izdzēsīsim OSD lietotāju:

ceph auth del osd.${ID}

Un visbeidzot, noņemsim paÅ”u OSD:

ceph osd rm osd.${ID}

PiezÄ«me: Ja izmantojat Ceph Luminous versiju vai jaunāku, iepriekÅ” minētās OSD noņemÅ”anas darbÄ«bas var samazināt lÄ«dz divām komandām:

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

Ja pēc iepriekÅ” aprakstÄ«to darbÄ«bu veikÅ”anas palaižat komandu ceph osd tree, tad jābÅ«t skaidram, ka serverÄ«, kurā tika veikts darbs, vairs nav OSD, kuriem tika veiktas iepriekÅ” minētās darbÄ«bas:

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

Pa ceļam ņemiet vērā, ka Ceph klastera stāvoklis tiks sasniegts HEALTH_WARN, un mēs redzēsim arÄ« OSD skaita un pieejamās diska vietas samazināŔanos.

Tālāk tiks aprakstÄ«tas darbÄ«bas, kas bÅ«s jāveic, ja vēlaties pilnÄ«bā apturēt serveri un attiecÄ«gi noņemt to no Ceph. Å ajā gadÄ«jumā ir svarÄ«gi to atcerēties Pirms servera izslēgÅ”anas ir jānoņem visi OSD Å”ajā serverÄ«.

Ja Å”ajā serverÄ« vairs nav palicis OSD, tad pēc to noņemÅ”anas serveris jāizslēdz no OSD kartes hv-2izpildot Ŕādu komandu:

ceph osd crush rm hv-2

Noņemt mon no servera hv-2palaižot tālāk norādÄ«to komandu citā serverÄ« (t.i., Å”ajā gadÄ«jumā uz hv-1):

ceph-deploy mon destroy hv-2

Pēc tam varat apturēt serveri un sākt turpmākās darbības (tā atkārtoti izvietot utt.).

Lieta Nr.2. Diska vietas sadalījums jau izveidotā Ceph klasterī

Otro stāstu sākÅ”u ar priekÅ”vārdu par PG (Izvietojuma grupas). PG galvenā loma Ceph ir galvenokārt Ceph objektu apkopoÅ”ana un turpmāka to atkārtoÅ”ana OSD. Formula, ar kuru jÅ«s varat aprēķināt nepiecieÅ”amo PG daudzumu, ir norādÄ«ta attiecÄ«gā sadaļa Ceph dokumentācija. ArÄ« Å”is jautājums tur tiek apspriests ar konkrētiem piemēriem.

Tātad: viena no izplatītākajām problēmām, lietojot Ceph, ir nesabalansētais OSD un PG skaits starp kopumiem Ceph.

Pirmkārt, Ŕī iemesla dēļ var rasties situācija, kad mazā pÅ«lā ir norādÄ«ts pārāk daudz PG, kas bÅ«tÄ«bā ir neracionāla diska vietas izmantoÅ”ana klasterÄ«. Otrkārt, praksē pastāv nopietnāka problēma: datu pārpilde vienā no OSD. Tas nozÄ«mē, ka klasteris vispirms pāriet uz stāvokli HEALTH_WARN, un tad HEALTH_ERR. Iemesls tam ir tas, ka Ceph, aprēķinot pieejamo datu apjomu (to varat uzzināt pēc MAX AVAIL komandas izvadē ceph df katram pÅ«lam atseviŔķi) ir balstÄ«ts uz OSD pieejamo datu apjomu. Ja vismaz vienā OSD nav pietiekami daudz vietas, vairs nevar ierakstÄ«t datus, kamēr dati nav pareizi sadalÄ«ti starp visiem OSD.

Ir vērts precizēt, ka Ŕīs problēmas lielākoties tiek izlemti Ceph klastera konfigurācijas posmā. Viens no rÄ«kiem, ko varat izmantot, ir Ceph PGCalc. Ar tās palÄ«dzÄ«bu tiek skaidri aprēķināts nepiecieÅ”amais PG daudzums. Tomēr jÅ«s varat arÄ« izmantot to situācijā, kad Ceph klasteris jau nepareizi konfigurēts. Å eit ir vērts paskaidrot, ka laboÅ”anas darbu ietvaros jums, visticamāk, bÅ«s jāsamazina PG skaits, un Ŕī funkcija nav pieejama vecākās Ceph versijās (tā parādÄ«jās tikai versijā MÄ«kstmiesis).

Tātad, iedomāsimies Ŕādu attēlu: klasterim ir statuss HEALTH_WARN jo vienam no OSD pietrÅ«kst vietas. Par to tiks norādÄ«ta kļūda HEALTH_WARN: 1 near full osd. Zemāk ir algoritms, kā izkļūt no Ŕīs situācijas.

Pirmkārt, jums ir jāsadala pieejamie dati starp atlikuÅ”ajiem OSD. Mēs jau veicām lÄ«dzÄ«gu darbÄ«bu pirmajā gadÄ«jumā, kad mēs ā€œiztukÅ”ojāmā€ mezglu - ar vienÄ«go atŔķirÄ«bu, ka tagad mums bÅ«s nedaudz jāsamazina reweight. Piemēram, lÄ«dz 0.95:

ceph osd reweight osd.${ID} 0.95

Tas atbrÄ«vo diska vietu OSD un novērÅ” ceph veselÄ«bas kļūdu. Tomēr, kā jau minēts, Ŕī problēma galvenokārt rodas nepareizas Ceph konfigurācijas dēļ sākotnējos posmos: ir ļoti svarÄ«gi veikt pārkonfigurāciju, lai tā neparādÄ«tos nākotnē.

MÅ«su konkrētajā gadÄ«jumā viss beidzās Ŕādi:

  • vērtÄ«ba ir pārāk augsta replication_count vienā no baseiniem,
  • pārāk daudz PG vienā baseinā un pārāk maz citā.

Izmantosim jau minēto kalkulatoru. Tas skaidri parāda, kas jāievada, un principā nav nekā sarežģīta. Pēc nepiecieÅ”amo parametru iestatÄ«Å”anas mēs saņemam Ŕādus ieteikumus:

PiezÄ«me: Ja Ceph klasteri iestatāt no jauna, vēl viena noderÄ«ga kalkulatora funkcija ir komandu Ä£enerÄ“Å”ana, kas no jauna izveidos pÅ«lus ar tabulā norādÄ«tajiem parametriem.

Pēdējā kolonna palīdz jums orientēties - Ieteicamais PG skaits. Mūsu gadījumā noder arī otrais, kur norādīts replikācijas parametrs, jo nolēmām mainīt replikācijas reizinātāju.

Tātad, vispirms ir jāmaina replikācijas parametri - vispirms ir vērts to izdarīt, jo, samazinot reizinātāju, mēs atbrīvosim vietu diskā. Kad komanda tiek izpildīta, pamanīsit, ka palielināsies pieejamā vieta diskā:

ceph osd pool $pool_name set $replication_size

Un pēc tā pabeigÅ”anas mēs mainām parametru vērtÄ«bas pg_num Šø pgp_num Ŕādi:

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

Tas ir svarÄ«gi: mums ir jāmaina PG skaits secÄ«gi katrā pÅ«lā un nemaina vērtÄ«bas citos baseinos, kamēr brÄ«dinājumi nav pazuduÅ”i "Pazemināta datu dublÄ“Å”ana" Šø "n-degradēto lapu skaits".

Varat arÄ« pārbaudÄ«t, vai viss noritēja labi, izmantojot komandu izejas ceph health detail Šø ceph -s.

Lieta Nr.3. Virtuālās maŔīnas migrÄ“Å”ana no LVM uz Ceph RBD

Situācijā, kad projektā tiek izmantotas virtuālās maŔīnas, kas uzstādÄ«tas uz Ä«rētām plikmetāla serveriem, bieži rodas jautājums par kļūdu izturÄ«gu krātuvi. Ä»oti vēlams arÄ«, lai Å”ajā krātuvē bÅ«tu pietiekami daudz vietas... Vēl viena izplatÄ«ta situācija: uz servera atrodas virtuālā maŔīna ar lokālo atmiņu un vajag paplaÅ”ināt disku, bet nav kur iet, jo nav serverÄ« palikusi brÄ«va vieta diskā.

Problēmu var atrisināt dažādi ā€“ piemēram, migrējot uz citu serveri (ja tāds ir) vai pievienojot serverim jaunus diskus. Taču ne vienmēr to ir iespējams izdarÄ«t, tāpēc migrÄ“Å”ana no LVM uz Ceph var bÅ«t lielisks Ŕīs problēmas risinājums. Izvēloties Å”o opciju, mēs arÄ« vienkārÅ”ojam turpmāko migrācijas procesu starp serveriem, jo ā€‹ā€‹nebÅ«s jāpārvieto lokālā krātuve no viena hipervizora uz citu. VienÄ«gā problēma ir tāda, ka jums bÅ«s jāpārtrauc VM, kamēr darbs tiek veikts.

SekojoŔā recepte ir ņemta no raksts no Ŕī emuāra, kuras norādÄ«jumi ir pārbaudÄ«ti darbÄ«bā. Starp citu, tur ir aprakstÄ«ta arÄ« bezproblēmu migrācijas metode, tomēr mÅ«su gadÄ«jumā tas vienkārÅ”i nebija vajadzÄ«gs, tāpēc nepārbaudÄ«jām. Ja tas ir bÅ«tiski jÅ«su projektam, mēs ar prieku uzzināsim par rezultātiem komentāros.

Pārejam uz praktisko daļu. Piemērā lietojam virsh un attiecīgi libvirt. Vispirms pārliecinieties, vai Ceph pūls, uz kuru tiks migrēti dati, ir savienots ar libvirt:

virsh pool-dumpxml $ceph_pool

Pūla aprakstā ir jāietver savienojuma dati ar Ceph ar autorizācijas datiem.

Nākamais solis ir tas, ka LVM attēls tiek pārveidots par Ceph RBD. Izpildes laiks galvenokārt ir atkarīgs no attēla lieluma:

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

Pēc konvertÄ“Å”anas paliks LVM attēls, kas noderēs, ja VM migrÄ“Å”ana uz RBD neizdodas un izmaiņas ir jāatceļ. Turklāt, lai varētu ātri atsaukt izmaiņas, izveidosim virtuālās maŔīnas konfigurācijas faila dublējumu:

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

... un rediģēt oriÄ£inālu (vm_name.xml). AtradÄ«sim bloku ar diska aprakstu (sākas ar rindiņu <disk type='file' device='disk'> un beidzas ar </disk>) un samaziniet to lÄ«dz Ŕādai formai:

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

Apskatīsim dažas detaļas:

  1. Uz protokolu source ir norādÄ«ta adrese krātuvei Ceph UBR (Ŕī ir adrese, kas norāda Ceph baseina nosaukumu un UBR attēlu, kas tika noteikts pirmajā posmā).
  2. Blokā secret veids ir norādīts ceph, kā arī noslēpuma UUID, lai ar to izveidotu savienojumu. Tās uuid var atrast, izmantojot komandu virsh secret-list.
  3. Blokā host ir norādītas Ceph monitoru adreses.

Pēc konfigurācijas faila rediģēŔanas un LVM konvertÄ“Å”anas uz RBD pabeigÅ”anas varat lietot modificēto konfigurācijas failu un startēt virtuālo maŔīnu:

virsh define $vm_name.xml
virsh start $vm_name

Ir pienācis laiks pārbaudÄ«t, vai virtuālā maŔīna startēja pareizi: to varat uzzināt, piemēram, pieslēdzoties tai caur SSH vai virsh.

Ja virtuālā maŔīna darbojas pareizi un citas problēmas nav atrastas, varat izdzēst LVM attēlu, kas vairs netiek izmantots:

lvremove main/$vm_image_name

Secinājums

Ar visiem aprakstÄ«tajiem gadÄ«jumiem saskārāmies praksē ā€“ ceram, ka norādÄ«jumi palÄ«dzēs citiem administratoriem atrisināt lÄ«dzÄ«gas problēmas. Ja jums ir komentāri vai citi lÄ«dzÄ«gi stāsti no jÅ«su pieredzes, izmantojot Ceph, mēs ar prieku tos redzēsim komentāros!

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru