<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
TO ALL!!!<br>
The link below describes three alternatives. A forth, quite recently
discussed on this list and serdev, should also be there: using
dispatcher on a stateless SER. If there are somebody who uses such a
setup, feel free to add it to the page!<br>
Also, Nick and others: If the descriptions are a bit short, misleading,
or if something misses, feel free to add/change. <br>
<br>
The rest is inline.<br>
<br>
Nick Hoffman wrote:
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap="">Hi Greger. I have a few questions about the three solutions you've proposed
in "Failover/redundancy and Scalability Overview"
(<a class="moz-txt-link-freetext" href="http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview">http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview</a>).
</pre>
<blockquote type="cite">
<pre wrap="">1. Cacheless usrloc with a mysql cluster as back-end DB combined with
implementation of the Path header (to find the registrar of a given UA).
No replication across servers
</pre>
</blockquote>
<pre wrap=""><!---->
By "cacheless usrloc", do you mean db_mode(1) for the "usrloc" module?
</pre>
</blockquote>
No, I mean the usrloc-cl module found in experimental (for 0.9.x).
Nothing is stored in memory, all queries are thrown at the db.<br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap="">
What do you mean by "implementation of the Path header (to find the
registrar of a given UA)"?
Would [registration?] replication across servers not be needed because of
db_mode(1)?
</pre>
</blockquote>
Yep.<br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap="">With this setup, can any UA register with any SER?
</pre>
</blockquote>
Yep, the path header will be stored in the DB and the info there would
be used for routing.<br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">2. Multiple SER registrars, each with a standalone, local DB and where
SIP is used to replicate registrations. By storing replications from a
peer in a location_peer1 table and then lookup using this table, you can
route INVITEs to the registrar being able to pinhole the NAT in front of
a given UA
</pre>
</blockquote>
<pre wrap=""><!---->
If each SER has its own local DB, UAs have to register with a specific SER
rather than any of the available SERs, right?
</pre>
</blockquote>
No, each peer is responsible for replicating to the other peers.<br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap="">
I'm afraid I don't understand the last sentence you wrote above. Would you
mind explaining it in a bit more detail please?
</pre>
</blockquote>
The UA #1 registers with SER A and call comes from UA #2 on SER B. SER
B can try to contact UA #1 directly, but if the UA is behind a
symmetric NAT, the NAT will not allow incoming messages from other ip
addresses than SER A. Thus, SER B should send the message to SER A, so
that SER A can contact UA #1 by traversing the NAT.<br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">3. Each SER is connected to a single mysql DB cluster as in #1, but
since usrloc also is in memory (cacheless usrloc is not used),
replication is done between the SER servers and save_memory() is used to
store the location only in memory (the registrar updates the cluster
with save())
</pre>
</blockquote>
<pre wrap=""><!---->
With this setup, can any UA register with any SER?
</pre>
</blockquote>
Yep.<br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Each of these three can be combined with either:
a. call-id sticky front-end load balancer (commercial or modified LVS)
</pre>
</blockquote>
<pre wrap=""><!---->
What is that?
</pre>
</blockquote>
What is what? LVS, you mean? <a class="moz-txt-link-freetext" href="http://www.linuxvirtualserver.org/">http://www.linuxvirtualserver.org/</a><br>
<blockquote cite="mid200607131353.23455.nick.hoffman@altcall.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">c. Linux HA creating two and two peers
</pre>
</blockquote>
<pre wrap=""><!---->
What is "two and two peers"?
</pre>
</blockquote>
<br>
Linux HA is Linux High Availability; two servers monitor each other and
if one goes down, the other will take the IP address configured on the
HA cluster. VRRP can also be used in combination or standalone.<br>
<a class="moz-txt-link-freetext" href="http://www.linux-ha.org/">http://www.linux-ha.org/</a><br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/html.charters/vrrp-charter.html">http://www.ietf.org/html.charters/vrrp-charter.html</a><br>
<a class="moz-txt-link-freetext" href="http://www.keepalived.org/">http://www.keepalived.org/</a><br>
<br>
The idea is that each physical server can either run virtualization
(xen/vmware) or use multiple interfaces (one for an active SER and one
for a standby SER), thus enabling each physical server to both be
active and a backup for another SER. Of course, you need to make sure
that one server can take the load of both in case one fails...<br>
g-)<br>
</body>
</html>