AEM con MongoDB aem-with-mongodb

Este artículo pretende mejorar los conocimientos sobre las tareas y consideraciones necesarias para implementar correctamente Adobe Experience Manager con MongoDB.

Para obtener más información relacionada con la implementación, consulte la Implementación y mantenimiento de la documentación.

Cuándo usar MongoDB con AEM when-to-use-mongodb-with-aem

MongoDB se utilizará normalmente para admitir implementaciones de AEM autor cuando se cumpla uno de los siguientes criterios:

Los criterios anteriores son solo para las instancias de autor y no para ninguna instancia de publicación que debería estar basada en TarMK. El número de usuarios hace referencia a usuarios autenticados, ya que las instancias de autor no permiten el acceso no autenticado.

Si no se cumplen los criterios, se recomienda una implementación TarMK activa/en espera para abordar la disponibilidad. Por lo general, MongoDB debe considerarse en situaciones en las que los requisitos de escalado sean más de lo que se puede lograr con un solo elemento de hardware.

Implementación mínima de MongoDB para AEM minimal-mongodb-deployment-for-aem

A continuación se muestra una implementación mínima para AEM en MongoDB. Para simplificar, se han generalizado los componentes de terminación SSL y proxy HTTP. Consiste en un único conjunto de réplicas MongoDB, con uno primario y dos secundarios.

Una implementación mínima requiere 3 mongod instancias configuradas como un conjunto de réplicas. Una instancia se elegirá principal y las otras instancias serán secundarias, y la elección será administrada por mongod. Adjunto a cada instancia hay un disco local. Para que el clúster admita la carga, se recomienda una ganancia mínima de 12 MB/s con más de 3000 operaciones de E/S por segundo (IOPS).

Los AEM autores están conectados al mongod instancias, con cada autor AEM conectándose a las tres mongod instancias. Las escrituras se envían a la primaria y las lecturas se pueden leer desde cualquiera de las instancias. El tráfico se distribuye en función de la carga de Dispatcher en cualquiera de las instancias de autor de AEM activas. El almacén de datos de OAK es un FileDataStore, y MongoDB es proporcionado por MMS o MongoDB Ops Manager según la ubicación de la implementación. Las soluciones de terceros, como Splunk o Ganglia, proporcionan la monitorización del registro y el nivel del sistema operativo.

En esta implementación, todos los componentes son necesarios para una implementación correcta. Cualquier componente que falte dejará la implementación sin funcionar.

Sistemas operativos operating-systems

Para obtener una lista de los sistemas operativos compatibles con AEM 6, consulte la Página Requisitos técnicos.

Entornos environments

Los entornos virtualizados son compatibles siempre que exista una buena comunicación entre los diferentes equipos técnicos que ejecutan el proyecto. Esto incluye el equipo que está ejecutando AEM, el equipo propietario del sistema operativo y el equipo que administra la infraestructura virtualizada.

Existen requisitos específicos que cubren la capacidad de E/S de las instancias de MongoDB que deben ser administradas por el equipo que administra el entorno virtualizado. Si el proyecto utiliza una implementación en la nube, como Amazon Web Service, las instancias deberán estar aprovisionadas con suficiente capacidad de E/S y coherencia para admitir las instancias de MongoDB. De lo contrario, los procesos MongoDB y el repositorio Oak se ejecutarán de forma infiable y errática.

En los entornos virtualizados, MongoDB requerirá configuraciones específicas de E/S y VM para garantizar que el motor de almacenamiento de MongoDB no se vea paralizado por las políticas de asignación de recursos de VMWare. Una implementación exitosa garantizará que no haya barreras entre los distintos equipos y que todos estén registrados para ofrecer el rendimiento requerido.

Consideraciones sobre hardware hardware-considerations

Almacenamiento storage

Para lograr el rendimiento de lectura y escritura para un mejor rendimiento sin necesidad de escalado horizontal prematuro, MongoDB generalmente requiere almacenamiento SSD o almacenamiento con un rendimiento equivalente a SSD.

RAM ram

Las versiones 2.6 y 3.0 de MongoDB que utilizan el motor de almacenamiento MAP requieren que el conjunto de trabajo de la base de datos y sus índices encaje en RAM.

La insuficiencia de RAM dará lugar a una reducción significativa del rendimiento. El tamaño del conjunto de trabajo y de la base de datos depende en gran medida de la aplicación. Si bien se pueden hacer algunas estimaciones, la manera más fiable de determinar la cantidad de RAM necesaria es crear la aplicación AEM y probarla de carga.

Para ayudar con el proceso de prueba de carga, se puede asumir la siguiente relación entre el conjunto de trabajo y el tamaño total de la base de datos:

Esto significa que en el caso de implementaciones de SSD, se necesitarán 200 GB de RAM para una base de datos de 2 TB.

Aunque las mismas limitaciones se aplican al motor de almacenamiento WiredTiger en MongoDB 3.0, la correlación entre el conjunto de trabajo, la RAM y los errores de página no es tan fuerte como WiredTiger no utiliza la asignación de memoria de la misma manera que lo hace el motor de almacenamiento MAP.

Almacén de datos data-store

Debido a las limitaciones del conjunto de trabajo de MongoDB, se recomienda mantener el almacén de datos independiente del MongoDB. En la mayoría de los entornos a FileDataStore debe usarse el uso de un NAS disponible para todas AEM instancias. Para situaciones en las que se utiliza Amazon Web Service, también existe un S3 DataStore. Si, por cualquier motivo, el almacén de datos se mantiene dentro de MongoDB, el tamaño del almacén de datos debe agregarse al tamaño total de la base de datos y los cálculos del conjunto de trabajo deben ajustarse adecuadamente. Esto puede significar un aprovisionamiento significativamente mayor de RAM para mantener el rendimiento sin errores de página.

Monitoreo monitoring

La supervisión es fundamental para que el proyecto se ejecute con éxito. Aunque con suficiente conocimiento es posible ejecutar AEM en MongoDB sin supervisión, ese conocimiento normalmente se encuentra en ingenieros especializados para cada sección del despliegue.

Normalmente, esto implica que un ingeniero de I+D trabaja en el Apache Oak Core y un especialista de MongoDB.

Sin supervisión a todos los niveles, se necesitará un conocimiento detallado de la base de código para diagnosticar los problemas. Con la supervisión y la orientación adecuada sobre las principales estadísticas, los equipos de implementación podrán reaccionar adecuadamente ante las anomalías.

Aunque es posible utilizar herramientas de línea de comandos para obtener una instantánea rápida de la operación de un clúster, hacerlo en tiempo real en muchos hosts es casi imposible. Las herramientas de línea de comandos rara vez proporcionan información histórica después de unos minutos y nunca permiten la correlación cruzada entre distintos tipos de métricas. Un breve periodo de fondo lento mongod la sincronización requiere un esfuerzo manual significativo para correlacionarse con los niveles de espera de E/S o de escritura excesivos con un recurso de almacenamiento compartido desde una máquina virtual aparentemente desconectada.

MongoDB Cloud Manager mongodb-cloud-manager

MongoDB Cloud Manager es un servicio gratuito ofrecido por MongoDB que permite la supervisión y administración de instancias de MongoDB. Proporciona una visión del rendimiento y el estado del clúster MongoDB en tiempo real. Administra instancias tanto en la nube como alojadas de forma privada, siempre que la instancia pueda acceder al servidor de supervisión de Cloud Manager.

Requiere un agente instalado en la instancia MongoDB que se conecte al servidor de monitorización. Hay 3 niveles del agente:

Aunque el uso de Cloud Manager para la automatización de mantenimiento de un clúster MongoDB facilita muchas de las tareas rutinarias, no es obligatorio y tampoco lo es para la copia de seguridad. Sin embargo, al elegir Cloud Manager para monitorizar, es necesario monitorizar.

Para obtener más información sobre MongoDB Cloud Manager, consulte la Documentación de MongoDB.

Administrador de operaciones de MongoDB mongodb-ops-manager

MongoDB Ops Manager es el mismo software que MongoDB Cloud Manager. Una vez registrado, Ops Manager puede descargarse e instalarse localmente en un centro de datos privado o en cualquier otro equipo portátil o de escritorio. Utiliza una base de datos local de MongoDB para almacenar datos y comunicarse de la misma manera que Cloud Manager con los servidores administrados. Si tiene directivas de seguridad que prohíben un agente de supervisión, debe utilizar el Administrador de operaciones de MongoDB.

Supervisión del sistema operativo operating-system-monitoring

Para ejecutar un clúster AEM MongoDB es necesario supervisar el nivel del sistema operativo.

Ganglia es un buen ejemplo de este sistema y proporciona una imagen sobre el rango y detalle de la información requerida que va más allá de las métricas básicas de salud como CPU, promedio de carga y espacio libre en disco. Para diagnosticar problemas, se requiere información de nivel inferior como niveles de pool de entropía, espera de E/S de CPU, sockets en estado FIN_WAIT2.

Agregación de registros log-aggregation

Con un clúster de varios servidores, la agregación de registros centrales es un requisito para un sistema de producción. Software como Splunk admite la agregación de registros y permite a los equipos analizar los patrones de comportamiento de la aplicación sin tener que recopilar manualmente los registros.

Listas de comprobación checklists

Esta sección trata de los pasos que debe seguir para asegurarse de que las implementaciones de AEM y MongoDB estén configuradas correctamente antes de implementar el proyecto.

Red network

Configuración AEM aem-configuration

Configuración del almacén de nodos node-store-configuration

Las instancias AEM deben configurarse para utilizar AEM con MongoMK. La base de la implementación de MongoMK en AEM es Document Node Store.

Para obtener más información sobre cómo configurar los almacenes de nodos, consulte Configuración de almacenes de nodos y almacenes de datos en AEM.

A continuación se muestra un ejemplo de la configuración del almacén de nodos de documentos para una implementación mínima de MongoDB:

# org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config

>[!CAUTION]
>
>AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our [technical support periods](https://helpx.adobe.com/es/support/programs/eol-matrix.html). Find the supported versions [here](https://experienceleague.adobe.com/docs/?lang=es).
#MongoDB server details
mongodburi=mongodb://aem:aempassword@mongodbserver1.customer.com:27000,mongodbserver2.customer.com:27000

#Name of MongoDB database to use
db=aem

#Store binaries in custom BlobStore e.g. FileDataStore
customBlobStore=true

cache=2048
blobCacheSize=1024

Donde:

Configuración del almacén de datos data-store-configuration

El almacén de datos se utiliza para almacenar archivos de un tamaño mayor que un umbral. Por debajo de ese umbral, los archivos se almacenan como propiedades dentro del almacén de nodos de documentos. Si la variable MongoBlobStore se utiliza, se crea una colección dedicada en MongoDB para almacenar los blobs. Esta colección contribuye al conjunto de trabajo del mongod y requerirán que mongod tiene más RAM para evitar problemas de rendimiento. Por este motivo, la configuración recomendada es evitar el MongoBlobStore para implementaciones de producción y uso FileDataStore respaldado por un NAS compartido entre todas las instancias AEM. Dado que la caché a nivel del sistema operativo es eficiente en la administración de archivos, el tamaño mínimo de un archivo en disco debe establecerse cerca del tamaño de bloque del disco, de modo que el sistema de archivos se utilice de manera eficiente y muchos documentos pequeños no contribuyan excesivamente al conjunto de trabajo del mongod instancia.

Esta es una configuración típica del almacén de datos para una implementación de AEM mínima con MongoDB:

# org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

>[!CAUTION]
>
>AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our [technical support periods](https://helpx.adobe.com/es/support/programs/eol-matrix.html). Find the supported versions [here](https://experienceleague.adobe.com/docs/?lang=es).
# The minimum size of an object that should be stored in this data store.

>[!CAUTION]
>
>AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our [technical support periods](https://helpx.adobe.com/es/support/programs/eol-matrix.html). Find the supported versions [here](https://experienceleague.adobe.com/docs/?lang=es).
minRecordLength=4096
path=/datastore
maxCachedBinarySize=4096
cacheSizeInMB=128

Donde:

Desactivación de la sugerencia de consulta disabling-the-query-hint

Se recomienda deshabilitar la sugerencia de consulta enviada con todas las consultas agregando la propiedad

-Doak.mongo.disableIndexHint=true

al iniciar AEM. De esta manera, MongoDB calculará en el índice más apropiado para usar basado en estadísticas internas.

Si la sugerencia de consulta no está deshabilitada, cualquier ajuste de rendimiento de los índices no tendrá ningún impacto en el rendimiento de AEM.

Habilitar caché persistente para MongoMK enable-persistent-cache-for-mongomk

Se recomienda habilitar una configuración de caché persistente para implementaciones MongoDB, con el fin de maximizar la velocidad para entornos con alto rendimiento de lectura de E/S. Para obtener más información, consulte la Documentación de Jackrabbit Oak.

Optimizaciones del sistema operativo MongoDB mongodb-operating-system-optimizations

Compatibilidad con sistemas operativos operating-system-support

MongoDB 2.6 utiliza un motor de almacenamiento asignado a memoria que es sensible a algunos aspectos de la administración a nivel de sistema operativo entre RAM y disco. El rendimiento de consulta y lectura de la instancia de MongoDB se basa en evitar o eliminar las operaciones de E/S lentas a menudo denominadas errores de página. Estos son errores de página que se aplican al mongod en particular. No deben confundirse con los errores de página a nivel de sistema operativo.

Para un funcionamiento rápido, la base de datos MongoDB solo debe acceder a los datos que ya están en RAM. Los datos a los que debe acceder están formados por índices y datos. Esta colección de índices y datos se denomina conjunto de trabajo. Cuando el conjunto de trabajo es más grande que la RAM disponible, MongoDB debe paginar esos datos desde el disco incurriendo en un coste de E/S, desalojando otros datos que ya están en memoria. Si el desalojo hace que los datos se vuelvan a cargar desde los errores de la página del disco, el rendimiento se verá afectado. Cuando el conjunto de trabajo es dinámico y variable, se incurrirán más errores de página para admitir operaciones.

MongoDB se ejecuta en una serie de sistemas operativos que incluyen una amplia variedad de sabores Linux, Windows y el sistema operativo Mac. Consulte https://docs.mongodb.com/manual/installation/#supported-platforms para obtener más información. Según la elección del sistema operativo, MongoDB tiene diferentes recomendaciones a nivel de sistema operativo. Hay documentos en https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration y resumido aquí para mayor comodidad.

Linux linux

Windows windows

WiredTiger wiredtiger

A partir de MongoDB 3.2 el motor de almacenamiento predeterminado para MongoDB es el motor de almacenamiento WiredTiger. Este motor proporciona una serie de funciones sólidas y escalables, lo que lo hace mucho mejor para cargas de trabajo generales de bases de datos. Las secciones siguientes describen estas funciones.

Conversión de nivel de documento document-level-concurrency

WiredTiger utiliza el control de concurrencia a nivel de documento para operaciones de escritura. Como resultado, varios clientes pueden modificar diferentes documentos de una colección al mismo tiempo.

Para la mayoría de las operaciones de lectura y escritura, WiredTiger utiliza un control de concurrencia optimista. WiredTiger solo utiliza bloqueos de intención en los niveles global, de base de datos y de recopilación. Cuando el motor de almacenamiento detecta conflictos entre dos operaciones, se producirá un conflicto de escritura que hará que MongoDB vuelva a intentar esa operación de forma transparente. Algunas operaciones globales, generalmente operaciones de corta duración que involucran múltiples bases de datos, aún requieren un bloqueo global "en toda la instancia".

Algunas otras operaciones, como soltar una colección, aún requieren un bloqueo exclusivo de la base de datos.

Instantáneas y puntos de comprobación snapshots-and-checkpoints

WiredTiger utiliza MultiVersion Concurrency Control (MVCC). Al inicio de una operación, WiredTiger proporciona una instantánea puntual de los datos de la transacción. Una instantánea presenta una vista coherente de los datos en memoria.

Al escribir en disco, WiredTiger escribe todos los datos en una instantánea en disco de forma consistente en todos los archivos de datos. El ahora- durable Los datos actúan como un punto de comprobación en los archivos de datos. El punto de comprobación garantiza que los archivos de datos sean coherentes hasta el último punto de comprobación, incluido el que lo incluya; es decir, los puntos de comprobación pueden actuar como puntos de recuperación.

MongoDB configura WiredTiger para crear puntos de comprobación (es decir, escribir los datos de la instantánea en el disco) a intervalos de 60 segundos o 2 gigabytes de datos del diario.

Durante la escritura de un nuevo punto de comprobación, el punto de comprobación anterior sigue siendo válido. Como tal, incluso si MongoDB termina o encuentra un error mientras escribe un nuevo punto de comprobación, al reiniciar, MongoDB puede recuperarse del último punto de comprobación válido.

El nuevo punto de comprobación se vuelve accesible y permanente cuando la tabla de metadatos de WiredTiger se actualiza automáticamente para hacer referencia al nuevo punto de comprobación. Una vez que se puede acceder al nuevo punto de comprobación, WiredTiger libera las páginas de los puntos de comprobación antiguos.

Uso de WiredTiger, incluso sin diario, MongoDB puede recuperarse del último punto de comprobación; sin embargo, para recuperar los cambios realizados después del último punto de comprobación, ejecute con diario.

Diario journal

WiredTiger utiliza un registro de transacciones por adelantado en combinación con puntos de comprobación para garantizar la durabilidad de los datos.

El diario WiredTiger mantiene todas las modificaciones de datos entre puntos de comprobación. Si MongoDB sale entre puntos de comprobación, utiliza el diario para reproducir todos los datos modificados desde el último punto de comprobación. Para obtener información sobre la frecuencia con la que MongoDB escribe los datos del diario en disco, consulte Proceso de diario.

El diario WiredTiger se comprime mediante la variable snply biblioteca de compresión. Para especificar un algoritmo de compresión alternativo o sin compresión, utilice la variable storage.wiredTiger.engineConfig.journalCompressor configuración.

Para obtener más información, consulte: Recorriendo con WiredTiger.

Compresión compression

Con WiredTiger, MongoDB soporta la compresión para todas las colecciones e índices. La compresión minimiza el uso del almacenamiento a expensas de la CPU adicional.

De forma predeterminada, WiredTiger utiliza la compresión de bloques con la variable snply biblioteca de compresión para todas las colecciones y compresión de prefijo para todos los índices.

Para colecciones, compresión de bloques con zlib también está disponible. Para especificar un algoritmo de compresión alternativo o sin compresión, utilice la variable storage.wiredTiger.collectionConfig.blockCompressor configuración.

Para índices, para desactivar compresión de prefijo, use el storage.wiredTiger.indexConfig.prefixCompression configuración.

La configuración de compresión también se puede configurar por colección y por índice durante la recopilación y la creación del índice. Consulte Especificar las opciones del motor de almacenamiento y db.collection.createIndex() storageEngine .

Para la mayoría de las cargas de trabajo, la configuración de compresión predeterminada equilibra la eficiencia del almacenamiento y los requisitos de procesamiento.

El diario WiredTiger también está comprimido de forma predeterminada. Para obtener información sobre la compresión de asientos, consulte Historial.

Uso de memoria memory-use

Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.

A partir de la versión 3.4, la caché interna de WiredTiger utilizará, de forma predeterminada, la mayor de las siguientes opciones:

De forma predeterminada, WiredTiger utiliza la compresión de bloques Snapse para todas las colecciones y la compresión de prefijos para todos los índices. Los valores predeterminados de compresión se pueden configurar a nivel global y también se pueden configurar por colección y por índice durante la recopilación y la creación del índice.

Se utilizan representaciones diferentes para los datos en la caché interna de WiredTiger en comparación con el formato en disco:

Los índices cargados en la caché interna de WiredTiger tienen una representación de datos diferente al formato en disco, pero aún pueden aprovechar la compresión de prefijos índice para reducir el uso de RAM.

La compresión de prefijos de índice anula la duplicación de prefijos comunes de campos indexados.

Los datos de recopilación en la caché interna de WiredTiger no están comprimidos y utilizan una representación diferente del formato en disco. La compresión de bloques puede proporcionar ahorros significativos en el almacenamiento en disco, pero el servidor debe descomprimir los datos para manipularlos.

A través de la caché del sistema de archivos, MongoDB utiliza automáticamente toda la memoria libre que no sea utilizada por la caché de WiredTiger o por otros procesos.

Para ajustar el tamaño de la caché interna de WiredTiger, consulte storage.wiredTiger.engineConfig.cacheSizeGB y —wiredTigerCacheSizeGB. Evite aumentar el tamaño de la caché interna de WiredTiger por encima de su valor predeterminado.

NUMA numa

El acceso a memoria no uniforme (NUMA) permite que un núcleo gestione cómo se asigna la memoria a los núcleos del procesador. Aunque esto intenta hacer que el acceso a la memoria sea más rápido para los núcleos, lo que garantiza que puedan acceder a los datos necesarios, la NUMA interfiere con el MAP al introducir latencia adicional, ya que no se puede predecir la lectura. Debido a esto, es necesario deshabilitar la NUMA para el mongod en todos los sistemas operativos que tengan la capacidad.

En esencia, en una arquitectura NUMA, la memoria está conectada a CPUs y las CPUs están conectadas a un bus. En una arquitectura SMP o UMA, la memoria está conectada al bus y compartida por CPUs. Cuando un subproceso asigna memoria en una CPU NUMA, la asigna según una directiva. El valor predeterminado es asignar la memoria conectada a la CPU local del subproceso a menos que no haya disponible, en cuyo momento utiliza la memoria de una CPU gratuita a un costo mayor. Una vez asignada, la memoria no se mueve entre CPUs. La asignación se realiza mediante una directiva heredada del subproceso principal, que en última instancia es el subproceso que inició el proceso.

En muchas bases de datos que ven la máquina como una arquitectura de memoria uniforme de varios núcleos, esto lleva a que la CPU inicial se llene primero y la CPU secundaria se llene más tarde, especialmente si un subproceso central es responsable de asignar búferes de memoria. La solución es cambiar la política de NUMA del hilo principal utilizado para iniciar el mongod proceso.

Esto se puede hacer ejecutando el siguiente comando:

numactl --interleaved=all <mongod> -f config

Esta directiva asigna memoria de forma rotona en todos los nodos de CPU, lo que garantiza una distribución uniforme en todos los nodos. No genera el acceso de mayor rendimiento a la memoria, como en sistemas con múltiples hardware de CPU. Aproximadamente la mitad de las operaciones de memoria serán más lentas y estarán por encima del bus, pero mongod no ha sido escrito para dirigirse a la NUMA de una manera óptima, por lo que es un compromiso razonable.

Problemas de NUMA numa-issues

Si la variable mongod el proceso se inicia desde una ubicación distinta a la /etc/init.d , es probable que no se inicie con la directiva NUMA correcta. Dependiendo de la directiva predeterminada, pueden surgir problemas. Esto se debe a que los diversos instaladores del gestor de paquetes Linux para MongoDB también instalan un servicio con archivos de configuración ubicados en /etc/init.d que realizan el paso descrito anteriormente. Si instala y ejecuta MongoDB directamente desde un archivo ( .tar.gz), entonces tendrá que ejecutar manualmente mongod en el numactl proceso.

El proceso MongoDB se comportará de forma diferente en diferentes políticas de asignación:

Algunas de las políticas pueden dar como resultado que menos de toda la RAM disponible se asigne al mongod proceso. A diferencia de MySQL, MongoDB evita activamente la paginación a nivel del sistema operativo y, en consecuencia, el mongod puede obtener menos memoria que parece disponible.

Intercambio swapping

Debido a la naturaleza intensiva en la memoria de las bases de datos, el intercambio a nivel de sistema operativo debe deshabilitarse. El proceso MongoDB evitará el intercambio por diseño.

Sistemas de archivos remotos remote-filesystems

Los sistemas de archivos remotos como NFS no son recomendables para los archivos de datos internos de MongoDB (los archivos de base de datos del proceso mondial) , ya que introducen demasiada latencia. Esto no debe confundirse con el sistema de archivos compartidos necesario para el almacenamiento de Oak Blob (FileDataStore), donde NFS es recomendado.

Leer adelante read-ahead

Leer con anticipación debe ser ajustado para que cuando una página se pagine usando una lectura aleatoria, los bloques innecesarios no se lean desde el disco, lo que resulta en un consumo innecesario de ancho de banda de E/S.

Requisitos de Linux linux-requirements

Versiones mínimas del núcleo minimum-kernel-versions

Configuración recomendada para los discos de base de datos recommended-settings-for-database-disks

Apagar tiempo

Se recomienda que atime está desactivado para los discos que contendrán las bases de datos.

Establezca el programador de discos NOOP

Para ello:

En primer lugar, compruebe el planificador de E/S que está configurado actualmente. Esto se puede hacer ejecutando el siguiente comando:

cat /sys/block/sdg/queue/scheduler

Si la respuesta es noop no hay nada que hacer más.

Si NOOP no es el programador de E/S configurado, puede cambiarlo ejecutando:

echo noop > /sys/block/sdg/queue/scheduler

Ajuste el valor de lectura anticipada

Se recomienda utilizar un valor de 32 para los discos desde los que se ejecutan las bases de datos MongoDB. Esto equivale a 16 kilobytes. Puede configurarlo ejecutando:

sudo blockdev --setra <value> <device>

Habilitar NTP enable-ntp

Asegúrese de tener NTP instalado y en ejecución en el equipo que hospeda las bases de datos MongoDB. Por ejemplo, puede instalarlo utilizando el administrador de paquetes yum en un equipo CentOS:

sudo yum install ntp

Una vez que el daemon NTP se haya instalado y se haya iniciado correctamente, puede comprobar el archivo de deriva para ver la compensación horaria de su servidor.

Deshabilitar páginas grandes transparentes disable-transparent-huge-pages

Red Hat Linux utiliza un algoritmo de administración de memoria llamado Transparent Huge Pages (THP). Se recomienda deshabilitarlo si utiliza el sistema operativo para cargas de trabajo de base de datos.

Puede desactivarlo siguiendo el procedimiento siguiente:

Deshabilitar NUMA disable-numa

En la mayoría de las instalaciones en las que NUMA está habilitado, el demonio MongoDB lo desactivará automáticamente si se ejecuta como un servicio desde el /etc/init.d carpeta.

En los casos en que no sea así, puede desactivar NUMA por proceso. Para desactivarlo, ejecute estos comandos:

numactl --interleave=all <path_to_process>

Donde <path_to_process> es el camino al proceso mondios.

A continuación, desactive la recuperación de zona ejecutando:

echo 0 > /proc/sys/vm/zone_reclaim_mode

Ajuste de la configuración de límite para el proceso mondios tweak-the-ulimit-settings-for-the-mongod-process

Linux permite un control configurable sobre la asignación de recursos a través del ulimit comando. Esto se puede hacer por usuario o por proceso.

Se recomienda configurar ulimit para el proceso mondios según la variable Configuración de límites recomendados de MongoDB.

Probar el rendimiento de E/S de MongoDB test-mongodb-i-o-performance

MongoDB proporciona una herramienta llamada mongoperf que está diseñado para probar el rendimiento de E/S. Se recomienda usarlo para probar el rendimiento de todas las instancias de MongoDB que conforman su infraestructura.

Para obtener información sobre cómo usar mongoperf, consulte la Documentación de MongoDB.

Probar el rendimiento de lectura en las máquinas virtuales que conforman la implementación

Después de instalar la herramienta, cambie al directorio de la base de datos MongoDB para ejecutar las pruebas. A continuación, inicie la primera prueba ejecutando mongoperfcon esta configuración:

echo "{nThreads:32,fileSizeMB:1000,r:true}" | mongoperf

La salida deseada debe alcanzar hasta dos gigabytes por segundo (2GB/s) y 500.000 IOPS que se ejecutan en 32 subprocesos para todas las instancias de MongoDB.

Ejecute una segunda prueba, esta vez con archivos asignados a memoria, configurando la variable mmf:true parámetro:

echo "{nThreads:32,fileSizeMB:1000,r:true,mmf:true}" | mongoperf

La salida de la segunda prueba debe ser considerablemente mayor que la primera, lo que indica el rendimiento de la transferencia de memoria.

Probar el rendimiento de escritura de la instancia principal de MongoDB

A continuación, compruebe el rendimiento de escritura de E/S de la instancia principal de MongoDB ejecutando mongoperf del directorio de la base de datos MongoDB con la misma configuración:

echo "{nThreads:32,fileSizeMB:1000,w:true}" | mongoperf

El resultado deseado debería ser de 12 megabytes por segundo y alcanzar alrededor de 3000 IOPS, con poca variación entre el número de subprocesos.

Pasos para entornos virtualizados steps-for-virtualised-environments

VMWare vmware

Si está utilizando WMWare ESX para administrar e implementar sus entornos virtualizados, asegúrese de realizar las siguientes configuraciones desde la consola ESX para dar cabida a la operación MongoDB:

Amazon Web Service amazon-web-services

Para obtener documentación sobre cómo configurar MongoDB con Amazon Web Service, consulte la siguiente guía MongoDB en AWS.

Protección de MongoDB antes de la implementación securing-mongodb-before-deployment

Ver este post en implementación segura de MongoDB para obtener consejos sobre cómo proteger la configuración de sus bases de datos antes de la implementación.

Dispatcher dispatcher

Elección del sistema operativo para Dispatcher choosing-the-operating-system-for-the-dispatcher

Para poder servir correctamente la implementación de MongoDB, el sistema operativo que alojará a Dispatcher debe estar en ejecución Apache httpd versión 2.4 o superior.

Además, asegúrese de que todas las bibliotecas utilizadas en la compilación estén actualizadas para minimizar las implicaciones de seguridad.

Configuración de Dispatcher dispatcher-configuration

Una configuración típica de Dispatcher servirá entre diez y veinte veces más el rendimiento de las solicitudes de una única instancia de AEM.

Dado que Dispatcher es principalmente apátrida, puede escalar horizontalmente con facilidad. En algunas implementaciones, es necesario restringir el acceso de los autores a ciertos recursos. Debido a esto, es muy recomendable que utilice un Dispatcher con las instancias de autor.

La ejecución de AEM sin Dispatcher requerirá que otra aplicación realice la terminación de SSL y el equilibrio de carga. Esto es necesario porque las sesiones deben tener afinidad con la instancia de AEM en la que crearon, un concepto conocido como conexiones duraderas. El propósito de esto es garantizar que las actualizaciones del contenido muestren una latencia mínima.

Marque la Documentación de Dispatcher para obtener más información sobre cómo configurarlo.

Configuración adicional additional-configuration

Conexiones fijas sticky-connections

Las conexiones duraderas garantizan que las páginas personalizadas y los datos de sesión de un usuario están compuestos en la misma instancia de AEM. Estos datos se almacenan en la instancia, por lo que las solicitudes posteriores del mismo usuario devolverán a la misma instancia.

Se recomienda habilitar las conexiones duraderas para todas las capas internas que dirijan solicitudes a las instancias de AEM, lo que anima a las solicitudes posteriores a llegar a la misma instancia de AEM. Esto ayudará a minimizar la latencia que, de lo contrario, es visible cuando el contenido se actualiza entre instancias.

Caduca larga long-expires

De forma predeterminada, el contenido enviado desde un Dispatcher AEM tiene encabezados Last-Modified y Etag , sin indicar la caducidad del contenido. Aunque esto garantiza que la interfaz de usuario siempre obtenga la versión más reciente del recurso, también significa que el explorador realizará una operación de GET para comprobar si el recurso ha cambiado. Esto puede dar como resultado varias solicitudes a las que la respuesta HTTP es 304 (sin modificar), según la carga de la página. Para los recursos que se sabe que no caducan, si se configura un encabezado Expires y se eliminan los encabezados Last-Modified y ETag , el contenido se almacenará en caché y no se realizarán solicitudes de actualización adicionales hasta que se cumpla la fecha en el encabezado Expires .

Sin embargo, el uso de este método significa que no hay una manera razonable de hacer que el recurso caduque en el explorador antes de que caduque el encabezado Caduca. Para mitigar esto, se puede configurar HtmlClientLibraryManager para que utilice direcciones URL inmutables para las bibliotecas de cliente.

Se garantiza que estas direcciones URL no cambien. Cuando cambie el cuerpo del recurso contenido en la dirección URL, los cambios se reflejarán automáticamente en la dirección URL, lo que garantiza que el explorador solicitará la versión correcta del recurso.

La configuración predeterminada agrega un selector a HtmlClientLibraryManager. Al ser un selector, el recurso se almacena en caché en Dispatcher con el selector intacto. Este selector también se puede utilizar para garantizar el comportamiento de caducidad correcto. El selector predeterminado sigue el lc-.*?-lc patrón. Las siguientes directivas de configuración httpd de Apache asegurarán que todas las solicitudes que coincidan con ese patrón se proporcionen con una hora de caducidad adecuada.

Header set Expires "Tue, 20 Jan 2037 04:20:42 GMT" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header set Cache-Control "public, no-transform, max-age=267840000" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset ETag "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Last-Modified "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Pragma "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"

Sin Franqueo no-sniff

Cuando el contenido se envía sin tipo de contenido, muchos navegadores intentarán adivinar el tipo de contenido leyendo los primeros bytes del contenido. Esto se llama "esnifado". El filtrado abre una vulnerabilidad de seguridad, ya que los usuarios que pueden escribir en el repositorio pueden cargar contenido malicioso sin tipo de contenido.

Por este motivo, es aconsejable agregar un no-sniff Encabezado a los recursos servidos por Dispatcher. Sin embargo, Dispatcher no almacena en caché los encabezados. Esto significa que cualquier contenido servido desde el sistema de archivos local tendrá su tipo de contenido determinado por su extensión, en lugar de usar el encabezado de tipo de contenido original desde su servidor de origen AEM.

No se puede habilitar ningún sniff de forma segura si se sabe que la aplicación web nunca proporciona recursos en caché sin un tipo de archivo.

Puede activar Sin recorte de forma inclusiva:

Header set X-Content-Type-Options "nosniff"

También se puede activar de forma selectiva:

RewriteCond %{REQUEST_URI} \.(?:js|jsonp)$ [OR]
RewriteCond %{QUERY_STRING} (callback|jsonp|cb)=\w+
RewriteRule .* - [E=jsonp_request:1]
Header set X-Content-Type-Options "nosniff"  env=jsonp_request
Header setifempty Content-Type application/javascript env=jsonp_request

Política de seguridad de contenido content-security-policy

La configuración predeterminada de Dispatcher permite abrir una Política de seguridad de contenido, también conocida como CSP. Esto permite que una página cargue recursos de todos los dominios sujetos a las políticas predeterminadas del entorno limitado del explorador.

Es deseable restringir desde dónde se pueden cargar los recursos para evitar cargar código en el motor de javascript desde servidores externos que no sean de confianza o que no estén verificados.

La CSP permite ajustar las políticas de forma más precisa. Sin embargo, en una aplicación compleja, los encabezados CSP deben desarrollarse con cuidado, ya que las políticas demasiado restrictivas pueden romper partes de la interfaz de usuario.

Tamaño sizing

Para obtener más información sobre el tamaño, consulte la Pautas para el tamaño del hardware.

Optimización del rendimiento de MongoDB mongodb-performance-optimization

Para obtener información genérica sobre el rendimiento de MongoDB, consulte Análisis del rendimiento de MongoDB.

Limitaciones conocidas known-limitations

Instalaciones concurrentes concurrent-installations

Aunque MongoMK admite el uso simultáneo de varias instancias de AEM con una sola base de datos, no lo son las instalaciones simultáneas.

Para solucionar este problema, asegúrese de ejecutar primero la instalación con un solo miembro y añada los demás después de que el primero haya finalizado la instalación.

Longitud del nombre de página page-name-length

Si AEM se está ejecutando en una implementación del administrador de persistencia de MongoMK, los nombres de página están limitados a 150 caracteres.