https lodbalance sticky routing cookie alapján [Felfüggesztve]

Web, mail, IRC, IM, hálózatok

Sziasztok,
valakinek tapasztalata nyílt (free?) szoftverrel ami tudja https loadbalance-ot cookie alapuló sticky session-nel?

Esetleg működő példán bemutatva...

TamsA

  • 8494 megtekintés

( Vizibirka | 2013. 11. 12., k – 14:47 )

Akad tapasztalat.
Ami ilyet tud: apache2, nginx

hát, figy, nem egy szinten vannak.

ha cookie, vagy bármi ami a forgalomban magában van alapján akarsz dönteni, fel kell dolgoznod a forgalmat, így layer 7-es alkalmazás kell. Nginx, lighttpd, varnish, meg még tonnaszám van ilyen program amivel ezt meg lehet tenni.

ldirectord csak a hálózati forgalmat figyeli, layer 4-5ben, az csak annyit tud, hogy ilyen ip ilyen port, és azt vagy routolja tovább vagy natolja, beállítástól függően. de abba a csomagba aztán akkor akármi lehet, nem foglalkozik vele.

( Mcsiv v | 2013. 11. 12., k – 17:25 )

haproxy?

// Happy debugging, suckers
#define true (rand() > 10)

használok 1.4-es ágat éles rendszerben (nagyon nagy terhelés mellett) és eddig teljesen stabil és megbízható. 1.5 ágat saját szerveremen használom, ha belefér az időnkénti downtime hogy frissíts, akkor szerintem jó barátok lehettek:)

// Happy debugging, suckers
#define true (rand() > 10)

( tamsa | 2013. 11. 12., k – 21:32 )

off on
Imádom amikor a xarul tervezett rendszert kell pikk pakk ingyé működő képessé tenni.

off off

Pound >> jónak tűnik
apache2 >> ilyet csináltam már, de pont attól tartok hogy elfogynak az erőforrások alóla
ngnix >> nem használtam még... de attól tartok apache2-höz hasonló
haproxy >> dev (1.5) ág jónak tűnik

oracle webcache >> értek hozzá / stabil / kicsit pazarlós/ de fizetős

Majd beszámolok ...

Webcache-t felejtsd el, szálkezelést tekintve ipari hulladék, sok szopással, gyatra konfigurációs lehetőségekkel, és csúnya hack-ekkel.

HaProxy kell neked, de nem értem, miért mondod, hogy csak a dev ág jó neked. Hasonlót csináltam már az 1.3-as ágon is emlékeim szerint.

És miért fontos neked, hogy maga a LB bontsa az SSL-t?
Évekkel ezelőtt valósítottam meg az általad vágyott megoldást, egy stunnel-lel a haproxy előtt. Tökéletesen működött.

A haproxy ssl moduljának igazából annyi plusz értelme van, hogy SSL session alapján tudsz sticky-t csinálni.

Ha alacsonyabb hálózati réteg szintjén megy a forgalom továbbítás akkor saját nyilvántartás szerint dolgozik a haproxy. Megjegyzi, hogy melyik kliens melyik backend szerverhez tartozik. 


TCP mode
--------
In this mode, the service relays TCP connections as soon as they're established,
towards one or several servers. No processing is done on the stream. It's only
an association of source(addr:port) -> destination(addr:port). To use this mode,
you must specify 'mode tcp' in the 'listen' section. This is the default mode.

Example :
---------
    listen smtp_proxy 0.0.0.0:25
        mode tcp

--
maszili

Nem értelek.

(1) Ha beesik egy új kapcsolat akkor még nincs sesion így a balancer valahogyan eldönti, hogy melyik backend szerver felé továbbítsa a forgalmat.
(2) Az első pontból következik, hogy nem feltétlenül kell session alapján meghatározni, hogy egy adott kliens forgalmát melyik backend szerver felé kell továbbítani.
(3) Ha bármilyen nyilvántartás szerint sikerül egy már felépített kapcsolat forgalmát következetesen ugyanarra a backend szerverre irányítani akkor nem sérül a session.

Tehát hol a probléma?

--
maszili

Akkor mi alapján?

Erre van a sessionid, vagy szerverid vagy bármi ... de ugye azt nem tudod az iphez kötni .. így http esetén kénytelen vagy vagy POST-ba, vagy GET-be csomagolni paraméterként... POST-ban https alatt utazik, tehát HAPROXY stable nem tudja kicsomagolni, GET+POST együtt meg nem használandó..
hát itt a probléma.

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Próbálj meg elvonatkoztatni a HTTP/HTTPS -től. A haproxy egy általános forgalom irányító rendszer és TCP szintjén is tud hálózati forgalmat továbbítani, ahol nincs semmilyen folyamat azonosító.
Nincs sessionid, nincs szerver azonosító, nincs semmi.

(1) Ha jön egy kliens akkor annak a forgalmát pl. round-robin beirányítja az egyik backend szerverhez. Nem néz bele a hálózati forgalomba mert nem érdekli hogy mi megy benne. (http,https,smtp,stb.)
(2) Az új kapcsolat adatait (kliens IP / backend IP) feljegyzi a saját nyilvántartásába.
(3) Ha újabb kérés érkezik a kliens felől akkor a saját nyilvántartása szerint ugyanarra a szerverre továbbítja így (http/https esetén) session tartó a forgalom továbbítás.

Remélem így már érthető mert ennél jobban már nem tudom elbábozni.

--
maszili

A tipikus ellenpélda, hogy ha a kliens olyan peches, hogy round-robin proxyja van (létezik még ilyen egyáltalán?), vagy egyszerűen csak éppen megváltozik a dinamikus IP címe, akkor elveszítheti a sessionjét, és ezt csak alkalmazás szinten, cookie-val lehet lekezelni.

--

Ha kellően kiheréled az apache2-ot akkor elég sokáig bírja.

Ha ez sem elég akkor gyanúm szerint az nginx is határon lesz.
Esetleg megpróbálhatsz iptables alapú LB-t és mögé teszed az apache2/nginx-et.

*Kiheréled= kikapcsolod az összes olyan modult amit nem használsz.

Mekkora a terhelés (req/sec), hogy szerinted karcsú az apache teljesítménye?

Ez mar nem igaz es igazabol regebbi verzioknal sem volt minden esetben igaz. Ez a bekezdes jol elmagyarazza a valos helyzetet, ami a performance-t illeti (http://en.wikipedia.org/wiki/Apache_HTTP_Server):
The Apache 2.2 series was considered significantly slower than nginx for delivering static pages, although remaining significantly faster for dynamic pages. To address this issue, the Apache version considered by the Apache Foundation as providing high-performance is the multi-threaded version which mixes the use of several processes and several threads per process.[16] This architecture, and the way it was implemented in the Apache 2.4 series, provides for performance equivalent or slightly better than event-based webservers.

Viszont a lenyeg az igazan itt mutatkozik meg (http://blog.coralic.nl/2013/05/12/apache-2-4-vs-nginx-1-4/):
Nginx is supposed to use less resources so I used the “uptime” command before starting the test and right after the test, here are the results (measured only for test: 1000 users, 1000 times):
Server Average load before the test Average load after the test
apache 1,55, 0,33, 0,11 18,74, 9,97, 4,02
apache 0,69, 0,16, 0,05 1,02, 0,77, 0,36

It clearly shows that Nginx uses less CPU than Apache for the same work, the difference is so big you can see it by just looking at the system monitor.

Vagyis szepen latszik, hogy nem szokik a load nginx eseten es kevesebbet zabal kozel ugyanolyan kiszolgalas alatt. Ez csak egy dolgot jelent: van benne meg boven tartalek cpu es savszel szempontbol es jo eselyel az alatta levo hattertar nem volt kepes megfelelo rate-et hozni.

// Happy debugging, suckers
#define true (rand() > 10)

( tamsa | 2013. 11. 14., cs – 11:29 )

Viszont nem terminálhatja el a https kapcsolatot a balancer, mert a https-t meg kell tartani egészen az appserverekig.... ez sajnos követelmény... Ha nem lenne az akkor már az IPS-ben meg tudnánk ezt oldani.

tehát így kell kinézzen:

kliens -https-->balancer --https--->appserv1
|->appserv2
\->appservn

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Ebben az esetben viszont nincs nem használhatsz layer7-es szintű LB-t. Pontosítok nem sok értelme van,még lassabb is lesz.
Performancia szempontjából az csak rossz, ha az LB kibontja az ssl-t majd újra létrehoz egyet a backend szerverek felé.

Mi az amiatt az LB-től is kell az SSL az app szerverekig? Ha azt mondod, hogy van olyan alkalmazásod ami megköveteli és ellenőrzi, hogy a kérés SSL-en jött be, akkor azt mondom, igen, láttam már ilyet és annak sem kellett az SSL az LB-től az appszerverig. Persze az LB-ig volt az SSL. (A félreértések végett nem írtam át a kódját, hogy menjen ssl nélkül!)

Az előző mondatom _biztosan_ csak JAVA-s alkalmazás esetén és TOMCAT/Glassfishben állja meg a helyét.

Félinformációkat dobálsz, és vagdalkozol az "az nekem nem jó, meg amaz se" típusú válaszokkal, de azt nem vagy képes leírni, mi a francért nem opció valami, csak hogy "azt nem lehet".

Miért fontos a https a webszerverig? Meg kell kapja a webszerver a kliens tanúsítványt?
Miért kell megkapja? Ha kell a tanúsítvány bármelyik jellemzője, hátradobhatod a backendnek HTTP headerként.
Ha nem kell, akkor simán megoldod az SSL terminálást az LB-n, majd ugyanúgy mehetsz a backend szerverek felé SSL-en, semmi akadálya. Persze nem tesz jót a teljesítménynek, de valamit valamiért ugye.

Sajnos a köveletményeket nem én írom...
eyebként lehet, h. valamilyen más módon fogom ezt kiváltani ... mert a kövelményben az van, hogy " ...a kommunikáció a teljes folyamat alatt (klienstől a végfelhasználási pontig) rejtjelezve kell történjen..."

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Ez jó, nincs benne, hogy ugyanazzal a protokollal kell, lb-ig https, utána mehet VPN-el, vagy bármilyen tunnel-el, ami egyszerűen megvalósítható, nincs kiírva, hogy nem mehet sima http-n a szerverig. Egyébként ezt úgy is lehet csinálni ha nincs sok belőle(<4), hogy minden appszerverre raksz egy http szervert amik sticky session-el hívják az appszervereket httpn, így a loadbalancer lehet buta majd az apache-ok elintézik, hogy minden mindig jó helyre menjen.

Olyan write only vagy, hogy az már fáj.
Aztán próbáljon az ember segíteni.

Először leírtam, hogy semmitmondó válaszokat adsz, majd feltettem 3 kérdést. Erre megint egy olyan választ adtál, ami leginkább lópikulát sem ér, és csak az egyik kérdésre válaszoltál, félig, azt is véletlenül.

Na mindegy. Ahogy a másik két kolléga is írja: a legjobb, ami történhet, hogy ilyen elvontan fogalmazták meg a követelményt.
A problémád meg van oldva:
kliens ----(HTTPS)----> [ stunnel -----(HTTP)----> haproxy 1.3 ] ----(HTTP over ipsec)----> frontend http szerver

Mivel a haproxy és az stunnel azonos gépen fut, a követelményt teljesítetted.

Ha vetted volna a fáradságot, hogy elolvasd a követelmény specifikációt, akkor magad is rájöttél volna, hogy amit felvázolsz az nettó hülyeség.
Az általad idézett specifikáció szerint "rejtjelezve" kell folynia az adatforgalomnak. Nos, mihamarabb terminálod az ssl-t tehát "kliens -https-->balancer", utána meg olyan rejtjelezési megoldást használsz, amit csak akarsz.

( tamsa | 2013. 11. 24., v – 13:31 )

Nos, köszönöm a válaszokat.
Az hogy milyen megoldás fog 'játszani' azt majd vki eldönti.
Nekem egyebek iránt az szimpatikus, hogy az LB terminálja a kapcsolatot és dedikált titkosított csatornában kommunikál a backend szerverekkel http-n.
Talán így lehet minimális szoftveres erőforrással megoldani. Az biztos, hogy lassabb lesz mint az ldirectord.

Köszönet a hozzászólásokért mindenkinek!

TamsA