La siguiente lista de verificación, junto con el Lista de verificación de desarrollo, ofrece recomendaciones para ayudarte a evitar problemas en tu implementación de MongoDB en producción.
Sistema de archivos
Alinee las particiones de su disco con su configuración de RAID.
Evita utilizar unidades NFS para tu
dbPath. El uso de discos NFS puede generar un rendimiento degradado e inestable. Consulta: Sistemas de archivos remotos (NFS) para obtener más información.Los usuarios de VMware deben utilizar unidades virtuales VMware a través de NFS.
Linux/Unix: formatea tus unidades en XFS o EXT4. Si es posible, utiliza XFS, ya que en general ofrece un mejor rendimiento con MongoDB.
Con el motor de almacenamiento WiredTiger, el uso de XFS es altamente recomendado para evitar los problemas de rendimiento que se presentan al usar EXT4 con WiredTiger.
Si usas RAID, puede que necesites configurar XFS con la geometría de RAID.
Windows: use el sistema de archivos NTFS. No utilices ningún sistema de archivos FAT (es decir, FAT 16/32/exFAT).
Replicación
Verifique que todos los miembros no ocultos del conjunto de réplicas estén aprovisionados de manera idéntica en términos de su RAM, CPU, disco, configuración de red, etc.
Configura el tamaño de la oplog para adaptarlo a tu caso de uso:
La oplog window de replicación debe cubrir el mantenimiento normal y las ventanas de inactividad para evitar la necesidad de una resincronización completa.
La ventana de oplog de replicación debe cubrir el tiempo necesario para restaurar un miembro del set de réplicas desde la última copia de seguridad.
Nota
La oplog window de replicación no necesita cubrir el tiempo necesario para restaurar un miembro del set de réplicas mediante una sincronización inicial, ya que los registros de oplog se extraen durante la copia de datos. Sin embargo, el nodo que se va a restaurar debe tener suficiente espacio en disco en la base de datos local para almacenar temporalmente estos registros oplog durante la etapa de copia de datos.
Asegúrate de que tu set de réplicas incluya al menos tres nodos con derecho a voto que tengan datos y estén ejecutando con registrar en la bitácora, y que emitas guardados con
w: majoritywrite concern para garantizar la disponibilidad y durabilidad.Utiliza nombres de host al configurar miembros del set de réplicas, en lugar de direcciones IP.
Asegura una conectividad completa y bidireccional entre todas las instancias de
mongod.Asegúrese de que cada host pueda resolver su propio nombre.
Asegúrate de que tu set de réplicas contenga un número impar de miembros con derecho a voto.
Asegúrate de que las instancias de
mongodtengan0o1votos.Para alta disponibilidad, implementa tu set de réplicas en al menos tres centros de datos.
particionado
Coloque sus servidores de configuración en hardware dedicado para un rendimiento óptimo en clústeres grandes. Asegúrese de que el hardware tenga suficiente RAM para almacenar los archivos de datos íntegramente en la memoria y que tenga almacenamiento dedicado.
Implemente enrutadores
mongosde acuerdo con las directrices de Configuración de producción.Utiliza NTP para sincronizar los relojes en todos los componentes de tu clúster fragmentado.
Asegura la conectividad de red bidireccional completa entre
mongod,mongosy los servidores de configuración.Usa CNAMEs para identificar los servidores de configuración ante el clúster, de modo que puedas cambiar el nombre y la numeración sin tiempo de inactividad.
Registrar en la bitácora: WiredTiger Storage Engine
Asegúrate de que todas las instancias utilicen registrar en la bitácora.
Coloca el diario en un disco propio de baja latencia para cargas de trabajo intensivas en escritura. Tenga en cuenta que esto afectará a las copias de seguridad de tipo snapshot, ya que los archivos que constituyen el estado de la base de datos residirán en volúmenes separados.
hardware
Utiliza RAID10 y discos SSD para un rendimiento óptimo.
SAN y virtualización:
Asegúrate que cada
mongodtenga IOPS aprovisionados para sudbPath, o tenga su propia unidad física o LUN.Evite las funcionalidades de memoria dinámica, como la expansión de memoria, al ejecutarse en entornos virtuales.
Evite colocar todos los miembros del conjunto de réplicas en la misma SAN, ya que la SAN puede ser un único punto de falla.
Implementaciones en nube Hardware
Windows Azure: Ajuste el keepalive TCP (
tcp_keepalive_time) a 100-120. El tiempo de espera de inactividad de TCP en el balanceador de carga de Azure es demasiado lento para el comportamiento de agrupación de conexiones de MongoDB. Consulta: Notas de producción de Azure para más información.Utilice MongoDB versión 2.6.4 o posterior en sistemas con almacenamiento de alta latencia, como Windows Azure, ya que estas versiones incluyen mejoras de rendimiento para esos sistemas.
Configuración del sistema operativo
Linux
Desactiva Transparent Hugepages. Ver Configuraciones de Transparent Huge Pages para más información.
Ajuste la configuración de readahead en los dispositivos que almacenan sus archivos de base de datos.
Para el motor de almacenamiento WiredTiger, establezca la anticipación de lectura entre 8 y 32, independientemente del tipo de medio de almacenamiento (disco giratorio, SSD, etc.), a menos que las pruebas demuestren un beneficio medible, repetible y confiable en un valor de anticipación de lectura más alto.
El soporte comercial de MongoDB puede ofrecer consejos y orientación sobre configuraciones alternativas de lectura anticipada.
Si utiliza
tuneden RHEL / CentOS, debe personalizar su perfil detuned. Muchos de los perfilestunedque se entregan con RHEL / CentOS pueden afectar negativamente el rendimiento con sus configuraciones por defecto. Personaliza el perfil detunedelegido para:Desactiva las hugepages transparentes. Consulte Uso de tuned y ktune para obtener instrucciones.
Configure la lectura anticipada entre 8 y 32 independientemente del tipo de medio de almacenamiento. Consulta Configuraciones de Readahead para más información.
Utilice los planificadores de disco
nonepara unidades NVMe o SSD.Utiliza el planificador de discos
nonepara unidades virtualizadas en máquinas virtuales de invitados. Si no hay vecinos, o si los vecinos no producen patrones de I/O intensos, habrá poca contención de HBA y el scheduler por defectononeserá suficiente.Utiliza
kyberpara ejecutar varias cargas de trabajo en la misma VM o en tu propio centro de datos.kybermejora la interpolación de E/S bajo contención y reduce el impacto de los vecinos ruidosos. Además,kyberfunciona de forma eficaz en situaciones autohospedadas, como la virtualización on-premises y cargas de trabajo ubicadas en una gran VM en la nube. Sin embargo,kybersolo está disponible en kernels de Linux a partir de la versión 4.12.Desactive NUMA o configure vm.zone_reclaim_mode en 0 y ejecutar
mongodinstancias con intercalado de nodos. Consulta: MongoDB y hardware NUMA para obtener más información.Ajusta los valores de
ulimiten tu hardware según tu caso de uso. Si hay varias instancias demongodomongosejecutándose bajo el mismo usuario, escalar los valores deulimiten consecuencia. Consulta: Configuraciones UNIXulimitpara implementaciones autogestionadas para obtener más información.Utiliza
noatimepara el punto de montajedbPath.Configure suficientes manejadores de archivos (
fs.file-max), límite de pid del kernel (kernel.pid_max), número máximo de subprocesos por proceso (kernel.threads-max) y número máximo de áreas de mapas de memoria por proceso (vm.max_map_count) para tu implementación. Para sistemas grandes, los siguientes valores proporcionan un buen punto de partida:fs.file-maxvalor de 98000,kernel.pid_maxvalor de 64000,kernel.threads-maxvalor de 64000 yvm.max_map_countvalor de 131060
Para gestionar el espacio de intercambio, realice una de las siguientes acciones:
Asegúrate de que tu sistema tenga configurado el espacio de swap. Consulta la documentación de tu sistema operativo para obtener detalles sobre el tamaño adecuado.
No asignar espacio de intercambio en tu sistema y configurar el kernel para deshabilitar completamente el intercambio.
Asegúrate de que la configuración del sistema TCP keepalive por defecto esté establecida correctamente. Un valor de 120 suele proporcionar un mejor rendimiento para sets de réplicas y clústeres particionados. Consulta: ¿El tiempo de
keepaliveTCP afecta las implementaciones de MongoDB? en Preguntas frecuentes para obtener más información.
Windows
Considere deshabilitar las actualizaciones de "última hora de acceso" de NTFS. Esto es análogo a deshabilitar
atimeen sistemas tipo Unix.Formatee discos NTFS usando el por defecto Allocation unit size de 4096 bytes.
Copias de seguridad
Programa pruebas periódicas de tu proceso de respaldo y restauración para tener estimaciones de tiempo a mano y verificar su funcionamiento.
Monitoring
Usa MongoDB Cloud Manager o Ops Manager, una solución on-premises disponible en MongoDB Enterprise Advanced u otro sistema de supervisión para supervisar los principales métricas de la base de datos y configurar alertas para ellos. Incluya alertas para las siguientes métricas:
atraso de la replicación
oplog window de replicación
afirmaciones
queues
Errores de página
Supervisa las estadísticas de hardware de los servidores. En particular, presta atención al uso del disco, la CPU y el espacio en disco disponible.
En ausencia de supervisión del espacio en disco, o como medida de precaución:
Crear un archivo ficticio de 4 GB en la unidad
storage.dbPathpara garantizar espacio disponible si el disco se llena.Una combinación de
cron+dfpuede generar alertas cuando el espacio en disco alcanza un nivel crítico, si no hay otras herramientas de supervisión disponibles.
Equilibrio de carga
Configura los balanceadores de carga para habilitar las "sesiones persistentes" o la "afinidad de cliente", con un tiempo de espera suficiente para las conexiones existentes.
Evite colocar balanceadores de carga entre los componentes del clúster de MongoDB o del set de réplicas.
Seguridad
Para obtener una lista de medidas de seguridad para proteger tu instalación de MongoDB, consulta la Lista de comprobación de seguridad de MongoDB.