CEPH valik. Osa 1
Meil oli viis riiulit, kümme optilist lülitit, konfigureeritud BGP, paarkümmend SSD-d ja hulk SAS-kettaid erinevates värvides ja suurustes, lisaks proxmox ja soov panna kogu staatika oma S3 salvestusse. See ei olnud tingimata vajalik virtualiseerimise jaoks, kuid kuna ma alustasin avatud allika kasutamist, siis tasub oma kirega lõpuni minna. Ainus, mis mind murelikuks tegi, oli BGP. Maailmas pole kedagi rohkem abitus ja vastutustundetu kui sisemine marsruutimine BGP kaudu. Ja ma teadsin, et varsti saame sellesse süveneda.
Ülesanne oli lihtne — CEPH oli olemas, kuid ei töötanud väga hästi. Oli vaja teha «hästi».
Minule jäänud klaster oli heterogeenne, käsitsi seadistatud ja praktiliselt mitte häälestatud. See koosnes kahest erinevast nodest, kus üksühine võrk täitis nii klastrivõrgu kui ka avaliku võrgu rolli. Nodedes oli neli tüüpi kettaid — kaks tüüpi SSD-sid, mis olid jagatud kaheks eraldi paigutusreegliks, ja kaks tüüpi HDD-d erinevates suurustes, mis kuulusid kolmandasse gruppi. Erinevate suurustega seotud probleem lahendati OSD-de erinevate kaaludega.
Seadistus jagati kaheks osaks — operatsioonisüsteemi häälestamine ja CEPH-i häälestamine ja selle seadistused.
OS-i täiustamine
Võrk
Kohutav latentsus mõjutas nii kirjutamise kui ka tasakaalustamise protsessi. Kirjutamise ajal — sest klient ei saa tagasisidet edukast kirjutamisest enne, kui andmete koopiad teistes paigutusgruppides ei kinnita edu. Kuna meie CRUSH kaardil oli replikate jaotamise reeglid ühe replikaga hosti kohta, siis kasutati võrku alati.
Seetõttu otsustasin kõigepealt veidi seadistada olemasolevat võrku, samal ajal püüdes veenda, et kolida eraldatud võrkude peale.
Alustasin võrkaartide seadistamisest. Alustasin järjekordade häälestamisest:
mida nägin:
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: 1On näha, et praegused parameetrid jäävad kaugele maksimaalsest. Suurendasin:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Tuginev suurepärasele artiklile
suurendasin saatmise järjekorra pikkust txqueuelen alates 1000 kuni 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Nii et järgides ceph'i dokumentatsiooni
suurendasin MTU kuni 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000Lisatud /etc/network/interfaces, et kõik ülaltoodud laaditaks käivitamisel
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 9000Pärast seda, järgides sama artiklit, hakkasin põhjalikult seadistama tuuma 4.15. Arvestades, et sõlmedel on 128G RAM, sain mingi konfiguratsioonifaili jaoks sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
# Maksimaalne andmete vastuvõtu puhver suurus kõikide ühenduste jaoks 54M
net.core.wmem_max = 56623104
# Maksimaalne andmete edastamise puhver suurus kõikide ühenduste jaoks 54M
net.core.rmem_default = 56623104
# Vaikimisi andmete vastuvõtu puhvri suurus kõikide ühenduste jaoks. 54M
net.core.wmem_default = 56623104
# Vaikimisi andmete edastamise puhvri suurus kõikide ühenduste jaoks 54M
# iga soketi kohta
net.ipv4.tcp_rmem = 4096 87380 56623104
# Vektorne (minimaalselt, vaikimisi, maksimaalselt) muutuja failis tcp_rmem
# sisaldab 3 täisarvu, mis määravad TCP sokettide vastuvõtu puhvri suuruse.
# Miinimum: igal TCP soketil on õigus kasutada seda mälu oma loomise hetkel.
# Selle puhvri kasutamise võimalus on garanteeritud isegi, kui saavutatakse
# piirangute tõke (mugav mälurõhk).
# Vaikimisi minimaalne puhvri suurus on 8 Kb (8192).
# Vaikimisi väärtus: puhvermälu lubatud suurus TCP soketi edastamiseks.
# See väärtus rakendatakse alternatiivina
# parameetrile /proc/sys/net/core/rmem_default, mida kasutavad teised protokollid.
# Vaikimisi kasutatava puhvri suurus on tavaliselt (vaikimisi)
# 87830 baiti. See määrab akna suuruse 65535 koos
# vaikimisi tcp_adv_win_scale ja tcp_app_win = 0,
# mõnevõrra väiksem, kui tavaliselt määratud tcp_app_win.
# Maksimum: maksimaalne puhvri suurus, mis võib automaatselt
# jaotatud TCP soketile vastuvõttu. See väärtus ei tühista maksimumi,
# mis on määratud failis /proc/sys/net/core/rmem_max. Statistilise
# mälu eraldamise puhul SO_RCVBUF selle parameetri puhul ei oma tähtsust.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Maksimaalne avatud soketite arv, mis ootavad ühendusi.
net.ipv4.tcp_timestamps=1
# Lubab ajatempli (timestamps) kasutamise vastavalt RFC 1323.
net.ipv4.tcp_sack=1
# Lubab TCP protokolli pakkumiste valikuliste kinnituste kasutamise
net.core.netdev_max_backlog=5000 (vaikimisi 1000)
# maksimaalne paketihulk töötlemiseks reas, kui
# liides saab pakette kiiremini, kui kernel suudab neid töödelda.
net.ipv4.tcp_max_tw_buckets=262144
# Maksimaalne sokettide arv, mis üheaegselt on TIME-WAIT seisundis.
# Kui see piir ületatakse, hävitatakse "ülemäärane" soket ja kirjutatakse
# teade süsteemilogisse.
net.ipv4.tcp_tw_reuse=1
# Lubame TIME-WAIT sokettide korduvkasutamise,
# kui protokoll peab seda ohutuks.
net.core.optmem_max=4194304
# Suurendame maksimaalset üldist puhverdusruumi
# mõõdetakse lehekülgede ühikutes (4096 baiti)
net.ipv4.tcp_low_latency=1
# Lubab TCP/IP stäkile eelistada madalat latentsust
# üle suure läbilaskevõime.
net.ipv4.tcp_adv_win_scale=1
# See muutuja mõjutab mälu arvestust soketi puhvris,
# mis on eraldatud TCP akna suuruse ja rakenduse puhvri jaoks.
# Kui tcp_adv_win_scale väärtus on negatiivne, siis arvutatakse suurus
# järgmiselt:
# Bytes - bytes2 astmes -tcp_adv_win_scale
# Kus bytes on akna suurus baitides. Kui tcp_adv_win_scale on
# positiivne, siis määratakse suurus järgmiselt:
# Bytes - bytes2 astmes tcp_adv_win_scale
# Muutuja omab täisarvu. Vaikimisi väärtus on 2,
# st rakenduse puhvri jaoks reserveeritakse ¼ osa mahust,
# mida määrab tcp_rmem muutuja.
net.ipv4.tcp_slow_start_after_idle=0
# aeglase käivitamise taaskäivitamise mehhanism, mis lähtestab akna väärtuse
# koormuse, kui ühendust ei ole kasutatud määratud aja jooksul.
# Parandage serveris SSR, et parandada pikaajaliste ühenduste töövõimet.
net.ipv4.tcp_no_metrics_save=1
#Ärge salvestage TCP ühenduse mõõtmistulemusi vahemäesse, kui see sulgub.
net.ipv4.tcp_syncookies=0
# Keela syncookie mehhanismi saatmine
net.ipv4.tcp_ecn=0
# Explicit Congestion Notification (Selge Üksikasjalik Teadaanne)
# TCP ühendustes. Kasutadab, et teavitada ummikust
# sihtkoha hostis või võrgus. Võib kasutada teatamiseks
# saatjale hostile vajaduse kohta vähendada pakettide saatmist
# kindla ruuteri või tulemüüri kaudu.
net.ipv4.conf.all.send_redirects=0
# keelab ICMP Redirecti saatmise … teistele hostidele. See valik peab olema
# lubatud, kui host toimib marsruuterina mistahes kujul.
# Meil ei ole marsruutimist.
net.ipv4.ip_forward=0
#Seega, väljumise suunamine on keelatud. Me ei ole värav, dockerid masinatel ei ole tõusnud,
# seda ei ole meil vaja.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Me ei vasta ICMP ECHO päringutele, mis saadetakse laiendatud pakettide kaudu
net.ipv4.tcp_fin_timeout=10
# määrab aja, kuivõrd soket jääb olekusse FIN-WAIT-2 pärast selle
# sulgemist kohaliku osapoolelt. Vaikimisi 60
net.core.netdev_budget=600 # (vaikimisi 300)
# Kui tarkvara katkestuste täitmine ei toimu piisavalt pikalt,
# siis võib sissetuleva andmevoo kiirus ületada tuuma võimalusi
# puhvrist tühjendada. Selle tulemusena NIC puhvried ületatakse ja traffic kaob.
# Mõnikord on vajalik suurendada SoftIRQs
# (tarkvara katkestuste) töö kestust CPU-l. Selle eest vastutab netdev_budget.
# Vaikimisi väärtus on 300. Parameeter sundib SoftIRQ protsessi
# 300 paketti NIC-st töötlema, enne kui ta CPU vabastab.
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# kui klient ja server toetavad TFO-d, millest teavitavad
# erilise lipuga TCP pakendis. Meie puhul on see platseebo, lihtsalt
# näeb kena välja)Aluster network oli eraldatud eraldi 10Gbps võrgu liidestel eraldi lapikusse võrku. Igal masinal olid paigaldatud kahekordsed võrkaartid mellanox 10/25 Gbps, ühendatud kahe eraldi 10Gbps lülitiga. Agregeerimine toimus OSPF kaudu, kuna LACP-ga sidumine näitas kummalisel kombel maksimaalset läbilaskevõimet 16 Gbps, samas kui OSPF suudab täielikult ära kasutada mõlema kümne iga masina kohta. Edasi plaanisime kasutada ROCE neid melanoxe, et vähendada latentsust. Kuidas me selle võrguosa seadistasime:
- Kuna masinatel on välised IP-d BGP-s, siis vajame me tarkvara — ( täpsemalt artikli kirjutamise ajal oli see ) juba paigaldatud.
- Kokku oli masinatel kaks võrku, igaühel kaks liidest — kokku 4 porti. Üks võrkaart kahe pordiga vaatas tehasesse ja sellel oli seadistatud BGP, teine — kahe pordiga vaatas kahe erineva lüliti poole ja sellele oli määratud OSPF
Rohkem OSPF seadistamisest: Peamine ülesanne on kaks linki kokku tuua ja omada vea taluvust.
kaks võrgu liidest on seadistatud kahes lihtsas lapikus võrgus — 10.10.10.0/24 ja 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 ens1f1kuidas masinad üksteist näevad.
DISK
Järgmise sammuna otsustasin optimeerida ketaste tööd. SSD-de puhul vahetasin planitaja noop, HDD-de jaoks — deadline. Üldiselt toimib NOOP printsiibi järgi „kellel on esimene kõnd, sellel on ka kingad“, mis inglise keeles kõlab kui „FIFO (First In, First Out)“. Taotlused järgnevad järjekorras nende saabumise järgi. DEADLINE on rohkem suunatud lugemisele, lisaks protsess järjekorrast saab praktiliselt monopolset juurdepääsu kettale operatsiooni hetkel. Meie süsteemile sobib see suurepäraselt — iga ketta puhul töötab ainult üks protsess — OSD daemon.
(Need, kes soovivad sukelduda sisendi ja väljundi plaaneerijasse, saavad selle kohta lugeda siit:
Eelistavad lugeda vene keeles: )
Linuxi häälestamise soovitustes soovitatakse samuti suurendada nr_request
nr_requests
nr_requests väärtus määrab I/O päringute koguse, mis vaheldub enne, kui I/O planeerija saadab / saab andmeid blokeerimisseadmele. Kui kasutate RAID kaarti / blokeerimisseadet, mis suudab käsitleda suuremat järjekorda kui I/O planeerija on seadistatud, võib nr_requests väärtuse tõstmine aidata parandada tootlikkust ja vähendada serverikoormust, kui serveris toimub suur I/O. Kui kasutate planeerijana Deadline'i või CFQ-d, soovitatakse nr_requests väärtust seada 2 korda järjekorra sügavuse väärtusele.
KUID! CEPH arendajad veenvad meid, et nende prioriteetsüsteem töötab paremini.
WBThrottle ja / või nr_requests
WBThrottle ja / või nr_requests
Failihaldus kasutab kirjutamiseks puhverdatud sisendi / väljundi toiminguid; see toob kaasa rida eeliseid, kui failihaldusprotokoll asub kiiruselt kiiremal kandjal. Kliendi päringud saavad teate, niipea kui andmed on logisse kirjutatud, ja seejärel kustutatakse need põhifailide kettale hiljem, kasutades Linuxi standardfunktsioone. See võimaldab OSD ketastele pakkuda kirjutamise latentsust, mis sarnaneb SSD-dega väikeste partii kirjutamiste korral. Selline viivitatud kirjutamine võimaldab südamikule ümber korraldada kettale suunatud sisendi / väljundi päringud, lootuses kas neid kokku liita või võimaldada olemasolevatel kettapeadel valida mõni optimaalsem tee oma plaatide peal. Lõppkokkuvõttes saate igast kettast pisut rohkem sisendi / väljundi operatsioone välja pigistada, kui seda oleks võimalik otse või sünkroonselt operatsioonide teostamisel.
Kuid esineb teatud probleem, kui Cephi klastrisse saabuvate kirjade maht ületab kõigi aluseks olevate ketaste võimekuse. Sellisel juhul võib kettale kirjutamise ootele jäävate sisendi / väljundi operatsioonide koguarv kontrollimatult kasvada, mille tulemuseks on sisendi / väljundi ootejärjekord, mis täidab kogu ketta ja Cephi järjekorra. Lugemistootmisnõudmised mõjutavad eriti halvasti, kuna nad jäävad kinni kirjutamispäringute vahele, mis võivad vajada mitmeid sekundeid põhikettale kirjutamiseks.
Ceph'il on probleemide lahendamiseks on sisseehitatud failisalvestusse mehhanism, mida nimetatakse WBThrottle, mis reguleerib kirjutamise ootejärjekorra üldmahtu. See on loodud selleks, et piirata kirjutamise operations, mis võivad järjekorda talletuda ja alustada vabastamisprotsessi varem, kui see kohaselt juhtuks. Kahjuks näitavad testid, et vaikimisi seadistused ei pruugi ikka veel vähendada mõju lugemisoperatsioonide latentsusele. Reguleerimine võib muuta käitumist, vähendades kirjutamisjärjekorra üldpikkusi ja tehes selle mõju väiksemaks. Siiski on tegemist kompromissiga: kui vähendate kogu maksimaalset ootejärjekorda lubatud kirjutisi, võite vähendada tuumade võimalust maksimeerida oma tõhusust SA-de haldamiseks. Mõelge natuke, mis on teile teie konkreetse rakenduse ja töökoormuse kontekstis olulisem ja reguleerige seda vastavalt.
Kirjutamise ootejärjekorra sügavuse haldamiseks saate kas vähendada üldiselt maksimaalset ootel olnud sisendi/väljundi operatsioonide arvu, kasutades WBThrottle seadeid, või vähendada maksimaalset arvu, mis on ootel oma tuuma blokeerimisel. Mõlemad võivad tõhusalt hallata sama käitumist ja teie eelistused juhtivad selle seadistuse rakendamist.
Tuleb märkida, et Ceph'i olemasolev operatsioonide prioriteetsüsteem on efektiivsem lühematele taotlustele diskitasandil. Kui vähendate selle diskiga seonduvat üldist järjekorda, liigub selle põhikoht Cephis üles, kus tal on suurem kontroll, milline prioriteet sisendi/väljundi operatsioonil on. Vaatame järgmisi näiteid:
echo 8 > /sys/block/sda/queue/nr_requestsÜLDINE
Ja veel mõned tuuma seadistused, mis aitavad teie masinat sujuvaks ja sametiseks muuta ning välja pigistada veel natuke jõudlust riistvarast.
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
# Iga on igas masinas 25 ketast, seega arvutasime, et protsesse on palju
kernel.threads-max=2097152
# Lõime palju lõime, muidugi.
vm.max_map_count=524288
# Suurendasime protsessi mälukaartide arvu.
# Nagu tuleneb tuumamuutujate dokumentatsioonist
# Mälukaardi alad kasutatakse mälestuse haldamise kõnede kõrvalmõjuna
# malloc, otseselt koos mmap, mprotect ja madvise, samuti raamatukogude laadimisel.
fs.aio-max-nr=50000000
# Häälestame sisend-väljundi parameetreid
# Linuxi tuum pakub asünkroonse mitteblokeeriva sisend-väljundi (AIO) funktsiooni,
# mis võimaldab protsessil algatada mitu sisend-väljunditegevust
# samal ajal, ootamata ühegi lõpetamist.
# See aitab suurendada rakenduste jõudlust,
# mis võivad töötlemise ja sisend-väljundi üle kattuda.
# Aio-max-nr parameeter määrab maksimaalse lubatud
# samasuguseid päringute arvu.
vm.min_free_kbytes=1048576
# minimaalne vaba mälu suurus, mida tuleb säilitada.
# Seadistatud 1GB, mida on täiesti piisavalt operatsioonisüsteemi tööks,
# ja aitab vältida OOM Killer'it OSD protsesside jaoks. Kuigi mälu on küllaga,
# on varu kotis väärt.
vm.swappiness=10
# Ütleme, et kasutame vahetust, kui vabastatud mälu on 10%.
# Masinatel, kus on 128G mälu, tähendab 10% 12 gigabaiti. Rohkem kui piisavalt tööks.
# Tavaline parameeter 60% sundis süsteemi aeglustuma, minnes vahetusse,
# kui vaba mälu on veel palju
vm.vfs_cache_pressure=1000
# Suurendame tavalisest 100. Sundime tuuma aktiivsemalt vabastama
# kasutamata mälu leheküljed vahemälust.
vm.zone_reclaim_mode=0
# Lubab kehtestada rohkem või vähem agressiivseid lähenemisviise
# mälu taaskasutamiseks, kui piirkonnas mälu otsa saab.
# Kui see on seatud nulliks, siis piirkonna taaskasutamist ei toimu.
# Failiserverite või koormuste jaoks
# on kasulik, et nende andmed on vahemälus, zone_reclaim_mode
# võiks välja lülitada, kuna vahemälu mõju,
# on tõenäoliselt olulisem kui andmete asukoht.
vm.dirty_ratio=20
# Protsent RAM-ist, mida saab määrata "mustadele" lehekülgedele
# Arvutati umbkaudse arvestuse põhjal:
# Süsteemis on 128 gigabaiti mälu.
# Umbes 20 SSD-kettast, mille seadetes CEPH on määratud
# varuma 3G RAM-i vahemäluks.
# Umbes 40 HDD-kettast, mille puhul see parameeter on 1G
# 20% 128-st on 25.6 gigabaiti. Kogu, maksimaalse mälu kasutamise korral,
# jääb süsteemi 2.4G mälu. Mis peaks kestma ja ootama
# ratsaväe tamburite kõlapid, see tähendab DevOps'i tulekut, kes kõik parandab.
vm.dirty_background_ratio=3
# protsent süsteemi mälust, mida võib täita "mustade" lehtedega enne,
# kui taustaprotsessid pdflush/flush/kdmflush kirjutavad nad kettale
fs.file-max=524288
# Noh, meil on tõenäoliselt avatud faile palju rohkem, kui vaikeväärtuselt näidatud. Sukeldumine CEPH-i
Seaded, millele soovin süvitsi minna:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Kolm parameetrit, mis hõlmavad
journal_block_align: true # otse i/o
journal_dio: true # ajakirja jaoks
journal_max_write_bytes: 1073714824 # Venitame veidi maksimaalset suurust
# ühekordse kirjutamise operatsiooni ajakirjas
journal_max_write_entries: 10000 # Ja samaaegsete kirjutamiste arv
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Otsustasime teha eraldi wal
# Isegi proovisime selle jaoks eraldi
# NVMe
bluestore_block_db_create: true # Noh, ja ajakirja jaoks eraldi seade
bluestore_block_db_size: '5368709120 #5G'
bluestore_block_wal_create: true
bluestore_block_wal_size: '1073741824 #1G'
bluestore_cache_size_hdd: '3221225472 # 3G'
# suur RAM maht võimaldab
# salvestada piisavalt suuri andmeid
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 # on ühe ketta demooni lõngade arv
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # samaaegsete täitmisoperatsioonide arv ühes OSD-s.
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 # Nisujõudluse eripärad. Väga kiiresti sai
osd_pool_default_size: 2 # ruumi puudus, kuna ajutine
# lahendus oli vähendada andmete
# koopia arvu
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 # parameeter, mida reguleerime vajadusel
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Mõned parameetrid, mida testiti QA-s versioonis 12.2.12, puuduvad versioonis ceph 12.2.2, näiteks osd_recovery_threads. Seetõttu plaaniti uuendada tootmisversioon 12.2.12. Praktika näitas versioonide 12.2.2 ja 12.2.12 ühilduvust ühes klastri, mis võimaldab teha rolling update.
Testiklastri
Muidugi oli testimiseks vajalik omada sama versiooni nagu tootmisversioonis, kuid minu töö alguse hetkeks klastriga oli hoidlas ainult uuem versioon. Vaadates, et minor versiooni erinevus ei olnud kuigi suur,1393 configide read vastandina 1436 (uuemas versioonis), otsustasime alustada uuema versiooniga (nii või naa on uuendamine vajalik, ei ole mõtet vanaga jätkata)
Ainus asi, mida püüdsime jätta vanasse versiooni, oli pakett ceph-deploy, sest osa utiliite (ja osa töötajaid) oli laskunud selle süntaksi alla. Uus versioon erines märgatavalt, kuid klastrite tööd see kuidagi ei mõjutanud, ja see jäeti vanemaks versiooniks 1.5.39
Kuna komandor ceph-disk ütleb selgelt, et see on deprecated ja palun kasutage, austatud, komandot ceph-volume — alustasime OSD loomist just selle komandoga, raiskamata aega aegunud versioonile.
Plaani kohaselt — luua peegel kahe SSD ketta vahel, kuhu paigutame OSD päevikud, mis omakorda asuvad spindle SAS ketastel. Nii kaitseme andmeid ketta rikete korral.
Klastri loomine sai aluseks dokumentatsioonile
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # eelne ettevalmistatud konfi
[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 # aadress on muudetud, loomulikult ))
rgw_dns_name = s3-qa.mycompany.ru # ja see aadress on muutunud
rgw_host = s3-qa.mycompany.ru # ja see ka
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # rohkem kui kolm sada plaanigruppi
# kettale ei julgenud
# kuigi parameeter sõltub loomulikult partii
# nende suurustest ja OSD arvust. Omada vähe, kuid terveid PG
# ei ole samuti parim valik - tasakaalustamine kannatab
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # praegu SSD kettade jaoks on nende
# ajakirja jaoks sama seade mis OSD
# otsustasime, et 5% kettast (mis iseenesest on 1.2Tb)
# peaks olema täiesti piisav, ja korreleerub parameetriga
# bluestore_block_db_size, pluss varieeruvus suurte
# plaanigruppide jaoks
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-qEsimene probleem, millega ma selle versiooni ceph-deploy puhul kokku puutusin versiooniga 12.2.12, oli viga OSD loomise katsetes db-ga tarkvara RAID-is.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid ei suutnud tuvastada PARTUUID-d seadmele: /dev/md1Tõepoolest, blkid ei näidanud PARTUUID-d, pidin partitsioonid käsitsi looma:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# partitsioone tuleb palju,
# ilma GPT-d ei saa neid luua
# partitsiooni suuruse määrasime konfis eespool = bluestore_block_db_size: '5368709120 #5G'
# Mul on 20 ketast OSD jaoks, käsitsi partitsioonide loomine on vaevalt
# seega tegin tsükli
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneTundub, et kõik on valmis, proovime taas OSD-d luua ja saame järgmise vea (mis, muide, toimumise osas ei esinenud):
OSD loomisel bluestore tüüpi ilma WAL-i teed näitamata, kuid db-iga.
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 parsitav uuid
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) avamine andis: (22) Keelatud argument
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db lisa blokeerimisseade(/var/lib/ceph/osd/ceph-0//block.wal) tagastas: (22) Keelatud argument
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs ebaõnnestus, (22) Keelatud argument
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs ebaõnnestus veaga (22) Keelatud argument
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** VIGA: tühja objektide poe loomine aadressil /var/lib/ceph/osd/ceph-0/: (22) Keelatud argumentSiiski, kui samas peeglis (või mõnes teises kohas, vastavalt valikule) luua veel üks partitsioon WAL-i jaoks ja see OSD loomisel märkida, siis kõik läheb sujuvalt (välja arvatud eraldi WAL-i ilmumine, mida te võib-olla ei soovinud).
Aga kuna plaanis oli WAL-i viia NVMe-le, siis osutus see praktikaks kasulikuks.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2Loomine monitore, haldurite ja OSD-d. Nüüd tahaks neid erinevatesse gruppidesse paigutada, et plaanides oleks erinevat tüüpi ketas — kiired pujad SSD-l ja suured, kuid aeglased SAS-plaadid.
Arvasime, et serverites on 20 ketast, esimesed kümme on üks tüüp, teine kümme - teine.
Esialgne, vaikekaart näeb välja selline:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID KLASS KAAL Tüüp NIMI STAATUS ÜMBERKAAL PRI-AFF
-1 14.54799 juur vaike
-3 9.09200 host ceph01-q
0 ssd 1.00000 osd.0 üles 1.00000 1.00000
1 ssd 1.00000 osd.1 üles 1.00000 1.00000
2 ssd 1.00000 osd.2 üles 1.00000 1.00000
3 ssd 1.00000 osd.3 üles 1.00000 1.00000
4 hdd 1.00000 osd.4 üles 1.00000 1.00000
5 hdd 0.27299 osd.5 üles 1.00000 1.00000
6 hdd 0.27299 osd.6 üles 1.00000 1.00000
7 hdd 0.27299 osd.7 üles 1.00000 1.00000
8 hdd 0.27299 osd.8 üles 1.00000 1.00000
9 hdd 0.27299 osd.9 üles 1.00000 1.00000
10 hdd 0.27299 osd.10 üles 1.00000 1.00000
11 hdd 0.27299 osd.11 üles 1.00000 1.00000
12 hdd 0.27299 osd.12 üles 1.00000 1.00000
13 hdd 0.27299 osd.13 üles 1.00000 1.00000
14 hdd 0.27299 osd.14 üles 1.00000 1.00000
15 hdd 0.27299 osd.15 üles 1.00000 1.00000
16 hdd 0.27299 osd.16 üles 1.00000 1.00000
17 hdd 0.27299 osd.17 üles 1.00000 1.00000
18 hdd 0.27299 osd.18 üles 1.00000 1.00000
19 hdd 0.27299 osd.19 üles 1.00000 1.00000
-5 5.45599 host ceph02-q
20 ssd 0.27299 osd.20 üles 1.00000 1.00000
21 ssd 0.27299 osd.21 üles 1.00000 1.00000
22 ssd 0.27299 osd.22 üles 1.00000 1.00000
23 ssd 0.27299 osd.23 üles 1.00000 1.00000
24 hdd 0.27299 osd.24 üles 1.00000 1.00000
25 hdd 0.27299 osd.25 üles 1.00000 1.00000
26 hdd 0.27299 osd.26 üles 1.00000 1.00000
27 hdd 0.27299 osd.27 üles 1.00000 1.00000
28 hdd 0.27299 osd.28 üles 1.00000 1.00000
29 hdd 0.27299 osd.29 üles 1.00000 1.00000
30 hdd 0.27299 osd.30 üles 1.00000 1.00000
31 hdd 0.27299 osd.31 üles 1.00000 1.00000
32 hdd 0.27299 osd.32 üles 1.00000 1.00000
33 hdd 0.27299 osd.33 üles 1.00000 1.00000
34 hdd 0.27299 osd.34 üles 1.00000 1.00000
35 hdd 0.27299 osd.35 üles 1.00000 1.00000
36 hdd 0.27299 osd.36 üles 1.00000 1.00000
37 hdd 0.27299 osd.37 üles 1.00000 1.00000
38 hdd 0.27299 osd.38 üles 1.00000 1.00000
39 hdd 0.27299 osd.39 üles 1.00000 1.00000
-7 6.08690 host ceph03-q
40 ssd 0.27299 osd.40 üles 1.00000 1.00000
41 ssd 0.27299 osd.41 üles 1.00000 1.00000
42 ssd 0.27299 osd.42 üles 1.00000 1.00000
43 ssd 0.27299 osd.43 üles 1.00000 1.00000
44 hdd 0.27299 osd.44 üles 1.00000 1.00000
45 hdd 0.27299 osd.45 üles 1.00000 1.00000
46 hdd 0.27299 osd.46 üles 1.00000 1.00000
47 hdd 0.27299 osd.47 üles 1.00000 1.00000
48 hdd 0.27299 osd.48 üles 1.00000 1.00000
49 hdd 0.27299 osd.49 üles 1.00000 1.00000
50 hdd 0.27299 osd.50 üles 1.00000 1.00000
51 hdd 0.27299 osd.51 üles 1.00000 1.00000
52 hdd 0.27299 osd.52 üles 1.00000 1.00000
53 hdd 0.27299 osd.53 üles 1.00000 1.00000
54 hdd 0.27299 osd.54 üles 1.00000 1.00000
55 hdd 0.27299 osd.55 üles 1.00000 1.00000
56 hdd 0.27299 osd.56 üles 1.00000 1.00000
57 hdd 0.27299 osd.57 üles 1.00000 1.00000
58 hdd 0.27299 osd.58 üles 1.00000 1.00000
59 hdd 0.89999 osd.59 üles 1.00000 1.00000
Loome oma virtuaalsed rackid ja serverid, koos mustade kardinate ja muu:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root #loome uue juure
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #loome uue hosti
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #liigutasime serveri teise racki
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Lisame OSD serverisse
# Kui see on vale ja loomine, siis saab kustutada
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01Probleemid, millega me silmitsi seisime töökeskkonnas klaster, kui üritasime luua uusi hoste ja liigutada neid olemasolevasse racki – käsk ceph osd crush move ceph01-host root=rack01 jääb seisma ja monitorid hakkasid üksikult kokku kukkuma. Käskluse katkestamine lihtsalt CTRL+C viib klastrit tagasi elu maailma.
Otsing näitas sellist probleemi:
Lahendus oli crushmap'i auk ja selle konfiguratsiooni eemaldamine rule replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Dumpime kaardi toorelt
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #tõlgime loetavasse
root@ceph01-prod:~#vim crushmap.txt #redigeerime, eemaldades reegli replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #kompileerime tagasi
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #laadime klastrisseHoiatus: see operatsioon võib põhjustada placement group'i ümberkorraldamist OSD'ide vahel. Meil juhtus see, kuid väga väikeses mahus.
Ja veidrus, millega me testiklastris kokku puutusime, oli see, et pärast serveri taaskäivitamist unustasid OSD'd, et nad olid uutesse serveritesse ja rack'idesse liigutatud, ning naasid algse vaikeseade juurde.
Kokkuvõttes, koostades lõppskeemi, kus loodi eraldi root SSD-diskide jaoks ja eraldi spindeldiskide jaoks, jaotati kõik OSD'd rack'idesse ning lihtsalt eemaldati vaikeseade. Pärast taaskäivitamist jäid OSD'd oma kohtadele.
Hiljem dokumentatsioonist kaevates leidsime parameetri, mis vastutab selle käitumise eest. Räägime sellest teises osas.
Kuidas me tegime erinevaid rühmi, mis põhinevad ketaste tüüpidel.
Esiteks tegime kaks root'i - SSD-diskide ja HDD-diskide jaoks.
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootKuna füüsiliselt asuvad serverid erinevates rack'ides - mugavuse huvides lõime rack'id ja panime nendesse serverid.
# Стойки:
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 hostja jagasime kettad nende tüüpide põhjal erinevatesse serveritesse.
root@ceph01-q:~# Kettad 0 kuni 3 on SSD, asuvad ceph01-q, paneme need serverisse
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:~# sarnane teiste serveritega.Jagades kettad ssd-root'i ja hdd-root'i, jätsime root-default'i tühjaks, seega saame selle kustutada.
root-ceph01-q:~#ceph osd crush remove defaultJärgmise sammuna peame looma jaotamisreeglid, mille seome loodud basseinidega - reeglite puhul näitame, millisesse root'i saame meie basseini andmed panna ja replikatsiooni unikaalsuse taset - näiteks replikad peavad olema erinevates serverites, või erinevates rack'ides (isegi erinevates root'ides, kui meil on selline jaotamine).
Enne tüübi valimist on parem tutvuda dokumentatsiooniga:
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:~# Näitasime kahte reeglit, mille puhul andmed replikatakse
root-ceph01-q:~# hostide vahel - see tähendab, et replika peab olema teises hostis,
root-ceph01-q:~# isegi kui nad on samas rack'is.
root-ceph01-q:~# Tootmisrežiimis, kui see on võimalik, oleks parem jagada hostid
root-ceph01-q:~# rack'ide vahel ja määrata replikate jaotamine rack'idesse:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnLoome ja loome basseine, kus soovime tulevikus hoida oma virtualiseerimise ketta pilte — 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 1024Ja ütleme nendele basseinidele, milliseid paigutamise reegleid järgida.
root-ceph01-q:~#ceph osd crush rule ls # vaatame reeglite nimekirja
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id # valime vajaliku ID
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
Paigutusgruppide arvu valimisel tuleb läheneda ettevaatlikult, omades varasemat arusaamist oma klastri kohta — kui palju OSD-sid seal enamasti on, milline on andmete maht (protsent kogumahtust) basseinis ja kui palju andmeid kokku on.
Kokku on soovitatav mitte ületada 300 paigutusgruppi ketta kohta, ja väikeste paigutusgruppidega on lihtsam tasakaalu saavutada — seega, kui kogu teie bassein hõlmab 10 Tb ja sellel on 10 PG — siis teraaibi plaatide (pg) ümberparkimine on keeruline — liivakottide väikeste teradega ümber vedamine on lihtsam ja sujuvam.
Aga tuleb meeles pidada, et mida rohkem on PG-e, seda rohkem ressursse kulub nende asukoha arvutamiseks — algavad mälu- ja CPU põlemised.
Umbes arusaamine võib , mille on esitanud CEPH-i dokumentatsiooni arendajad.
Materjalide loetelu:
Allikas: habr.com
