ProHoster > Blogs > Administrācija > Ceph ā€” no Ā«uz papÄ«raĀ» lÄ«dz Ā«ražoÅ”anaĀ»

Ceph ā€” no Ā«uz papÄ«raĀ» lÄ«dz Ā«ražoÅ”anaĀ»

Ceph izvēle. 1. daļa

Mums bija piecas kastes, desmit optiskie slēdži, konfigurēts BGP, pāris desmiti SSD un kaudze SAS diskus visās krāsās un izmēros, kā arÄ« proxmox un vēlÄ“Å”anās ievietot visu statiku savā S3 krātuvē. Ne jau tas viss bija nepiecieÅ”ams virtualizācijai, bet, ja jau sāku izmantot opensource, tad ir jādara viss pa nopietno. VienÄ«gais, kas mani uztrauca ā€” tas bija BGP. Pasaulē nav neviena bezpalÄ«dzÄ«gāka, bezatbildÄ«gāka un amorālāka par iekŔējo marÅ”rutÄ“Å”anu pa BGP. Un es zināju, ka diezgan drÄ«z mēs tajā iedziļināsimies.

Ceph ā€” no Ā«uz papÄ«raĀ» lÄ«dz Ā«ražoÅ”anaĀ»

Uzdevums bija vienkārÅ”s ā€” bija Ceph, kas darbojās ne Ä«paÅ”i labi. Vajadzēja izdarÄ«t to "normāli".
Mani uzticētā klastera struktÅ«ra bija dažāda, ātri konfigurēta un praktiski netunēta. Tas sastāvēja no divām dažādu mezglu grupām ar vienu kopēju tÄ«klu, kas kalpoja gan kā klastera, gan publiskais tÄ«kls. Mezgli tika apgādāti ar četriem disku veidiem ā€” diviem SSD veidiem, kas tika savākti divās atseviŔķās izvietojuma shēmās, un diviem HDD dažādos izmēros, kas tika grupēti treÅ”ajā grupā. Problēma ar dažādajiem izmēriem tika atrisināta ar dažādiem OSD svariem.

PaÅ”u konfigurāciju sadalÄ«jām divās daļās ā€” operētājsistēmas tuningā un un paÅ”a Ceph tuningā un viņa iestatÄ«jumos.

OS jaunināŔana

TÄ«kls

Augsts latentums ietekmēja gan ierakstu, gan balansÄ“Å”anu. Ieraksta laikā ā€” jo klients nesaņems atbildi par veiksmÄ«gu ierakstu, kamēr dati citās izvietojuma grupās nepārbaudÄ«s panākumus. Tā kā repliku sadales noteikumi CRUSH kartē bija ar vienu repliku uz host, tÄ«kls tika izmantots vienmēr.

Tādēļ pirmais solis bija nedaudz noregulēt esoÅ”o tÄ«klu, vienlaikus cenÅ”oties pārliecināt par pāreju uz atseviŔķiem tÄ«kliem.

Vispirms uzliku uzstādījumus tīkla kartēm. Sāku ar rindas uzstādījumiem:

kas bija:

ethtool -l ens1f1

root@ceph01:~# ethtool -l ens1f1
Kanālu parametri ens1f1:
IepriekŔ iestatītās maksimumi:
RX:     0
TX:     0
Cits:      1
Kopā:   63
PaÅ”reizējie aparatÅ«ras iestatÄ«jumi:
RX:     0
TX:     0
Cits:      1
Kopā:   1
root@ceph01:~# ethtool -g ens1f1
Rindas parametri ens1f1:
IepriekŔ iestatītās maksimumi:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
PaÅ”reizējie aparatÅ«ras iestatÄ«jumi:
RX:     256
RX Mini:    0
RX Jumbo:   0
TX:     256
root@ceph01:~# ethtool -l ens1f1
Kanālu parametri ens1f1:
IepriekŔ iestatītās maksimumi:
RX:     0
TX:     0
Cits:      1
Kopā:   63
PaÅ”reizējie aparatÅ«ras iestatÄ«jumi:
RX:     0
TX:     0
Cits:      1
Kopā:   1

Redzams, ka paÅ”reizējie parametri ir tālu no maksimumiem. Palielināju:

root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63

Vadoties pēc lieliskas raksta

https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/

palielināju sūtīŔanas rindas garumu txqueuelen no 1000 līdz 10 000

root@ceph01:~#ip link set ens1f0 txqueuelen 10000

Un sekojot ceph dokumentācijai

https://ceph.com/geen-categorie/ceph-loves-jumbo-frames/

palielināju MTU līdz 9000.

root@ceph01:~#ip link set dev ens1f0 mtu 9000

Pievienots ../etc/network/interfaces, lai viss iepriekÅ”minētais ielādētos startējot

cat /etc/network/interfaces

root@ceph01:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto ens1f0
iface ens1f0 inet manual
post-up /sbin/ethtool -G ens1f0 rx 4096
post-up /sbin/ethtool -G ens1f0 tx 4096
post-up /sbin/ethtool -L ens1f0 combined 63
post-up /sbin/ip link set ens1f0 txqueuelen 10000
mtu 9000

auto ens1f1
iface ens1f1 inet manual
post-up /sbin/ethtool -G ens1f1 rx 4096
post-up /sbin/ethtool -G ens1f1 tx 4096
post-up /sbin/ethtool -L ens1f1 combined 63
post-up /sbin/ip link set ens1f1 txqueuelen 10000
mtu 9000

Pēc tam, sekojot Å”ai paÅ”ai rakstā, sāku apdomÄ«gi uzstādÄ«t kodola 4.15 iestatÄ«jumus. Ņemot vērā, ka mezgliem ir 128G RAM, izveidojās kāds konfigurācijas fails sysctl

cat /etc/sysctl.d/50-ceph.conf

net.core.rmem_max = 56623104  
#Maksimālais datu pieņemÅ”anas bufera lielums visiem savienojumiem  54M

net.core.wmem_max = 56623104
#Maksimālais datu pārsūtīŔanas bufera lielums visiem savienojumiem 54M

net.core.rmem_default = 56623104
#Datu pieņemÅ”anas bufera lielums pēc noklusējuma visiem savienojumiem. 54M

net.core.wmem_default = 56623104
#Datu pārsÅ«tÄ«Å”anas bufera lielums pēc noklusējuma visiem savienojumiem 54M  
# katram soketam

net.ipv4.tcp_rmem = 4096 87380 56623104
#Vektora (minimālais, pēc noklusējuma, maksimālais) mainīgais tcp_rmem failā
# satur 3 vesels skaitļus, kas nosaka TCP soketu pieņemÅ”anas bufera lielumu.
# Minimālais: katram TCP soketam ir tiesÄ«bas izmantot Å”o atmiņu
# tā izveidoÅ”anas brÄ«dÄ«. Šāda bufera izmantoÅ”anas iespēja
# tiek garantēta pat sasniedzot ierobežojuma slieksni (vidēja atmiņas spiediena).
# Minimālā bufera noklusējuma izmērs ir 8 Kbaiti (8192).
# Noklusējuma vērtība: atmiņas daudzums, kas tiek pieņemts
# TCP soketa pārsÅ«tÄ«Å”anas buferim pēc noklusējuma. Å Ä« vērtÄ«ba tiek izmantota
# kā aizvietotājs parametram /proc/sys/net/core/rmem_default, ko izmanto
# citi protokoli.
# Noklusējuma izmēra buferis parasti (pēc noklusējuma)
# ir 87830 baiti. Tas nosaka loga izmēru 65535
# ar noklusējuma tcp_adv_win_scale un tcp_app_win = 0, 
# nedaudz mazāku nekā normālo tcp_app_win noklusējuma vērtību.
# Maksimālais: maksimālais bufera lielums, kas var tikt automātiski
# pieŔķirts TCP pieņemÅ”anai. Å Ä« vērtÄ«ba neaizvieto maksimālo,
# kas norādīts failā /proc/sys/net/core/rmem_max. Statiskas
# atmiņas pieŔķirÅ”anas gadÄ«jumā, izmantojot SO_RCVBUF, Å”is parametrs nav spēkā.

net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000    
# Maksimālais atvērto soketu skaits, kas gaida savienojumus.

net.ipv4.tcp_timestamps=1
# Atļauj izmantot laika zīmogus (timestamps), atbilstoŔi RFC 1323.

net.ipv4.tcp_sack=1
# Atļaut izvēles apstiprinājumus TCP protokolā

net.core.netdev_max_backlog=5000 (noklusējums 1000)
# maksimālais paketu skaits rindā apstrādei, ja
# interfeiss saņem paketus ātrāk, nekā kodols tos spēj apstrādāt.

net.ipv4.tcp_max_tw_buckets=262144
# Maksimālais soketu skaits, kas vienlaicīgi atrodas TIME-WAIT stāvoklī.
# Pārsniedzot Ŕo slieksni, "liekais" sokets tiek iznīcināts un tiek ierakstīts
# ziņojums sistēmas žurnālā.

net.ipv4.tcp_tw_reuse=1
#Atļaujam atkārtotu izmantoŔanu TIME-WAIT soketiem gadījumos,
# ja protokols to uzskata par droŔu.

net.core.optmem_max=4194304
#Palielināt maksimālo kopējo buferizÄ“Å”anas ALLOCATABLE
# izmēru, kas mērīts lapas vienībās (4096 biti)

net.ipv4.tcp_low_latency=1
#Atļauj TCP/IP stekam dot priekŔroku zema laika aizkavei
# pirms augstāka caurlaidspēja.

net.ipv4.tcp_adv_win_scale=1
# Šis mainīgais ietekmē atmiņas apjoma aprēķinu soketa buferī,
# ko pieŔķir TCP loga izmēram un lietotnes buferim.
# Ja vērtība tcp_adv_win_scale ir negatīva, tad izmanto nākamo izteiksmi:
# Bytes- bytes2 pakāpē -tcp_adv_win_scale
# Kur bytes ā€“ ir loga izmērs baitos. Ja vērtÄ«ba tcp_adv_win_scale
# ir pozitīva, tad izmanto nākamo izteiksmi:
# Bytes- bytes2 pakāpē tcp_adv_win_scale
# Mainīgais pieņem veselu skaitli. Noklusējuma vērtība ir 2,
# t.i., lietotnes buferim tiek pieŔķirta Ā¼ daļa no apjoma, ko nosaka mainÄ«gais
# tcp_rmem.

net.ipv4.tcp_slow_start_after_idle=0
# lēnas palaiÅ”anas mehānisms, kas atiestata loga slodzes
# vērtību, ja savienojums nav ticis izmantots noteiktu laiku.
# Labāk izslēgt SSR serverī, lai uzlabotu
# ilgstoÅ”u savienojumu veiktspēju.

net.ipv4.tcp_no_metrics_save=1
#Nesaglabāt TCP savienojuma mērÄ«jumu rezultātus keŔā, kad tas tiek slēgts.

net.ipv4.tcp_syncookies=0
#Izslēgt syncookie sÅ«tÄ«Å”anas mehānismu

net.ipv4.tcp_ecn=0
#Explicit Congestion Notification (Skaidrs Pārslodzes Paziņojums) TCP
# savienojumos. Tiek izmantots, lai paziņotu par "sastrēgumu"
# marŔrutā uz norādīto host vai tīklu. Var izmantot,
# lai paziņotu sÅ«tÄ«tājam par nepiecieÅ”amÄ«bu samazināt paketu pārsÅ«tÄ«Å”anas ātrumu caur
# konkrētu marÅ”rutētāju vai ugunsmÅ«ri.

net.ipv4.conf.all.send_redirects=0
# izslēdz ICMP Redirect sÅ«tÄ«Å”anu citiem hostiem. Å Ä« iespēja noteikti
# jāieslēdz, ja hosts darbojas kā jebkāda veida marÅ”rutētājs.
# Mums nav marŔrutēŔanas.

net.ipv4.ip_forward=0
#LÄ«dz ar to izslēdzam pārsÅ«tÄ«Å”anu. Mēs neesam tilts, docker uz maŔīnām nav pacelts,
# mums tas nav nepiecieŔams.

net.ipv4.icmp_echo_ignore_broadcasts=1
#NEREGULĒJAM ICMP ECHO pieprasÄ«jumus, kas nosÅ«tÄ«ti kā plaÅ”saziņas paketi

net.ipv4.tcp_fin_timeout=10
#nosaka laiku, kad sokets tiek saglabāts FIN-WAIT-2 stāvoklī pēc tā
# slēgÅ”anas no vietējās puses. Noklusējums 60

net.core.netdev_budget=600 # (noklusējums 300)
# Ja programmatūru pārtraukumi neizpildās pietiekami ilgi,
# tad ienākoÅ”o datu pieauguma temps var pārsniegt kodola iespēju
# iztukÅ”ot buferi. Tā rezultātā NIC buferi pārplÅ«dÄ«s, un datplÅ«sma tiks zaudēta.
# Dažreiz ir nepiecieŔams palielināt SoftIRQs
# (programmatūras pārtraukumu) darbības ilgumu ar CPU. Par to ir atbildīgs netdev_budget.
# Noklusējuma vērtība 300. Parametrs liks SoftIRQ procesam apstrādāt
# 300 paketus no NIC pirms CPU atbrīvoŔanas

net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# ja abiem, klientam un serverim, ir atbalsts TFO, kas tiek norādīts
# ar speciālu karogu TCP pakotnē. MÅ«su gadÄ«jumā tas ir plasebo, vienkārÅ”i
# izskatās labi)

Arluster tÄ«kls tika nodalÄ«ti atseviŔķos 10Gbps tÄ«kla saskarnēs atseviŔķā plakanā tÄ«klā. Uz katras maŔīnas tika uzstādÄ«tas divu portu tÄ«kla kartes mellanox 10/25 Gbps, kas tika iekļauti divos atseviŔķos 10Gbps slēdžos. Agregācija tika veikta, izmantojot OSPF, jo bonda izmantoÅ”ana ar lacp, kā izrādÄ«jās, parādÄ«ja kopējo caurlaidspēju maksimums 16 Gbps, kamēr ospf veiksmÄ«gi izmantoja pilnÄ«bā abas desmit uz katras maŔīnas. Turpmākajos plānos bija izmantot ROCE uz Å”iem mellanox, lai samazinātu latentumu. Kā tika konfigurēta Ŕī tÄ«kla daļa:

  1. Tā kā paŔām maŔīnām ir ārējie IP adreses BGP, mums ir nepiecieÅ”ams programmatÅ«ra ā€” (precÄ«zāk, rakstÄ«Å”anas brÄ«dÄ« tas bija frr=6.0-1 ) jau uzstādÄ«ts.
  2. Kopumā maŔīnām bija divas tÄ«kla saskarnes ā€” kopā 4 porti. Viena tÄ«kla karte ar diviem portiem skatÄ«jās uz fabrikas pusi, un uz tās bija konfigurēts BGP, otra ā€” ar diviem portiem skatÄ«jās uz diviem dažādiem slēdžiem un uz to tika pārsÅ«tÄ«ts OSPF.

SÄ«kāk par OSPF konfigurāciju: Galvenais uzdevums ā€” agregēt divus linkus un nodroÅ”ināt kļūdu toleranci.
divas tÄ«kla saskarnes ir konfigurētas divās vienkārŔās plakanās tÄ«klos ā€” 10.10.10.0/24 un 10.10.20.0/24

1: ens1f0:  mtu 9000 qdisc mq state UP group default qlen 1000
    inet 10.10.10.2/24 brd 10.10.10.255 scope global ens1f0

2: ens1f1:  mtu 9000 qdisc mq state UP group default qlen 1000
    inet 10.10.20.2/24 brd 10.10.20.255 scope global ens1f1

pēc kuriem maŔīnas redz viena otru.

DISKS

Nākamajā solÄ« nolēmu optimizēt disku darbÄ«bu. SSD gadÄ«jumā nomainÄ«ju plānotāju uz noop, HDD gadÄ«jumā ā€” deadline. Ja vienkārÅ”i sakot ā€” NOOP darbojas pēc principa Ā«kurÅ” pirmais piecēlies ā€” tam arÄ« čībasĀ», kas angliski izklausās kā Ā«FIFO (First In, First Out)Ā». PieprasÄ«jumi stāv rindā, kad tie ienāk. DEADLINE ir vairāk orientēts uz lasÄ«Å”anu, plus process no rindas saņem gandrÄ«z monopolisku piekļuvi diskam operācijas laikā. MÅ«su sistēmai tas ir ideāli piemērots ā€” jo ar katru disku strādā tikai viens process ā€” OSD deamons.
(Vēlējēji, kas vēlas izpētÄ«t ieejas-izejas plānotāju, var izlasÄ«t par to Å”eit:
http://www.admin-magazine.com/HPC/Articles/Linux-I-O-Schedulers

Vēlējējiem lasīt krieviski: https://www.opennet.ru/base/sys/linux_shedulers.txt.html)

Ieteikumos par Linux optimizāciju ieteicams arī palielināt nr_request

nr_requests
nr_requests vērtÄ«ba nosaka I/O pieprasÄ«jumu daudzumu, kas tiek buferizēti pirms I/O plānotājs nosÅ«ta / saņem datus uz / no bloka ierÄ«ces. Ja izmantojāt RAID karti / bloku ierÄ«ci, kas var apstrādāt lielāku rindu, nekā to ir iestatÄ«jis I/O plānotājs, nr_requests vērtÄ«bas palielināŔana var palÄ«dzēt uzlabot caurlaidspēju un samazināt servera slodzi, kad serverÄ« notiek lieli I/O procesi. Ja izmantojat Deadline vai CFQ kā plānotāju, ieteicams iestatÄ«t nr_request vērtÄ«bu uz 2 reizes rindas dziļuma vērtÄ«bu.

TOMĒR! PaÅ”i CEPH izstrādātāji pārliecina mÅ«s, ka viņu prioritāŔu sistēma darbojas labāk.

Ceph ā€” no Ā«uz papÄ«raĀ» lÄ«dz Ā«ražoÅ”anaĀ»

WBThrottle un / vai nr_requests

WBThrottle un / vai nr_requests
Failu krātuve izmanto buferizētas I/O operācijas rakstÄ«Å”anai; tas piedāvā virkni priekÅ”rocÄ«bu, ja failu krātuves žurnāls atrodas ātrākajā nesējā. Klienta pieprasÄ«jumi saņem paziņojumus, tiklÄ«dz dati ir rakstÄ«ti žurnālā, un pēc tam tiek pārsÅ«tÄ«ti uz paÅ”u datu disku vēlāk, izmantojot standarta Linux funkcionalitāti. Tas ļauj OSD spoles diskam piedāvāt rakstÄ«Å”anas latentumu, kas ir lÄ«dzÄ«gs SSD, kad dati tiek rakstÄ«ti nelielos pakeÅ”os. Šāds aizkavēts atliktais ieraksts arÄ« ļauj paÅ”am kodolam pārstrukturēt I/O pieprasÄ«jumus uz disku ar cerÄ«bu vai nu apvienot tos, vai ļaut esoÅ”ajām diskā esoÅ”ajām galvām izvēlēties optimālāku ceļu virs savām plāksnēm. Gala rezultāts ir tas, ka jÅ«s varat izspiest nedaudz vairāk I/O operāciju no katra diska, nekā tas bÅ«tu iespējams, veicot tieÅ”as vai sinhroniskas I/O operācijas.

Tomēr, rodas noteikta problēma, ja ienākoÅ”o ierakstu apjoms Å”ajā Ceph klasterÄ« pārsniedz visu pamatdisku iespējas. Šādā scenārijā kopējais I/O operāciju skaits, kas gaida ierakstu diskā, var nekontrolējami pieaugt un rezultātā izveidot I/O operāciju rindas, kas aizpilda visu disku un Ceph rindas. LasÄ«Å”anas pieprasÄ«jumi ietekmē Ä«paÅ”i slikti, jo tie ieÄ·eras starp rakstÄ«Å”anas pieprasÄ«jumiem, kas var prasÄ«t vairākas sekundes, lai pārsÅ«tÄ«tu uz galveno disku.

Lai risinātu Å”o problēmu, Ceph ir iebÅ«vēts mehānisms atliktās rakstÄ«Å”anas (writeback) dzÄ“Å”anas kontrolei ar nosaukumu WBThrottle. Tas ir izstrādāts, lai ierobežotu kopējo atliktās rakstÄ«Å”anas I/O operāciju apjomu, kas var tikt ievietots rindā un uzsākt savu izmeÅ”anas procesu agrāk, nekā tas notiktu dabiski, ieslēdzot paÅ”u kodolu. Diemžēl testi rāda, ka noklusējuma iestatÄ«jumi joprojām var neierobežot esoÅ”o uzvedÄ«bu lÄ«dz lÄ«menim, kas varētu samazināt ietekmi uz lasÄ«Å”anas latentumu. RegulÄ“Å”ana var mainÄ«t Å”o uzvedÄ«bu un samazināt kopējo rakstÄ«Å”anas rindu garumu, padarot iespējamu vieglāku ietekmi. Tomēr pastāv kāds kompromiss: samazinot kopējo maksimāli atļauto rakstÄ«Å”anas ierakstu skaitu, jÅ«s varat samazināt paÅ”a kodola iespēju maksimizēt savu efektivitāti, kārtÄ«bā saņemto pieprasÄ«jumu. Ir vērts pārdomāt, kas ir svarÄ«gāks jÅ«su konkrētajā lietoÅ”anas gadÄ«jumā, darba slodzēs un pielāgot atbilstoÅ”i tam.

Lai pārvaldÄ«tu atliktās rakstÄ«Å”anas rindas dziļumu, jÅ«s varat vai nu samazināt kopējo maksimāli atļauto neizpildÄ«to I/O operāciju skaitu, izmantojot WBThrottle iestatÄ«jumus, vai arÄ« samazināt maksimālo vērtÄ«bu neizpildÄ«tām operācijām paŔā kodola bloku lÄ«menÄ«. Abi var efektÄ«vi pārvaldÄ«t vienu un to paÅ”u uzvedÄ«bu, un tieÅ”i jÅ«su izvēles bÅ«s pamats Ŕīs iestatÄ«Å”anas Ä«stenoÅ”anai.
ArÄ« jāatzÄ«mē, ka esoŔā Ceph operāciju prioritāŔu sistēma ir efektÄ«vāka Ä«sām pieprasÄ«juma operācijām diska lÄ«menÄ«. Samazinot kopējo rindu skaitu uz Å”o disku, galvenā atraÅ”anās vieta rindā tiek pārvietota uz Ceph, kur tam ir lielāka kontrole pār to, kāda prioritāte ir I/O operācijai. ApskatÄ«sim nākamo piemēru:

echo 8 > /sys/block/sda/queue/nr_requests

http://onreader.mdl.ru/MasteringCeph/content/Ch09.html#030202

PARASTS

Un vēl dažādi kodola iestatÄ«jumi, kas ļauj jÅ«su maŔīnai bÅ«t mÄ«kstākai un gludākai, izspiest vēl nedaudz veiktspējas no aparatÅ«ras.

cat /etc/sysctl.d/60-ceph2.conf

 kernel.pid_max = 4194303
# Disk drives in each machine are 25, so we calculated that there would be many processes
kernel.threads-max=2097152
# Threads, of course, also.
vm.max_map_count=524288
# Increased the number of memory mapping areas for the process.
# As indicated in the documentation for kernel variables
# Memory mapping areas are used as a side effect of calls
# malloc, directly via mmap, mprotect, and madvise, as well as when loading
# shared libraries.
fs.aio-max-nr=50000000
# Tuning input-output parameters
# The Linux kernel provides an asynchronous non-blocking input-output (AIO) function,
# which allows a process to initiate multiple input-output operations
# simultaneously, without waiting for any of them to finish.
# This helps improve application performance,
# which can overlap processing and input-output.
# The parameter aio-max-nr determines the maximum number of allowed
# simultaneous requests.
vm.min_free_kbytes=1048576
# The minimum size of free memory that needs to be maintained.
# Set to 1GB, which is quite sufficient for the operating system to function,
# and prevents the OOM Killer from affecting OSD processes. Although there is plenty
# of memory available, having a reserve does not hurt.
vm.swappiness=10
# Instruct to use swap if 10% of memory is free.
# On machines with 128G RAM, 10% is 12GB. More than enough for operation.
# The default parameter of 60% would cause the system to lag by going into swap,
# when there's still plenty of free memory.
vm.vfs_cache_pressure=1000
# Increasing from the default 100. Forcing the kernel to unload
# unused memory pages from the cache more aggressively.
vm.zone_reclaim_mode=0
# Allows setting more or less aggressive approaches to
# reclaiming memory when the zone runs out of memory.
# If set to zero, no zone reclaim occurs.
# For file servers or workloads
# it is advantageous if their data is cached, leaving zone_reclaim_mode
# disabled is preferable, since the caching effect
# is likely more important than the location of the data.
vm.dirty_ratio=20
# The percentage of RAM that can be allocated for "dirty" pages
# Calculated from an approximate estimate:
# The system has 128GB of memory.
# Approximately 20 SSD drives, which are configured in CEPH
# to allocate 3GB of RAM for caching.
# Approximately 40 HDD drives, for which this parameter equals 1GB.
# 20% of 128 is 25.6GB. Therefore, in case of maximum memory utilization,
# the system would have 2.4GB of memory left. Which should be enough for it to survive and await
# the cavalry - meaning the arrival of DevOps to fix everything.
vm.dirty_background_ratio=3
# The percentage of system memory that can be filled with dirty pages before
# background processes pdflush/flush/kdmflush write them to disk.
fs.file-max=524288
# We will likely have many more open files than indicated by default.

IegremdÄ“Å”anās CEPH

Iestatījumi, pie kuriem vēlētos apstāties sīkāk:

cat /etc/ceph/ceph.conf

osd:
    journal_aio: true               # Trīs parametri, kas iekļauj 
    journal_block_align: true       # tieŔo i/o
    journal_dio: true               # žurnālam
    journal_max_write_bytes: 1073714824 # Nedaudz paplaÅ”ināsim maksimālo izmēru
                                        # vienreizēji rakstāmās operācijas žurnālā
    journal_max_write_entries: 10000    # Un arī vienlaicīgo ierakstu skaits
    journal_queue_max_bytes: 10485760000 
    journal_queue_max_ops: 50000
    rocksdb_separate_wal_dir: true      # Nolēmām veidot atseviŔķu wal                                                                            
                                        # Pat mēģinājām pieņemt Å”o jautājumu                                                                                                                                                                                     
                                        # NVMe
    bluestore_block_db_create: true     # Nu arī žurnālam atseviŔķa ierīce
    bluestore_block_db_size: '5368709120 #5G'
    bluestore_block_wal_create: true
    bluestore_block_wal_size: '1073741824   #1G' 
    bluestore_cache_size_hdd: '3221225472   # 3G' 
                                            # liels operatīvās atmiņas apjoms ļauj 
                                            # uzglabāt diezgan lielus apjomus
    bluestore_cache_size_ssd: '9663676416   # 9G' 

    keyring: /var/lib/ceph/osd/ceph-$id/keyring
    osd_client_message_size_cap: '1073741824 #1G'
    osd_disk_thread_ioprio_class: idle
    osd_disk_thread_ioprio_priority: 7
    osd_disk_threads: 2 # pavedienu skaits demonam uz vienu disku
    osd_failsafe_full_ratio: 0.95
    osd_heartbeat_grace: 5
    osd_heartbeat_interval: 3
    osd_map_dedup: true
    osd_max_backfills: 2 # vienlaicīgo piepildījuma operāciju skaits uz vienu OSD.
    osd_max_write_size: 256
    osd_mon_heartbeat_interval: 5
    osd_op_threads: 16
    osd_op_num_threads_per_shard: 1
    osd_op_num_threads_per_shard_hdd: 2
    osd_op_num_threads_per_shard_ssd: 2
    osd_pool_default_min_size: 1     # ÄŖpatnÄ«bas alkatÄ«bas. Ä»oti ātri sākās
    osd_pool_default_size: 2         # vietas trūkums, jo pagaidu                                                                                                                                                      
                                     # risinājums tika pieņemts samazināt
                                     # datu replikāciju skaitu
    osd_recovery_delay_start: 10.000000
    osd_recovery_max_active: 2
    osd_recovery_max_chunk: 1048576
    osd_recovery_max_single_start: 3
    osd_recovery_op_priority: 1
    osd_recovery_priority: 1            # parametrs regulējams pēc nepiecieÅ”amÄ«bas
    osd_recovery_sleep: 2
    osd_scrub_chunk_max: 4

Daži parametri, kas tika pārbaudÄ«ti QA versijā 12.2.12, trÅ«kst versijā ceph 12.2.2, piemēram osd_recovery_threads. Tāpēc plānos bija iekļauta atjaunināŔana ražoÅ”anā lÄ«dz 12.2.12. Prakse parādÄ«ja saderÄ«bu vienā klasterÄ« ar versijām 12.2.2 un 12.2.12, kas ļauj veikt rullējoÅ”u atjauninājumu.

Testa klasteris

Dabis, testÄ“Å”anai bija nepiecieÅ”ama tieÅ”i tāda pati versija kā ražoÅ”anā, taču, kad es uzsāku darbu ar klasteri, repozitorijā bija tikai jaunāka versija. Pārskatot, ka atŔķirÄ«bas starp nelielajām versijām nav lielas,1393 rindas konfigurācijās pret 1436 (jauno versiju), nolēmām sākt testēt jauno (tāpat bÅ«s jāatjaunina, kamdēļ braukt ar veco miskasti)

VienÄ«gais, ko mēs mēģinājām saglabāt no vecās versijas, bija pakete ceph-deploy, jo daļa utilÄ«tu (un daļa darbinieku) bija pielāgota tās sintaksei. Jaunā versija bÅ«tiski atŔķīrās, taču tas ietekmēja paÅ”a klastera darbÄ«bu, un mēs to atstājām versijā. 1.5.39

Tā kā komanda ceph-disk skaidri norāda, ka tā ir novecojusi un aicina izmantot, cienÄ«jamie, komandu ceph-volume ā€” mēs sākām izveidot OSD tieÅ”i ar Å”o komandu, netērējot laiku novecojuÅ”ai.

Plāns bija tāds ā€” izveidot spoguli no divām SSD diskiem, uz kuriem tiks novietoti OSD žurnāli, kuri, savukārt, atrodas uz griezējdiskiem SAS. Tādējādi mēs aizsargāsim datus pret problēmām, ja diska žurnāls sabojājas.

Klasteri sāka veidot pēc dokumentācijas

cat /etc/ceph/ceph.conf

root@ceph01-qa:~# cat /etc/ceph/ceph.conf # iepriekŔ sagatavotā konfigurācija
[client]
rbd_cache = true
rbd_cache_max_dirty = 50331648
rbd_cache_max_dirty_age = 2
rbd_cache_size = 67108864
rbd_cache_target_dirty = 33554432
rbd_cache_writethrough_until_flush = true
rbd_concurrent_management_ops = 10
rbd_default_format = 2
[global]
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx
cluster network = 10.10.10.0/24
debug_asok = 0/0
debug_auth = 0/0
debug_buffer = 0/0
debug_client = 0/0
debug_context = 0/0
debug_crush = 0/0
debug_filer = 0/0
debug_filestore = 0/0
debug_finisher = 0/0
debug_heartbeatmap = 0/0
debug_journal = 0/0
debug_journaler = 0/0
debug_lockdep = 0/0
debug_mon = 0/0
debug_monc = 0/0
debug_ms = 0/0
debug_objclass = 0/0
debug_objectcatcher = 0/0
debug_objecter = 0/0
debug_optracker = 0/0
debug_osd = 0/0
debug_paxos = 0/0
debug_perfcounter = 0/0
debug_rados = 0/0
debug_rbd = 0/0
debug_rgw = 0/0
debug_throttle = 0/0
debug_timer = 0/0
debug_tp = 0/0
fsid = d0000000d-4000-4b00-b00b-0123qwe123qwf9
mon_host = ceph01-q, ceph02-q, ceph03-q
mon_initial_members = ceph01-q, ceph02-q, ceph03-q
public network = 8.8.8.8/28 # adrese ir mainīta, protams ))
rgw_dns_name = s3-qa.mycompany.ru # un Ŕī adrese arī ir mainīta
rgw_host = s3-qa.mycompany.ru # un Ŕī arī
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # vairāk nekā trīs simti plānojumu grupu
                          # uz diska, izlemts neriskēt
                     # lai gan parametrs, protams, atkarīgs no baseinu skaita,
                     # to izmēriem un OSD skaita. Mazs, bet veselīgs PG
                        # arÄ« nav labākais variants - cieÅ” balansÄ“Å”anas precizitāte
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # paŔlaik SSD diskiem vieta to
                          # žurnālam ir tas pats ierīces, kas OSD
                          # izlemts, ka 5% no diska (kas pats ir 1.2Tb)
                          # būtu pilnīgi pietiekami un korelē ar parametru
                          # bluestore_block_db_size plus variācija uz lielām 
                          # plānojumu grupām
mon_osd_nearfull_ratio = 0.9
mon_pg_warn_max_per_osd = 520
[osd]
bluestore_block_db_create = true
bluestore_block_db_size = 5368709120 #5G
bluestore_block_wal_create = true
bluestore_block_wal_size = 1073741824 #1G
bluestore_cache_size_hdd = 3221225472 # 3G
bluestore_cache_size_ssd = 9663676416 # 9G
journal_aio = true
journal_block_align = true
journal_dio = true
journal_max_write_bytes = 1073714824
journal_max_write_entries = 10000
journal_queue_max_bytes = 10485760000
journal_queue_max_ops = 50000
keyring = /var/lib/ceph/osd/ceph-$id/keyring
osd_client_message_size_cap = 1073741824 #1G
osd_disk_thread_ioprio_class = idle
osd_disk_thread_ioprio_priority = 7
osd_disk_threads = 2
osd_failsafe_full_ratio = 0.95
osd_heartbeat_grace = 5
osd_heartbeat_interval = 3
osd_map_dedup = true
osd_max_backfills = 4
osd_max_write_size = 256
osd_mon_heartbeat_interval = 5
osd_op_num_threads_per_shard = 1
osd_op_num_threads_per_shard_hdd = 2
osd_op_num_threads_per_shard_ssd = 2
osd_op_threads = 16
osd_pool_default_min_size = 1
osd_pool_default_size = 2
osd_recovery_delay_start = 10.0
osd_recovery_max_active = 1
osd_recovery_max_chunk = 1048576
osd_recovery_max_single_start = 3
osd_recovery_op_priority = 1
osd_recovery_priority = 1
osd_recovery_sleep = 2
osd_scrub_chunk_max = 4
osd_scrub_chunk_min = 2
osd_scrub_sleep = 0.1
rocksdb_separate_wal_dir = true

# сŠ¾Š·Š“Š°ŠµŠ¼ Š¼Š¾Š½ŠøтŠ¾Ń€Ń‹
root@ceph01-qa:~#ceph-deploy mon create ceph01-q
# Š³ŠµŠ½ŠµŃ€ŠøруŠµŠ¼ ŠŗŠ»ŃŽŃ‡Šø Š“Š»Ń Š°ŃƒŃ‚ŠµŠ½Ń‚ŠøфŠøŠŗŠ°Ń†ŠøŠø Š½Š¾Š“ Š² ŠŗŠ»Š°ŃŃ‚ŠµŃ€Šµ
root@ceph01-qa:~#ceph-deploy gatherkeys ceph01-q
# Š­Ń‚Š¾ ŠµŃŠ»Šø ŠæŠ¾ŃˆŃ‚ŃƒŃ‡Š½Š¾. Š•ŃŠ»Šø у Š½Š°Ń Š½ŠµŃŠŗŠ¾Š»ŃŒŠŗŠ¾ Š¼Š°ŃˆŠøŠ½ Š“Š¾ŃŃ‚ŃƒŠæŠ½Ń‹ - тŠµ, ŠŗŠ¾Ń‚Š¾Ń€Ń‹Šµ Š¾ŠæŠøсŠ°Š½Ń‹ Š² ŠŗŠ¾Š½Ń„ŠøŠ³Šµ Š² сŠµŠŗцŠøŠø 
# mon_initial_members = ceph01-q, ceph02-q, ceph03-q
# Š¼Š¾Š¶Š½Š¾ Š·Š°ŠæустŠøть этŠø Š“Š²Šµ ŠŗŠ¾Š¼Š°Š½Š“ы Š² Š²ŠøŠ“Šµ Š¾Š“Š½Š¾Š¹
root@ceph01-qa:~#ceph-deploy mon create-initial
# ŠŸŠ¾Š»Š¾Š¶ŠøŠ¼ ŠŗŠ»ŃŽŃ‡Šø Š² уŠŗŠ°Š·Š°Š½Š½Ń‹Šµ Š² ŠŗŠ¾Š½Ń„ŠøŠ³Šµ Š¼ŠµŃŃ‚Š°
root@ceph01-qa:~#cat ceph.bootstrap-osd.keyring > /var/lib/ceph/bootstrap-osd/ceph.keyring 
root@ceph01-qa:~#cat ceph.bootstrap-mgr.keyring > /var/lib/ceph/bootstrap-mgr/ceph.keyring 
root@ceph01-qa:~#cat ceph.bootstrap-rgw.keyring > /var/lib/ceph/bootstrap-rgw/ceph.keyring
# сŠ¾Š·Š“Š°Š“ŠøŠ¼ ŠŗŠ»ŃŽŃ‡ Š“Š»Ń уŠæрŠ°Š²Š»ŠµŠ½Šøя ŠŗŠ»Š°ŃŃ‚ŠµŃ€Š¾Š¼
root@ceph01-qa:~#ceph-deploy admin ceph01-q
# Šø Š¼ŠµŠ½ŠµŠ“Š¶ŠµŃ€, ŠæŠ»Š°Š³ŠøŠ½Š°Š¼Šø уŠæрŠ°Š²Š»ŃŃ‚ŃŒ
root@ceph01-qa:~#ceph-deploy mgr create ceph01-q

Pirmais, ar ko sastapos, strādājot ar Å”o ceph-deploy versiju klasterÄ« ar versiju 12.2.12 ā€” tas ir kļūda, mēģinot izveidot OSD ar db uz programmatÅ«ras RAID ā€”

root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid nevarēja noteikt PARTUUID ierīcei: /dev/md1

TieŔām, blkid nerāda PARTUUID, bija jāizveido sadaļas paŔrocīgi:

root@ceph01-qa:~#parted /dev/md0 mklabel GPT 
# sekciju būs daudz, 
# bez GPT tās izveidot neizdosies
# sekcijas izmērs, ko mēs norādÄ«jām iepriekŔējā konfigurācijā = bluestore_block_db_size: '5368709120 #5G'
# Man ir 20 diski OSD, paŔrocīgi izveidot sadaļas slinkums
# tāpēc izveidoju ciklu
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; done

Izskatās, ka visi ir gatavi, mēģinām vēlreiz izveidot OSD un saņemam nākamo kļūdu (kura, starp citu, ražoÅ”anā nerādÄ«jās)

pie OSD bluestore veidoŔanas bez WAL ceļa norādīŔanas, bet ar db norādīŔanu

root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
 stderr: 2019-04-12 10:39:27.211242 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _read_fsid neparsējams uuid
 stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) atvērt atvērts ieguva: (22) Nepareizs arguments
 stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db pievienot blokota ierīce(/var/lib/ceph/osd/ceph-0//block.wal) atgriezās: (22) Nepareizs arguments
 stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs neizdevās, (22) Nepareizs arguments
 stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs neizdevās ar kļūdu (22) Nepareizs arguments
 stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1  ** KÄ»ÅŖDA: tukÅ”a objekta krātuves izveide /var/lib/ceph/osd/ceph-0/: (22) Nepareizs arguments

Ja tomēr uz to paÅ”u spoguļa (vai citā vietā, pēc izvēles) izveido vēl vienu sadaļu WAL un norāda to OSD izveidē ā€” tad viss ies gludi (izņemot atseviŔķā WAL parādÄ«Å”anos, kuru, iespējams, jÅ«s nemaz negribējāt).

Tomēr, ņemot vērā, ka tāpat tālā plānotā ir WAL pārcelÅ”ana uz NVMe, tad prakse izrādÄ«jās lieka.

root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2

Izveidojām monitorus, menedžerus un OSD. Tagad vēlamies tos grupēt dažādi, jo plānoti ir dažādu veidu diski ā€” ātri baseini uz SSD un lieli, bet lēni uz HDD.

Uzcelsim, ka serveros ir 20 diski, pirmais desmit ir viens veids, otrais ā€” cits.
Sākotnējā, noklusējuma, karte izskatās Ŕādi:

ceph osd tree

root@ceph01-qa:~# ceph osd tree
ID KLASE SVARS TIPS NOSAUKUMS STATUSS PĀRVARĒT
-1 14.54799 sakne noklusējuma
-3 9.09200 hosts ceph01-qa
0 ssd 1.00000 osd.0 augŔā 1.00000 1.00000
1 ssd 1.00000 osd.1 augŔā 1.00000 1.00000
2 ssd 1.00000 osd.2 augŔā 1.00000 1.00000
3 ssd 1.00000 osd.3 augŔā 1.00000 1.00000
4 hdd 1.00000 osd.4 augŔā 1.00000 1.00000
5 hdd 0.27299 osd.5 augŔā 1.00000 1.00000
6 hdd 0.27299 osd.6 augŔā 1.00000 1.00000
7 hdd 0.27299 osd.7 augŔā 1.00000 1.00000
8 hdd 0.27299 osd.8 augŔā 1.00000 1.00000
9 hdd 0.27299 osd.9 augŔā 1.00000 1.00000
10 hdd 0.27299 osd.10 augŔā 1.00000 1.00000
11 hdd 0.27299 osd.11 augŔā 1.00000 1.00000
12 hdd 0.27299 osd.12 augŔā 1.00000 1.00000
13 hdd 0.27299 osd.13 augŔā 1.00000 1.00000
14 hdd 0.27299 osd.14 augŔā 1.00000 1.00000
15 hdd 0.27299 osd.15 augŔā 1.00000 1.00000
16 hdd 0.27299 osd.16 augŔā 1.00000 1.00000
17 hdd 0.27299 osd.17 augŔā 1.00000 1.00000
18 hdd 0.27299 osd.18 augŔā 1.00000 1.00000
19 hdd 0.27299 osd.19 augŔā 1.00000 1.00000
-5 5.45599 resursu ceph02-q
20 ssd 0.27299 osd.20 augŔā 1.00000 1.00000
21 ssd 0.27299 osd.21 augŔā 1.00000 1.00000
22 ssd 0.27299 osd.22 augŔā 1.00000 1.00000
23 ssd 0.27299 osd.23 augŔā 1.00000 1.00000
24 hdd 0.27299 osd.24 augŔā 1.00000 1.00000
25 hdd 0.27299 osd.25 augŔā 1.00000 1.00000
26 hdd 0.27299 osd.26 augŔā 1.00000 1.00000
27 hdd 0.27299 osd.27 augŔā 1.00000 1.00000
28 hdd 0.27299 osd.28 augŔā 1.00000 1.00000
29 hdd 0.27299 osd.29 augŔā 1.00000 1.00000
30 hdd 0.27299 osd.30 augŔā 1.00000 1.00000
31 hdd 0.27299 osd.31 augŔā 1.00000 1.00000
32 hdd 0.27299 osd.32 augŔā 1.00000 1.00000
33 hdd 0.27299 osd.33 augŔā 1.00000 1.00000
34 hdd 0.27299 osd.34 augŔā 1.00000 1.00000
35 hdd 0.27299 osd.35 augŔā 1.00000 1.00000
36 hdd 0.27299 osd.36 augŔā 1.00000 1.00000
37 hdd 0.27299 osd.37 augŔā 1.00000 1.00000
38 hdd 0.27299 osd.38 augŔā 1.00000 1.00000
39 hdd 0.27299 osd.39 augŔā 1.00000 1.00000
-7 6.08690 resursu ceph03-q
40 ssd 0.27299 osd.40 augŔā 1.00000 1.00000
41 ssd 0.27299 osd.41 augŔā 1.00000 1.00000
42 ssd 0.27299 osd.42 augŔā 1.00000 1.00000
43 ssd 0.27299 osd.43 augŔā 1.00000 1.00000
44 hdd 0.27299 osd.44 augŔā 1.00000 1.00000
45 hdd 0.27299 osd.45 augŔā 1.00000 1.00000
46 hdd 0.27299 osd.46 augŔā 1.00000 1.00000
47 hdd 0.27299 osd.47 augŔā 1.00000 1.00000
48 hdd 0.27299 osd.48 augŔā 1.00000 1.00000
49 hdd 0.27299 osd.49 augŔā 1.00000 1.00000
50 hdd 0.27299 osd.50 augŔā 1.00000 1.00000
51 hdd 0.27299 osd.51 augŔā 1.00000 1.00000
52 hdd 0.27299 osd.52 augŔā 1.00000 1.00000
53 hdd 0.27299 osd.53 augŔā 1.00000 1.00000
54 hdd 0.27299 osd.54 augŔā 1.00000 1.00000
55 hdd 0.27299 osd.55 augŔā 1.00000 1.00000
56 hdd 0.27299 osd.56 augŔā 1.00000 1.00000
57 hdd 0.27299 osd.57 augŔā 1.00000 1.00000
58 hdd 0.27299 osd.58 augŔā 1.00000 1.00000
59 hdd 0.89999 osd.59 augŔā 1.00000 1.00000

Izveidosim savus virtuālos stendus un serverus ar melnajiem jokeriem un pārējo:

root@ceph01-q:~#ceph osd crush add-bucket rack01 sakne #izveidojām jauno sakni
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #izveidojām jaunu resursu
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #pārvietojām serveri uz citu stendu
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # pievienojām OSD serverim

# Ja esam nepareizi izveidojuÅ”i, varam dzēst
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01

Problēmas, ar kurām mēs saskārāmies cīņas klasterÄ«, mēģinot izveidot jaunus resursus un pārvietot tos uz esoÅ”u stendu ā€” komanda ceph osd crush move ceph01-host root=rack01 iestrēga, un monitora sāka krist viens pēc otra. Komandas pārtraukÅ”ana ar vienkārÅ”o CTRL+C atgrieza klasteri dzÄ«vo pasaulē.

MeklÄ“Å”ana parādÄ«ja Ŕādu problēmu: https://tracker.ceph.com/issues/23386

Risinājums izrādījās iznests crushmap un izdzēst no turienes sadaļu rule replicated_ruleset

root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #izmetam karti neapstrādātā veidā
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #pārvērÅ”am to lasāmā
root@ceph01-prod:~#vim crushmap.txt #rediģējam, izdzÄ“Å”ot rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #kompiliējam atpakaļ
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #ielādējam klasterī

UzmanÄ«bu: Ŕī operācija var izsaukt pārbalansÄ“Å”anu placement group starp OSD. Mums tas izraisÄ«ja, taču ļoti nedaudz.

DÄ«vainÄ«ba, ar ko mēs saskārāmies testÄ“Å”anas klasterÄ«, ir tā, ka pēc servera restartÄ“Å”anas OSD aizmirsÄ«s, ka tie tika pārvietoti uz jaunajiem serveriem un plauktiem, un atgriezÄ«sies sākotnējā noklusējuma stāvoklÄ«.
Galu galā, izveidojot galÄ«go shēmu, kurā mēs izveidojām atseviŔķu root ssd diskiem un atseviŔķu spindulveida diskiem, mēs izklÄ«dām visus OSD plauktos un vienkārÅ”i izdzēsam noklusējuma root. Pēc restartÄ“Å”anas OSD palika savās vietās.
Pēcāk rakājoties dokumentācijā, atradām parametrus, kas ir atbildÄ«gi par Å”o uzvedÄ«bu. Par to otrajā daļā.

Kā mēs izveidojām dažādas grupas pēc disk tipu.

Sāksim ar divu root izveidi ā€” ssd un hdd.

root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root root

Tā kā fiziski serveri atrodas dažādos plauktos ā€” ērtÄ«bas labad izveidojām plauktus un tajos jau serverus.

# Š”тŠ¾Š¹ŠŗŠø:
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack02 rack
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack03 rack

root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack

# Š”ŠµŃ€Š²ŠµŃ€Š°
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph01-q host
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph02-q host
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph03-q host

root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph01-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph02-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph02-q host

un sadalījām diskus pēc to veidiem dažādos serveros.

root@ceph01-q:~# Diski no 0 līdz 3 ir SSD, atrodas ceph01-q, iestājam tos serverī 
root@ceph01-q:~#  ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 0 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 1 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 2 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 3 1 host=ssd-ceph01-q
root-ceph01-q:~# analoģiski ar citiem serveriem.

Sadalot diskus pa ssd-root un hdd-root, mēs atstājām root-default tukÅ”u, tāpēc varam to dzēst.

root-ceph01-q:~#ceph osd crush remove default

Tālāk jāizveido izplatÄ«Å”anas noteikumi, ko piesaistÄ«sim izveidotajiem pulciņiem ā€” noteikumos norādÄ«sim, kuros root var glabāt mÅ«su pÅ«la datus un replikas unikāluma lÄ«meni ā€” piemēram, replikām jābÅ«t obligāti uz dažādiem serveriem vai dažādos plauktos (var pat bÅ«t dažādos root, ja mums ir tāda izplatÄ«Å”ana).

Pirms izvēlēties veidu, labāk izlasīt dokumentāciju:
http://docs.ceph.com/docs/jewel/rados/operations/crush-map/#crushmaprules

root-ceph01-q:~#ceph osd crush rule create-simple rule-ssd ssd-root host firstn
root-ceph01-q:~#ceph osd crush rule create-simple rule-hdd hdd-root host firstn
root-ceph01-q:~# Mēs norādījām divus noteikumus, kuros dati replikējas 
root-ceph01-q:~# starp hostiem - t.i., replikai jābūt uz cita hosta,
root-ceph01-q:~# pat ja tie ir vienā plauktā
root-ceph01-q:~# RažoÅ”anā, ja ir iespēja, labāk izkliedēt hostus
root-ceph01-q:~# pa plauktiem un norādīt izplatīt replikas pa plauktiem:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstn

Tātad, mēs izveidojam baseinus, kuros nākotnē vēlēsimies glabāt mÅ«su virtualizācijas diska attēlus ā€” PROXMOX:

    root-ceph01-q:~# #ceph osd pool create {NAME} {pg_num} {pgp_num}
    root-ceph01-q:~# ceph osd pool create ssd_pool 1024 1024 
    root-ceph01-q:~# ceph osd pool create hdd_pool 1024 1024

Un norādām Å”iem baseiniem, kādi izvietoÅ”anas noteikumi jāievēro

 root-ceph01-q:~#ceph osd crush rule ls # skatāmies noteikumu sarakstu
    root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id #izvēlamies nepiecieÅ”amā ID
    root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2

Pie plānojot placment grupu skaitu, jāpieiet ar iepriekŔēju izpratni par savu klasteri ā€” cik apmēram OSD tur bÅ«s, kāds datu apjoms (procentos no kopējā apjoma) bÅ«s baseinā, cik kopējais datu apjoms.

Kopumā vēlams, lai uz diska nebÅ«tu vairāk par 300 placment grupām, un bÅ«s vieglāk balansēt ar mazām placment grupām ā€” tas ir, ja viss jÅ«su baseins aizņem 10 Tb un tajā ir 10 PG ā€” tad balansēt, pārvietojot terabaitus (pg) bÅ«s sarežģīti ā€” pārvietot smiltis ar maziem graudiem pa spainÄ«Å”iem ir vieglāk un vienmērÄ«gāk).

Bet jāpatur prātā, ka jo vairāk PG ā€” jo vairāk resursu tiek patērēts uz to izvietoÅ”anas aprēķināŔanu ā€” sāk tikt izmantota atmiņa un CPU.

Aptuvena izpratne var sniedz kalkulators, ko snieguŔi CEPH dokumentācijas izstrādātāji.

Materiālu saraksts:

https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data
http://www.admin-magazine.com/HPC/Articles/Linux-I-O-Schedulers
http://onreader.mdl.ru/MasteringCeph/content/Ch09.html#030202
https://tracker.ceph.com/issues/23386
https://ceph.com/pgcalc/

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster