cephfs - MEGOLDVA

Linux-haladó

Létre szeretnék hozni cephfs-el egy 3 gépből álló klasztert, amin egy mappa mindhárom gépen szinkronban van, írható és olvasható.
Tudom, hogy még nem teljesen stabil a cephfs, de mennie már kellene.

Minden szép és jó addig, ameddig nem próbálom a bemásolt fájlokat visszaolvasni.
Létrehoztam a ceph klasztert, 3 darab egyenként 100 GB-s OSD-vel, létrehoztam 1-1 pool-t a cephfsnek adatnak és metaadatnak, és végül magát a cephfs-t: ceph fs new cephfs cephfs_metadata cephfs_data.
Ezt fstab-ban becsatoltam az /mnt alá, bármit belemásolok, az szépen megjelenik minden gépen (mindhárom gépen be van csatolva az /mnt alá), de ha megnyitom, minden fájl üres.
A rados df parancs szerint a cephfs_data pool üres, oda nem történik írás.

Egy másik furcsaság, hogy egy 1 GB-s fájl másolása esetén kb 300 GB hálózati forgalom megjelenik a két másik gépen, miközben az OSD paraméterei: replicated size 3 min_size 2, ami szerint mindhárom gépen ott kellene legyen az adat.

--- MEGOLDÁS ---

Mivel cephfs-nél ebben a helyzetben jobb megoldásnak tűnt a GlusterFS, és nyitott maradt az a kérdés, hogy egyáltalán megvalósítható-e cephfs-el, ezért GlusterFS-el oldottam meg.

  • 6396 megtekintés

( NagyZ v | 2015. 06. 25., cs – 13:45 )

a cephfst nem hiszem, hogy fel lehet stabilan mountolni olyan gepen, ami akar monitor, akar osd. rbd-t kernelen keresztul biztos nem lehet mappelni, mert erdekes hibak jonnek elo.

probaltad mar masik geprol?

rados CLI-vel tudsz irni a poolra? jogosultsagok rendben vannak (ha cephx-et hasznalsz)?

Ezek a jogosultságok:
client.cephfs
key: ...
caps: [mon] allow r
caps: [osd] allow rwx pool=cephfs_data,cephfs_metadata
A mount megy a kulcsal, és a metadata pool-ba van írás is.
Kipróbálom másik géprő, de ha csak úgy megy, akkor tárgytalan az egész.

Ceph-el meg lehet máshogy oldani, hogy összesen 3 gépet használva, mindhármon be tudjak csatolni valamit, ami írható és olvasható is?

HEALTH_OK-ban van.
A cursh map-et ki tudom exportálni, azt nem tudom, hogy lehet megállapítani, hogy jó-e.
A következő parncsok működnek és jó a kimenetük:
rados lspool
rados df
rados mkpool
ha ezt érted rados CLI alatt.

Azt még nem tudom, hogy tudom megnézni, hogy tudok-e írni adatot a cephfs_data pool-ra, de ha rájövök, megírom.

Igen, minden szép és jó. Így, hogy megadtad az irányt avval, hogy más gépen kell csatolni, lehet össze is jönne, de így jelenleg nem biztos, hogy érdekes a dolog, legalábbis akkor ha máshogy meg tudom oldani az osztott tárolót.

RBD device-al vajon működne?
Ha igen, akkor milyen FS-el?

root@wcl1:/etc/ceph# ceph -s
cluster 31d2c04b-af55-453c-9528-6b72f3721a4b
health HEALTH_OK
monmap e1: 3 mons at {wcl1=188.xx.xx.41:6789/0,wcl2=188.xx.xx.42:6789/0,wcl3=188.xx.xx.43:6789/0}
election epoch 16, quorum 0,1,2 wcl1,wcl2,wcl3
mdsmap e12: 1/1/1 up {0=wcl1=up:active}, 2 up:standby
osdmap e34: 3 osds: 3 up, 3 in
pgmap v554: 272 pgs, 4 pools, 3725 kB data, 21 objects
120 MB used, 284 GB / 284 GB avail
272 active+clean

az a baj, hogy mindenkepp kell 4 gep, mivel a 3 gep egyiken sem tudod az rbd-t mappelni. vagy atallsz 2x-es replikaciora, akkor eleg a 3 gep, de csak ketto vehet reszt a ceph clusterben.

amit sokan csinalnak (en is, vmware reszere): csinalsz egy rbd imaget, felmappeled, mkfs, majd nfs-en kiexportalod. innentol mar mindenki eleri, akinek kell, viszont az NFS failoverrol neked kell gondoskodnod.

Ez a vmware részére dolog hogy néz ki. Már sokat gondolkodtam azon, hogy vmware-hoz létrehozzak egy tárolót, de még nem valósítottam meg.
Kell gondolom 3 storage szerver.
Ezek lehetnek egyben NFS szerverek is, vagy annak kell még min 2 gép, ami csatlakozik ehhez a három backend géphez?

Ha jól képzelem el, és ez az 5 gépes felállás a minimum egy fail over klaszterhez, akkor a 2 NFS szerver egyenként mindhárom tárolóhoz csatlakozik és minden vmware mindkét NFS-hez?

masik lehetoseg (direkt kulon postban irom), hogy berakod KVM ala az apacheokat - a lenyeg, hogy ne egy kernel csinaljon mindent :)

de ebed utan kiprobalom egy teszt rendszeren, mert abban biztos vagyok, hogy RBD-t nem mappelhetsz OSD gepen, de CephFS-re nem talaltam ilyen limitaciot _elvileg_. ebed utan megnezem, es megirom az eredmenyeket.

Igazság szerint egy webklasztert szeretnék összehozni így, de nem "pocsékolnék" rá nagyon sok gépet, mivel annak ellenére, hogy sok weblap van rajta, nagyon kicsi a forgalom.
Létrehoztam egy mariadb galera klasztert, és ez mellé kellene egy fájlrendszer is.
Most két gépen fut az egész mysql replikával, de a weblapok osztva vannak a két gép között, és reboot-kor van egy pici kiesés. Ezt szépen meg lehetne oldani egy ilyen rendszerrel.

Ha jol ertem atfutva a problemadat, szerintem jobban jarsz vmilyen csak usermodban futo megoldassal. Glusterfs, MooseFS vagy akar vmilyen API-n keresztil elerheto megoldas, ha az opcio.
Vagy ha a webalkalmazasok nem irnak, akkor egyszeruen odaszinkronizalod es lesz.

Esetleg ha tenyleg annyira kicsia a forgalom, akkor master-master drbd.

Kezdek én is ilyesmi fele hajlani. A weblapokon írás szinte semmi nincs, inkább csak a frissítések.
Mivel a galera klaszter 3 node-ból áll, 3 gép adott, és ehhez kell fs megoldást is találjak.
Régen drbd-t használtam, de ott elég kényes a split-brain situáció. Ahogy látom a glusterfs is hasonlóan megy, csak egyszerűbb, mivel itt megoldja a szinkronizálást és a fájlrendszert is egyben, ha nem tévedek.

mfs-t tudod mountolni sajat magara, ennek lesz egy olyan elonye, hogyha az adat elerheto a gepen beluli chunkserveren akkor onnan fogja kapni.
cserebe a metadata mastert hibaturore nehez megcsinalni (1.6.x verziot ismerem)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az rsync tudtommal nem tud szinkronban tartani valamit, ami 3 ponton változik. Valahonnan valahova szinkronizál.
Jelenleg pont az a probléma, hogy pár weblapot egyik, párat a másik szerver szolgál ki. Ennek megfelelően azon a szerveren történnek módosítások.
Most az rsync ennek függvényében, hogy mi hol van szinkronizál.
Közben beüzemeltem egy glusterfs-t és úgy tűnik tudja amit akarok.
Mindegy melyik szerveren történik módosítás, az megjelenik a másikon is, és én nem kell avval törődjek, hogy épp hol mit módosítok, az oda kerül ahova kell, illetve ha egy szerver kiesik, akkor az egy másikon simán megy.

Ha ez tényleg ilyen szépen megy, akkor szerintem egyszerűbb lesz a helyzet, mint jelenleg.

A ceph szimpatikus nekem, és ez egy jó helyzet lett volna ahhoz, hogy elkezdjem élesben is használni, és belépő a jövőbeni komolyabb terhelés, és adatmennyiség alatt használathoz.

Ezeket okos atszervezessel meg lehet oldani.

Eloszor is, ha kialakitotok egy deployment folyamatot, akkor a dizajner nem az eles oldalon dolgozik, illetve a WP frissiteseket is elobb kitesztelitek egy, a clustertol fuggetlen rendszeren, majd kitoljatok az eles szerverre. Ezek fix maintenance pontok.

Ugyanez a "helyileg masolunk oda fajlokat, tartalmat, weblapot" cimu problemadra is, alakitsatok ki deployment folyamatokat, mert ami most van, azt jobb helyeken kaosznak hivjak.

Tenyleg no offense, de egy ilyen rendszert nem lehet ugy kezelni, mint a labad mellett duruzsolo webszervert, hozza kell idomulnia a fejlesztesi metodikanak is.
--
Blog | @hron84
Üzemeltető macik

Jó tudni.
A GlusterFS a split-brain lehetőséget leszámítva kényelmesebb, de ha sok gond adódik vele, akkor marad ez tartalékmegoldásnak.
Vagy kiegészítésnek, mivel lehet lesz egy földrajzilag különálló szerver is, ahol már rizikósabb a GlusterFS, igaz ott a sima rsync is lehet megteszi.

( akoscomp | 2015. 06. 29., h – 14:08 )

up
NagyZ felé nyitva maradt egy kérdésem, amire nagyon megköszönném ha írna választ:
Ez a vmware részére dolog hogy néz ki. Már sokat gondolkodtam azon, hogy vmware-hoz létrehozzak egy tárolót, de még nem valósítottam meg.
Kell gondolom 3 storage szerver.
Ezek lehetnek egyben NFS szerverek is, vagy annak kell még min 2 gép, ami csatlakozik ehhez a három backend géphez?

Ha jól képzelem el, és ez az 5 gépes felállás a minimum egy fail over klaszterhez, akkor a 2 NFS szerver egyenként mindhárom tárolóhoz csatlakozik és minden vmware mindkét NFS-hez?

( wyx v | 2015. 06. 29., h – 21:58 )

A cephfs szépen muxik a Linux webklaszterünk alatt, csatolva egyszerre 3 db külső webszerverre (nem pedig a klaszterre magára)...konkurens írás olvasás is megy. Azaz megoldható a dolog, nem kell NFS failover, meg ilyenszörnyűségek...
Egy kicsit trükközni kell az attribútumokkal.

Lásd az egyik mount-ot
10.8.2.80:6789,10.8.2.81:6789,10.8.2.82:6789:/ on /var/www type ceph (0)

A klaszteren:
root@node1:~# rados df
pool name category KB objects clones degraded unfound rd rd KB wr wr KB
.......
webpool - 3488703 9457 0 0 0 1196657 83420674 28478 8102071

A VMware ESXi zárt rendszer, az alá nem lehet CephFS-t csatolni csak NFS-t, ezért kell NFS-en kiajánlani. De erre a célra nem használható a Ceph node maga, hiszen arra nem lehet felcsatolni a CephFS-t. Muszáj fizikai vasra tenni a CephFS->NFS szervert - a redundancia miatt 2-re. Röviden ennyi, hogy mit miért.

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

De, ugye még mindig ott tartunk, hogy a Ceph cluster-ben stabilan csak 1 MDS futhat, ami viszont így spof :/ (én emiatt nem merek még egyelőre cephfs-re átállni)

Teljesítményben mit tud? Mert én egyelőre librbd-vel felcsatolt image-eket használok de így a teljesítmény elég siralmas :(

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Én kvm-el használom kb. így: kvm -> qemu -> librbd. van ssd cache tier is gagyi ssd-ből, így már használható a sebesség de még mindig ráférne egy kis tunning.
Már gondolkoztam rajta, hogy érdemes lenne a ceph tunning/sebesség témakörre külön topkiot nyitni.

--------------------
http://grant-it.com/

Támogatom, mert nálam is ugyanez a felállás, de komoly problémák vannak :/
Fileszerveren (kvm guest, samba3, ~10 data disk rbd image alatta, ~150 user) gyakorlatilag használhatatlan.
Igaz, itt egyelőre csak nyers SATA HDD OSD-k mennek, most van tervben az SSD cache vagy SSD journal (de melyik ad többet?)
Illetve itt jönne be, hogy a data disk-eket nem librbd-n, hanem cephfs-en csatolnám a Samba server alá.

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"