Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/
Gestión
Docs Home
/
Gestión
Docs Home
/
Gestión

Lista de verificación de operaciones para implementaciones autogestionadas

La siguiente lista de verificación, junto con el La lista de verificaciónde desarrollo proporciona recomendaciones para ayudarlo a evitar problemas en su implementación de MongoDB de producción.

Sistema de archivos

Replicación

  • Verifique que todos los miembros del conjunto de réplicas no ocultos estén aprovisionados de manera idéntica en términos de 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 del registro de operaciones de replicación debe cubrir el tiempo necesario para restaurar un miembro del conjunto de réplicas desde la última copia de seguridad.

      Nota

      La ventana del registro de operaciones de replicación no necesita cubrir el tiempo necesario para restaurar un miembro del conjunto de réplicas mediante la sincronización inicial, ya que los registros del registro de operaciones se extraen durante la copia de datos. Sin embargo, el miembro que se restaura debe tener suficiente espacio en disco en la base de datos local para almacenar temporalmente estos registros del registro de operaciones durante esta 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: majority write concern para garantizar la disponibilidad y durabilidad.

  • Utilice nombres de host al configurar los miembros del conjunto 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 mongod tengan 0 o 1 votos.

  • 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 de mongos acuerdo con las pautas 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, mongos y los servidores de configuración.

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 mongod tenga IOPS aprovisionados para su dbPath, o tenga su propia unidad física o LUN.

    • Evite las funciones de memoria dinámica, como el aumento de memoria, al ejecutar 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

  • Si ejecuta MongoDB 8.0 o posterior, active las páginas enormes transparentes.

  • Si ejecuta MongoDB 7.0 o una versiónanterior, desactive las páginas enormes transparentes.

  • Ajuste la configuración de lectura anticipada 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 usa tuned en RHEL/CentOS, debe personalizar su perfil tuned. Muchos de los perfiles tuned que vienen con RHEL/CentOS pueden afectar negativamente al rendimiento con su configuración predeterminada. Personalice el perfil tuned que elija para:

  • Utilice los planificadores de disco none para unidades NVMe o SSD.

  • Utilice el programador de discos none para las unidades virtualizadas en las máquinas virtuales invitadas. Si no hay vecinos, o si estos no generan patrones de E/S intensos, habrá poca contención de HBA y el programador predeterminado none será suficiente.

    Utilice kyber para ejecutar varias cargas de trabajo en la misma máquina virtual o en su propio centro de datos. kyber mejora la interpolación de E/S en contención y reduce el impacto de vecinos ruidosos. Además, kyber funciona eficientemente en entornos alojados en servidores propios, como la virtualización local y las cargas de trabajo coubicadas en una gran máquina virtual en la nube. Sin embargo, kyber solo 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 mongod instancias con intercalado de nodos. Consulta: MongoDB y hardware NUMA para obtener más información.

  • Ajusta los valores de ulimit en tu hardware según tu caso de uso. Si hay varias instancias de mongod o mongos ejecutándose bajo el mismo usuario, escalar los valores de ulimit en consecuencia. Consulta: Configuraciones UNIX ulimit para implementaciones autogestionadas para obtener más información.

  • Utiliza noatime para el punto de montaje dbPath.

  • 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-max valor de 98000,

    • kernel.pid_max valor de 64000,

    • kernel.threads-max valor de 64000 y

    • vm.max_map_count valor 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 keepalive TCP 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 atime en 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

  • Utilice MongoDB Cloud Manager u Ops Manager, una solución local disponible en MongoDB Enterprise Advanced u otro sistema de monitorización, para supervisar las métricas clave de la base de datos y configurar alertas. Incluya alertas para las siguientes métricas:

    • atraso de la replicación

    • oplog window de replicación

    • afirmaciones

    • queues

    • fallos 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.dbPath para garantizar espacio disponible si el disco se llena.

    • Una combinación de cron+df puede 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.

Volver

Cliente OpenSSL

Next

Notas de producción

En esta página