Load Balancer y Availability Zones

Azure Load Balancer admite escenarios de zonas de disponibilidad. Puede usar Standard Load Balancer para aumentar la disponibilidad en todo el escenario mediante la alineación de recursos con zonas y su distribución entre ellas. Revise este documento para conocer estos conceptos y la guía de diseño de un escenario básico.

Una instancia de Load Balancer puede ser con redundancia de zona, zonal o no zonal. Para configurar las propiedades relacionadas con la zona (mencionadas anteriormente) para el equilibrador de carga, seleccione el tipo de servidor front-end adecuado que se requiera.

Redundancia de zona

En una región con Availability Zones, una instancia de Standard Load Balancer puede tener redundancia de zona. El tráfico se sirve mediante una dirección IP única.

Una única dirección IP de servidor front-end sobrevivirá a los errores de zona. Se puede usar la IP de front-end para llegar a todos los miembros del grupo de back-end (no afectados), independientemente de la zona. Se puede producir un error en una o más zonas de disponibilidad y la ruta de acceso de datos sobrevive siempre que una zona de la región permanezca correcta.

La dirección IP del front-end se suministra a la vez en varias implementaciones de infraestructura independientes de varias zonas de disponibilidad. Los reintentos o el restablecimiento se realizarán correctamente en otras zonas a las que no haya afectado por el error de zona.

La ilustración muestra un equilibrador de carga estándar con redundancia de zona que dirige el tráfico de tres zonas diferentes a tres subredes diferentes en una configuración con redundancia de zona.

Ilustración: Equilibrador de carga con redundancia de zona

Zonal

Puede optar por tener un front-end garantizado para una sola zona, lo que se conoce como zonal. Este escenario significa que cualquier flujo de entrada o de salida es atendido por una sola zona en una región. El front-end comparte destino con el estado de la zona. La ruta de acceso de datos no se ve afectada por errores en zonas distintas a la garantizada. Puede utilizar front-end zonales para exponer una dirección IP por cada zona de disponibilidad.

Además, se admite el uso de servidores front-end zonales directamente para puntos de conexión con equilibrio de carga dentro de cada zona. Puede usar esta configuración para exponer puntos de conexión con equilibrio de carga por zona para supervisar de forma individual cada zona. En el caso de los puntos de conexión públicos, puede integrarlos con un producto de equilibrio de carga de DNS como Traffic Manager y usar un nombre DNS único.

La ilustración muestra tres equilibradores de carga estándar zonales que dirigen el tráfico de una zona a tres subredes diferentes de una configuración zonal.

Ilustración: Equilibrador de carga zonal

En el caso de un servidor front-end de equilibrador de carga público, se agrega un parámetro de zonas a la dirección IP pública. La configuración IP del servidor front-end que usa la regla correspondiente hace referencia a esta dirección IP pública.

En el caso de un servidor front-end de equilibrador de carga interno, se agrega un parámetro de zonas a la configuración IP del front-end del recurso de equilibrador de carga interno. Un servidor front-end zonal garantiza una dirección IP en una subred a una zona específica.

No zonal

Los equilibradores de carga también se pueden crear en una configuración no zonal mediante un front-end "sin zona". En estos escenarios, un equilibrador de carga público usaría una dirección IP pública o un prefijo de IP pública y un equilibrador de carga interno usaría una dirección IP privada. Esta opción no ofrece garantía de redundancia.

Nota

Todas las direcciones IP públicas que se actualicen de una SKU básica a otra estándar serán de tipo "sin zona". Aprenda a actualizar una dirección IP pública en Azure Portal.

Consideraciones de diseño

Ahora que ya conoce las propiedades relacionadas con las zonas de Standard Load Balancer, las consideraciones de diseño siguientes pueden ayudarle a la hora de diseñar para lograr una alta disponibilidad.

Tolerancia a errores de zona

  • Un servidor front-end con redundancia de zona puede dar servicio a un recurso zonal en cualquier zona con una sola dirección IP. La IP puede sobrevivir a uno o más errores de zona, siempre que al menos una de las zonas tenga un estado correcto dentro de la región.
  • Un front-end zonal es una reducción del servicio a una única zona y comparte el mismo destino que la zona correspondiente. Si la implementación en su zona no funciona, su equilibrador de carga no sobrevivirá a este error.

Los miembros del grupo back-end de un equilibrador de carga normalmente se asocian con una única zona (por ejemplo, con máquinas virtuales zonales). Un diseño común para cargas de trabajo de producción sería tener varios recursos zonales. Por ejemplo, la colocación de máquinas virtuales de la zona 1, 2 y 3 en el back-end de un equilibrador de carga con un front-end con redundancia de zona cumple este principio de diseño.

Varios servidores front-end

El uso de varios front-ends le permite equilibrar la carga del tráfico en más de un puerto o dirección IP. Al diseñar la arquitectura, asegúrese de tener en cuenta cómo interactúa la redundancia de zona con varios servidores front-end. Si el objetivo es hacer que cada front-end sea resistente a errores, todas las direcciones IP asignadas como servidores front-end deben tener redundancia de zona. Si un conjunto de front-ends está pensado para asociarse a una sola zona, todas las direcciones IP de ese conjunto se deben asociar a esa zona específica. No se requiere un equilibrador de carga en cada zona. En su lugar, cada front-end zonal (o conjunto de servidores front-end zonales) se podría asociar con máquinas virtuales del grupo de back-end que forman parte de esa zona de disponibilidad específica.

Transición entre modelos zonales regionales

En el caso de que una región se aumente para tener zonas de disponibilidad, las IP existentes, como las usadas para los servidores front-end del equilibrador de carga, seguirán siendo no zonales. Para asegurarse de que la arquitectura puede aprovechar las nuevas zonas, se recomienda la creación de direcciones IP de front-end. Una vez creado, puede reemplazar el front-end no zonal existente por un nuevo front-end con redundancia de zona mediante el método descrito aquí. Todo el equilibrio de carga existente y las reglas NAT pasarán al nuevo front-end.

Implicaciones de los planos de control frente a los planos de datos

La redundancia de zona no implica un plano de control o un plano de datos sin incidencias. Los flujos con redundancia de zona pueden usar cualquier zona y los flujos que use utilizarán todas las zonas correctas de una región. En el caso de un error de zona, los flujos de tráfico que usan zonas correctas no se ven afectados.

Los flujos de tráfico que están usando una zona en el momento en que se produce un error en esta pueden resultar afectados, pero las aplicaciones se pueden recuperar. El tráfico continúa por las zonas correctas de la región después de la retransmisión cuando Azure ha detectado el error en la zona.

Revise los patrones de diseño en la nube de Azure para mejorar la resistencia de la aplicación a los escenarios de error.

Limitaciones

  • Las zonas no se pueden cambiar, actualizar ni crear para el recurso después de su creación.
  • Los recursos no se pueden actualizar de zonal a con redundancia de zona y viceversa después de su creación.

Pasos siguientes