Zgjedhja e CEPH. Pjesa 1
Ishim të ndarë në pesë tenda, dhjetë switch-e optike, të konfiguruar BGP, disa dhjetë SSD dhe një sërë diskesh SAS të secilës ngjyrë dhe madhësi, dhe gjithashtu proxmox dhe dëshira për ta vendosur të gjithë statikën në një depo S3 të vetme. Jo se gjithçka ishte e nevojshme për virtualizimin, por pasi fillova të përdor opensource — duhej ta ndiqja pasionin deri në fund. E vetmja gjë që më shqetësonte ishte BGP. Në botë nuk ka askënd më të pafuqishëm, të papërgjegjshëm dhe të pa moralshëm se sa brendësia e routing-ut BGP. Dhe e dija se shumë shpejt do të zhyteshim në këtë.
Detyra ishte e thjeshtë — kishim një CEPH që nuk funksiononte shumë mirë. Duhej ta bënim 'mirë'.
Klusteri që më ra mua në dorë ishte heterogjen, i konfiguruar shpejt dhe praktikisht pa tuning. Ai përbëhej nga dy grupe nodash të ndryshme, me një rrjet të vetëm që shërbente si rrjet i klusterit dhe publik. Nodat ishin të mbushura me katër lloje diskesh — dy lloje SSD të grumbulluara në dy rregulla të ndryshme vendosjeje dhe dy lloje HDD të madhësive të ndryshme, të grumbulluara në një grup të tretë. Problemi me madhësitë e ndryshme u zgjidh me pesha të ndryshme OSD.
Konfigurimi vetë u ndan në dy pjesë — tuning-i i sistemit operativ dhe tuning-i i CEPH vetë dhe konfigurimet e tij.
Përmirësimi i OS-së
Rrjeti regjistro log /dev/log local0 regjistro log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s përdorues haproxy grup haproxy daemondefaults log global mode http opsion httplog opsion 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ë ndikohej 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 host, rrjeti përdorej gjithmonë.
Prandaj, e para gjë që vendosa të bëja ishte të konfiguroja pak rrjetin aktual, duke përpiquar njëkohësisht të bindja për të kaluar në rrjete të ndara.
Fillimisht, nisa të rregulloja parametrat e kartave të rrjetit. Nisa me konfigurimin e radhëve:
çfarë kishte:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Parametrat e kanalit për ens1f1:
Maksimumet e paracaktuar:
RX: 0
TX: 0
Tjera: 1
E përbashkët: 63
Parametrat aktualë të hardware-it:
RX: 0
TX: 0
Tjera: 1
E përbashkët: 1
root@ceph01:~# ethtool -g ens1f1
Parametrat e rrethit për ens1f1:
Maksimumet e paracaktuar:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Parametrat aktualë të hardware-it:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Parametrat e kanalit për ens1f1:
Maksimumet e paracaktuar:
RX: 0
TX: 0
Tjera: 1
E përbashkët: 63
Parametrat aktualë të hardware-it:
RX: 0
TX: 0
Tjera: 1
E përbashkët: 1Duket se parametrat aktualë janë larg maksimumeve. E rritëm:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63E udhëhoqa nga një artikull i shkëlqyer
rrita gjatë e radhës së dërgesës txqueuelen nga 1000 në 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Dhe ndjekur dokumentacionin e vetë ceph
e rita MTU në 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000Shtova në /etc/network/interfaces, që e gjithë e mësipërmja të ngarkohet gjatë startit
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 9000Pas kësaj, duke ndjekur po atë artikull, fillova me kujdes të rregulloja parametrat e kernelit 4.15. Duke pasur parasysh se nodat kishin 128G RAM, rezultoi një skedar konfigurimi për sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
#Maksimalna madhësi e buffers për marrjen e të dhënave për të gjitha lidhjet 54M
net.core.wmem_max = 56623104
#Maksimalna madhësi e buffers për dërgimin e të dhënave për të gjitha lidhjet 54M
net.core.rmem_default = 56623104
#Madhësia e buffers për marrjen e të dhënave sipas parazgjedhjes për të gjitha lidhjet. 54M
net.core.wmem_default = 56623104
#Madhësia e buffers për dërgimin e të dhënave sipas parazgjedhjes për të gjitha lidhjet 54M
# për çdo socket
net.ipv4.tcp_rmem = 4096 87380 56623104
#Vektori (minimumi, sipas parazgjedhjes, maksimumi) variable në skedarin tcp_rmem
# përmban 3 numra të plotë, që përcaktojnë madhësinë e buffers për marrjen e të dhënave në socket-et TCP.
# Minimumi: çdo socket TCP ka të drejtë të përdorë këtë memorie
# në momentin e krijimit të tij. Përdorimi i një buffers të tillë
# garantohet edhe nëse arrihet kufiri i limitit (moderate memory pressure).
# Madhësia minimale e buffers sipas parazgjedhjes është 8 Kbyte (8192).
#Vlera sipas parazgjedhjes: sasia e memories që lejohet për bufferin
# për dërgimin e socket-it TCP sipas parazgjedhjes. Kjo vlerë zëvendëson
# parametrin /proc/sys/net/core/rmem_default, i përdorur nga protokolle të tjera.
# Vlera e buffers sipas parazgjedhjes zakonisht (sipas parazgjedhjes)
# është 87830 byte. Kjo përcakton madhësinë e dritares 65535 me
# vlerën sipas parazgjedhjes të tcp_adv_win_scale dhe tcp_app_win = 0,
# pak më të vogël se vlera sipas parazgjedhjes e tcp_app_win.
# Maksimumi: madhësia maksimale e buffers që mund të alokohen automatikisht
# për marrjen nga socket-i TCP. Kjo vlerë nuk heq maksimumin,
# e cila përcaktohet në skedarin /proc/sys/net/core/rmem_max. Në alokimin "statik"
# të memories me SO_RCVBUF ky parametr nuk ka vlerë.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Numri maksimal i socket-eve të hapura, që presin lidhjet.
net.ipv4.tcp_timestamps=1
# Lejon përdorimin e timestamp-eve, sipas RFC 1323.
net.ipv4.tcp_sack=1
# Lejon konfirmimet selektive të protokollit TCP
net.core.netdev_max_backlog=5000 (defolt 1000)
# numri maksimal i paketave në radhë për përpunim, nëse
# interface-i merr paketa më shpejt se sa bërthama mund t'i përpunojë.
net.ipv4.tcp_max_tw_buckets=262144
# Numri maksimal i socket-eve që ndodhen në gjendjen TIME-WAIT njëkohësisht.
# Nëse kjo prag arrihet – socket-i "i tepërt" shkatërrohet dhe shkruhet
# një mesazh në regjistrin sistemor.
net.ipv4.tcp_tw_reuse=1
# Lejojmë ripërdorimin e socket-eve TIME-WAIT në raste,
# kur protokolli e konsideron të sigurt.
net.core.optmem_max=4194304
#Rritni maksimumin e buffers së përgjithshëm ALLOCATABLE
#matuar në njësi faqesh (4096 byte)
net.ipv4.tcp_low_latency=1
# Lejon stakun TCP/IP të preferojë latencën e ulët
# mbi një bandwidth më të lartë.
net.ipv4.tcp_adv_win_scale=1
# Ky parametr ndikon në llogaritjen e sasisë së memories në buffer-in e socket-it,
# e cila dedikohet për madhësinë e dritares TCP dhe për buffer-in e aplikacionit.
# Nëse vlera tcp_adv_win_scale është negative, 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ë byte. Nëse vlera tcp_adv_win_scale
# është pozitive, atëherë për të përcaktuar madhësinë përdoret shprehja e mëposhtme:
# Bytes- bytes2 në fuqinë tcp_adv_win_scale
# Parametri merr një vlerë të plotë. Vlera sipas parazgjedhjes është 2,
# dmth, për buffer-in e aplikacionit i jepet ¼ e sasisë së përcaktuar nga
# parametri tcp_rmem.
net.ipv4.tcp_slow_start_after_idle=0
# mekanizmi i rinisjes së fillimit të ngadaltë, i cili rivendos vlerën e dritares
# së mbingarkesës, nëse lidhja nuk është përdorur për një periudhë të caktuar kohore.
# Është më mirë të çaktivizohet SSR në server për të përmirësuar performancën
# e lidhjeve afatgjata.
net.ipv4.tcp_no_metrics_save=1
#Mos e ruani rezultatet e matjeve të lidhjes TCP në cache gjatë mbylljes së saj.
net.ipv4.tcp_syncookies=0
#Çaktivizo mekanizmin e dërgimit të syncookie
net.ipv4.tcp_ecn=0
#Njoftimi i Shprehur të Ngarkesës (Explicit Congestion Notification) në
# lidhjet TCP. Përdoret për të njoftuar për ndodhin e "ngarkesës"
# në rrugën drejt një host-i ose rrjeti të caktuar. Mund të përdoret për të njoftuar
# host-in dërgues për nevojën e uljes së shpejtësisë së dërgimit të paketave përmes
# një ruter ose firewall-i të caktuar.
net.ipv4.conf.all.send_redirects=0
# çaktivizon dërgimin e ICMP Redirect … për hoste të tjerë. Kjo opsion është e nevojshme
# të jetë aktiv, nëse hosti funksionon si router i çdo lloji.
# Ne nuk kemi routing.
net.ipv4.ip_forward=0
#Përkthimi i drejtë. Ne nuk jemi një gateway, docker në makinat nuk është ngritur,
# nëna na nevojitet.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Nuk përgjigjemi ndaj kërkesave ICMP ECHO, të dërguara me paketa të shpërndara
net.ipv4.tcp_fin_timeout=10
#përcakton kohën e mbajtjes së socket-it në gjendjen FIN-WAIT-2 pas mbylljes
# nga ana lokale. Defolt 60
net.core.netdev_budget=600 # (defolt 300)
# Nëse ekzekutimi i premtimeve programore nuk kryhet mjaftueshëm gjatë,
# atëherë ritmi i rritjes së të dhënave të hyra mund të tejkalojë mundësinë e bërthamës
# për të zbrazur bufferin. Si rezultat, buffers e NIC do mbushen, dhe trafiku do humbasë.
# Ndonjëherë, është e nevojshme të rritet periudha e punës SoftIRQs
# (premtimeve programore) me CPU. Kjo kontrollohet nga netdev_budget.
# Vlera sipas parazgjedhjes 300. Parametri do ta detyrojë procesin SoftIRQ të përpunojë
# 300 paketa nga NIC para se të lirojë CPU
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# nëse si klienti ashtu edhe serveri kanë mbështetje për TFO, për të cilën njoftohet nga
# një flamur i veçantë në paketën TCP. Në rastin tonë është placebo, duket thjesht
# bukur)Srrjeti i luster u ndikime të veçantë 10Gbps të ndërfaqeve rrjetike që janë ndarë në një rrjet të sheshtë. Në çdo makinë ishin vendosur karta rrjetesh me dy porte mellanox 10/25 Gbps, të vendosura në dy kalues të veçantë 10Gbps. Agregimi u realizua me anë të OSPF, pasi bërthama me lacp ndodhi për një arsye dhe tregoi një kapacitet maksimal prej 16 Gbps, ndërsa ospf arriti të shfrytëzojë plotësisht të dy dhjetët në çdo makinë. Planifikohej përdorimi i ROCE në këto mellanox për të ulur latencën. Si u konfigurua kjo pjesë e rrjetit:
- Duke pasur parasysh se makinat vetë kanë adresa IP jashtme në BGP, na nevojitet kjo software - (në fakt në momentin e shkruajtjes së këtij artikulli ishte ) kishte vendosur.
- Në total, në makina kishte dy rrjeta me dy ndërfaqe - gjithsej 4 porte. Një kartë rrjeti me dy porta shihte në fabrikë dhe BGP ishte i konfiguruar mbi të, ndërsa tjetra - me dy porta shihte në dy kalues të ndryshëm dhe mbi të ishte vendosur OSPF
Më shumë rreth konfigurimit të OSPF: Detyra kryesore - të agregojmë dy lidhje dhe të kemi tolerancë për dështime.
dy ndërfaqe rrjeti janë konfigurura 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 shohin njëra-tjetrën.
DISK
Hapi tjetër ishte optimizimi i punës së disqeve. Për SSD, ndryshova planifikuesin në noop, për HDD - deadline. Në termat e thjeshtë - NOOP punon në parimin 'kush erdhi i pari, ai merr sandalët', e cila në anglisht quhet 'FIFO (First In, First Out)'. Kërkesat renditen në radhë sipas ardhjes së tyre. DEADLINE është më i orientuar ndaj leximit, plus procesi nga radhë merr një akses pothuajse monopol në disk gjatë operacionit. Për sistemin tonë, kjo është ideale - sepse vetëm një proces punon me secilin disk - OSD daemon.
(Ata që dëshirojnë të thellohen në planifikuesin e hyrjes-daljes mund të lexojnë për të këtu:
Ata që preferojnë të lexojnë në rusisht: )
Në rekomandimet për optimizimin e linux-it, rekomandohet gjithashtu të rritet nr_request
nr_requests
Vlera e nr_requests përcakton numrin e kërkesave I/O që ruhen para se planifikuesi I/O të dërgojë/pranojë të dhëna në pajisjen bllokuese, nëse po përdorni një kartë RAID / Pajisje Bllokuese që mund të menaxhojë një radhë më të madhe se sa ku është vendosur planifikuesi I/O, rritja e vlerës së nr_requests mund të ndihmojë për të përmirësuar throughput-in dhe për të reduktuar ngarkesën e serverit 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 nr_request në 2 herë vlerën e thellësisë së radhës.
PO! Vetë zhvilluesit e CEPH na bindin se sistemi i tyre i prioriteteve punon më mirë
WBThrottle dhe/ose nr_requests
WBThrottle dhe/ose nr_requests
Storage sistemi përdor operacione të hyrjes/daljes të tamponizuara për shkrime; kjo sjell një sërë përfitimesh nëse regjistri i sistemit të skedarëve ndodhet në një mbajtës më të shpejtë. Kërkesat e klientëve marrin njoftime sapo të dhënat shkruhen në regjistër, dhe pastaj largohet në diskun e dhënave në një kohë më të vonë duke përdorur funksionalitetin standard të Linux-it. Kjo bën të mundur që OSD e disqeve mekanikë të ofrojnë latencë shkrimi të ngjashme me SSD gjatë shkrimeve të paketave të vogla. Kjo shkrim i vonuar gjithashtu lejon kernelin të riprogramojë kërkesat e hyrjes/daljes në disk me shpresën se ose mund t'i bashkojë ato, ose t'i lejojë kokat e ekzistuese të zgjedhin një rrugë më optimale mbi pllakën e tyre. Efekti përfundimtar është që mund të nxjerrësh pak më shumë operacione hyrjeje/daljeje nga çdo disk se sa do të ishte e mundur me operacione të drejtpërdrejta ose sinkronizuara.
Megjithatë, lind një problem nëse volumi i shkrimeve hyrëse në këtë kluster Ceph tejkalon të gjitha mundësitë e disqeve në themel. Në një skenar të tillë, numri total i operacioneve të hyrjes/daljes që presin të shkruhen në disk mund të rriten pa kontroll dhe të rezultojnë në radhë operacionet e hyrjes/daljes që mbushin plotësisht diskun dhe radhët e Ceph. Kërkesat për lexim ndikojnë veçanërisht keq, pasi ato ngecin midis kërkesave të shkrimit, të cilat mund të kërkojnë disa sekonda për t'u shkruar në diskun kryesor.
Për të adresuar këtë problem, Ceph ka një mekanizëm të integruar për ruajtjen e skedarëve i quajtur WBThrottle, i cili kryen dërgimin e vonuar. Ai është projektuar për të kufizuar vëllimin total të operacioneve të dërgimit të vonuar që mund të vendosen në radhë dhe të fillojnë procesin e heqjes më herët se sa do të ndodhte natyrshëm nga vetë bërthama. Fatkeqësisht, testimi tregon se vlerat e paracaktuar ende mund të mos reduktojnë sjelljen e ekzistueshme deri në një nivel që mund të zvogëlojë ndikimin në latencën e operacioneve të leximit. Rregullimi i këtyre vlerave mund ta ndryshojë këtë sjellje dhe të reduktojë përgjithshëm gjatë e radhëve të dërgimit, duke e bërë mundur që ndikimi të mos jetë shumë i fortë. Megjithatë, ka një kompromis: duke zvogëluar numrin maksimal të lejuar të derdhjeve në radhë, mund të ulni mundësinë e bërthamës për të maksimizuar efikasitetin e renditjes së kërkesave që vijnë. Duhet të mendoni pak për atë që është më e nevojshme për rastin tuaj specifik të përdorimit, ngarkesat e punës dhe ta rregulloni atë në përputhje me to.
Për të menaxhuar thellësinë e një radhe të dërgimit të vonuar, mund të ulni numrin maksimal të operacioneve të papërfunduara të hyrjes/daljes duke aplikuar rregullimet WBThrottle, ose duke zvogëluar vlerën maksimale për operacionet e papërfunduara në nivelin e bllokut të bërthamës tuaj. Të dyja mund të menaxhojnë në mënyrë efektive të njëjtin sjellje dhe preferencat tuaja do të jenë baza për zbatimin e këtij rregullimi.
Duhet gjithashtu të theksohet se sistemi i prioriteteve të operacioneve në Ceph është më efektiv për kërkesa më të shkurtra në nivelin e diskut. Me reduktimin e përgjithshëm të radhës për këtë disk, vendndodhja kryesore e rendit të tij zhvendoset në Ceph, ku ka më shumë kontroll mbi atë se çfarë prioriteti ka një operacion hyrjeje/daljeje. Le të shqyrtojmë shembullin e mëposhtëm:
echo 8 > /sys/block/sda/queue/nr_requestsTË PËRBASHKËTA
Dhe disa rregullime të tjera të bërthamës që lejojnë që makina juaj të jetë e butë dhe e qetë, duke nxjerrë më shumë performancë nga hardueri.
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
#Diskët në çdo makinë janë 25, kështu që kemi llogaritur se do të ketë shumë procese
kernel.threads-max=2097152
# Threads, natyrisht, gjithashtu.
vm.max_map_count=524288
# Rritëm numrin e zonave të hartës së memories për procesin.
# Siç rezulton nga dokumentacioni për ndryshoret e bërthamës
# Zonat e hartës së memories përdoren si një efekt anësor i thirrjes
# malloc, drejtpërdrejt përmes mmap, mprotect dhe madvise, si dhe gjatë ngarkimit
# bibliotekave të zakonshme.
fs.aio-max-nr=50000000
# Të përmirësojmë parametrat e input-output
# Bërthama Linux ofron një funksion të input-output asinkron pa bllokim (AIO),
# i cili lejon që procesi të iniciatojë disa operacione input-output
# njëkohësisht, pa pritur që ndonjëra prej tyre të përfundojë.
# Kjo ndihmon në përmirësimin e performancës së aplikacioneve,
# të cilat mund të mbivendosin përpunimin dhe input-output.
# Parametri aio-max-nr përcakton numrin maksimal të lejuar
# të kërkesave njëkohëshe.
vm.min_free_kbytes=1048576
# madhësia minimale e memories së lirë që duhet ruajtur.
# Caktoi 1Gb, që është më se e mjaftueshme për funksionimin e sistemit operativ,
# dhe ndihmon në shmangien e OOM Killer për proceset OSD. Megjithëse ka shumë
# memorie, por një rezervë kurrë nuk dëmton
vm.swappiness=10
# Thonë të përdoret swap nëse mbetet e lirë 10% e memories.
# Në makinat me 128G RAM, dhe 10% është 12 Giga. Më shumë se e mjaftueshme për funksionimin.
# Parametri standard prej 60% bënte që sistemi të ngadalësohej duke hyrë në swap,
# kur ende kishte shumë memorie të lirë
vm.vfs_cache_pressure=1000
# Rrisim nga 100 të zakonshmet. Kemi nxitur bërthamën të shkarkojë
# faqet e memories së papërdorura nga cache.
vm.zone_reclaim_mode=0
# Lejon të vendosim qasje më ose më pak agresive për
# rikuperimin e memories, kur në zonë përfundon memoria.
# Nëse është e vendosur në zero, nuk ndodh 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ë gecuara, zone_reclaim_mode
# duhet lënë të çaktivizuar, pasi efekti i gecimit,
# ndoshta do të jetë më i rëndësishëm se vendndodhja e të dhënave.
vm.dirty_ratio=20
# Përqindja e memories RAM që mund të ndahen për "faqet e ndotura"
# Llogaritur nga një llogaritje e përafërt:
# Në sistem janë 128 gigabyte memorje.
# Përafërsisht 20 disqe SSD, për të cilat në cilësimet e CEPH është specifikuar
# të ndahen për gecim 3G memorje.
# Përafërsisht 40 disqe HDD, për të cilat ky parameter është 1G
# 20% nga 128 është 25.6 gigabytes. Pra, në rastin e maksimalizimit të përdorimit të memories,
# për sistemin do të mbetet 2.4G memorje. Mjafton për të mbijetuar dhe pritur
# duke dëgjuar këmbanat e kalorësve - pra ardhjen e DevOps që do ta rregullojë gjithçka.
vm.dirty_background_ratio=3
# përqindja e memories sistemike, e cila mund të mbushet me faqe të ndotura deri në atë pikë,
# sa proceset e prapme pdflush/flush/kdmflush të shkruajnë ato në disk
fs.file-max=524288
# Pra, numri i skedave të hapura do të jetë ndoshta shumë më i lartë se sa cenohet standard. Shqyrtimi i CEPH
Cilësimet që do të donim të ndaleshim më në detaje:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Три параметра, включающие
journal_block_align: true # прямой i/o
journal_dio: true # на журнал
journal_max_write_bytes: 1073714824 # Немного растянем максимальный размер
# разово записываемой операции в журнал
journal_max_write_entries: 10000 # Ну и количество одновременных записей
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Решили делать отдельный wal
# Даже попытались выбить под это дело
# NVMe
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'
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: 2 # количество одновременных операций заполнения на один ОСД.
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 # Особенности жадности. Очень быстро стало
osd_pool_default_size: 2 # нехватать места, потому как временное
# решение приняли уменьшение количество
# реплик данных
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 # параметр регулируем по необходимости на ходу
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Часть параметров, которые тестировались на QA на версии 12.2.12, отсутствуют в версии ceph 12.2.2, к примеру osd_recovery_threads. Потому в планы было включено обновление на проде до 12.2.12. Практика показала совместимость в одном кластере версий 12.2.2 и 12.2.12, что позволяет сделать rolling update.
Тестовый кластер
Естественно, для тестирования было необходимо иметь ту-же версию что и на бою, но на момент начала моей работы с кластером в репозитории имелась лишь более новая. Посмотрев, что различите в минорной версии не сильно большое (1393 строки в конфигах против 1436 в новой версии), решили начать тестировать новую (все равно обновляться, чего ехать на старом хламе)
Единственное, что постарались оставить старой версии — это пакет ceph-deploy, поскольку часть утилит (и часть сотрудников) была заточена под её синтаксис. Новая версия достаточно сильно отличалась, но на работу самого кластера никак не влияла, и её оставили версии 1.5.39
Поскольку команда ceph-disk явно говорит что она deprecated и пользуйтесь-ка, уважаемые, командой ceph-volume — мы начали создавать OSD именно этой командой, не тратя время на устаревшее.
План был таков — создать зеркало из двух SSD дисков, на которых разместим журналы OSD, которые, в свою очередь, располагаются на шпиндельных SASах. Так подстрахуемся от проблем с данными при падении диска с журналом.
Создавать кластер стали по документации
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # kemi një konfigurim të përgatitur më parë
[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 # po ashtu kjo adresë është ndryshuar
rgw_host = s3-qa.mycompany.ru # po ashtu ky gjithashtu
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # më shumë se treqind grupe vendosjesh
# nuk u vendos në disk
# edhe pse parametri, natyrisht, varet nga numri i puseve,
# madhësitë e tyre dhe numri i OSD. Të kesh pak por të shëndetshëm PG
# gjithashtu nuk është një zgjedhje 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ër momentin për disk SSD, vendi për
# regjistrin e tyre është e njëjta pajisje si për OSD
# kemi vendosur që 5% e diskut (i cili është vetë 1.2Tb)
# duhet të jetë mjaftueshëm dhe korrelon me parametrin
# bluestore_block_db_size plus variabilitet për grupet e 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 që u takim në përdorimin e kësaj versioni të ceph-deploy me një grup versioni 12.2.12 — ishte një gabim gjatë përpjekjes për të krijuar OSD me db në RAID software —
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid nuk mundi të identifikonte një PARTUUID për pajisjen: /dev/md1Vërtet, blkid nuk tregon PARTUUID, duhej të krijonim parti sipas dorës:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# do të ketë shumë parti,
# pa GPT nuk mund të krijojmë ato
# madhësia e partisë e kemi shënuar në konfigurimin më sipër = bluestore_block_db_size: '5368709120 #5G'
# Kam 20 disqe për OSD, duarve nuk më pëlqen të krijoj parti
# 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 gjithçka është gati, provoni përsëri të krijoni OSD dhe marrim gabimin e mëposhtëm (i cili, për faktin, nuk u shfaq në situatën reale)
kur krijoni OSD të llojit bluestore pa specifikuar një rrugë 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 papërshtatshëm
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) hapur 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 bllok ( /var/lib/ceph/osd/ceph-0//block.wal) ktheu: (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 në krijimin e magazinës bosh në /var/lib/ceph/osd/ceph-0/: (22) Argument i pavlefshëmMegjithatë, nëse në të njëjtën espejo (ose në një vend tjetër, sipas zgjedhjes) krijoni një ndarje tjetër për WAL dhe e specifikoni ate gjatë krijimit të OSD — atëherë gjithçka do të shkojë mirë (përveç shfaqjes së WAL të ndarë, që ndoshta nuk e dëshironit).
Por, pasi gjithsesi në planet e mia të largëta ishte të lëvizja WAL 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 ndryshe, pasi në planet kemi disqe të ndryshëm tipesh — grupe të shpejta në SSD dhe të mëdha, por të ngadalta në SAS.
Le të supozojmë se në servera ka 20 disqe, dhjetë e para janë një tip, e dyta — një tjetër.
Harta fillestare, defolt, duket kështu:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 14.54799 root 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
Të krijojmë stacionet dhe serverët tanë virtualë me blackjack dhe 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 #kemi zhvendosur serverin në një stacion tjetër
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Shtuam OSD në server
# Nëse e krijuam gabim, atëherë mund ta fshijmë
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Problemet që na janë shfaqur në klasterin e prodhimit, gjatë përpjekjes për të krijuar një host të ri dhe për ta zhvendosur atë në një stacion ekzistues - komanda ceph osd crush move ceph01-host root=rack01 u ngrit dhe monitorët filluan të shuheshin një nga një. Ndalimi i komandës me CTRL+C e ktheu klasterin në një botë të gjallë.
Kërkimi zbuloi një problem të tillë:
Zgjidhja ishte të dumpojmë crushmap dhe të fshijmë seksionin rule replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Dumpim kartën në formën e papërpunuar
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #e kthejmë në një format të lexueshëm
root@ceph01-prod:~#vim crushmap.txt #redaktojmë, duke fshirë rregullin replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #kemi kompiluar përsëri
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #ngarkojmë në klasterKujdes: kjo operacion mund të shkaktojë ribalancimin e grupit të vendosjes midis OSD. Këtë e kemi pasur, por shumë shpesh.
Dhe gjëja e çuditshme që u përballëm në klasterin testues është se pas riçeljes së serverit OSD harrojnë se janë zhvendosur në servera dhe stacione të reja, dhe kthehen në root default.
Dhe kështu, pasi ndërtuam diagramin përfundimtar, në të cilin krijuam veçmas root për disqet ssd dhe veçmas për disqet me spin, shpërndamë të gjitha OSD-të në stacione dhe në të vërtetë fshimë root default. Pas rindezjes OSD-të filluan të mbeteshin në vendet e tyre.
Pas shqyrtimit më të thellë në dokumentacion, gjetëm një parametër që përgjigjet për këtë sjellje. Rreth tij në pjesën e dytë
Si e bëmë grupet e ndryshme sipas llojeve të disqeve.
Në fillim krijuam dy root-a - për ssd dhe për hdd
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootDuke qenë se serverët fizikisht ndodhen në stacione të ndryshme - për lehtësi kemi krijuar stacione dhe në to serverët
# Стойки:
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 kemi shpërndarë disqet sipas llojit të tyre në servera të ndryshme
root@ceph01-q:~# Disqet 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:~# ashtu si me serverat e tjerëDuke shpërndarë disqet sipas root-eve ssd-root dhe hdd-root e lamë root-default bosh, prandaj mund ta fshijmë atë
root-ceph01-q:~#ceph osd crush remove defaultMë pas duhet të krijojmë rregulla shpërndarjeje, të cilat do i lidhim me rezervuarët që do krijojmë - në rregulla do e përcaktojmë në cilat root mund të ruhen të dhënat e rezervuarëve tonë dhe niveli i unikësisë së kopjimit - për shembull, kopjet duhet të jenë domosdo në servera të ndryshëm, ose në stacione të ndryshme (madje mund të jenë edhe në root-e të ndryshëm, nëse kemi një shpërndarje të tillë)
Para se të zgjedhim llojin, është më mirë të lexojmë 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:~# Kemi përcaktuar dy rregulla, në të cilat të dhënat replikohen
root-ceph01-q:~# midis hosteve - pra, kopja duhet të gjendet në një host tjetër,
root-ceph01-q:~# pavarësisht nëse ato janë në një stacion
root-ceph01-q:~# Në prodhim, nëse ka mundësi, është më mirë të shpërndahen hostet
root-ceph01-q:~# sipas stacioneve dhe të përcaktojmë që të shpërndahen kopjet sipas stacioneve:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnKështu krijojmë grupe, në të cilat dëshirojmë të ruajmë imazhet e diskëve tanë të virtualizimit në të ardhmen — 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 u japim këtyre grupeve rregullat e vendosjes që 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 #zgjedhim ID-në e nevojshme
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Zgjedhja e numrit të grupeve të vendosjes duhet të bëhet me një vizion të qartë për klasterin tuaj — sa OSD do të ketë aty, çfarë sasisë të të dhënave (në përqindje nga volumi total) do të jetë në grup, dhe sa të dhëna gjithsej.
Në total është preferuar të mos keni më shumë se 300 grupe vendosjeje në disk, dhe do të ishte më e lehtë të balancoheshin grupe të mëdha — pra, nëse i gjithë grupi juaj zë 10 Tb dhe ka 10 PG — balancimi duke kaluar blloqet e terabajtëve (pg) do të jetë problematik — është më e lehtë të kalosh rërë me kokrriza të vogla me kovë.
Por duhet të mbani mend se sa më shumë të jenë PG-të — aq më shumë resurse harxhohen për të llogaritur vendosjen e tyre — fillon të shfrytëzohet memorie dhe CPU.
Një kuptim i përafërt mund , i ofruar nga zhvilluesit e dokumentacionit CEPH.
Lista e materialeve:
Burimi: habr.com
