Hi Greger. I have a few questions about the three solutions you've proposed
in "Failover/redundancy and Scalability Overview"
(
http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview).
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
By "cacheless usrloc", do you mean db_mode(1) for the "usrloc"
module?
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)?
With this setup, can any UA register with any SER?
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
If each SER has its own local DB, UAs have to register with a specific SER
rather than any of the available SERs, right?
I'm afraid I don't understand the last sentence you wrote above. Would you
mind explaining it in a bit more detail please?
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())
With this setup, can any UA register with any SER?
Each of these three can be combined with either:
a. call-id sticky front-end load balancer (commercial or modified LVS)
What is that?
c. Linux HA creating two and two peers
What is "two and two peers"?
Cheers,
-- Nick
e: nick.hoffman(a)altcall.com
p: +61 7 5591 3588
f: +61 7 5591 6588
If you receive this email by mistake, please notify us and do not make any
use of the email. We do not waive any privilege, confidentiality or
copyright associated with it.