Lehekülje Ceph lähteteksti vaatamine

===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"

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

[[Pilt:Ceph Architecture1.gif]]

'''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

[[Pilt:Poolig.png]]

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.

[[Pilt:Ceph-skeem.png]]

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

[[Pilt:Ceph-topo.jpg]]

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.

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 ära selle, et info kirjutamine hakkaks ootama journali kirjutamise taga (journal kirjutatakse alati esimesena), kuid kirjutamisel jagavad nad sellest hoolimata olemasolevat ketta ribalaiust.

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.

[[Pilt:Ceph Architecture2.gif]]

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.

[[Pilt:CEPH-net.png]]

Näites on kasutatud cephi versiooni 0.80.6.

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

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)

 mon_initial_members = ceph3, ceph6, ceph2
 mon_host = 10.0.0,10.0.0.22,10.0.0.11
 auth_cluster_required = cephx
 auth_service_required = cephx
 auth_client_required = cephx
 filestore_xattr_use_omap = true


Seda tuleks täiendada järgneva osaga. 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

 # 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]
    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
 
 [client]
     rbd cache = true
     rbd cache writethrough until flush = true
     #admin socket = /var/run/ceph/rbd-client-$pid.asok

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.

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

 $ ceph osd tree | grep osd.13
 13  3                   osd.13  up  1   

Teeme muutmise 3 pealt 2 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
Logida nodesse ja panna osd seisma.
 # ceph osd rm 5

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

 [osd]
    osd data = /srv/ceph/osd$id
    osd journal = /srv2/ceph/osd$id/journal
    osd journal size = 10000

Kui on soov 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

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 käsk

 # ceph-deploy admin ceph-client


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

===Cephi paigaldus käsitsi ilma deploy utiliidita===

Mõningail erandjuhtudel võib olla soov mitte kasutada ceph-deploy mehanismi, näiteks on vajadus skriptida kogu cephi clustri ehitamiseks oma töövahend. Selleks siis juhend kuidas hakkama saada kui deployd pole.

'''Võtmete loomine'''

meil vaja kahte võtit. Esimene võti mille tekitame monitoridele

 ceph-authtool --create-keyring /etc/ceph/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'

Teiseks admin.keyring

 ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-uid=0 --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow'
 ceph-authtool /etc/ceph/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring

kopeerime mõlemad võtmed kõigile hostidele

 scp ceph.mon.keyring ceph.client.admin.keyring mon1:/etc/ceph
 ...

'''Monitori loomine'''

OSD ja MDS serverid kasutavad ceph.conf faili, et saada teada mis on MON serverid. Kuid
mon serverid ise vajavad omavahelise quorumi ja selle reeglite süsteemi praxis suhtluse jaoks binaarfaili monmap.

 monmaptool --create --add mon.0 192.168.2.1 --add mon.1 192.168.2.2 --add mon.2 192.168.2.3 --fsid 1798897a-f0c9-422d-86b3-d4933a12c7ac initial-monmap

ja seejärel monmap kõigisse monitoridesse

 scp initial-monmap mon1:/etc/ceph
 scp initial-monmap mon2:/etc/ceph
 scp initial-monmap mon3:/etc/ceph
 ...

Logime mon1 masinasse ja seal käsud

 mkdir -p /var/lib/ceph/mon/ceph-0

ja täidame tekkinud kausta infoga

 ceph-mon --mkfs -i 0 --monmap initial-monmap --keyring ceph.mon.keyring

ja samamoodi kõigis monitorides

'''Osd loomine'''

Ketta ettevalmistamine (kuna ketas ilmselt suurem kui kaks tera kasutame GPT partitsioonitabelit)

 parted --script /dev/sda mklabel gpt
 parted --script /dev/sda mkpart primary btrfs 0% 100%

Kettale GPT patitsioonitabel ja sinna failisüsteem
 
 mkfs.btrfs -L <label> /dev/sda1

näiteks

 mkfs.btrfs -f -L OSD3 /dev/sda1

Kettal olevaid btrfs labeleid saab vaadata käsuga

 # btrfs filesystem show
 Label: 'OSD3'  uuid: 02e79f37-14f6-4a69-adee-764d6641dd53
 	Total devices 1 FS bytes used 141.26GiB
 	devid    1 size 3.64TiB used 144.04GiB path /dev/sdb1
 
 Label: 'OSD4'  uuid: 0a9caf15-6e16-4542-bb6c-092c21bb1c8c
 	Total devices 1 FS bytes used 105.88GiB
 	devid    1 size 3.64TiB used 108.04GiB path /dev/sdc1
 
 Label: 'OSD5'  uuid: 2f065f62-ae16-4343-b9f9-01257d2c67cb
 	Total devices 1 FS bytes used 118.84GiB
 	devid    1 size 3.64TiB used 121.04GiB path /dev/sdd1

 # uuidgen
 fb84a114-e961-4a8d-98a3-0b263c003129

 # ceph osd create fb84a114-e961-4a8d-98a3-0b263c003129
 0

Edasi OSD startimine

 # ceph-osd -i 0 --mkfs --mkkey --osd-uuid fb84a114-e961-4a8d-98a3-0b263c003129
 2014-11-20 14:13:24.790861 7feef17a9780 -1 journal FileJournal::_open: disabling aio for non-block journal.  Use journal_force_aio to force use of aio anyway
 2014-11-20 14:13:25.338929 7feef17a9780 -1 journal FileJournal::_open: disabling aio for non-block journal.  Use journal_force_aio to force use of aio anyway
 2014-11-20 14:13:25.350759 7feef17a9780 -1 filestore(/var/lib/ceph/osd/ceph-0) could not find 23c2fcde/osd_superblock/0//-1 in index: (2) No such file or directory
 2014-11-20 14:13:25.648467 7feef17a9780 -1 created object store /var/lib/ceph/osd/ceph-0 journal /var/lib/ceph/osd/ceph-0/journal for osd.0 fsid e86f3136-90b0-469f-91b5-574e868fb32e
 2014-11-20 14:13:25.648527 7feef17a9780 -1 auth: error reading file: /var/lib/ceph/osd/ceph-0/keyring: can't open /var/lib/ceph/osd/ceph-0/keyring: (2) No such file or directory
 2014-11-20 14:13:25.648605 7feef17a9780 -1 created new key in keyring /var/lib/ceph/osd/ceph-0/keyring

Nagu viimaselt näha reaöt loodi ka cephi masinale unikaalne võti

 # cat /var/lib/ceph/osd/ceph-0/keyring
 [osd.0]
 	key = AQDsds1U3MSnahAAf4NslrVyGqMGeDFcdOpVRg==

Sama võtmefaili kasutame selleks, et lisada loodud osd info monitoride praxise andmebaasi

 # ceph auth add osd.0 osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-0/keyring
 added key for osd.0



 ceph osd crush add osd.0 1.0 host=data1

===Kasutamine===

====Poolid====

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

Tekitame uue pooli

 # rados mkpool kettaimidzad

Pooli 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 10 OSD  deemoni ja pool default size=  3 korral tuleks see arv umbkaudu 333. (100*10)/3=333

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

Seadistame testimiseks pooli replikatsiooniks 2 (Set number of replicas across all nodes)

 # ceph osd pool set kettaimidzad size 2

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 (pooli nimi tuleb kirjutada kaks korda ja lisada veel täiendav kinnitus)

 # rados rmpool failid failid --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 *”

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

 # rbd rm myimage2

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

_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

 # rados mkpool failid
 # ceph osd pool set webdata size 2
 # ceph osd pool set webdata pg_num 128
 # ceph osd pool set webdata pgp_num 128

NB! Uuemas versioonis on ilmselt cepfs failisüsteemi loomine täielikult ümbermuudetud. http://ceph.com/docs/master/cephfs/createfs/

Hangime pooli ID

 $ '''ceph osd dump | grep webdata'''
 pool 5 'webdata' rep size 2 crush_ruleset 0 object_hash rjenkins pg_num 500 pgp_num 500 last_change 12 owner 0

Seome ID mille saime mds serveriga

 $ '''ceph mds add_data_pool 5'''
 added data pool 5 to mdsmap

 # '''cat ceph.client.admin.keyring'''
 [client.admin]
         key = AfasdfllAALKDKLAKFLJSALKKasfg==

Ja seejärel haagime

 # mount -t ceph ceph2,ceph3,ceph4:/ /srv/mds/pools/cephfs_data -o name=admin,secret=AfasdfllAALKDKLAKFLJSALKKasfg==

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

===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>

===Kiirustestid===

Integreeritud cephi testimise vahend RADOS bench

 # rados -p '''pool''' bench 20 write -t 16

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.

Remove the pre-defined metadata file by
    $ rados -p {pool_name} rm benchmark_last_metadata
Cleanup by prefix
    $ rados -p {pool_name} cleanup --prefix bench

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

Nodede jälgimisel tundub olevat abiks '''dstat''' nimeline utiliit

[[Pilt:Dstat.png]]

===Jamadega jamamine ja tuunimine===

Palju aitab tavaliselt käsk

 # ceph health detail

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

Cephi haldamiseks võib kirjutada igasuguseid vahvaid skripte näiteks kellaaja paika seadistamiseks

<source lang=bash>
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
</source>

===Ü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.

[[Pilt:Diskstats latency-day-ceph6.png]]

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 jagatakse sama 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. Aidata võib vahel ka see kui vähendada aeglaste ketaste raskust (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.

===Kettakatkestuse crashtest===

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

===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