9

Hi fellow Tridionauts,

I am working on a project with following server setup:

enter image description here

Cluster currently has 2 (websphere) servers, but this number will probably change in the future. Each server has it's own deployer and separate DB server (everything is doubled for disaster recovery purposes) and this approach will continue with scaling up the number of servers.

Next step is to setup caching.

Simplest approach would be to add cache channel service (as java standalone app) to each of the webservers and use RMI to sync the cache on each server separately.

Is there any disadvantage to this approach? Are there any benefits if JMS is used for cache synchronization , talking into account this type of server configuration (scaling up is done only through Web server+DB duplication).

Edit 1 Also, I am thinking about is putting broker DB's into cluster, which would both increase performance on the db level and still keep disaster recovery requirements in check. Would this possible change, push the choice in JMS direction?

Edit 2 In the scenario that deployers are load balanced (all of them deploying to the same DB cluster) what would be cache sync scenario?

Improve this question

3 Answers 3

Reset to default
8

The basic principle is that for each deployer there is a cache invalidation process. For RMI , this is via the Cache Channel Service (CCS) and for JMS this is via a JMS queue. If you have two servers each with their own DB and deployer, then you will need two cache invalidation processes (CCS or JMSQ).

All brokers (websites) that serve content deployed by one deployer must subscribe to cache invalidation messages from that deployer, via CCS or JMSQ. As soon as you have more deployers you will need more CCS processes or more JMSQs.

As Sebastian states, JMS can provide a better stability in terms of fault tolerance but it will require more infrastructure to make it happen. RMI is a single point of failure but is simple to implement. In the event of any communication failure to RMI or JMS (for whatever reason) the Brokers can be configured to behave to either; not cache anything, cache everything with no expiry or periodically flush & rebuild the cache. All strategies are a compromise but the first and latter will have an impact on performance.

Also, I am thinking about is putting broker DB's into cluster, which would both increase performance on the db level and still keep disaster recovery requirements in check. Would this possible change, push the choice in JMS direction?

Not as such; you can still choose either but the more you scale out everything, the more JMS is a better solution. This is especially relevant if you have broker servers separated from the deployers by a firewall. RMI is not firewall friendly.

In the scenario that deployers are load balanced (all of them deploying to the same DB cluster) what would be cache sync scenario?

If you mean two deployers deploying to the same DB then this is not supported, it should be a one to one relationship between DB and Deployer. Or to be more accurate, publication to database. But to answer what you ask, all deployers and brokers should connect to the same cache invalidation should they be all connected to the same database.

Improve this answer
2
  • @@Julian tnx. In the last scenario, I would have multiple deployers behind load balancer deploying all content to the same DB cluster which is used on the content delivery side. As each deployment package will be sent to only 1 deployer, why is this not supported? In this scenario, should there be only 1 CCS / JMS that would be used by both deployers?
    – user3760419
    Jan 28, 2015 at 11:22
  • I gave you the very simple statement. You can do this but each deployer must handle a -separate- set of publications. If two deployers deploy packages from the same publication you get errors under load. Without load you may not see it. More information here: julianwraith.com/2012/12/…
    – Julian Wraith
    Jan 28, 2015 at 11:40
3

For few years, we are exactly in the same configuration : caching setup with one cache channel service (as Windows Service) configured on each webserver. Each webservers is synchronized with its dedicated Cache Channel.

The only disavantage I see in this scenario is that Cache Channel becomes a SPOF. It cannot be scaled up. One Cache Channel for one Webservers. If one Cache Channel is down then the corresponding webserver will have poor performances.

If you use a JMS instance on a JMS server then you have the capability to put in place a fault tolerant solution (ie failover, cluster, etc...) if your need it.

If you don't need this, the RMI solution works very well.

Improve this answer
1

Simplest approach would be to add cache channel service (as java standalone app) to each of the webservers and use RMI to sync the cache on each server separately. Is there any disadvantage to this approach?

Absolutely. I wouldn't call this a stable enterprise production-ready solution. The processes could go down, typically you would need to setup custom monitoring of these processes for a production environment, there would not be any failover either - basically, it's a brittle setup for an enterprise system.

Are there any benefits if JMS is used for cache synchronization

Yes, the messaging queue server can be scaled out with a failover configuration having the JMS is in a cluster. So if your website, deployer or other parts of the content delivery infrastructure go down, your Cache Channel will remain.

Here are a couple of resources on Tridion Cache Channel with JMS to bookmark:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.