Ceph

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 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).

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 on võimeline jagama ja talletama infot kolmel viisil.

1. 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).
2. 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/.
3. 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.

Clustri koostamine

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.

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.

Siin toodi näide veel, et kui kirjutada journal ja data ühele ja samale kettale jaguneb liiklus järgnevalt

Device:             wMB/s
sdb1 - journal      50.11
sdb2 - osd_data     40.25

Ceph OSDs calculate data placement with CRUSH, selleks vajab OSD vähemalt 4 tuuma.

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

Cephi paigaldus Debianile ceph-deploy utiliidiga

Esiteks tuleb paigadada uuem kernel, vanemaga kipub btrfs kernel paanikat kisama, kernel tuleb paigalda kõigile masinatele ühesugune muidu võib erroreid tekkida. Juhul kui btrfsi kasutada ei plaani võib need punktid vahele jätta.

faili /etc/apt/sources.list

deb http://ftp.au.debian.org/debian testing main

ja värske kernel

# apt-get install btrfs-tools linux-image-3.16-2-amd64

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

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

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

vaikimisi tekib xfs seega tuleks näitada btrfs ette võtmega ceph.conf lõppu lisada mõned read, selleks kui meil pole tegu puhaste ketastega vaid neil oli juba varem nt btrfs olemas --overwrite-conf parameeter on ka selle tarbeks

osd mkfs type = btrfs
osd mkfs options btrfs = "-f" 

Ja siis hakkame kettaid ja osd'sid valmistama ehk paigaldame kõigile serveritele OSD (iga ketas nõuab eraldi OSD deemonit)

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

Ja nii kõigile nodedele

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

Statistika

# 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)

Pools

When you first deploy a cluster without creating a pool, Ceph uses the default pools for storing data. A pool provides you with:

1. Resilience: You can set how many OSD are allowed to fail without losing data. For replicated pools, it is the desired number of copies/replicas of an object. A typical configuration stores an object and one additional copy (i.e., size = 2), but you can determine the number of copies/replicas. For erasure coded pools, it is the number of coding chunks (i.e. m=2 in the erasure code profile)
2. Placement Groups: You can set the number of placement groups for the pool. A typical configuration uses approximately 100 placement groups per OSD to provide optimal balancing without using up too many computing resources. When setting up multiple pools, be careful to ensure you set a reasonable number of placement groups for both the pool and the cluster as a whole.
3. CRUSH Rules: When you store data in a pool, a CRUSH ruleset mapped to the pool enables CRUSH to identify a rule for the placement of the object and its replicas (or chunks for erasure coded pools) in your cluster. You can create a custom CRUSH rule for your pool.
4. Snapshots: When you create snapshots with ceph osd pool mksnap, you effectively take a snapshot of a particular pool.
5. Set Ownership: You can set a user ID as the owner of a pool.

pool cephfs tekitamine

rados mkpool cephfs

Set pool replication to 1 (just for testing):

ceph osd pool set cephfs size 1

Pooli sisse luuakse omakorda nt rbd kettad

rbd create {image-name} --size {megabytes} --pool {pool-name}

For example, to create a 1GB image named foo that stores information in a pool named swimmingpool, execute the following:

# rbd create foo --size 1024 --pool swimmingpool

Integreeritud cephi testimise vahend RADOS bench

Benchmark for seconds. The mode can be write, seq, or rand. seq and rand are read benchmarks, either sequential or random. Before running one of the reading benchmarks, run a write benchmark with the –no-cleanup option. The default object size is 4 MB, and the default number of simulated threads (parallel writes) is 16.

Runs a simple throughput benchmark against OSD.N, writing TOTAL_BYTES in write requests of BYTES_PER_WRITE each. By default, the test writes 1 GB in total in 4-MB increments.

ceph tell osd.10 bench

keep in mind the osd bench is entirely a local test — if it says 100MB/s, that means your OSD disk can do 100MB/s, and increasing the network connectivity isn't going to change that.

Praktikas suudab tavaline gigabit võrk kirjutada kiirusel 100 MB/sekundis

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.

   50 MB/sec journal
   50 MB/sec failisüsteem

Btrfs kasutamine hoiab ära selle, et info kirjutamine hakkaks ootama journali kirjutamise taga (journal kirjutatakse alati esimesena), kuid kirjutamisel jagavad nad sellest hoolimata olemasolevat ketta ribalaiust.

7200 RPM kiirusega ketaste ning gigase võrgu puhul tundub mõistlik kasutada 10Gb suurust journalit.

osd journal size = 10000

Võimalus seadistada journal ja data erinevatesse kohtadesse

[default]
osd mount options btrfs = noatime,nodiratime
[osd]
   osd data = /srv/ceph/osd$id
   osd journal = /srv2/ceph/osd$id/journal
   osd journal size = 512

2014 ühest listist "I can confirm, we used to run all our nodes on btrfs and I cannot recommend anyone of doing that at this time. We had problems with deadlocks and very slow performance and even corruption over time all the way up to kernel 3.13, I haven't tried 3.14 but there's some patches mentioning performance and deadlocks."

It heavily fragements over time. Also no kernel backports are available to stable kernels. So which one would you choose?

# ceph --admin-daemon /var/run/ceph/ceph-osd.4.asok config show | grep paral
  "filestore_journal_parallel": "false",

selleks konfi

filestore journal parallel = true

Teate clock skew detected on mon.ceph3, mon.ceph4 vastu aitab

clock drift warn backoff = <Seconds>

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

http://noahdesu.github.io/2014/01/31/ceph-perf-wtf.html

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

Lingid

Testclustri ehitamine http://ceph.com/docs/master/start/quick-ceph-deploy/

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