16 Oct
2012
16 Oct
'12
2:23 p.m.
On 15.10.2012 23:36, Thomas Hoffman wrote:
We’re trying to determine how best to design/architect
a solution where
we use Kamailio as a Presence/XCAP server and be scalable to support
millions of subscribers.
I see the Dispatcher module, but it appears that requires having
dedicated instances of the server running just in Dispatcher mode – then
you can load balance across the actual instances of the presence
servers.
Yes, it is typical to use a dispatcher to dispatch the load over several
servers which do the real stuff (presence, gateways ...), eg:
clients <--Internet-----> dispatcher <------- server 1
\------- server 2
\------ server X
Dispatching (eg. Kamailio with dispatcher module) is much less resource
intensive (e.g. no DB lookups, just stateless forwarding), thus a single
dispatcher can handle the load for several backend servers.
If the load is too big for a single dispatcher node, then you need more
dispatcher nodes. You can use for example multiple SRV records for the
SIP domain, or provision the clients with different IP addresses (of the
respective dispatcher nodes). Then, every dispatcher sends the traffic
to a certain partition of the backend servers, or you distribute the
traffic over all backend servers.
It’s not clear if a server can be configured to work
as a
dispatcher and a presence server at the same time.
Yes you can but it does not make sense - if a node itself is a presence
server it does not make sense to dispatch the request to other presence
servers. One if the main advantages of having a dispatcher in front of
the cluster is to have a single border element (single IP address) which
eases problems like NAT traversal.
Does anyone have any high-level guidance how to
approach this problem?
Presence requires, that a presence server which receives a subscription
for a presentity, also knows the status of this presentity. There are 2
approaches to handle this problem:
a) make sure to send PUBLISH requests from a certain presentity, and the
SUBSCRIBE requests to this presentity, to the same presence backend. In
this setup, every presence server uses its own database (or just memory
without a DB). In case a presence server is removed (crash, maintenace),
all traffic needs to be moved to other nodes and the current state is
usually lost. Further you have to be sure to have the XCAP data
available to all nodes.
b) all presence servers use the same database. In this case, the
presence servers can not do any caching and have to query the DB for
every operation. This setup simplifies the SIP setup, but increases the
load on the DB and you may need a fast DB cluster. There were recently
much changes to the presence modules for such a DB-only mode.
regards
Klaus