Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /
Administración
/ / /

Lista de verificación de operaciones para implementaciones autogestionadas

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.

  • 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: majority write 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 mongod tengan 0 o 1 votos.

  • Para alta disponibilidad, implementa tu set de réplicas en al menos tres centros de datos.

  • 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 mongos de 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, mongos y 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.

  • 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.

  • 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 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.

  • 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.

  • 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 tuned en RHEL / CentOS, debe personalizar su perfil de tuned. Muchos de los perfiles tuned que se entregan con RHEL / CentOS pueden afectar negativamente el rendimiento con sus configuraciones por defecto. Personaliza el perfil de tuned elegido 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 none para unidades NVMe o SSD.

  • Utiliza el planificador de discos none para 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 defecto none será suficiente.

    Utiliza kyber para ejecutar varias cargas de trabajo en la misma VM o en tu propio centro de datos. kyber mejora la interpolación de E/S bajo contención y reduce el impacto de los vecinos ruidosos. Además, kyber funciona 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, 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.

  • 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.

  • Programa pruebas periódicas de tu proceso de respaldo y restauración para tener estimaciones de tiempo a mano y verificar su funcionamiento.

  • 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.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.

  • 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.

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

Notas de producción

En esta página