hello
A gondom az hogy nem tudom mi a hiba a konfigba. A HAproxy nem ad load balance-t. Minden kérés csak egy webszerverhez megy.
A konfig így nézki:
global
log 127.0.0.1 local0 debug
#log loghost local0 info
chroot /var/lib/haproxy # this option related to socket
stats socket /var/lib/haproxy/stats
defaults
#logformat
# httplog Enable logging of HTTP request, session state and timers
# clf means Common Log Format such as Apache
option http-server-close
option http-pretend-keepalive
option originalto
frontend wt
bind 1.2.3.215:80
backend bck_lb
#balance roundrobin
#balance static-rr
balance leastconn
server web1 1.2.3.208:80 track bck1/web1
server web2 1.2.3.207:80 track bck2/web2
backend bck1
server web1 1.2.3.208:80/index.html cookie A check
backend bck2
server web2 1.2.3.207:80/index.html cookie B check
Próbáltam (ahogy láthatjátok) már roundrobinnal, static-rr meg leastconn de mindig csak a web1 kap mindent.
Valaki látja a hibát? Mert én nem.
Update
Nos a probléma a cookie-k voltak. :) Plusz a leastconn kellett használni.
Update 2
Nos a végleges configot alább találjátok. A nem ad egyensúlyt pedig azt jelentette, hogy nem osztotta el a terhelést a két node között.
global
#log 127.0.0.1 local0 debug
log 127.0.0.1 local0 info
maxconn 4096
#debug
#quiet
chroot /var/lib/haproxy # this option related to socket
user haproxy
group haproxy
stats socket /var/lib/haproxy/stats
defaults
log global
mode http
#logformat
# httplog Enable logging of HTTP request, session state and timers
# clf means Common Log Format such as Apache
option httplog clf
# do not log requests with no data
option dontlognull
# log as soon as the server starts to respond, an do not wait for the
# end of the data transfer.
option logasap
# disable keep-alive
option httpclose
# Enable insertion of the X-Forwarded-For header to requests sent to servers
option forwardfor header x-client
# Ebabke checks
# Enable the SMTP service check
#option smtpchk EHLO example.com
# Enable SSL check - This could be used at server section!!!
#option ssl-hello-chk
# Enable the HTTP service check
option httpchk HEAD /index.html HTTP/1.0
# Enable or disable HTTP connection closing on the server side
option http-server-close
# Define whether haproxy will announce keepalive to the server or not
option http-pretend-keepalive
# Enable insertion of the X-Original-To header to requests sent to servers
option originalto
# retry when a valid connection fails
retries 3
# Enables session redistribution in case of connection failures.
# So session stickness is overriden if a VPS goes down.
option redispatch
maxconn 20000
contimeout 5000
clitimeout 50000
srvtimeout 50000
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
#replace XXXX with customer site name
cookie SERVERID insert indirect nocache
option httpclose
listen test-config 1.2.3.215:80
balance leastconn
server web1 1.2.3.208:80/index.html cookie A check
server web2 1.2.3.207:80/index.html cookie B check
listen ssl_test-config 0.0.0.0:443 #replace with shared public ip
mode tcp
balance source
option ssl-hello-chk
option forwardfor
#replace with web node private ip
server web1 1.2.3.208:443/index.html cookie A check
#replace with web node private ip
server web2 1.2.3.207:443/index.html cookie B check
- 7503 megtekintés
Hozzászólások
Ugye nem egy kliensről teszteled?
- A hozzászóláshoz be kell jelentkezni
ő, de :)
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Hmmm... sticky session?
(esetleg tiltsd le a cookie-k fogadását vagy próbáld két külön browserből!)
- A hozzászóláshoz be kell jelentkezni
A statisztika szerint mindkét kiszolgáló aktív?
--
maszili
- A hozzászóláshoz be kell jelentkezni
+1
Állítsd be a webfelületét, azért van!:)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
melyik webfelületre gondolsz?
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
igen, mind a kettő kiszolgáló aktív.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Most tényleg megnézted a "webes felületen" a statisztikát vagy csak rávágtad az igent? :)
Egy régebbi konfig, hátha segít...
listen all 1.2.3.4:80
maxconn 4096
mode http
stats enable
stats auth admin:123qwe <--- webes felület azonosítása
balance roundrobin
cookie SERVERID insert indirect
option httpclose
option forwardfor
option httpchk HEAD /haproxy_check HTTP/1.0 <---- szolgáltatás ellenőrzés
server ha1 10.0.0.1:80 cookie HA1 check
server ha2 10.0.0.2:80 cookie HA2 check
server ha3 10.0.0.3:80 cookie HA3 check
errorfile 503 /etc/haproxy/errors/503.http
--
maszili
- A hozzászóláshoz be kell jelentkezni
igen, megnéztem. mind a két kiszolgáló aktív és elérhető.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
A módosított config így nézki és még mindig nem az igazi....:
global
log 127.0.0.1 local0 info
maxconn 4096
chroot /var/lib/haproxy # this option related to socket
user haproxy
group haproxy
stats socket /var/lib/haproxy/stats
defaults
log global
mode http
option httplog clf
option dontlognull
option logasap
option httpclose
option forwardfor header x-client
option http-server-close
option http-pretend-keepalive
option originalto
retries 3
option redispatch
maxconn 20000
contimeout 5000
clitimeout 50000
srvtimeout 50000
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
cookie SERVERID insert indirect nocache
option httpclose
frontend wt
bind 10.3.8.215:80
acl web1 url_sub wtd=wt1
acl web2 url_sub wtd=wt2
acl web1_up nbsrv(bck1) gt 0
acl web2_up nbsrv(bck2) gt 0
use_backend bck1 if web1_up web1
use_backend bck2 if web2_up web2
default_backend bck_lb
backend bck_lb
balance roundrobin
#balance static-rr
#balance leastconn
server web1 10.3.8.208:80 track bck1/web1
server web2 10.3.8.20:80 track bck2/web2
backend bck1
balance roundrobin
server web1 10.3.8.208:80/index.html cookie A check
backend bck2
balance roundrobin
server web2 10.3.8.207:80/index.html cookie B check
Az ACL-re gyanakszom.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Nem igazán értem mi a problémád, a "nem az igazi" nem egy hiba jelenség
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
a hiba az, hogy nem load balance-ba adja a kéréseket hanem, minden az egyik node-nak, ha az nem elérhető akkor megy a másikhoz. De a roundrobin nem ez.
A roundrobin az hogy az egyik kérés megy a node1-hez a másik kérés a node2-hoz.
Vagy tévedek?
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Nem, nem tévedsz, de ehhez round robint kéne használni nem? A te konfigod most valami zseniális katyvasz (és nem attól zseniális mert jó, hanem mert egyáltalán elindul vele a haproxy). Te most sticky session-t használsz (round robin segédlettel)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
pontosan mi is az a sticky session?
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Ha rosszul tudom, valaki úgyis kijavít: amikor a session-öd, amit létrehoztál egy web szerverrel, a továbbiakban ragaszkodik fizikailag ahhoz a géphez, amelyikre először kapcsolódtál.
Pl. akkor lehet jelentősége, ha a http session adatait memóriában vagy lokális fájlrendszeren tárolod.
- A hozzászóláshoz be kell jelentkezni
HZ jól írta, lényegében arról van szó, hogy amikor elsőnek találkozik a user a szerverrel, kap egy session cookie-t (ez addig él, míg a böngészője nyitva van), ez alapján a session alapján a haproxy a későbbiekben ugyan ahhoz a szerverhez fogja irányítani a felhasználót. Ezt olyan rendszerekhez találták ki, amik nem voltak felkészítve a széltében skálázódásra, vagy valamilyen technikai oka van annak, hogy a felhasználó ugyan ahhoz a szerverhez jusson. Ezért hívják "sticky"-nek, "odaragasztja" a usert a szerverhez. Ha törlöd a cookie-t, a round robin esélyeivel fogsz új szervert kapni.
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Láttam, de sajnos látni nem mindig elegendő:D
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Csak azon vigyorgok ilyenkor, hogy nem is ismerem a szóban forgó szoftvert, ehhez képest elég jól beletaláltam. :)
- A hozzászóláshoz be kell jelentkezni
Melyik cookie-k?
- A hozzászóláshoz be kell jelentkezni
a kliensen. azt gondolom, mivel a konfigban a szervereknel beallitottam a cookie-t igy az torten, hogy ha a node1 valaszolt nekem, akkor a mindig az valaszolt nekem addig amig az elerheto volt.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Akkor próbálom másképp, mivel nem ismerem ezt a szoftvert: a böngésződbe lerakott cookie-k okozták a gondot, ahogy már az elején említettem, mint tippet vagy maga a HAproxy pakol saját cookie-kat valahova és azok kavartak be?
- A hozzászóláshoz be kell jelentkezni
azt hiszem az elobbi.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
Egy megoldást is írnál?
- A hozzászóláshoz be kell jelentkezni
Ha jól látom user error volt nem konfig. ;)
- A hozzászóláshoz be kell jelentkezni
Szerintem már említettem korábban is, hogy több böngészőből/gépről kellene próbálgatnod. :)
- A hozzászóláshoz be kell jelentkezni
Engem inkább az érdekelne, hogy ez mi a lófasz:
nem ad egyensúlyt
- A hozzászóláshoz be kell jelentkezni