Confiabilidad en Azure NAT Gateway

Azure NAT Gateway es un servicio de traducción de direcciones de red (NAT) totalmente administrado que proporciona conectividad saliente a Internet para los recursos conectados a la red virtual privada. El servicio proporciona la traducción de direcciones de red de origen (SNAT) para las conexiones salientes y la traducción de direcciones de red de destino (DNAT) exclusivamente para los paquetes de respuesta a conexiones originadas desde salidas. Dado que se encuentra en las rutas de acceso de red críticas, Azure NAT Gateway está diseñado para ser un servicio altamente resistente.

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.

En este artículo se describe cómo puede hacer que azure NAT Gateway sea resistente a una variedad de posibles interrupciones y problemas, incluidos los errores transitorios y las interrupciones de zona de disponibilidad. También resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure NAT Gateway.

Recomendaciones de implementación de producción

En el caso de las cargas de trabajo de producción, se recomienda que usted:

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

Una puerta de enlace NAT es un recurso que se implementa. Para usar la puerta de enlace NAT como ruta predeterminada para el tráfico saliente de Internet, la adjunte a una o varias subredes de la red virtual. No es necesario configurar rutas personalizadas ni otras configuraciones de enrutamiento.

Arquitectura física

Internamente, una puerta de enlace NAT consta de una o varias instancias, que representan la infraestructura subyacente necesaria para operar el servicio.

Azure NAT Gateway implementa una arquitectura distribuida mediante redes definidas por software para proporcionar alta confiabilidad y escalabilidad. El servicio funciona en varios dominios de error, lo que le permite sobrevivir a varios errores de componentes de infraestructura sin impacto en el servicio. Azure administra las operaciones de servicio subyacentes, incluida la distribución entre dominios de error y redundancia de infraestructura.

Para más información sobre la arquitectura y la redundancia de Azure NAT Gateway, consulte Recurso de Azure NAT Gateway.

Resistencia a 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.

El agotamiento de puertos SNAT es una situación en la que las aplicaciones realizan varias conexiones independientes a la misma dirección IP y puerto, lo que agota los puertos SNAT disponibles para la dirección IP saliente. El agotamiento de puertos SNAT puede manifestarse como un error transitorio en la aplicación. Para reducir la probabilidad de errores transitorios relacionados con la traducción de direcciones de red, debe:

• Minimice la probabilidad de agotamiento de puertos SNAT. Configure las aplicaciones para controlar SNAT correctamente mediante la implementación de la agrupación de conexiones y la administración adecuada del ciclo de vida de la conexión.

• Implemente suficientes direcciones IP públicas. Una sola puerta de enlace NAT admite varias direcciones IP públicas y cada dirección IP pública proporciona un conjunto independiente de puertos SNAT.

• Supervise la métrica de disponibilidad de la ruta de acceso de datos de la puerta de enlace NAT. Use Azure Monitor para detectar posibles problemas de conectividad al principio. Configure alertas para errores de conexión y agotamiento de puertos SNAT para identificar y solucionar de forma proactiva las condiciones de error transitorias antes de que afecten a la conectividad saliente de las aplicaciones. Para más información, consulte ¿Qué son las métricas y alertas de Azure NAT Gateway?.

• Evite establecer valores de tiempo de espera de inactividad elevados. Los valores de tiempo de espera de inactividad que son significativamente mayores que los 4 minutos predeterminados para las conexiones de puerta de enlace NAT pueden contribuir al agotamiento de puertos SNAT durante grandes volúmenes de conexión.

Para obtener instrucciones completas sobre la administración de conexiones y la solución de problemas específicos de Azure NAT Gateway, consulte Solución de problemas de conectividad de Azure NAT Gateway.

Resistencia a errores de zona 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 NAT Gateway admite zonas de disponibilidad en configuraciones con redundancia de zona y zonales:

• Con redundancia de zona: Cuando se usa la SKU StandardV2 de Azure NAT Gateway, la redundancia de zona se habilita automáticamente. La redundancia de zona distribuye las instancias de la puerta de enlace NAT en todas las zonas de disponibilidad de la región. Al usar una configuración con redundancia de zona, puede mejorar la resistencia y la confiabilidad de las cargas de trabajo de producción.

  

• Zonal: Si usa la SKU Estándar (v1), puede crear opcionalmente una configuración zonal. Una puerta de enlace NAT zonal se implementa en una sola zona de disponibilidad que seleccione. Cuando la puerta de enlace NAT se implementa en una zona específica, proporciona conectividad saliente a Internet explícitamente desde esa zona. No se permiten direcciones IP públicas zonales de una zona de disponibilidad diferente. Todo el tráfico de subredes conectadas se enruta a través de la puerta de enlace NAT, incluso si se encuentra en una zona de disponibilidad diferente.

  

  Si una puerta de enlace NAT dentro de una zona de disponibilidad experimenta una interrupción, todas las máquinas virtuales de las subredes conectadas no se pueden conectar a Internet, incluso si esas máquinas virtuales están en zonas de disponibilidad correctas.

  Importante

  La asignación a una sola zona de disponibilidad solo se recomienda cuando la latencia entre zonas es demasiado alta para sus necesidades y después de comprobar que la latencia no cumple sus requisitos. Por sí mismo, un recurso zonal no proporciona resistencia a una interrupción de zona de disponibilidad. Para mejorar la resiliencia de un recurso zonal, debe desplegar explícitamente recursos independientes en múltiples zonas de disponibilidad y configurar el enrutamiento del tráfico y la conmutación por error. Para obtener más información, consulte Recursos zonales y resistencia de zona.

  Si implementa máquinas virtuales en varias zonas de disponibilidad y necesita usar puertas de enlace NAT zonales, puede crear pilas zonales en cada zona de disponibilidad. Para crear pilas zonales, debe implementar:

  • Varias subredes: se crean subredes independientes para cada zona de disponibilidad en lugar de usar una subred que abarque zonas.
  • Puertas de enlace NAT zonales: cada subred obtiene su propia puerta de enlace NAT que se implementa en la misma zona de disponibilidad que la propia subred.
  • Asignación manual de máquinas virtuales: coloque explícitamente cada máquina virtual en la zona de disponibilidad correcta y en su subred correspondiente.

  

Si implementa una puerta de enlace NAT estándar (v1) y no especifica una zona de disponibilidad, la puerta de enlace NAT no es zonal, lo que significa que Azure selecciona la zona de disponibilidad. Si alguna zona de disponibilidad de la región tiene una interrupción, es posible que la puerta de enlace NAT se vea afectada. No se recomienda una configuración no zonal porque no proporciona protección contra interrupciones de zona de disponibilidad.

Requisitos

• Compatibilidad con regiones: Las puertas de enlace NAT zonales y con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad.

• SKU: Para implementar una puerta de enlace NAT con redundancia de zona, debe usar la SKU standardV2. Para implementar una puerta de enlace NAT zonal, debe usar la SKU estándar. Se recomienda usar la SKU StandardV2.

• Direcciones IP públicas: Los requisitos para las direcciones IP públicas asociadas a una puerta de enlace NAT dependen de la configuración de implementación y la SKU:

  SKU de puerta de enlace NAT	Tipo de soporte de zona de disponibilidad	Requisitos de ip pública
  StandardV2	Con redundancia de zona	Debe implementarse con la dirección IP pública standardV2.
  Estándar	Zonal	La dirección IP pública estándar debe ser con redundancia de zona o zonal en la misma zona que la puerta de enlace NAT.
  Estándar	No zonal	La dirección IP pública estándar puede ser con redundancia de zona o zonal en cualquier zona.

Cost

No hay ningún costo adicional para utilizar el soporte de zona de disponibilidad en Azure NAT Gateway. Para más información sobre los precios, consulte Precios de Azure NAT Gateway.

Configurar soporte de zonas de disponibilidad

• Nuevos recursos: Los pasos de implementación dependen de la configuración de zona de disponibilidad que desea usar para la puerta de enlace NAT.

  • Redundante en zona: Para implementar una nueva puerta de enlace NAT redundante en zona mediante la SKU StandardV2, consulte Crear una puerta de enlace NAT estándar V2 de Azure.

  • Zonal: Para implementar una nueva puerta de enlace NAT zonal mediante la SKU estándar, consulte Creación de una puerta de enlace NAT. Al crear la puerta de enlace NAT, seleccione su zona de disponibilidad en lugar de seleccionar Sin zona.

• Habilite la compatibilidad con la zona de disponibilidad: La configuración de la zona de disponibilidad de Azure NAT Gateway no se puede cambiar después de la implementación. Para modificar la configuración de la zona de disponibilidad, debe implementar una nueva puerta de enlace NAT con la configuración de zona deseada.

  Para actualizar de una puerta de enlace NAT Estándar a StandardV2, también debe crear una nueva dirección IP pública que use la SKU StandardV2.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando las puertas de enlace NAT están configuradas para la compatibilidad con la zona de disponibilidad y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: la forma en que el tráfico de la máquina virtual se enruta a través de la puerta de enlace NAT depende de la configuración de la zona de disponibilidad que usa la puerta de enlace NAT.

  • Con redundancia de zona: El tráfico se puede enrutar a través de una instancia de puerta de enlace NAT dentro de cualquier zona de disponibilidad.

  • Zonal: Cada instancia de puerta de enlace NAT funciona independientemente dentro de su zona de disponibilidad asignada. El tráfico saliente de los recursos de subred se enruta a través de la zona de la puerta de enlace NAT, incluso si la máquina virtual está en una zona diferente.

• Replicación de datos entre zonas: Azure NAT Gateway no realiza la replicación de datos entre zonas, ya que es un servicio sin estado para la conectividad saliente. Cada instancia de puerta de enlace NAT funciona independientemente dentro de su zona de disponibilidad sin necesidad de sincronización con instancias de otras zonas.

Comportamiento durante un fallo de zona

En esta sección se describe qué ocurre cuando una puerta de enlace NAT está configurada para ser compatible con zonas de disponibilidad y no hay suficientes zonas de disponibilidad.

• Detección y respuesta: La responsabilidad de la detección y respuesta depende de la configuración de zona de disponibilidad que usa la puerta de enlace NAT.

  • Con redundancia de zona: Azure NAT Gateway detecta e responde a fallos en una zona de disponibilidad. No necesita hacer nada para iniciar una conmutación por error de una zona de disponibilidad.

  • Zonal: es responsable de implementar la recuperación frente a errores en el nivel de aplicación, a modo de métodos de conectividad alternativos o puertas de enlace NAT en otras zonas.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  También puede usar la métrica de disponibilidad de la ruta de acceso de datos de la puerta de enlace NAT para supervisar el estado de la puerta de enlace NAT. Puede configurar alertas en la métrica de disponibilidad de datapath para detectar problemas de conectividad.

• Solicitudes activas: Lo que sucede con las solicitudes activas depende de la configuración de zona de disponibilidad que usa la puerta de enlace NAT.

  • Con redundancia de zona: se quitan las conexiones salientes activas a través de instancias en la zona con errores y los clientes deben volver a intentarlas. Los intentos de conexión posteriores fluyen a través de una instancia de puerta de enlace NAT en otra zona de disponibilidad.

  • Zonal: se pierden las conexiones salientes activas a través de una puerta de enlace NAT zonal con errores. Debe decidir si y cómo volver a establecer la conectividad a través de rutas de conectividad alternativas. Las aplicaciones deben implementar la lógica de reintento para controlar los errores de conexión.

    Si se vuelve a enrutar el tráfico, ya que cambia la dirección IP pública de salida, es posible que sea necesario renegociar las sesiones TCP.

• Pérdida de datos esperada: No se produce ninguna pérdida de datos porque Azure NAT Gateway es un servicio sin estado para la conectividad saliente. El estado de conexión se vuelve a crear cuando se vuelven a establecer las conexiones.

• Tiempo de inactividad esperado: El tiempo de inactividad esperado depende de la configuración de zona de disponibilidad que use la puerta de enlace NAT.

  • Con redundancia de zona: es posible que se interrumpan las conexiones existentes de la zona con errores. Los clientes pueden reintentar las conexiones inmediatamente y las solicitudes se enrutarán a una instancia de otra zona. Todas las conexiones restantes de zonas saludables se mantienen.

  • Zonal: La conectividad saliente se pierde hasta que se recupera la zona o hasta que se vuelve a enrutar el tráfico a través de métodos de conectividad alternativos o puertas de enlace NAT en otras zonas.

• Reenrutamiento del tráfico: El comportamiento de reenrutamiento del tráfico depende de la configuración de zona de disponibilidad que usa la puerta de enlace NAT.

  • Con redundancia de zona: las nuevas solicitudes de conexión se enrutan a través de una instancia de puerta de enlace NAT en una zona de disponibilidad sin errores.

    Es poco probable que las máquinas virtuales de la zona de disponibilidad afectada sigan funcionando. Sin embargo, en caso de que exista un error parcial en la zona que hace que Azure NAT Gateway no esté disponible mientras las máquinas virtuales siguen funcionando, las conexiones salientes de las máquinas virtuales de la zona afectada se enrutarán a través de una instancia de Gateway NAT en otra zona.

  • Zonal: es responsable de implementar cualquier recuperación frente a errores en el nivel de aplicación, como métodos de conectividad alternativos o puertas de enlace NAT en otras zonas.

Recuperación de zona

No se requiere ninguna intervención manual para las operaciones de failback porque Azure NAT Gateway es un servicio sin estado.

Cuando se recupera una zona de disponibilidad, las instancias de puerta de enlace NAT de esa zona estarán disponibles automáticamente para las nuevas conexiones salientes. Las conexiones establecidas a través de instancias de puerta de enlace NAT en otras zonas durante la interrupción continúan usando sus rutas de conectividad actuales hasta que las conexiones finalizan de forma natural.

Prueba de fallos de zona

Las opciones para probar errores de zona dependen de la configuración de zona de disponibilidad que usa la instancia.

• Con redundancia de zona: la plataforma de Azure NAT Gateway administra el enrutamiento del tráfico, la recuperación frente a errores y la restauración de puertas de enlaces NAT Gateways con redundancia de zona. Dado que esta característica está totalmente administrada, no es necesario iniciar nada ni validar los procesos de error de zona de disponibilidad.

• Zonal: es responsable de preparar y probar los protocolos de recuperación frente a errores en caso de que se produzca un error de zona.

Resistencia a errores en toda la región

Azure NAT Gateway es un servicio de una sola región que funciona dentro de los límites de una región de Azure específica. El servicio no incluye funciones nativas multirregionales ni recuperación automática frente a errores entre regiones. Si una región deja de estar disponible, las puertas de enlace NAT de esa región tampoco están disponibles.

Si diseña un enfoque de red con varias regiones, debe implementar puertas de enlace NAT independientes en cada región.

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.

Azure NAT Gateway está cubierto por el SLA NAT de Red Virtual de Azure. El Acuerdo de Nivel de Servicio (SLA) de disponibilidad solo se aplica cuando tiene dos o más máquinas virtuales operativas y excluye de los cálculos de tiempo de inactividad el agotamiento de puertos SNAT.

Contenido relacionado

• Introducción a Azure NAT Gateway
• Puerta de enlace NAT y zonas de disponibilidad
• Solución de problemas de conectividad de Azure NAT Gateway
• Estado de los recursos de Azure NAT Gateway