|
On Mon, Aug 28, 2006 at 09:22:19AM +0800, Azhar.Ismail@xxxxxxxxxxxxxxxxxxx
wrote:
>#ipvsadm
>IP Virtual Server version 1.2.0 (size=4096)
>Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
># ipvsadm -A -t 192.168.200.5:389 -s rr
># ipvsadm -a -t 192.168.200.5:389 -m -r 192.168.3.166:389
># ipvsadm -a -t 192.168.200.5:389 -m -r 192.168.3.170:389
># ipvsadm
>IP Virtual Server version 1.2.0 (size=4096)
>Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>TCP 192.168.200.5:ldap rr
> -> 192.168.3.170:ldap Masq 1 0 0
> -> 192.168.3.166:ldap Masq 1 0 0
It looks good so far. Two things to note:
1) 192.168.200.5 is the director. In Masq mode, it needs to have
/proc/sys/net/ipv4/ip_forward set to 1.
2) 192.168.3.170 and 192.168.3.166 need to use the director as the
gateway. TYPICALLY this is done by having an ip address in the same
network, such as 192.168.3.1 on the director. Basically, the director
should be the default gateway for the ldap servers.
>then..i even cannot bind to my openldap..
How are you testing? What machines are testing from? What are the IP
addresses of those test machines? Are they on the same network as the
director or the same network as the ldap servers?
>i just have
>-----------
>redhat(kernel 2.6.9..) & ipvsadm - (1 machine)
>openldap - (2 machine 192.168.3.166 & 192.168.3.170)
>client request to connect to ldap
This is doable, we have two ldap servers load balanced as well, though
we use the DR method instead of the Masq method. They work very well
for us.
--
Regards... Todd
when you shoot yourself in the foot, just because you are so neurally
broken that the signal takes years to register in your brain, it does
not mean that your foot does not have a hole in it. --Randy Bush
Linux kernel 2.6.12-18mdksmp 14 users, load average: 0.18, 0.40, 0.52
|
