Compartir por

Confiabilidad en Azure NetApp Files

En este artículo, se describe la compatibilidad con la confiabilidad en Azure NetApp Files, que abarca la resistencia dentro de la región a través de zonas de disponibilidad e implementaciones de varias regiones.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

Azure NetApp Files es una solución de almacenamiento de archivos nativa de grado empresarial que se integra sin problemas en Azure y permite el uso compartido de archivos entre clientes mediante los protocolos Network File System (NFS) y Bloque de mensajes del servidor (SMB). Azure NetApp Files se diseñó para un alto rendimiento y proporciona almacenamiento de archivos escalable y seguro administrado como servicio.

Para usar Azure NetApp Files, es necesario configurar una cuenta de NetApp que contenga grupos de capacidad que hospeden volúmenes. Es posible configurar la capacidad y el rendimiento de forma independiente y administrar las opciones de protección de datos para que se ajusten a diversas necesidades. Puede habilitar la replicación entre volúmenes, incluso si están en ubicaciones diferentes.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Azure NetApp Files para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Azure NetApp Files en Azure Well-Architected Framework.

Errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Además de los tipos de error transitorios que afectan a cualquier solución basada en la nube, el mantenimiento planeado ocasional, como actualizaciones de plataforma, actualizaciones de servicio y actualizaciones de software, también afectan a Azure NetApp Files.

Desde una perspectiva del protocolo de archivos, como NFS y SMB, los errores transitorios no son perjudiciales si la aplicación puede controlar las pausas de entrada/salida (E/S) que podrían producirse durante estos eventos. Las pausas de E/S suelen ser cortas, desde unos segundos hasta 30 segundos. Algunas aplicaciones pueden requerir el ajuste para controlar las pausas de E/S.

El protocolo NFS es sólido y las operaciones de archivos de servidor cliente, por lo general, continúan con normalidad. Algunas aplicaciones podrían requerir ajustes para controlar las pausas de E/S durante un tiempo de 30 a 45 segundos. Asegúrese de conocer 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 usan el protocolo SMB, la configuración de protocolo estándar suele ser suficiente. Azure NetApp Files también admite la disponibilidad continua de SMB, lo que permite la conmutación por error transparente de SMB. La conmutación por error transparente de SMB elimina las interrupciones que provocan los eventos de mantenimiento del servicio. También mejora la confiabilidad y la experiencia del usuario.

La disponibilidad continua de SMB solo está disponible para aplicaciones específicas.

Para más recomendaciones, consulte Preguntas más frecuentes sobre resistencia de aplicaciones para Azure NetApp Files.

Soporte para zonas de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Azure NetApp Files admite implementaciones zonales de volúmenes. Use la característica de colocación de volumen de zona de disponibilidad en Azure NetApp Files para implementar cada volumen en una sola zona de disponibilidad de su elección. Esta característica solo se puede usar si Azure NetApp Files se encuentra presente en esa zona de disponibilidad y tiene capacidad suficiente. Si tiene aplicaciones sensibles a la latencia, es posible implementar un volumen en la misma zona de disponibilidad que los recursos de Azure Compute y otros servicios.

En el diagrama siguiente, las flechas naranjas con puntas de flecha sólidas representan cómo todas las máquinas virtuales (VM) dentro de la región de las redes virtuales emparejadas pueden acceder a todos los recursos de Azure NetApp Files. Las flechas verdes representan cómo las máquinas virtuales que acceden a los volúmenes de Azure NetApp Files en la misma zona comparten el dominio de error de la zona de disponibilidad. No hay replicación entre los distintos volúmenes en el nivel de plataforma.

Diagrama que muestra la ubicación del volumen de la zona de disponibilidad de Azure NetApp Files.

Una implementación de una sola zona no es suficiente para cumplir los requisitos de alta confiabilidad. Para replicar de forma asincrónica los datos entre volúmenes de diferentes zonas de disponibilidad, puede usar la replicación entre zonas. Debe configurar la replicación entre zonas por separado de la ubicación del volumen de la zona de disponibilidad.

Si se produce un error en una zona de disponibilidad, es responsable de detectar el error y cambiar a un volumen alternativo en una zona diferente.

Soporte para regiones

La replicación entre zonas está disponible en todas las regiones habilitadas para zona de disponibilidad que admitan Azure NetApp Files.

Consideraciones

  • La ubicación del volumen de zona de disponibilidad en Azure NetApp Files proporciona ubicación de volumen zonal. Verá baja latencia al conectarse a máquinas virtuales de la misma zona de disponibilidad. Sin embargo, la colocación de volumen de zona de disponibilidad no proporciona colocación de proximidad con máquinas virtuales u otros recursos, y el volumen podría estar en una parte física diferente del centro de datos.

  • Solo se permite la replicación entre distintas suscripciones de Azure si están dentro del mismo inquilino de Microsoft Entra.

  • Para más consideraciones sobre las zonas de disponibilidad en Azure NetApp Files, consulte Requisitos y consideraciones sobre el uso de la replicación entre zonas y la Administración de la colocación del volumen de zona de disponibilidad.

Costos

No hay ningún cargo adicional para habilitar la selección de ubicación de volumen de zona de disponibilidad en Azure NetApp Files. Solo paga por los grupos de capacidad y los recursos que implemente en estas zonas.

Los volúmenes de réplica se hospedan en un grupo de capacidad. El coste de la replicación entre zonas se basa en el tamaño y el nivel del grupo de capacidad aprovisionado. No hay ningún coste adicional para la replicación de datos.

Configurar soporte de zonas de disponibilidad

Debe configurar por separado la ubicación del volumen y la replicación entre zonas.

Operaciones normales

En esta sección se describe qué esperar al implementar varios volúmenes de Azure NetApp Files en zonas de disponibilidad independientes, la replicación entre zonas esté habilitada y todas las zonas de disponibilidad se encuentren operativas.

  • Enrutamiento de tráfico entre zonas: las solicitudes entrantes se enrutan al volumen específico, que se encuentra en la zona de disponibilidad que seleccione.

  • Replicación de datos entre zonas: La replicación entre zonas de Azure NetApp Files significa que todos los cambios en el volumen de origen se replican de forma asincrónica en volúmenes de destino. Es posible decidir con qué frecuencia se producirá la replicación. La replicación entre zonas admite tres programaciones de replicación: cada 10 minutos, cada hora y cada día.

    Importante

    La programación de replicación de 10 minutos no se admite para grandes volúmenes que usen la replicación entre zonas.

Experiencia de reducción de zona

En esta sección se describe qué esperar al implementar varios volúmenes de Azure NetApp Files en zonas de disponibilidad independientes, la replicación entre zonas esté habilitada y haya una interrupción de zona de disponibilidad.

  • Detección y respuesta: Es responsable de detectar la pérdida de una zona de disponibilidad e iniciar una conmutación por error.

    Para supervisar el estado del volumen de Azure NetApp Files, puede usar métricas de Azure Monitor. Azure Monitor detecta anomalías que indican escenarios de zona inactiva a través de métricas en tiempo real, como operaciones de entrada y salida por segundo (IOPS), latencia y utilización de capacidad. Es posible configurar alertas y notificaciones para enviar a los administradores para que respondan inmediatamente reequilibrando recursos compartidos de archivos o iniciando la conmutación por error u otros protocolos de recuperación ante desastres.

    La conmutación por error es un proceso manual. Cuando necesite activar el volumen de destino, como cuando quiera conmutar por error a la zona de disponibilidad de destino, debe interrumpir el emparejamiento de replicación y, a continuación, montar el volumen de destino. Para obtener más información, consulte Conmutación por error al volumen de destino.

  • Solicitudes activas: durante un evento de zona inactiva, las solicitudes activas pueden experimentar interrupciones o aumentar las latencias.

  • Pérdida de datos esperada: la cantidad de pérdida de datos o el objetivo de punto de recuperación (RPO) que se puede esperar durante una conmutación por error de zona dependerá de la programación de replicación entre zonas configurada.

    Programación de replicación RPO típico
    Cada 10 minutos 20 minutos
    Cada hora Dos horas
    Diariamente Menos de 48 horas

  • Tiempo de inactividad esperado: la conmutación por error a otra zona requiere que interrumpa la relación de emparejamiento para activar el volumen de destino y proporcionar acceso a datos de lectura y escritura en el segundo sitio. Después de desencadenar el emparejamiento para que se interrumpa, espere que la conmutación por error se complete en un minuto.

    Sin embargo, la cantidad total de tiempo de inactividad o el objetivo de tiempo de recuperación (RTO), que se puede esperar durante una conmutación por error de zona dependerá de varios factores, incluyendo el tiempo que tarden los sistemas o procesos en detectar la pérdida de la zona e iniciar los procesos de conmutación por error. También es importante decidir si se automatizará la respuesta o si se requerirán pasos manuales. Para aquellas configuraciones que estén bien preparadas, el proceso general normalmente requerirá de unos minutos a una hora para completarse.

  • Reenrutamiento del tráfico: Es responsable de redirigir el tráfico de la aplicación para conectarse al volumen de destino recién activo. Para obtener más información, consulte Conmutación por error al volumen de destino.

Recuperación de zona

La conmutación por recuperación es un proceso manual que requiere que se realice una operación de resincronización, restablecer la replicación y volver a montar el volumen de origen para que el cliente acceda. Para más información, consulte Administración de la recuperación ante desastres mediante Azure NetApp Files.

Pruebas para detectar fallos en la zona

Puede probar la configuración de replicación entre zonas de forma segura mediante instantáneas del volumen. Para más información sobre un enfoque de alto nivel para probar la configuración de replicación entre zonas, consulte Prueba de la recuperación ante desastres para Azure NetApp Files.

Soporte multirregional

De forma predeterminada, Azure NetApp Files es un servicio de una sola región. Si la región deja de estar disponible, los volúmenes almacenados en esa región tampoco están disponibles. Para mejorar la resistencia si se produce una interrupción regional, Azure NetApp Files admite la replicación entre regiones. Es posible replicar datos de forma asincrónica desde un volumen de Azure NetApp Files (el origen) de una región a otro volumen de Azure NetApp Files (el destino) de otra región que Microsoft preseleccione. Esta funcionalidad le permite realizar la conmutación por error de la aplicación crítica en caso de un desastre o una interrupción en toda la región.

Nota:

También puede replicar un único volumen en otra zona de disponibilidad y en otra región. Para más información, consulte Comprender la replicación de Azure NetApp Files.

Soporte para regiones

La región secundaria a la que puede replicar los volúmenes depende de la región primaria. Para más información, consulte pares de regiones admitidos.

Consideraciones

Solo se permite la replicación entre distintas suscripciones de Azure si están dentro del mismo inquilino de Microsoft Entra.

Para conocer otras consideraciones relacionadas con la replicación entre regiones en Azure NetApp Files, consulte Requisitos y consideraciones para usar la replicación entre regiones.

Costos

Los cargos de replicación entre regiones se basan en la cantidad de datos replicados. Para obtener más información y algunos escenarios de ejemplo, consulte Modelo de costes de la replicación entre regiones.

Configuración de la compatibilidad con varias regiones

Operaciones normales

En esta sección se describe qué esperar cuando los volúmenes de Azure NetApp Files estén configurados para usar la replicación entre regiones y ambas regiones se encuentren operativas.

  • Enrutamiento del tráfico entre regiones: Las solicitudes entrantes se enrutan al volumen específico, que se encuentra en la región primaria.

  • Replicación de datos entre regiones: La replicación entre regiones de Azure NetApp Files significa que todos los cambios en el volumen de origen se replican de forma asincrónica en volúmenes de destino. Es posible decidir con qué frecuencia se producirá la replicación. La replicación entre regiones admite tres programaciones de replicación: cada 10 minutos, cada hora y cada día.

    Importante

    La programación de replicación de 10 minutos no se admite para grandes volúmenes que usen la replicación entre regiones.

  • Supervisar el estado de replicación: Puede supervisar el estado de la relación de emparejamiento y puede configurar alertas para notificarle si el retraso de replicación aumenta más allá del umbral esperado. Para más información, consulte Visualización del estado y supervisión de la relación de replicación.

Experiencia a nivel de regiones

En esta sección se describe qué esperar cuando los volúmenes de Azure NetApp Files estén configurados para usar la replicación entre regiones y haya una interrupción de la región primaria.

  • Detección y respuesta: Es responsable de detectar la pérdida de una región e iniciar una conmutación por error.

    Para supervisar el estado del volumen de Azure NetApp Files, puede usar métricas de Azure Monitor. Azure Monitor detecta anomalías que indican un escenario de reducción regional a través de métricas en tiempo real, como IOPS, latencia y utilización de capacidad. Es posible configurar alertas y notificaciones para enviar a los administradores para que respondan inmediatamente reequilibrando recursos compartidos de archivos o iniciando la conmutación por error u otros protocolos de recuperación ante desastres.

    La conmutación por error es un proceso manual. Cuando necesite activar el volumen de destino, como cuando quiera conmutar por error a la región de destino, debe interrumpir el emparejamiento de replicación y, a continuación, montar el volumen de destino. Para obtener más información, consulte Conmutación por error al volumen de destino.

  • Solicitudes activas: Durante un evento de región inactiva, las solicitudes activas pueden experimentar interrupciones o mayores latencias.

  • Pérdida de datos esperada: la cantidad de pérdida de datos o RPO que se puede esperar durante una conmutación por error de regiones dependerá de la programación de replicación entre regiones configurada.

    Programación de replicación RPO típico
    Cada 10 minutos Menos de 20 minutos
    Cada hora Menos de dos horas
    Diariamente Menos de 48 horas

  • Tiempo de inactividad esperado: la conmutación por error a otra región requiere interrumpir la relación de emparejamiento para activar el volumen de destino y proporcionar acceso a datos de lectura y escritura en el segundo sitio. Después de desencadenar el emparejamiento para que se interrumpa, espere que la conmutación por error se complete en un minuto.

    Sin embargo, la cantidad total de tiempo de inactividad o RTO que se puede esperar durante una conmutación por error de zonas dependerá de varios factores, incluyendo el tiempo que tarden los sistemas o procesos en detectar la pérdida de la zona e iniciar los procesos de conmutación por error. También es importante decidir si se automatizará la respuesta o si se requerirán pasos manuales. Para aquellas configuraciones que estén bien preparadas, el proceso general normalmente requerirá de unos minutos a una hora para completarse.

  • Reenrutamiento del tráfico: Es responsable de redirigir el tráfico de la aplicación para conectarse al volumen de destino recién activo. Para obtener más información, consulte Conmutación por error al volumen de destino.

Recuperación de regiones

Después de que la región primaria se recupere, usted será responsable de la conmutación por restauración. La conmutación por recuperación es un proceso manual que requiere que se realice una operación de resincronización, restablecer la replicación y volver a montar el volumen de origen para que el cliente acceda. Para más información, consulte Administración de la recuperación ante desastres mediante Azure NetApp Files.

Pruebas de errores de región

Puede probar la configuración de replicación entre regiones de forma segura mediante instantáneas del volumen. Para más información sobre un enfoque de alto nivel para probar la configuración de replicación entre regiones, consulte Prueba de la recuperación ante desastres para Azure NetApp Files.

Copias de seguridad

La copia de seguridad de Azure NetApp Files amplía las funcionalidades de protección de datos de Azure NetApp Files al proporcionar una solución de copia de seguridad totalmente administrada para la recuperación, el archivo y el cumplimiento a largo plazo. Las copias de seguridad que crea el servicio se almacenan en Azure Storage, independientemente de las instantáneas de volumen que estén disponibles para la recuperación o clonación a corto plazo. Las copias de seguridad que realice el servicio se podrán restaurar en nuevos volúmenes de Azure NetApp Files de la región. La copia de seguridad de Azure NetApp Files admite tanto copias de seguridad basadas en directivas (programadas) como copias de seguridad manuales (a petición).

Para mayor seguridad, las instantáneas de Azure NetApp Files agregan estabilidad, escalabilidad y capacidad de recuperación rápida sin afectar al rendimiento. Proporcionan la base para otras soluciones de redundancia, como la copia de seguridad, la replicación entre regiones y la replicación entre zonas.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Contenido relacionado

  • Last updated on