Zgjedhja e CEPH. Pjesa 1
Kishim pesë stenda, dhjetë switch-a optikë, BGP të konfiguruar, disa dhjetëra SSD dhe një mori diskesh SAS të ngjyrave dhe madhësive të ndryshme, si dhe proxmox dhe dëshirën për ta transferuar gjithë statikën në një depo të vetme S3. Jo se gjithë kjo ishte e nevojshme për virtualizimin, por që kur e fillova të përdorja opensource — duhet të shkoj deri në fund me këtë pasion. E vetmja gjë që më shqetësonte ishte BGP. Njerëz më të pafuqishëm, të papërgjegjshëm dhe të pamoralshëm se sa vërtetësia e brendshme e BGP nuk ekziston në botë. Dhe e dija se shumë shpejt do të merreshim me të.
Detyra ishte e thjeshtë — kishim CEPH, i cili nuk punonte shumë mirë. Duhej të bëhej "mirë".
Klastëri që më ishte dhënë ishte heterogjen, i konfiguruar me shpejtësi dhe praktikisht pa tuning. Ai përbëhej nga dy grupe nodash të ndryshme, me një rrjet të përbashkët që shërbente si rrjet klaster ashtu edhe rrjet publik. Nodat ishin të mbushura me katër lloje disku — dy lloje SSD, të grumbulluara në dy rregulla vendosjeje të veçanta dhe dy lloje HDD me madhësi të ndryshme, të grumbulluara në një grup të tretë. Problemi me madhësitë e ndryshme u zgjidh me pesha të ndryshme OSD.
Konfigurimi i vetë u nda në dy pjesë — tunimi i sistemit operativ dhe tunimi i vetë CEPH dhe cilësimeve të tij.
Përmirësimi i OS
Network global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check
Latenca e lartë kishte ndikim si gjatë shkrimit ashtu edhe gjatë balancimit. Gjatë shkrimit — sepse klienti nuk merr përgjigje për shkrimin e suksesshëm derisa replikat e të dhënave në grupet e tjera të vendosjes të konfirmojnë suksesin. Duke qenë se rregullat e shpërndarjes së replikave në hartën CRUSH ishin një replikë për çdo host, rrjeti përdorej gjithmonë.
Pra, stopova për të rregulluar pak rrjetin aktual, duke u përpjekur njëkohësisht të bindja për të kaluar në rrjete të ndara.
Për fillim, luajta me konfigurimet e kartave rrjet. Fillova me konfigurimin e radhëve:
çfarë kishte:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Parametrat e kanalit për ens1f1:
Maksimumet e parapara:
RX: 0
TX: 0
Të tjera: 1
Të kombinuara: 63
Cilësimet aktuale të harduerit:
RX: 0
TX: 0
Të tjera: 1
Të kombinuara: 1
root@ceph01:~# ethtool -g ens1f1
Parametrat e radhëve për ens1f1:
Maksimumet e parapara:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Cilësimet aktuale të harduerit:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Parametrat e kanalit për ens1f1:
Maksimumet e parapara:
RX: 0
TX: 0
Të tjera: 1
Të kombinuara: 63
Cilësimet aktuale të harduerit:
RX: 0
TX: 0
Të tjera: 1
Të kombinuara: 1E dukshme është se parametrat aktualë janë shumë larg maksimumeve. Shtova:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Duke u udhëhequr nga një artikull të shkëlqyer
shtova gjatë e radhëve të dërgimit txqueuelen nga 1000 deri në 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Dhe duke ndjekur dokumentacionin e vetë ceph
e rriti MTU në 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000E shtova në /etc/network/interfaces, që gjithçka e përmendur më sipër të ngarkohej gjatë nisjes
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 9000Pasi e bëra këtë, duke ndjekur të njëjtin artikull, fillova të rregulloj me kujdes parametrat e bërthamës 4.15. Duke marrë parasysh se në nodet kishte 128G RAM, rezultoi një skedar konfigurimi për sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
#Maksimumi i madhësisë së buffer-it të marrjes së të dhënave për të gjitha lidhjet 54M
net.core.wmem_max = 56623104
#Maksimumi i madhësisë së buffer-it të dërgimit të të dhënave për të gjitha lidhjet 54M
net.core.rmem_default = 56623104
#Madhësia e buffer-it të marrjes së të dhënave si parazgjedhje për të gjitha lidhjet. 54M
net.core.wmem_default = 56623104
#Madhësia e buffer-it të dërgimit të të dhënave si parazgjedhje për të gjitha lidhjet 54M
# për çdo soket
net.ipv4.tcp_rmem = 4096 87380 56623104
#Variabla vektoriale (minimumi, parazgjedhja, maksimumi) në skedarin tcp_rmem
# përmban 3 numra të plotë, duke përcaktuar madhësinë e buffer-it të marrjes për soketet TCP.
# Minimumi: çdo soket TCP ka të drejtë të përdorë këtë memorie sipas
# krijimit të tij. Përdorimi i këtij buffer-i
# garanton edhe duke arritur pragun e kufizimit (presion i moderuar mbi memorien).
# Madhësia minimale e buffer-it si parazgjedhje është 8 KB (8192).
#Vlera e parazgjedhur: sasia e memories e lejuar për bufferin
# e dërgimit të soketit TCP si parazgjedhje. Kjo vlerë aplikohet në vend të
# parametrave /proc/sys/net/core/rmem_default, që përdoren nga protokolle të tjera.
# Vlera e buffer-it që përdoret si parazgjedhje zakonisht (si parazgjedhje)
# është 87830 bajta. Kjo përcakton madhësinë e dritares 65535 me
# vlerën e parazgjedhur tcp_adv_win_scale dhe tcp_app_win = 0,
# disi më e vogël se vlera e parazgjedhur e përcaktuar për tcp_app_win.
# Maksimumi: maksimumi i madhësisë së buffer-it që mund të alokohet automatikisht
# për marrjen e soketit TCP. Kjo vlerë nuk anulon maksimumin,
# të caktuar në skedarin /proc/sys/net/core/rmem_max. Kur alokimi "statik"
# bëhet me SO_RCVBUF ky parameter nuk ka rëndësi.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Numri maksimal i soketeve të hapura që presin lidhjet.
net.ipv4.tcp_timestamps=1
# Lejon përdorimin e timestamp-eve, sipas RFC 1323.
net.ipv4.tcp_sack=1
# Lejo konfirmimet selektive të protokollit TCP
net.core.netdev_max_backlog=5000 (parazgjedhje 1000)
# numri maksimal i paketave në radhë për përpunim, nëse
# interfaci merr paketa më shpejt se sa bërthama mund t'i përpunojë ato.
net.ipv4.tcp_max_tw_buckets=262144
# Numri maksimal i soketeve që ndodhen në gjendjen TIME-WAIT në të njëjtën kohë.
# Kur ky prag tejkalohet - soketi "i tepërt" shkatërrohet dhe një
# mesazh shkruhet në regjistrin sistemor.
net.ipv4.tcp_tw_reuse=1
#Lejojmë ripërdorimin e soketeve TIME-WAIT në raste,
# kur protokolli e konsideron këtë të sigurt.
net.core.optmem_max=4194304
#Rrisni maksimumin e hapësirës totale të buffer-it ALLOCATABLE
#matuar në njësi faqe (4096 bajta)
net.ipv4.tcp_low_latency=1
#Lejon që steka TCP/IP të japë përparësi për kohën e ulët të pritjes
# përpara se të ketë më shumë kapacitet.
net.ipv4.tcp_adv_win_scale=1
# Kjo variabël ndikon në llogaritjen e sasisë së memories në bufferin e soketit,
# e alokuar për madhësinë e dritares TCP dhe për bufferin e aplikacionit.
# Nëse vlera tcp_adv_win_scale është negative, atëherë për llogaritjen e madhësisë
# përdoret shprehja e mëposhtme:
# Bytes - bytes2 në fuqinë -tcp_adv_win_scale
# Ku bytes është madhësia e dritares në bajta. Nëse vlera tcp_adv_win_scale
# është pozitive, për përcaktimin e madhësisë përdoret shprehja:
# Bytes - bytes2 në fuqinë tcp_adv_win_scale
# Variabla merr një vlerë të plotë. Vlera e parazgjedhur – 2,
# dmth. për bufferin e aplikacionit alokohet ¼ e sasisë, e cila përcaktohet nga variabla
# tcp_rmem.
net.ipv4.tcp_slow_start_after_idle=0
# mekanizmi i ri fillim të ngadaltë, i cili rivendos vlerën e dritares
# së mbingarkesës, nëse lidhja nuk ishte përdorur për një periudhë të caktuar kohe.
# Është më mirë të çaktivizoni SSR në server për të përmirësuar performancën
# e lidhjeve afatgjata.
net.ipv4.tcp_no_metrics_save=1
#Nuk ruajmë rezultatet e matjeve të lidhjes TCP në cache kur ajo mbyllet.
net.ipv4.tcp_syncookies=0
#Çaktivizo mekanizmin e dërgimit të syncookie
net.ipv4.tcp_ecn=0
#Njoftimi i Shprehur mbi Ngarkesën (Explicit Congestion Notification) në
# lidhjet TCP. Përdoret për të njoftuar për ndodhi "bllokimi"
# në rrugën drejt një hosti ose rrjeti të caktuar. Mund të përdoret për të njoftuar
# hostin dërgues për nevojën për të ulur shpejtësinë e dërgimit të paketeve përmes
# një rrugëzuesi ose një firewall të caktuar.
net.ipv4.conf.all.send_redirects=0
# çaktivizon lëshimin e ICMP Redirect … për hostet e tjera. Kjo opsion
# patjetër duhet të jetë i aktivizuar, nëse hosti vepron si ruter ndonjë lloji.
# Ne nuk kemi routing.
net.ipv4.ip_forward=0
#Përsa i përket çaktivizimit të përparimit. Ne nuk jemi portë, docker në makinat nuk është ngritur,
# na nevojitet kjo.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Nuk përgjigjemi ndaj kërkesave ICMP ECHO, të transmetuara me paketa broadcast
net.ipv4.tcp_fin_timeout=10
#përcakton kohën e mbajtjes së soketit në gjendjen FIN-WAIT-2 pas mbylljes
# nga ana lokale. Parazgjedhje 60
net.core.netdev_budget=600 # (parazgjedhje 300)
# Nëse ekzekutimi i ndërprerjeve programore nuk kryhet për një periudhë të mjaftueshme,
# atëherë ritmi i rritjes së të dhënave të ardhshme mund të tejkalojë mundësinë e bërthamës
# për të shplarë buffer-in. Si rezultat, buffer-at e NIC do të mbushen dhe trafiku do të humbasë.
# Disa herë, është e nevojshme të rritet koha e punës SoftIRQs
# (ndërprerjeve programore) me CPU. Kjo është përgjegjësia e netdev_budget.
# Vlera e parazgjedhjes 300. Parametri do të bëjë që procesi SoftIRQ të përpunojë
# 300 paketa nga NIC përpara se të lirojë CPU-në
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# nëse si klienti ashtu edhe serveri kanë mbështetje TFO, të cilën e raportojnë me anë
# të një flamuri të veçantë në paketën TCP. Në rastin tonë, është një placebo, thjesht
# duket bukur)Drrjetit luster u ndan në interfaca rrjetësh të veçanta 10Gbps në një rrjet të sheshtë të veçantë. Çdo makinë kishte karta rrjeti me dy porta të instaluara mellanox 10/25 Gbps, të vendosura në dy switch-e të veçantë 10Gbps. Agregimi u realizua me OSPF, pasi bonyosja me lacp për çudi tregoi një kapacitet maksimal të shfrytëzueshëm prej 16 Gbps, ndërsa ospf e shfrytëzoi plotësisht të dy dhjetat në çdo makinë. Planet e ardhshme ishin të shfrytëzohej ROCE në këto mellanox, për të reduktuar latencën. Si e konfigurojmë këtë pjesë të rrjetit:
- Duke qenë se vetë makinat kanë adresa IP të jashtme në BGP, ne na nevojitet softi — (për të qenë më të saktë në momentin e shkruarjes së artikullit ky ishte ) kishte qenë i instaluar.
- Në total, mbi makinat kishte dy karta rrjeti me nga dy interfaca — në total 4 porte. Një kartë rrjeti me dy porta shikonte drejt fabrikës dhe mbi të ishte konfiguruar BGP, ndërsa tjetra — me dy porta shikonte në dy switch-e të ndryshëm dhe mbi të ishte vendosur OSPF
Për më shumë për konfigurimin e OSPF: Detyra kryesore është të agregojmë dy lidhje dhe të kemi tolerancë ndaj dështimeve.
dy interfaca rrjeti janë konfiguruar në dy rrjete të thjeshta të sheshta — 10.10.10.0/24 dhe 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 ens1f1përmes të cilave makinat shihen njëra-tjetrën.
DISK
Hapi tjetër ishte të optimizoja punën e disqeve. Për SSD ndryshova planifikuesin në noop, për HDD — deadline. Nëse flasim në terma të thjeshtë — NOOP funksionon në parimin "ai që ngrihet i pari, merr sandalet", që në anglisht quhet "FIFO (First In, First Out)". Kërkesat renditen sipas ardhjes së tyre. DEADLINE është më i fokusuar në lexim, plus procesi nga radhët merr qasje pothuajse monopol në disk në momentin e operacionit. Për sistemin tonë kjo është ideale — sepse me secilin disk punon vetëm një proces — OSD daemon.
(Ata që dëshirojnë të thellohen në planifikuesin e hyrjes-daljes mund të lexojnë rreth tij këtu:
Ata që preferojnë të lexojnë në rusisht: )
Në rekomandimet për optimizimin e linux-it, sugjerohet gjithashtu të rritet nr_request
nr_requests
Vlera e nr_requests përcakton sasinë e kërkesave I/O që grumbullohen para se planifikuesi I/O të dërgojë/marrë të dhëna në pajisjen bllokuese. Nëse po përdorni një kartë RAID/pajisje bllokuese që mund të përballojë një radhë më të madhe sesa çfarë është vendosur për planifikuesin I/O, rritja e vlerës së nr_requests mund të ndihmojë për të përmirësuar kapacitetin dhe për të reduktuar ngarkesën në server kur ndodhin sasi të mëdha I/O në server. Nëse po përdorni Deadline ose CFQ si planifikues, sugjerohet që të vendosni vlerën e nr_request në 2 herë vlerën e thellësisë së radhës.
PO! Vetë qytetarët zhvillues të CEPH na sigurojnë se sistemi i tyre i prioriteteve funksionon më mirë.
WBThrottle dhe/ose nr_requests.
WBThrottle dhe/ose nr_requests.
Depoja e skedarëve përdor operacione të buffer-uara të regjistrimit të I/O; kjo sjell një sërë përfitimesh nëse regjistri i depozitës së skedarëve ndodhet në një medium më të shpejtë. Kërkesat e klientëve marrin njoftime sapo të dhënat regjistrohen, dhe më pas ato shuhen në diskun e dhënave në një kohë më të vonë duke përdorur funksionalitetin standard të Linux. Kjo e bënë të mundur për OSD-të e disqeve me rrotulla që të ofrojnë një latencë regjistrimi të ngjashme me SSD gjatë regjistrimeve me paketa të vogla. Kjo regjistrim i vonuar gjithashtu lejon kernelin të ristrukturojë kërkesat e operacioneve të I/O në disk në shpresën që t'i bashkojë ato ose t'u lejojë kryeveprave ekzistuese të diskut të zgjedhin një rrugë më optimale mbi pllakat e tyre. Efekti përfundimtar është ai që mund të nxirrni pak më shumë operacione I/O nga secili disk se sa do të ishte e mundur me operacione I/O direkte ose sinkron.
Megjithatë, ka një problem të caktuar nëse volumi i regjistrimeve të ardhshme në këtë klaster Ceph do të tejkalojë të gjitha mundësitë e disqeve në bazë. Në një skenar të tillë, numri i përgjithshëm i operacioneve të I/O që priten për regjistrim në disk mund të rritet pa kontroll dhe të shkaktojë radhë operacionesh I/O që mbushin të gjithë diskun dhe radhët e Ceph. Kërkesat për lexim ndikojnë veçanërisht keq, pasi ato ngecin ndërmjet kërkesave për regjistrim, të cilat mund të kërkojnë disa sekonda për t'u shlyer në diskun kryesor.
Për të përballuar këtë problem, Ceph ka një mekanizëm të ndërtuar për ruajtjen e skedarëve, që quhet WBThrottle, për të kufizuar vëllimin e përgjithshëm të operacioneve të inputit/faqes së pritur për shkrim, të cilat mund të radhiten dhe të fillojnë procesin e tyre të shkarkimit më herët sesa do ndodhte natyrshëm nga bërthama. Fatkeqësisht, testimi tregon se vlerat e paracaktuara ende nuk mund të kufizojnë sjelljen ekzistuese në një nivel që mund të reduktojë ndikimin e tillë në latentën e operacioneve të leximit. Rregullimi mund të ndryshojë këtë sjellje dhe të ulin gjatësinë e përgjithshme të radhëve të shkrimeve, duke bërë të mundur që ndikimi të mos jetë aq i fortë. Megjithatë, ka një kompromis: zvogëlimi i numrit maksimal të lejuar të shkrimeve në radhë mund të reduktojë mundësinë që bërthama vetë të maksimizojë efikasitetin e saj në renditjen e kërkesave që po vijnë. Duhet të mendoni pak se çfarë është më e nevojshme për rastin tuaj të veçantë të përdorimit dhe ngarkesat e punës dhe të rregulloni për t'iu përputhur atyre.
Për të menaxhuar thellësinë e kësaj radhë për shkrime të pritura, ju mund të zvogëloni numrin maksimal të operacioneve të pritshme të inputit/fazës, duke u përdorur me konfigurimet e WBThrottle, ose duke zvogëluar vlerën maksimale për operacionet e pritshme në nivelin e vetë bërthamës. Të dyja mund të menaxhojnë me efikasitet të njëjtën sjellje dhe preferencat tuaja do të jenë në bazë të zbatimit të këtij rregullimi.
Duhet gjithashtu të vërehet se sistemi i prioriteteve të operacioneve në Ceph është më efikas për kërkesat e shkurtra në nivelin e diskut. Duke zvogëluar radhën totale për këtë disk, vendndodhja kryesore në radhë kalon në Ceph, ku ka më shumë kontroll mbi prioritetin e operacionit të inputit/faqes. Le të shqyrtojmë këtë shembull:
echo 8 > /sys/block/sda/queue/nr_requestsTË PËRGJITHSHME
Dhe disa rregullime të tjera të bërthamës, që e bëjnë makinën tuaj të butë dhe të qetë, për të nxjerrë edhe pak performancë nga hardueri.
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
# Disket në çdo makinë është 25, kështu që llogaritëm se do të ketë shumë procese
kernel.threads-max=2097152
# Threads, sigurisht, gjithashtu.
vm.max_map_count=524288
# Rritëm numrin e hapësirave të hartës së memories së procesit.
# Siç tregohet në dokumentacionin për variablat e bërthamës
# Hapësirat e hartës së memories përdoren si një efekt anësor i thirrjes
# malloc, direkt me mmap, mprotect dhe madvise, si dhe gjatë ngarkimit
# bibliotekave të përbashkëta.
fs.aio-max-nr=50000000
# Tuning parametrat e input-output
# Bërthama e Linux-it ofron funksionin e hyrjes dhe daljes asinkrone jo-bllokuese (AIO),
# e cila lejon një proces të niste shumë operacione hyrje-daljeje
# njëkohësisht, pa pritur për përfundimin e ndonjë prej tyre.
# Kjo ndihmon në rritjen e performancës së aplikacioneve,
# që mund të mbivendosen me procesimin dhe hyrje-daljen.
# Parametri aio-max-nr përcakton numrin maksimal të lejuar
# të kërkesave të përbashkëta.
vm.min_free_kbytes=1048576
# madhësia minimale e memories së lirë që duhet ruajtur.
# Vendosur 1Gb, e cila është mjaft e mjaftueshme për funksionimin e sistemit operativ,
# dhe lejon shmangien e OOM Killer për proceset OSD. Megjithëse memoria është
# e mjaftueshme
vm.swappiness=10
# Them të përdoret swap nëse mbetet e lirë 10% e memories.
# Në makinat me 128G RAM, dhe 10% kjo është 12 Giga. Më shumë se mjaftueshëm për punë.
# Parametri standard prej 60% detyronte sistemin të ngadalësohej, duke u futur në swap,
# kur kishte ende shumë memorie të lirë
vm.vfs_cache_pressure=1000
# Rrisim nga 100. Detyrojmë bërthamën të shkarkojë më aktivisht
# faqet e memories të papërdorura nga cache.
vm.zone_reclaim_mode=0
# Lejon përcaktimin e qasjeve më ose më pak agresive ndaj
# rikuperimit të memories, kur rezervuari përfundon.
# Nëse është vendosur në zero, nuk ndodhi rikuperimi i zonës.
# Për serverat e skedarëve ose ngarkesat e punës
# është e dobishme, nëse të dhënat e tyre janë të ruajtura, zone_reclaim_mode
# të mbetet të çaktivizohet, pasi efekti i ruajtjes,
# për siguri do të jetë më i rëndësishëm se vendndodhja e të dhënave.
vm.dirty_ratio=20
# Përqindja e memories së RAM, që mund të dedikohet për "faqet e ndotura"
# Llogaritur nga një vlerësim i përafërt:
# Në sistem 128 gigabajt memorie.
# Rreth 20 disqe SSD, të cilat kanë në konfigurimet CEPH të caktuara
# allocated për ruajtje 3G RAM.
# Rreth 40 disqe HDD, për të cilat ky parametr është 1G
# 20% nga 128 është 25.6 gigabytes. Pra, në rastin e shfrytëzimit maksimal të memories,
# për sistemin do të mbeten 2.4G memories. E cila duhet të jetë mjaft e mjaftueshme për të mbijetuar dhe pritur
# goditjen e këmbësorisë - e cila do të thotë ardhjen e DevOps që do të rregullojë gjithçka.
vm.dirty_background_ratio=3
# përqindja e memories sistemit, që mund të mbushet me faqet e ndotura deri në atë,
# përpara se proceset e prapambetura pdflush/flush/kdmflush të shkruajnë ato në disk
fs.file-max=524288
# E pra, numri i skedarëve të hapur do të jetë ndoshta shumë më i madh se sa thuhet sipas parazgjedhjes. Shkëndija në CEPH
Parametrat mbi të cilët do doja të qëndroja më në detaje:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Tre parametra që përfshijnë
journal_block_align: true # i/o direkt
journal_dio: true # në jurnal
journal_max_write_bytes: 1073714824 # Të zgjatëm disi madhësinë maksimale
# e operacionit të shkruar njëherësh në jurnal
journal_max_write_entries: 10000 # Po ashtu numri i regjistrimeve për njëkohësisht
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Vendosëm të krijojmë një wal të veçantë
# Madje provuam të përfitojmë për këtë çështje
# NVMe
bluestore_block_db_create: true # Dhe për journali një pajisje të veçantë
bluestore_block_db_size: '5368709120 #5G'
bluestore_block_wal_create: true
bluestore_block_wal_size: '1073741824 #1G'
bluestore_cache_size_hdd: '3221225472 # 3G'
# një volum i madh i RAM-it lejon
# ruajtjen e sasisë së madhe
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 # numri i tread-ave për demonin në një disk
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # numri i operacioneve njëkohësisht të mbushjes në një 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 # Karakteristikat e lakmisë. Shumë shpejt është bërë
osd_pool_default_size: 2 # e nevojshme të zvogëlohet hapësira, sepse
# vendosëm si zgjidhje përkohshme
# zvogëlimin e numrit të
# kopjeve të të dhënave
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 # parametri rregullohet sipas nevojës në lëvizje
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Disa nga parametrat që u testuan në QA në versionin 12.2.12, mungojnë në versionin ceph 12.2.2, për shembull osd_recovery_threads. Prandaj në planet ishte përfshirë azhurnimi në prodhim në 12.2.12. Praktika ka treguar kompatibilitetin në një klaster midis verzioneve 12.2.2 dhe 12.2.12, duke mundësuar një azhurnim të vazhdueshëm.
Klasteri testues
Për fat të keq, për testimin ishte e nevojshme të kishim versionin e njëjtë si në prodhim, por në momentin kur fillova punën me klasterin, në depo kishte vetëm një version më të ri. Pas shqyrtimit të ndryshimeve në versionin minor, e kuptuam që ndryshimet nuk ishin shumë të mëdha.1393 rreshta në konfigurime krahasuar 1436 me versionin e ri), vendosëm të fillonim të testonim versionin e ri (prapëseprapë do të bëjmë përditësimin, pse të vazhdojmë me gjërat e vjetra).
E vetmja gjë që u përpoqëm të ruanim nga versioni i vjetër ishte paketa ceph-deploy, sepse disa utilitare (dhe disa punonjës) ishin të përshtatura me sintaksën e saj. Versioni i ri ishte ndjeshëm ndryshe, por nuk kishte asnjë ndikim në punën e klasterit, kështu që e mbajëm atë në versionin 1.5.39
Duke qenë se ekipi ceph-disk qartë thotë që është i deprecated dhe ju lutem, përdoreni komandën ceph-volume — filluam të krijonim OSD me këtë komandë, pa humbur kohë me atë të vjetruar.
Plani ishte i tillë — të krijonim një pasqyrë nga dy disqe SSD, mbi të cilat do të vendosnim regjistrat OSD, të cilat, nga ana tjetër, do të ishin të vendosura në SAS spinning. Kështu do të mbroheshim nga problemet me të dhënat në rast të rënies së një disku me regjistrin.
Filluan të krijojnë klasterin sipas dokumentacionit.
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # ngushëm konfigurimin e përgatitur paraprakisht
[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 # adresa është ndryshuar, natyrisht ))
rgw_dns_name = s3-qa.mycompany.ru # dhe kjo adresë është ndryshuar
rgw_host = s3-qa.mycompany.ru # dhe ky gjithashtu
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # më shumë se treqind grupe vendosjeje
# nuk u vendosën në disk
# ndonëse parametri, natyrisht, varet nga numri i grupeve,
# dimensionet e tyre dhe numri i OSD. Të kesh pak por të shëndetshëm PG
# gjithashtu nuk është një zgjedhje më e mirë - vuan saktësia e balancimit
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # përkohësisht për disqet SSD hapësira për
# jurnal është e njëjtë me atë për OSD
# vendosëm se 5% e diskut (i cili mbetet 1.2Tb)
# duhet të mjaftojë, dhe korrelon me parametrin
# bluestore_block_db_size plus variabilitetin në grupe të mëdha
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-qE para, ndodhi i pari që u ndesha në punën e kësaj versioni ceph-deploy me klasterin version 12.2.12 – ishte një gabim gjatë përpjekjes për të krijuar OSD me db në një RAID softuerik –
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid nuk mundi të zbulojë një PARTUUID për pajisjen: /dev/md1Vërtetë, blkid nuk tregonte PARTUUID-në, duhej të krijoja pjesët manualisht:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# do të ketë shumë pjesë,
# pa GPT nuk do t'i krijojmë dot
# madhësia e pjesës e kemi caktuar në konfigurimin më sipër = bluestore_block_db_size: '5368709120 #5G'
# Kam 20 disqe për OSD, ndjeshëm më vjen keq të krijoj pjesët manualisht
# kështu që bëra një cikël
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneDuket se gjithçka ishte e gatshme, provojmë përsëri të krijojmë OSD dhe marrim gabimin e mëposhtëm (i cili, për fat të keq, nuk u riprodhua në prodhim)
duke krijuar OSD të tipit bluestore pa specifikuar rrugën për WAL, por me specifikimin e db
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 uuid i pandeshmueshëm
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) hap hap ka marrë: (22) Argument i pavlefshëm
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db shto pajisjen e bllokut(/var/lib/ceph/osd/ceph-0//block.wal) u kthye: (22) Argument i pavlefshëm
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs dështoi, (22) Argument i pavlefshëm
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs dështoi me gabim (22) Argument i pavlefshëm
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** GABIM: gabim gjatë krijimit të dyqanit të zbrazët të objekteve në /var/lib/ceph/osd/ceph-0/: (22) Argument i pavlefshëmMegjithatë, nëse në të njëjtin pasqyrë (ose diku tjetër, sipas zgjedhjes) krijoni një pjesë tjetër për WAL dhe e specifikoni atë gjatë krijimit të OSD – atëherë gjithçka do të shkojë mirë (përveç shfaqjes së një WAL të veçantë, që ndoshta nuk e keni dëshiruar).
Por, pasi që gjithsesi në planet e largëta ishte parashikuar që WAL të shkonte në NVMe, kjo praktikë nuk ishte e tepërt.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2Krijuam monitorët, menaxherët dhe OSD. Tani dëshirojmë t'i grupojmë ato në mënyrë të ndryshme, sepse kemi plane për të pasur disqe të llojeve të ndryshme – pool-et e shpejtë në SSD dhe ato të mëdha, por të ngadalta në disqe SAS.
Të supozojmë se çdo server ka 20 disqe, dhjetë të parët janë një tip, të dytët - një tjetër.
Harta fillestare, defaul, duket kështu:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID KLASI PESHA LLOJI EMRI STATUS RIKTHIM PRI-AFF
-1 14.54799 rrënja default
-3 9.09200 host ceph01-q
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 up 1.00000 1.00000
2 ssd 1.00000 osd.2 up 1.00000 1.00000
3 ssd 1.00000 osd.3 up 1.00000 1.00000
4 hdd 1.00000 osd.4 up 1.00000 1.00000
5 hdd 0.27299 osd.5 up 1.00000 1.00000
6 hdd 0.27299 osd.6 up 1.00000 1.00000
7 hdd 0.27299 osd.7 up 1.00000 1.00000
8 hdd 0.27299 osd.8 up 1.00000 1.00000
9 hdd 0.27299 osd.9 up 1.00000 1.00000
10 hdd 0.27299 osd.10 up 1.00000 1.00000
11 hdd 0.27299 osd.11 up 1.00000 1.00000
12 hdd 0.27299 osd.12 up 1.00000 1.00000
13 hdd 0.27299 osd.13 up 1.00000 1.00000
14 hdd 0.27299 osd.14 up 1.00000 1.00000
15 hdd 0.27299 osd.15 up 1.00000 1.00000
16 hdd 0.27299 osd.16 up 1.00000 1.00000
17 hdd 0.27299 osd.17 up 1.00000 1.00000
18 hdd 0.27299 osd.18 up 1.00000 1.00000
19 hdd 0.27299 osd.19 up 1.00000 1.00000
-5 5.45599 host ceph02-q
20 ssd 0.27299 osd.20 up 1.00000 1.00000
21 ssd 0.27299 osd.21 up 1.00000 1.00000
22 ssd 0.27299 osd.22 up 1.00000 1.00000
23 ssd 0.27299 osd.23 up 1.00000 1.00000
24 hdd 0.27299 osd.24 up 1.00000 1.00000
25 hdd 0.27299 osd.25 up 1.00000 1.00000
26 hdd 0.27299 osd.26 up 1.00000 1.00000
27 hdd 0.27299 osd.27 up 1.00000 1.00000
28 hdd 0.27299 osd.28 up 1.00000 1.00000
29 hdd 0.27299 osd.29 up 1.00000 1.00000
30 hdd 0.27299 osd.30 up 1.00000 1.00000
31 hdd 0.27299 osd.31 up 1.00000 1.00000
32 hdd 0.27299 osd.32 up 1.00000 1.00000
33 hdd 0.27299 osd.33 up 1.00000 1.00000
34 hdd 0.27299 osd.34 up 1.00000 1.00000
35 hdd 0.27299 osd.35 up 1.00000 1.00000
36 hdd 0.27299 osd.36 up 1.00000 1.00000
37 hdd 0.27299 osd.37 up 1.00000 1.00000
38 hdd 0.27299 osd.38 up 1.00000 1.00000
39 hdd 0.27299 osd.39 up 1.00000 1.00000
-7 6.08690 host ceph03-q
40 ssd 0.27299 osd.40 up 1.00000 1.00000
41 ssd 0.27299 osd.41 up 1.00000 1.00000
42 ssd 0.27299 osd.42 up 1.00000 1.00000
43 ssd 0.27299 osd.43 up 1.00000 1.00000
44 hdd 0.27299 osd.44 up 1.00000 1.00000
45 hdd 0.27299 osd.45 up 1.00000 1.00000
46 hdd 0.27299 osd.46 up 1.00000 1.00000
47 hdd 0.27299 osd.47 up 1.00000 1.00000
48 hdd 0.27299 osd.48 up 1.00000 1.00000
49 hdd 0.27299 osd.49 up 1.00000 1.00000
50 hdd 0.27299 osd.50 up 1.00000 1.00000
51 hdd 0.27299 osd.51 up 1.00000 1.00000
52 hdd 0.27299 osd.52 up 1.00000 1.00000
53 hdd 0.27299 osd.53 up 1.00000 1.00000
54 hdd 0.27299 osd.54 up 1.00000 1.00000
55 hdd 0.27299 osd.55 up 1.00000 1.00000
56 hdd 0.27299 osd.56 up 1.00000 1.00000
57 hdd 0.27299 osd.57 up 1.00000 1.00000
58 hdd 0.27299 osd.58 up 1.00000 1.00000
59 hdd 0.89999 osd.59 up 1.00000 1.00000
Do të krijojmë raftet dhe serverët tanë virtualë me blackjack dhe gjëra të tjera:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root #krijuam një root të ri
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #krijuam një host të ri
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #përcaktuam serverin në raft tjetër
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Shtuam OSD në server
# Nëse u krijua gabim atëherë mund ta fshijmë
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Problemet me të cilat u ballafaquam në luftë klaster, gjatë përpjekjes për të krijuar një host të ri dhe për ta lëvizur atë në raftin ekzistues — komanda ceph osd crush move ceph01-host root=rack01 u bllokua, dhe monitorët fillonin të binin një nga një. Ndërprerja e komandës me CTRL+C e kthen klasterin në botën e gjallë.
Kërkimi tregoi një problem të tillë:
Zgjidhja ishte të dump-ojmë crushmap dhe ta fshijmë seksionin rule replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Dumpim hartën në formë të papërpunuar
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #e kthejmë në formë të lexueshme
root@ceph01-prod:~#vim crushmap.txt #e redaktojmë, duke fshirë rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #e kompilojmë përsëri
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #e ngremë në klasterKujdes: kjo operacion mund të shkaktojë ribalancim të grupit të vendosjes midis OSD-ve. Kjo na ndodhi, por shumë pak.
E çuditshme, me të cilën u përballëm në klustërin e testimit, është se pas rinisjes së serverit OSD-të harronin se ishin zhvendosur në servera dhe stiva të reja, dhe ktheheshin në root default.
Si rezultat, duke ndërtuar skemën përfundimtare, ku krijuam veçmas root për diskët ssd dhe veçmas për ata spinning, ne shpërndamë të gjithë OSD-të nëpër stiva dhe thjesht fshimë default root. Pas rinisjes, OSD-të filluan të qëndronin në vendet e tyre.
Pas një kërkimi më vonë në dokumentacion, gjetëm parametrin që përgjigjej për këtë sjellje. Rreth tij do të flasim në pjesën e dytë.
Si i bëmë grupet e ndryshme sipas llojeve të diskëve.
Për fillim, krijuam dy root-a — një për ssd dhe një për hdd.
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootPasi serverat fizikisht ndodhen në stiva të ndryshme — për lehtësi krijuam stiva dhe aty vendosëm serverat.
# Стойки:
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 hostdhe shpërndamë diskët sipas llojeve të tyre në servera të ndryshëm.
root@ceph01-q:~# Diskët nga 0 në 3 janë SSD, ndodhen në ceph01-q, i vendosim në 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:~# po njësoj me serverat e tjerë.Pas shpërndarjes së diskëve në root-at ssd-root dhe hdd-root, ne lanë root-default të zbrazët, prandaj mund ta fshijmë.
root-ceph01-q:~#ceph osd crush remove defaultMë pas duhet të krijojmë rregulla shpërndarjeje, të cilat do të lidhim me rezervuarët që do krijojmë — në rregulla do të shpallim në cilat root mund të vendosen të dhënat e rezervuarit tonë dhe niveli i unikësisë së replikave — për shembull, replikat duhet të jenë patjetër në servera të ndryshëm, ose në stiva të ndryshme (madje mund të jenë në root të ndryshme, nëse kemi një shpërndarje të tillë).
Para se të zgjidhni llojin, është më mirë të lexoni dokumentacionin:
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:~# Ne shpallëm dy rregulla, në të cilat të dhënat replikohen
root-ceph01-q:~# midis hosteve - pra replika duhet të jetë në një host tjetër,
root-ceph01-q:~# edhe nëse ndodhen në të njëjtin stivë
root-ceph01-q:~# Në prodhim, nëse ka mundësi, është më mirë të shpërndahen hostet
root-ceph01-q:~# nëpër stiva dhe të specifikohet që replikat të shpërndahen nëpër stiva:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnKështu krijojmë pultat në të cilat dëshirojmë të ruajmë imazhet e disqeve të virtualizimit tonë — 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 1024Dhe i themi këtyre pulate se cilat rregulla shpërndarjeje duhet të përdorin
root-ceph01-q:~#ceph osd crush rule ls # shohim listën e rregullave
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id #zgjidhim ID-në e duhur
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Zgjedhja e numrit të grupit të vendosjes duhet të bëhet me një vizion paraprak mbi klasterin tuaj — sa OSD do të ketë atje, çfarë sasi të dhënash (në përqindje nga shuma totale) do të jetë në pul, sa të dhëna gjithsej.
Së bashku, është e preferueshme të mos kemi më shumë se 300 grupe vendosjeje për diskut, dhe do të jetë më e lehtë të balancojmë me grupe të vogla — domethënë, nëse e gjithë pule juaj zë 10 Tb dhe ka 10 PG — atëherë balansimi duke kaluar bloket e terabyteve (pg) do të jetë i komplikur — të kalosh rërën me një madhësi më të vogël është më e lehtë dhe më e saktë.
Por duhet të kujtohet se sa më shumë PG të ketë — aq më shumë resurse shpenzohen për llogaritjen e vendndodhjes së tyre — fillon të shfrytëzohet memoria dhe CPU.
Një kuptim i përafërt mund , i ofruar nga zhvilluesit e dokumentacionit CEPH.
Lista e materialeve:
Burimi: habr.com
