[MEGOLDVA] LVS és Squid3 virtualizált környezetben

Fórumok

Van egy kicsi kis virtualizált "rendszerem" leginkább tanulás a célja

Egy terheléselosztott proxy-t szeretnék összerakni.

A testpc kliensről a proxy0 -ra mennek a kérések, ami aztán szét osztja roundrobinnal a proxy1 és proxy2 gépekre a kéréseket. A proxy1 és proxy2 gépeken fut a squid3 ezek működnek is, ha ezeket állítom be proxynak akkor megy minden szépen.

Azonban ha proxy0 -t állítom be proxynak akkor nem kapok választ, illetve kapok, csak nem a proxy0 -tól, hanem attól a proxytól ahová az ip_vs tovább adta a kérést.

Az ipvs config proxy0 -n:


root@proxy0:~# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.120.80.250:8080 wrr
  -> 10.120.80.51:8080            Masq    10     0          0         

(Furcsa, hogy bár a proxy2 -t is hozzá adtam a confighoz, az még sincs benne a listában, de ez most mindegy is, mivel a kérések mennek mind a két szerverre.)

Hálózatok a proxy1 -en


root@proxy1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 10.120.80.250/32 brd 10.120.80.250 scope global lo:0
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:88:12:ea brd ff:ff:ff:ff:ff:ff
    inet 10.120.80.51/24 brd 10.120.80.255 scope global eth0
    inet6 fe80::a00:27ff:fe88:12ea/64 scope link 
       valid_lft forever preferred_lft forever

Hálózat a proxy2 -n


root@proxy2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 10.120.80.250/32 brd 10.120.80.250 scope global lo:0
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:4d:52:11 brd ff:ff:ff:ff:ff:ff
    inet 10.120.80.52/24 brd 10.120.80.255 scope global eth0
    inet6 fe80::a00:27ff:fe4d:5211/64 scope link 
       valid_lft forever preferred_lft forever

Végül egy kis tcpdump és test a testpc -ről


15:03:22.804949 IP (tos 0x0, ttl 64, id 30705, offset 0, flags [DF], proto TCP (6), length 60)
    10.120.80.1.55432 > 10.120.80.250.8080: Flags [S], cksum 0xb619 (incorrect -> 0xd6a8), seq 3257497788, win 29200, options [mss 1460,sackOK,TS val 3216940 ecr 0,nop,wscale 7], length 0
15:03:22.805602 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    10.120.80.51.8080 > 10.120.80.1.55432: Flags [S.], cksum 0x7309 (correct), seq 822206754, ack 3257497789, win 14480, options [mss 1460,sackOK,TS val 35764 ecr 3216940,nop,wscale 4], length 0

test@testpc:~$ env http_proxy='http://10.120.80.250:8080' wget -S -O /dev/null "http://hup.hu/"  
--2015-02-28 15:13:52--  http://hup.hu/
Csatlakozás a következőhöz: 10.120.80.250:8080… 

Aztán ez eltart az idők végezetéig

Szóval a kérdés, hogy mit nem vettem észre, mi hiányzik még?

De különben minden ötletre vevő vagyok

----

Az ARP -táblák kiürítése aka reboot megoldotta a problémát :@

Hozzászólások