Hi,
i understand why the output of ipvsadm means that everything should be
working.
yes exactly, this mean that it is configured to serve request as soon as
the VIP will be set.
Still when A is running *only* A is answering all requests.
the output of ipvsadm :
TCP lvs:http rr persistent 5
-> linux10.local:http Local 1 0 0 - my
localhost (=A)
-> linux5:http Masq 1 0 0 - the
other machine (=B)
should mean that also linux5 (=B) is also serving requests.
Am i right ?
No. Director can serve request if request is directed to him. So, only if
VIP is set on director.
Or is this simply the meaning of "active/passive" ?
Active <=> MASTER
Passive <=> BACKUP
Active/Passive <=> BACKUP director is waiting until MASTER crash. But in a
normal state BACKUP will not handle any traffic, just waiting crash.
How would i create an "active/active"-configuration (=loadbalancing) with
http ?
Active/Active <=> both director are configured with VRRP in MASTER state.
in active/active LVS-HA setup, both director serving requests on differents
VIPs. For example HTTP VIP on A and SMTP VIP on B.
Since Active state is conditioned by VIP set on director. If you plan to
run HTTP active/active LVS cluster then you need to administratively (in
keepalived.conf) specify VIP for your HTTP service. But your HTTP services
must be dissociate. I mean for example : If you plan to set LVS-HA for both
HTTP services : www.domain1.com & www.domain2.com, both domain with a
different IP address. Then in a Active/Active setup, IP belonging to
www.domain1.com will be configured as VRRP VIP on LVS-A and IP for
www.domain2.com as VRRP VIP on LVS-B.
So, your both LVS will be active at a time one handling traffic for
www.domain1.com and other for www.domain2.com.
Realtek NIC's (RTL-8139) not working :
AFAIK this is the chipset used in most cheap NICs nowadays ,
probably i could even send you a spare one if you like
(and the shipping cost isn't to high).
Some kernel driver are broken for link state monitoring... :/ eepro100 &
3C90X are fully supported (GigE tigoon too).
Best regards,
Alexandre
|