Ceph teszt #2

A "Ceph teszt #1" blogomban leírtam, mik voltak az előkészületek a telepítéshez.

Most nézzük magát a klaszter elvi működését röviden. A ceph klaszter lényege az, hogy az ún. osd-k, mint objektumtárolók fogják tárolni az adatainkat, eme tárolók pedig "szét vannak terítve" a node-ok között. Speciális csíkozási technológiát használ alapban a ceph, azaz minden osd-re fog kerülni az adatainkból redundánsan. Ennek a részleteibe ne menjünk bele, sok beállítási lehetőség van, maradjunk az alapbeállításoknál egyelőre. Aztán vannak úgynevezett monitor démonok, amelyek azért felelősek, hogy egymást figyelve megállapítsák, lehalt e a node, vagy valamelyik szolgáltatása. Léteznek még mds-es is, amik viszont a metadata tárolásáért felelnek, itt a rendszer névterére gondolok és a adathozzáférési koordinációra. Eme három démon alapesetben, egy egyszerű klaszternél fusson minden node-on.
A node-ok között szinkronizáció folyik folyamatosan, erre keyring file-okat hoz létre a rendszer, amelyek segítségével titkosított megoldás is működhet. Mind a metadata démon, mind az osd démon kommunikál a többiekkel.

Nagyon kellemes a dolog, ugyanis az osd-knek lehet adni egy blokkeszközt, amit használnak, minden node esetében külön konfigurálhatóan. (Az osd blokkeszköz alá majd a klaszter másolja be az objektumok tartalmát, normál file-ok formájában, nem kell semmi extrára gondolni.)

Nálam a két XCP-s VM alatt az "xvdb" lett ez, az ESX-is VM-nél az "sdb". Ezek külön diszkek voltak, mint korábban említettem, magasabb diszk IO-val. Persze itt lehetőségünk van LVM-et is használni, ennek meg is lehet az értelme (a több osd / node esetben), erre később kitérek. Eme blokkeszközt majd formázni kell manuálisan, itt az ajánlás az XFS, de lehet BTRFS-t is használni (ez nem stabil még), illetve akár EXT4-et is. Rajtunk múlik a döntés. Én a legelsőt választottam.

Rakjuk össze a klasztert. Ha megvannak a klaszter felé néző hálózati lábak, és a node-ok látják egymást, nyert ügyünk van. Mint írtam, 3db node géppel fogunk foglalkozni, mind a hármon el kell végezni a következő lépéseket:

A rendszer tehát: Ubuntu. 13.04beta2 server (ubuntu-13.04-beta2-server-i386.iso)

apt-get install ntp
/etc/init.d/ntp restart
apt-get install ceph ceph-mds xfsprogs

(Itt fontos, hogy az új ubuntu-ban az mds-t külön kell telepíteni, ez a leírásokból nem mindig derül ki!)

Majd hozzuk létre a nem létező konfig file-t:
nano /etc/ceph/ceph.conf
----
; Ceph conf file!
; use semi-colon to put a comment!

[global]
auth supported = cephx
keyring = /etc/ceph/keyring.admin

[mds]
keyring = /etc/ceph/keyring.$name
[mds.0]
host = ceph01
[mds.1]
host = ceph02
[mds.2]
host = ceph03

[osd]
osd data = /mnt/ceph/osd$id
osd journal = /mnt/ceph/osd$id/journal
osd journal size = 512
osd class dir = /usr/lib/rados-classes
keyring = /etc/ceph/keyring.$name

; working with ext4
; filestore xattr use omap = true
osd mkfs type = xfs

; solve rbd data corruption
filestore fiemap = false

[osd.0]
host = ceph01
devs = /dev/xvdb
[osd.1]
host = ceph02
devs = /dev/sdb
[osd.2]
host = ceph03
devs = /dev/xvdb

[mon]
mon data = /mnt/ceph/mon$id
[mon.0]
host = ceph01
mon addr = 172.20.16.80:6789
[mon.1]
host = ceph02
mon addr = 172.20.16.81:6789
[mon.2]
host = ceph03
mon addr = 172.20.16.82:6789
----------

Szintén szeretik kihagyni a leírásokból azt, hogy a default konfigban meg kell adni a "osd mkfs type" paramétert, különben nem lesz jó a dolog.

Hosts file-t bővítsük:

172.20.16.80 ceph01
172.20.16.81 ceph02
172.20.16.82 ceph03

Hozzuk létre az egyes node-okon a következő könyvtárakat:

#1 mkdir -p /mnt/ceph/{osd0,mon0}
#2 mkdir -p /mnt/ceph/{osd1,mon1}
#3 mkdir -p /mnt/ceph/{osd2,mon2}

Fstab bővítése mindenhol a megfelelő eszközökkel:
----------
#1 /dev/xvdb /mnt/ceph/osd0 xfs rw,noexec,nodev,noatime,nodiratime,barrier=0 0 0
#2 /dev/sdb /mnt/ceph/osd1 xfs rw,noexec,nodev,noatime,nodiratime,barrier=0 0 0
#3 /dev/xvdb /mnt/ceph/osd2 xfs rw,noexec,nodev,noatime,nodiratime,barrier=0 0 0

Formázás:

mkfs.xfs -f /dev/xvdb
mount /dev/xvdb
----

A következő lépés az, hogy definiálunk egy "vezérlőt", amely az induláskor elkészíti a klaszter filerendszerét az osd-ken, ez nálam a #1 node lett, ezen létrehozunk egy rsa kulcsot, majd ezt hozzáadjuk a másik két node-hoz.

ssh-keygen -t rsa
scp .ssh/id_rsa.pub ceph02:.ssh/authorized_keys2
scp .ssh/id_rsa.pub ceph03:.ssh/authorized_keys2

Erre azért van szükség, mert a vezérlő node képes az egész klasztert manipulálni ssh parancsokkal, elkerülve a jelszókérést.
(Hozzáteszem, hogy Ubuntu alatt alapban nincs a root felhasználónak jelszava, előtte egy passwd paranccsal ezt hozzuk létre minden node-on, hogy el tudjuk végezni az scp-s másolást root-ként!)

Ezután készítjük el a tényleges klasztert:

cd /etc/ceph
mkcephfs -a -c /etc/ceph/ceph.conf -k ceph.keyring

Nos, ha ez lefut hiba nélkül, szerencsénk van. Sajnos a jelenlegi ubuntu-n hibát ír ki a szkript, azt állítja, hogy nem üres az egyik mon könyvtár. Ennek több oka is lehet, általában egy lock file van ott. A legegyszerűbb kijavítani magát a szkriptet úgy, hogy kikommentezzük a megfelelő részt:

if [ $type = "mon" ]; then
get_conf mon_data "/var/lib/ceph/mon/ceph-$id" "mon data"
# if test -d $mon_data && ! find "$mon_data" -maxdepth 0 -empty | read foo; then
# echo "ERROR: $name mon_data directory $mon_data is not empty."
# echo " Please make sure that it is empty before running mkcephfs."
# exit 1
# fi
$BINDIR/ceph-mon -c $conf --mkfs -i $id --monmap $dir/monmap --osdmap $dir/osdmap -k $dir/keyring.mon
fi

Ezután már lefut a parancs. Ha lefutott, nem kapunk hibajelzést, minden más esetben baj van.

Ezután indítjuk el a klasztert:

/etc/init.d/ceph -a start

A "-a" kapcsoló az összes node-ot jelenti, azaz minden node-ra belép a szkript és elindítja a megfelelő démonokat.
Itt is lehet hiba, ezesetben sajna egyik node nem indul el megfelelően, ilyenkor többnyire az a gond, hogy valamit elkonfiguráltunk vagy nem egyeznek a konfig file-ok a node-okon.
Sajna ezesetben törölni le kell állítani az összes indult node-ot,

/etc/init.d/ceph -a stop

majd törölni a ceph-hez tartozó dolgokat, és újra elkezdeni a mkcephfs parancstól.

Ha a start lefutott, ellenőrizzünk:

ceph -k /etc/ceph/keyring.admin -c /etc/ceph/ceph.conf health
vagy,
ceph -s

Ha HEALTH_OK van, akkor vagyunk partiban. Ez sokesetben eltart pár percig, ha még nem teljesen okés minden, úgyis kiírja a parancs, mi a gondja, vagy éppen hol tart a szinkronizálással.

Most irassuk ki a biztonsági kódot, ami majd kell a mount-oláshoz:

ceph-authtool --print-key /etc/ceph/keyring.admin
AQBTDWRRWC+uGhAAcMDWKjVRxZACLJOBBzK7qw==

Ezzel kész is vagyunk a klaszter részéről. Megyünk a kliensgépre, ahol majd mount-oljuk a filerendszert az előbbi titkos kóddal:

kliens1# mount -t ceph 172.20.16.80:6789,172.20.16.81:6789,172.20.16.82:6789:/ /mnt/cephstorage/ -vv -o name=admin,secret=AQBTDWRRWC+uGhAAcMDWKjVRxZACLJOBBzK7qw==

(Megjegyzem, megy fuse-al is, ezt most nem részletezem.)

Természetesen ez a kliensgép is egy 13.04beta2 ubuntu volt, nem minden kernelben van benne natívan a ceph támogatás. Mint látható, a mount parancsnál mind a három gép monitorját betettem, ezzel biztosítható a failover az egyik node kiesése esetében. Ez ugye a jóöreg NFS-nél nem vóót.
A kliens2# -n is lefuttatható ugyanez a parancs, és mindkét gép konkurensen (RW) eléri ugyanazon adatokat, ez pedig a klaszter filerendszer tulajdonságait mutatja.

Készen is vagyunk. Lehet tesztelni...

A következő blog majd az tapasztalt okosságok első részét fogja bemutatni, addig is jó konfigurálást...

Hozzászólások

nosuid?
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Tipp:
nekunk btrfs jobban bejott, illetve mar most vezessetek be valamilyen conf mgmt rendszert (cfengine, puppet, whatever...)

> definiálunk egy "vezérlőt", amely az induláskor elkészíti a klaszter filerendszerét az osd-ken

Erre csak az indulaskor van szukseg, utana sosem, jol ertem?

10x
tompos

Köszi a beszámolót, engem nagyon érdekelne a folytatás is. köszi!