AEM 6.4 ha llegado al final de la compatibilidad ampliada y esta documentación ya no se actualiza. Para obtener más información, consulte nuestra períodos de asistencia técnica. Buscar las versiones compatibles here.
Esta página se refiere a las topologías recomendadas para AEM. Para obtener más información sobre las capacidades de agrupación en clúster y cómo configurarlas, consulte la Documentación de la API de Apache Sling Discovery.
Los microkernels actúan como gestores de persistencia en la AEM 6.4. La elección de uno que se adapte 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 sus usos recomendados en las configuraciones de AEM más comunes.
En esta situación, se ejecuta una sola instancia de TarMK en un solo servidor.
Esta es la implementación predeterminada para instancias de autor.
Las ventajas:
Las desventajas:
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 puede utilizarse como una copia de seguridad porque el repositorio completo se replica constantemente en el servidor de failover. El servidor de conmutación por error se está ejecutando en modo de espera en frío, lo que significa que solo se está ejecutando el HttpReceiver de la instancia.
Las ventajas:
Las desventajas:
Para obtener más información sobre cómo configurar AEM con el modo de espera pasiva TarMK, consulte this artículo.
La implementación en espera pasiva en este ejemplo de TarMK requiere que tanto la instancia principal como la de espera tengan licencia por separado, ya que hay replicación constante en el servidor de conmutación por error. Para obtener más información sobre las licencias, consulte la Condiciones generales de licencia del Adobe.
Varias instancias de Oak se ejecutan 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 de granja. Para obtener más información, consulte Replicación.
En 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.
Esta es la implementación predeterminada para los entornos de publicación.
Las ventajas:
Este enfoque implica que varias instancias de Oak accedan a un conjunto de réplicas de MongoDB dentro de un solo centro de datos, creando de hecho 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 caso de que falle el hardware o la red.
Las ventajas:
Las desventajas:
Este enfoque implica que varias instancias de Oak acceden a un conjunto de réplicas de MongoDB en varios centros de datos, lo que 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 servidor 3 y AEM servidor 4 se presentan con un estado de inactividad suponiendo una latencia de red entre los servidores de AEM en el centro de datos 2 y el nodo principal MongoDB en el centro de datos 1 que es superior al requisito documentado here. Si la latencia máxima es compatible con los requisitos, por ejemplo mediante el uso de zonas de disponibilidad, los servidores de AEM en el 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 más información sobre los conceptos arquitectónicos de MongoDB descritos en esta sección, consulte Replicación de MongoDB.
La regla básica que debe tenerse 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 según sus necesidades.
Adobe recomienda encarecidamente que TarMK sea la tecnología de persistencia predeterminada que utilizan los clientes en todos los casos 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 backend 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 utilizando 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 capacidad de CPU y memoria de un solo servidor, que admite todas las actividades de creación concurrentes, ya no es sostenible.
Es casi imposible predecir cuál será exactamente el modelo de concurrencia después de que un nuevo sitio se ponga en marcha. Por lo tanto, Adobe recomienda tener en cuenta los siguientes criterios al evaluar si usar MongoMK y dos o más nodos activos Author:
Se puede utilizar Tough Day 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 here.
Una implementación mínima con MongoDB generalmente involucrará 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 binarios no se almacenen dentro de MongoDB. Esto garantizará un rendimiento óptimo dentro de la implementación.
Una de las ventajas adicionales de implementar un conjunto de réplicas de MongoDB con un clúster de dos o más instancias de autor es tener un escenario de recuperación automatizada con un tiempo de inactividad mínimo en caso de instancias de autor, réplica de MongoDB o una falla completa del centro de datos. Sin embargo, la elección de MongoMK sobre TarMK no debería ser impulsada únicamente 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 se cumplan los criterios anteriores durante los primeros dieciocho meses de implementación, se recomienda implementar primero AEM utilizando TarMK, luego volver a evaluar la configuración en una fecha posterior, cuando se apliquen los criterios anteriores, y finalmente determinar si debe 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 una granja de instancias de publicación completamente independientes que ejecutan TarMK, que se mantienen sincronizadas replicando contenido de las instancias de autor. Esta arquitectura de "nada compartido", adecuada para las instancias de publicación, permite la implementación del nivel de publicación para escalar horizontalmente de forma lineal. La topología de granja también proporciona la ventaja de aplicar cualquier actualización o actualización para publicar instancias de forma gradual, de modo que cualquier cambio en el nivel de publicación no requerirá ningún 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 un clúster MongoMK sería apropiado, como cualquier clúster del lado de publicación independientemente del MK elegido, como MongoDB o RDB.
Hay disponible un conjunto de requisitos previos y recomendaciones si está considerando una implementación de MongoMK para AEM:
Requisitos previos obligatorios para las 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 Servicio de atención al cliente de Adobe.
Para sitios que planean implementar AEM Communities, se recomienda elegir una implementación optimizado para gestionar UGC publicado por miembros de la comunidad desde el entorno de publicación.
Mediante una tienda 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 software de terceros y no está incluido en el paquete de licencias de AEM. Para obtener más información, consulte la página Directiva de licencias de MongoDB.
Para aprovechar al máximo su implementación de AEM, Adobe recomienda licenciar la versión de MongoDB Enterprise para beneficiarse del soporte profesional.
La licencia incluye un conjunto de réplicas estándar, que consta de una instancia principal y dos instancias secundarias que pueden utilizarse para el autor o para las implementaciones de publicación.
En caso de que desee ejecutar el autor y publicar en MongoDB, se deben adquirir dos licencias independientes.
Para obtener más información, consulte la Página MongoDB para Adobe Experience Manager.