Details
-
Type:
New Feature
-
Status: Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.3
-
Component/s: None
-
Labels:None
-
Last commented by user?:true
Description
In a corporate environment, its important to be able to cluster webapps so that:
a) it can be deployed on standard appserver farms (which are clustered)
b) we have redundancy and automatic failover.
If the application requires a cold standby (as is the case with Jira nd Confluence as they stand), its a major PITA.
Due to it support priorities to business-critical applications, a application that requires manual fail-over will have a downtime of anything from minutes to hours.
As I see it the issues are:
1) Hibernate Caching - can be taken care of at the hibernate level (known solutions: free and not free - customer can choose)
2) Indexing. If filesystem indexing is essential, then we need some kind of fault-tolerant index synchronisation mechanism. JMS?
3) confluence.cfg.xml Config file. Can this be pre-edited and deployed in the WAR?
4) default-formatting.properties Can this be pre-edited and deployed in the WAR?
5) Custom Velocity templates: Can these be stored in database or via webdav?
Activity
Hi Darren,
We are currently in the early stages of making Confluence clusterable.
One of the assumptions we have made to help reduce the complexity of this task is that Confluence will be talking to a single database. We do not distringuish between a single database or a distributed database so long as the behaviour is the same. With your master-master setup, will Confluence be able to make that assumption?
Originally, primary keys were generated by an application level sequence. This has now been changed to Hibernates HiLo ID generator. How does your custom UUID generation differ from this? Will it work with our assumption of a single database?
Regards,
-Daniel
FWIW, I have configured Confluence as a managed service in Microsoft Cluster Server (MSCS). This configuration is tested and in production.
If you're not familiar with the product, MSCS is a failover cluster system that manages resources among multiple physical nodes. When a physical node fails, the applications, IP address/network names, and physical disk resources are moved from the failing machine to a surviving node in the cluster.
>>It's alvery well having a cluster, but what we want is a replicated database.
Confluence caches loads of info - without a distributed cache & distributed event mechanism, this wouldnt work...
We have a very similar requirement (conf instances in NY, LON & TOK)- and if done right, the clustering solution could scale accross the WAN...
Unfortunately, there are many different interpretations for "clustering". Best to stick to specific requirements and each organization will have different ones that fit into this category. Here are mine:
1) High availability (HA) across a WAN. All instances available. When an instance fails, re-route to another instance. Want advantage of better "local" performance.
2) HA on local environment (like MSCS solution mentioned above) would be useful especially if 1) is not available
3) Needs to handle Confluence upgrades with minimal downtime. Upgrades are the BIGGEST cause of downtime for Confluence!
4) Not just for large customers! As more critical data goes into Confluence, downtime (planned and unplanned) is bad even for smaller companies (50-500 users). Please make it affordable for smaller environments too!
Confluence 2.3 is now clusterable. Not sure why we didn't close this last week!
Nick brings up excellent points – the lack of clustering support causes me grief and probably limits Confluence adoption by big biz.
Honestly – I'd recommend renaming the Enterprise edition to "Large Business" and setting the user limit at 1000 ($40/seat) ...because frankly, it isn't Enterprise level.
BTW – The pricing, frankly, is screwed up too – Enterprise to me means 5,000 or more users. So the little guy spending $2,200 for 50 users is getting screwed because the 5,000 (or 50,000) user "Enterprise" essentially gets the unlimited licenses for super cheap peanuts per user. And the irony is that they can afford to pay thousands more!
And without clustering, the perception is that any product will start to have performance issues after users load gets above some arbitrary number.
Please note that I didn't say Confluence WILL have perf issues, just that perception of the Pointy Haired Boss is that "Enterprise" means X thousand users will "require clustering" and without that, the product can't possibly scale. But if it costs $XXX,XXX and says "cluster" – then, well, it MUST be GOOD!
Cheers - Timo
P.S. All comments above are my personal opinions – my employer doesn't have [nor want] anything to do with them.