[Megoldva] GlusterFS gondok

Fórumok

Üdv!

Adott 4 gép, ezek közül 2 (H1 és H2) virtualizálnak és kell hozzájuk közös HA storage.
A maradék 2 gép (S1 és S2) alkotná a HA storage-ot. Ezekben van két-két merevlemez, tükrözve.
H1 és H2 direktbe össze vannak kötve az egyik lábukon (S1:192.168.100.1 és S2:192.168.100.2), és mind a kettőnek van még egy-egy lába 192.168.1.0/24 hálózaton. (S1 nyilt lába 192.168.1.11 és S2 nyílt lába 192.168.1.12)

Szeretném ha a két storage egymás között kommunikálva szinkronizálnának. Illetve, ha az egyik leáll valamiért akkor a kliens automatikusan a másikat érné el. Megoldható ez ebben a felállásban vagy kell hozzá más is (mondjuk hartbeat és VIP?)

Eddigi próbálkozások alkalmával vagy nem tudta felcsatolni a kliens vagy leszakadás esetén nem volt olvasható/írható a felcsatolt rész)
Ez alapján csináltam meg: http://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2…

Kihagytam volna valamit? A kliensnek is azonos hálón kellene lennie mint a Storage-oknak?

ui: igen tudom, hogy jobb volna fizetni rendes storage-ért, de ez van ezt nem kell megvenni. ha lesz már pénz majd veszünk. most azonban erre a felállásra kell valamit kitalálnom.
Köszönöm előre is a válaszokat.

Megoldás, hogy meglegyen későbbre is.
a glusterfs és ifenslave telepítve
S1,S2 -n:

~# apt-get install ucarp nfs-common
~# service glusterfs-server restart

S1 -n:
/etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.2.11
netmask 255.255.255.0
gateway 192.168.2.1
network 192.168.2.0
broadcast 192.168.2.255
ucarp-vid 1
ucarp-vip 192.168.2.10
ucarp-password titok
ucarp-advskew 1
ucarp-advbase 1
ucarp-master yes

iface eth0:ucarp inet static
address 192.168.2.10
netmask 255.255.255.0

auto bond0
iface eth1 inet manual
iface eth2 inet manual

iface bond0 inet static
address 192.168.21.1
netmask 255.255.255.248
broadcast 192.168.21.7
network 192.168.21.0
bond_miimon 100
bond_mode balance-rr
up /sbin/ifenslave bond0 eth1 eth2
down /sbin/ifenslave -d bond0 eth1 eth2

S2 -n:
/etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.2.12
netmask 255.255.255.0
gateway 192.168.2.1
network 192.168.2.0
broadcast 192.168.2.255
ucarp-vid 1
ucarp-vip 192.168.2.10
ucarp-password titok
ucarp-advskew 100
ucarp-advbase 1
ucarp-master no

iface eth0:ucarp inet static
address 192.168.2.10
netmask 255.255.255.0

auto bond0
iface eth1 inet manual
iface eth2 inet manual

iface bond0 inet static
address 192.168.21.2
netmask 255.255.255.248
broadcast 192.168.21.7
network 192.168.21.0
bond_miimon 100
bond_mode balance-rr
up /sbin/ifenslave bond0 eth1 eth2
down /sbin/ifenslave -d bond0 eth1 eth2

S1-en (elég az egyiken):

~# gluster
gluster> peer probe 192.168.21.2
gluster> volume create imagevol replica 2 transport tcp 192.168.21.1:/data/images 192.168.21.2:/data/images
gluster> volume set imagevol auth.allow
gluster> volume imagevol start

kliensen:

~# apt-get install nfs-common
~# ip ro add 192.168.21.1 via 192.168.2.11
~# ip ro add 192.168.21.2 via 192.168.2.12
~# mount -o mountproto=tcp,vers=3 -t nfs 192.168.2.10:imagevol /mnt/glusterfs

természetesen a statikus route szabályokat rögzíteni kell még, csakúgy mint az auto mount-ot az fstab-ba, hogy reboot után is működjenek. :) de ezt már oldja meg mindenki ahogy neki tetszik.

még egyszer köszönöm mindenki hozzászólását.

Hozzászólások

Amikor hasonlóval kísérleteztem, a következőképp oldottam meg:

ucarp-ot használtam a node-ok felcsatolásánál, így ha egyik mirror leszakadt, ott volt a másik.

(remélem segítettem)

-
Debian Squeeze

> A maradék 2 gép (S1 és S2) alkotná a HA storage-ot.

Nem feltetlenul kell kulon VM host node es kulon storage node.
Persze nem artasz vele.

> kell hozzá más is (mondjuk hartbeat és VIP?)

Kell. A VIP nem tudom, micsoda. De vmi failover sw-re szukseged lesz, hacsaknem hasznalod glusterfs fuse-os klienset, de valoszinuleg nem akarsz ilyet csinalni.

tompos

pedig éppen ez volt vele a szándékom. használni a saját kliensét. csakhogy nem működött nálam úgy ahogy gondoltam. (vagyis ha lekapcsoltam az egyiket, akkor megszűnt az elérés)
sajnos nem tudom, hogy miként lehet finomhangolni a glustert, mert amit találtam leírást azok mind faék egyszerűek és látszólag működniük kéne.

Egyelore meg azt sem irtad le, mit csinaltal. Mi allt le? Egyaltalan beallitottad a replikaciot?

Olvass utana, egyelore az lesz a helyzet, h NFS-sel valoszinuleg nagyobb sebesseget fogsz elerni, mint a fuse-os klienssel.
Mas kerdes, h a fuse-os klienssel nincs szukseged (elvileg) a floating IP-re (a virtual ip szerintem vmi egeszen mas...). Viszont ez az, ami neked nem mukodik, amit viszont meg nem mond neked senki, amig visszatartod az informaciokat. Akkor viszont mit szeretnel?:)

tompos

nem tartok én vissza semmit.

beállítottam ahogy fent a linken írták.
csak nekem a szerverek egymással közvetlen kapcsolatban vannak, direkt összekötve bond-al.

most csak ket a két storage node-van képben, mert egyelőre tesztelem a működésüket.
S1.priv és S2.priv a direkbe kötések ip címei. (192.168.222.1 és .2)
S1,S2 switchen ülő lábai 192.168.1.11 és .11

S1-en:
gluster peer probe S2.priv #megvan és látom a listában
gluster volume create datavol S1.priv:/data S2.priv:/data #megvan
gluster volume start datavol #megvan
gluster volume set datavol auth.allow 192.168.1.107 #vagyis a kliens gep ami már switchelt hálón van

a kliensen
mount.glusterfs S1:/datavol /mnt/glusterfs

mount-ra kiadja hogy mountolva van
df-re is.
irok bele, happy vagyok, mert latszik a S-eken.
S1 shutdown.
Kliensen df ... var es var es var...
ls /mnt/glusterfs # sok türelem árán: ...a végpont nincs csatlakoztatva...
na ez a bajom.

nem tudom viszont azt, hogy ha a szerveren datavol mappájába az S1-en beteszek valamit direktbe, akkor nem kéne összeszinkronizálódnia annak az S2-n is?
mert ha kéne akkor ez sem megy úgy ahogy kéne. (ha meg nem kell, akkor ez működik... :) )

előre is kösz

A replikaciot nem allitottad be. Replicated volume-ot kell letrehozni.

Ha jol ertem, az is a bajod, hogy kell-e a gluster networknek es a klienseknek egy azonos halon lenniuk. Erre konkretan nem emlekszem, de mintha az remlene, h gluster eseten ez igy nem lehetseges es/vagy felesleges.
De ha kell is, akkor meg tudod kerulni statikus route szabalyok felvetelevel.

ip ro add s1.belso.ip via s1.kulso.ip
ip ro add s2.belso.ip via s2.kulso.ip

De azt nem tudom, h nyersz-e egyaltalan ezzel vmit. Elso korben nee bonyolitsd, hozza letre 1 db subneten 1 db clustert es azon a subneten csatlakozz a kliensekkel.

tompos

nah megcsinaltam. az egesz egy subneten van. megsem akar ugy mukodni, ahogy szeretnem

volume info all

Volume Name: imagevol
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: 192.168.1.173:/data/images
Brick2: 192.168.1.160:/data/images
Options Reconfigured:
auth.allow: 192.168.1.156

ha leallitom az S1-est (brick1) akkor a kliensen egy ls -l semmit nem ad vissza (meg a shell-t sem) csak var es var.

mount.glusterfs s1:imagevol /mnt/glusterfs

amig elnek a nodeok, addig rendben van minden, szinkronizalnak, de ha leakad az amelyiket mountoltam, megall az elet a kliensen.
(meg nem telepitettem fel floating ip-t)

volt idom jatszani vele.
egy alhalon sikerult osszejatszanom, de csak ucarp-al.

volume create imagevol replica 2 transport tcp s1.sec:/data/images s2:/data/images
volume info all

Volume Name: imagevol
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: s2:/data/images
Brick2: s1:/data/images
Options Reconfigured:
auth.allow: client1

amikor kulon subneten kommunikalnak a serverek egymassal akkor gluster nem mukodik a kliens oldalrol. :(
(ha valaki megis tudna mikent lehet ravenni erre ne fogja vissza magat ... )

a ucarp-hoz innét vettem a leírást http://laurentbel.com/2012/04/04/simple-failover-cluster-on-ubuntu-usin…
szoval egyelore itt tartok. kosz mindenkinek