Alfresco Enterprise (One/Content Services) vs Alfresco Community (HA)

[liviu_ioan]

Hello,

I would like to understand more about the technical differences on Enterprise vs Community.
I was not able to find any good (deep) resources on the subject.
(you can actually give me pointers in the Alfresco Enterprise code/components)

I am interested in a high availability (HA) context (2 Alfresco nodes).
A small number of users can be connected at the same time (< 10).
Less than 25 000 documents are inserted in Alfresco per day (usually, way less than 10 000 are deposited every day)
The scenario is well depicted here:
https://docs.alfresco.com/5.2/concepts/cluster-scenario-redundancy.html

My understand is the following:
the 2 Alfresco nodes share the same database
the needed Solr nodes operate in cluster mode
When Alfresco starts, it simply interrogates the database and Solr for the info needed.

Question: why can't I use Alfresco Community for the above HA scenario?
What is missing in Alfresco Community?

Thank you.
Regards,
Liviu

[afaust · Accepted solution]

Feature differences between Alfresco Community and Enterprise should be easy to find, either in the documentation or in the wider community, i.e. in an older comparison provided by Contentreich. Alfresco rarely provides low-level technical documentation beyond APIs, so if you are looking for technical details you'd have to get yourself familiar with the codebase a bit. Generally speaking, the technical differences are quite limited. Enterprise re-uses 100% Community code and only adds a handful of JARs that deal with clustering, JMX management, automatic shard registration, user license handling etc.

The reason you cannot (reliably) run two Community instances in such a scenario has to do with non-persistent data that cannot be communicated or kept in-sync between the two nodes in Community Edition. Such data includes ephemeral state such as short-lived locks, authentication tickets and some other bits only held by in-memory caches and not stored in the database. Additionally, some functional components store intermediary data structures in caches that have been derived from DB data - without inter-node communication of an active cluster, these structures run the risk of inconsistency when the DB is changed by an interaction with one of the nodes.

The key thing that is missing in Community Edition is a distributed caching and messaging layer. The core code shared between Community and Enterprise defines the common interface(s) of the layer, but only Enterprise contains a specific implementation that deals with distributed caching / messaging using Hazelcast as the library.

It is not impossible to add such functionality to Community Edition since the interfaces are public (I have done so in a proprietary module), but it certainly is not trival.

[liviu_ioan]

Thank you for your detailed reply, Axel!

I think I get the big picture (I know what locks & caches are).

One more question, to make sure I get a better understanding: could you give some basic, practical examples of what could go (terribly) wrong when using a LB, 2 Alfresco Community nodes, 1 database cluster and 1 solr cluster?

[afaust]

Well, imagine your users are using the Edit Online feature via AOS. One user (temporarily) locks a document for edit on server A, a second user tries to open that document and his request goes to server B. That server does not know about the lock and voila, you run into potential update conflicts where one user may override another users changes. (temporary locks are not stored in the DB)

If you configure a new data model via the Content Model Manager feature on server A, server B will not be aware of that since the initialised dictionary state is actually stored in a runtime cache, and there is no option to have it always "read-through" (that would be prohibitively expensive). As a result, users would not be able to access certain folders / documents on one server and SOLR would not be able to index new elements of that model.

There are various other effects, but I hope this should suffice...

[liviu_ioan]

OK, Axel. Again, thanks.

Yes, updating models on one node is a bad idea, if nodes are not clustered.

But what about if objects are not editable? Are there any concerns in this context? (only upload & read operations permitted)

[afaust]

If there are only read-only operations, then there would not be an issue. A simple upload may already cause issues since there is a cache for childByName lookups that would become stale if a new document is uploaded to a folder on which there has already been a lookup.

[liviu_ioan]

Q1: So uploads are not propagated in a real time manner into the database? When are the uploads seen by the 2 instances? Are there any concerns regarding the uploads, besides the fact that they are not seen in "realtime"?

Q2 (important question regarding uploads into the ContentStore😞 Let's say 2 Alfresco nodes are sharing the same ContentStore (when FileContentStore is used, the actual folder is shared by the OS between the 2 machines; when S3ContentStores are used, we are simply talking about the same bucket on the S3 storage). I can see a new object ID in the ContentStore is simply generated using GUID.generate() (for both FileContentStores and S3ContentStores). How come no collisions are taking place? Is GUID.generate() making use of the Alfresco Enterprise clustering mechanisms?

[afaust]

Q1: Uploads are propagated in real time to the DB, but due to caching, some operations may not always query the DB and thus immediately be aware of changes. Operations relevant for a simple "list all children" of a folder will immediately pick up the upload, because they always go to the DB. Operations like "give me the child with name X" may not immediately be aware of a newly uploaded file or a file that has been moved to a different location, if that "give me the child with name X" had already been called before the change and thus caused data to be cached.

Q2: GUID is NOT making use of any clustering mechanisms. It simply generates a GUID in such a way that conflicts are extremely unlikely. For starters, each server selects a pseudo-random number generator from a set of 256 generators for the actual generation step. Then it uses a library implementing the RFC4122 UUID specification to generate UUIDs (based on section 4.4 of the RFC) for the actual, random UUID generation.

[liviu_ioan]

OK, so the 2 nodes can generate IDs in the same ContentStores due to mathematical mechanisms (probabilities), not because of clustering.