[Javalist] WildFly több root webapp

[Gábor Garami]

A proxy NEM tesz kulonbseget alkalmazasszerver es alkalmazas kozott. O
egy ip-t meg egy portot lat, hogy mi van mogotte, az a proxyt baromira
nem erdekli. Felcsatlakozik a portra, elkuldi a requestet, ha timeout
van, akkor szamara az a node enkomplette nem el, irrelevans, hogy az
alkalmazas futott timeoutra, az alkalmazasszerver nem bootolt meg fel,
esetleg a halokabelt huztak ki menet kozben, vagy netalan az
alkalmazasszervert hordozo urhajo hiperugrast hajtott vegre. A proxy
csak annyit lat, hogy van valasz vagy nincs valasz (az appszerver
iranyabol jovo gateway timeout == nincs valasz, azt hiszem). Ha nincs
valasz, goto next hop. Es ezt az apache es az nginx is igy csinalja.

De amugy van cooldown (tehat van egy idoszak, amig a hibas node nem
kap kereseket, hogy ne terhelje szenne a proxy - hiszen nem tudhatja,
miert nincs valasz), illetve a legtobb proxynak meg lehet adni, hogy
egy kliens - egy node, vagyis ne akarjon egy klienst ket-harom node-ra
szetdobni.

Ezek mind-mind konfiguralhato opciok, utana kell nezni.

> problemas node-t a forgalombol, illetve a haproxy eleg sok szempont
> alapjan kepes balancolni a node-ok kozt, akar meg a kliens IP alapjan
> is...

Ok... akkor ez a legjobb megoldás, nem kell mod_cluster WildFly elé.
Esetleg majd egyszer írd meg a Red Hat-nak is, hogy tévúton járnak.

Nem. A RedHat valasztott egyfajta megoldast, ami jo - bizonyos
kornyezetekbe. Mivel gozom sincs arrol, hogy mekkora
rendelkezesreallast kell biztositani az erintett rendszernek, igy nem
tudom eldonteni, hogy a mod_cluster jo vagy nemjo megoldas. Elvben
ugyanis peldaul az apache frontend az SPOF ebben a rendszerben, de ha
ez belefer, akkor meg lehet jo megoldas. Ha nem fer bele, akkor hiaba
a mod_cluster, mindenkepp kell ele (vagy az apache, vagy az appszerver
ele) egy haproxy + keepalived, mert ezek jobban el tudjak kezelni a
terheleselosztast, mint az apache barmikor, raadasul gyorsabban. Olyan
helyen, ahol nagyon magas (sokkilences) rendelkezesre allasra van
igeny, ezt erdemes preferalni az apache helyett.

Again, sehol nem mondtam, hogy a RedHat megoldasa rossz megoldas,
ennekokan irni sem ohajtok nekik. Alapvetoen minden megoldas jo, ami
mukodokepes konfigot eredmenyez. Azt mondtam, hogy ha tobbre van
szukseg, nagyobb rendelkezesre allasra, gyorsabb reakciora, vagy
nagyon finomhangolhato terheleselosztasra, akkor van olyan megoldas,
ami kifejezetten erre van kitalalva, es nem egy webszerver
felokositva. Projektje es kornyezete hatarozza meg, hogy mikor mi a
jo, mikor mit erdemes valasztani.


Garami Gábor
E-mail: gabor.garami at hron.me
Tel: +36 20 235 9621
MSN: hrgy at vipmail.hu
Skype: hron84


2014-06-25 10:55 GMT+02:00  <auth.gabor at javaforum.hu>:
>> "Esetleg nem ad rá kérést, ha a node válaszol, csak az alkalmazás nem?"
>
> Egyszerű: az alkalmazásszerver él, de egy alkalmazás nem. Két node esetén
> mi lesz a minta?
> * 200-200-200-200 - egy node válaszol, ahol él az alkalmazás
> * 200-503-200-503 - két node válaszol és felváltva hibát kap a felhasználó?
>
>> Az nginx - es egyebkent az apache is - gepnevet meg portot lat. Az
>> nginx-nel ha jol tudom, meg lehet adni per node a timeout ertekeket,
>> ha addig nem jon meg a response, akkor a masik node-dal probalkozik,
>> es elvben ki is ejti az adott node-t egy idore. De egeszen reszletes
>> doksija van az nginx-nek erdemes utanaolvasni.
>>
>> A haproxy/keepalived azert jo megoldas, ha extrem fontos a magas
>> rendelkezesre allas, mert az (a keepalived) kepes akar az egyik gep
>> IP-jet kompleten atrakni a masikra, igy kvazi tokeletesen kiejtve a
>> problemas node-t a forgalombol, illetve a haproxy eleg sok szempont
>> alapjan kepes balancolni a node-ok kozt, akar meg a kliens IP alapjan
>> is...
>
> Ok... akkor ez a legjobb megoldás, nem kell mod_cluster WildFly elé.
> Esetleg majd egyszer írd meg a Red Hat-nak is, hogy tévúton járnak.
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist