Well, usrloc-cl is in experimental module and latest version of openser has db-mode 3 (the same) and path implementation, so Andreas' setup is possible.  The thing is, this way of doing it makes sense for some setups and for a small-scale setup (like 1000 accounts), the setup is a bit complicated. It also requires mysql cluster competence etc etc.
    Maybe it's the best, I don't know, people have different preferences. http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview
is an attempt at starting to describe the various setups and get people's input and maybe reach a consensus on what can be said to be a best practice setup. We need some reported experiences and people's input, so please discuss, add/change the description at the above link.
    So, your contribution is very welcome. We had an author for the best practice reference, but that person moved to another company than the one with focus on SER and redundancy/failover and was not interested in taking on the task. Open spot! ;-)
g-)

Nick Hoffman wrote:
Hi Greger. On October 25, 2005, you wrote:

  
At least one thing is for sure: I have now registered a two-digit number
of people who are struggling with and proposing various solutions to load
balancing/failover.  We really need to find a solution soon, so all these
bright people can spend their resources on tackling problems that will
bring ser even further!!  Such a solution should be a "best practice"
that is *good enough*, and I would vote for simplicity.  People who
really need that top-performance/hardware are capable of tuning and
fixing themselves (and maybe improve best-practice along the way), all
the others need a simple, well-described setup.
    That is why I have been working with Andreas to try to mirror his
efforts in an onsip.org setup that we will document and make
available as soon as it is ready for prime time.  I suggest that anybody
who have opinions or suggestions put them forward so that everything will
be taken into consideration.
    

I was wondering what progress has been made on this front. Obviously the 
documentation isn't ready since it hasn't been released, but I'd be 
interested in reading what's been done so far, and contributing my 
knowledge wherever I can.

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.