morgan at mediatemple
May 26, 2008, 12:12 PM
Post #8 of 9
(2185 views)
Permalink
|
Those looks reasonable, however, you will probably not want to
separate the SIP and RTP traffic. It would make more sense to use two
iptables rules that set the same firewall mark. IE: You can set as
many iptables rules as the system can handle to assign a given
firewall mark. Any traffic (regardless of port/type) can be balanced
with the FWM. FWM is (as you can see by the ipvsadm man-page) it's
own service type. Instead of specifying --tcp-service or --udp-
service you specify --fwmark-service. Given that I use Keepalived vs.
the other methods, it is slightly different than making direct calls
with ipvsadm.
In short, no need to have separate VIPS for SIP and RTP unless you
have different servers handing SIP traffic.
It would probably look something more like this:
> virtual service fwmark 1 { # SIP RTP
> persistent...
> iptables -t mangle -A PREROUTING -p udp -d 192.168.1.27-28 --dport
> 10000:20000 -j MARK --set-mark 1 # SIP RTP: where -d has ip of real
> servers
> iptables -t mangle -A PREROUTING -p tcp -d 192.168.1.27-28 --dport
> 5060 -j MARK --set-mark 1 # SIP RTP: where -d has ip of real servers
I've not used FWM+NAT in a good long while. You probably don't need
to set the firewall mark on the realservers as the firewall mark (I
don't believe) stays with the packet once it leaves the local
networking stack (ie, it is not sent out on the wire). So unless the
system needs to do something specific with the firewall mark (IE
iprule to policy-route to the director) the firewall mark will not
need to be set on the real-server.
A DR configuration should work almost identically, however, I've not
done UDP in a DR configuration (always NAT). A standard DR
configuration ~should~ function for a Asterisk setup like this.
--
Morgan Fainberg
Systems Architect
(mt) Media Temple, Inc
http://www.mediatemple.net/
On May 25, 2008, at 7:48 AM, Gerry Reno wrote:
> Morgan Fainberg wrote:
>> In theory, you could use a FWM (firewall mark) setup and persistent
>> connections. If you map the virtual server group to use the same FWM
>> for the TCP ( SIP uses TCP port 5060) and UDP (RTP usually is
>> configured for UDP ports 16384-32767) datastreams. It should work
>> in
>> theory.
>>
>> However, the application-based Load-balancing in Asterisk does
>> function fairly well and you might end up with a better solution.
>> Typically, with load-balancing I find that the more complexity you
>> add
>> just makes it that much harder to debug when things go awry.
>>
>>
> I think the fwmark approach might work. And I like this since
> load-balancing with LVS is better for me because I have all my other
> services on it.
> I'm keeping all traffic going through the Asterisk box with
> canreinvite=no. canreinvite=yes would present a further scenario as
> the
> endpoints would then end up in direct communication for RTP.
> You'll have to excuse me if I've oversimplified this. I have not used
> fwmarks before.
>
> So let's see, I'm using keepalived so in the conf I guess I would have
> something like:
> virtual service RS_IP 5060 { # SIP
> persistent...
> virtual service fwmark 1 { # SIP RTP
> persistent...
>
> In iptables (directors):
> iptables -t mangle -A PREROUTING -p udp -d 192.168.1.27-28 --dport
> 10000:20000 -j MARK --set-mark 1 # SIP RTP: where -d has ip of real
> servers
>
> In iptables (realservers): # only for NAT, what about DR?
> iptables -A PREROUTING -t mangle -d <VIRTUAL_IP> -j MARK --set-mark
> 1 #
> route back to director
>
> Does this look reasonable?
>
> Regards,
> Gerry
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
> Send requests to lvs-users-request [at] LinuxVirtualServer
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
