Header Content Footer
Discover best selling sofas, Lounge chairs and get an extra 10% off using the code SEDONA10
Support
Store location
1-800-995-3959
logo Codeland

AEM Services and beyond
Architecture, CodeLand

Setup an AEM author cluster with MongoDB

With the introduction of AEM 6 and its following releases, creation of clusters of author instances has been rethought. The typical persistance model which supports clustering in AEM uses MongoDB.

Adobe suggests to define a cluster of author AEM instances when one of the following criteria is met:

  • 1000+ unique users per day
  • 100+ concurrent users
  • high volumes of page edits
  • large rollouts or activations

These guidelines do not take in consideration scenarios where, even if these criteria are not met, it is vital to guarantee continuity and fault tolerance. For those scenarios it is available the Author Cold StandBy approach which grants fault tolerance but not work continuity which the cluster grants.

Once the cluster of author AEM instances is defined, it is important to avoid the use of MongoDB as a single point of failure. Therefore the database has to be configured as a ReplicaSet in order to grand robustness.

ADVANTAGES – DISADVANTAGES

Hence the advantages in using an author cluster are:

  • Ability to scale AEM instances
  • High availability, redundancy and automated failover of the data layer

Anyway there is also a clear disadvantage:

  • Performances are not as good as with TarMK

MongoDB will be used as a shared NodeStore for AEM, the DataStore can be set up using any of the available possibilities: usually as FileSystem replicated on any author, or as a shared machine, or as an Amazon AWS service.

This part of the configuration is not in the scope of this post, it is possible to read more about it in the Adobe documentation

The following post provides a primer for setting up an AEM author cluster with MongoDB.

STEP-BY-STEP INSTALL

PRE-REQUISITE:
  • Java JRE version 1.8 (including its updates)
  • AEM version 6.2
  • MongoDB version 3.2. This is the last version at the moment working with AEM 6.2
STEP 1 – MongoDB with replica set configuration

cluster setup

In the following, three instances of MongoDB with replicaSet (a primary, a secondary and an arbiter) will be set up. This tutorial explains how to deploy it on the same machine. This is usually an environment for testing and developing. In a real cluster, it is sufficient to change the name of the machines and ports accordingly, given that they can reach each other.

Create a config file for each MongoDB instance to be created, following this template:

# mongo.conf

# data directory
dbpath=Path to allocate files of the instance

# log file
logpath=Path to allocate the log file of the instance

logappend=true

# port number
port=[port_number] / Default: 27017

# replica set name
replSet=[replicaSet Name]

Note: If you want more information about configuration, check the documentation.

Be aware that on the same machine you must set different ports. Once you have prepared the files, you can install each instance via command line. This example works for windows and creates a service for each instance. Alternatively it could be set up directly via command line, as stated in the documentation.

[MONGODB_PATH]\bin\mongod --config mongod1.cfg --serviceName MongoDB1 --serviceDisplayName MongoDB1 --install
[MONGODB_PATH]\bin\mongod --config mongod2.cfg --serviceName MongoDB2 --serviceDisplayName MongoDB2 --install
[MONGODB_PATH]\bin\mongod --config mongod3.cfg --serviceName MongoDB3 --serviceDisplayName MongoDB3 --install

Start all three instances of MongoDB:

net start mongodb1
net start mongodb2 
net start mongodb3

Now it is possible to configure the replica set from the MongoDB shell, connect with this command: 

[MONGODB_PATH]\bin\mongo --port 27017

The instance on which the replica set is initiated will be the primary. Instantiate a configuration variable with the id of the replica set and its starting member:

config = { _id: "rs1", 
           members:[ { _id : 0, host : "localhost:27017"} ] 
}

With this variable, initialize the replica set and verify its result status.

rs.initiate(config)
{
    "info" : "Config now saved locally.  Should come online in about a minute.",
    "ok" : 1
}

Add the two other instances to the replica set, one will be a secondary replica and the other will be an arbiter:

rs.add("localhost:37017")
rs.addArb("localhost:47017")

It is possible now to verify the final status: you should have three instances with this roles: primary, secondary and arbiter.

rs.status()
STEP 2 – Set up the AEM 6.2 servers.

Take two new AEM 6.2 instances and run them with the following commands:

java -jar [aem instance jar name] -r crx3,crx3mongo -Doak.mongo.uri=mongodb://[primaryhost]:[port],[secondaryhost]:[port]/?replicaSet=[replicaSet name]

During startup, check the logs both from mongo and from AEM in order to be sure the startup process ends well. On Mongo you should see the connections from the AEM instances. On AEM you will see eventual errors.

STEP 3 – Testing
  • Log into the AEM servers and open CRXde or the Geometrixx outdoors website to check the correctness of the startup.
  • On any of the two AEM servers, open a page of the Geometrixx outdoors website. Try adding/modifying/deleting some content on the page. If you check on the other server these changes are reflected instantaneously.
  • Shut down the primary MongoDB server and check that both AEM instances are still working without any problem.

AUTHORS

Javier Reyes Alonso, Marco Pasini

BIBLIOGRAPHY

https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/aem-with-mongodb.html http://www.techaspect.com/blog/web-content-management/adobe-experience-manager/oak-cluster-with-mongomk https://docs.mongodb.com/manual/tutorial/deploy-replica-set/

You might also like