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).
- 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?
- 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?
- 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@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.