Implementaciones recomendadas
NOTEAEM Los microKernels actúan como administradores de persistencia a partir de la versión 6.2 de la. La elección de una que se ajuste a sus necesidades depende del propósito de su instancia y del tipo de implementación que esté considerando.
AEM Los siguientes ejemplos están pensados para indicar cuáles son sus usos recomendados en las configuraciones de administración más comunes de los dispositivos de administración de la.
Escenarios de implementación
Instancia de TarMK única
En esta situación, se ejecuta una sola instancia de TarMK en un solo servidor.
Esta es la implementación predeterminada para las instancias de autor.
Las ventajas:
- Sencillo
- Fácil mantenimiento
- Buen rendimiento
Los inconvenientes:
- No escalable más allá de los límites de la capacidad del servidor
- Sin capacidad de failover
TarMK en espera fría
Una instancia de TarMK actúa como instancia principal. El repositorio del principal se replica en un sistema de failover en espera.
El mecanismo de espera en frío también se puede utilizar como 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 el HttpReceiver de la instancia.
Las ventajas:
- Simplicidad
- Mantenimiento
- Rendimiento
- Failover
Los inconvenientes:
- No escalable más allá de los límites de la capacidad del servidor
- Un servidor está inactivo la mayor parte del tiempo
- La conmutación por error no es automática. Debe detectarse externamente antes de que el sistema de conmutación por error pueda iniciar el servicio de solicitudes.
NOTENOTEGranja TarMK
Varias instancias de Oak se ejecutan cada una con una instancia de TarMK. Los repositorios TarMK son independientes y deben estar sincronizados.
Mantener los repositorios sincronizados se proporciona con el hecho de que el servidor de creación publica el mismo contenido en cada miembro de la granja. Para obtener más información, consulte Replicación.
Para AEM Communities, el contenido generado por el usuario (UGC) nunca se duplica. Para admitir UGC en una granja TarMK, consulte consideraciones sobre AEM Communities.
Esta es la implementación predeterminada para los entornos de publicación.
Las ventajas:
- Rendimiento
- Escalabilidad para acceso de lectura
- Failover
Clúster Oak con failover MongoMK para alta disponibilidad en un solo centro de datos
Este enfoque implica que varias instancias de Oak AEM acceden a un conjunto de réplicas de MongoDB dentro de un solo centro de datos, lo que de hecho crea un clúster activo-activo para el entorno de creación de la. Los conjuntos de réplicas de MongoDB se utilizan para proporcionar alta disponibilidad y redundancia en caso de un error de hardware o de red.
Las ventajas:
- AEM Capacidad de escalar horizontalmente con nuevas instancias de autor de
- Alta disponibilidad, redundancia y failover automatizado de la capa de datos
Los inconvenientes:
- El rendimiento puede ser menor que con TarMK en algunos casos
Clúster de Oak con conmutación por error MongoMK en varios centros de datos
Este método implica varias instancias de Oak AEM que acceden a un conjunto de réplicas de MongoDB en varios centros de datos, lo que de hecho crea un clúster activo-activo para el entorno de creación de la. Con varios centros de datos, la replicación MongoDB proporciona la misma alta disponibilidad y redundancia, pero ahora incluye la capacidad de gestionar una interrupción del centro de datos.
Las ventajas:
- AEM Capacidad de escalar horizontalmente con nuevas instancias de autor de
- Alta disponibilidad, redundancia y failover automatizado de la capa de datos (incluidas las interrupciones del centro de datos)
NOTENOTEMicrokernels: cuál utilizar
La regla básica que debe tenerse en cuenta al elegir entre los dos micro núcleos 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 adapta a sus necesidades.
Adobe AEM 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 autor de como de Publish, excepto en los casos de uso descritos a continuación.
AEM Excepciones para elegir MongoMK en lugar de TarMK en instancias de autor
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 usar MongoDB como sistema de almacenamiento de persistencia. La necesidad de ejecutar más de una instancia de autor se debe generalmente al hecho de que la capacidad de CPU y memoria de un solo servidor, que admite todas las actividades de creación simultáneas, ya no es sostenible.
Es casi imposible predecir cuál será el modelo de concurrencia exacto después de que se publique un nuevo sitio. Por lo tanto, Adobe recomienda tener en cuenta los siguientes criterios al evaluar si se debe utilizar MongoMK y dos o más nodos activos de Author:
- Número de usuarios con nombre conectados en un día: en miles o más.
- Número de usuarios simultáneos: en cientos o más.
- Volumen de ingestas de recursos por día: en cientos de miles o más.
- Volumen de ediciones de página al día: en cientos de miles o más (incluidas actualizaciones automatizadas a través del Administrador de varios sitios o ingestas de fuentes de noticias, por ejemplo).
- Volumen de búsquedas por día: en decenas de miles o más.
NOTEUna implementación mínima con MongoDB suele incluir la siguiente topología:
- Un conjunto de réplicas de MongoDB que consta de un nodo principal, dos nodos secundarios con cada una de las instancias de MongoDB que se ejecutan en una zona de disponibilidad con una latencia inferior a 15 milisegundos en cada nodo;
- Clúster de instancias de autor con un nodo maestro, un nodo no maestro y ambos activos en todo momento, con cada una de las instancias de autor en ejecución en cada uno de los centros de datos, donde se ejecutan las instancias principales y secundarias de MongoDB.
Además, es muy recomendable 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 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 un tiempo de inactividad mínimo si hay instancias de autor, una réplica MongoDB o un error completo del centro de datos. Sin embargo, la elección de MongoMK sobre TarMK no debe ser impulsada únicamente por el requisito de recuperación, ya que TarMK también puede proporcionar una solución de tiempo de inactividad mínima con un mecanismo de failover controlado.
AEM Si no se espera que los criterios anteriores se cumplan durante los primeros 18 meses de implementación, se recomienda primero implementar mediante 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.
AEM Excepciones para elegir MongoMK sobre TarMK en instancias de Publish
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 "no se ha compartido nada", propia de las instancias de publicación, permite la implementación del nivel de publicación para escalar horizontalmente de forma lineal. La topología de conjunto de servidores también ofrece la ventaja de aplicar cualquier actualización o actualización a las instancias de publicación 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 sería apropiado un clúster de MongoMK, como lo sería cualquier clúster del lado de publicación independientemente del MK elegido, como MongoDB o RDB.
Requisitos previos y Recommendations AEM al implementar la implementación de la aplicación con MK
AEM Hay disponible un conjunto de requisitos previos y recomendaciones si está considerando una implementación de MongoMK para lo siguiente:
Requisitos previos obligatorios para implementaciones de MongoDB:
- La arquitectura y el tamaño de la implementación de MongoDB deben formar parte de la implementación del proyecto con la ayuda de los arquitectos de Adobe Consulting AEM o MongoDB que estén familiarizados con el uso de la tecnología de la base de datos de la plataforma de datos de la plataforma de datos de;
- La experiencia de MongoDB debe estar presente dentro del equipo del socio o cliente para tener confianza en poder mantener y mantener un entorno de MongoDB existente o nuevo;
- AEM Puede elegir implementar la versión comercial o de código abierto de MongoDB (admite ambas), pero debe adquirir un contrato de mantenimiento y soporte de MongoDB directamente de MongoDB Inc;
- AEM Las arquitecturas e infraestructuras generales y de MongoDB deben ser bien definidas y validadas por un arquitecto de Adobe AEM
- AEM Revise el modelo de soporte para implementaciones de que incluyan MongoDB.
Recomendaciones sólidas para implementaciones de MongoDB:
NOTE
