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.