Ü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.
- 9108 megtekintés
Hozzászólások
érdekel
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Ceph + proxmox?
http://pve.proxmox.com/wiki/Storage:_Ceph
http://ceph.com/
Esetleg OpenStack, csak állítólag insecure + pilótavizsga kell beállítani...
- A hozzászóláshoz be kell jelentkezni
> 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
- A hozzászóláshoz be kell jelentkezni
2 node "storage" clusterre gondolt és a VIP az a virtual IP, ami mindig az aktív node-nál lenne.
- A hozzászóláshoz be kell jelentkezni
Igen, latom, h arra gondolt, sot le is irta, mire gondolt. Akkor sem szukseges feltetlenul.
tompos
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
ha jól tudom, amennyiben beleírsz direktbe, akkor kezdheted újra S1 S2 felépítését.
-
Debian Squeeze
- A hozzászóláshoz be kell jelentkezni
meg az elejen probaltam, de igazad van kezdhettem ujra.
azota nem kovettem el azt a hibat ujra...
- A hozzászóláshoz be kell jelentkezni
Nyilvan nem egeszseges, ha hujeseget irsz bele, de egyebkent lehetseges. Van pl., h replikacios hibat igy javitanak.
tompos
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
jol latod, az is bajom, hogy a ket storage 1 subneten van, de a kliensek egy masik subneten van.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Ha a nativ klienssel vagy most, akkor nincs is szukseg a floating IP-re.
Mit latsz a logok-ban a kliensen es a szerveren is?
tompos
- A hozzászóláshoz be kell jelentkezni
nem melyedtem bele a logokba, de igy hogy van ucarp nem okoz gondot. nativ klienssel.
most azzal fogok jatszani, hogy megprobalom nfs-el elerni. hatha nagyobb lesz a sebessege. :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
amennyiben külön hálók, akkor a geo-replication lesz a barátod.
Performance gondokra számíts (ssh miatt).
-
Debian Squeeze
- A hozzászóláshoz be kell jelentkezni
az csak akkor, ha a két node van külön alhálón. itt a két node egy alhálón volt csak a kliens eltérőn.
- A hozzászóláshoz be kell jelentkezni
Lenyegtelen, milyen halon vannak. En pl. csinaltam mar olyat is, hogy key kulonbozo datacenterben volt ket node.
tompos
- A hozzászóláshoz be kell jelentkezni
kipróbáltam a statikus route szabályokat és működik vele. Köszönöm...
- A hozzászóláshoz be kell jelentkezni