[SR-Users] Load balance on HA scenario

Duarte Rocha duarterocha91 at gmail.com
Wed Oct 21 20:40:20 CEST 2020


Hi Yufei,

I've tried to do that but unfortunately i'm facing a weird issue.

I have nodes on probing mode, but dispatcher only sends probing via one of
the sockets and then, in some cases, wrongfully updates the status of the
elements of the pair.

I've even tried to manually disable one of the Dipsatcher destinations,
first the one with the VIP and then the other, and Kamailio still sends
requests via one of the sockets, usually the second in the list.
This only happens if i have two destinations with same IP but different
sockets. In scenarios with different IP and different sockets it all works
correctly.

I'm currently on Kamailio v5.4.1. What version are you on? Any special
parameter to make that work?

Best Regards,

A segunda, 12/10/2020, 15:34, Duarte Rocha <duarterocha91 at gmail.com>
escreveu:

> Greetings,
>
> I have two machines with Kamailio in a HA setup with replicated DB. For
> simplicity let's say each machine has one HA IP and that IP can jump to the
> other machine in case something happens (kamailio stopping, etc).
>
> I'm using Dispatcher with load balance configuration. I have Dispatcher
> configured so that each peer has one instance for socket with HA IP 1 and
> HA IP 2.
>
> In order for this to work correctly on the load balance scenario I must
> disable via RPC command the peer which has the socket that doesn't belong
> to the machine. I also must do it every time the IP jumps back and forth,
> which adds complexety to my system.
>
> Does Dispatcher has any sort of help on this? It could not include peers
> with sockets IPs that don't belong to the machine in the destination set,
> for example. Is this possible?
>
> I could also work with failover support but i would rather avoid having so
> many failovers.
>
> Best Regards,A
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201021/8bd80d52/attachment.htm>


More information about the sr-users mailing list