Oharra
Orrialde honetara sartzeak baimena behar du. Saioa hasteko edo direktorioak aldatzen saia zaitezke.
Orrialde honetara sartzeak baimena behar du. Direktorioak aldatzen saia zaitezke.
Azure Load Balancer es un servicio de equilibrio de carga de nivel 4 para el tráfico del Protocolo de control de transmisión (TCP) y el protocolo de datagramas de usuario (UDP) que distribuye las solicitudes entrantes entre las instancias correctas de los servicios. Load Balancer proporciona alta disponibilidad y rendimiento de red de 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 información clave sobre el acuerdo de nivel de servicio (SLA) de Load Balancer.
Importante
La confiabilidad de la solución general depende de la configuración de las instancias de back-end (servidores), como máquinas virtuales (VM) de Azure o conjuntos de escalado de máquinas virtuales a los que el equilibrador de carga enruta el tráfico.
En este artículo no se tratan las instancias de back-end, pero sus configuraciones de disponibilidad afectan directamente a la resistencia de la aplicación. Revise las guías de confiabilidad de los servicios de Azure de la solución para obtener información sobre cómo cada servicio admite sus requisitos de confiabilidad. Al configurar las instancias de back-end para alta disponibilidad y redundancia de zona, puede lograr una confiabilidad completa para la aplicación.
Recomendaciones de implementación de producción
Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, seguridad, costo, operaciones y rendimiento. Para obtener información sobre cómo estas áreas influyen entre sí y contribuyen a una solución confiable de Load Balancer, consulte Procedimientos recomendados de arquitectura para Load Balancer.
Introducción a la arquitectura de confiabilidad
Un equilibrador de carga puede ser público o interno. Se puede acceder a un equilibrador de carga público desde Internet a través de un recurso de dirección IP pública. Un equilibrador de carga interno solo es accesible desde dentro de la red virtual y otras redes que se conectan a la red virtual.
Cada equilibrador de carga consta de varios componentes:
Configuraciones 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 del equilibrador de carga que definen cómo el equilibrador de carga distribuye el tráfico desde un front-end a un grupo de instancias en el back-end.
Sondas de estado que supervisan la disponibilidad de las instancias de servidor del back-end.
Para obtener más información, consulte Componentes de Load Balancer.
En el caso de las soluciones implementadas globalmente, puede implementar un equilibrador de carga global, que es un tipo único de equilibrador de carga público para enrutar el tráfico entre diferentes implementaciones regionales de la solución. Un equilibrador de carga global proporciona una única dirección IP de anycast y enruta el tráfico al equilibrador de carga regional más cercano basándose en 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, que incluyen estrategias de retroceso exponenciales.
Configure sondeos de estado con tolerancia. Configure los sondeos de estado para equilibrar la detección rápida de errores con la necesidad de evitar falsos positivos durante problemas transitorios.
Supervisar la asignación de puertos SNAT. Para las conexiones salientes, supervise la asignación de puertos de traducción de direcciones de red de origen (SNAT) y configure reglas de salida para evitar errores de conexión transitorios que se producen 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 una zona falla, los servicios pueden transferirse a una de las zonas restantes.
Puede implementar el Load Balancer como redundante por zona configurando cada configuración de IP de front-end que usted cree. Una configuración de IP de front-end con redundancia de zona usa una infraestructura independiente en varias zonas para atender el tráfico simultáneamente. 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 que usa una configuración similar con redundancia de zona.
Nota:
Puede implementar equilibradores de carga zonales, pero se recomienda usar equilibradores de carga con redundancia de zona para todas las cargas de trabajo, incluidas las cargas de trabajo que implemente en una sola zona. Microsoft está migrando todas las direcciones IP públicas y equilibradores de carga a configuraciones con redundancia de zona.
En regiones sin zonas de disponibilidad, Azure crea todos los equilibradores de carga en una configuración regional o no zonal mediante una configuración de front-end sin zona configurada. Si la región experimenta una interrupción, los equilibradores de carga nozonales pueden experimentar tiempo de inactividad.
Instancias de back-end y zonas de disponibilidad
La configuración de zona de disponibilidad de las instancias de back-end funciona independientemente de la configuración de IP de front-end del equilibrador de carga.
Para distribuir las instancias de back-end entre zonas, configure el servicio pertinente según sus características de confiabilidad y sus requisitos de arquitectura.
Nota:
Para lograr resiliencia, distribuya las instancias de back-end entre varias zonas de disponibilidad. Si todas las instancias de back-end se ejecutan en una sola zona, una interrupción en esa zona hace que la aplicación no esté disponible, incluso si usa un equilibrador de carga con redundancia de zona.
Por ejemplo, cuando se usan máquinas virtuales, un enfoque de diseño común para cargas de trabajo de producción consiste en colocar varias máquinas virtuales zonales en las zonas 1, 2 y 3 para lograr resistencia de zona. Para realizar el equilibrio de carga, puede crear un equilibrador de carga redundante por zonas y configurar esas máquinas virtuales como instancias de back-end para el equilibrador. 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.
Si implementa las máquinas virtuales en la misma zona de disponibilidad, puede implementar una configuración ip de front-end con redundancia de zona en el equilibrador de carga, como se muestra en el diagrama siguiente.
Requisitos
Compatibilidad con regiones: Puede implementar equilibradores de carga con redundancia de zona en cualquier región que admita zonas de disponibilidad.
Cost
La configuración de la zona de disponibilidad no cambia la forma en que Azure factura un equilibrador de carga. Azure basa la facturación en el número de reglas que configure y los datos que procesa, independientemente de la configuración de zona. Para más información, consulte los precios de Azure Load Balancer.
Configurar soporte de zonas de disponibilidad
Al utilizar un Load Balancer, se activa la compatibilidad de zona de disponibilidad en la configuración del 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 se asocia a él. Para que la zona de configuración de IP de front-end sea redundante, cree o elija una dirección IP pública con redundancia de zona. Azure configura las direcciones IP públicas como redundantes de zona de forma predeterminada. Para más información, consulte Creación de un equilibrador de carga público para equilibrar la carga de 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 ip de front-end. Para más información, 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 zona de disponibilidad de un equilibrador de carga existente, reemplace la configuración de IP de front-end. Puede usar este enfoque para pasar de una configuración zonal a una configuración ip de front-end con redundancia de zona:
Cree una nueva configuración de IP de front-end que tenga la configuración de zona de disponibilidad deseada.
En el caso de los equilibradores de carga públicos, cree 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 ip de front-end con la configuración de disponibilidad deseada. Este paso asigna una nueva dirección IP privada desde la subred.
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.
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 funcionan normalmente.
Enrutamiento de tráfico entre zonas: El equilibrio de carga puede producirse en cualquier zona de disponibilidad. El equilibrador de carga envía tráfico a instancias de back-end saludables que especificáis en el grupo de back-end, sin tener en cuenta la región de disponibilidad que contiene la instancia de back-end.
Replicación de datos entre zonas: Load Balancer funciona como un servicio de paso a través de red que no almacena ni replica los datos de la aplicación. Incluso si configura la persistencia de sesión en el equilibrador de carga, el equilibrador de carga no almacena ningún estado. La persistencia de la sesión ajusta el proceso de hash para dirigir las solicitudes a la misma instancia de back-end, aunque el equilibrador de carga no garantiza dicha persistencia. Cuando cambia el grupo de back-end, el equilibrador de carga vuelve a calcular la distribución de las solicitudes de cliente y no almacena ni sincroniza el estado.
El servicio mantiene su estado de configuración a través de la 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 balanceador de carga usa una configuración IP frontal con redundancia de zona y ocurre una falla en la 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: Cuando se produce un error en una zona, los flujos TCP y UDP existentes dentro de la zona se restablecen automáticamente y los clientes deben reintentar esos flujos. Los clientes deben implementar un control de errores transitorio suficiente, incluidos los reintentos automatizados.
Pérdida de datos esperada: Load Balancer es un servicio de red sin estado, por lo que no almacena los datos de la aplicación y 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 zonal ya que los equilibradores de carga siguen funcionando desde zonas saludables.
Si el error afecta a los servicios de proceso de la zona, es posible que las máquinas virtuales u otros recursos de la zona afectada no estén disponibles. Los sondeos de estado del equilibrador de carga detectan estos errores y enrutan el tráfico a instancias alternativas en otra zona, según el algoritmo de equilibrio de carga y el estado de salud de las instancias de back-end.
Reenrutamiento del tráfico: El equilibrador de carga sigue funcionando desde las zonas correctas. El Balanceador de Carga mantiene la misma dirección IP de front-end durante fallos de zona. Este comportamiento significa que no es necesario aplicar actualizaciones del sistema de nombres de dominio (DNS) ni volver a configurar clientes. La plataforma Azure establece nuevas conexiones de cliente a través de zonas correctas restantes.
Recuperación de zona
Cuando se recupera una zona de disponibilidad, Load Balancer reanuda automáticamente las operaciones normales. El front-end con redundancia de zona comienza automáticamente a atender el tráfico desde la zona recuperada junto con otras zonas operativas. Los sondeos de estado de la zona recuperada reanudan la evaluación de las instancias de back-end.
Si el error de zona también afecta a los servicios de proceso de esa zona, Load Balancer agrega automáticamente instancias de back-end al grupo de instancias de back-end saludable después de que las instancias se recuperen y pasen las comprobaciones de estado. La distribución del tráfico se rebalancea en todas las zonas disponibles en función del algoritmo de equilibrio de carga y del estado de salud de las instancias de fondo.
Prueba de fallos de zona
La plataforma Azure administra el enrutamiento del tráfico, la respuesta de zona inactiva y la recuperación, 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 un error que apaga 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 también no estarán disponibles. Load Balancer proporciona compatibilidad nativa con varias regiones a través de un equilibrador de carga global, que admite el equilibrio de carga entre regiones de Azure. Además, puede desplegar otros servicios de balanceo de carga para enrutar y realizar conmutación por error entre las regiones de Azure.
Equilibradores de carga globales
Los equilibradores de carga globales proporcionan una única dirección IP anycast estática que automáticamente enruta el tráfico a la implementación regional óptima, basada en la proximidad del cliente y la salud regional. Los equilibradores de carga globales mejoran la confiabilidad y el rendimiento de la aplicación.
Con los equilibradores de carga globales, se implementan varios equilibradores de carga públicos en distintas regiones y un equilibrador de carga global actúa como front-end global. Si los servidores back-end de una región tienen un problema, el tráfico cambia automáticamente a regiones saludables sin cambios de DNS porque la dirección IP anycast permanece constante y enruta el tráfico a otra región.
Para más información, consulte Equilibrador de carga global.
Soluciones personalizadas de varias regiones para la resistencia
Azure proporciona una gama de servicios de equilibrio de carga que se ajustan a diferentes requisitos. Elija un equilibrador de carga que cumpla los requisitos de resistencia y 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 Load Balancer se aplica cuando tiene 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.