AEM With MongoMK - Options

We can have 2 types of MongoMK configurations for AEM Oak Clusters.

1) Failover for High Availability in a Single Datacenter

Here a primary MongoDB will be used for Read/Write. So the multiple Oak instances accessing a MongoDB replica set within a single data center.
This setup helps for high availability and redundancy in the event of a hardware or network failure

Major advantages are,

• Scalability
• High availability
• redundancy
• automated failover of data layer

One of the disadvantage of this setup is, there are some performance issues when compared with TarMK.

2) Failover Across Multiple Datacenters

Here multiple Data Centers are involved. Primary MongoDB will be replicated to secondary systems. So multiple Oak instances accessing a MongoDB replica set across multiple data centers. In this configuration, MongoDB replication provides the same high availability and redundancy as comapared to previous configuration but it also includes the ability to handle a data center outage.

Major advantages are,

• Scalability
• High availability
• Redundancy
• Automated failover of data layer

Final notes:
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances, except in the use cases outlined here.

Foot notes:
What is MongoDB Arbiter. Why we need an Arbiter?

In software the CAP theorem says, "If there are equal number of servers on either side of the partition, the database cannot maintain CAP (Consistency, Availability, and Partition tolerance). An Arbiter is specifically designed to create an -imbalance- or majority on one side so that a primary can be elected in this case."

As per MongoDB site(https://docs.mongodb.com/v3.4/tutorial/add-replica-set-arbiter/) "Arbiters are mongod instances that are part of a replica set but do not hold data. Arbiters participate in elections in order to break ties. If a replica set has an even number of members, add an arbiter. Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an arbiter on an application server or a monitoring host."

If you get an even number of nodes on both sides, MongoDB will not elect a primary and your set will not accept writes.

Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK
Read More
Rule Engine integration with AEM

Subscribe Our YouTube Channel Here.

AEM With TarMK - Options

We can have 3 types of TarMK configurations for AEM Oak Clusters.

1) Single TarMK Instance

A single TarMK instance runs on a single server. For Author instances, this is the default deployment method.

Major advantages are,

• Simple
• Easy to maintain
• Better performance

The disadvantages:

• Scalability is within the limits of server capacity
• No failover capacity

2) TarMK Cold Standby

Here single TarMK instance acts as the primary instance & the repository from the primary is replicated to a standby, which acts as failover system.

Major advantages are,

• Simplicity
• Maintainability
• Performance
• Failover

The disadvantages:

• Scalability is within the limits of server capacity
• There is a manual task involved in detecting failure and failover to start working

3) TarMK Farm

Multiple Oak instances are involved and each Oak instance is running with one TarMK. All TarMK repositories are not in sync
TarMK Farm is the default deployment for publish environments.

Major advantages are,

• Performance
• Scalability for read access
• Failover

Final notes:
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances, except in the use cases outlined here.
Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK
Read More
Rule Engine integration with AEM

AEM Microkernels - MongoMK vs TarMK

Latest AEM comes with Oak storage. Oak(Apache Jackrabbit Product) is a new JCR implementation with a completely new internal architecture.
There are two options for the AEM persistence layer back-end used by Oak : TarMK and MongoMK. Let us see the scenarios where each one is feasible and what are all the main differences.


TarMK Vs MongoMK

Adobe recommendation says we must consider MongoMK when we come across below metrics

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

Prerequisites for considering MongoMK as persistence layer.

Once we identified MongoMK as persistence layer below factors are mandatory.
1. Ensure involving MongoDB architects/ Adobe MongoDB Specialists for designing the solution.
2. AEM Developers should work hand in hand with MongoDB developers to implement a successful solution.
3. For a better turn around time, always ensure to have Mongo DB Maintenance License.
4. Ensure the proposed design is validated by an Adobe Certified Experience Manager Architect to avoid any future issues.

Advantages of MongoMK in Authroing Instances

Horizontal Scalability Support – MongoMK supports multiple AEM instances share the same MongoDB instance.
Efficient Data Replication – MongoMK effectively delegates replication functionality to the MongoDB, which has mature model to maintain replica sets. Major advantage here is MongoDB replicas and AEM instances are independent each other.
Distributed Authoring Team Support – Content authoring across different geographical regions are supported by Mongo MK. At first data gets saved int the primary MongoDB and then gets replicated to the secondary DB replica sets.
Automated Failover Recovery – MongoDB supports automated failover. The efficient configuration can helps in automated system recovery from data center failure.

Advantages of TarMK in Publish Instances
Automated Failover Recovery - Efficient configuration of TarMK provides Automated recovery during system failures.
24/7 availability: Code changes are released on one data center, validate the release and then release it to the other data center. TarMK supports such rolling release efficiently.
Efficent upgrades: AEM Upgrades and patch fixes needs rolling release, thus TarMK provides better support.

Huge Data considerations: Which one to use?
If most of the Data in (TB) are binaries, TarMK is a good fit, and a data store on the file system. If the data (in multiple TB) is structured content / nodes, MongoMK is the better choice because we can shard the data.

Sharding can be found at MongoDB Documentation : Overview / Adobe Experience Manager 6.0 / Deploying and Maintaining / or The MongoDB Manual.

Final Notes:
TarMK is optimized for single node performance whereas MongoMK is designed for scalability and clustered deployments. Another factor is the volume of the data. Also keep in mind MongoMK setup/configuration/maintenance requires additional knowledge about MongoDB.

In my next blog I will be talking about MongoMK Recommended Deployments(AEM on MongoDB )
Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK
Read More
Rule Engine integration with AEM

Subscribe Our YouTube Channel Here.

Hybrid Content Management(HCM) & AEM

Hybrid Content Management system integrates cloud storage, content management services and/or features with on-premises content management software for store, share and manage enterprise content. Some of the decision factors which involved for selection of Hybrid Content Management are cost, mobility and new features.

Importance of Hybrid Content Management
Some of the recent data analyst group study revealed that within few years, majority of enterprises will manage the content using a hybrid storage model. This showcases the importance of new Hybrid AEM designs.



EFSS
Cloud file sharing is one of the factor that can drive hybrid CMS demand with AEM. Enterprise file sync and share services (EFSS) examples are Box, Dropbox, Citrix ShareFile, Office 365, G Suite.

Majority of companies are moving to a cost effective cloud based system, but factors of security are still a concern and some of the federal data laws asks for an on-premise storage(compliance, performance related, and security restrictions). Hybrid approach of synchronizing such existing on-premises storage with new EFSS services is ideal in this case, this shows the importance of Hybrid Content Management system.

Some of the laws which asks for a secure data system:
Health Insurance Portability and Accountability Act (HIPAA), the Sarbanes-Oxley Act (SOX), the U.S. Securities and Exchange Commission (SEC) and other compliances.

Hybrid cloud services(HCS)
Hybrid cloud services, a bridge between on-premise storage infrastructure and the cloud of choice, allowing customers to scale cloud storage as needed, use a blend of private and public clouds, and maintain control of their data with simple management tools. New AEM designs asks for this type of service integrations.

Example for HCS system: NetApp's Data ONTAP - storage operating system, can be used to connect Amazon S3 or EVS storage.

Synchronization
When we migrate the applications or data to a new system , common set of problem arises such as disruption of business operations, data loss and transitioning users to new processes.

When platforms are synchronized, content is automatically populated in the new system. Through Synchronization, users can still securely collaborate with external parties and across multiple devices. Synchronization helps to sync EFSS services to their existing platforms while preserving past investments and keeping their IT infrastructure intact.

Think before you act

There are some factors to be considered before we sync up AEM with hybrid systems. Our design should be based on the out come of below considerations.

1) Ensure  bi-directional sync : When you plug AEM into a hybrid system, ensure a bi-directional sync, this confirms both platforms are up-to-date.

2) Define an inter-operability :
Consider synchronization of user permissions, document versioning and metadata across systems so that the connection is seamless, secure and transparent to end-users.

3) Think Investments done & reduce cost :
Organization might have done huge investments on the existing system already. So consider this while defining the hybrid approach. Based on usage, sync only their most used active content, while keeping old data and archived information within premise & decommission aging servers.

4) Study the system
Do an impact study on the existing system and their rules like metadata, permission, user accounts management etc. Based on the study define the new hybrid approach.

Queries?
Let us know through the comment section