LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] Problem with udp/1812 on a 2-node UltraMonkey style HA c

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] Problem with udp/1812 on a 2-node UltraMonkey style HA cluster
From: John Donath <john.donath@xxxxx>
Date: Sat, 27 Oct 2007 00:02:45 +0200
Joseph Mack NA3T wrote:
> On Wed, 24 Oct 2007, John Donath wrote:
>
>   
>> Yes, I do. This is not a problem as only read actions are involved.
>>     
>
> just checking
>
>   
>>> Is Radius listening on the VIP? (it should be, see writeup
>>> for LocalNode)
>>>
>>>
>>>       
>> Radius is listening on 0.0.0.0.
>>     
>
> that knocks my main theory down.
>
> Just to clean things up a little, can you run it only on the 
> VIP?
>
>   
Yes, I can:
[root@grind11 ~]# netstat -an | grep 1812
udp        0      0 172.31.1.10:1812            0.0.0.0:*

But this won't work either because the check - as defined in the 
ldirector.cf - will fail :
virtual=172.31.1.10:1812
        #fallback=127.0.0.1:1812
        real=172.31.1.11:1812 gate
        real=172.31.1.12:1812 gate
        service=radius
        ...

This should be the situation I guess:

[root@grind11 ~]# ipvsadm
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
UDP  172.31.1.10:radius rr
  -> 172.31.1.12:radius           Route   1      0          0
  -> 172.31.1.11:radius           Local   1      0          3

But when I bind radius to the VIP only one if the realnodes has gone away:

IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
UDP  172.31.1.10:radius rr
  -> 172.31.1.12:radius           Route   1      0          0

>> Just a remark - when the radius service is down on the primary but up on
>> the failover node the radius service nicely responds to requests.
>>     
>
> hmm, udp load balances by staying on one realserver for a 
> while (15mins? - see the UDP write ups in the HOWT0). It 
> doesn't behave like tcp at all. I don't know what will 
> happen if the realserver fails that clients are connecting 
> to for that time interval.
>
> Do you have another udp service you can test? ntp is udp, 
> but the time interval for checks increases. Hopefully 
> ntpdate is udp and you can run that on demand.
>
> you don't have any firewall rules anywhere? turn them off 
> for testing.
>   
No firewalling involved.
> Joe
>
>   




<Prev in Thread] Current Thread [Next in Thread>