sql >> Base de Datos >  >> NoSQL >> MongoDB

Cinco consejos para un mejor alojamiento de MongoDB en Azure

La plataforma informática en la nube de Azure ha experimentado una gran variedad de mejoras en los últimos dos años, que apenas se parecen a la plataforma original con la que Microsoft comenzó en 2010. ScaleGrid fue una de las primeras plataformas de alojamiento de MongoDB compatibles con Azure y hemos seguido evolucionando nuestra oferta a medida que evoluciona Azure.

Ya sea que haya estado usando Azure por un tiempo o recién esté comenzando a usar Azure para el hospedaje de MongoDB, aquí hay algunos patrones de diseño de arquitectura que debe considerar para asegurarse de que está aprovechando el Plataforma Azure para la mejor experiencia de alojamiento MongoDB.

    1. Plataforma Azure Resource Manager (ARM)

      Aproveche el poder de la nueva plataforma Azure Resource Manager (ARM). Si todavía está en la plataforma Azure Classic, ¡ahora es el momento de mudarse! Hay varios beneficios de migrar a la nueva plataforma ARM, que incluyen el aprovechamiento de discos administrados, redes virtuales e instancias reservadas. Todos los beneficios se detallan en la publicación de blog Beneficios de migrar IaaS a Azure Resource Manager.

    2. Redes virtuales de Azure y grupos de seguridad de red

      Las bases de datos se implementan mejor en subredes privadas que no están expuestas a Internet. Azure le permite crear su propia red virtual (VNET) e implementar sus servidores de bases de datos en subredes específicas. También puede manejar el control de acceso mediante la creación de reglas de grupo de seguridad de red (NSG) y asignar una IP pública a su servidor de base de datos (solo) si necesita que sea accesible a través de Internet. Como parte de nuestro modelo Traiga su propia nube, permitimos que nuestros clientes implementen sus clústeres de MongoDB en su propia VNET para aprovechar los controles de seguridad avanzados de VNET y NSG.

    3. Conjunto de disponibilidad de Azure y zonas de disponibilidad

      Los conjuntos de disponibilidad son esenciales para distribuir los nodos de su clúster en diferentes hardware. De esta manera, una sola falla de hardware no afecta a todos sus nodos. Nuestra recomendación es crear un conjunto de disponibilidad por réplica. Azure también ha introducido recientemente zonas de disponibilidad para protegerlo de interrupciones en el nivel del centro de datos. Puede distribuir sus réplicas entre las zonas de disponibilidad para obtener un tiempo de actividad del 99,99 %.

      Cinco consejos para mejorar el alojamiento de #MongoDB en AzureHaga clic para twittear

    4. Tipos de instancias de Azure

      Es muy importante elegir el tipo de instancia de Azure correcto para su carga de MongoDB; no todos los tipos de instancias son adecuados para MongoDB. En general, debería buscar tipos de instancias "optimizadas para memoria" o tipos de instancias "optimizadas para almacenamiento".

      La última serie Ev3 de instancias optimizadas para memoria suele ser un excelente punto de partida para la mayoría de las cargas de trabajo de MongoDB. Si necesita más CPU que la proporcionada por E2 v3, puede considerar los tipos de instancia Dv3 de "propósito general".

      Las instancias del modo 'Ráfaga':'B1S, B1MS, B2MS' suelen ser una buena opción para cargas de trabajo pequeñas, entornos de desarrollo/prueba, etc. A medida que sus datos aumentan, el La serie L4 'optimizada para almacenamiento' con discos SSD locales de Azure encaja perfectamente; más detalles en la sección Disco de Azure a continuación. En general, el tipo de instancia correcto depende de su carga de trabajo, por lo que es importante iterar y probar la carga de los distintos tipos de instancia con su carga de trabajo.

    5. Discos Azure

      Azure ofrece una variedad de tipos de discos para manejar diferentes cargas de trabajo:

      • Discos heredados (estándar y premium)

        A los efectos de esta discusión, no vamos a considerar los discos heredados de Azure. Si usa discos heredados, debería considerar pasarse a discos administrados.

      • Discos administrados (estándar y premium)

        Los discos administrados de Azure simplifican en gran medida la administración de sus discos informáticos en Azure. Ofrecen varias ventajas sobre los discos heredados:

        • No hay necesidad de preocuparse por las cuentas de almacenamiento.
        • No debe preocuparse por el tamaño de la cuenta de almacenamiento ni por los límites de rendimiento.
        • Instantáneas sencillas y creación de nuevos discos a partir de instantáneas.
        • Convierta fácilmente de estándar a premium y viceversa.
        • Aproveche los conjuntos de disponibilidad mejorados para aplicarlos a sus discos.

        Puede encontrar los detalles completos sobre las diferencias entre los discos administrados y los discos heredados en la documentación de Azure.

        Premium Managed Disks también ofrece diferentes garantías de IOPS según el tamaño del disco. Para los clústeres de producción de MongoDB, recomendamos encarecidamente Premium Managed Disks, mientras que para entornos de desarrollo/prueba, Standard Managed Disks es una buena opción.
      • Discos SSD locales

        Los tipos de instancias de Azure "almacenamiento optimizado" proporcionan grandes discos SSD locales que ofrecen el mejor rendimiento en Azure. Es ideal para clústeres grandes que necesitan mucha entrada/salida (E/S) de disco. Nuestros clústeres de alto rendimiento de Azure para MongoDB utilizan las instancias de la serie L. Sin embargo, los discos SSD locales son "efímeros":cuando detiene la instancia, los datos desaparecen. Por lo tanto, es importante tener mucho cuidado al usar discos locales. Nuestra recomendación es usar una réplica que esté en Managed Premium Disks para garantizar la seguridad de los datos.

Sé que prometimos 5 consejos, pero aquí hay uno extra para el camino:

  1. Aproveche las instancias reservadas de Azure

    Azure ahora admite instancias reservadas (RI), también conocidas como AWS. Puede comprar instancias reservadas de Azure por períodos de uno o tres años por adelantado y reducir considerablemente los costos de alojamiento de MongoDB hasta en un 82 %.