cluster with single database replicating only content store?

[cbouvier]

I'm trying to setup a cluster of Alfresco servers, with replicating content stores. The two nodes of the cluster are each at one end of a slow network connection. The goal is to keep users on each side happy by transparently synchronising the content of each node.

I configured one node with a replicatingContent store, storing its content to a local fileContentStore as primary store, and to a NFS mounted fileContentStore as secondary store. It seems to  work well so far: content added on that node is pushed to the secondary contentstore.

I configured the other node exactly symmetrically: i.e., its primary content store is the secondary content store of the other node, and vice-versa. It connects to the same database.

However, I cannot login to the second node: it keeps on refusing my login/password. Does that mean that I really need to configure a cluster of  databases as well, and also a cluster of caches?

TIA

[xyz123]

Hi !
  Well, I m sorry that I won't be able to answer your question.
  But I think u can answer my question.

  I want to setupt a cluster for Alfresco ( for 2 nodes).

  Can u tell me the steps I should follow ?
  Provided documents doesn't help me at all.
  Thanks in advance.

–Tabs

[sebastien_marin]

Hi, we've got exactly the same problem. So we are going to deploy Alfresco for a lot of user and we will probably need to cluster Application. So my question is the same as "cbouvier".

So Ok, we have to cluster fileSyteme with a content store manager when we want to cluster app server. So the problem is that when we read the hight-level-architecture tutorial, you are also clustering database.

Is it possible to cluster webapp without cluster database ?

APP server                                                                  App server
       |                                                                                 |
Content store <——> Content store manager <——> Content store
                                               |
                                               |
                                        Database

[derek]

Hi,

Yes.  The database can be shared.  4:1 would still be a valid ratio of servers to database.

To answer the question, the missing piece is the index-tracker-context.xml which comes as an extension sample.  You need an index tracker running on each of the servers to pick up remote transactions that have been committed to the database.  This will get rid of the login issue as it relies on the indexes for username lookups.

I've been a bit busy on support stuff to update the Wiki docs, which really are old and for 1.3 in terms of config.  Structurally, the architecture remains the same.

Regards

[sebastien_marin]

Hi,

Yes.  The database can be shared.  4:1 would still be a valid ratio of servers to database.

To answer the question, the missing piece is the index-tracker-context.xml which comes as an extension sample.  You need an index tracker running on each of the servers to pick up remote transactions that have been committed to the database.  This will get rid of the login issue as it relies on the indexes for username lookups.

I've been a bit busy on support stuff to update the Wiki docs, which really are old and for 1.3 in terms of config.  Structurally, the architecture remains the same.

Regards

Ok, thank you very much for your answer. Just for confirmimation, it is not possible to have a shared file system (files and lucene) for many app server ?

Thank you for your help.

[derek]

Hi,

It is possible, architecturally, to have multiple servers using the same content store.  We never write to the same file twice, a choice mandated by, amongst others, the ability to share a store in a cluster.  Provided your shared store is fast, it is the simplest solution.  If your shared store is slow, make it a secondary store to each of the servers.

What you can't share are the indexes.  You can put your indexes anywhere you like provided the storage mechanism supports atomic locks on the files.  So, a CIFS shared drive would not be feasible.  Practically, you want the indexes to be on a local, but separate disk - make it a fast one.  Disks aren't expensive provided that you don't need to stripe them and so forth.  Indexes have very low backup requirements as they can be rebuilt easily.  So put the indexes local to each server and share the content store and database.

One of the configs we present during consulting is to have the custom config shared as well.

Regards