Esta página se refiere a las topologías recomendadas para AEM. Para obtener más información sobre las capacidades de clustering y cómo configurarlas, consulte la documentación de la API de Apache Sling Discovery.
Los microkernels actúan como gestores de persistencia en AEM 6.4. La elección de una para adaptarse a sus necesidades depende del propósito de su instancia y del tipo de implementación que esté considerando.
Los siguientes ejemplos pretenden indicar cuáles son los usos recomendados en las configuraciones de AEM más comunes.
En este escenario, una sola instancia de TarMK se ejecuta en un único servidor.
Ésta es la implementación predeterminada para instancias de autor.
Las ventajas:
Los inconvenientes:
Una instancia de TarMK actúa como instancia principal. El repositorio del primario se replica en un sistema de failover en espera.
El mecanismo de espera en frío también se puede utilizar como una copia de seguridad porque el repositorio completo se replica constantemente en el servidor de conmutación por error. El servidor de conmutación por error se está ejecutando en modo de espera en frío, lo que significa que sólo se está ejecutando HttpReceiver de la instancia.
Las ventajas:
Los inconvenientes:
Para obtener más información sobre cómo configurar AEM con TarMK Cold Standby, consulte este artículo.
La implementación en frío y en espera en este ejemplo de TarMK requiere que las instancias principal y en espera tengan una licencia independiente, ya que existe una replicación constante en el servidor de failover. Para obtener más información acerca de las licencias, consulte los Términos generales de licencias de Adobe.
Se ejecutan varias instancias de Oak cada una con una instancia de TarMK. Los repositorios TarMK son independientes y deben mantenerse sincronizados.
Mantener los repositorios sincronizados se proporciona con el hecho de que el servidor de creación está publicando el mismo contenido para cada miembro del conjunto de servidores. Para obtener más información, consulte Replicación.
Para AEM Communities, el contenido generado por el usuario (UGC) nunca se replica. Para obtener soporte para UGC en una granja TarMK, consulte consideraciones para AEM Communities.
Ésta es la implementación predeterminada para entornos de publicación.
Las ventajas:
Este enfoque implica que varias instancias de Oak tienen acceso a un conjunto de réplicas de MongoDB dentro de un solo centro de datos, lo que en realidad crea un clúster activo-activo para el entorno de creación de AEM. Los conjuntos de réplicas en MongoDB se utilizan para proporcionar alta disponibilidad y redundancia en el evento de un fallo de hardware o de red.
Las ventajas:
Los inconvenientes:
Este enfoque implica que varias instancias de Oak tienen acceso a un conjunto de réplicas de MongoDB en varios centros de datos, lo que en realidad crea un clúster activo-activo para el entorno de creación de AEM. Con múltiples centros de datos, la replicación de MongoDB proporciona la misma alta disponibilidad y redundancia, pero ahora incluye la capacidad de manejar una interrupción en el centro de datos.
Las ventajas:
En el diagrama anterior, AEM Server 3 y AEM Server 4 se presentan con un estado inactivo, suponiendo una latencia de red entre los servidores AEM del Centro de datos 2 y el nodo principal MongoDB del Centro de datos 1 que es superior al requisito documentado aquí. Si la latencia máxima es compatible con los requisitos, por ejemplo mediante el uso de zonas de disponibilidad, los servidores de AEM del Centro de datos 2 también pueden estar activos, lo que crea un clúster de AEM activo-activo en varios centros de datos.
Para obtener información adicional sobre los conceptos arquitectónicos de MongoDB descritos en esta sección, consulte Replicación de MongoDB.
La regla básica que se debe tener en cuenta al elegir entre los dos microneles disponibles es que TarMK está diseñado para el rendimiento, mientras que MongoMK se utiliza para la escalabilidad.
Puede utilizar estas matrices de decisión para establecer cuál es el mejor tipo de implementación que se adapte a sus necesidades.
Adobe recomienda encarecidamente que TarMK sea la tecnología de persistencia predeterminada utilizada por los clientes en todos los escenarios de implementación, tanto para las instancias de AEM Author como para Publish, excepto en los casos de uso descritos a continuación.
La razón principal para elegir el servidor de persistencia MongoMK sobre TarMK es escalar las instancias horizontalmente. Esto significa tener dos o más instancias de autor activas ejecutándose en todo momento y usando MongoDB como sistema de almacenamiento de persistencia. La necesidad de ejecutar más de una instancia de autor se debe en general al hecho de que la CPU y la capacidad de memoria de un único servidor, que admite todas las actividades de creación concurrentes, ya no son sostenibles.
Es casi imposible predecir cuál será el modelo exacto de concurrencia después de que se active un nuevo sitio. Por lo tanto, Adobe recomienda considerar los siguientes criterios al evaluar si se debe utilizar MongoMK y dos o más nodos activos de Author:
Se puede utilizar el Día duro para evaluar el rendimiento de la aplicación del cliente en el contexto de la configuración de hardware implementada. Encontrará más información sobre esta herramienta disponible aquí.
Una implementación mínima con MongoDB suele incluir la siguiente topología:
Además, se recomienda configurar el almacén de datos en un sistema de archivos compartido o Amazon S3, de modo que los recursos o los archivos binarios no se almacenen en MongoDB. Esto garantizará un rendimiento óptimo dentro de la implementación.
Una de las ventajas adicionales de implementar un conjunto de réplicas MongoDB con un clúster de dos o más instancias de autor es tener un escenario de recuperación automatizada con tiempo de inactividad mínimo en caso de que se produzcan instancias de autor, una réplica de MongoDB o una falla completa del centro de datos. Sin embargo, la elección de MongoMK sobre TarMK no debe estar únicamente motivada por el requerimiento de recuperación, ya que TarMK también puede proporcionar una solución de downtime mínima con un mecanismo de failover controlado.
Si no se espera que los criterios anteriores se cumplan durante los primeros dieciocho meses de implementación, se recomienda implementar primero AEM mediante TarMK, luego volver a evaluar la configuración en una fecha posterior cuando se apliquen los criterios anteriores y, finalmente, determinar si desea permanecer en TarMK o migrar a MongoMK.
No se recomienda implementar MongoMK para instancias de publicación. El nivel de publicación de la implementación casi siempre se implementa como un conjunto de instancias de publicación completamente independientes que ejecutan TarMK, que se mantienen sincronizadas al replicar contenido de las instancias de creación. Esta arquitectura de "nada compartido", adecuada a las instancias de publicación, permite que la implementación del nivel de publicación se escale horizontalmente de forma lineal. La topología del conjunto de servidores también ofrece la ventaja de aplicar cualquier actualización o actualización para publicar instancias de forma sucesiva, de modo que cualquier cambio en el nivel de publicación no requerirá tiempo de inactividad.
Esto no se aplica a AEM Communities que utiliza clústeres MongoMK en el nivel de publicación siempre que haya más de un editor. Si elige JSRP (consulte Almacenamiento de contenido de la comunidad), entonces sería adecuado un clúster MongoMK, como cualquier clúster de publicación independientemente del MK elegido, como MongoDB o RDB.
Hay un conjunto de requisitos previos y recomendaciones disponibles si está considerando una implementación MongoMK para AEM:
Requisitos previos obligatorios para implementaciones de MongoDB:
Recomendaciones sólidas para implementaciones de MongoDB:
Para todas las preguntas adicionales sobre estas directrices, requisitos previos y recomendaciones, póngase en contacto con Adobe Customer Care.
Para los sitios que planeen implementar AEM Communities, se recomienda elegir una implementación optimizada para administrar UGC anunciados por miembros de la comunidad desde el entorno de publicación.
Al utilizar un almacén común, no es necesario replicar UGC entre el autor y otras instancias de publicación para obtener una vista coherente del UGC.
A continuación se muestra un conjunto de matrices decisorias que pueden ayudarle a elegir el mejor tipo de persistencia para la implementación:
MongoDB es un software de terceros y no está incluido en el paquete de licencias de AEM. Para obtener más información, consulte la página Política de licencias de MongoDB.
Para aprovechar al máximo su implementación de AEM, Adobe recomienda que se le otorgue la licencia de la versión MongoDB Enterprise para beneficiarse de la asistencia profesional.
La licencia incluye un conjunto de réplicas estándar, compuesto por una instancia primaria y dos instancias secundarias que se pueden usar para la implementación de publicación o del autor.
Si desea ejecutar tanto la creación como la publicación en MongoDB, deberá adquirir dos licencias independientes.
Para obtener más información, consulte la página MongoDB para Adobe Experience Manager.