Valg av CEPH. Del 1
Vi hadde fem stativer, ti optiske svitsjer, konfigurert BGP, et par dusin SSD-er og en haug med SAS-disker i alle farger og stĂžrrelser, pluss proxmox og Ăžnsket om Ă„ lagre all statisk data i vĂ„rt eget S3-lager. Det var ikke akkurat nĂždvendig for virtualisering, men nĂ„r man fĂžrst har begynt Ă„ bruke opensource â sĂ„ mĂ„ man gĂ„ all in. Det eneste jeg bekymret meg for var BGP. Det finnes ikke noe mer hjelpelĂžst, uansvarlig og umoralsk enn intern ruting via BGP. Og jeg visste at vi ganske snart ville dykke ned i dette.
Oppgaven var enkel â vi hadde CEPH, det fungerte ikke sĂ„ bra. Vi trengte Ă„ fĂ„ det til Ă„ fungere «godt».
Klyngen jeg fikk, var heterogen, satt opp i hastverk og praktisk talt ikke tunet. Den bestod av to grupper med forskjellige noder, med ett felles nettverk som fungerte bĂ„de som cluster og offentlig nettverk. Nodene hadde fire typer disker â to typer SSD-er, fordelt pĂ„ to separate plassering regler og to typer HDD-er av forskjellige stĂžrrelser, samlet i en tredje gruppe. Problemet med de ulike stĂžrrelsene ble lĂžst med forskjellige vektlegginger for OSD.
Selve konfigureringen ble delt inn i to deler â tuning av operativsystemet og tuning av selve CEPH og innstillingene dens.
Oppgradering av OS
Nettverk
HĂžy latens pĂ„virket bĂ„de ved skriving og ved lastbalansering. Ved skriving â fordi klienten ikke vil motta svar om vellykket skriving fĂžr datakopiene i andre plassering grupper bekrefter suksess. Siden replikas distribusjonsregler i CRUSH-kartet vĂ„rt var med Ă©n replika per vert, ble nettverket alltid brukt.
Derfor bestemte jeg meg fÞrst for Ä justere det nÄvÊrende nettverket, samtidig som jeg prÞvde Ä overbevise om Ä flytte til separate nettverk.
FĂžrst justerte jeg innstillingene for nettverkskortene. Jeg startet med innstilling av kĂžene:
hva vi hadde:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Kanalparametere for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Annet: 1
Kombinert: 63
NĂ„vĂŠrende maskinvareinnstillinger:
RX: 0
TX: 0
Annet: 1
Kombinert: 1
root@ceph01:~# ethtool -g ens1f1
Ringparametere for ens1f1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
NĂ„vĂŠrende maskinvareinnstillinger:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Kanalparametere for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Annet: 1
Kombinert: 63
NĂ„vĂŠrende maskinvareinnstillinger:
RX: 0
TX: 0
Annet: 1
Kombinert: 1Det er tydelig at nÄvÊrende parametre er langt fra maksimum. Jeg Þkte:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Veiledet av en utmerket artikkel
forlenga kĂžen for sending txqueuelen fra 1000 til 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Og ifĂžlge dokumentasjonen for Ceph
forlenga MTU til 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000La til i /etc/network/interfaces sÄ alt det overnevnte lastes ved oppstart
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 9000Etter dette begynte jeg, i henhold til den samme artikkelen, Ă„ nĂžye justere kjernens kontroller 4.15. Gitt at nodene har 128G RAM, fikk jeg en viss konfigurasjonsfil for sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
# Maksimal stÞrrelse pÄ buffer for innkommende data for alle tilkoblinger 54M
net.core.wmem_max = 56623104
# Maksimal stÞrrelse pÄ buffer for utgÄende data for alle tilkoblinger 54M
net.core.rmem_default = 56623104
# Standard stÞrrelse pÄ buffer for innkommende data for alle tilkoblinger. 54M
net.core.wmem_default = 56623104
# Standard stÞrrelse pÄ buffer for utgÄende data for alle tilkoblinger 54M
# for hver socket
net.ipv4.tcp_rmem = 4096 87380 56623104
# Vektorisert (minimum, standard, maksimum) variabel i tcp_rmem-filen
# inneholder 3 heltall som definerer stÞrrelsen pÄ innkommende buffer for TCP-sokler.
# Minimum: hver TCP-socket har rett til Ă„ bruke dette minnet fra
# opprettelsen. Muligheten til Ă„ bruke et slikt buffer
# garanteres selv ved overskridelse av den moderate minnepressgrensen.
# Minimum buffer stĂžrrelse er 8 Kbyte (8192).
# Standardverdi: mengden minne tillatt for standard TCP-socket buffer. Denne verdien brukes i stedet for
# parameteren /proc/sys/net/core/rmem_default, som brukes av andre protokoller.
# Den vanligste standardbufferstĂžrrelsen er 87830 byte. Dette definerer vindusstĂžrrelsen 65535 med
# standardverdien tcp_adv_win_scale og tcp_app_win = 0,
# litt mindre enn det standard tcp_app_win-verdien definerer.
# Maksimum: maksimal stÞrrelse pÄ buffer som kan tildeles automatisk
# til innkommende TCP-socket. Denne verdien annullerer ikke maksimum
# angitt i /proc/sys/net/core/rmem_max. Under "statiske"
# minneallokeringer med SO_RCVBUF er denne parameteren irrelevant.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Maksimalt antall Äpne sokler som venter pÄ tilkoblinger.
net.ipv4.tcp_timestamps=1
# Aktiverer bruk av tidsstempler i samsvar med RFC 1323.
net.ipv4.tcp_sack=1
# Aktiverer selektiv bekreftelse for TCP-protokollen
net.core.netdev_max_backlog=5000 (standard 1000)
# Maksimalt antall pakker i kĂž for behandling, hvis
# grensesnittet mottar pakker raskere enn kjernen kan behandle dem.
net.ipv4.tcp_max_tw_buckets=262144
# Maksimalt antall sokler som er i TIME-WAIT-tilstand samtidig.
# NĂ„r denne terskelen overskrides, Ăždelegges den "overflĂždige" sokkelen,
# og en melding skrives til systemloggen.
net.ipv4.tcp_tw_reuse=1
# Tillater gjenbruk av TIME-WAIT-sokler i tilfeller,
# hvis protokollen anser det som trygt.
net.core.optmem_max=4194304
# Ăker maksimal total bufferplass tildelt ALLOCATABLE
# mÄlt i sidestÞrrelser (4096 byte)
net.ipv4.tcp_low_latency=1
# Tillater TCP/IP-stacken Ă„ prioritere lav ventetid
# over hÞyere bÄndbredde.
net.ipv4.tcp_adv_win_scale=1
# Denne variabelen pÄvirker beregningen av volumet av minne i sokkelbufferet,
# tildelt til TCP-vindusstĂžrrelsen og applikasjonsbufferet.
# Hvis verdien tcp_adv_win_scale er negativ, brukes fĂžlgende uttrykk til beregning:
# 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 til Ă„ bestemme stĂžrrelsen:
# Bytes - bytes2^(tcp_adv_win_scale)
# Variabelen tar et heltall. Standardverdi er 2,
# det vil si at Πav volumet definert av variabelen
# tcp_rmem tildeles applikasjonsbufferen.
net.ipv4.tcp_slow_start_after_idle=0
# Mekanisme for Ă„ tilbakestille den langsomme oppstarten, som tilbakestiller vindusstĂžrrelsen ved
# overbelastning hvis tilkoblingen har vĂŠrt inaktiv i en viss periode.
# Det er best Ä deaktivere SSR pÄ serveren for Ä forbedre ytelsen for
# langvarige tilkoblinger.
net.ipv4.tcp_no_metrics_save=1
# Ikke lagre mÄleresultater for TCP-tilkoblinger i cache ved lukking.
net.ipv4.tcp_syncookies=0
# Deaktiverer mekanismen for sending av syncookie
net.ipv4.tcp_ecn=0
# Explicit Congestion Notification (Eksplisitt Varsel om Overbelastning) i
# TCP-tilkoblinger. Brukes for Ă„ varsle om forekomsten av "kĂž"
# pÄ stien til en bestemt vert eller nettverk. Kan brukes til Ä informere
# avsendervert om behovet for Ä redusere hastigheten pÄ pakkeoverfÞringen gjennom
# en bestemt ruter eller brannmur.
net.ipv4.conf.all.send_redirects=0
# Deaktiverer sending av ICMP Redirect ⊠til andre verter. Denne opsjonen mÄ aktivert
# hvis verten fungerer som en ruter av noe slag.
# Vi har ikke ruting.
net.ipv4.ip_forward=0
# Egnede deaktiverer videresending. Vi er ikke en gateway, Docker pÄ maskinene er ikke hevet,
# vi trenger ikke dette.
net.ipv4.icmp_echo_ignore_broadcasts=1
# Svarer ikke pÄ ICMP ECHO-forespÞrsler sendt med bredbÄndspakker
net.ipv4.tcp_fin_timeout=10
# Definerer tiden for Ă„ opprettholde sokkelen i FIN-WAIT-2-tilstand etter Ă„ ha blitt
# lukket av den lokale siden. Standard 60
net.core.netdev_budget=600 # (standard 300)
# Hvis utfĂžrelsen av programvareinterrupts ikke skjer lenge nok,
# kan veksten i innkommende data overstige kjernens mulighet
# til Ä tÞmme bufferet. Som et resultat vil NICs bufre fylles opp, og trafikken vil gÄ tapt.
# Noen ganger kan det vĂŠre nĂždvendig Ă„ Ăžke varigheten av SoftIRQs
# (programvareinterrupts) med CPU. Dette hÄndteres av netdev_budget.
# Standardverdi 300. Parameteren vil fÄ SoftIRQ-prosessen til Ä behandle
# 300 pakker fra NIC fĂžr den slipper CPUen.
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# hvis bÄde klient og server stÞtter TFO, som rapporteres ved hjelp av
# en spesialflagg i TCP-pakken. I vÄrt tilfelle er det placebo, bare
# ser bra ut)Cklynge nettverk ble tildelt pÄ separate 10Gbps nettverksgrensesnitt i et eget flatt nettverk. Hver maskin hadde installert to-ports nettverkskort mellanox 10/25 Gbps, som var koblet til to separate 10Gbps switcher. Aggregasjonen ble utfÞrt med OSPF, ettersom bonding med lacp av en eller annen grunn viste en samlet bÄndbredde pÄ maks 16 Gbps, mens ospf viste seg Ä utnytte fullt begge ti pÄ hver maskin. Videre planer var Ä bruke ROCE pÄ disse mellanox-ene for Ä redusere latens. Slik ble denne delen av nettverket satt opp:
- Siden selve maskinene har eksterne IP-adresser pĂ„ BGP, er vi avhengige av programvaren â (og mer spesifikt pĂ„ tidspunktet for skrivingen av artikkelen var det ) allerede installert.
- Totalt var det to nettverkskort med to grensesnitt â til sammen 4 porter. Ett nettverkskort med to porter sĂ„ mot fabrikken og BGP var konfigurert pĂ„ det, det andre â med to porter sĂ„ mot to forskjellige switche og OSPF var satt opp pĂ„ det.
Mer om OSPF-konfigurasjonen: Hovedoppgaven er Ă„ aggregere to lenker og ha feil toleranse.
to nettverksgrensesnitt er konfigurert i to enkle flate nettverk â 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 ens1f1som maskinene ser hverandre.
DISK
Neste steg var Ă„ optimalisere diskene. For SSD byttet jeg planleggeren til noop, for HDD â deadline. Grovt sagt fungerer NOOP pĂ„ prinsippet «den som stĂ„r fĂžrst, fĂ„r fĂžrst», som pĂ„ engelsk kalles «FIFO (First In, First Out)». ForespĂžrslene stĂ„r i kĂž etter hvert som de kommer inn. DEADLINE er mer tilpasset lesing, pluss at prosessen fra kĂžen fĂ„r praktisk talt monopol tilgang til disken under operasjonen. For vĂ„rt system passer dette utmerket â ettersom det kun er Ă©n prosess som jobber med hver disk â OSD daemon.
(De som Ăžnsker Ă„ dykke inn i I/O-planleggeren kan lese om den her:
De som foretrekker Ä lese pÄ russisk: )
I anbefalingene for tuning av linux anbefales det ogsÄ Ä Þke nr_request
nr_requests
Verdien av nr_requests bestemmer mengden I/O-forespÞrsler som blir bufret fÞr I/O-scheduler sender/mottar data til blokk-enheten. Hvis du bruker et RAID-kort/blokk-enhet som kan hÄndtere en stÞrre kÞ enn det I/O-scheduler er satt til, kan det Ä Þke verdien av nr_requests bidra til Ä forbedre ytelsen og redusere serverbelastningen nÄr store mengder I/O skjer pÄ serveren. Hvis du bruker Deadline eller CFQ som scheduler, anbefales det at du setter nr_request-verdien til 2 ganger verdien av kÞdybden.
MEN! Utviklerne av CEPH overbeviser oss om at deres prioriteringssystem fungerer bedre.
WBThrottle og/eller nr_requests
WBThrottle og/eller nr_requests
Fil lagring bruker bufrede I/O-operasjoner for skriving; dette gir en rekke fordeler hvis filsystemets journal ligger pÄ et raskere medium. KlientforespÞrslene fÄr varslinger sÄ snart dataene er skrevet til journalen, som deretter blir tÞmt til selve datadiskene pÄ et senere tidspunkt ved hjelp av standardfunksjonaliteten i Linux. Dette gjÞr det mulig for OSD-spindeldiskene Ä tilby skrive-latens som ligner SSD ved smÄ skrivepakker. Denne forsinkede skrivingen tillater ogsÄ kjernen Ä omorganisere I/O-forespÞrslene til disken i hÄp om Ä enten samle dem eller la de eksisterende diskhodene velge en mer optimal rute over platene. Den endelige effekten er at du kan presse litt mer I/O-ut fra hver disk enn hva som ville vÊrt mulig med direkte eller synkron I/O-operasjoner.
Imidlertid oppstÄr det et problem hvis volumet av innkommende skrivinger til dette Ceph-klusteret overstiger hva de underliggende diskene kan hÄndtere. I et slikt scenario kan det totale antallet I/O-operasjoner som venter pÄ Ä bli skrevet til disk, vokse ukontrollert og resultere i en I/O-kÞ som fyller hele disken og Ceph-kÞene. LeseforespÞrslene pÄvirkes spesielt negativt, da de sitter fast mellom skriveforespÞrslene, som kan ta flere sekunder Ä bli tÞmt til hoveddisken.
For overcoming this issue, Ceph has a built-in writeback mechanism in its file storage called WBThrottle. It is designed to limit the total volume of queued writeback input/output operations that can start their flush process earlier than it would naturally occur due to the kernel's engagement. Unfortunately, testing shows that the default settings may still not reduce the existing behavior to a level that can mitigate such an impact on read latency. Adjustments can change this behavior and reduce the overall lengths of write queues, making it possible to lessen such an impact. However, there is a trade-off: by reducing the overall maximum number of allowed queued writes, you may diminish the kernel's ability to maximize its efficiency in ordering incoming requests. It's worth considering what is more essential for your specific use case and workloads and adjusting accordingly.
To manage the depth of such a writeback queue, you can either decrease the total maximum number of pending input/output operations by applying the WBThrottle settings or reduce the maximum value for pending operations at the block level of your kernel. Both approaches can effectively manage the same behavior, and your preferences will underpin the implementation of this setting.
It should also be noted that the existing priority system in Ceph is more effective for shorter requests at the disk level. When reducing the total queue to this disk, the primary location in the queue shifts to Ceph, where it has greater control over the input/output operation's priority. Consider the following example:
echo 8 > /sys/block/sda/queue/nr_requestsCOMMON
And a few more kernel settings that allow you to make your machine smoother and extract a bit more performance from the hardware.
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
# Diskene i hver maskin er 25, sÄ vi regnet med at det ville vÊre mange prosesser
kernel.threads-max=2097152
# TrÄder, selvfÞlgelig.
vm.max_map_count=524288
# Ăkt antall minnekartomrĂ„der for prosessen.
# Som beskrevet i dokumentasjonen for kjernevare variabler
# MinnekartomrÄder brukes som en bivirkning av Ä kalle
# malloc, direkte ved hjelp av mmap, mprotect og madvise, samt ved lasting av
# delte biblioteker.
fs.aio-max-nr=50000000
# Optimalisering av input-output-parametere
# Linux-kjernen tilbyr en funksjon for asynkron ikke-blokkerende input-output (AIO),
# som gjĂžr at prosessen kan initiere flere input-output-operasjoner
# samtidig, uten Ä vente pÄ at noen av dem skal vÊre ferdige.
# Dette bidrar til Ă„ forbedre ytelsen til applikasjoner,
# som kan overlappe behandling og input-output.
# Parameteren aio-max-nr angir det maksimale antallet tillatte
# samtidige forespĂžrselene.
vm.min_free_kbytes=1048576
# Minimum stÞrrelse pÄ ledig minne som mÄ opprettholdes.
# Innstilt pÄ 1Gb, noe som er mer enn tilstrekkelig for at operativsystemet skal fungere,
# og gjÞr det mulig Ä unngÄ OOM Killer for OSD-prosesser. Selv om det er
# masser av minne tilgjengelig, er det alltid godt med en reserve.
vm.swappiness=10
# Angir at svapping skal brukes hvis 10% av minnet er ledig.
# PĂ„ maskiner med 128G RAM, betyr 10% 12 GB. Mer enn tilstrekkelig til drift.
# Standardinnstillingen pÄ 60% gjorde at systemet ble tregt, ved Ä gÄ til swap,
# nÄr det fortsatt var mye ledig minne.
vm.vfs_cache_pressure=1000
# Ăker fra standard 100. Tvinger kjernen til Ă„ slippe
# ubrukte minnesider fra cache.
vm.zone_reclaim_mode=0
# Lar deg sette mer eller mindre aggressive tilnĂŠrminger for
# minnegjenoppretting nÄr det er lite minne i sonen.
# Hvis den er satt til null, skjer det ingen gjenoppretting.
# For filservere eller arbeidsbelastninger
# er det gunstig hvis dataene deres er bufret, sÄ zone_reclaim_mode
# bĂžr holdes deaktivert, ettersom caching-effekten
# sannsynligvis vil vĂŠre viktigere enn plasseringen av dataene.
vm.dirty_ratio=20
# Prosentandel av RAM som kan dedikeres til "skitne" sider
# Beregnet fra et omtrentlig estimat:
# Systemet har 128 GB minne.
# Ca. 20 SSD-er, hvor innstillingene i CEPH
# er satt til Ă„ allokere 3 GB RAM per enhet for cache.
# Ca. 40 HDD-er, hvor denne parameteren er 1 GB
# 20% av 128 er 25.6 GB. SĂ„, i tilfelle maksimal utnyttelse av minne,
# vil det vĂŠre 2.4 GB igjen for systemet. Det bĂžr vĂŠre tilstrekkelig for den Ă„ overleve og vente
# pÄ at hjelp skal komme - det vil si ankomsten av DevOps som vil fikse alt.
vm.dirty_background_ratio=3
# prosent av systemminnet som kan fylles med skitne sider fĂžr
# bakgrunnsprosessene pdflush/flush/kdmflush skriver dem til disk
fs.file-max=524288
# Vel, antall Ă„pne filer vil antagelig vĂŠre mye mer enn det som er angitt som standard. InnfĂžring i CEPH
Innstillinger som det er Ăžnskelig Ă„ utdype:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Tre parametere som aktiverer
journal_block_align: true # direkte i/o
journal_dio: true # til journalen
journal_max_write_bytes: 1073714824 # La oss utvide den maksimale stĂžrrelsen
# for en enkelt diskoperasjon til journalen
journal_max_write_entries: 10000 # Og antall samtidige oppfĂžringer
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Valgt Ă„ bruke en separat wal
# Vi forsÞkte til og med Ä fÄ det til Ä fungere
# NVMe
bluestore_block_db_create: true # SĂ„ et eget enhet for 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 minne lar
# lagre store mengder
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 # antall trÄder til demon pÄ én disk
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # antall samtidige utfyllingsoperasjoner for Ă©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 # Spesifikasjoner for grÄdighet. Det ble raskt
osd_pool_default_size: 2 # mangel pÄ plass, derfor vedtok vi
# Ă„ redusere antallet
# datareplica
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 reguleres etter behov
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Noen parametere som ble testet pÄ QA i versjon 12.2.12, finnes ikke i versjon ceph 12.2.2, for eksempel osd_recovery_threads. Derfor var oppgradering til 12.2.12 planlagt i produksjonen. Praksis viste at versjonene 12.2.2 og 12.2.12 var kompatible i samme klynge, som muliggjorde rolling update.
Testklynge
SelvfÞlgelig var det nÞdvendig Ä ha den samme versjonen for testing som i produksjon, men ved starten av mitt arbeid med klyngen var det kun en nyere versjon tilgjengelig i depotet. Etter Ä ha sett at forskjellene i den minor versjonen ikke var sÄ store,1393 linjer i konfigurasjonene mot 1436 den nye versjonen), bestemte vi oss for Ä begynne Ä teste den nye (uansett mÄtte vi oppdatere, hvorfor kjÞre pÄ gammel hardware)
Det eneste vi forsÞkte Ä beholde fra den gamle versjonen var pakken ceph-deploy, siden en del verktÞy (og noen ansatte) var tilpasset dens syntaks. Den nye versjonen skilt seg betydelig ut, men pÄvirket ikke driften av klyngen, sÄ vi beholdt versjonen 1.5.39
Siden ceph-disk-klienten Ă„penbart indikerer at den er utdatert og anbefaler Ă„ bruke ceph-volume â begynte vi Ă„ lage OSD-er med nettopp denne kommandoen, uten Ă„ kaste bort tid pĂ„ det utdaterte.
Planen var Ä opprette et speil med to SSD-disker, hvor vi plasserte OSD-loggene, som igjen var lagret pÄ mekaniske SAS-disker. PÄ denne mÄten sikret vi oss mot dataproblemer ved fall av disken med loggen.
Vi begynte Ă„ opprette klyngen i henhold til dokumentasjonen
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # vi har forberedt konfigurasjonen
[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 endret, selvfĂžlgelig ))
rgw_dns_name = s3-qa.mycompany.ru # og denne adressen er ogsÄ endret
rgw_host = s3-qa.mycompany.ru # og denne ogsÄ
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # mer enn tre hundre plassering grupper
# pÄ disken ble ikke vedtatt
# selv om parameteren selvfĂžlgelig avhenger av antall puljer,
# deres stĂžrrelser og antall OSD. Ă
ha lite men sunne PG
# er heller ikke det beste valget - nĂžyaktigheten til balansen lider
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # for SSD-disker er plassen for deres
# logg den samme enheten som for OSD
# vi har bestemt at 5% av disken (som selv er 1.2Tb)
# burde vĂŠre mer enn nok, og korrelerer med parameteren
# bluestore_block_db_size pluss variasjonen for store
# plassering 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Ăžrste jeg stĂžtte pĂ„ i arbeidet med denne versjonen av ceph-deploy med klyngen versjon 12.2.12, var en feil nĂ„r jeg forsĂžkte Ă„ opprette OSD med db pĂ„ programvare RAID â
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid klarte ikke Ä oppdage en PARTUUID for enheten: /dev/md1Faktisk viser blkid ingen PARTUUID, mÄtte opprette partisjoner manuelt:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# det vil bli mange partisjoner,
# uten GPT gÄr det ikke Ä opprette dem
# stÞrrelsen pÄ partisjonen er angitt i konfigurasjonen ovenfor = bluestore_block_db_size: '5368709120 #5G'
# Jeg har 20 disker for OSD, det er kjedelig Ă„ lage partisjoner manuelt
# derfor laget jeg en lĂžkke
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneSer ut som alt er klart, vi prÞver Ä opprette OSD igjen og fÄr fÞlgende feil (som for Þvrig ikke oppstod i produksjonen)
nÄr du oppretter OSD av typen bluestore uten Ä spesifisere banen til WAL, men med angivelse av 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 unparsable uuid
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) Ă„pne fikk: (22) Ugyldig argument
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db add block device(/var/lib/ceph/osd/ceph-0//block.wal) returnert: (22) Ugyldig argument
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs mislyktes, (22) Ugyldig argument
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs mislyktes med feil (22) Ugyldig argument
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** FEIL: feil ved oppretting av tomt objektlager i /var/lib/ceph/osd/ceph-0/: (22) Ugyldig argumentHvis jeg imidlertid oppretter en annen partisjon for WAL pĂ„ det samme speilet (eller et annet sted) og spesifiserer den ved opprettelse av OSD â sĂ„ gĂ„r alt glatt (bortsett fra det at det blir en separat WAL, som du kanskje ikke Ăžnsket).
Men siden jeg uansett hadde planer om Ă„ flytte WAL til NVMe, var det ikke bortkastet.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2Vi har opprettet monitorer, managere og OSD. NĂ„ vil jeg gruppere dem pĂ„ forskjellige mĂ„ter, fordi jeg planlegger Ă„ ha disker av forskjellige typer â raske puler pĂ„ SSD og store, men langsomme pĂ„ SAS-plater.
La oss anta at det er 20 disker pÄ serverne, den fÞrste tienden er én type, den andre er en annen.
Den opprinnelige, standard, kartet ser slik ut:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID KLASS VEKT TYPE NAVN STATUS REVEKT PRI-AFF
-1 14.54799 rot standard
-3 9.09200 vert ceph01-q
0 ssd 1.00000 osd.0 oppe 1.00000 1.00000
1 ssd 1.00000 osd.1 oppe 1.00000 1.00000
2 ssd 1.00000 osd.2 oppe 1.00000 1.00000
3 ssd 1.00000 osd.3 oppe 1.00000 1.00000
4 hdd 1.00000 osd.4 oppe 1.00000 1.00000
5 hdd 0.27299 osd.5 oppe 1.00000 1.00000
6 hdd 0.27299 osd.6 oppe 1.00000 1.00000
7 hdd 0.27299 osd.7 oppe 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 vert 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 vert 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
Vi skal lage vÄre egne virtuelle rack og servere med blackjack og annet:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root #lagde ny root
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #lagde ny vert
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #flyttet server til et annet rack
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # La til OSD til server
# Hvis vi opprettet feil, kan vi slette
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Problemene vi mĂžtte i driftsmiljĂžet ved forsĂžk pĂ„ Ă„ opprette nye vert og flytte den til et eksisterende rack â kommandoen ceph osd crush move ceph01-host root=rack01 hang, og monitorene begynte Ă„ falle av en etter en. Avbryte kommandoen med CTRL+C brakte klyngen tilbake til livet.
SĂžk viste fĂžlgende problem:
LĂžsningen var Ă„ dumpe crushmap og fjerne seksjonen fra den rule replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Dump the map in raw format
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #Convert to readable format
root@ceph01-prod:~#vim crushmap.txt #Edit, removing rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #Compile back
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #Load into the clusterAttention: this operation may cause a rebalance of placement groups among OSDs. It caused this for us, but only a very minor one.
A strange issue we encountered in the test cluster was that after rebooting the OSD servers, they forgot that they had been moved to new servers and racks, and reverted to the root default.
As a result, having compiled the final scheme where we created a separate root for SSDs and another for spinning disks, we spread all OSDs across the racks and simply deleted the default root. After rebooting, the OSDs stayed in their places.
Later, while digging through the documentation, we found a parameter that governs this behavior. More about it in the second part.
How we created different groups by disk types.
To start, we created two rootsâone for SSDs and one for HDDs.
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootSince the servers are physically located in different racks, we created racks for convenience and placed the servers in them.
# ĐĄŃĐŸĐčĐșĐž:
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 hostand sorted the disks by their types across different servers.
root@ceph01-q:~# Disks 0 to 3 are SSDs, located in ceph01-q, placing them in the 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:~# similarly for other serversHaving distributed the disks between the ssd-root and hdd-root, we left the root-default empty, so we can delete it.
root-ceph01-q:~#ceph osd crush remove defaultNext, we need to create distribution rules that we will tie to the pools we createâin the rules, we will specify which root data from our pool can be placed in and the uniqueness level of the replicasâfor example, replicas must be on different servers or in different racks (even in different roots if we have such distribution).
Before choosing a type, itâs better to read the documentation:
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 angitt to regler der data replikkeres
root-ceph01-q:~# mellom vertene - det vil si at replikaen mÄ ligge pÄ en annen vert,
root-ceph01-q:~# selv om de er i samme rack
root-ceph01-q:~# I produksjonen, hvis det er mulig, er det bedre Ă„ fordele vertene
root-ceph01-q:~# pÄ racks og angi Ä distribuere replikker pÄ racks:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnSĂ„ oppretter vi pooler der vi i fremtiden vil lagre diskbilder av virtualiseringen vĂ„r â 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 angir hvilke plassering regler disse poolene skal bruke
root-ceph01-q:~#ceph osd crush rule ls # ser pÄ listen over regler
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id # velger IDen vi trenger
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Valget av antall plassering grupper mĂ„ gjĂžres med en forhĂ„ndsvisning av klyngen din â hvor mange OSD-er som omtrent vil vĂŠre der, hvor mye data (i prosent av total volum) vil vĂŠre i poolen, hvor mye data som totalt vil vĂŠre.
Generelt bĂžr vi ikke ha mer enn 300 plassering grupper per disk, og det vil vĂŠre enklere Ă„ balansere med smĂ„ plassering grupper â det vil si hvis hele poolen din tar 10 Tb, og den har 10 PG-er â sĂ„ vil det vĂŠre problematisk Ă„ balansere ved Ă„ flytte terabyte steiner (pg) â det er lettere Ă„ fordele sand med smĂ„ korn i bĂžtter.
Men vi mĂ„ huske at jo hĂžyere antall PG-er â jo mer ressurser brukes til Ă„ beregne deres plassering â minne og CPU blir begynner Ă„ bli utnyttet.
En omtrentlig forstÄelse kan , levert av utviklerne av CEPH-dokumentasjonen.
Liste over materialer:
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish