Confiabilidad en Azure Load Balancer

Azure Load Balancer es un servicio de equilibrio de carga de nivel 4 (TCP/UDP) que distribuye el tráfico entrante entre instancias correctas de servicios. Load Balancer proporciona alta disponibilidad y rendimiento de red a las aplicaciones con latencia ultra baja.

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 hacer que Load Balancer sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Load Balancer.

Recomendaciones de implementación de producción

Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, rendimiento, seguridad, costo y operaciones. Para comprender cómo estas áreas influyen entre sí y contribuir a una solución confiable de Load Balancer, consulte Procedimientos recomendados de arquitectura para Load Balancer en Azure Well-Architected Framework.

Introducción a la arquitectura de confiabilidad

Un equilibrador de carga puede ser público o interno. Un equilibrador de carga público acepta el tráfico de Internet a través de un recurso de dirección IP pública. Solo se puede acceder a un equilibrador de carga interno dentro de la red virtual y otras redes que se conecten a la red virtual.

Cada equilibrador de carga consta de varios componentes, entre los que se incluyen:

• Configuraciones de IP de front-end, que reciben tráfico. Un equilibrador de carga público recibe tráfico en una dirección IP pública. Un equilibrador de carga interno recibe tráfico en una dirección IP dentro de la red virtual.
• Grupos de back-end, que contienen una colección de instancias de back-end que pueden recibir tráfico, como máquinas virtuales individuales que ejecutan la aplicación.
• Reglas de equilibrio de carga, que definen cómo se debe distribuir el tráfico de un front-end a un grupo de back-end.
• Sondeos de estado, que supervisan la disponibilidad de las instancias de back-end.

Para más información sobre cómo funciona Load Balancer, consulte Componentes de Load Balancer.

Para las soluciones implementadas globalmente, puede implementar un equilibrador de carga global, que es un tipo especial de equilibrador de carga público diseñado para enrutar el tráfico entre diferentes implementaciones regionales de la solución. Un equilibrador de carga global proporciona una única dirección IP anycast. Enruta el tráfico al equilibrador de carga regional más cercano en función de la proximidad del cliente y el estado de salud regional. Para obtener más información, consulte Resilience to region-wide failures (Resistencia a errores en toda la región).

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.

Al usar Load Balancer, tenga en cuenta los procedimientos recomendados siguientes para minimizar el riesgo de errores transitorios que afectan a la aplicación:

• Implementación de la lógica de reintento. Los clientes deben implementar mecanismos de reintento adecuados para errores de conexión transitorios, incluidas las estrategias de retroceso exponencial.

• Configure sondeos de estado con tolerancia. Configure las sondas de salud para equilibrar la detección rápida de fallas y evitar falsos positivos durante problemas transitorios.

• Supervisar la asignación de puertos SNAT. En el caso de las conexiones salientes, supervise la asignación de puertos SNAT y configure reglas de salida para evitar errores de conexión transitorios debido al agotamiento de puertos.

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 se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

Load Balancer se puede implementar como con redundancia de zona configurando cada configuración de IP de front-end que cree. Una configuración ip de front-end con redundancia de zona se sirve simultáneamente desde una infraestructura independiente en varias zonas. Esta configuración garantiza que los errores de zona no afecten a la capacidad del equilibrador de carga para recibir y distribuir el tráfico.

En el diagrama siguiente se muestra un equilibrador de carga público con redundancia de zona, que se configura mediante la creación de una dirección IP pública con redundancia de zona:

En el diagrama siguiente se muestra un equilibrador de carga interno mediante una configuración similar con redundancia de zona:

En regiones sin zonas de disponibilidad, los equilibradores de carga se crean en una configuración no zonal o regional mediante una configuración de front-end sin una zona configurada. Si la región experimenta una interrupción, los equilibradores de carga nozonales podrían experimentar tiempo de inactividad.

Instancias de back-end y zonas de disponibilidad

La configuración de la zona de disponibilidad de las instancias de back-end es independiente de la configuración IP de front-end del equilibrador de carga.

Distribuya las instancias de back-end entre zonas mediante la configuración del servicio pertinente, de acuerdo con las características de confiabilidad del servicio al que pertenecen y la arquitectura que diseñe.

Por ejemplo, cuando se usan máquinas virtuales, un enfoque de diseño común para cargas de trabajo de producción es lograr resistencia de zona colocando varias máquinas virtuales zonales en las zonas 1, 2 y 3. Para el equilibrio de carga, puede crear un equilibrador de carga con redundancia de zona y configurar esas máquinas virtuales como instancias de back-end dentro del equilibrador de carga. Los sondeos de estado del balanceador de carga eliminan automáticamente las máquinas virtuales no saludables de la rotación independientemente de su ubicación de zona.

Sin embargo, si decide implementar las máquinas virtuales en la misma zona de disponibilidad, todavía puede implementar una configuración ip de front-end con redundancia de zona en el equilibrador de carga, que se muestra en el diagrama siguiente:

Requisitos

Compatibilidad con regiones: Los equilibradores de carga con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad.

Cost

La configuración de la zona de disponibilidad no cambia la forma en que se factura un equilibrador de carga. La facturación se basa en el número de reglas configuradas y los datos procesados, independientemente de la configuración de zona. Para más información, consulte Precios de Azure Load Balancer.

Configurar soporte de zonas de disponibilidad

Al trabajar con Load Balancer, se establece la compatibilidad con la zona de disponibilidad en la configuración de IP de front-end.

• Cree un nuevo equilibrador de carga con soporte para zonas de disponibilidad.

  • En el caso de los equilibradores de carga públicos, la configuración de IP de front-end adopta automáticamente la configuración de zona de disponibilidad del recurso de dirección IP pública que asocia a él. Para que la configuración de ip de front-end sea redundante en la zona, cree o seleccione una dirección IP pública con redundancia de zona. Las direcciones IP públicas son con redundancia de zona de forma predeterminada. Para ver los pasos detallados, consulte Creación de un equilibrador de carga público para equilibrar la carga de las máquinas virtuales mediante Azure Portal.

  • En el caso de los equilibradores de carga internos, al configurar la dirección IP de front-end del equilibrador de carga, se establece el tipo de compatibilidad de zona de disponibilidad en la configuración de IP de front-end. Para ver los pasos detallados, consulte Creación de un equilibrador de carga interno para equilibrar la carga de las máquinas virtuales mediante Azure Portal.

• Cambie la configuración de zona de disponibilidad de un equilibrador de carga existente. Para cambiar la configuración de la zona de disponibilidad de un equilibrador de carga existente, debe reemplazar la configuración de IP de front-end. Puede usar este enfoque para pasar de una configuración de IP zonal a una front-end con redundancia zonal. El enfoque de alto nivel es:

  1. Cree una nueva configuración de IP de front-end con la configuración de zona de disponibilidad deseada.

     En el caso de los equilibradores de carga públicos, cree primero una nueva dirección IP pública que use la configuración de zona de disponibilidad deseada. A continuación, vuelva a configurar el equilibrador de carga para agregar una configuración ip de front-end que haga referencia a esa dirección IP pública.

     En el caso de los equilibradores de carga internos, vuelva a configurar el equilibrador de carga para agregar una nueva configuración de IP de front-end con la configuración de disponibilidad deseada. Este paso asigna una nueva dirección IP privada desde la subred.

  2. Vuelva a configurar las reglas de equilibrio de carga para usar la nueva configuración de IP de front-end.

     Importante

     Esta operación requiere que vuelva a configurar los clientes para enviar tráfico a la nueva dirección IP de front-end. En función de los clientes, el proceso puede requerir tiempo de inactividad.

  3. Quite la configuración anterior de IP de front-end.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando un equilibrador de carga usa una configuración ip de front-end con redundancia de zona y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: El equilibrio de carga se puede realizar en cualquier zona de disponibilidad. El tráfico se envía a instancias back-end saludables especificadas en el grupo de back-end, sin tener en cuenta en qué zona de disponibilidad se encuentra la instancia.

• Replicación de datos entre zonas. Load Balancer es un servicio de paso a través de red que no almacena ni replica los datos de la aplicación. Incluso si habilita la persistencia de sesión en el equilibrador de carga, no se almacena ningún estado en el equilibrador de carga. La persistencia de la sesión ajusta el proceso de hash para enrutar las solicitudes a la misma instancia de back-end. Sin embargo, no se garantiza la persistencia de la sesión. Cuando cambia el grupo de back-end, se vuelve a calcular la distribución de las solicitudes de cliente. Este proceso se realiza sin almacenar ni sincronizar el estado.

  El servicio mantiene su estado de configuración con replicación sincrónica entre zonas, lo que garantiza la coherencia inmediata de las reglas de equilibrio de carga, las configuraciones de sondeo de estado y la pertenencia al grupo de back-end en todas las zonas.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando un equilibrador de carga usa una configuración ip de front-end con redundancia de zona y hay una interrupción de zona de disponibilidad.

• Detección y respuesta: la plataforma Azure es responsable de detectar un error en una zona de disponibilidad y responder. No es necesario hacer nada para iniciar una conmutación por error de la zona.

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

• Solicitudes activas: los flujos TCP/UDP existentes dentro de la zona con errores se restablecen y deben ser reintentados por el cliente. Los clientes deben tener un control de errores transitorio suficiente implementado, incluidos los reintentos automatizados.

• Pérdida de datos esperada: como servicio de red sin estado, Load Balancer no almacena datos de aplicación, por lo que no se produce ninguna pérdida de datos en la capa del equilibrador de carga.

• Tiempo de inactividad esperado: No se espera ningún tiempo de inactividad para los equilibradores de carga con redundancia de zona, ya que el equilibrador de carga sigue funcionando desde zonas saludables.

  Sin embargo, si el error afecta a los servicios de proceso de la zona, las máquinas virtuales u otros recursos que se encuentran en la zona afectada podrían no estar disponibles. Los sondeos de estado del equilibrador de carga están diseñados para detectar estos errores y enrutar el tráfico a instancias alternativas en otra zona, en función del algoritmo de equilibrio de carga y del estado de salud de las instancias de backend.

• Enrutamiento de tráfico: el equilibrador de carga continúa operando desde las zonas saludables. El servicio Load Balancer mantiene la misma dirección IP frontal durante los fallos de zona. Este comportamiento significa que no es necesario aplicar actualizaciones de DNS ni volver a configurar clientes. Las nuevas conexiones se establecen automáticamente a través de las zonas saludables restantes.

Recuperación de zona

Cuando se recupera una zona de disponibilidad, Load Balancer reanuda automáticamente las operaciones normales. El front-end de redundancia zonal comienza automáticamente a procesar el tráfico desde la zona recuperada, junto con otras zonas operativas. Las comprobaciones de estado de la zona recuperada reanudan la evaluación de las instancias del servidor backend.

Si el error de zona también afectó a los servicios de proceso en la zona, entonces, a medida que las instancias de back-end en la zona recuperada superan las comprobaciones de salud, se agregan automáticamente de nuevo al grupo de back-end en buen estado. La distribución del tráfico se reequilibra en todas las zonas disponibles según el algoritmo de equilibrio de carga y el estado de salud de las instancias de back-end.

Prueba de fallos de zona

La plataforma Azure administra el enrutamiento del tráfico, la respuesta ante caída de zona y la recuperación. Estas funcionalidades están totalmente administradas, por lo que no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

Puede usar Azure Chaos Studio para simular el error de una máquina virtual en una sola zona. Chaos Studio proporciona errores integrados para las máquinas virtuales, incluido apagar una máquina virtual. Puede usar estas funcionalidades para simular los fallos de zona y probar los procesos de failover.

Resistencia a errores en toda la región

Los equilibradores de carga públicos e internos se implementan en una sola región de Azure. Si la región deja de estar disponible, los equilibradores de carga de esa región tampoco están disponibles. Sin embargo, Azure Load Balancer proporciona compatibilidad nativa con varias regiones a través de Load Balancer global, lo que permite el equilibrio de carga entre regiones de Azure. También puede implementar otros servicios de equilibrio de carga para enrutar y realizar una conmutación por error entre regiones de Azure.

Equilibradores de carga globales

El Global Load Balancer proporciona una única dirección IP anycast estática que enruta automáticamente el tráfico a la implementación regional óptima, basada en la proximidad del cliente y el estado de operación regional. Load Balancer global puede ayudar a mejorar la confiabilidad y el rendimiento de la aplicación.

Con Global Load Balancer, se implementan varios equilibradores de carga públicos en distintas regiones y el equilibrador de carga global actúa como front-end global. Si los servidores backend de una región tienen un problema, el tráfico cambia automáticamente a regiones saludables y sin cambios de DNS porque la dirección IP de anycast sigue siendo constante y direcciona el tráfico hacia otra región.

Para obtener más información, consulte Global Load Balancer.

Soluciones personalizadas de varias regiones para la resistencia

Azure proporciona una variedad de servicios de equilibrio de carga que se ajustan a diferentes requisitos. Puede seleccionar un equilibrador de carga que cumpla los requisitos de resistencia y que se adapte al tipo de aplicación. Para obtener más información, consulte Opciones de equilibrio de carga.

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.

El Acuerdo de Nivel de Servicio de Azure Load Balancer se aplica cuando hay al menos dos máquinas virtuales correctas configuradas como instancias de back-end. El Acuerdo de Nivel de Servicio excluye el tiempo de inactividad debido al agotamiento de puertos SNAT o a los grupos de seguridad de red (NSG) que bloquean el tráfico.

Contenido relacionado

• Documentación de Azure Load Balancer
• Equilibrador de carga global
• Introducción a la confiabilidad de Azure