Ceph
NB! Katsetused tehtud versiooniga ceph-0.80.x "Firefly"
Sisukord
Sissejuhatus
Ceph on dünaamiliselt exabaidini laiendatav objekti, bloki, and failihoidla, mis arendatud pidades silmas tõrkekindlust. Cephi toetus on uuemates kernelites olemas.
Device Drivers Block devices Rados block device (RBD) File systems Btrfs filesystem support Btrfs POSIX Access Control Lists FUSE (Filesystem in Userspace) support Network File Systems Ceph distributed file system
Cephi esimene stable reliis (Argonaut) tuli välja aastal 2012. Hetkel on aktiivne verisoon koodnimega Firefly
ceph-0.56.x "Bobtail" ceph-0.67.x "Cuttlefish" ceph-0.72.x "Dumpling" ceph-0.80.x "Firefly"
Tegemist on väga kiirelt areneva tarkvaraga. Üks näide sellest kui toores tegelikult see kõik on kasvõi see, et fstrimi tugi jõudis rbd sisse alles 2014 lõpus ilmunud kerneliga ja see on suht oluline täiendus.
Cephi struktuur
Et kõik ausalt ära rääkida siis Ceph koosneb kolmest põhikompnentist, millede kogumit nimetatakse RADOSiks. Seal on Object Storage Daemon (OSD), Monitor (MON) ja Meta-Data Server (MDS). Lisaks on olemas algoritm nimega crush mis ütleb kus info peaks asuma ning rados on see mootor, mis selle töö ära teeb.
OSD on deemon mis tegeleb andmete hoidmise ja paigaldamisega. See deemon peab töötama igas clustri nodes, kus on salvestusseadmed (sas, sata vms kettad). Kui süsteemis pole raidi tuleb nodes käivitada iga ketta kohta oma OSD deemon (nt 4 ketast tähendab 4 deemonit). Kui kasutuses raid siis piisab ühest. Vaikimisi on ühe OSD kohta kolm nn pooli (data, metadata ja rbd).
Teine oluline komponent on monitor. Tegemist on kergekaalulise deemoniga, mis tegeleb klientide ja muude väliste tarkvaratükkidega läbiviidava suhtlusega. Samuti tegeleb ta info terviklikkuse kontrollimise jms töödega (Quorum decisions). Näiteks, kui mountida ceph failisüsteem kliendi poolelt siis tuleb see ühendada MON serveri aadressiga. Ideaalne on cephi soovituse järgi omada clustris kolme monitori.
Meta-data server on koht kuhu salvestatakse metadata. Seda deemonit on tegelikult vaja vaid Ceph failisüsteemi kasutades, RBD'd (cephi blockdevicet kasutades seda vaja ei ole). Hetkel pole clustrisse üle ühe MDS teenuse võimalik paigaldada, arendus käib. Metadata serverites on mõnedes seadistustes kasutatud SSD kettaid.
Ceph rühmitab infot kandvad objektid PGdesse (placement groupidesse) ja seob need omakorda poolidesse. Iga pooli kohta saab määrata mitme PG vahel seal objektid jagatakse, aga sellest pikemalt juba allpool. Poolide peale tekitatakse omakorda failisüsteemid, blokkseadmed jne
Ceph on võimeline jagama ja talletama infot kolmel viisil.
- Ceph RGW, mis on Amazon S3 ja openstackiga ühilduv API. Sellele ligipääsuks on vaja paigaldada Radosgw nimeline tarkvara (tegemist fastcgi mooduliga ja tuleb paigaldada fastcgi võimelisele veebiserverile).
- Ceph RBD, mis jagab blokkseadmeid (nt virtuaalmasinatele) ja pakub snapshottimist, provisioneerimist ja pakkimist. RBD tugi on olemas Proxmox VE süsteemis ja olemas on ka QEMU-RBD http://ceph.com/docs/master/rbd/qemu-rbd/.
- CephFS, mis hajus posix ühilduv failisüsteem, seda saab mountida nii kerneli draiveri kui fuse abil ning ta vajab serverites täiendavat MDS (metadata) teenust http://ceph.com/docs/master/cephfs/kernel/
Nagu juba varem öeldud siis on vaja näiteks lihtsa ainult blockseadmeid säilitava ja jagava clustri ehitamiseks OSD ja MON deemoneid sisaldavaid servereid.
Tasub tähele panna, et monitorid ise andmeid osd-delt ei liiguta. Monitor jagab vaid map-i ja kasutajad suhtlevad edasi osd-dega otse üle avaliku (public) võrgu.
Clustri planeerimine
Cephi clustri koostamiseks on olemas päris arvutult erinevaid võimalusi. Kuna tegemist on väga modulaarse ja võimalusterohke tarkvaraga sõlbu kõik sellest, et mis on vajadus, milleks tahetakse seda hiljem kasutama hakata, mis on infrastruktur, palju on raha ja nodesid jne jne. Näiteks tuleks blokseadmeid jagav cephi SAN mitmeti erinev veebiprojektile vajaminevast objektilaost Mõned üldised soovitused siiski netis on õnneks olemas.
Clustriks vajalike arvutite hulgast rääkides ei ole soovitatav kasutada alla kolme serveri, paljud allikad nimetavad production clustri minimaalseks suuruseks viis serverit ning soovitavad nt kolme serveri lahendust kasutada ainult testimiseks.
Esimene küsimus - mitu OSD ja MON serverit/teenust? Kiire gogeldamisega jõuab selleni, et nt 10 monitori igas clustri "õlas" on paha. Soovitatakse kasutada keskmistel või suurtel clustritel kolme. Liiga palju monitore pidid tekitama overheadi endavahelise sünkimisega. Raidi kasutada ei soovitata, soovitatakse kettad panna JBOD formaati raidikaardi korral ja iga ketta kohta üks OSD deemon (seejuures ühe masina kohta üle kaheksa OSD ehk siis ketta ei soovitata). Sageli olid clustrinoded koostatud nii, et 2 väikest ketast opsüsteemiga, 2 SSD ketast journaliga (selleni kohe jõuan) ja kaheksa suurt ketast info jaoks.
Järgneval pildil on blokk-seadmeid jagava clustri skeem, kus kakskümmend kuus OSD masinat, mis kasutavaid kettaid ilma raidita ning omavad iga ketta kohta ühe OSD deemoni ja kolm monitor nodet.
Iga salvestamiseks oleva terabaidi kohta soovitatakse OSDl omada üks gigabait mälu (läheb peamiselt vaja taastamisel jms operatsioonidel). Metadata serveritel 1G iga deemoni instance kohta. Väidetakse, et enamus OSD aeglusi tuleb sellest, et faile hoitakse ühel ja samal kettal.
Teine küsimus - kuidas jagada data ja journal info. Ceph lammutab nimelt kõik info enne ketastele kirjutamist kahte lehte. Esimene siis journal ja teine metadata. Vaikimisi pannakse journal info igale kettale data kõrval asuvasse eraldi olevasse kausta ja Ceph peab suutma kirjutada journali info enne seda, kui saab alustada andmete kirjutamist, mis tekitab traditsioonilistes failisüsteemides nagu EXT4 ja XFS seisaku. Btrfs failisüsteem suudab kirjutada journalit ja infot paraleelselt, mistõttu sobib paremini. Samas on hetkel btrfsi ja cephi kooskasutamine mitte soovitatav kuna väikeste failide jõudlus kipub kaduma. Btrfs kirjutab neid nagu aru võis saada mitmest listivestlusest liiga suure blokiga.
Siinpuhul leidsin tõesti väga palju näiteid, kus kasutatakse süsteemi, et iga kuue "pöörleva" traditsioonilise kõvaketta kohta pannakse serverisse üks SSD ketas metadata jaoks. Pakuti välja selline valem
Journal number = (SSD seq write speed) / (spinning disk seq write speed)
Ehk siis SSD teeb keskmiselt ~500MB/s seq write ja tavaline ketas 110 siis tuligi suhtarv midagi 4.5 mida siis nad ümardasid veel.
Oletame, et meil on kõvaketas, mis kirjutab 100MB/s nimg me paigutame nii journali kui andmed samale kettale. Koos vaikimis writeahead seadistusega lüüakse kirjutamiskiirus viie sekundi järel kaheks.
Device: wMB/s sdb1 - journal 50.11 sdb2 - osd_data 40.25
Btrfs kasutamine hoiab vähemalt teoreetiliselt ära selle, et info kirjutamine hakkaks ootama journali kirjutamise taga (journal kirjutatakse alati esimesena), kuid kirjutamisel jagavad nad sellest hoolimata olemasolevat ketta ribalaiust. Seetõttu võib hoida journalit ka btrfsi peal. Subjektiivsed testid näitasid, et kiirusevõit kolides btrfs peal oleval journalilt ümber eraldi SSD peal oleval journalile on kuskil 15-25% aidates ilmselt clustrist viimast pigistada aga pole ilmselgelt esmavajalik, eriti kui vaja on pigem maksimaalselt suurt mahtu ja hoida clustri hind madal. Samas oli 2014 aastal veel btrfs kasutamisel probleeme väikeste blokkide kiire kirjutamisega ja ka cephi arendajad ei soovitanud seda veel productionis rakendada.
Ceph OSDs calculate data placement with CRUSH, selleks vajab OSD vähemalt 4 tuuma. Lisades Cephi clustrisse OSD deemoni uuendatakse cluster mapi ning viiakse läbi tasakaalustamine, mille käigus osad PGd migreeritakse eksisteerivatelt OSDdelt ümber uutele tühjale osdle.
Vähemalt test lingil http://ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/ näitab, et mõistlik oleks kasutada raidikaardil JBOD (just bunch of drives) võimekust, ehk jagada läbi raidikaardi kõik kettad ükshaaval opsüsteemile ilma raidita välja ning tekitada igale sellisele kettale oma OSD deemon. Samuti tuleks parima jõudluse saavutamiseks kasutada btrfs failisüsteemi.
Cephile ehitatud objektihoidla skeem.
Võrgu koostamine
Soovituslik oleks eraldada OSD deemonite omavaheline sünkronisatsioon ja infovahetus eraldi võrku/vlani.
Cephi paigaldus Debianile ceph-deploy utiliidiga
Cephi cluster mida ehitama hakkame näeb välja järgnev.
See koosneb kuuest data nodest, kolmest monitorist ja ühest kontrollmasinst.
Näites on kasutatud cephi versiooni 0.80.6.
admin masinas milleks meil on ceph1 anname järgnevad käsud
Genereerime ssh võtme
# ssh-keygen
ja kopeerime võtme kõigile nodedele
ssh-copy-id root@ceph2 ssh-copy-id root@ceph3 ssh-copy-id root@ceph4 ssh-copy-id root@ceph5 ssh-copy-id root@ceph6 ssh-copy-id root@ceph7 ssh-copy-id root@ceph8 ssh-copy-id root@ceph9
Seejärel tekitame järgneva /etchosts faili
10.40.6.117 ceph1 10.40.6.118 ceph2 10.40.6.119 ceph3 10.40.6.120 ceph4 10.40.6.121 ceph5 10.40.6.122 ceph6 10.40.6.123 ceph7 10.40.6.124 ceph8 10.40.6.125 ceph9
hosts fail ja enviroment paika kõigile
# for masin in `cat nodes.txt`; do echo -n "$masin: " && scp -r /etc/environment root@$masin:/etc/environment; done # for masin in `cat nodes.txt`; do echo -n "$masin: " && scp -r /etc/hosts root@$masin:/etc/hosts; done
Installime ceph-deploy programmi
# wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | apt-key add - # echo deb http://ceph.com/debian-dumpling/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list # apt-get update # apt-get install ceph-deploy
cephi tarkvara tuleb järgneva käsuga paigaldada kõigile nodedele
# ceph-deploy install ceph1 ceph2 ceph3 ceph4 ceph5 ceph6 ceph7 ceph8 ceph9
Seejärel tuleb luua monitor(id) neid tekitame kolm tk
# ceph-deploy new ceph3 ceph4 ceph2 # ceph-deploy mon create-initial ceph2 ceph3 ceph4
Seejärel peaks tekkima deploy masina root kausta ceph.conf (samuti kõikide nodede /etc kauasta)
# defineerime monitorid mon_initial_members = ceph3, ceph6, ceph2 mon_host = 10.0.0,10.0.0.22,10.0.0.11 # ilma selle reata ei ole võimalik klientidel autentimist kasutada auth supported = cephx # defineerime autentimise lahenduse auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx filestore_xattr_use_omap = true # Võrgu seadistuseks, et OSDe liiklus oleks eraldi cluster network = 10.7.0.0/24 public network = 10.2.0.0/24 filestore journal parallel = true mon_clock_drift_allowed = 1 # osd spetsiifilised seadistused [osd] osd journal size = 2048 osd_op_threads = 4 osd_disk_threads = 4 osd mkfs options btrfs = -f osd mkfs type = btrfs osd mount options btrfs = noatime,nodiratime # kliendi seadistused [client] rbd cache = true rbd cache writethrough until flush = true #admin socket = /var/run/ceph/rbd-client-$pid.asok
Kui on soov kasutada xfsi asemel btrfsi tuleb konfi täiendada. Vaikimisi tekib xfs seega tuleks näitada btrfs ette võtmega osd mkfs type = btrfs. Selleks kui meil pole tegu puhaste ketastega vaid neil oli juba varem nt btrfs olemas tuleb anda -f (force) võti osd mkfs options btrfs = "-f". Ning --overwrite-conf parameeter on ka selle tarbeks
Lisaks tekivad deploy masina root kausta failid ceph.bootstrap-mds.keyring ceph.bootstrap-osd.keyring ceph.client.admin.keyring mis olulised hiljem nt kliendil ligipääsuks clustrile
Edasi data nodede paigaldus. Neid on meil kokku viis. ceph6 ceph5 ceph7 ceph8 ceph9 on masinad mil on süsteemis neli ketast
sda - süsteem sdb sdc sdd
Ja siis hakkame kettaid ja osd'sid valmistama ehk paigaldame kõigile serveritele OSD (iga ketas nõuab eraldi OSD deemonit). journal võib olla nii fail kui ka haljas blockseade. Hetkel tekitatakse igale kettale eraldi 1-10G suurune journal partitsioon.
ceph-deploy disk zap ceph7:sdb ceph-deploy disk zap ceph7:sdc ceph-deploy disk zap ceph7:sdd ceph-deploy --overwrite-conf osd prepare --fs-type btrfs ceph7:sdb ceph-deploy --overwrite-conf osd prepare --fs-type btrfs ceph7:sdc ceph-deploy --overwrite-conf osd prepare --fs-type btrfs ceph7:sdd ceph-deploy disk zap ceph6:sdb ceph-deploy disk zap ceph6:sdc ceph-deploy disk zap ceph6:sdd ceph-deploy --overwrite-conf osd prepare --fs-type btrfs ceph6:sdb ceph-deploy --overwrite-conf osd prepare --fs-type btrfs ceph6:sdc ceph-deploy --overwrite-conf osd prepare --fs-type btrfs ceph6:sdd # selleks, et ka peale booti võetaks osd külge ceph-deploy osd activate ceph7:/dev/sdb ceph-deploy osd activate ceph7:/dev/sdc ceph-deploy osd activate ceph7:/dev/sdd
Ja nii kõigile nodedele
Kuidas opsüsteem teab mis kettad automaagiliselt kuhu kaustadesse mountida? Ceph osd create käsuga luuakse partitsioon mille labeliks Ceph UUID. Kui udev tuvastab boodil cephi uuid partitsiooni kutsub ta välja ceph-disk activate /dev/sdX käsu, mis moundib failisüsteemi /var/lib/ceph/osd/cluster-osd-id alla ning stardib omakorda init skripti mis paneb tööle sobiva OSD deemoni.
nullist alustamiseks, juhul kui kõik läks nässu.
ceph-deploy purge ceph1 ceph2 ceph3 ceph4 ceph5 ceph6 ceph7 ceph8 ceph9 ceph-deploy purgedata ceph1 ceph2 ceph3 ceph4 ceph5 ceph6 ceph7 ceph8 ceph9 ceph-deploy forgetkeys
PS: Purgedata teeb ka unmoundi.
Konfiguratsiooni muutmise järel tuleb see kopeerida ka kõigile monitoridele/data nodedele, selleks
# ceph-deploy --overwrite-conf config push ceph2 ceph3 ceph4 ceph5 ceph6 ceph7 ceph8 ceph9
Journali osas tundub, et 7200 RPM kiirusega ketaste ning gigase võrgu puhul on mõistlik kasutada 10Gb suurust journalit.
[osd] osd journal size = 10000
Võimalus seadistada journal ja data erinevatesse kohtadesse. Näiteks soovides seadistada journali igas data nodes eraldi mounditud SSD kettale tuleb lisada ceph.conf faili
[osd] osd journal = /journal/osd.$id.journal
OSD deemoni journali /var/lib alt uude (nt ssd peale) kohta tõstmine
Juba toimiva ja töötava OSD journali liigutamine nõuab rohkem samme. Esiteks tuleb OSD mille journalit hakkame liigutama seisata
# /etc/init.d/ceph.osd-$number stop
Seejärel kirjutame journali sisu kettale tühjaks
# ceph-osd -i $number --flush-journal
Seejärel muudame ceph.conf failis journali asukohta ja genereerime uue journali, mis tekib siis juba uude kohta
# ceph-osd -i $number --mkjournal
Ning stardime osd deemoni uuesti
# /etc/init.d/ceph.osd-$number start
Kui on soov tõsta journal tmpfs peale võiks seadistatud veel olla
journal dio = false
Seda on vaja kuna tmpfs ei toeta Direct I/O'd. Tasub märkida, et journali käitamine mälukettal tähendab põhimõtteliselt kaudset journali väljalülitamist. Kahjuks selleasemel, et pakkuda cluster-failisüsteemile võtit journal=disable on ehitatud sisse võimalus toppida journal tmfsile, mis põhimõtteliselt tähendab journali väljalülitamist sest journal (andmebaas mis vähendab võimalust ootamatute crashide puhul jääda katkise failisüsteemiga) asub mälukettal ning hävib esimesena.
ja nii filestore journal writeahead = true kui filestore journal parallel = true võiksid olla välja lülitatud
Kui on soov (ülaltoodud hoiatusest hoolimata) ikkagi kasutada btrfsi siis tasub silmas pidada, et 2014 oktoobri seisuga stabiilne debiani kernel seda hästi ei toeta ja vajalik on paigaldada unstable kernel. Lisaks võib kontrollida kas journal_parallel on sisse lülitatud
# ceph --admin-daemon /var/run/ceph/ceph-osd.4.asok config show | grep paral "filestore_journal_parallel": "false",
selle toimima panekuks konfi
filestore journal parallel = true
Kasutamine
Klientmasinale ei pea paigaldama kogu cephi täies mahus, pakettide paigalduseks piisab näiteks kui adminmasinas anda käsk
# ceph-deploy install ceph-client
Selleks, et klientmasinasse paigaldataks ka cephi konfiguratsioon ja ceph.client.admin.keyring tuleb anda admin-masinas käsk
# ceph-deploy admin ceph-client
Statistika vaatamiseks
# ceph status cluster 0a588263-cc78-407c-9282-7539cc947a86 health HEALTH_WARN too few pgs per osd (12 < min 20); clock skew detected on mon.ceph3, mon.ceph4 monmap e1: 3 mons at {ceph2=10.40.6.118:6789/0,ceph3=10.40.6.119:6789/0,ceph4=10.40.6.120:6789/0}, election epoch 6, quorum 0,1,2 ceph2,ceph3,ceph4 osdmap e82: 15 osds: 15 up, 15 in pgmap v139: 192 pgs, 3 pools, 0 bytes data, 0 objects 62608 kB used, 21319 GB / 21349 GB avail 192 active+clean
Veel saab vaadata osd deemonite statistikat
# ceph osd tree
weight peaks näitama seejuures suurust (weight 1 on tera, weight 1.8 kaks jne).
Selle muutmiseks, näiteks on osd13 ekslikult lisatud liiga väiksena. Suurendame osd.13 ketta 3T pealt 2T peale
$ ceph osd crush reweight osd.13 2
Kontrollime muudatust
$ ceph osd tree | grep osd.13 13 2 osd.13 up 1
OSD kustutamine
# ceph osd out osd.5 # ceph osd crush remove osd.5 # ceph auth del osd.5
Seejärel tuleb logida nodesse ja panna osd seisma. Lõplikult eemaldub osd cephi süsteemist käsuga
# ceph osd rm 5
Cephi OSD ketta võib andmenodes mountida ka käsitsi
mount /dev/sd<XY> /var/lib/ceph/osd/ceph-<K>/
Ja seejärel startida OSD deemoni
start ceph-osd id=<K>
Node startimisel käivitab cephi init skript ühe OSD deemoni iga kausta kohta, mis leitud /var/lib/ceph/osd alt võttes OSD id kausta nimest. Näiteks kui seal on ceph-2 siis starditakse OSD.2
Monitori info asub kaustas
/var/lib/ceph/mon/ceph-<myid>
Cephi monitori info kustutamiseks ja uue monitori initsialiseerimiseks
# rm -rf /var/lib/ceph/mon/ceph-<myid> # ceph-mon --mkfs -i <myid> --keyring /etc/ceph/ceph.client.admin.keyring
Konfi saab vaadata data nodede seest nt
# ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok config show | grep paral "filestore_journal_parallel": "true",
Mõningaid cephi parameetreid saab kõigis nodedes jooksvalt muuta injectargs abil, nt tõstame parandamise paraleelsust
ceph tell osd.* injectargs '--osd-max-backfills 32'
Jooksvalt sättimisest isegi tekst http://www.sebastien-han.fr/blog/2012/10/22/ceph-inject-configuration-without-restart/
Poolid
Esiteks poolide kohta mõned põhimõtted, kõik failisüsteemid, rbd seadmed jms peavad kuuluma pooli. Pool on selline väga oluline üksus mis koondab enda alla andmeid sisaldavad PG-d. Igal poolil tuleb luues ära määrata ka PGde arv ning seegi mõjutab mingil (testide järgi mitte küll üliolulisel määral) pooli omadusi. Üks olulisemaid pooli omadusi on aga koopiate arv, ehk mitu tükki igast andmeühikust on clustri peale hajutatud.
Näiteks võib arhiveerimiseks mõeldud poolile panna julgelt ilmselt koopiate arvuks 2 aga näiteks veebi, andmebaaside jms jaoks võiks see arv olla 2 või vahel isegi 4. Koopiate arvu hulka ja ka PG-de hulka saab muide jooksvalt muuta seega pole probleemi ka kui hiljem seda ümber seadistada.
Iga pooli statistikat saab ka vaadata eraldi mis teeb utiliseerimise jälgimise mõnusamaks.
Poolil suuruse limiiti vaikimisi pole ehk pool võtab niipalju ruumi kui seal sees infot on. Näiteks kui paneme sinna sisse 100G jagu virtuaalmasinaid siis storagest võtab see kolme koopia puhul ruumi 300GB jagu. Küll on aga võimalik poolile seadistada täiendavalt quota, ehk öelda palju baite või objekte võib ta maksimaalselt sisaldada.
Peale cephi paigaldamist on olemas juba kolm vaikimisi pooli, näiteks rbd nimeline. Neid saab ise juurde tekitada ning igale poolile saab seadistada
- Mitu OSDd võib rikneda, ehk mitu replikat failist hoitakse.
- Placement groups mis määrib ära koormuse ja info jaotuse. Tavaliselt 100tk OSD kohta,
- CRUSH reeglid.
- Snapshotid
- Kasutajaõigused
Olemasolevaid poole näeme käsuga
$ ceph osd lspools 1 testpool,4 ectestpool,
Tekitame uue pooli, selleks käsk
$ ceph osd pool create <my-new-pool> <pg_num>
Näiteks
$ ceph osd pool create testpool 512
Nagu näha on loomisel on vajalik seadistada ka PG ehk placement groupide arv muutujaga pg_num kuna neid automaatselt ei seadistata. NB! Tasub jälgida, et kasutusel oleks realistlik number PG'sid. Infot clustrisse kirjutades mapitakse objektid PGdeks ning need PGd mapitakse omakordad OSDdele. PGde arvu suurendamine aitab hajutada clustri koormust paremini. Aga seda numbrit ei tohi ka ülemäära suureks ajada kuna iga PG napsab õige pisut CPU jõudlust ning mälu OSD kaudu, mis seda endas hoiab. Pg numbrite kohta on selline reegel:
- Vähem kui 5 OSDs süsteemis - pg_num 128
- 5 kuni 10 OSDd pg_num 512
- 10 kuni 50 OSD'd pg_num 2096
- Rohkem kui 50 OSD korral tasub pg_num arvutada ise. Soovitatav valem on võtta iga OSD kohta sada PG'd ning jagada
saadud arv replica numbriga (osd pool default size). Ehk siis 200 OSD deemoni ja pool default size= 3 korral tuleks see arv umbkaudu 4400. (100*200)/3=333. Saadud tulemuse juures on soovitatud ametlikul lehel veel järgnevat "The result should be rounded up to the nearest power of two". Ehk siis tulemus võiks lõpuks olla 8192.
Tähele tuleb aga panna seda, et 8192 tuleb panna pooli PGde arvuks kui kogu cephi peal on vaid üks pool mis kasutab 100% kettast. Kui on plaan tekitada kaks või kolm pooli, millest iga kasutab võrdselt ühe kolmandiku cephi mahust, tuleks see saadud arv jagada veel omakorda kolmega. Ehk siis PG-de arv on terve clustri ülene. See kokkuvõtteks teeb kogu PG-de arvutamise üsna kohmakaks ja samas ka oluliseks.
PS: Katsetused näitasid, et vastupidiselt ametlikele soovitusele tundub 128 PGd ühe pooli kohta nelja nodelises ja 12 OSD sisaldavas clustris andvat täiesti rahuldava kiiruse. Rohkem PGsid kippus näiteks DD kirjutamiskiirust alla tõmbama (testitud sai samas 1M suuruste blokkidega kirjutamist). Ilmselt vajab täiendavat katsetamist.
Selleks, et vaadata palju pooli pg_num on seadistatud
# ceph osd pool get kettaimidzad pg_num pg_num: 8
Nende seadistamiseks nt poolil rbd tuleb anda käsk
# ceph osd pool set kettaimidzad pg_num 128 # ceph osd pool set kettaimidzad pgp_num 128
Tähele tasub panna, et pg-de arvu hiljem vähendada ei saa, ainult suurendada.
Vaatame replikatsiooni taset
# ceph osd pool get kettaimidzad size size: 3
Seadistame testimiseks pooli replikatsiooniks 2 (Set number of replicas across all nodes)
# ceph osd pool set kettaimidzad size 2 set pool 6 size to 2
Võib seadistada ka muutuja min_size juhuks kui vaja süsteemi kirjutada degraded olekus mil ei jätku replikate jaoks piisavalt resurssi. Ehk kui süsteemis vajalikku replicate arvu tagada ei suudeta, siis kirjutamist ette ei võeta.
# ceph osd pool set kettaimidzad min_size 1
Vaatame statistikat ja poolide liiklust
# ceph osd pool stats pool data id 0 nothing is going on pool metadata id 1 nothing is going on pool rbd id 2 -89/0 objects degraded (-inf%) recovery io 167 MB/s, 41 objects/s pool kettaimidzad id 5 nothing is going on
Kustutamine. Vaikimisi on versioonist 11 poolide kustutamine keelatud, lubamiseks tuleb lisada konfi
mon_allow_pool_delete = false
Kustutamiseks tuleb pooli nimi kirjutada kaks korda ja lisada veel täiendav kinnitus)
ceph osd pool delete rbd rbd --yes-i-really-really-mean-it
Võimalik on ka määrata kasutajaid, mis võivad kasutada ainult teatud poole.
[client.test] key = AQA5XRZRUPvHABAABBkwuCgELluyyXSSYc5Ajw== caps osd = “allow * pool=test, allow * pool=test2” caps mds = “allow” caps mon = “allow *”
Pooli ümebernimetamine on samuti võimalik
# ceph osd pool rename {current-pool-name} {new-pool-name}
NB! rados käsuga saab ka pooli teha aga pole soovitatav, see tekitab pooli mitmete piirangutega.
Proxmoxile/openstackile tuleb iga pool eraldi külge võtta. See üks pool on nt proxmoxile nagu eraldi LVMi viilakas, kuhu siis prox oskab ise rbd kettaid, lvmi viilakate lõikamise analoogsena, tekitada. FC/iSCSIle tavapärast multipathi cephi poolide külgevõtmiseks, seda pole ka otseselt vaja kuna cephi klient ei suhtle ühe kindla kontrolleri IP-ga nagu iscsil vaid kõigi monitoride ja kõigi OSDdega.
Rbd blokkseade
Pooli sisse luuakse omakorda nt rbd kettad. Tekitame sinna näiteks ühe 10 giga suuruse tüki
# rbd create myimage2 --size 10240 --pool kettaimidzad
Ilma --pool võtmeta tekitatakse myimage2 vaikimisi loodud rbd pooli. Suuruse võib anda ka kujul ---size 2T
Selleks, et ketas võetaks opsüsteemile külge
# rbd map myimage2 --id admin --pool kettaimidzad
Failisüsteemi loomine ja külgehaakimine
# mkfs.ext4 /dev/rbd0 # mount /dev/rbd0 /mnt
tekitatud rbd ketaste vaatamiseks (ilma pool parameetrita näidatakse vaid rbd poolis olevat infot)
# rbd -p kettaimidzad list myimage2 myimage3
Mis kettad ühendatud?
# rbd showmapped id pool image snap device 0 kettaimidzad myimage2 - /dev/rbd0 1 kettaimidzad myimage3 - /dev/rbd1
Kliendi poolt lahti haakimiseks
# rbd unmap /dev/rbd0
Eemaldamiseks klustrist (kui pole tegemist default pooliga tuleb -p võtmega öelda ka pool)
# rbd rm myimage2 -p kettaimidzad
Rbd boodil külgevõtmine. Bootskript on olemas ja asub /etc/init.d/rbdmap
# update-rc.d rbdmap defaults
Seejärel tuleb muuta /etc/ceph/rbdmap sisu
# RbdDevice Parameters rbd/mysql id=admin,keyring=/etc/ceph/ceph.client.admin.keyring
Ja lõpuks muuta fstabi
/dev/rbd0 /mnt/mysql-data ext4 defaults,noatime,_netdev 0 0
Kasutatud ruumi vabastamiseks võib aegajalt käivitada fstrim käsu, selleks paistab ei pea isegi eraldi discard võtmega failisüsteemi haakima.
_netdev parameeter annab opsüsteemile teada, et rbd seadet ei tohi mountida enne kui võrk ei tööta.
http://www.sebastien-han.fr/blog/2012/11/15/make-your-rbd-fly-with-flashcache/ cache rbd blokkseadmete töö kiirendamiseks.
Cephfs
Suhtlus kliendi, MDS ja OSD vahel käib lihtsustatult järgnevalt
- Klient saadab Open päringu MDS serverile
- MDS vastab faili inode, faili suuruse jne info
- Klient kirjutab otse OSDle.
Cephfs vajab esiteks metadata serverit MDS, selle paigaldamiseks tuleb anda käsk
ceph-deploy mds create {host-name}[:{daemon-name}
Näiteks
# ceph-deploy mds create ceph1:mds1
Hetkel manuaalide järgi ei ole produktsioonis soovitatav kasutada rohkem kui ühte mds serverit.
Cepfsi saab mountida nii kerneli driveri abil kui üle fuse. Esimesena tuleb paigaldada paketid
# apt-get install ceph-fs-common ceph-fuse
Seejärel tekitame vajaliku pooli ja seadistame muu vajaliku
$ ceph osd pool create cephfs_data <pg_num> $ ceph osd pool create cephfs_metadata <pg_num>
Ja loome failisüsteemi
$ ceph fs new <fs_name> <metadata>
Näiteks
$ ceph fs new cephfs cephfs_metadata cephfs_data
Ligipääsuks võti
# cat ceph.client.admin.keyring [client.admin] key = AfasdfllAALKDKLAKFLJSALKKasfg==
Ja seejärel haagime
# mount -t ceph 192.168.0.1:6789:/ /mnt/mycephfs -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==
Monitori aadresse võib olla mitu nind need tuleb eraldada komaga, kui port pole määratud kasutatakse 6789 vaikimisi.
Või siis fuse abil mountimine:
ceph-fuse -m {ip-address-of-monitor}:6789 ~/mycephfs
Fstabi kaudu mountimiseks /etc/fstab faili kirje
192.168.200.101:6789:/ /srv ceph name=cephfs,secretfile=/etc/ceph/client.cephfs,noatime 0 2
Kasutajad
Tekitame kasutaja mart, kes saab kirjutada ja lugeda pooli nimega zoo
# ceph auth get-or-create client.mart mon 'allow r' osd 'allow rw pool=zoo' [client.moodle] key = akKAKDLKklalsdkjasdAKKlaskdjalksdjAKKK==
Saadud võtme võib salvestada faili ceph.client.mart.keyring ja kasutada cephi käskude juures parameetrina: --keyring=/etc/ceph/ceph.client.mart.keyring
Ligipääsuõiguste vaatamiseks
# ceph auth get client.mart exported keyring for client.mart [client.mart] key = akKAKDLKklalsdkjasdAKKlaskdjalksdjAKKK== caps mon = "allow r" caps osd = "allow rw pool=zoo"
Õiguste muutmiseks
# ceph auth caps client.mart mon 'allow rw' osd 'allow rwx pool=zoo' updated caps for client.mart
Tasub tähele panna, et seejuures kirjutatakse kõik vanad õigused üle.
Kasutaja kustutamine
# ceph auth del client.mart updated
Crushi peenhäälestus
Kui Cephi klient loeb või kirjutab infot siis ühendub ta alati esimese primaarse OSDga aktiivse osdde nimekirjast. Näiteks on primaarseteks 2,3,4 siis valib client osd.2 kasutamiseks. Selleks, et klient ei üritaks ühenduda aeglaste OSD masinatega saab seadistada järgneva käsuga OSD kaalukust.
# ceph osd primary-affinity <osd-id> <weight>
Cephis saab masinaid jagada crush mapis nö rackidesse ehk masinad vaikimisi jaotatakse root harusse, iga masina külge kinnistatakse siis omakorda osd-d aga masinaid saab jagada veel omakorda gruppideks. Neid tüüpe mille alusel jagada on terve rodu
# types type 0 osd type 1 host type 2 chassis type 3 rack type 4 row type 5 pdu type 6 pod type 7 room type 8 datacenter type 9 region type 10 root
Meie ülaltoodud näites on vaikimisi kõik masinad seatud root alla ja kõik aga võimalik on teha ka selline topoloogia
root rack1 data1 data2 data3 rack2 data4 data5 data6
ja seadistada täiendavalt crushis
ruleset-failure-domain=rack
Mis see annab? manual ütleb seda, et antud reegel kindlustab, et kaks andmeblokki pole kunagi paigutatud ühte ja samasse racki.
Ehk siis kui on osd-sid kandvad andmenoded jaotatud kogu ceph peal kahte füüsilisse racki kumbki eraldi füüsilise switchiga siis kui üks switch üles ütleb või kapil vool kaob töötab ceph teoreetiliselt ja hädapäraselt teise poolega edasi. Sest crushi loogika üritab hoida nii, et kummaski kapis on üks koopia andmetest olemas.
Erasure Coding
RAIDi asemel kasutatav, kiiremini taastuv ja vähem kettaruumi vajav liiasussüsteem objektandmemassiivide jaoks.
EC ei oma partial writes funktsionaalsust, seega on selle ette vaja teha writebackiga cache tier. EC pooli peale ei saa luua RBD imaget, v.a. juhul kui see luuakse cachetud EC poolile.
Cachemine on efektiivne juhul, kui enamasti loetakse andmeid, mida just kirjutati. Kuna EC pool suudab RBD imaget kasutada ainult läbi cache, ei ole see suvaliste lugemiste-kirjutamiste tegemiseks efektiivne, kuna tekib lisa vahelüli. ECd soovitatakse Cephiga kasutada, kui chace istub SSDde peal. Sel juhul on jõudluse langus keerlevate ketaste kasutamisega võrreldes tunduvalt väiksem.
Põhimõtted
- n = k + m kus
- k = Mitmesse juppi originaalsed andmed jaotatud on.
- m = Originaalsetele andmejuppidele lisatud lisakoodid. Võib vaadelda kui andmete säilimise usaldusväärsuse taset.
- n = Protsessi läbi tekitatud juppide summa.
Taaste : Taaste toimimiseks on vaja k juppi n juppidest ja seega talub süsteem iga m jupi hävimist.
Usaldusväärsuse tase : Süsteemi talub juppide hävimist kuni m arvuni.
Kodeerimise määr (r) : r = k / n , kus r < 1
Vajaminev maht : 1 / r
Näide 1 : (3,5) Kustutuskood suvalise andmefaili kohta näeks välja järgmine:
n = 5 , k = 3 ja m = 2 ( m = n - k )
Kustutuskoodi valem: 5 = 3 + 2 Seega 2 kodeeritud juppi lisatakse 3 andmejupile et luua 5 juppi, mida hoitakse hajutatult cephi klastris. Vea ilmnemisel on originaalfaili loomiseks vaja 3 juppi 5-st. Seega antud näitel suudab süsteem taluda kahe jupi kadu.
- Kodeerimise määr (r) = 3 / 5 = 0.6 < 1
- Vajaminev maht = 1 / 0.6 = 1.6 times of original file.
Kui originaalfaili suurus on 1GB, on selle cephi klastris kustutuskoodimist kasutades hoiustamiseks (3,5) poolis vaja 1.6GB andmesalvestusmahtu.
EC profiilid
- k - juppide arv milleks andmed jaotatakse. Iga jupp paikneb eraldi OSDl.
- erasure-code-k=<juppide_arv>
Vaikimisi 2
- m - Lisatud koodide(juppide) arv. OSDde arv, mille kaotust võib taluda.
erasure-code-m=<lisajuppide_arv> Vaikeväärtus 1
- plugin - Hetkel on kasutusel jerasure, aga äkki peaks mõtlema GF-complete peale üleminekule. Kuni kaks korda kiirem.
- erasure-code-plugin=<plugina_nimi>
Vaikeväärtus 1
- directory ===> The directory name from where EC plugin library will loaded from. In most of the cases this parameter is automatically added once you define plugin name .The equivalent command line parameter for this is
- erasure-code-directory=<directory_path>
Default value = /usr/lib64/ceph/erasure-code
- ruleset-failure-domain - Veakäitluse skoop. Hea sättida tasemele 'OSD', et saavutada paremad taastevõimalused.
Vaikeväärtus = host
EC profiili loomine
data1 ~ # ceph osd erasure-code-profile set ectest data1 ~ # ceph osd erasure-code-profile ls default ectest
data1 ~ # ceph osd erasure-code-profile get ectest jerasure-per-chunk-alignment=false k=2 m=1 plugin=jerasure ruleset-failure-domain=osd ruleset-root=default technique=reed_sol_van w=4
EC profiili seadistamine
võimalik et tuleb kasutada võtit --force.
Muudame väärtuse k 4ks.
data1 ~ # ceph osd erasure-code-profile set ectest ruleset-failure-domain=osd k=4 m=2 Error EPERM: will not override erasure code profile ectest
data1 ~ # ceph osd erasure-code-profile set ectest ruleset-failure-domain=osd k=4 m=2 --force
data1 ~ # ceph osd erasure-code-profile get ectest directory=/usr/lib64/ceph/erasure-code k=4 m=2 plugin=jerasure ruleset-failure-domain=osd technique=reed_sol_van
EC ceph pooli loomine eelnevalt seadistatud parameetritega
Pooli loomine käib järgnevalt:
ceph osd pool create <Pooli_nimi> <pg_arv> <pg_arv> erasure <EC_profiili_nimi> data1 ~ # ceph osd pool create ECtemppool 128 128 erasure ectest pool 'ECtemppool' created
data1 ~ # rados lspools data metadata rbd ECtemppool
data1 ~ # ceph osd dump | grep -i erasure pool 22 'ECtemppool' erasure size 6 min_size 2 crush_ruleset 1 object_hash rjenkins pg_num 128 pgp_num 128 last_change 2034 owner 0 flags hashpspool stripe_width 4096
Katsetame pooli kirjutamist ja taastet
Loome faili
data1 ~ # echo "dmskaldjska'djskladjka;sdl" > ectest.txt data1 ~ # cat testfile dmskaldjska'djskladjka;sdl
Vaatame, mis meie loodud poolis on. Just loodud faili seal olla ei tohiks. Liigutame selle sinna.
data1 ~ # rados -p ECtemppool ls
data1 ~ # data1 ~ # rados -p ECtemppool put object.1 ectest.txt data1 ~ # rados -p ECtemppool ls object.1
Uurime pgmapi abil, kus faili jupid asuvad.
data1 ~ # ceph osd map ECtemppool object.1 osdmap e1012 pool 'ECtemppool' (2) object 'object.1' -> pg 2.f560f2ec (2.6c) -> up ([15,12,6,13,21,29], p15) acting ([15,12,6,13,21,29], p15)
k=4 ja m=2 määramise tõttu asuvad kokku kuus juppi, igaüks erineval OSDl.
Katses loodud pool suudab taastuda kahe jupi (2 OSD) hävimisest.
Katsetame taastet:
data1 ~ # ceph osd down osd.21 osd.29 marked down osd.21. marked down osd.29. data1 ~ # ceph osd map ECtemppool object.1 osdmap e1034 pool 'ECtemppool' (2) object 'object.1' -> pg 2.f560f2ec (2.6c) -> up ([15,12,6,13,NONE,NONE], p15) acting ([15,12,6,13,NONE,NONE], p15)
data1 ~ # ceph -w cluster 4498e6af-b33b-450a-bc54-bcac90dc69e5 health HEALTH_WARN 1 pgs peering 54 pgs stale monmap e1: 3 mons at {mon1=10.80.0.48:6789/0,mon2=10.80.0.49:6789/0,mon3=10.80.0.50:6789/0} election epoch 78, quorum 0,1,2 mon1,mon2,mon3 osdmap e1043: 39 osds: 37 up, 37 in flags sortbitwise pgmap v209823: 1152 pgs, 2 pools, 3068 GB data, 768 kobjects 9043 GB used, 70076 GB / 79120 GB avail 1096 active+clean 54 stale+active+clean 1 active+clean+scrubbing+deep 1 peering 2016-07-25 13:31:08.590040 mon.0 [INF] pgmap v209822: 1152 pgs: 54 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1096 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:09.591813 mon.0 [INF] osd.29 10.80.0.54:6808/1270 boot 2016-07-25 13:31:09.609586 mon.0 [INF] osdmap e1043: 39 osds: 37 up, 37 in 2016-07-25 13:31:09.645985 mon.0 [INF] pgmap v209823: 1152 pgs: 54 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1096 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:10.744494 mon.0 [INF] osdmap e1044: 39 osds: 37 up, 37 in 2016-07-25 13:31:10.787185 mon.0 [INF] pgmap v209824: 1152 pgs: 54 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1096 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:07.537255 osd.29 [WRN] map e1041 wrongly marked me down 2016-07-25 13:31:11.891079 mon.0 [INF] pgmap v209825: 1152 pgs: 54 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1096 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:12.941188 mon.0 [INF] pgmap v209826: 1152 pgs: 54 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1096 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:13.991767 mon.0 [INF] pgmap v209827: 1152 pgs: 54 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1096 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:15.103604 mon.0 [INF] pgmap v209828: 1152 pgs: 13 stale+active+clean, 1 peering, 1 active+clean+scrubbing+deep, 1137 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:12.332372 osd.21 [INF] 1.2b6 scrub starts 2016-07-25 13:31:12.996763 osd.21 [INF] 1.2b6 scrub ok 2016-07-25 13:31:16.160389 mon.0 [INF] pgmap v209829: 1152 pgs: 1 peering, 1 active+clean+scrubbing+deep, 1150 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:17.279717 mon.0 [INF] pgmap v209830: 1152 pgs: 1 active+clean+scrubbing+deep, 1151 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:24.858209 mon.0 [INF] pgmap v209831: 1152 pgs: 1 active+clean+scrubbing+deep, 1151 active+clean; 3068 GB data, 9043 GB used, 70076 GB / 79120 GB avail 2016-07-25 13:31:20.513659 osd.0 [INF] 1.348 scrub starts 2016-07-25 13:31:21.077522 osd.0 [INF] 1.348 scrub ok
Kiirustestid
Etteruttavalt võib öelda, et cephi puhul tundub (jällegi kohati subjektiivse hinnanguna) olevat kõige suurem kirjutusjõudlus just suurte blokkidega kirjutades ning väikeste failide ja random mustriga on see tunduvalt madalam kui võrk ja raud lubaks.
Integreeritud cephi testimise vahend RADOS bench
# rados bench -p pool 30 write -t 16
Antud käsk toimib 30 sekundit ja kirjutab 16 lõimega. Vaikimisi objektisuurus on 4mb.
Poolist testandmete kustutamine
$ rados -p {pool_name} cleanup --prefix bench
Praktikas suudab tavaline gigabit võrk kirjutada kiirusel 100 MB/sekundis. Rbd blokkseadme kirjutamiskiirust tuleks võrrelda ühe füüsilise ketta random kirjutamisega, et oleks õiglane test. Rbd nimelt kirjutab korraga paljudele erinevatele ketastele, mitte järjest nagu nt DD füüsilisel kettal.
Konkreetse osd kiiruse testimiseks, vaikimisi kirjutab test 1GB andmeid 4MB blokkidena. Tasule täheb ka panna, et tegemist on täiesti lokaalse testiga mille juures ei mõjuta võrgukiirus.
$ ceph tell osd.34 bench { "bytes_written": 1073741824, "blocksize": 4194304, "bytes_per_sec": 32216444 }
Nodede jälgimisel tundub olevat abiks dstat nimeline utiliit
Kiirusetestides tasub meeles pidada, et 4M on tüüpiline stripe ühik. http://dachary.org/loic/ceph-doc/man/8/rbd/#striping Ehk siis RBD hajutatakse 4M kaupa ketastele. Seega annab just see blokisuurus rdd testides kõige parema tulemuse.
Cache tiering
Põhimõtteliselt siis SSD ketastele ehitatud pisike pool mis sünkroniseerib oma sisu hiljem aeglastele ketastele. Manualis öeldakse:
A cache tier provides Ceph Clients with better I/O performance for a subset of the data stored in a backing storage tier. Cache tiering involves creating a pool of relatively fast/expensive storage devices (e.g., solid state drives) configured to act as a cache tier, and a backing pool of either erasure-coded or relatively slower/cheaper devices configured to act as an economical storage tier. The Ceph objecter handles where to place the objects and the tiering agent determines when to flush objects from the cache to the backing storage tier. So the cache tier and the backing storage tier are completely transparent to Ceph clients.
Rohkem lugemist http://ceph.com/docs/master/rados/operations/cache-tiering/?highlight=performance
Jamadega jamamine ja tuunimine
Üks esimesi käske vigade tuvastamiseks oleks
# ceph health detail
OSD staatust saab vaadata käsuga
# ceph daemon osd.9 status { "cluster_fsid": "01fc30bc-1b09-47aa-8332-7a218eef9b53", "osd_fsid": "80c6a422-b2b7-4d5b-bee5-195b749c58e1", "whoami": 9, "state": "booting", "oldest_map": 2053, "newest_map": 2677, "num_pgs": 95 }
Teate clock skew detected on mon.ceph3, mon.ceph4 vastu aitab
mon_clock_drift_allowed = 1
Peale paigaldamist teade HEALTH_WARN too few pgs per osd (12 < min 20)
# ceph osd pool get rbd pg_num pg_num: 64
Tundub, et see number on liiga väike, suurendame
# ceph osd pool set rbd pg_num 512 # ceph osd pool set rbd pgp_num 512
Pudelikaelade paika ajamine. Võib juhtuda, et cephi enda perf testi tehes kukub cur MB/s nulli ja tuleb teade
health HEALTH_WARN 41 requests are blocked > 32 sec
Abiks aegluse tekitajate otsimisel ilmselt käsk
# cat /var/log/ceph/ceph.log | grep 'slow request'| awk '{print $3}' | sort | uniq -c | sort -n 2 osd.10 2 osd.12 2 osd.14 4 osd.7 4 osd.9 6 osd.1 10 osd.8 170 osd.4
http://noahdesu.github.io/2014/01/31/ceph-perf-wtf.html
Kõikide PG'de ülekontrollimiseks sobib käsk
# ceph pg dump | grep -i active | cut -f 1 | while read i; do ceph pg deep-scrub ${i}; done
Cephi haldamiseks võib kirjutada igasuguseid vahvaid skripte näiteks kellaaja paika seadistamiseks
for masin in `cat datanodes.txt | awk '{ print $2 }'`; do
echo $masin
ssh -q "$masin" bash <<-'EOF'
apt-get -y install ntp ntpdate
/etc/init.d/ntp stop
ntpdate 10.40.0.140
/etc/init.d/ntp start
date
EOF
done
Kui tegemist juba keerukama juhtumiga võib ceph.conf failist debugimist juurde keerata
debug ms = 1/5 [mon] debug mon = 20 debug paxos = 1/5 debug auth = 2 [osd] debug osd = 1/5 debug filestore = 1/5 debug journal = 1 debug monc = 5/20
Probleem PG-dega
soovitaks alustada sellest, et teha kindlaks mis OSD peal on need 16 kadunud pg'd. Seejärel ma vaataks need osd'd ehk kettad üle. Kas kettad annavad errorit? kas journali kirjutamine on ok? (on osd journalile eraldi ssd ketas?). Samuti võib neile OSDdele teha restardi (osd deemonitele siis) või isegi tervele nodele. Võibolla on üks osd jäänud imelikku seisu?
Vaadake selleks nt
ceph health detail
Seejärel tehke scrub neile pg'dele
ceph pg scrub {pg-id}
Seejärel proovige
ceph pg repair {katkise pg ID'd järjest}
Kui need ikka ei aita ja nt on kõik need kadunud PG'd ühel kindlal kettal siis võib selle ühe ketta/OSD lihtsalt crushi mapist eemaldada ja vaadata mida crush siis teeb.
Kui ikka mitte kui midagi siis on ilmselt juhtunud selline hull asi, et kuidagi on läinud kaduma PG metadata, selline asi võib juhtuda nt siis kui süsteemis vähe kettaid ja vähe pg'sid ja korraga jookseb mitu masinat kokku. Seejärel on viimane võimalus
ceph pg {pg-id} mark_unfound_lost revert|delete
Aga kui ka see ei aita siis tuleb teha uus pool uute pg'dega ja proovida vana info sinna üle sünkroniseerida.
Ühe jama anatoomia
Näidisjuhtum probleemist ja selle lahenduskäigust.
Kirjutamisel kukkus average MB/s pidevalt nulli ja logis olid teated health HEALTH_WARN 41 requests are blocked > 32 sec
Süüdlane tundus olevat üks osd milles 2.5 terabaidine ketas. Sai see osd eemaldatud ning vead kadusid aga keskmine MB/s kukkus ikkagi nulli. Täpsem monitoorimine tõi ühel nodel, kus töötasid kaks OSDd ketastega sdb ja sdd välja järgmise pildi.
Ehk siis ka teine 2.5 terane ketas (sdd) oli kohutavalt aeglase latentsusega. Peale ka selle ketta eemaldamist kadusid keskmise kirjutamise anomaaliad.
Mis toimus? Kirjutamistel jagatakse Iga OSD peale ühesuurune kogus infot. Kui üks ketas on teistest aeglasem siis peavad kiiremad ootama kuni aeglasem kinnitab, et kirjutamised on toimunud, mistõttu terve clustri töövõimekus langeb. Kui ketast eemaldada ei saa võib vahel aidata ka aeglaste ketaste raskuse vähendamine (weight).
PS: Kettad olid WD green seeria omad tõestades, et green kettad võivad olla küllap head kodukasutajatele aga mitte suurtes süsteemides.
Recovery tuunimine
Kui Ceph liiga usinalt end taastab ja liiklus klastri igapäevategevust segab, on abiks ceph.conf failis, osd alajaotuses määrata osd_recovery_sleep väärtus. See vähendab võrguliiklust märgatavalt, samas tuleb arvestada et taastusprotsess võtab selle võrra kauem.
Alustada võib 0.1-st ja vanema riistvara puhul minna välja 1-ni, kuigi enamasti soovitatakse jääda 0.1 ja 0.5 vahele. Suuremad väärtused aeglustavad taastusprotsessi liialt.
Veidi eksperimente sellel teemal
Kettakatkestuse korral
Mis on cephi puhul suurim hirm? ikkagi ketta või node seiskumine, testime mis juhtub kui nt kaks ketast (rohkem kui meil replikatsioone süsteemis) eemaldada.
Reaalselt tundub, et nt replikatsiooni taseme 2 juures võib seiskuda kas üks node või hävida üks ketas suvalises masinas. Kuna crush üritab hoida nii, et ühte objekti ei replikeeritaks samasse nodesse pole tähtis mitu OSDd seiskub ühe node piires.
Ühe ketta kadu
Ühe ketta eemaldamise peale algas tihe sebimine
pgmap v88842: 320 pgs, 4 pools, 75805 MB data, 47583 objects 114 GB used, 14710 GB / 14882 GB avail 313 active+clean 7 down+peering recovery io 34269 kB/s, 24 objects/s
Otsustasin seepeale märkida teise OSD manuaalselt kadunud hingeks
# ceph osd out osd.11 # ceph osd crush remove osd.11
Algas taas mingi sagimine
pgmap v89053: 320 pgs, 4 pools, 76904 MB data, 48282 objects 120 GB used, 14704 GB / 14882 GB avail 2575/96659 objects degraded (2.664%) 316 active+clean 4 active+recovering recovery io 180 MB/s, 130 objects/s client io 55645 kB/s rd, 492 op/s
Ja sai nagu korda
pgmap v89082: 320 pgs, 4 pools, 76904 MB data, 48282 objects 121 GB used, 14704 GB / 14882 GB avail 320 active+clean client io 203 kB/s rd, 50 op/s
Varemalt kettale loodud 10GB suurust faili luges samuti.
# dd if=suvakas of=/dev/null 21113848+0 records in 21113848+0 records out 10810290176 bytes (11 GB) copied, 9.44596 s, 1.1 GB/s
Mitme ketta, ehk rohkemate ketaste kadu kui replikatsiooni number
Tõmbasin julmalt kaks ketast cephi clustri kahest nodest välja. Mispeale kaks OSDd lõpetasid enga tegevuse.
Kahe ketta kadu kajastus kohe ka staatuses
pgmap v88655: 320 pgs, 4 pools, 76380 MB data, 48151 objects 107 GB used, 15642 GB / 15811 GB avail 7619/96397 objects degraded (7.904%) 29 stale+active+clean 82 active+degraded 8 peering 201 active+clean
Mõni aeg hiljem algas miski parandamine
pgmap v88791: 320 pgs, 4 pools, 76896 MB data, 48280 objects 108 GB used, 12861 GB / 13021 GB avail 359/96653 objects degraded (0.371%) 7 stale+active+clean 289 active+clean 9 incomplete 1 active+recovering 9 active+degraded 5 active+remapped recovery io 91160 kB/s, 45 objects/s
- Degraded - Ceph has not replicated some objects in the placement group the correct number of times yet.
- Incomplete - Ceph detects that a placement group is missing a necessary period of history from its log. If you see this state, report a bug, and try to start any failed OSDs that may contain the needed information.
Tundub, et seda poolikut failisüsteemi saab isegi kasutada
# echo suvakas > faili # cat faili suvakas
Ilmselt saab ka osasid objekte lugeda (mis polnud täielikult kadunud PG'de peal)
Kui nüüd ühtegi neist kahest kettast parandada ei õnnestu on Ilmselt mõistlik katsuda tekitada uus rbd ketas ja pool ning sünkroniseerida kõik kättesaadav info sinna ümber. Proovisin lugeda enne crash kettale kirjutatud 11GB suurust faili aga ei õnnestunud. DD lõpetas sellepeale toimimise.
Ühe node kadu
Crush peaks vaikimisi üritama paigutada objektist tehtud koopiaid selliselt, et nad satuksid alati erinevatel serveritel asuvatesse PGdesse.
pgmap v89103: 320 pgs, 4 pools, 76904 MB data, 48282 objects 117 GB used, 14708 GB / 14882 GB avail 17155/96659 objects degraded (17.748%) 176 active+clean 144 active+degraded
Varemalt kirjutatud faili suudetakse lugeda
# dd if=suvakas of=/dev/null 21113848+0 records in 21113848+0 records out 10810290176 bytes (11 GB) copied, 9.27239 s, 1.2 GB/s
Samuti paistab cluster jäävat kirjutatavaks.
Samal ajal algab taustal PGde ümberpaigutamine
osdmap e208: 12 osds: 9 up, 9 in pgmap v89300: 320 pgs, 4 pools, 77929 MB data, 48538 objects 123 GB used, 12851 GB / 13023 GB avail 320 active+clean recovery io 31987 kB/s, 13 objects/s
Ja süsteem taas töökorras
osdmap e208: 12 osds: 9 up, 9 in pgmap v89305: 320 pgs, 4 pools, 77929 MB data, 48538 objects 123 GB used, 12851 GB / 13023 GB avail 320 active+clean
PG incomplete/Orphan PG
Üks tõsisemaid ja fataalsemaid hädasid mis võib cephi tabada on terve PG täielik riknemine. Põhjuseid võib seal olla palju, näiteks on info küll replikeerituna kahe OSD peal aga mõlemaid tabab fataalne kettarike. Ceph health näitab seljuhul järgnevat pilt
pg 2.56e is stuck inactive for 9608224.300756, current state incomplete, last acting [25,8] pg 2.56e is stuck unclean for 9608224.301460, current state incomplete, last acting [25,8] pg 2.56e is incomplete, acting [25,8]
Mille puhul võib ka märkida pg igavesti kadunuks
# ceph pg 4.7fc mark_unfound_lost revert
Viimases hädas võib õnnetu pg ka uuesti tekitada
# ceph pg force_create_pg 2.56e
Kuid on juhtumeid kus ka ülaltoodud käsud ei aita ning tuleb lõpuks terve pool maha kanda, uuesti luua ja andmed varukoopiatest taastada. Vana infot pole seejuures võimalik samuti kätte saada kuna rbd ketta mountimine lõppeb kerneli paanikaga.
Lingid
Testclustri ehitamine http://ceph.com/docs/master/start/quick-ceph-deploy/
OSD koormuste balanseerimine http://cephnotes.ksperis.com/blog/2013/12/09/ceph-osd-reweight
Veel ühe clustri ehitamine http://www.server-world.info/en/note?os=CentOS_6&p=ceph
Jõudlustestid https://software.intel.com/en-us/blogs/2013/10/25/measure-ceph-rbd-performance-in-a-quantitative-way-part-i
Ilusad skeemid aga võõras keeles http://wiki.zionetrix.net/informatique:systeme:ha:ceph
Veel üks võimalik kombinatsioon http://www.openclouddesign.org/articles/vdi-storage/ceph-highly-scalable-open-source-distributed-file-system
Mõned testid http://www.sebastien-han.fr/blog/2012/08/26/ceph-benchmarks/
Performanci nõuanded http://www.slideshare.net/Inktank_Ceph/ceph-performance
Veel üks asjalik ehitusõpetus http://www.sebastien-han.fr/blog/2012/06/10/introducing-ceph-to-openstack/
Testid raidikaartidega http://ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/
http://www.anchor.com.au/blog/2012/09/a-crash-course-in-ceph/
http://www.jamescoyle.net/how-to/1244-create-a-3-node-ceph-storage-cluster
http://ceph.com/user-story/ceph-from-poc-to-production/ soovitused ja rahul kasutaja
http://www.severalnines.com/blog/how-cluster-liferay-mysql-galera-and-ceph-high-availability-and-performance?page=5 kasulik juhend, tasub uurida.
http://dachary.org/?p=1971 kah hea
Placement Groupide arvutamiseks: https://ceph.com/pgcalc/