Recommended Deployments

You are reading the AEM 6.2 version of Recommended Deployments.
This documentation is also available for the following versions:  AEM 6.3  AEM 6.1  AEM 6.0 

Note

This page refers to recommended topologies for AEM. For more information on clustering capabilities and how to configure them, see the Apache Sling Discovery API documentation.

MicroKernels act as persistence managers in AEM 6.2. Choosing one to fit your needs depends on the purpose of your instance and the deployment type you are considering.

The below examples are meant to be an indication of what are their recommended uses in the most common AEM setups.

Deployment scenarios

Single TarMK Instance

In this scenario, a single TarMK instance runs on a single server.

This is the default deployment for author instances.

file

The advantages:

  • Simple
  • Easy maintenance
  • Good performance

The disadvantages:

  • Not scalable beyond the limits of server capacity
  • No failover capacity

TarMK Cold Standby

One TarMK instance acts as the primary instance. The repository from the primary is replicated to a standby failover system.

The cold standby mechanism can also be used as a backup because the complete repository is constantly replicated to the failover server. The failover server is running in cold standby mode, which means that only the HttpReceiver of the instance is running.

file

The advantages:

  • Simplicity
  • Maintainability
  • Performance
  • Failover

The disadvantages:

  • Not scalable beyond the limits of the server capacity
  • One server is idle most of the time
  • The failover is not automatic. It has to be detected externally before the failover system can start serving requests.

Note

For more info on how to configure AEM with TarMK Cold Standby, see this article.

Note

The Cold Standby deployment in this TarMK example requires that both the primary and standby instances be licensed separately, as there is constant replication to the failover server. For more information about licensing, please consult the Adobe General Licensing Terms.

TarMK Farm

Multiple Oak instances run each with one TarMK instance. The TarMK repositories are independent and need to be kept in sync.

Keeping the repositories in sync is provided with the fact that the author server is publishing the same content to each farm member. For more information, see Replication.

For AEM Communities, user generated content (UGC) is never replicated.  For supporting UGC on a TarMK Farm, see considerations for AEM Communities.

This is the default deployment for publish environments.

file

The advantages:

  • Performance
  • Scalability for read access
  • Failover

Oak Cluster with MongoMK Failover for High Availability in a Single Datacenter

This approach implies multiple Oak instances accessing a MongoDB replica set within a single data center. Replica sets in MongoDB are used to provide high availability and redundancy in the event of a hardware or network failure.

file

The advantages:

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

The disadvantages:

  • Performance is not as good as with TarMK

Oak Cluster with MongoMK Failover Across Multiple Datacenters

This approach implies multiple Oak instances accessing a MongoDB replica set across multiple data centers. With multiple data centers, MongoDB replication provides the same high availability and redundancy but now includes the ability to handle a data center outage.

file

The advantages:

  • Ability to scale AEM instances
  • High availability, redundancy, and automated failover of data layer (including data center outages)

Note

In case the arbiter needs to be hosted on platforms like Amazon Web Services, it is recommended that it is configured to only take part in the voting process, and not contain any additional data.

Note

For more information on the MongoDB architectural concepts described in this article, see MongoDB Replication.

Microkernels: which one to use

The basic rule that needs to be taken into account when choosing between the two available micro kernels is that TarMK is designed for performance, while MongoMK is used for scalability.

You can use these decision matrices in order to establish what is the best type of deployment suited to your requirements.

Adobe highly recommends TarMK to be the default persistence technology used by customers in all deployment scenarios, for both the AEM Author and Publish instances, except in the use cases outlined below.

Exceptions for choosing AEM MongoMK over TarMK on Author Instances

The primary reason for choosing the MongoMK persistence backend over TarMK is to scale the instances horizontally. This means having two or more active author instances running at all times and using MongoDB as the persistence storage system. The need to run more than one author instance results generally from the fact that the CPU and memory capacity of a single server, supporting all concurrent authoring activities, is no longer sustainable.

It is almost impossible to predict what the exact concurrency model will be after a new site goes live. Therefore, Adobe recommends you consider the following criteria when evaluating whether to use MongoMK and two or more Author active nodes:

  1.  Number of named users connected in a day: in the thousands or more.
  2.  Number of concurrent users: in the hundreds or more.
  3.  Volume of asset ingestions per day: in hundreds of thousands or more.
  4.  Volume of page edits per day: in hundreds of thousands or more (including automated updates via Multi Site Manager or news feed ingestions for example).
  5.  Volume of searches per day: in tens of thousands or more.

Note

Tough Day can be used to evaluate the performance of the customer’s application in the context of the hardware configuration deployed. More information about this tool is available here.

A minimum deployment with MongoDB will typically involve the following topology:

  • A MongoDB replica set consisting of one primary node, one secondary node, one arbiter node, with each of the MongoDB instances running in a different datacenter with a latency under 15 miliseconds across each node;
  • A cluster of author instances with one leader node, one non-leader node and both active at all time, with each of the author instances running in each of the datacenters, where the MongoDB primary and secondary instances are running.

Additionally, it is highly recommended to configure the datastore on a shared file system or Amazon S3, such that the assets or binaries are not stored within MongoDB. This will ensure optimal performance within the deployment.

One of the additional benefits of deploying a MongoDB replica set with a cluster of two or more author instances is having an automated recovery scenario with minimal downtime in case of an author instances, MongoDB replica or a complete datacenter failure. Nonetheless, the choice of MongoMK over TarMK should not be solely driven by the recovery requirement, as TarMK can also provide a minimal downtime solution with a controlled failover mechanism.

If the above criteria are not expected to be met during the first eighteen months of deployment, it is encouraged to first deploy AEM using TarMK, then re-evaluate your configuration at a later date when the above criteria apply, and finally determine whether to remain on TarMK or migrate to MongoMK.

Exceptions for choosing AEM MongoMK over TarMK on Publish Instances

It is not recommended to deploy MongoMK for publish instances. The publish tier of the deployment is almost always deployed as a farm of fully independent publish instances running TarMK, which are kept in sync by replicating content from the author instances. This "shared nothing" architecture, proper to the publish instances, allows the deployment of the publish tier to scale horizontally in a linear fashion. The farm topology also provides the benefit of applying any update or upgrade to publish instances on a rolling basis, such that any change to the publish tier will not require any downtime.

This does not apply to AEM Communities using MongoMK clusters on the publish tier whenever there's more than one publisher.  If choosing JSRP (see Community Content Storage), then a MongoMK cluster would be appropriate, as would any publish side cluster regardless of the MK chosen, such as MongoDB or RDB.

Prerequisites and Recommendations when deploying AEM with MongoMK

A set of prerequisites and recommendations is available if you are considering a MongoMK deployment for AEM:

Mandatory prerequisites for MongoDB deployments:

  1. MongoDB deployment architecture and sizing must be part of the project implementation with help from Adobe Consulting or MongoDB Architects who are familiar with AEM;
  2. MongoDB expertise must be present within the partner or customer team in order to have confidence in being able to sustain and maintain an existing or new MongoDB environment;
  3. You may choose to deploy the commercial or open source version of MongoDB (AEM supports both), but must purchase a MongoDB Maintenance and Support contract directly from MongoDB Inc;
  4. Overall AEM and MongoDB architectures and infrastructures should be well defined and validated by an Adobe AEM Architect;
  5. You must review the support model for AEM deployments that include MongoDB.

Strong recommendations for MongoDB deployments:

  • Consult the MongoDB for Adobe Experience Manager article;
  • Review the MongoDB production checklist;
  • Attend a certification class on MongoDB available online here.

Note

For all additional questions about these guidelines, prerequisites, and recommendations please contact Adobe Customer Care.

Considerations for AEM Communities

For sites which plan to deploy AEM Communities, it is recommended to choose a deployment optimized for handling UGC posted by community members from the publish environment.

By using a common store, UGC does not need to be replicated between author and other publish instances in order to obtain a consistent view of the UGC.

 

Below are a set of decisional matrices that can assist you in choosing the best type of persistence for your deployment:

Choosing the deployment type for author instances

file

Choosing the deployment type for publish instances

file

Note

MongoDB is third-party software and is not included in the AEM licensing package. For more information see the MongoDB licensing policy page.

In order to get the most of your AEM deployment, Adobe recommends licensing the MongoDB Enterprise version in order to benefit from professional support.

The license includes a standard replica set, which is composed of one primary and two secondary instances that can be used for either the author or the publish deployments.

In case you wish to run both author and publish on MongoDB, two separate licenses need to be purchased.

For more information, see the MongoDB for Adobe Experience Manager page.

Any questions?

Have a question about this or any other AEM topic? Ask our Community.
Learn more about AEM topics on our help hub.
Was this helpful?

By submitting your feedback, you accept the Adobe Terms of Use.

Thank you for submitting your feedback.