load balancing és cluster megvalósítása két szerveren

 ( corvin | 2007. október 22., hétfő - 8:05 )

Üdv!

A következő probléma miatt fordultam hozzátok:

Adott 2db VMware-s Debian Etch szerver.
A két szerver egy alhálózatba van látják is egymást...
Feltettem a heartbeat csomagot és az LVS-t.
Bekonfigoltam, ipvsadm -L -n parancs látja két szervert és aktivként tünteti fel,tehát az ldirectord is megy rendesen.Amúgy apache megy a két szerveren.

Ami problémám lenne:

- Cluster megy,tehát ha lelövöm az egyik szervert, akkor átveszi a másik,de hol a load balancing?Honnan tudom azt meg, hogy éppen a slave szerver is szolgál?

- Kintről nem látszódik érhető el 80-as porton a VIP, kint alatt a windows-t értem, ping megy kintről is, VMware alatt viszont megy a VIP tehát szolgál a 80-as porton is.
Kintről RIP megy,csak a VIP nem.

- Közös storage hiányában, hogyan tudom összeszinkronizálni az adatokat?
Mit tud a drdb?

Előre is köszönöm, ha kell konfig részlet, akkor azt majd este tudok adni...

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szia!

Én load balance-ra haproxy-t használtam, + ssl végződtetésre stunnel-t. Nagyon jól működik, egyszerű konfigurálni, 10 perc egy szkript, ami megoldja, hogy a virtuális címet felvegye az állva maradt láb, (ez neked a post-od alapján már működik) a heartbeat-et figyeli, szóval tuti.

Egy le nem írható cég le nem írható (publikus) rendszere előtt szolgált, mivel az űberszuper sokmilliós cisco hardware-es load-balancernek van egy hibája, amit azóta sem tudott senki orvosolni. Abban a környezetben a cisco-val összemérhető teljesítményt nyújtott, összehasonlíthatatlanul olcsóbban.

Természetesen továbbra is szoftveres maradt, tehát ha olyan sebességgel lett volna képes a backend kiszolgálni, amilyennel nem, akkor valószínűleg elmaradt volna a hw megoldástól. De az ár/teljesítmény viszonya akkor is sokkal jobb, ha az utolsó legapróbb költséget is hozzászámoljuk. Ja és nem vagyok egy hálózati szakértő, tehát lehet, hogy optimalizálással még sokkal jobb lett volna. (pl router-nek fordított kernel, tcp window size, stb.)

Nekem az adott célra tökéletesen bevált.

Üdv

Karika

Kötött a kezem, diplomamunka lesz...Ebből kell gazdálkodnom, igazából tudja is azt ami nekem kell,csak szükséfem lenne egy tapasztalt segítségére!

Kicsit fogalmi zavarba kerültem,remélem tud rajtam segíteni valaki.
Szerintem az egyszerűbb,ha én leírom, hogy mit szeretnék és valaki majd (talán) útbaigazít.

Két szerverből álló clustert szeretnék létrehozni, amely elosztja a terhelést,

Tehát a két gép ip-je valójában kifele csak egy, viszont a terhelést, pl 50 kérést elosztja a két apache között.Tudom itt az adatokat teljesen szinkornban kell tartani,de az majd egy másik kérdés lesz...DRDB-t nézegettem,de miután kiderült,h az általa szolgáltatott fs-t csak az aktiv node éri el a másik csendeben szinkronizál,így ez nekem valszeg nem lesz ok...Esetleg valami másik ötlet?

Ha jól gondolom, ehhez a felálláshoz "kevés" a heartbeat, mert az nem tudja azt a részt,hogy a két szerver "egy ip-ként fusson", erre való az LVS!-Tévedek?

Tehát itt már bejön az LVS is a képbe...Ha LVS van akkor a heartbeat-nek az aktiv/aktiv változatát kell hasznánlom igaz?Mert, ha nem akkor a passziv node nem fog szolgáltatni, jól gondolom?

Sajnos kicsit el vagyok veszve,pedig töretlenül, próbálkozom,olvasok,fórumozok stb...

Tudna nekem tanácsot adni valaki,aki tapasztalt?

Előre is köszönöm a segítséget

drbd image felmountolva nfs-sel? (es akkor mindket oldal tudja irni, bar IO intenziv dolgokra egy ilyen setupot nem hasznalnek)

Olvastam még 1-2 dologról:

Szóval heartbeat azért,kell hogyha az egyik szerver behal a másik átvegye a szerepét.
Aktiv/aktiv módban kell hogy fussanak, mivel load balancing is lesz.
Tehát van két szerver, azon fut apache, az adatokat rsync-el fogom szinkronizálni.

192.168.1.100 - server1
192.168.1.101 - server2

Ahhoz hogy kintről a két szervert egyként lássuk kell az lvs, persze többek között ez fog majd load balance-olni.

Igy kintről a 192.168.200 as ip-ről érem a webszerver(eket), de én csak egynek fogom látni.

Ha lehal az egyik akkor, a másik viszi tovább,viszont ha megy mindkettő,akkor elosztják a terhelést.

Hogyan tudom azt szimulálni/kipróbálni, hogy az egyik kérést a 192.168.1.100 szolgálta ki, a másikat a 192.168.1.101?Próbáltam, hogy más index.html-t teszek az oldalra,de nem ment mindig a master reagált!

Esetleg ötletek?

Olvastam még a mod_proxy modulról, ami a sessionök miatt lenne jó ötlet...

Kérem segítsen aki képbe van...

Szerintem hogyha a cluster két nodeján más-más tartalom van az úgy nem fog müködni (elvileg nem is kell müködjön.).
Lehet egy megoldás irni egy cgi/perl vagy php scriptet ami egyszerüen az adott node hostnevét vagy ip cimét irja ki a weboldaladra. Igy lehet szemléltetni hogy mikor melyik node vállaszol a kérésedre.

P.S. Úgy utólag ötlött fel bennem: A cluster nem csak akkor osztja a terhelést a nodeok közt ha az egy bizonyos "értéket" meghalad? Csak HP-UX clusterekkel foglalkoztam, és azokon nem használtunk load balancingot, de nekem igy tünik logikusnak.
--
Nem tudom miert jottem, de azt igen hogy miert megyek el.

Igen tartalmat muszály lesz szinkronizálni,de csak statikus tartalom lesz, mivel a munkának nem az a célja,hanem hogy a cluster/load balancing menjen rendesen.

rsync-el fogom a tartalom synce-et megoldani,mivel drdb nekem nem jó!Load balancing, igen bizonyos esetekben csak,de azt hol tudom definiálni?

Esetleg valaki meg tudná erősíteni, hogy az a "koncepicó" amit fentebb írtam,helyes-e vagy sem!?

Ha csak statikus lesz a tartalom, akkor a session-ök mennyiben érdekesek?

Szia!

Ha megnézed a www.linuxvirtualserver.org-on a load balance megvalósítását az ipvs végzi a howto-k szerint. Ez egy kernelben levő LB megvalósítás. Szerintem ez hiányozhat neked.

---- bocsi, közben feltűnt az ipvsadm, előző bekezdés sztornó ----

Amúgy meg nézd meg ezt: http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTO.html#doesnt_work
ezen belül a 7.13-as pont lehet a te barátod.

A session-ök kezelésére a következő megoldásokat ismerem:

1. forrás ip szerint szórom a két szerver között. - Ha táblázatot tartok fenn a forrás ip-k ről, isten memóriája sem elég, tehát maszkolni szokták. Ezzel csak az a baj, hogy nincs rá garancia, hogy a kliensek ip-i 50-50%-ban oszlanak meg a maszk szerint, másrészt azt sem lehet garantálni, hogy egyforma terhelést jelentenek)

2. teszek rá, egyik kérés ide, másik oda. - Ugye nem kell részleteznem, milyen gáz ez a session-ök szempontjából

3. beteszek vmilyen azonosítót egy cookie-ba. Na ennek van szerintem értelme. Én nemes egyszerűséggel bele szoktam tenni egy myserver= 1/2 -t, és ha már van ilyen cookie-ja, akkor küldöm az egyes/kettes szerverhez. Nem baj, ha a session valami emberi időn belül lejár, mert kevésbé csúszhat el a terhelés az egyik szerver felé.

Sajna az IPVS-t nem ismerem, tehát nem tudom megmondani, hogy ezek a módszerek itt is használhatók-e. (tartok tőle hogy nem, mert ehhez a html szinten kell szórni, ez a cucc meg mintha ip szinten szórna)

Ha nem muszáj LVS-t használnod, (a megvan kötve a kezem félek azt jelenti, hogy muszáj) akkor haproxy-ban tudok segíteni, a leírásából gyorsan rájön az ember, hogy mit is kell tenni. Load-balance és failover minden további nélkül megoldható, session persistence-el együtt.

vagy kozos helyen tarolod a sessionoket (rmdbs, memcache, vagy csak session fajlok halozatni megosztason helyezkednek el, ami mindket geprol elerheto)

p.s: latom eleg regi hozzaszolasra valaszoltam, de hatha valakinek segitseg

Tyrael

Olvasd el ezt a leirast, bar mysql-eket rak clusterbe, az 5. oldaltol kezdve vannak azon infok, amik neked is hasznosak lehetnek. Ez defaultbol sulyzott round-robint csinal, s minden realserver azonos sullyal szerepel benne. Igy szepen megy a terheles elosztas. wrr helyett hasznalhatsz masfajta elosztasi meghatarozot.

Értem és köszönöm az eddigi hozzászólásokat...
Esetleg valaki képbe tenne,mert lehet hogy rosszul látok pár dolgot:

Tehát van két virtuális szerver vmware alatt

server1 - 192.168.1.100
server2 - 192.168.1.101

- HEARTBEAT kell nekem, hogy ha az egyik megállna akkor a másik átvegye a resource group-ot.
Mivel nekem load balancing is lesz,ezért akit/aktiv módban fognak futni a szerverek, mivel mindegyik fogja nyújtani ugyanazt az apache szolgáltatást.

- LVS (linuxvurtualserver) fogja nekem nyújtani azt hogy a két szerver, csúnyán fogalmazva 1 ip-n látszódjon ez mondjuk a 192.168.100.200, emelett még load balancingot is fog nyújtani.

- Hogy az adatok szinronba legyen az pedig az rsync-el tudom megoldani...

Nekem ez kell, mivel dinamikus tartalmat nem fogok szolgáltatni (se php,se cgi se semmi), csak a csomagból feltelepített apache!

Ami kérdés:

Jól látom én azt,amit felvázoltam?Ami nem igazán tiszta az az aktiv/aktiv felállás és az LVS loadbalancing szerep.

Mi is valójában a loadbalancing?Tudom azt én LVS esetén szabályozni,h mikor melyik szolgáltasson?Vagy esetleg egy kérést server1, másik kérés server2.

Kb erre lenne szükségem, amiket említettek doksik, olvastam átjártam, és nagyjából megvalósítottam,de a háttér amiket itt említettem és egyéb hiányosságaim vannak!

Milyen LB-t csináltál? Az lvs doksi 3 változatot ír. http://www.linuxvirtualserver.org/how.html

Ha nem tudod, küldd el a konfig fájlokat.

A legjobb, ha elküldöd az ipvsadm kimenetét. Paraméterek nélkül! Ez ugyanis kiírja, hogy melyik szerver milyen portját milyen gépek között osztja, milyen algoritmussal, súlyozással.

pl:

director:/lvs/conf# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn
TCP  192.168.2.110:www rr
  -> 192.168.1.11:www             Masq    1      0          13
  -> 192.168.1.12:www             Masq    1      0          12

mint a kimenetből látod, itt a 192.168.2.110-es ip 80-as (www) portjára érkező kéréseket rr (round-robin) módon osztja a következő 2 szerver között:
192.168.1.11,192.168.1.12
a weight-je mindkettőnek 1, úgyhogy 50-50% az arány. látszik a két gépen levő active és inactive connection-ök száma, illetve az hogy a kérést ip masquerading-al (NAT) juttatja a valódi szerverekre.

Tehát a parancs kimenete nagyjából mindent elmond, amit a rendszeredről tudni szeretnél.

A failover director megvalásításról itt egy kis anyag: http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.localnode.html

Üdv

Karika

Hello Karika,

Vártam már hogy mikor nézel be ide, láttam, hogy aktiv résztvevője voltál/vagy a ha,lvs dolgoknak... Köszönöm szépen!

Szóval nekem valami más van,de hogy mi azt nem egészen tudom:

root@debianmaster:/etc/network# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.8.200:www rr persistent 600
-> debianslave:www Route 1 0 0
-> debianmaster.localdomain:www Local 1 0 0

Valszeg nekem is a NAT-oltal kéne próbálkoznom?
Az ultramonkey-al próbálkoztam előszőr,de az nem ment etch alatt, ezért feltettem csomagból, viszont a konfigot azt hagytam!De nem megy rendesen!

Hogy konkrétan mivel rendelkezem:

2 db WMware szerver, ami naton kapja eleve az ip-t és a két gép valós ip-je

- 192.168.8.100 - debianserver
- 192.168.8.101 - debianmaster

Az LVS pedig 192.168.8.200

Windows alol tudom pingelni a 192.168.8.200-at viszont nem szolgáltat a 80-as porton!Ha az egyik szerveren vagyok, ott persze megy a dolog!
Ha beállítottam a Listen 192.168.8.200:80-at akkor hibával nem indult az apache!

A sysctl fájlom nem tartalmaz semmit, ultramonkey miatt volt ott 1-2 dolog oda nem kell betennem semmit?

ifconfig:

#debianmaster
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.8.100
netmask 255.255.255.0
network 192.168.8.0
broadcast 192.168.8.255
gateway 192.168.8.2
dns-nameservers 192.168.8.2

#debianslave
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.8.101
netmask 255.255.255.0
network 192.168.8.0
broadcast 192.168.8.255
gateway 192.168.8.2
dns-nameservers 192.168.8.2

LVS-t igazából nem is konfigoltam, csak a heartbeatet:

ha.cf
-----

logfacility local0
#keepalive 1
#deadtime 10
#warntime 5
#initdead 120
# serial serialportname ...
#serial /dev/ttyS0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback off
match uname -n
node debianmaster
node debianslave
ping 192.168.8.2 # VMware gateway
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

haresources
-----------

debianmaster \
ldirectord::ldirectord.cf \
LVSSyncDaemonSwap::master \
IPaddr2::192.168.8.200/24/eth0/192.168.8.255

ldirectord.cf
-------------

# Global Directives
checktimeout=10
checkinterval=2
#fallback=127.0.0.1:80
autoreload=yes
#logfile="/var/log/ldirectord.log"
logfile="local0"
quiescent=no

# Virtual Server for HTTP
virtual=192.168.8.200:80
fallback=127.0.0.1:80
real=192.168.8.100:80 gate
real=192.168.8.101:80 gate
service=http
request="ldirector.html"
receive="Working"
scheduler=rr
persistent=600
protocol=tcp
checktype=negotiate

Ennyi lenne az egész.Az apache-hoz nem nyúltam,az alap!
Fentebb olvashattad,h mit szeretnék igazából,de biztonság kedvéért beteszem ide mégegyszer:

- HEARTBEAT kell nekem, hogy ha az egyik megállna akkor a másik átvegye a resource group-ot.
Mivel nekem load balancing is lesz,ezért akit/aktiv módban fognak futni.

- LVS (linuxvurtualserver) fogja nekem nyújtani azt hogy a két szerver, csúnyán fogalmazva 1 ip-n látszódjon ez mondjuk a 192.168.100.200, emelett még load balancingot is fog nyújtani.

- Hogy az adatok szinronba legyen az pedig az rsync-el tudom megoldani...

Nekem ez kell, mivel dinamikus tartalmat nem fogok szolgáltatni (se php,se cgi se semmi), csak a csomagból feltelepített apache!

Jól látom én azt,amit felvázoltam?Ami nem igazán tiszta az az aktiv/aktiv felállás és az LVS loadbalancing szerep.

Kb erre lenne szükségem, amiket említettek doksik, olvastam átjártam, és nagyjából megvalósítottam,de a háttér amiket itt említettem és egyéb hiányosságaim vannak!

Köszönöm előre is, hogy időt szánsz/szántok a problémámra!

szia!

Küldök egy telefonszámot privátban, hívj fel és átbeszéljük.

Egy kicsit lassan megy a csevegés így...

Üdv

Okarika

Javítom, vagy engedélyezd a személyes kapcsolatfelvételt, vagy Te küldj egy telefonszámot, mivel úgy nézem nem engedélyezted. (vagy csak én nem tudom használni a Hup-ot)

Hello!

Esetleg skype/msn vagy vmi más csatorna?

Ilyen szempontból elég konzervatív vagyok, de akár az is megoldható. Nem tudom opensuse alatt melyiket a legegyszerűbb beizzítani. De én még mindig a telefont favorizálom (főleg, mivel nem én fizetem a számlámat)

Ok, én alkalmazkodom!

Előre is köszönöm!Mikor lenne jó neked?Most értem haza munkából, kicsit szét vagyok esve...Esetleg holnap?

Szerintem egy gyors elméleti alapozó ma,
a lényeg holnap.

Jó így?

Ha gondolod küldd el a számod személyes üzenetben, és akkor a cégem fizeti a csevejt.
(katt a felhasználónévre, majd a jobb oldali fülnél tudsz küldeni. Úgy gondolom, ezeket a részleteket már nem a fórumon kéne megbeszélni. Ha megoldottuk a gondodat, az eredményt ide is beküldjük, hátha másnak is segít)

Heartbeat-et nem ismerem. Keepalived-t használjuk, működik vele ugyanaz, amit szeretnél.

Hali!

A heartbeat rendesen megy viszont a következőt írja ki:

datum INFO: IPaddr Resource is stopped
datum INFO: IPaddr Resource is stopped

#Mindkét szerveren

Feltettem a haproxy-t ez a
listen http_proxy 192.168.8.200:80
mode http
balance roundrobin
server web1 192.168.8.100:80 check
server web2 192.168.8.101:80 check

Ez lenne a konfig,de erre pedig ez a hibaüzenet jön:

cannot bind socket for proxy http_proxy. Aborting

Szia a cannot bind legvalószínűbb oka, hogy valaki más fogja a portot. (pl. egy apache) Legegyszerűbben egy netstat -napt|grep :80 deríti ki hogy milyen processz fogja.

Az én fejemben a következő kép van:

1. lépés:

mindkét gépen van egy-egy apache, ami a 8080-as (vagy más, 80-tól különböző) porton figyel.

master gépen beállítunk egy ip alias-t az eth0-on, ez lesz a virtul ip-je az egésznek.

haproxy figyel a virtual ip 80-as porton, és továbbdobja a kéréseket mindkét gép 8080-as portjára.

2. lépés

heartbeat-et felkonfigurálni, hogy ha a masteren nem megy a haproxy, vagy az ip alias, akkor (miután leállította azt ami a kettőből megmaradt) ugyanezeket a másik gépen indítsa el.

Ha ezek megvannak, akkor lehet tovább cizellálni a dolgot, pl ha egy apache leáll, akkor próbáljuk meg automatikusan újra elindítani.

Szia!

Van valami új hír?

A loadbalance-os részt nem teljesen fogom. Ha egy master és egy slave van, ez drbd-nél alap, akkor a két gép között hogy osztod a terhelést? Egyáltalán milyen szolgáltatásokat szeretnél loadbalance-olni? Ha egyszerre kell nagy rendelkezésre állás és loadbalance kell az négy szerver.

Kettővel is meg lehet oldani. LVS Direct Routing-al pl.

Megy két szerveren is a történet!drdb tudtommal nekem azért nem jó,mert aki éppen aktiv az fogja az adatot, erre lenne jó a gpfs :)!
rsyncel fogom megoldani ezt a részét!

Üdv mindenkinek!

Kicsit eltűnem, mert sok volt a munka!
Igen, Karika köszönöm van újdonság!

Minden tökéletesen működik! :)
Annyi, hogy a heartbeat-et lecseréltem keepalived-re mivel a haproxy oldalán is arról beszéltek.
Bekonfigoltam tökéletesen megy!Ha kiveszem a master szervert a "játékból", akkor a slave-re kerül át a virtuális ip és ő viszi tovább, ha visszajön a master akkor ő is bekerül a játékba ismét, és megy a loadbalancing!

Sokat szivtam vele,de hála istennek megy!Most még annyi van hátra, hogy be kell konfigolnom, hogy rsync menjen, aztán egy kis mod_security és remélem rábólintanak a szakdolgozatomra!

Esetleg tudnátok adni linket, ahol a mod_security-ről lehet tanulni?
Előre is köszönöm!

Jaj igen,megy két szervere a cluster és a load-balancing!

Ha a szakdolgozatod nem is, de valami howtot nem akarsz hupwikibe osszedobni a temarol? Eleg bonyolult a tema, es szerintem sok embernek erdekes/ertekes lenne.

Ha megcsinalod, koszi!

Szia!

Örülök, hogy sikerült összehozni.

Ha írsz valamit a dologról, szivesen átnézem.

Üdv

Karika

Ennel jobb tanulasi forrast aligha talalsz modsechez.

Örülök, hogy végre én is tudtam olyan dolgot csinálni, ami mást is érdekel! :)
Természetesen megosztom veletek, amire jutottam!Meg kell írnom még a doksit, mert csak a gyakorlati részével vagyok meg,meg megkérdezem a konzulensemet, mert Ő egy másik történet, és nem akarom, hogy ebből bajom legyen!De mindenképpen felrakom, maximum az időpontot befolyásolja ez!

Alig varjuk....

\o\ |o| /o/

Beszéltem a konzulensemmel...Azt mondta,h most nem nézné jó szemmel,ha feltennék ide akár részletet is,mert onnantól kezdve nem tudom bizonyítani, hogy ki csinálta valójában...Kérdésekben szivesen segítek, de amig nem fogadják el,addig nem tudom feltenni...Jártam már, úgy sajnos, hogy fórumon buktam be dolgot...Amint "felszabadulok" közzéteszem, lehet az egész munkámat,hátha másnak is hasznos lesz, nem nagyon van info ezekről, magyarul meg aztán főleg nincsen

Azóta csak lediplomáztál :P
--
unix -- több, mint kód. filozófia.
Life is feudal

Udv mindenkinek!

Epitettem egy apache2 clustert 3 szerverbol. Egy vegzi a terheles elosztast (mod_proxy,proxy_balancer_module) a masik ketto pedig kiszolgal.

Elviekben a session kezeles (sticky session) megodva.
Ennek ellenere ketszer kell bejelentkezni az adott oldalra.

Ha kozos fajlrendszeren vannak a session fajlok (tehat mindket apache ugyanazokat a fajlokat latja/hasznalja) akkor a problema nem jon elo.

A kerdesem az lenne, hogy szukseges a session fajlokat kozos fajlrendszerre rakni?
Egyik dokumentacio sem irja hogy kellene...
Akkor mit rontok el?

A konfig fajlok a kovetkezok

load balancer

        ProxyRequests Off

        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>

        <Proxy balancer://mycluster>
                BalancerMember http://ha1 route=ha1
                BalancerMember http://ha2 route=ha2
                ProxySet lbmethod=byrequests
        </Proxy>

        ProxyPass /balancer-manager !
        ProxyPass /server-status !
        ProxyPass /server-info !

        ProxyPass / balancer://mycluster/ stickysession=BALANCEID nofailover=Off

        ProxyPassReverse / http://ha1/
        ProxyPassReverse / http://ha2/

ha1,ha2 kiszolgalok

        RewriteEngine On
        RewriteRule .* - [CO=BALANCEID:balancer.proba.hu:.proba.hu]

--
maszili

Szia!

Nekm úgy tűnik, az a baj, hogy mindkét gépen ugyanaz kerül a BALANCEID-ba, így aztán nem tudja, hova kell küldeni.

A session fájlok alatt mit értesz?

Próbáld meg a következőt:
ha1 - RewriteRule .* - [CO=BALANCEID:balancer.ha1:.proba.hu]
ha2 - RewriteRule .* - [CO=BALANCEID:balancer.ha2:.proba.hu]

Üdv

Okarika

(a load balancernek el kell érnie a ha1,ha2 gépeket ha1.proba.hu, ha2.proba.hu néven!)

Veletlenul elirtam :)
A ha1,ha2 konfig fajlokban ugy van ahogy Te is irtad.

ha1

RewriteRule .* - [CO=BALANCEID:balancer.ha1:.proba.hu]

ha2

RewriteRule .* - [CO=BALANCEID:balancer.ha2:.proba.hu]

a load balancernek el kell érnie a ha1,ha2 gépeket ha1.proba.hu, ha2.proba.hu néven!)

Ez is rendben van.

De sajnos tovabbra sem jo.

Session fajlok alatt a php session fajljait ertem.

--
maszili

ez mar php feature, ezt nem fogja szerintem lekezelni neked a load ballancer.
megoldas lehet, ha halozati megosztasra allitod php.ini-bol a session_save_path -ot, ha ahogy fentebb is irtam, ha atallitod a session adatok tarolasi helyet fajlrol adatbazisra (session_save_handler ha jol emlekszem)

Tyrael

Ertem... Akkor nem varialok vele tovabb.

A ket gep kozott szetosztva van egy OCFS es most azon vannak a php session fajlok. Igy mukodni latszik.

Koszi a segitseget!

--
maszili

Nem volna ezzel gond, ha a ugyanaz a session ugyanarra a gépre találna a következő kérésnél. Ezért volna fontos a jól beállított loadbalancer. Szerintem most ez nem igaz.

sajnos a proxy_load_balancer-rel nem vagyok barátságban, az egyéb http load balancerek erre beállítanak egy cookie-t, amikor beesik valamelyik szerverre és később e szerint dobják tovább. Szerintem ez a BALANCEID, de a szintaxis nekem kicsit homályos...

ez jol hangzik.

Tyrael

Eddig akarhany dokumantaciot talaltam a neten mindenutt elinteztek ennyivel.

Ezert csodalkozom hogy miert kell meg ezek utan kozos fajlrendszeren tartani a php session fajlokat. Ami azert nem szerencses mert plusz terhelest jelent a szervereknek.

--
maszili

Ki lehetne mazsolázni mi történik, ha a load balanceren futtatnál egy tcpdump-ot.

Amúgy az apache mod_proxy helyett én is tudom ajánlani a haproxy-t, pofonegyszerű és nagyon működik.

(anno Corvin kollégát is én beszéltem rá, előtte a kernel hasonló feature-eivel próbálkozott, ami legalább olyan rosszul dokumentált, mint a mod_proxy)

Üdv

Okarika

U.I: A load balancernek valóban nem kell feltétlenül külön gép. Igaz, ha valamelyik backend gépre teszed, valamennyi plusz terhelést okoz, de szerintem nem vészes.

A load balancernek valóban nem kell feltétlenül külön gép. Igaz, ha valamelyik backend gépre teszed, valamennyi plusz terhelést okoz, de szerintem nem vészes.

Itt most arra gondolsz, hogy a haproxy-val?

Tehat osszesen 2 szerver van...

    * mindketton ugyanazok a szolgaltatasok (apache), haproxy
    * normal uzemben az egyik osztja a kereseket maganak es a masiknak
    * normal uzemben mindketto kiszolgal
    * az egyik meghibasodasa eseten a masik tovabb szolgaltat
    * ha az hibasodik meg ami terhelest oszt el akkor a masikon levo haproxy kezd mukodni
    * ha visszajon az egyik kiesett szerver akkor be lehet rakni a masik melle ujbol

--
maszili

Magam sem tudtam volna jobban összefoglalni.

Ilyenkor tipikusan egy ip alias-on hallgat a haproxy, ha meghal, a másik pillanatok alatt felveszi ugyanazt az ip aliast. Heartbeat-el klasszul meg lehet csinálni. A haproxy leírásában van is rá példa. (már csak a tűzfal/router nem HA, de biztosan arra is van megoldás. Csak ez már nem az én asztalom.)

Okarika

Ilyen felallast egy szerver hotelben is meg lehet jatszani? Ket uplink kell az ISP switch-ebol, de egy IP, s vagy itt van felhuzva vagy a masikon? Mi a helyzet az ISP arp cache-sevel? arp poison?

Az a baj, hogy nekem nem ez volt a problémám. Kiindulásnak olvasd el a haproxy leírását. Abban van egy elég cizellált példa. (a letöltött arhívumban van)

A két gép közé én mindenképpen tennék egy kábelt, hogy a haproxy már belső címekre küldje a kéréseket, és ne kelljen órákig magyarázni a szolgáltatónak, hogy miért kell több ip. (Amit lehet inkább csináljunk meg magunk, a szolgáltató vagy megcsinálja, vagy nem, vagy jól, vagy nem...)

Ok en ertem amit irsz, de nem ez volt a kerdesem. :) Persze legyen natolt halo a haproxyk mogott, az okes. De ket uplink kell az ISP halojabol, ha ket proxy szervert szeretnek (redundans haproxy), de egy publikus IPvel amit atvesznek egymastol a haproxys gepek, ha lehal az egyikuk. Az ISPknel pedig altalaban normalis switchek vannak, amikben van arp cache, igy ha atveszi a masik gep a cimet, frissiteni kellene az isp arp cache tablajat. Ha jol sejtem.

Nem tudom, valószínűleg igazad van, esetleg nézd meg ezt:
http://haproxy.1wt.eu/download/1.2/doc/architecture.txt - 2. HTTP load-balancing with cookie prefixing and high availability

Amúgy ha jól rémlik simán át lehet egy kártya mac adress-ét állítani... és akkor oldja meg az ethernet. (persze akkor meg a switch mit szól hozzá, de gondolom csak megoldja. Elvégre egy laptopot is rádugnak időnként másik portra.)

Másrészt, ha az arp cache hibázik, mi történik? Szerintem tol egy broadcast-ot, és vígan megy az új mac address-el.
(Ugyanaz mint az előző, csak nem ethernet, hanem ip szinten.)

De az arp-nak, és az ethernet switch-eknek nem vagyok szakértője, úgyhogy ezek csak találgatások.

Üdv

Okarika

erre nem feltétlenül szükséges plusz switch port, elegendő egy bevitt saját switch, aminek az uplinkje megy a ISP-hez, te pedig rádugod a saját két gépedet. plusz egy hibaforrás, ezért érdemes jó minőségű switchet venni :)

Nekem van erre egy működőképes megoldásom!2 szerver alatt építettem meg!

A terheléselosztás a HAProxy végzi, session-t is kezeli gond nélkül, könnyű konfigolni, a magas rendelkezésre állást pedig keepalived-al oldottam meg!

Mindenféleképpen az általad említett programokkal kell megoldanod?

Elfogadták már?

Nem nagyon jött a magyar leírás...

(persze ha még nem fogadták el, akkor nem szóltam.)

Okarika

Hali!

Most van elbírálás alatt...A gond az, hogy idén nem diplomázhatom, mert a matekon elhasaltam... :S
Itt sem az a lényeg sajnos, hogy szakmailag legyen képbe az ember...

Szia!

Privátban sem küldheted el??

sziasztok,

nagyon frankó ez a téma, sokat tanultam belőle,

nos az addig OK, hogy egy szolgáltatónál hogyan tudok HA clustert létrehozni, de
lehetséges különböző szolgáltatónál lerakott gépek LB-ként használata is?

ugye eddig, erről volt szó;
ISP1 - LB1, LB2 ... LBn

és most ez a kérdés;
pl.: ISP1 - LB1; ISP2 - LB2 (különböző IP címekkel)

elnézést, ha nagyon egyszerűen fogalmaztam (többnyire magam miatt ...)

R.

up

Elso korben en azt erzem problemanak, hogy hogyan oldod meg a loadbalancer elhelyezeset? Melyik szolgaltatohoz rakod le? Aztan a global filerendszer (mar ha hasznalod), aztan a szinkron a node-ok kozott!?

-- Soha ne vitatkozz idiotakkal! Lesulyedsz az O szintjukre es legyoznek a rutinjukkal !!! --

1. kérdés: más network-ös LB-k monitorozására nem jó pl.: a heartbeat v. a keepalived?

VRRP (keepalived) csak LAN-on működik.
A heartbeat lehet, hogy route-olható, de minek? Failoverkor hiába veszi át a backup az IP címet, az nem olyan, hogy egyszer itt, másszor ott.

akkor az AKTIV/AKTIV HA-LB csak LAN-on (ua. ISP-n) működik?

Egyszerűen: IGEN.
Bővebben: http://hup.hu/node/46072#comment-508010

Ok.
Szimplán passzív/aktív heartbeat, és nem kell LB, akkor ez így külön LAN.on működhet ... ?!

UP.

WAN failover heartbeat?

Nem túl nyerő ötlet, ha létezik is. VLAN a két ISP között?

--
http://laszlo.co.hu/

Pedig ez kellene ...

Létezik az ISP1-nél HTTP1 kiszolgáló.
ISP2-nél HTTP2 kiszolgáló üzembe kerül.

Hogyan valósítható meg, hogy figyeljék egymást a gépek, és egyik-másik kiesése esetén a PASSIV kiszolgáló elinduljon?

Úgy éreztem erre való heartbeat v. keepalived ...
Javítsatok ki, ha rosszul tudnám (keepalived-t tudom csak ua. LAN-ba jó)

Nem az a probléma, hogy HTTP2 elindul vagy nem indul el. (Ez szerintem heartbeattel megoldható.)

A gond az, hogy a kliensek honnan fogják tudni, hogy HTTP2-höz kell fordulni. Írtam, hogy az gyakorlatilag nem megoldható, hogy egy IP cím 2 külön szolgáltatónál legyen. Tehát az kell, hogy DNS-ből más IP cím oldódjon fel, ha kiesik a HTTP1. Erre valószínűleg létezik okosabb megoldás, mint kiesés esetén kézzel szerkeszteni a zónafile-okat. Sajnos, mivel sosem használtam DNS-alapú loadbalancingot/failovert, ebben nem tudok segíteni.

Persze, ha ezt megoldottad, akkor fontos az is, hogy a beállítások és a tartalom szinkronban legyenek. Erre jópár megoldás létezik, de - ahogy én tudom - egyik sem next-next-finish jellegű dolog. Ilyeneket keresgélj: GFS, GlusterFS, GPFS, DRDB, cluster FS, distributed FS.
(Én a helyedben először megpróbálnám elérni, hogy a fontos dolgok a webszervereken read-only legyenek, és valamilyen master-slave (pl. rsync) megoldással frissítém a statikus tartalmat. Ez jóval egyszerűbb és strapabíróbb, mint elosztott filerendszert csinálni WAN-on.)

Ok. Akkor ez a heartbeat WAN-on téma lezárva.

Más.
Szerinted az megoldható, hogy Round Robin DNS-el (van saját DNS szerverünk) + HTTP2-n slave BIND-al mégiscsak eltudjak érni valami failover-ecskét?

A köztes DNS cache -ek miatt elég kürülményes lehet.
Miért nem kérsz ajánlatot a két szolgáltatótól egy VLAN -ra?

--
http://laszlo.co.hu/

Láttál már ilyet? Én még nem.
A szolgáltatók L3-on szoktak kapcsolódni (mondjuk a BIX-en vagy privát peeringen).
Esetleg L2TP-n lehetne átvinni a VLAN-t... de azért ez nem az igazi (bár innentől már nem értek hozzá). Tartok tőle, hogy még ekkor is, ha az "elsődleges" hálózat (az a hely, ahová a hálózat BGP-vel hirdetve van) leszakad a BIX-ről, akkor a VLAN "másik oldala" sem lesz elérhető.

Esetleg hálózatos szakemberek megerősíthetnének vagy megcáfolhatnának. Tényleg érdekel.

Igazad lehet, nagyon nem mélyűltem el a dologban.
Nem lehetne akkor a két hely között VPN -t kialakítani és mind a két szervernek egy-egy lába a VPN -hez tartozna. Ez is lehetetlen kategória?

--
http://laszlo.co.hu/

VPN-t akármilyen 2 host között tudsz csinálni. Az IP alapú klaszterekhez viszont kell egy olyan "lebegő" IP cím, amit minden terheléselosztó használni tud. Ezen semmit sem segít a VPN.

Értsd meg, hogy egy dolog a monitorozás (él-e a másik?), más dolog a failover (IP cím átvétele). Lehet, hogy az kavar meg, hogy a keepalived és a heartbeat látszólag önállóan elintézi a dolgokat. Ez nem így van.
Monitorozni bárhonnan lehet. IP failovert csak LAN-on lehet csinálni.

Akkor majd meg kellene néznem a SUN -nak a SUN Cluster 3.2 -ben a geocluster részt, hisz ott pont arról van szó, hogy adott két cluster a világ bármely pontján és ha az egyiknek sanyi, akkor a másik átveszi a szerepét és ennek a két clusternak tuti, hogy nem kell egy LAN -on lenniük, de majd olvasok :)

--
http://laszlo.co.hu/

Azért valahogy még is csak lehet:

Idézet:
The Sun Cluster Geographic Edition product provides the following features:
Failure detection of multiple clusters that are geographically separated
Configurable heartbeat monitoring between clusters
Application resource switchover from one cluster to another cluster
Data replication between geographically separated clusters
Secure Sockets Layer (SSL) authentication and encryption for communication between nodes or clusters
Configurable IPsec security for data replication between clusters and for heartbeat communication between clusters
Ability to automatically run a script when a heartbeat-loss notification is issued

Több időm jelenleg nincs, hogy részletesen áttanulmányozzam, hogyan is valósítható ez meg, de itt a link.
--
http://laszlo.co.hu/

Igen. Ha nincsenek user session-ök, akkor akár azt is megteheted, hogy a két DNS szerver fixen különböző válaszokat ad (mindegyik szerver a saját IP-jére oldja fel a nevet). És akkor össze-vissza lesznek dobálva a kliensek a 2 szerver között. Az ugyanis nem determinisztikus, hogy a DNS rezolverek melyik autoritatív szervert kérdezik.
Ha vannak session-ök, akkor ezt inkább ne csináld, esetleg replikáld a session-öket.

Lehetséges, hogy van olyan eszköz, amivel automatikusan módosítható a zóna akkor, ha nem érhető el egy szerver. Nekem még sosem kellett ilyesmi.

Attól függ, mit akarsz.

IP szintű load balancert nem igazán rakhatsz két ISP-hez. Ha mégis ez a feladat, akkor kell egy olyan IP tartomány, amit önállóan tudsz valamilyen routing protokollal hirdetni (pl. BGP). Ilyenkor megteheted, hogy az elsődleges load balancer kiesése esetén a backup route átveszi a forgalmat. (Megj.: ez igazából sokkal bonyolultabb, mint ahogy leírtam. Szinte biztos, hogy nem ez kell neked.)

Csinálhatsz DNS alapú terheléselosztást, ennek minden előnyével (pl. egyszerű) és hátrányával (nem igazán dinamikus, azaz hibára lassan reagál).

Ha elegendő egy helyen load balancer, akkor LVS + TUN, és a real servereket szét tudod szórni a világban.

Vagy elmész az akamai-hoz, hátradőlsz a főnöki masszázsfotelben és szívod tovább a havannai szivart... ;)

Amennyire én tudom, olcsón nem tudod magad függetleníteni az egyes ISP datacenterek rendelkezésre (nem-)állásától.

Körvonalazódik...

Legyen 2 ISP. Valahol pedig egy HQ (Head Quarter).
A HQ a 2 ISP-vel külön-külön bérelt vonallal csatlakozik, plusz redundancia, hogy a bérelt vonalak médiája pl.: földi és mikró.

A HQ saját AS-el, IP range-el, BGP router-rel rendelkezik.
Az HQ AS "felhője" belelóg vmelyik ISP-hez (mindegy melyikbe), mivel továbbra is itt lesznek a kiszolgálók.

Ez így műszakilag teljesen OK.

Csak ne feledkezz meg a többoldali árambetáplálásról és a klímáról sem! Meg a hálózati eszközök tartalékolásáról. Magyarul építesz egy redundáns hálózati bekötésű adatközpontot.

IMHO ez túlzás egyetlen klaszterért. Sokkal olcsóbban kijön ugyanez egy többé-kevésbé megbízhatónak tekintett adatközpontban. De ti tudjátok.

Kicsit a temaba vag: distributed FS. Tetszik a glusterfs, de van par kerdesem, amire egyelore nem talaltam valaszt a leirasokban.

Atolvastam a 3 server + 1 kliens howtot, ebbol nekem az jott le, hogy minden kliensen fel kell sorolnom az osszes kulonbozo remote-host-u servert, megosztasonkent, majd a vegen unifybe kell fogni oket. (glusterfs-client.vol) Ez azt jelenti, hogy ha bekerul egy uj node, akkor ezt a kliens konfigot mindenhol modositani kell, es szukseg van egy umount/mount-ra? Es mi lesz akkor, ha egy node elhal? Olyankor mi tortenik?

Ha jol lattam az on-the-fly atmeretezes a roadmap szerint 1.4-es verzioban jelenik meg.

Koszi.

Hali!

Kaptam pár levelet azzal kapcsolatban, hogy jó lenne, ha megosztanám a szakdolgozatomat ill. egy részét. Úgy látszik a dolog lassan révbe ér, mert június közepén lesz az államvizsgám, utánna már azt kezdek a munkámmal, amit szeretnék!
Mivel sok ötletet, tanácsot kaptam innen (kifejezetten Karikától | köszönöm még1x) így június végén, megosztom veletek az anyagot!

Biztosan lesz benne kifogásolható rész, de tanulni mindenképpen jó lesz belőle/fejlődni is, mert van 1-2 ötletem ezzel kapcsolatban, amit csak fejben tudok elképzelni...

Szóval kb. 1 hónap és közzéteszem - Ez mégsem olyan hosszú idő, mint várni a Duke Forever-re :D

Üdv.

Remélem sikerült a szakvizsga. Ha befejezted a Duke-ozást, akkor oszd meg velünk az anyagot, ha lehet.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Szia corvin!

Látom a kapcsolatfelvétel még le van tiltva nálad.
Kiváncsi lennék a dolgozatra én is, ha már publikus.

Előre is kösz.

Üdv,
aty

+1, engem is érdekelne. Köszi.

Sziasztok!

Látom corvin megérdemelt pihenését tölti:)

Addig is ha valakit érdekel a téma:
HAProxy+Heartbeat: http://www.howtoforge.com/high-availability-load-balancer-haproxy-heartbeat-debian-etch
HAProxy+Keepalive: http://www.howtoforge.com/haproxy_loadbalancer_debian_etch

Ennek a mintájára, bármilyen ügyeskedés nélkül elkészíthető két gépes környezetben is a topicban vázolt load balancing megoldás.

FS-szintű szinkronizálásra pedig ajánlom a drbd-t. Képes dual-primary módban is működni, és úgy látom eléggé pörög a projekt német precizitással:
http://www.drbd.org/home/what-is-drbd/

Engem is érdekelne az anyag...

Azért egy 5 és fél éves topicot felhozni ....
A konkrétan feletted levő howtoforde-os link nem volt elegendő?

up

+1
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

subscribe

sub