Val av CEPH. Del 1
Vi hade fem rack, tio optiska switchar, konfigurerad BGP, ett par dussin SSD och massor av SAS-diskar i alla fĂ€rger och storlekar, och dessutom proxmox och en önskan att placera all statisk data i vĂ„rt eget S3-lagringsutrymme. Inte sĂ„ att allt detta var nödvĂ€ndigt för virtualisering, men nĂ€r man vĂ€l har börjat anvĂ€nda opensource â dĂ„ ska man följa sitt intresse till slutet. Det enda som oroade mig var BGP. Det finns ingen mer hjĂ€lplös, oansvarig och omoralisk form av intern routning Ă€n BGP. Och jag visste att vi ganska snart skulle dyka ner i detta.
Uppgiften var enkel â vi hade CEPH, men det fungerade inte sĂ€rskilt bra. Vi behövde göra det "bra".
Klustret jag fick var heterogent, konfigurerat hastigt och praktiskt taget inte finjusterat. Det bestod av tvĂ„ grupper av olika noder, med ett gemensamt nĂ€tverk som fungerade bĂ„de som kluster- och offentligt nĂ€tverk. Noderna var utrustade med fyra typer av diskar â tvĂ„ typer SSD, grupperade i tvĂ„ separata placeringsregler, och tvĂ„ typer HDD i olika storlekar, grupperade i en tredje grupp. Problemet med de olika storlekarna löses med olika vikter för OSD.
SjĂ€lva konfigurationen delades upp i tvĂ„ delar â finjustering av operativsystemet och finjustering av sjĂ€lva CEPH och dess instĂ€llningar.
FörbÀttring av OS
NĂ€tverk
Hög latens pĂ„verkade bĂ„de vid skrivning och vid balans. Vid skrivning â eftersom klienten inte fĂ„r svar om lyckad skrivning förrĂ€n replikorna av data i andra placeringsgrupper bekrĂ€ftar framgĂ„ng. Eftersom reglerna för distribution av replikor i CRUSH-kartan hade en replik pĂ„ varje vĂ€rd, sĂ„ anvĂ€ndes nĂ€tverket alltid.
DÀrför beslutade jag först att justera det aktuella nÀtverket lite, samtidigt som jag försökte övertyga om att flytta till separata nÀtverk.
Till att börja med justerade jag instÀllningarna för nÀtverkskorten. Jag började med att stÀlla in köerna:
vad som var:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Kanalparametrar för ens1f1:
FörinstÀllda maximivÀrden:
RX: 0
TX: 0
Ăvrigt: 1
Kombinerat: 63
Aktuella hÄrdvaruinstÀllda instÀllningar:
RX: 0
TX: 0
Ăvrigt: 1
Kombinerat: 1
root@ceph01:~# ethtool -g ens1f1
Ringparametrar för ens1f1:
FörinstÀllda maximivÀrden:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Aktuella hÄrdvaruinstÀllda instÀllningar:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Kanalparametrar för ens1f1:
FörinstÀllda maximivÀrden:
RX: 0
TX: 0
Ăvrigt: 1
Kombinerat: 63
Aktuella hÄrdvaruinstÀllda instÀllningar:
RX: 0
TX: 0
Ăvrigt: 1
Kombinerat: 1Det Àr uppenbart att de aktuella parametrarna Àr lÄngt ifrÄn de maximala. Jag ökade:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Med inspiration frÄn en utmÀrkt artikel
ökade jag lÀngden pÄ sÀndningskön txqueuelen frÄn 1000 till 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Och enligt dokumentationen frÄn Ceph
ökat ip a show till 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000Lade till i /etc/network/interfaces sÄ att allt ovanstÄende laddas vid start
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 9000DÀrefter, enligt samma artikel, började jag noggrant justera kÀrnhandtagen 4.15. Med 128G RAM pÄ noderna blev det en viss konfigurationsfil för sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
#Maximalt mottagningsbuffer för alla anslutningar 54M
net.core.wmem_max = 56623104
#Maximalt sÀndningsbuffer för alla anslutningar 54M
net.core.rmem_default = 56623104
#Standard mottagningsbuffer för alla anslutningar. 54M
net.core.wmem_default = 56623104
#Standard sÀndningsbuffer för alla anslutningar 54M
# för varje socket
net.ipv4.tcp_rmem = 4096 87380 56623104
#Vektorerad (min, standard, max) variabel i tcp_rmem-filen
# innehÄller 3 heltal som definierar storleken pÄ TCP-socketens mottagningsbuffer.
# Minimum: varje TCP-socket har rÀtt att anvÀnda detta minne vid
# skapandet av den. AnvÀndning av en sÄdan buffer
# garanteras Àven vid mjukvarupress.
# Standardminimum för buffern Àr 8 KByte (8192).
#StandardvÀrde: mÀngden minne som Àr tillÄtet för
# TCP-socketens sÀndningsbuffer som standard. Detta vÀrde tillÀmpas istÀllet
# för parametern /proc/sys/net/core/rmem_default, som anvÀnds av andra protokoll.
# Det anvÀnda standardvÀrdet för buffern Àr normalt (som standard)
# 87830 byte. Detta definierar storleken pÄ fönstret 65535 med
# det givna standardvÀrdet tcp_adv_win_scale och tcp_app_win = 0,
# nÄgot mindre Àn det antagna standardvÀrdet för tcp_app_win.
# Maximalt: maximala storleken pÄ den buffer som automatiskt
# kan tilldelas för att ta emot TCP-socketar. Detta vÀrde annullerar inte maxvÀrdet,
# som anges i filen /proc/sys/net/core/rmem_max. Vid "statisk"
# tilldelning av minne med hjÀlp av SO_RCVBUF Àr denna parameter utan betydelse.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Maximalt antal öppna sockets som vÀntar pÄ anslutningar.
net.ipv4.tcp_timestamps=1
# TillÄter anvÀndning av tidsstÀmplar (timestamps), enligt RFC 1323.
net.ipv4.tcp_sack=1
# TillÄta selektiva bekrÀftelser för TCP-protokollet
net.core.netdev_max_backlog=5000 (standard 1000)
# maximalt antal paket i kö för behandling, om
# grÀnssnittet fÄr paket snabbare Àn kÀrnan kan bearbeta dem.
net.ipv4.tcp_max_tw_buckets=262144
# Maximalt antal sockets som Àr i TIME-WAIT-tillstÄnd samtidigt.
# Om detta tröskel överskrids, kommer "överskotts" socket att förstöras och
# ett meddelande registreras i systemloggen.
net.ipv4.tcp_tw_reuse=1
#TillÄter ÄteranvÀndning av TIME-WAIT sockets i de fall,
# om protokollet bedömer att det Àr sÀkert.
net.core.optmem_max=4194304
#Ăka det maximala totalbufferutrymmet ALLOCATABLE
#mÀtt i sidor (4096 byte)
net.ipv4.tcp_low_latency=1
#TillÄter TCP/IP-stacken att prioritera lÄg latens
# framför högre bandbredd.
net.ipv4.tcp_adv_win_scale=1
# Denna variabel pÄverkar berÀkningen av mÀngden minne i socketens buffer,
# tilldelad för TCP-fönsterstorleken och för applikationens buffer.
# Om tcp_adv_win_scale Àr negativ, anvÀnds följande uttryck för berÀkningen:
# Bytes - bytes2 till exponent -tcp_adv_win_scale
# DÀr bytes Àr storleken pÄ fönstret i byte. Om tcp_adv_win_scale Àr positiv,
# anvÀnds följande uttryck för att bestÀmma storleken:
# Bytes - bytes2 till exponent tcp_adv_win_scale
# Variabeln tar ett heltal. StandardvÀrdet Àr 2,
# dvs. ÂŒ av volymen bestĂ€md av variabeln
# tcp_rmem tilldelas för applikationsbuffern.
net.ipv4.tcp_slow_start_after_idle=0
# mekanismen för att Äterstarta den lÄngsamma starten, som ÄterstÀller vÀrdet pÄ fönstret
# för trÀngsel, om anslutningen inte har anvÀnts under en viss tid.
# Det Àr bÀttre att stÀnga av SSR pÄ servern för att förbÀttra prestandan hos
# lÄnglivade anslutningar.
net.ipv4.tcp_no_metrics_save=1
#Spara inte resultat av TCP-mÀtningar i cachen nÀr den stÀngs.
net.ipv4.tcp_syncookies=0
#StÀng av mekanismen för att skicka syncookies
net.ipv4.tcp_ecn=0
#Explicit Congestion Notification i TCP-anslutningar. AnvÀnds för att meddela
# om det uppstÄr en "trÀngsel" pÄ vÀgen till en given vÀrd eller nÀtverk.
# Kan anvÀndas för att informera avsÀndarens vÀrd om att sÀnka hastigheten pÄ
# paketöverföringen via en specifik router eller brandvÀgg.
net.ipv4.conf.all.send_redirects=0
# stÀnger av utfÀrdande av ICMP-omdirigering .. till andra vÀrdar. Denna option mÄste
# nödvÀndigtvis vara aktiverad om vÀrden fungerar som nÄgot slags router.
# Vi har ingen routing.
net.ipv4.ip_forward=0
#Som sagt avstÀngning av vidarebefordran. Vi Àr ingen gateway, docker pÄ maskinerna Àr inte
# aktiverad, vi behöver inte det.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Svarar inte pÄ ICMP ECHO-förfrÄgningar som skickas via sÀndningspaket
net.ipv4.tcp_fin_timeout=10
#definierar tiden för att behÄlla socketen i FIN-WAIT-2-tillstÄnd efter att den
# har stÀngts av den lokala sidan. Standard 60
net.core.netdev_budget=600 # (standard 300)
# Om körningen av mjukvara avbrott inte görs tillrÀckligt lÀnge,
# sÄ kan takten av inkommande data överstiga kÀrnans förmÄga
# att tömma buffern. Som resultat kan NIC-buffrar översvÀmmas och trafik gÄ förlorad.
# Ibland Àr det nödvÀndigt att öka lÀngden pÄ SoftIRQs
# (programvaruavbrott) med CPU. Det stÄr netdev_budget för.
# StandardvÀrdet Àr 300. Parametern tvingar SoftIRQ-processen att bearbeta
# 300 paket frÄn NIC innan den slÀpper CPU
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# om bÄde klienten och servern har stöd för TFO, vilket meddelas genom
# ett speciellt flagga i TCP-paketet. I vÄrt fall Àr det bara placebo, det ser bra ut)Medluster network var tilldelat pÄ separata 10Gbps nÀtverksgrÀnssnitt i ett separat platt nÀtverk. Varje maskin hade installerade nÀtverkskort med tvÄ portar mellanox 10/25 Gbps, anslutna till tvÄ separata 10Gbps switchar. Aggeringen utfördes med hjÀlp av OSPF, eftersom bondingen med LACP av nÄgon anledning visade en sammanlagd kapacitet pÄ högst 16 Gbps, medan OSPF framgÄngsrikt utnyttjade fullt ut bÄda tio pÄ varje maskin. Framtida planer var att anvÀnda ROCE pÄ dessa mellanoxar för att minska latensen. SÄ hÀr konfigurerade vi denna del av nÀtverket:
- Eftersom maskinerna sjĂ€lva har externa IP-adresser pĂ„ BGP, sĂ„ behövde vi mjukvara â ( och vid tidpunkten för skrivandet av artikeln var detta ) redan installerad.
- Totalt fanns det tvĂ„ nĂ€tverkskort pĂ„ maskinerna med tvĂ„ grĂ€nssnitt â totalt 4 portar. Ett nĂ€tverkskort med tvĂ„ portar pekade mot fabriken och hade BGP konfigurerat, det andra â med tvĂ„ portar pekade mot tvĂ„ olika switchar och var kopplat till OSPF
Mer om OSPF-konfiguration: Huvuduppgiften Àr att aggregera tvÄ lÀnkar och ha fel-tolerans.
TvĂ„ nĂ€tverksgrĂ€nssnitt var instĂ€llda i tvĂ„ enkla platta nĂ€tverk â 10.10.10.0/24 och 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 ens1f1genom vilka maskinerna ser varandra.
DISK
NĂ€sta steg beslutade jag att optimera diskarnas prestanda. För SSD Ă€ndrade jag schemalĂ€ggaren till noop, för HDD â deadline. Grovt sett fungerar NOOP enligt principen 'först till kvarn', vilket pĂ„ engelska kallas 'FIFO (First In, First Out)'. FörfrĂ„gningar stĂ€lls i kö i takt med att de kommer in. DEADLINE Ă€r mer inriktad pĂ„ lĂ€sning, plus att processen frĂ„n kön fĂ„r praktiskt taget monopolĂ„tkomst till disken vid operationen. Detta passar utmĂ€rkt för vĂ„rt system â eftersom endast en process arbetar med varje disk â OSD daemon.
(De som vill fördjupa sig i I/O-schemalÀggaren kan lÀsa om den hÀr:
För dem som föredrar att lÀsa pÄ ryska: )
I rekommendationerna för att optimera Linux föreslÄs ocksÄ att man ökar nr_request
nr_requests
VÀrdet av nr_requests avgör mÀngden I/O-förfrÄgningar som buffras innan I/O-schemalÀggaren skickar/mottar data till blockenheten. Om du anvÀnder ett RAID-kort/blockenhet som kan hantera en större kö Àn vad I/O-schemalÀggaren Àr instÀlld pÄ, kan en ökning av vÀrdet av nr_requests hjÀlpa till att förbÀttra genomströmningen och minska serverbelastningen vid stora mÀngder I/O pÄ servern. Om du anvÀnder Deadline eller CFQ som schemalÀggare, rekommenderas det att du sÀtter nr_requests till 2 gÄnger vÀrdet av ködjupet.
MEN! SjÀlva medborgarna, utvecklarna av CEPH, övertygar oss om att deras prioritetsystem fungerar bÀttre
WBThrottle och/eller nr_requests
WBThrottle och/eller nr_requests
Filhanteringen anvÀnder buffrade I/O-operationer för skrivning; detta ger en rad fördelar om loggen för filhanteringen ligger pÄ en snabbare enhet. KlientförfrÄgningar fÄr notifieringar sÄ snart data har skrivits till loggen, och skrivs sedan ut till sjÀlva datadisken vid ett senare tillfÀlle med hjÀlp av standardfunktionaliteten i Linux. Detta gör det möjligt för OSD-spindeldiskar att ge skrivlatens svar som liknar SSD vid skrivningar i smÄ paket. Denna fördröjda skrivning möjliggör ocksÄ för kÀrnan att omstrukturera I/O-operationsförfrÄgningar till disken med förhoppningen att antingen slÄ ihop dem, eller lÄta de befintliga huvuden vÀlja en mer optimal vÀg över sina plattor. Den slutliga effekten Àr att du kan pressa ut lite fler I/O-operationer frÄn varje disk Àn vad som skulle vara möjligt med direkta eller synkrona I/O-operationer.
Det uppstÄr dock ett visst problem om volymen av inkommande skrivningar till denna Ceph-kluster överstiger alla möjligheter hos de underliggande diskarna. I ett sÄdant scenario kan det totala antalet I/O-operationer som vÀntar pÄ att skrivas till disken kontrolleras okontrollerat vÀxa och resultera i en kö av I/O-operationer som fyller hela disken och Ceph-köer. LÀsförfrÄgningar pÄverkas sÀrskilt negativt, eftersom de fastnar mellan skrivförfrÄgningar som kan ta flera sekunder att skriva till huvuddisken.
För att hantera detta problem har Ceph en inbyggd mekanism för drosselkontroll av fördröjd skrivning (writeback) kallad WBThrottle. Den Àr utformad för att begrÀnsa det totala antalet fördröjda skrivningsoperationer som kan stÀllas i kö och pÄbörja sin process för att skriva tillbaka tidigare Àn vad som skulle ha skett naturligt av kÀrnan sjÀlv. TyvÀrr visar tester att standardinstÀllningarna fortfarande kanske inte reducerar det nuvarande beteendet till en nivÄ som kan minska pÄverkan pÄ latensen av lÀsoperationer. Justeringar kan förÀndra detta beteende och minska de totala kölÀngderna för skrivningar, vilket gör att pÄverkan kan bli mindre. Det finns dock en viss kompromiss: genom att minska det totala maximala antalet tillÄtna skrivningar i kö kan du minska kÀrnans möjlighet att maximera sin effektivitet i hanteringen av inkommande förfrÄgningar. Det kan vara vÀrt att tÀnka pÄ vad som Àr viktigast för ditt specifika anvÀndningsfall, arbetsbelastningar och justera för att motsvara dem.
För att hantera djupet av sÄdana köer för fördröjd skrivning kan du antingen minska det totala maximala antalet uteslutna in- och utdataoperationer genom att anvÀnda WBThrottle-instÀllningarna, eller minska det maximala vÀrdet för uteslutna operationer pÄ blocknivÄ i din kÀrna. BÄda metoderna kan effektivt hantera samma beteende och det Àr dina preferenser som kommer att ligga till grund för implementeringen av denna instÀllning.
Det Àr ocksÄ vÀrt att notera att det befintliga prioriteringssystemet i Ceph Àr mer effektivt för kortare förfrÄgningar pÄ disk nivÄ. NÀr den totala kön till den aktuella disken minskar, flyttas det primÀra lÀget i kön till Ceph, dÀr det har mer kontroll över vilken prioritet in- och utdataoperationen har. LÄt oss övervÀga följande exempel:
echo 8 > /sys/block/sda/queue/nr_requestsALLMĂNT
Och ytterligare nÄgra kÀrninstÀllningar som gör att din maskin blir mjuk och smidig, pressa ut lite mer prestanda frÄn hÄrdvaran
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
# Diskar per maskin Àr 25, sÄ vi berÀknade att det kommer att finnas mÄnga processer
kernel.threads-max=2097152
# TrÄdar, förstÄs, ocksÄ.
vm.max_map_count=524288
# Ăkade antalet minneskartsomrĂ„den för processen.
# Enligt dokumentationen om kÀrnvariabler
# AnvÀnds minneskartsomrÄden som en bieffekt av anropet
# malloc, direkt via mmap, mprotect och madvise, samt vid inlÀsning av
# delade bibliotek.
fs.aio-max-nr=50000000
# Finjustera in- och utdata parametrar
# Linux-kÀrnan tillhandahÄller en funktion för asynkron icke-blockerande in- och utdata (AIO),
# som gör att processen kan initiera flera in- och utdataoperationer
# samtidigt utan att vÀnta pÄ att nÄgon av dem ska avslutas.
# Detta hjÀlper till att öka prestandan för applikationer,
# som kan överlappa behandling och in- och utdata.
# Parametern aio-max-nr definierar det maximala antalet
# tillÄtna samtidiga förfrÄgningar.
vm.min_free_kbytes=1048576
# Minsta storlek pÄ ledigt minne som mÄste upprÀtthÄllas.
# Satte 1Gb, vilket Àr fullt tillrÀckligt för att driva operativsystemet,
# och förhindrar att OOM Killer anvĂ€nds för OSD-processer. Ăven om minnet finns
# i överflöd, men en reserv skadar aldrig.
vm.swappiness=10
# SÀg att vi anvÀnder swap om 10% av minnet Àr ledigt.
# PÄ maskiner med 128G RAM, och 10% Àr 12 GB. Mer Àn tillrÀckligt för att fungera.
# Standardparametern pÄ 60% gjorde att systemet saktade ner genom att anvÀnda swap,
# nÀr det fortfarande fanns en massa ledigt minne.
vm.vfs_cache_pressure=1000
# Ăkade frĂ„n standard 100. Tvingar kĂ€rnan att mer aktivt avlasta
# oanvÀnda sidor frÄn minnet i cache.
vm.zone_reclaim_mode=0
# Möjliggör mer eller mindre aggressiva metoder för
# minnesÄtervinning nÀr minnet i zonen hÄller pÄ att ta slut.
# Om den sÀtts till noll, sÄ sker ingen zonÄtervinning.
# För filservrar eller arbetsbelastningar
# Àr det fördelaktigt om deras data Àr cachade, sÄ lÀmna zone_reclaim_mode
# avstÀngd, eftersom cache-effekten
# antagligen blir mer viktig Àn datans plats.
vm.dirty_ratio=20
# Andel av RAM-minnet som kan tilldelas "smutsiga" sidor
# BerÀknades utifrÄn en grov uppskattning:
# Systemet har 128 gig RAM.
# UngefÀr 20 SSD-diskar, för vilka CEPH-instÀllningarna anger
# 3G RAM för caching.
# UngefÀr 40 HDD-diskar, för vilka denna parameter Àr 1G.
# 20 % av 128 Àr 25.6 GB. SÄ i hÀndelse av maximal utnyttjande
# kommer 2.4G minne att kvarstÄ för systemet. Det borde vara tillrÀckligt för att överleva och vÀnta pÄ
# ridarnas klampande - det vill sÀga ankomsten av DevOps som kan fixa allt.
vm.dirty_background_ratio=3
# Andel av systemminnet som kan fyllas med smutsiga sidor innan,
# bakgrundsprocesserna pdflush/flush/kdmflush skriver dem till disken.
fs.file-max=524288
# Och antalet öppna filer kommer förmodligen att vara mycket mer Àn standardinstÀllningen. Inblick i CEPH
InstÀllningar som vi gÀrna vill fördjupa oss i:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Tre parametrar som inkluderar
journal_block_align: true # direkt i/o
journal_dio: true # i journalen
journal_max_write_bytes: 1073714824 # LÄt oss öka den maximala storleken
# för engÄngsskrivning i journalen
journal_max_write_entries: 10000 # Och antalet samtidiga poster
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Beslutade att skapa en separat wal
# Ăven försökt att fĂ„ detta till att fungera
# NVMe
bluestore_block_db_create: true # SÄ en separat enhet för journalen
bluestore_block_db_size: '5368709120 #5G'
bluestore_block_wal_create: true
bluestore_block_wal_size: '1073741824 #1G'
bluestore_cache_size_hdd: '3221225472 # 3G'
# stor mÀngd RAM möjliggör
# lagring av tillrÀckligt stora mÀngder
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 # antalet trÄdar per demon pÄ en disk
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # antal samtidiga fyllnadsoperationer pÄ en 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 # Specifika detaljer om girighet. Det blev vÀldigt snabbt
osd_pool_default_size: 2 # brist pÄ utrymme, sÄ
# vi beslutade att minska antalet
# datarepliker
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 # parametern justerar vi vid behov
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Vissa parametrar som testades pÄ QA i version 12.2.12, saknas i version ceph 12.2.2, till exempel osd_recovery_threads. DÀrför ingick en uppgradering till 12.2.12 i planerna. Praktiken har visat att versionerna 12.2.2 och 12.2.12 Àr kompatibla inom samma kluster, vilket möjliggör en rolling update.
Testkluster
SjÀlvklart krÀvdes det att ha samma version för testning som i produktionen, men vid starten av mitt arbete med klustret fanns det endast en nyare version i arkivet. Efter att ha sett att skillnaderna i den mindre versionen inte var sÄ stora,1393 rader i konfigurationsfilerna mot 1436 den nya versionen), bestÀmde vi oss för att börja testa den nya (vi mÄste ÀndÄ uppgradera, sÄ varför köra pÄ gammal skrÀp)
Det enda vi försökte behÄlla frÄn den gamla versionen var paketet ceph-deploy, eftersom vissa verktyg (och vissa anstÀllda) var anpassade för dess syntax. Den nya versionen skiljde sig ganska mycket, men pÄ klustrets funktion pÄverkade den inte, och sÄlunda behölls versionen. 1.5.39
Eftersom kommandot ceph-disk tydligt anger att det Àr förÄldrat och att man ska anvÀnda kommandot ceph-volume - vi började skapa OSD via just detta kommando, utan att slösa tid pÄ det förÄldrade.
Planen var att skapa en spegel av tvÄ SSD-diskar, dÀr vi skulle placera OSD-loggarna, som i sin tur ligger pÄ snurrande SAS-disks. PÄ sÄ sÀtt skyddar vi oss mot dataproblem vid diskfel med loggar.
Klustret började byggas enligt dokumentationen
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # förberett konfiguration
[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 # adressen har Àndrats, naturligtvis ))
rgw_dns_name = s3-qa.mycompany.ru # och den hÀr adressen har Àndrats
rgw_host = s3-qa.mycompany.ru # och den hÀr ocksÄ
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # mer Àn tre hundra placering grupper
# pÄ disk ville vi inte gÄ pÄ
# men parametern beror naturligtvis pÄ antalet pooler,
# deras storlek och antal OSD. Att ha fÄ men friska PG
# Àr inte heller det bÀsta valet - det pÄverkar precisionen i belastning
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # just nu för SSD-diskar Àr utrymmet för deras
# logg samma enhet som för OSD
# vi har beslutat att 5% av disken (som faktiskt Àr 1.2Tb)
# borde vara tillrÀckligt och korrelerar med parametern
# bluestore_block_db_size plus variabilitet pÄ stora
# placering grupper
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-qDet första hindret jag stötte pĂ„ i arbetet med denna version av ceph-deploy med kluster version 12.2.12 var ett fel nĂ€r jag försökte skapa OSD med db pĂ„ mjukvaruraid â
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid kunde inte detektera ett PARTUUID för enhet: /dev/md1Verkligen, blkid visar inte PARTUUID, jag var tvungen att skapa partitioner manuellt:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# Det kommer att bli mÄnga partitioner,
# utan GPT kan de inte skapas
# storleken pÄ partitionen angav vi i konfigurationen ovan = bluestore_block_db_size: '5368709120 #5G'
# Jag har 20 diskar för OSD, det Àr trÄkigt att skapa partitioner för hand
# sÄ jag gjorde en loop
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneDet verkar som allt Àr klart, vi provar igen att skapa OSD och fÄr följande fel (som för övrigt inte reproducerades i produktion)
vid skapandet av OSD av typen bluestore utan angiven vÀg för WAL, men med angiven 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 otolkningsbart uuid
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) open open fick: (22) Ogiltigt argument
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db lÀgg blockenhet( /var/lib/ceph/osd/ceph-0//block.wal) returnerade: (22) Ogiltigt argument
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs misslyckades, (22) Ogiltigt argument
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs misslyckades med fel (22) Ogiltigt argument
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** FEL: fel vid skapande av tomt objektlager i /var/lib/ceph/osd/ceph-0/: (22) Ogiltigt argumentMen, eftersom det ÀndÄ fanns planer pÄ att flytta WAL till NVMe, sÄ var denna praktik inte överflödig.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2
Vi har skapat övervakare, hanterare och OSD. Nu vill vi gruppera dem pĂ„ olika sĂ€tt, eftersom vi planerar att ha diskar av olika typer â snabba pooler pĂ„ SSD och stora men lĂ„ngsamma pĂ„ SAS-disken.Vi förutsĂ€tter att servrarna har 20 diskar, den första halvan Ă€r en typ, den andra â en annan.
Det ursprungliga, standard, kortet ser ut sÄ hÀr:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID KLASSET VIKT TYP NAMN STATUS REVIKT PRI-AFF
-1 14.54799 rot standard
-3 9.09200 vÀrd 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
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
Vi skapar vÄra egna virtuella stÀll och servrar med blackjack och annat:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root #skapat ny root
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #skapat ny host
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #flyttat server till annan stÀll
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Lagt till OSD i server
# Om vi skapade fel kan vi ta bort
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Problemer vi stötte pĂ„ i produktionsklustret nĂ€r vi försökte skapa en ny vĂ€rd och flytta den till en befintlig stĂ€ll â kommandot ceph osd crush move ceph01-host root=rack01 hĂ€ngde, och monitorerna började falla en efter en. Att avbryta kommandot med CTRL+C Ă„terstĂ€llde klustret till livet.
Sökning visade ett sÄdant problem:
Lösningen visade sig vara att dumpa crushmap och ta bort sektionen rule replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Skapar en dump av kartan i rÄformat
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #ĂversĂ€tter till lĂ€sbart format
root@ceph01-prod:~#vim crushmap.txt #Redigerar, tar bort rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #Kompilerar tillbaka
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #Laddar upp till klustretVarning: denna operation kan orsaka ombalansering av placements grupper mellan OSD. Det orsakade detta för oss, men vÀldigt lite.
En underlighets som vi stötte pÄ i testklustret var att efter omstart av OSD-servern glömde de att de flyttats till nya servrar och rack, och ÄtervÀnde till root default.
Som ett resultat, genom att skapa det slutliga schemat dÀr vi skapade en separerad root för SSD-diskar och en separat för spindeldiskar, fördelade vi alla OSD över racken och tog helt enkelt bort default root. Efter omstart stannade OSD pÄ sina platser.
Efter att vi grÀvt mer i dokumentationen hittade vi en parameter som ansvarar för detta beteende. Den behandlas i del tvÄ.
Hur vi skapade olika grupper efter typ av diskar.
Till att börja med skapade vi tvĂ„ root â för SSD och för HDD.
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootEftersom servrarna fysiskt stĂ„r i olika rack â för enkelhetens skull skapade vi rack och placerade servrarna i dem.
# ĐĄŃĐŸĐčĐșĐž:
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 hostoch fördelade diskarna efter deras typer över olika servrar.
root@ceph01-q:~# Diskar frÄn 0 till 3 Àr SSD, de finns i ceph01-q, vi placerar dem i servern
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:~# samma sak med andra servrarGenom att fördela diskarna över root ssd-root och hdd-root lÀmnade vi root-default tomt, sÄ vi kan ta bort den.
root-ceph01-q:~#ceph osd crush remove defaultDĂ€refter mĂ„ste vi skapa distributionsregler som vi kopplar till de skapade poolerna â i reglerna specificerar vi vilka root vi kan placera data frĂ„n vĂ„r pool och nivĂ„n pĂ„ unikhet för repliker â till exempel mĂ„ste repliker vara pĂ„ olika servrar, eller i olika rack (Ă€ven i olika root, om vi har sĂ„dan fördelning).
Innan du vÀljer typ, Àr det bÀttre att lÀsa dokumentationen:
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:~# Vi har angivit tvÄ regler dÀr data replikeras
root-ceph01-q:~# mellan vÀrdarna - det vill sÀga att en replik ska ligga pÄ en annan vÀrd,
root-ceph01-q:~# Àven om de Àr i samma rack.
root-ceph01-q:~# I produktion, om möjligt, Àr det bÀttre att fördela vÀrdarna
root-ceph01-q:~# över racken och ange att replikor ska fördelas över racken:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnOch vi skapar pooler dĂ€r vi i framtiden vill lagra bilder av vĂ„ra virtuella maskiner â 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 1024Och vi sÀger till dessa pooler vilka placeringsregler de ska anvÀnda
root-ceph01-q:~#ceph osd crush rule ls # ser listan över regler
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id #vÀljer ID:n vi behöver
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Valet av antal placeringsgrupper bör göras med en förhandsvision av din klynga - hur mÄnga OSD:er som kommer att finnas dÀr, vilken procentandel av de totala data som kommer att finnas i poolen, och hur mycket data totalt.
Det Àr önskvÀrt att ha högst 300 placeringsgrupper per disk, och det blir enklare att balansera med smÄ placeringsgrupper - om hela din pool tar 10 Tb och innehÄller 10 PG - sÄ blir det problematiskt att balansera genom att flytta terabytestegel (pg) - det Àr enklare och jÀmnare att flytta sand med smÄ korn i hinkar.
Men man mĂ„ste komma ihĂ„g att ju fler PGs â desto fler resurser slösas pĂ„ att berĂ€kna deras placering â minne och CPU börjar anvĂ€ndas.
En ungefÀrlig förstÄelse kan , tillhandahÄllen av utvecklarna av CEPH-dokumentationen.
Materiallista:
KĂ€lla: habr.com
