Adobe Experience Manager con MongoDB aem-with-mongodb

AEM Este artículo tiene como objetivo mejorar el conocimiento sobre las tareas y las consideraciones necesarias para implementar correctamente la implementación de (Adobe Experience Manager) con MongoDB.

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

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

AEM MongoDB se utiliza generalmente para admitir implementaciones de autor de en las que se cumple uno de los siguientes criterios:

Los criterios anteriores solo son para las instancias de autor y no para ninguna instancia de publicación que deba basarse 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 activa/en espera de TarMK para abordar la disponibilidad. Por lo general, MongoDB debe considerarse en situaciones en las que los requisitos de escalado son más de lo que se puede lograr con un solo elemento de hardware.

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

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

Una implementación mínima requiere tres mongod instancias configuradas como un conjunto de réplicas. Una instancia se selecciona principal y las demás instancias son secundarias, y la elección se administra mediante mongod. Cada instancia tiene un disco local adjunto. Para que el clúster pueda admitir la carga, se recomienda un rendimiento mínimo de 12 MB por segundo con más de 3000 operaciones de E/S por segundo (IOPS).

AEM Los autores de la están conectados al mongod AEM instancias, con cada autor de la conectándose a las tres mongod instancias. Las escrituras se envían a la instancia principal y las lecturas se pueden leer desde cualquiera de las instancias. AEM El tráfico se distribuye en función de la carga que realiza Dispatcher en cualquiera de las instancias de autor de la activa. El almacén de datos de Oak es un FileDataStorey la monitorización MongoDB la proporciona MMS o el administrador de operaciones de MongoDB según la ubicación de la implementación. Las soluciones de terceros como Splunk o Ganglia proporcionan monitorización del nivel del sistema operativo y del registro.

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

Sistemas operativos operating-systems

AEM Para obtener una lista de los sistemas operativos admitidos para la versión 6 de la aplicación, consulte la Página de requisitos técnicos.

Entornos environments

Se admiten entornos virtualizados siempre que haya una buena comunicación entre los diferentes equipos técnicos que ejecutan el proyecto. AEM Esta asistencia incluye al equipo que está ejecutando la infraestructura virtualizada, al equipo propietario del sistema operativo y al equipo que administra la infraestructura virtualizada.

Existen requisitos específicos que cubren la capacidad de E/S de las instancias de MongoDB que debe administrar el equipo que administra el entorno virtualizado. Si el proyecto utiliza una implementación en la nube, como Amazon Web Service, las instancias deben aprovisionarse con suficiente capacidad de E/S y coherencia para admitir las instancias de MongoDB. De lo contrario, los procesos de MongoDB y el repositorio de Oak funcionan de forma poco fiable y errática.

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

Consideraciones de 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 al 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 se ajuste a la RAM.

La insuficiencia de RAM provoca 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. AEM Si bien se pueden hacer algunas estimaciones, la manera más confiable de determinar la cantidad de RAM necesaria es construir la aplicación y probarla con la carga.

Para ayudarle con el proceso de prueba de carga, se puede dar por hecha la siguiente relación entre el espacio de trabajo y el tamaño total de la base de datos:

Estas proporciones significan que para las implementaciones de SSD se requieren 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. 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 que el almacén de datos se mantenga independiente de MongoDB. En la mayoría de los entornos, una FileDataStore AEM debe utilizarse el uso de un NAS disponible para todas las instancias de la. Para situaciones en las que se utiliza Amazon Web Service, también hay 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 añadirse al tamaño total de la base de datos y los cálculos del conjunto de trabajo deben ajustarse correctamente. Este tamaño puede significar el aprovisionamiento de más RAM para mantener el rendimiento sin errores de página.

Monitoreo monitoring

La supervisión es vital para una implementación exitosa del proyecto. AEM Con los conocimientos suficientes, es posible ejecutar la ejecución de MongoDB sin tener que realizar un seguimiento de la ejecución de los programas de la. Sin embargo, ese conocimiento normalmente se encuentra en ingenieros especializados para cada sección del despliegue.

Este conocimiento especializado suele incluir a un ingeniero de I+D que trabaja en el Apache Oak Core y a un especialista de MongoDB.

Sin supervisión en todos los niveles, se requiere un conocimiento detallado del código base para diagnosticar los problemas. Una vez establecida la supervisión y con las directrices adecuadas sobre las estadísticas principales, los equipos de implementación pueden reaccionar adecuadamente ante las anomalías.

Aunque es posible utilizar herramientas de línea de comandos para obtener una instantánea rápida del funcionamiento 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 a partir de unos minutos y nunca permiten la correlación cruzada entre distintos tipos de métricas. Un breve período de lentitud mongod La sincronización requiere un esfuerzo manual significativo para correlacionar con la espera de E/S o los niveles de escritura excesivos con un recurso de almacenamiento compartido desde una máquina virtual aparentemente no conectada.

Cloud Manager de MongoDB mongodb-cloud-manager

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

Requiere un agente instalado en la instancia de MongoDB que se conecta al servidor de monitorización. Existen tres niveles de agente:

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

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 ordenador portátil o de sobremesa. 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 políticas de seguridad que prohíben un agente de monitoreo, debe usarse MongoDB Ops Manager.

Monitorización del sistema operativo operating-system-monitoring

AEM Es necesaria la monitorización a nivel de sistema operativo para ejecutar un clúster de MongoDB en el que se ejecute un clúster de MongoDB en el sistema operativo.

Ganglia es un buen ejemplo de un sistema de este tipo y proporciona una imagen sobre la gama y el 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 grupo 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 central es un requisito para un sistema de producción. El 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

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

Red network

AEM Configuración de aem-configuration

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

AEM AEM Las instancias de deben configurarse para utilizar la configuración de la aplicación con MongoMK. AEM La base de la implementación de MongoMK en es el Almacén de nodos de documentos en el que se realiza la creación de la aplicación.

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

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
#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 for example, 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 en el almacén de nodos de documentos. Si la variable MongoBlobStore , se crea una colección dedicada en MongoDB para almacenar los blobs. Esta colección contribuye al conjunto de trabajo del mongod y requiere que mongod tiene más RAM para evitar problemas de rendimiento. Por este motivo, la configuración recomendada es evitar el MongoBlobStore para implementaciones y uso de producción FileDataStore AEM respaldado por un NAS compartido entre todas las instancias de la. Dado que la caché en el nivel del sistema operativo es eficaz para administrar archivos, el tamaño mínimo de un archivo en disco debe establecerse en un tamaño cercano al tamaño de bloque del disco. Al hacerlo, se asegura de que el sistema de archivos se utiliza de forma eficaz y que muchos documentos pequeños no contribuyen en exceso al conjunto de trabajo del mongod ejemplo.

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

# org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
# The minimum size of an object that should be stored in this data store.
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 AEM cuando empiece a. Al hacerlo, MongoDB calcula el índice más apropiado para usar según las estadísticas internas.

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

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

Se recomienda habilitar una configuración de caché persistente para implementaciones MongoDB, a 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 la memoria que es sensible a algunos aspectos de la gestión de nivel del sistema operativo entre la RAM y el disco. El rendimiento de consulta y lectura de la instancia de MongoDB depende de evitar o eliminar las operaciones de E/S lentas, a menudo denominadas errores de página. Estos problemas son errores de página que se aplican al mongod proceso en particular. No confunda con errores de página del sistema operativo.

Para un funcionamiento rápido, la base de datos MongoDB solo debe acceder a los datos que ya están en la 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 mayor que la RAM disponible, MongoDB tiene que paginar esos datos desde el disco incurriendo en un coste de E/S, desalojando otros datos que ya están en la memoria. Si la expulsión hace que los datos se vuelvan a cargar desde el disco, los errores de página predominan y el rendimiento se degrada. Cuando el conjunto de trabajo es dinámico y variable, se incurre en más errores de página para admitir operaciones.

MongoDB se ejecuta en varios sistemas operativos, incluidos una amplia variedad de sabores Linux®, Windows y macOS. 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 de nivel de sistema operativo. Hay documentos en https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration y se resume 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 algunas funciones sólidas y escalables, lo que lo hace mucho más adecuado para las cargas de trabajo generales de bases de datos. Las secciones siguientes describen estas funciones.

Concurrencia de nivel de documento document-level-concurrency

WiredTiger utiliza el control de concurrencia de nivel de documento para las 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 control de concurrencia optimista. WiredTiger sólo utiliza bloqueos por intención en los niveles global, de base de datos y de colección. Cuando el motor de almacenamiento detecta conflictos entre dos operaciones, uno incurre en un conflicto de escritura que hace que MongoDB vuelva a intentar esa operación de forma transparente. Algunas operaciones globales, normalmente operaciones de corta duración que implican varias bases de datos, siguen precisando un bloqueo global "en toda la instancia".

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

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

WiredTiger utiliza el Control de concurrencia de varias versiones (MVCC). Al comienzo 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 el disco, WiredTiger escribe todos los datos en una instantánea en el disco de una manera consistente en todos los archivos de datos. El ahora- duradero 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. 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 instantánea en el disco) a intervalos de 60 segundos o 2 GB de datos de 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 al escribir 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 el nuevo punto de control es accesible, WiredTiger libera páginas de los antiguos puntos de control.

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 una combinación de inicio de sesión de transacción de escritura anticipada 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 existe entre puntos de comprobación, utiliza el historial 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 el disco, consulte Proceso de diario.

El historial WiredTiger se comprime usando el brusco biblioteca de compresión. Para especificar un algoritmo de compresión alternativo o que no haya compresión, use storage.wiredTiger.engineConfig.journalCompressor configuración.

Consulte Diario con WiredTiger.

Compresión compression

Con WiredTiger, MongoDB admite 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 brusco biblioteca de compresión para todas las colecciones y compresión de prefijo para todos los índices.

Para colecciones, la compresión de bloques con zlib también está disponible. Para especificar un algoritmo de compresión alternativo o que no haya compresión, use storage.wiredTiger.collectionConfig.blockCompressor configuración.

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

Los ajustes de compresión también se pueden configurar por recopilación y por índice durante la recopilación y la creación de índices. Consulte Especificar opciones del motor de almacenamiento y db.collection.createIndex() storageEngine opción.

Para la mayoría de las cargas de trabajo, los ajustes de compresión predeterminados equilibran 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 diarios, consulte Diario.

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 3.4, la caché interna de WiredTiger, de forma predeterminada, utiliza el mayor de los siguientes:

De forma predeterminada, WiredTiger utiliza la compresión de bloques Snappy 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 establecer por colección e índice durante la recopilación y la creación de índices.

Se utilizan diferentes representaciones 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 del prefijo de índice para reducir el uso de RAM.

La compresión del prefijo de índice deduplica los prefijos comunes de los campos indizados.

Los datos de recopilación de 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 los datos deben descomprimirse para que el servidor los manipule.

A través de la caché del sistema de archivos, MongoDB utiliza automáticamente toda la memoria libre que no es 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

NUMA (Acceso a Memoria No Uniforme) permite que un núcleo administre cómo se asigna la memoria a los núcleos del procesador. Aunque este proceso intenta acelerar el acceso a la memoria de los núcleos, asegurándose de que puedan acceder a los datos necesarios, NUMA interfiere con MAP introduciendo una latencia adicional, ya que las lecturas no se pueden predecir. Como resultado, NUMA debe deshabilitarse para mongod procesar en todos los sistemas operativos compatibles.

En esencia, en una arquitectura NUMA, la memoria se conecta a las CPU y las CPU se conectan a un bus. En una arquitectura SMP o UMA, la memoria se conecta al bus y se comparte con las CPU. Cuando un subproceso asigna memoria en una CPU NUMA, se asigna según una directiva. El valor predeterminado es asignar memoria conectada a la CPU local del subproceso a menos que no haya memoria libre, momento en el que utiliza la memoria de una CPU libre a un costo mayor. Una vez asignada, la memoria no se mueve entre las CPU. La asignación se realiza mediante una directiva heredada del subproceso primario, que en última instancia es el subproceso que inició el proceso.

En muchas bases de datos que ven el equipo como una arquitectura de memoria uniforme multinúcleo, este escenario lleva a que la CPU inicial se llene primero y la CPU secundaria se llene más tarde. Es especialmente cierto si un subproceso central es responsable de asignar búferes de memoria. La solución es cambiar la política NUMA del hilo principal utilizado para iniciar el mongod procese ejecutando el siguiente comando:

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

Esta directiva asigna la memoria de forma circular en todos los nodos de la CPU, lo que garantiza una distribución uniforme en todos los nodos. No genera el mayor acceso de rendimiento a la memoria como en sistemas con varios hardware de CPU. Alrededor de la mitad de las operaciones de memoria son más lentas y sobre el bus, pero mongod no se ha escrito para dirigirse a 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 de /etc/init.d , es probable que no haya comenzado con la política NUMA correcta. Dependiendo de cuál sea la directiva predeterminada, pueden surgir problemas. El motivo es que los distintos instaladores de Linux® Package Manager para MongoDB también instalan un servicio con archivos de configuración en /etc/init.d que realizan el paso descrito anteriormente. Si instala y ejecuta MongoDB directamente desde un archivo ( .tar.gz), debe ejecutar manualmente mongood en numactl proceso.

El proceso MongoDB se comporta de forma diferente en diferentes directivas de asignación:

Algunas de las políticas pueden resultar en menos de toda la RAM disponible para el mongod proceso. A diferencia de MySQL, MongoDB evita activamente la paginación a nivel de sistema operativo y, por lo tanto, el mongod El proceso puede obtener menos memoria que parece estar disponible.

Intercambio swapping

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

Sistemas de archivos remotos remote-filesystems

Los sistemas de archivos remotos como NFS no se recomiendan para los archivos de datos internos de MongoDB (los archivos de base de datos de proceso de MongoDB) , porque introducen demasiada latencia. No confunda con el sistema de archivos compartido requerido para el almacenamiento de Oak Blob (FileDataStore), donde se recomienda NFS.

Leer más read-ahead

Ajuste la lectura con anticipación para que, cuando se registre una página mediante una lectura aleatoria, no se lean bloques innecesarios desde el disco. Estos resultados implican un consumo innecesario de ancho de banda de E/S.

Requisitos ® Linux linux-requirements

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

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

Tiempo de desactivación

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

Establezca el programador de discos NOOP

Haga lo siguiente:

En primer lugar, compruebe el programador de E/S configurado ejecutando el siguiente comando:

cat /sys/block/sdg/queue/scheduler

Si la respuesta es noopNo, no hay nada más que usted debe hacer.

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 en los que se ejecutan bases de datos MongoDB. Este valor asciende a 16 KB. Puede establecerlo si ejecuta lo siguiente:

sudo blockdev --setra <value> <device>

Habilitar NTP enable-ntp

Asegúrese de tener NTP instalado y en ejecución en el equipo que aloja 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 instalado el daemon NTP y iniciado correctamente, puede comprobar el desplazamiento de tiempo del servidor en el archivo de deriva.

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

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

Puede desactivarla siguiendo el siguiente procedimiento:

Deshabilitar NUMA disable-numa

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

Si este no es el caso, puede deshabilitar NUMA en un nivel de proceso individual. Para deshabilitarlo, ejecute los siguientes comandos:

numactl --interleave=all <path_to_process>

Donde <path_to_process> es el camino al proceso mongodo.

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

echo 0 > /proc/sys/vm/zone_reclaim_mode

Ajuste la configuración de ulimit para el proceso mongood 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. Esta configuración se puede realizar por usuario o por proceso.

Se recomienda configurar ulimit para el proceso mongood según el Configuración de límite recomendada de MongoDB.

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

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

Para obtener información sobre cómo utilizar mongoperf, vea la Documentación de MongoDB.

Pruebe el rendimiento de lectura en las máquinas virtuales que componen la implementación

Una vez instalada la herramienta, cambie al directorio de 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 (2 GB/s) y 500.000 IOPS ejecutándose a 32 hilos para todas las instancias de MongoDB.

Ejecute una segunda prueba, esta vez con archivos asignados de 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.

Pruebe 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 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 utiliza WMWare ESX para gestionar e implementar sus entornos virtualizados, asegúrese de realizar los siguientes ajustes desde la consola ESX para adaptarse al funcionamiento de MongoDB:

Amazon Web Service amazon-web-services

Para obtener documentación sobre cómo configurar MongoDB con Amazon Web Service, consulte la Configuración de la integración con AWS artículo en el sitio web de MongoDB.

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

Ver esta publicación en implementación segura de MongoDB para obtener consejos sobre cómo proteger la configuración de las 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 servir correctamente la implementación de MongoDB, el sistema operativo que aloja 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

AEM Una configuración típica de Dispatcher sirve entre diez y 20 veces más el rendimiento de solicitudes de una sola instancia de.

Como Dispatcher no tiene estado, puede escalarse horizontalmente con facilidad. En algunas implementaciones, se debe restringir el acceso de los autores a ciertos recursos. Se recomienda utilizar una instancia de Dispatcher con las instancias de autor.

AEM La ejecución de la ejecución sin un Dispatcher requiere la terminación SSL y el equilibrio de carga que debe realizar otra aplicación. AEM Esto es necesario porque las sesiones deben tener afinidad con la instancia de en la que se crean, un concepto conocido como conexiones fijas. El motivo es garantizar que las actualizaciones del contenido muestren una latencia mínima.

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

Configuración adicional additional-configuration

Conexiones fijas sticky-connections

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

AEM AEM Se recomienda que las conexiones fijas estén habilitadas para todas las capas internas y que las solicitudes de enrutamiento se dirijan a las instancias de, lo que anima a las solicitudes subsiguientes a llegar a la misma instancia de. Al hacerlo, se ayuda a minimizar la latencia que, de lo contrario, se aprecia cuando se actualiza el contenido entre instancias.

Caduca mucho long-expires

AEM De forma predeterminada, el contenido enviado desde un Dispatcher de tiene encabezados Last-Modified y Etag, sin indicación de la caducidad del contenido. Este flujo garantiza que la interfaz de usuario siempre obtenga la última versión del recurso. También significa que el explorador realiza una operación de GET para ver si el recurso ha cambiado. Como resultado, puede generar varias solicitudes a las que la respuesta HTTP es 304 (sin modificar), según la carga de la página. Para los recursos que no caducan, establecer un encabezado Expires y quitar los encabezados Last-Modified y ETag hacen que el contenido se almacene en caché. Además, no se realizan más solicitudes de actualización hasta que se cumpla la fecha del encabezado Caduca.

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 Expires. Para mitigar este flujo de trabajo, HtmlClientLibraryManager se puede configurar para que utilice direcciones URL inmutables para las bibliotecas de cliente.

Se garantiza que estas direcciones URL no cambiarán. Cuando el cuerpo del recurso contenido en la URL cambia, los cambios se reflejan en la URL, lo que garantiza que el explorador solicite 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. Además, este selector puede utilizarse para garantizar el comportamiento de caducidad correcto. El selector predeterminado sigue al lc-.*?-lc patrón. Las siguientes directivas de configuración httpd de Apache garantizan que todas las solicitudes que coinciden 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 olfatear no-sniff

Cuando el contenido se envía sin tipo de contenido, muchos exploradores intentan adivinar el tipo de contenido leyendo los primeros bytes. Este método se denomina "olfateo". El rastreo 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 añadir un no-sniff encabezado a recursos proporcionados por Dispatcher. Sin embargo, Dispatcher no almacena en caché los encabezados. AEM Como tal, significa que cualquier contenido servido desde el sistema de archivos local tiene su tipo de contenido determinado por su extensión, en lugar de utilizar el encabezado de tipo de contenido original de su servidor de origen de la.

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

Puede activar No olfatear 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 directiva de seguridad de contenido, también conocida como CSP. Esta configuración permite que una página cargue recursos de todos los dominios sujetos a las directivas predeterminadas de la zona protegida del explorador.

Es deseable restringir desde dónde se pueden cargar los recursos para evitar cargar código en el motor JavaScript desde servidores externos no fiables o no verificados.

CSP permite ajustar las directivas. 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 Directrices de tamaño de hardware.

Optimización de 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 simultáneas concurrent-installations

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

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

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

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