2 Replies Latest reply on May 10, 2012 6:48 PM by jlewis@42lines.net

    Best Practices: Clustered Author Environment

    New2CQ

      Hello,

       

      We are setting our CQ 5.5 infrastructure in 3 datacenters with ultimately an Authoring instance in each (total of three).  Our plan was to Cluster the three machines using “Share Nothing” and each would replicate to the Publish instances in all data centers.  To eliminate confusion within our organization, I’d like to create a single URL resource for our Authors so they wouldn’t have to remember to log into 3 separate machines?

       

      So instead of providing cqd1.acme.com, cqd2.acme.com, cqd3.acme.com, I would distribute something like “cq5.acme.com” which would resolve to one of the three author instances.  While that’s certainly possible by putting a web server/load balancer in front of the three, I’m not so sure that’s even a best practice for supporting internal users.

       

      I’m wondering what have other multi-datacenter companies done (or what does Adobe recommend) to solve this issue, did you:

       

      1. Only give one destination and let the other two serve as backups? (this appears to defeat the purpose of clustering)
      2. Place a web server/load balancer in front of each machine and distribute traffic that way?
      3. Do nothing, e.g., provide all 3 author URLs and let the end-user choose the one closest to them geographically?
      4. Something else???

       

      It would be nice if there was a master UI an Author could use that communicated with the other author machines in a way that’s transparent to the end-user – so if Auth01 went down, the UI would continue to work with the remaining machiness without the end-user (author) even knowing the difference (e.g., not have to change machines).

       

      Any thoughts would be greatly appreciated.

        • 1. Re: Best Practices: Clustered Author Environment
          justin_at_adobe Adobe Employee

          In general, it is best to have all users *writing* to a single author node (the master). If the master goes down, use a load balancer (if available, which it hopefully is) to direct the traffic to the new master.

          • 2. Re: Best Practices: Clustered Author Environment
            jlewis@42lines.net

            Day's documentation (for CRX 2.3) states in part, "whenever a write operation is received by a slave instance, it is redirected to the master instance ..."  So, all writes will always go to the master, regardless of which instance you hit.

             

            Day's documentation also states, "Perhaps surprisingly, clustering can also benefit the author environment because even in the author environment the vast majority of interactions with the repository are reads. In the usual case 97% of repository requests in an author environment are reads, while only 3% are writes."

             

            This being the case, it seems the latency of hitting a remote author would far outweight other considerations.  If I were you, New2CQ, I would probably have my users hit the instance that's nearest to them (in terms of network latency, etc...) regardless or whether it's a master or a slave.