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

  • Configure el tamaño del registro de operaciones para adaptarlo a su 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úrese de que su conjunto de réplicas incluya al menos tres miembros votantes que contengan datos y que se ejecuten con registro y que emita escrituras con w: majority preocupación de escritura por cuestiones de disponibilidad y durabilidad.

  • Utilice nombres de host al configurar los miembros del conjunto de réplicas, en lugar de direcciones IP.

  • Asegúrese de que haya conectividad de red bidireccional completa entre todas las instancias.mongod

  • Asegúrese de que cada host pueda resolverse por sí mismo.

  • Asegúrese de que su conjunto de réplicas contenga un número impar de miembros con derecho a voto.

  • Asegúrese de que instancias mongod tengan 0 o 1 votos.

  • Para lograr una alta disponibilidad, implemente su conjunto de réplicas en un mínimo de 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.

  • Utilice NTP para sincronizar los relojes en todos los componentes de su clúster fragmentado.

  • Asegúrese de que haya conectividad de red bidireccional completa mongod entre, mongos y los servidores de configuración.

Registro en diario: motor de almacenamiento WiredTiger

  • Asegúrese de que todas las instancias utilicen registro en diario.

  • Coloque el diario en su propio disco de baja latencia para cargas de trabajo con escritura intensiva. Tenga en cuenta que esto afectará las copias de seguridad instantáneas, ya que los archivos que constituyen el estado de la base de datos residirán en volúmenes separados.

Hardware

  • Utilice unidades RAID10 y SSD para obtener un rendimiento óptimo.

  • SAN y virtualización:

    • Asegúrese de que cada mongod tenga IOPS aprovisionadas para su, o dbPath que 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 hardware en la nube

  • Windows Azure: Ajuste el keepalive de TCPtcp_keepalive_time () a 100120-. 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. Consultelas Notas de producción de Azure para obtener más información.

  • Utilice la versión 2.6.4 o posterior de MongoDB 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

  • Desactivar las páginas enormes transparentes. Consulta la configuración de páginas enormes transparentes para más información.

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

    • Desactivar las páginas enormes transparentes.Consulta "Usar tuned" y "ktune" para obtener instrucciones.

    • Establezca la lectura anticipada entre 8 y,32 independientemente del tipo de medio de almacenamiento. Consulte la configuración de lectura anticipada para obtener más información.

  • Utilice los programadores 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.

  • Deshabilite NUMA o configure vm.zone_reclaim_mode en 0 y ejecute instancias con mongod intercalación de nodos. Consulte: Hardware de MongoDB y NUMA para obtener más información.

  • Ajuste los ulimit valores en su hardware según su caso de uso. Si varias mongod instancias o se ejecutan con el mismo usuario, ajuste los mongos ulimit valores según corresponda. Consulte: Configuración de UNIX ulimit para implementaciones autogestionadas para obtener más información.

  • Utilice noatime para el dbPath punto de montaje.

  • Configure suficientes identificadores de archivo (fs.file-max), límite de PID del kernel (kernel.pid_max), máximo de subprocesos por proceso (kernel.threads-max) y máximo número de áreas de mapa de memoria por proceso (vm.max_map_count) para su implementación. Para sistemas grandes, los siguientes valores son 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 administrar el espacio de intercambio, realice una de las siguientes acciones:

    • Asegúrese de que su sistema tenga configurado el espacio de intercambio. Consulte la documentación de su sistema operativo para obtener información sobre el tamaño adecuado.

    • No asigne espacio de intercambio en su sistema y configure el kernel para deshabilitar el intercambio por completo.

  • 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 "último acceso" de NTFS. Esto es similar a deshabilitar atime en sistemas tipo Unix.

  • Formatear discos NTFS utilizando el valor predeterminado Allocation unit size de 4096 bytes.

Copias de seguridad

  • Programe pruebas periódicas de su proceso de copia de seguridad y restauración para tener estimaciones de tiempo a mano y verificar su funcionalidad.

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

    • ventana del registro de operaciones de replicación

    • afirmaciones

    • queues

    • fallos de página

  • Monitoree las estadísticas de hardware de sus servidores. En particular, preste atención al uso del disco, la CPU y el espacio disponible en disco.

    En ausencia de monitorización del espacio en disco, o como medida de precaución:

    • Cree un 4 archivo ficticio de GB en la unidad para garantizar que haya espacio disponible si el disco se storage.dbPath llena.

    • Una combinación de cron+df puede alertar cuando el espacio en disco alcanza un nivel máximo, si no hay otra herramienta de monitoreo disponible.

Equilibrio de carga

  • Configure balanceadores de carga para habilitar "sesiones persistentes" o "afinidad de cliente", con un tiempo de espera suficiente para las conexiones existentes.

  • Evite colocar balanceadores de carga entre componentes del conjunto de réplicas o del clúster MongoDB.

Seguridad

Para obtener una lista de medidas de seguridad para proteger su instalación de MongoDB, consulte la Lista de verificación de seguridad de MongoDB.

Volver

Cliente OpenSSL

Next

Notas de producción

En esta página