|
Hi Leon,
I've setup the same thing for RDP on 2 physical nodes.
If you are using ESX you have to add another NIC to your VM and to
define another Virtual Switch on another LAN (or possibily VLAN) on
which clients will see the Virtual IP to connect to via RDP and you
will have to use masquerading (see Ultramonkey site for example
configuration).
If you need failover and failback feature I'd suggest to stay on the
latest 2.4 Kernel series (at least 2.4.29 as someone reported on this
list), since 2.6 on ESX isn't yet so stable for production IMHO.
HTH.
Luca
On 13/10/05, Keijser, L.S <keijser@xxxxxx> wrote:
> Hi,
>
> I'm trying to set up 2 load balancers (LVS) in combination with heartbeat for
> HA, to balance load on our windows terminal servers. Now, let me first say
> that my knowledge of routing isn't too good, so i might be asking/stating
> obvious things. Please excuse me if i do.
>
> Secondly, this is my situation: the 2 boxes work together just fine with
> heartbeat. One drops, the other one takes over and vice versa. It's just that
> the load balancing is not working .. I don't know which information i should
> submit, so here goes:
>
> Both machines run on VMWare ESX, using 2 NICs. One i've configured for
> connection with our LAN (in the 192.168 range), the other one is private for
> the heartbeat (10.10.10.x). I can ping the cluster IP just fine from a
> workstation. Heartbeat uses ldirectord to set up ipvsadm rules, which are
> (when active):
>
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 192.168.51.200:3389 wlc
> -> 192.168.50.12:3389 Route 1 0 0
> -> 192.168.50.14:3389 Route 1 0 0
> -> 192.168.50.15:3389 Route 1 0 0
> -> 192.168.50.13:3389 Route 1 0 0
> -> 192.168.50.11:3389 Route 1 0 0
>
> Then i open a MS Remote Desktop Client connection to 192.168.51.200, and get
> timeouts. If i look at the stats i see that no packets are being transmitted:
>
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
> -> RemoteAddress:Port
> TCP 192.168.51.200:3389 6 15 0 720 0
> -> 192.168.50.12:3389 3 8 0 384 0
> -> 192.168.50.14:3389 2 4 0 192 0
> -> 192.168.50.15:3389 1 3 0 144 0
> -> 192.168.50.13:3389 0 0 0 0 0
> -> 192.168.50.11:3389 0 0 0 0 0
>
>
> I think it has something to do with routing ... but i have no idea why, or
> where to start looking :(
>
>
> If somebody could help, i'd appreciate it alot!
>
>
> Thanks,
>
> Léon
>
>
> **************************************************************************************************
> De informatie verzonden in dit e-mailbericht is vertrouwelijk en is
> uitsluitend bestemd voor de geadresseerde. Openbaarmaking,
> vermenigvuldiging, verspreiding en/of verstrekking van deze informatie
> aan derden is, behoudens voorafgaande schriftelijke toestemming van het
> Ruwaard van Putten Ziekenhuis, niet toegestaan. Het Ruwaard van Putten
> Ziekenhuis staat niet in voor de juiste en volledige overbrenging van de
> inhoud van een verzonden e-mailbericht, noch voor tijdige ontvangst
> daarvan. Het Ruwaard van Putten Ziekenhuis kan niet garanderen dat een
> verzonden e-mailbericht vrij is van virussen, noch dat e-mailberichten
> worden overgebracht zonder inbreuk of tussenkomst van onbevoegde derden.
>
> Indien bovenstaand e-mailbericht niet aan u is gericht, verzoeken wij u
> vriendelijk doch dringend het e-mailbericht te retourneren aan de
> verzender en het origineel en eventuele kopieën te verwijderen en te
> vernietigen.
>
>
> The information contained in this communication is confidential and is
> intended solely for the use of the individual or entity to whom it is
> addressed. You should not copy, disclose or distribute this
> communication without the authority of Ruwaard van Putten Hospital.
> Ruwaard van Putten Hospital is neither liable for the proper and
> complete transmission of the information contained in this communication
> nor for any delay in its receipt. Ruwaard van Putten Hospital does not
> guarantee that the integrity of this communication has been maintained
> nor that the communication is free of viruses, interceptions or
> interference.
>
> If you are not the intended recipient of this communication please
> return the communication to the sender and delete and destroy all
> copies.
> **************************************************************************************************
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
