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,
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,
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.
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.
No comments:
Post a Comment