Valg af CEPH. Del 1
Vi havde fem stativer, ti optiske switcher, opsat BGP, et par dusin SSD'er og en masse SAS-diske i alle farver og størrelser, derudover proxmox og ønsket om at placere al statikken i et eget S3-lager. Ikke at dette alt sammen var nødvendigt for virtualisering, men når man begynder at bruge opensource – så fortsæt med sin interesse til ende. Det eneste, der bekymrede mig, var BGP. I verden findes der ikke noget mere hjælpeløst, uansvarligt og umoralsk end intern routing via BGP. Og jeg vidste, at vi ret hurtigt ville dykke ned i det.
Opgaven var banal – der var en CEPH, som ikke fungerede særlig godt. Det skulle laves "godt".
Den kluster, der blev overdraget til mig, var heterogen, opsat i hastværk og næsten ikke optimeret. Den bestod af to grupper forskellige noder, med et fælles netværk, der fungerede både som cluster og public network. Noderne var proppet med fire typer diske – to typer SSD, sammensat i to separate placement rules, og to typer HDD af forskellige størrelser, samlet i en tredje gruppe. Problemet med forskellige størrelser blev løst med forskellige vægte på OSD.
Selve opsætningen blev delt op i to dele – optimering af operativsystemet og optimering af selve CEPH og dets indstillinger.
Optimering af OS
Netværk
Høj latency påvirkede både ved skrivning og ved balancering. Ved skrivning – fordi klienten ikke får bekræftelse på en vellykket skrivning, før data-replikaterne i andre placement grupper bekræfter succesen. Da replikationsreglerne i CRUSH-kortet havde en replikat pr. vært, blev netværket altid brugt.
Derfor besluttede jeg først at justere det nuværende netværk, samtidig med at jeg forsøgte at overtale til at skifte til separate netværk.
Til at begynde med justerede jeg indstillingerne for netværkskort. Jeg startede med at justere køerne:
hvad der var:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Channel parameters for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1
root@ceph01:~# ethtool -g ens1f1
Ring parameters for ens1f1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Channel parameters for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1Det er tydeligt, at de nuværende parametre er langt fra maksimum. Jeg har øget:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Med udgangspunkt i en fremragende artikel
øget længden af sendekøen txqueuelen fra 1000 til 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Og ifølge dokumentationen fra ceph
øget MTU til 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000Tilføjet til /etc/network/interfaces, så alt det ovenfor nævnte indlæses ved opstart
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 9000Herefter, ifølge den samme artikel, begyndte jeg omhyggeligt at justere indstillingerne for kerne 4.15. Da noderne har 128G RAM, resulterede det i en slags konfigurationsfil til sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
# Den maksimale størrelsen på bufferen for data som mottas for alle forbindelser 54M
net.core.wmem_max = 56623104
# Den maksimale størrelsen på bufferen for data som sendes for alle forbindelser 54M
net.core.rmem_default = 56623104
# Standardstørrelsen på bufferen for data som mottas for alle forbindelser. 54M
net.core.wmem_default = 56623104
# Standardstørrelsen på bufferen for data som sendes for alle forbindelser 54M
# for hver socket
net.ipv4.tcp_rmem = 4096 87380 56623104
# Vektoren (minimum, standard, maksimum) i tcp_rmem
# inneholder 3 heltall som definerer størrelsen på mottaksbufferet for TCP-sockets.
# Minimum: hver TCP-socket har rett til å bruke dette minnet ved
# opprettelsen. Muligheten til å bruke en slik buffer
# garanteres selv ved moderate minnespenninger.
# Standard minimumsbufferstørrelse er 8 KB (8192).
# Standardverdi: mengden minne som er tillatt for bufferet
# for TCP-sockets. Denne verdien brukes i stedet for
# parameteren /proc/sys/net/core/rmem_default, som brukes av andre protokoller.
# Den brukte standardbufferstørrelsen er vanligvis (standard)
# 87830 byte. Dette definerer vindusstørrelsen 65535 med
# den antatte standardverdien tcp_adv_win_scale og tcp_app_win = 0,
# noe som er noe mindre enn den standardverdi som tcp_app_win angir.
# Maksimum: den maksimale størrelsen på bufferen som kan tildeles
# automatisk for mottak til TCP-socketen. Denne verdien opphever ikke maksimum,
# angitt i filen /proc/sys/net/core/rmem_max. Når minne tildeles
den statisk med SO_RCVBUF, absorberer ikke denne parameteren.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Det maksimale antallet åpne sockets som venter på forbindelser.
net.ipv4.tcp_timestamps=1
# Tillater bruk av tidsstempel (timestamps) i henhold til RFC 1323.
net.ipv4.tcp_sack=1
# Tillat valgfrie bekreftelser fra TCP-protokollen
net.core.netdev_max_backlog=5000 (standard 1000)
# Det maksimale antallet pakker i kø for behandling dersom
# grensesnittet mottar pakker raskere enn kjernen kan håndtere dem.
net.ipv4.tcp_max_tw_buckets=262144
# Det maksimale antallet sockets som kan være i TIME-WAIT tilstand samtidig.
# Hvis dette terskelen overskrides, blir "overflødig" socket ødelagt og
# en melding skrives til systemloggen.
net.ipv4.tcp_tw_reuse=1
#Tillat gjennbruk av TIME-WAIT sockets når
#protokollen anser det som trygt.
net.core.optmem_max=4194304
#Øk det maksimale totale bufferområdet for ALLOCATABLE
#målt i enheter av sider (4096 byte)
net.ipv4.tcp_low_latency=1
#Tillater TCP/IP-stakken å prioritere lav ventetid
#over høyere båndbredde.
net.ipv4.tcp_adv_win_scale=1
# Denne variabelen påvirker beregningen av minnevolumet i buffered socket,
# tildelt for TCP-vindusstørrelsen og bufferet til applikasjonen.
# Hvis verdien tcp_adv_win_scale er negativ, brukes følgende uttrykk:
# Bytes - bytes2^(-tcp_adv_win_scale)
# Der bytes er vindusstørrelsen i byte. Hvis verdien tcp_adv_win_scale er positiv,
# brukes følgende uttrykk for å bestemme størrelsen:
# Bytes - bytes2^(tcp_adv_win_scale)
# Variabelen aksepterer et helt tall. Standardverdi - 2,
# dvs. at ¼ av volumet bestemt av variabelen
# tcp_rmem er avsatt for applikasjonsbuffere.
net.ipv4.tcp_slow_start_after_idle=0
# mekanismen for å starte sakte på nytt, som tilbakestiller vindusverdien
# for overbelastning dersom forbindelsen ikke har vært i bruk i en bestemt tidsperiode.
# Det er best å deaktivere SSR på serveren for å forbedre ytelsen
# til langvarige forbindelser.
net.ipv4.tcp_no_metrics_save=1
#Ikke lagre TCP-forbindelsesmålinger i hurtigminnet ved stenging.
net.ipv4.tcp_syncookies=0
#Deaktiver mekanismen for sending av syncookie
net.ipv4.tcp_ecn=0
#Explicit Congestion Notification (Explicit Notification of Congestion) i
# TCP-forbindelser. Brukes for å varsle om det oppstår «trengsel»
# på ruten til den angitte verten eller nettverket. Kan brukes for å varsle
# avsender-hosten om at det er nødvendig å redusere hastigheten på pakketransporten gjennom
# en bestemt ruter eller brannmur.
net.ipv4.conf.all.send_redirects=0
# slår av ICMP Redirect til andre verter. Dette alternativet må være
# aktivert dersom verten fungerer som ruter av noe slag.
# Vi har ingen ruting.
net.ipv4.ip_forward=0
# Avstemming av forwarding. Vi er ikke en gateway, Docker er ikke høyrereist på maskinene,
# vi trenger det ikke.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Vi svarer ikke på ICMP ECHO forespørslene sendt i bredbåndspakker
net.ipv4.tcp_fin_timeout=10
#definerer tiden en socket beholdes i FIN-WAIT-2 tilstand etter å ha
#blitt lukket fra den lokale siden. Standard 60
net.core.netdev_budget=600 # (standard 300)
# Hvis programvareinterrupter ikke kjøres lenge nok,
# kan tempoet av innkommende data overstige kjernens evne
# til å tømme bufferen. Som et resultat kan NIC-bufferne bli overfylte, og trafikk vil gå tapt.
# Noen ganger er det nødvendig å øke varigheten av SoftIRQs
# (programvareinterrupter) med CPU. Dette administreres av netdev_budget.
# Standardverdi 300. Parameteren tvinger prosessen SoftIRQ til å håndtere
# 300 pakker fra NIC før den frigjør CPUen.
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# hvis både klienten og serveren støtter TFO, som rapporteres med
# en spesialflagg i TCP-pakken. I vårt tilfelle er det placebo, det ser bare
# bra ut.)Medluster netværk blev tildelt på separate 10Gbps netværksinterfaces i et separat fladt net. Der var installeret netværkskort med to porte på hver maskine. mellanox 10/25 Gbps, indsat i to separate 10Gbps switches. Aggregationen blev udført ved hjælp af OSPF, da bonding med LACP af en eller anden grund viste en samlet båndbredde på maksimalt 16 Gbps, mens OSPF lykkedes med at udnytte begge ti fuldt ud på hver maskine. Fremover var der planer om at benytte ROCE på disse mellanoxer for at mindske latens. Sådan blev denne del af netværket konfigureret:
- Da maskinerne har eksterne IP-adresser på BGP, har vi brug for software — (eller rettere sagt, på tidspunktet for artiklens skrivning var det ) allerede installeret.
- I alt var der to netværkskort på maskinerne med to interfaces hver — i alt 4 porte. Et netværkskort med to porte så mod fabrikken, og BGP var konfigureret på det, mens det andet netværkskort med to porte så mod to forskellige switches, og OSPF var konfigureret til det.
Mere om konfigurationen af OSPF: Hovedopgaven er at aggregere to links og have fejl tolerance.
to netværksinterfaces er konfigureret i to simple flade netværk — 10.10.10.0/24 og 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 ens1f1hvor maskinerne kan se hinanden.
DISK
Næste skridt var at optimere diskens præstation. Til SSD'er ændrede jeg planlæggeren til noop, til HDD'er — deadline. Groft sagt fungerer NOOP på princippet "den først ankomne får først serveret", hvilket på engelsk kaldes "FIFO (First In, First Out)". Anmodninger bliver tilføjet til køen efter deres ankomst. DEADLINE er mere fokuseret på læsning, plus processen fra køen får næsten monopoladgang til disken på tidspunktet for operationen. Dette passer perfekt til vores system — kun én proces arbejder med hver disk — OSD daemon.
(De, der ønsker at dykke ned i input/output-planlæggeren, kan læse om den her:
Foretrækker at læse på russisk: )
I anbefalingerne til tuning af linux anbefales det også at øge nr_request
nr_requests
Værdien af nr_requests bestemmer antallet af I/O-anmodninger, der bliver buffret, før I/O-planlæggeren sender/modtager data til blokenheden. Hvis du bruger et RAID-kort eller en blokenhed, der kan håndtere en større kø end hvad I/O-planlæggeren er indstillet til, kan en forhøjelse af værdien af nr_requests hjælpe med at forbedre ydelsen og reducere serverbelastningen, når store mængder I/O opstår på serveren. Hvis du bruger Deadline eller CFQ som planlægger, anbefales det at sætte nr_requests til 2 gange værdien af køens dybde.
MEN! Selve borgerne, udviklerne af CEPH, overbeviser os om, at deres prioritetsystem fungerer bedre.
WBThrottle og/eller nr_requests
WBThrottle og/eller nr_requests
Filopbevaringen bruger buffrede I/O-operationer til skrivning; dette medfører en række fordele, hvis loggen for filopbevaringen er på et hurtigere lagermedium. Klientanmodninger får besked, så snart data er skrevet til loggen, og derefter bliver de flere gange sendt til selve datadrevet på et senere tidspunkt ved hjælp af standardfunktionaliteten i Linux. Dette gør det muligt for OSD-spindle-diskene at tilbyde en skrive-latens svarende til SSD ved at skrive små pakker. En sådan forsinket, udskudt skrivning tillader også kernen at omarrangere anmodningerne til I/O-operationer til disken i håbet om enten at samle dem eller lade de eksisterende diskhoveder vælge en mere optimal rute over deres plader. Den endelige effekt er, at du kan presse lidt flere I/O-operationer ud af hver disk, end det ville have været muligt med direkte eller synkrone I/O-operationer.
Dog opstår der et bestemt problem, hvis mængden af indgående opslag i den pågældende Ceph-klynge overgår alle mulighederne i de underliggende diske. I et sådant scenarie kan det samlede antal I/O-operationer, der venter på at blive skrevet til disken, vokse ukontrolleret og resultere i køer af I/O-operationer, der fylder hele disken og Ceph-køerne. Læseanmodninger påvirkes især negativt, da de sidder fast mellem skriveanmodninger, som kan tage flere sekunder at sende til hoveddisken.
For overcoming this issue, Ceph has a built-in writeback delay write throttling mechanism called WBThrottle. It is designed to limit the total volume of delayed write I/O operations that can be queued and start their flushing process earlier than would naturally occur by the core itself. Unfortunately, testing shows that the default values may still not curb existing behavior to a level that can reduce such impacts on read latency. Adjustment can change this behavior and lower overall write queue lengths, making it possible to not severely impact latency. However, there is a trade-off: by reducing the total maximum number of allowed queued writes, you may diminish the core's ability to maximize its efficiency in order processing incoming requests. It's worth considering what is more necessary for your specific use case and workloads, and adjust accordingly.
To manage the depth of the delayed write queue, you can either decrease the total maximum number of outstanding I/O operations by applying WBThrottle settings or reduce the maximum value for outstanding operations at the block level of your core. Both can effectively manage the same behavior, and your preferences will guide the implementation of this setting.
It should also be noted that the current priority system in Ceph is more effective for shorter I/O requests at the disk level. Reducing the overall queue to this disk shifts the main location in the queue to Ceph, where it has greater control over the priority of the I/O operation. Consider the following example:
echo 8 > /sys/block/sda/queue/nr_requestsCOMMON
And a few more kernel settings that can make your machine smooth and silky, squeezing a bit more performance from the hardware.
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
# Der er 25 diske i hver maskine, så vi har regnet med, at der vil være mange processer
kernel.threads-max=2097152
# Tråde, selvfølgelig, også.
vm.max_map_count=524288
# Vi har øget antallet af hukommelseskortområder for processen.
# Som det fremgår af dokumentationen for kernelvariabler
# Hukommelseskortområder bruges som en bivirkning af opkald til
# malloc, direkte med mmap, mprotect og madvise samt ved indlæsning
# af delte biblioteker.
fs.aio-max-nr=50000000
# Vi optimerer input-output-parametre
# Linux-kernen giver en funktion til asynkron ikke-blokerende input-output (AIO),
# som gør det muligt for processen at initiere flere input-output-operationer
# samtidigt uden at vente på, at nogen af dem afsluttes.
# Dette hjælper med at forbedre applikationens ydeevne,
# da den kan overlappe behandling og input-output.
# Parameteren aio-max-nr angiver det maksimale antal tilladte
# samtidige anmodninger.
vm.min_free_kbytes=1048576
# Minimumsstørrelsen af ledig hukommelse, der skal opretholdes.
# Sat til 1Gb, hvilket er helt tilstrækkeligt til at køre operativsystemet,
# og hjælper med at undgå OOM Killer for OSD-processer. Selvom der er rigeligt
# med hukommelse, er det stadig rart at have en buffer.
vm.swappiness=10
# Angiver at swap skal bruges, hvis der er tilbage 10% ledig hukommelse.
# På maskiner med 128G RAM, og 10% er 12 Gigabyte. Mere end tilstrækkeligt til drift.
# Den standardparameter på 60% fik systemet til at bremse, da det sneg sig ind i swap,
# når der stadig var mange ledige ressourcer.
vm.vfs_cache_pressure=1000
# Vi øger den fra standard 100. Tvinger kernen til mere aktivt at frigøre
# ubrugte hukommelsessider fra cachen.
vm.zone_reclaim_mode=0
# TIllader at indstille mere eller mindre aggressive tilgange til
# genopretning af hukommelse, når der er mangel på hukommelse i zonen.
# Hvis den er sat til nul, sker der ikke zoneregenerering.
# For filservere eller arbejdsbelastninger
# er det fordelagtigt, hvis deres data er cachelagret, så zone_reclaim_mode
# kan holdes deaktiveret, da caching-effekten
# sandsynligvis vil være vigtigere end datalokationen.
vm.dirty_ratio=20
# Procentdelen af RAM, der kan tildeles som "beskidte" sider.
# Beregnet ud fra et omtrentligt regnestykke:
# Systemet har 128 gigabytes hukommelse.
# Cirka 20 SSD-diske, som i CEPH-opsætningen angiver
# at tildele 3G RAM til caching.
# Omtrent 40 HDD-diske, for hvilke denne parameter er 1G
# 20% af 128 er 25.6 gigabytes. I tilfælde af maksimal udnyttelse af hukommelsen,
# vil der være 2.4G hukommelse tilbage til systemet. Det burde være nok til at overleve
# indtil hjælpen ankommer - altså DevOps, som kan fikse alt.
vm.dirty_background_ratio=3
# Procentdelen af systemhukommelse, der kan fyldes med dirty pages, før
# baggrundsprocesserne pdflush/flush/kdmflush skriver dem til disk.
fs.file-max=524288
# Og vi vil sandsynligvis have mange flere åbne filer end angivet som standard. Dykning i CEPH
Indstillinger, som vi gerne vil dykke mere ned i:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Tre parametre, der inkluderer
journal_block_align: true # direkte i/o
journal_dio: true # til journalen
journal_max_write_bytes: 1073714824 # Lad os strække den maksimale størrelse
# af skriveoperationen i journalen
journal_max_write_entries: 10000 # Og antallet af samtidige optegnelser
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Vi besluttede at lave en separat wal
# Vi forsøgte endda at få et sted til dette
# NVMe
bluestore_block_db_create: true # Og et separat apparat til journalen
bluestore_block_db_size: '5368709120 #5G'
bluestore_block_wal_create: true
bluestore_block_wal_size: '1073741824 #1G'
bluestore_cache_size_hdd: '3221225472 # 3G'
# stort mængde RAM tillader
# lagring af ganske store 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 # antal tråde for dæmonen pr. disk
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # antal samtidige fyldningsoperationer på én 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 # Funktioner vedrørende grådighed. Meget hurtigt blev
osd_pool_default_size: 2 # der mangel på plads, da midlertidigt
# løsningen var at reducere antallet af
# datakopier
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 # parameter justeres efter behov i realtid
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Nogle af de parametre, der blev testet i QA i version 12.2.12, mangler i version ceph 12.2.2, for eksempel osd_recovery_threads. Derfor var der planlagt en opdatering i produktionen til 12.2.12. Praksis har vist kompatibilitet i samme klynge mellem versionerne 12.2.2 og 12.2.12, hvilket muliggør en rolling update.
Testklynge
Naturligvis var det nødvendigt at have den samme version til test, som den der kørte i produktion, men på tidspunktet for min start med klusteret var der kun en nyere version tilgængelig i repository'et. Da vi så, at ændringerne i den mindre version ikke var så betydelige,1393 linjer i konfigurationsfilerne mod 1436 (i den nye version), besluttede vi at begynde at teste den nye (vi skulle alligevel opdatere, hvorfor køre med gammelt skrammel)
Det eneste, vi forsøgte at bevare fra den gamle version, var pakken ceph-deploy, da nogle værktøjer (og nogle medarbejdere) var tilpasset dens syntaks. Den nye version adskilte sig væsentligt, men påvirkede ikke klusterets funktionalitet, så den blev stadig brugt. 1.5.39
Da teamet ceph-disk tydeligt angiver, at det er deprecated og anbefaler at bruge ceph-volume, begyndte vi at oprette OSD'er præcist med denne kommando og spildte ikke tid på det forældede.
Planen var at oprette et spejl med to SSD-diske, hvor vi ville placere OSD-logfilerne, som igen ville være placeret på spindle SAS-diske. På den måde sikrer vi os mod datarelaterede problemer ved fejl på logdisken.
Vi begyndte at oprette klusteret baseret på dokumentationen
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # vi har forberedt konfigurationen på forhånd
[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 er ændret, selvfølgelig ))
rgw_dns_name = s3-qa.mycompany.ru # og denne adresse er også ændret
rgw_host = s3-qa.mycompany.ru # og denne også
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # flere end tre hundrede placering grupper
# på disk er ikke blevet taget tilbud om
# selvom parameteren, selvfølgelig, afhænger af antallet af puljer,
# deres størrelser og antallet af OSD. At have få men sunde PG
# er heller ikke et bedste valg - nøjagtigheden af balanceringen lider
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # for nu er pladsen til deres
# log den samme enhed som for OSD
# vi besluttede at 5% af disken (som er 1.2Tb)
# bør være mere end nok, og korrelerer med parameteren
# bluestore_block_db_size plus variabilitet for store
# placeringsgrupper
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ørste, jeg støder på i arbejdet med denne version af ceph-deploy med en kluster version 12.2.12, er en fejl, når jeg forsøger at oprette OSD med db på software RAID -
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid kunne ikke registrere en PARTUUID for enhed: /dev/md1Faktisk viser blkid ikke PARTUUID, så jeg måtte oprette partitioner manuelt:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# der vil være mange partitioner,
# uden GPT kan de ikke oprettes
# størrelsen på partitionen har vi angivet i konfigurationen ovenfor = bluestore_block_db_size: '5368709120 #5G'
# Jeg har 20 diske til OSD, det er kedeligt at oprette partitioner manuelt
# så jeg lavede en løkke
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneDet ser ud til, at alt er klar, vi prøver at oprette OSD igen og får følgende fejl (som for øvrigt ikke blev gentaget i produktion)
ved oprettelse af OSD-type bluestore uden at angive en sti til WAL, men med angivelse af 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 uformel uuid
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) åbn åbent fik: (22) Ugyldigt argument
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db tilføj blokenhed(/var/lib/ceph/osd/ceph-0//block.wal) returnerede: (22) Ugyldigt argument
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs mislykkedes, (22) Ugyldigt argument
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs mislykkedes med fejl (22) Ugyldigt argument
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** FEJL: fejl ved oprettelse af tom objektlager i /var/lib/ceph/osd/ceph-0/: (22) Ugyldigt argumentMen hvis jeg opretter en ekstra partition til WAL på samme spejl (eller et andet sted, alt efter valg) og angiver det ved oprettelsen af OSD - så fungerer alt glat (bortset fra at der er en adskilt WAL, som du muligvis ikke ønskede).
Men da det stadig var i fjernplanerne at tage WAL på NVMe, var praksis ikke spildt.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2Vi har oprettet monitorer, managere og OSD. Nu ønsker vi at gruppere dem på forskellige måder, da vi har planer om at have diske af forskellige typer - hurtige puljer på SSD og store, men langsomme på SAS-diske.
Lad os antage, at der er 20 diske pr. server, den første ti er én type, den anden - en anden.
Den oprindelige, standardkort ser sådan ud:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID KLASSE VÆGT TYPE NAVN STATUS REWEIGHT PRI-AFF
-1 14.54799 rod standard
-3 9.09200 værts ceph01-q
0 ssd 1.00000 osd.0 op 1.00000 1.00000
1 ssd 1.00000 osd.1 op 1.00000 1.00000
2 ssd 1.00000 osd.2 op 1.00000 1.00000
3 ssd 1.00000 osd.3 op 1.00000 1.00000
4 hdd 1.00000 osd.4 op 1.00000 1.00000
5 hdd 0.27299 osd.5 op 1.00000 1.00000
6 hdd 0.27299 osd.6 op 1.00000 1.00000
7 hdd 0.27299 osd.7 op 1.00000 1.00000
8 hdd 0.27299 osd.8 oppe 1.00000 1.00000
9 hdd 0.27299 osd.9 oppe 1.00000 1.00000
10 hdd 0.27299 osd.10 oppe 1.00000 1.00000
11 hdd 0.27299 osd.11 oppe 1.00000 1.00000
12 hdd 0.27299 osd.12 oppe 1.00000 1.00000
13 hdd 0.27299 osd.13 oppe 1.00000 1.00000
14 hdd 0.27299 osd.14 oppe 1.00000 1.00000
15 hdd 0.27299 osd.15 oppe 1.00000 1.00000
16 hdd 0.27299 osd.16 oppe 1.00000 1.00000
17 hdd 0.27299 osd.17 oppe 1.00000 1.00000
18 hdd 0.27299 osd.18 oppe 1.00000 1.00000
19 hdd 0.27299 osd.19 oppe 1.00000 1.00000
-5 5.45599 vært ceph02-q
20 ssd 0.27299 osd.20 oppe 1.00000 1.00000
21 ssd 0.27299 osd.21 oppe 1.00000 1.00000
22 ssd 0.27299 osd.22 oppe 1.00000 1.00000
23 ssd 0.27299 osd.23 oppe 1.00000 1.00000
24 hdd 0.27299 osd.24 oppe 1.00000 1.00000
25 hdd 0.27299 osd.25 oppe 1.00000 1.00000
26 hdd 0.27299 osd.26 oppe 1.00000 1.00000
27 hdd 0.27299 osd.27 oppe 1.00000 1.00000
28 hdd 0.27299 osd.28 oppe 1.00000 1.00000
29 hdd 0.27299 osd.29 oppe 1.00000 1.00000
30 hdd 0.27299 osd.30 oppe 1.00000 1.00000
31 hdd 0.27299 osd.31 oppe 1.00000 1.00000
32 hdd 0.27299 osd.32 oppe 1.00000 1.00000
33 hdd 0.27299 osd.33 oppe 1.00000 1.00000
34 hdd 0.27299 osd.34 oppe 1.00000 1.00000
35 hdd 0.27299 osd.35 oppe 1.00000 1.00000
36 hdd 0.27299 osd.36 oppe 1.00000 1.00000
37 hdd 0.27299 osd.37 oppe 1.00000 1.00000
38 hdd 0.27299 osd.38 oppe 1.00000 1.00000
39 hdd 0.27299 osd.39 oppe 1.00000 1.00000
-7 6.08690 vært ceph03-q
40 ssd 0.27299 osd.40 oppe 1.00000 1.00000
41 ssd 0.27299 osd.41 oppe 1.00000 1.00000
42 ssd 0.27299 osd.42 oppe 1.00000 1.00000
43 ssd 0.27299 osd.43 oppe 1.00000 1.00000
44 hdd 0.27299 osd.44 oppe 1.00000 1.00000
45 hdd 0.27299 osd.45 oppe 1.00000 1.00000
46 hdd 0.27299 osd.46 oppe 1.00000 1.00000
47 hdd 0.27299 osd.47 oppe 1.00000 1.00000
48 hdd 0.27299 osd.48 oppe 1.00000 1.00000
49 hdd 0.27299 osd.49 oppe 1.00000 1.00000
50 hdd 0.27299 osd.50 oppe 1.00000 1.00000
51 hdd 0.27299 osd.51 oppe 1.00000 1.00000
52 hdd 0.27299 osd.52 oppe 1.00000 1.00000
53 hdd 0.27299 osd.53 oppe 1.00000 1.00000
54 hdd 0.27299 osd.54 oppe 1.00000 1.00000
55 hdd 0.27299 osd.55 oppe 1.00000 1.00000
56 hdd 0.27299 osd.56 oppe 1.00000 1.00000
57 hdd 0.27299 osd.57 oppe 1.00000 1.00000
58 hdd 0.27299 osd.58 oppe 1.00000 1.00000
59 hdd 0.89999 osd.59 oppe 1.00000 1.00000
Lad os oprette vores egne virtuelle stativer og servere med blackjack og andet:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root # oprettede ny root
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host # oprettede ny vært
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 # flyttede server til andet rack
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Tilføjede OSD til server
# Hvis det blev oprettet forkert, kan du slette det
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Problemer, vi stødte på i operations klyngen, da vi forsøgte at oprette en ny vært og flytte den til et eksisterende rack — kommandoen ceph osd crush move ceph01-host root=rack01 hangte, og overvågerne begyndte at falde en ad gangen. Afbrydelse af kommandoen med CTRL+C bragte klyngen tilbage til liv.
Søgning viste et sådant problem:
Løsningen var at dumpe crushmap og fjerne sektionen rule replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row # Dumper kortet i rå form
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt # konverterer til læseligt
root@ceph01-prod:~#vim crushmap.txt # redigerer, fjerner rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row # kompilere tilbage
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row # indlæser i klyngenAdvarsel: denne operation kan forårsage en genbalancering af placement group mellem OSD. Det gav os det, men kun en meget lille ændring.
En underlighed, vi stødte på i testklyngen, var, at efter genstart af OSD-serveren glemte de, at de var flyttet til nye servere og rack, og vendte tilbage til root default.
Som resultat af at samle den endelige skema, hvor vi oprettede et separat root for SSD-diskene og et andet for spindeldiskene, fordelte vi alle OSD på rackene og fjernede blot default root. Efter genstart blev OSD'erne, hvor de skulle være.
Efter at have gravet lidt i dokumentationen fandt vi den parameter, der styrer denne adfærd. Den er omtalt i anden del.
Hvordan vi lavede forskellige grupper baseret på disktyper.
Først oprettede vi to roots — for SSD og for HDD.
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootDa serverne fysisk står i forskellige rack — for nemheds skyld oprettede vi rack med serverne 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 hostog fordelte diskene efter deres typer til forskellige servere.
root@ceph01-q:~# Diskene fra 0 til 3 er SSD, som ligger i ceph01-q, vi sætter dem i serveren
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:~# på samme måde med de andre servere.Ved at fordele diskene til roots ssd-root og hdd-root, efterlod vi root-default tomt, så vi kan slette det.
root-ceph01-q:~#ceph osd crush remove defaultDernæst skal vi oprette fordelingsregler, som vi vil knytte til de puljer, vi opretter — i reglerne angiver vi, hvilke roots vores puljer kan placeres i, og niveauet for unikke replikaer — for eksempel skal replikaer altid være på forskellige servere eller i forskellige rack (det kan endda være i forskellige roots, hvis vi har sådan en fordeling).
Før du vælger en type, er det bedst at læse 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 defineret to regler, hvor data replikeres
root-ceph01-q:~# mellem værter — det vil sige en replika skal befinde sig på en anden vært,
root-ceph01-q:~# selvom de er i samme rack.
root-ceph01-q:~# I produktionen, hvis det er muligt, er det bedst at fordele værterne
root-ceph01-q:~# på rack og angive at replikaer skal fordeles på rack:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnOg vi opretter puljer, hvor vi i fremtiden ønsker at gemme diskbillederne fra vores virtualisering - 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 1024Og vi fortæller disse puljer, hvilke placeringregler de skal følge
root-ceph01-q:~#ceph osd crush rule ls # ser listen over regler
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id #vælger den ønskede ID
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Valget af antallet af placeringsgrupper bør ske med en forudgående forståelse af dit cluster - hvor mange OSD'er der cirka vil være, hvilket procentuelt antal data (i forhold til det samlede volumen) der vil være i puljen, og hvilket total antal data der vil være.
Det er generelt ønskeligt ikke at have mere end 300 placeringsgrupper pr. disk, og det vil være lettere at balancere med små placeringsgrupper - det vil sige, hvis hele din pulje fylder 10 Tb og indeholder 10 PG - så vil det være problematisk at balancere ved at flytte terabyte-klodser (pg); det er lettere og mere jævnt at flytte sand med små korn i spande.
Men man skal huske, at jo større antal PG - jo mere ressourcer bruges der til at beregne deres placering - dette begynder at udnytte hukommelsen og CPU'en.
En omtrentlig forståelse kan , leveret af udviklerne af dokumentationen CEPH.
Materialeliste:
Kilde: habr.com
