Details

    • Type: New Feature 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

        Hide
        Daniel Ostermeier added a comment -

        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

        Show
        Daniel Ostermeier added a comment - 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
        Hide
        Justin Pitts added a comment -

        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.

        Show
        Justin Pitts added a comment - 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.
        Hide
        Nick Minutello added a comment -

        >>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...

        Show
        Nick Minutello added a comment - >>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...
        Hide
        Bob Swift added a comment -

        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!

        Show
        Bob Swift added a comment - 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!

        Show
        Charles Miller [old account, do not assign issues] added a comment - Confluence 2.3 is now clusterable. Not sure why we didn't close this last week!

          People

          • Votes:
            50 Vote for this issue
            Watchers:
            17 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Last commented:
              7 years, 15 weeks, 6 days ago