Preguntas más frecuentes sobre resistencia de aplicaciones para Azure NetApp Files

  • Artículo

En este artículo se responden las preguntas más frecuentes (P+F) sobre la resistencia de aplicaciones para Azure NetApp Files.

¿Qué se recomienda para controlar posibles interrupciones de la aplicación debido a eventos de mantenimiento del servicio de almacenamiento?

Azure NetApp Files pueden someterse a un mantenimiento planeado ocasional (por ejemplo, actualizaciones de plataforma, actualizaciones de servicio o de software). Desde una perspectiva del protocolo de archivos (NFS/SMB), las operaciones de mantenimiento no son disruptivas, siempre y cuando la aplicación pueda controlar las pausas de E/S que podrían producirse brevemente durante estos eventos. Las pausas de E/S suelen ser cortas, desde unos segundos hasta 30 segundos. El protocolo NFS es especialmente sólido y las operaciones de archivo cliente-servidor continúan con normalidad. Algunas aplicaciones pueden requerir un ajuste para administrar las pausas de E/S de entre 30 y 45 segundos. Por lo tanto, asegúrese de que conoce la configuración de resistencia de la aplicación para hacer frente a los eventos de mantenimiento del servicio de almacenamiento. En el caso de las aplicaciones interactivas humanas que aprovechan el protocolo SMB, la configuración de protocolo estándar suele ser suficiente.

Importante

Para garantizar una arquitectura resistente, es fundamental reconocer que la nube funciona bajo un modelo de responsabilidad compartida. Este modelo abarca la plataforma en la nube de Azure, sus servicios de infraestructura, la capa del sistema operativo y los proveedores de aplicaciones. Cada uno de estos componentes desempeña un papel fundamental en el control correcto de posibles interrupciones de las aplicaciones que pueden surgir durante los eventos de mantenimiento del servicio de almacenamiento.

¿Es necesario tomar precauciones especiales para las aplicaciones basadas en SMB?

Sí, ciertas aplicaciones basadas en SMB requieren la conmutación por error transparente de SMB. La conmutación por error transparente de SMB facilita las operaciones de mantenimiento en el servicio Azure NetApp Files sin interrumpir la conectividad con las aplicaciones de servidor que almacenan los datos en volúmenes SMB y acceden a ellos. Para facilitar la conmutación por error transparente de SMB, Azure NetApp Files ahora admite la opción de recursos compartidos con disponibilidad continua de SMB. El uso de la disponibilidad continua de SMB solo se admite para cargas de trabajo en:

Precaución

Las aplicaciones personalizadas no se admiten con la disponibilidad continua de SMB y no se pueden usar con volúmenes habilitados para la disponibilidad continua de SMB.

Estoy ejecutando IBM MQ en Azure NetApp Files. ¿Qué precauciones puedo tomar para evitar interrupciones debido a eventos de mantenimiento del servicio de almacenamiento a pesar de usar el protocolo NFS?

Si ejecuta la aplicación IBM MQ en una configuración de archivos compartidos, donde los datos y registros de IBM MQ se almacenan en un volumen de Azure NetApp Files, se recomiendan las siguientes consideraciones para mejorar la resistencia durante los eventos de mantenimiento del servicio de almacenamiento:

Nota:

El número de mensajes que debe procesar cada par de instancias múltiples de MQ depende en gran medida de su entorno específico. Debe decidir cuántos pares de instancias múltiples de MQ serían necesarios o cuáles serían las reglas de escalado o reducción vertical.

La arquitectura de escalabilidad horizontal constaría de varios pares de instancias múltiples de la implementados IBM MQ detrás de una instancia de Azure Load Balancer. Las aplicaciones configuradas para comunicarse con IBM MQ se configurarían para comunicarse con las instancias de IBM MQ mediante Azure Load Balancer. Para obtener compatibilidad relacionada con IBM MQ en volúmenes NFS compartidos, debe obtener soporte técnico del proveedor en IBM.

Estoy ejecutando Apache ActiveMQ con LevelDB o KahaDB en Azure NetApp Files. ¿Qué precauciones puedo tomar para evitar interrupciones debido a eventos de mantenimiento del servicio de almacenamiento a pesar de usar el protocolo NFS?

Si ejecuta Apache ActiveMQ, se recomienda implementar la alta disponibilidad de ActiveMQ con cajas de seguridad de almacenamiento conectables.

Los modelos de alta disponibilidad de ActiveMQ garantizan que una instancia de agente siempre está en línea y puede procesar el tráfico de mensajes. Los dos modelos de alta disponibilidad de ActiveMQ más comunes implican el uso compartido de un sistema de archivos a través de una red. El propósito es proporcionar LevelDB o KahaDB a las instancias de agente activas y pasivas. Estos modelos de alta disponibilidad requieren que se obtenga y mantenga un bloqueo de nivel de sistema operativo en un archivo de los directorios LevelDB o KahaDB, denominado "bloqueo". Hay algunos problemas con este modelo de alta disponibilidad de ActiveMQ. Pueden provocar una situación de "no maestro", donde la réplica no es consciente de que puede bloquear el archivo. También pueden dar lugar a una configuración de "maestro-maestro" que da como resultado daños en el índice o el diario y, en última instancia, la pérdida de mensajes. La mayoría de estos problemas se derivan de factores fuera del control de ActiveMQ. Por ejemplo, un cliente NFS mal optimizado puede hacer que los datos de bloqueo se vuelvan obsoletos bajo carga, lo que provoca un tiempo de inactividad "sin maestro" durante la conmutación por error.

Dado que la mayoría de los problemas con esta solución de alta disponibilidad se derivan de bloqueos de archivos de nivel de sistema operativo inexactos, la comunidad de ActiveMQ introdujo el concepto de una caja de seguridad de almacenamiento conectable en la versión 5.7 del agente. Este enfoque permite que un usuario aproveche un medio diferente del bloqueo compartido, mediante un bloqueo de base de datos JDBC de nivel de fila en lugar de un bloqueo del sistema de archivos de nivel de sistema operativo. Para obtener soporte técnico o consultoría sobre las implementaciones y arquitecturas de alta disponibilidad de ActiveMQ, debe ponerse en contacto con OpenLogic by Perforce.

Estoy ejecutando Apache ActiveMQ con LevelDB o KahaDB en Azure NetApp Files. ¿Qué precauciones puedo tomar para evitar interrupciones debido a eventos de mantenimiento del servicio de almacenamiento a pesar de usar el protocolo SMB?

La recomendación general del sector es no ejecutar el almacenamiento compartido de KahaDB en CIFS/SMB. Si tiene problemas para mantener el estado de bloqueo preciso, consulte la página de la caja de seguridad de almacenamiento conectable de JDBC, que puede proporcionar un mecanismo de bloqueo más confiable. Para obtener soporte técnico o consultoría sobre las implementaciones y arquitecturas de alta disponibilidad de ActiveMQ, debe ponerse en contacto con OpenLogic by Perforce.

Estoy ejecutando Boomi en Azure NetApp Files. ¿Qué precauciones puedo tomar para evitar interrupciones debidas a eventos de mantenimiento del servicio de almacenamiento?

Si ejecuta Boomi, se recomienda seguir los procedimientos recomendados de Boomi para la alta disponibilidad en tiempo de ejecución y la recuperación ante desastres.

Boomi recomienda el uso de Boomi Molecule para implementar la alta disponibilidad de Boomi Atom. Los requisitos del sistema de Boomi Molecule indican que se puede usar NFS con el bloqueo NFS activado (soporte NLM) o archivos compartidos SMB. En el contexto de Azure NetApp Files, los volúmenes NFSv4.1 tienen compatibilidad con NLM.

Boomi recomienda el uso de archivos compartidos SMB con las máquinas virtuales de Windows; para NFS, Boomi recomienda las máquinas virtuales de Linux.

Nota:

Azure NetApp Files de disponibilidad continua compartidos no son compatibles con Boomi.

Pasos siguientes