Compartir a través de

Azure Load Balancer: Características y escenarios de implementación(es-MX)

  • Artículo

Créditos

https://social.technet.microsoft.com/wiki/contents/articles/52169.azure-load-balancer-features-and-deployment-scenarios.aspx

Introduccion

Azure Load Balancer ofrece una variedad de servicios que son adecuados para múltiples escenarios. Para un arquitecto o un consultor de Azure, es esencial saber qué configuración es la adecuada para cada escenario.

En este artículo, exploraremos múltiples servicios atendidos por Azure Load Balancer y también analizaremos diferentes tipos de escenarios de implementación

Importantes consideraciones sobre el Azure Load Balancer

  • Azure Load Balancer es un Balanceador de Capa 4 que funciona con Transport Layer y es compatible con los protocolos TCP y UDP.
  • Azure Load Balancer puede traducir la dirección IP y el puerto pero no puede traducir el protocolo. Eso significa que, si el tráfico entrante llega a través del protocolo TCP, Azure Load Balancer lo reenviará a través del protocolo TCP. Si el tráfico entrante llega a través del protocolo UDP, Load Balancer lo reenviará a través del protocolo UDP.
  • Al usar Azure Load Balancer, podemos implementar Balanceador de carga externo / público (ELB) o Balanceador de carga interno (ILB) según el escenario. Cubriremos esto en secciones posteriores.
  • Los balanceadores de carga se adjuntan a las máquinas virtuales de Azure a través de la tarjeta de red VM (NIC).
  • La mayor parte del tiempo el tráfico es entrante a máquinas virtuales de Azure. Sin embargo, un Load Balancer público también puede proporcionar conexiones salientes para máquinas virtuales dentro de la red virtual al traducir sus direcciones IP privadas a direcciones IP públicas.
  • Azure Load Balancer viene en dos SKU diferentes, Básico y Estándar. Basic Load Balancer es gratuito, mientras que Standard Load Balancer implica cargos.
  • El SKU para IP pública y Azure Load Balancer debe ser el mismo. No puede adjuntar una dirección IP básica con Standard Load Balancer o una dirección IP estándar con Basic Load Balancer.
  • Una máquina virtual se puede conectar a un recurso de Load Balancer público y uno interno.

Alcances del Load Balancer 

  • No puede adjuntar Azure Load Balancer a máquinas virtuales de Azure en diferentes regiones; todas las máquinas virtuales deben estar en la misma región de Azure. Esto es cierto tanto para Basic como para Standard Load Balancer. Para cobertura de múltiples regiones, Microsoft tiene otra oferta llamada Azure Traffic Manager.
  • Basic Load Balancer puede cubrir máquinas virtuales desde un único conjunto de disponibilidad y conjuntos de escalas.
  • Basic Load Balancer puede cubrir máquinas virtuales dentro de una única Zona de disponibilidad.
  • El equilibrador de carga estándar puede incluir máquinas virtuales de múltiples conjuntos de disponibilidad y conjuntos de escalas.
  • El equilibrador de carga estándar también puede incluir máquinas virtuales de varias zonas de disponibilidad. Es compatible con el equilibrio de carga entre zonas, que es un Microsoft recomienda un enfoque para mantener el fallo de la zona.
  • Para un equilibrador de carga interno, se puede acceder al VIP privado desde la red virtual de Azure, así como desde la red corporativa y otras redes virtuales interconectadas, si hay una conectividad adecuada. Esto hace que el ILB sea extremadamente útil. Por ejemplo, ILB se puede usar con SQL Always on Cluster, donde el puerto de front-end sería el puerto de escucha Always-On.

Load Balancer Básico y Standard

  • Microsoft recomienda Standard Load Balancer para una implementación grande y compleja, ya que mejora las capacidades de Basic Load Balancer y agrega más funciones.
  • El Balanceador de carga estándar tiene una cobertura más amplia en comparación con la básica, que se explicó en la sección anterior. 
  • Standard Load Balancer es compatible con HTTPS Health Probe, que Basic Load Balancer no es compatible. Ambos soportan las sondas de salud basadas en HTTP y TCP.
  • Basic Load Balancer es gratuito, mientras que Standard Load Balancer implica cargos.
  • Para obtener una comparación completa entre las SKU estándar y básicas, siga este enlace.
  • El balanceador de carga estándar admite zonas de disponibilidad. Para equilibrar las máquinas virtuales en todas las zonas de disponibilidad con un equilibrador de carga estándar, siga este enlace.
  • Para obtener más información sobre la configuración de Standard Load Balancer en las zonas de disponibilidad, consulte este artículo.

¿Cómo funciona el Balanceador de Azure?

Debajo se enumeran los componentes relacionados:

 

Componente

Descripción

Front-end (VIP)

Front-end consiste de 3 componentes :

  • IP (Pública or Interna)
  • Protocolo de transporte (TCP or UDP)
  • Puerto

Back-end Pool

Máquinas virtuales a ser balanceadas. Las tarjetas de red de las Máquinas virtuales podrían ser configuradas con el Balanceador

Health Probe

Monitoreo del estado de salud de la aplicación. Requiere Parámetros como Puerto, Ruta, Intervalo, etc.

Load Balancer Rule

La regla de Load Balancer define cómo se comportará el LB, y consta de los siguientes parámetros :

a) Front End IP

b) Protocol (TCP or UDP)

c) Front-end Port

d) Back-end Pool

e) Back-end Port

f) Health Probe

g) Session Persistence

Flujo de control

  • Azure Load Balancer recibe el tráfico entrante en el front-end IP virtual. Para Load Balancer externo, el front end VIP es una IP pública. Para Internal Load Balancer, el front end VIP es una IP privada.
  • El tráfico entrante se recibe a través de un determinado puerto que está configurado. Por defecto, el puerto es 80.
  • Al recibir el tráfico, el equilibrador de carga comprueba la regla LB y, según la regla, reenvía el tráfico entrante al grupo de servicios de fondo en el puerto mencionado. El puerto de destino puede ser el mismo que el puerto de origen o diferente, según la regla LB.
  • Para garantizar que todas las máquinas virtuales y las aplicaciones estén funcionando en el grupo de servicios de fondo, Azure Load Balancer supervisa la sonda de estado después de un intervalo específico. La sonda de estado agrega o elimina dinámicamente las máquinas virtuales de la rotación del equilibrador de carga en función de su respuesta a las comprobaciones de estado. De forma predeterminada, una máquina virtual se elimina de la distribución del equilibrador de carga después de dos fallas consecutivas en intervalos de 15 segundos. Creamos una sonda de salud basada en un protocolo o una página de comprobación de estado específica para nuestra aplicación.

Modo de distribución

El Modo de distribución define cómo se distribuiría el tráfico entrante en las máquinas virtuales de Azure back-end.

En otras palabras, el modo de distribución es el algoritmo de equilibrio de carga que decide a qué tráfico de VM de back-end se enviará.

Azure Load Balancer admite los siguientes dos modos de distribución:

  • Modo de distribución basada en hash
  • Modo de afinidad de IP de origen (afinidad de sesión / afinidad de cliente)

En modo de distribución basada en hash es el modo predeterminado, que es un hash de 5 tuplas. Estas 5 tuplas son:

  • IP de origen
  • Puerto de origen
  • IP de destino
  • Puerto de destino
  • Tipo de protocolo

En Hash Based Distribution, Azure Load Balancer ofrece pegajosidad solo en la misma sesión, no para una nueva sesión. Esto significa que, mientras se esté ejecutando una sesión, el tráfico de la misma IP de origen siempre se desviará al mismo DIP de back-end (IP del centro de datos). Pero si la misma IP de origen inicia una nueva sesión, el tráfico puede desviarse a un DIP diferente.

En el modo de afinidad de IP de origen, Azure Load Balancer siempre desvía el tráfico al mismo punto final de DIP que proviene de una fuente particular, siempre que el servidor de servicios de fondo pase la sonda de estado.

Para más información sobre el modo de distribución, consulte este artículo.

Sondeo de salud (Health Probes)

**Las sondeos no controlan la salud de las máquinas virtuales de Azure; monitorean la aplicación alojada en esas máquinas virtuales. Para que los servidores de servicios de fondo participen en el conjunto del equilibrador de carga, deben pasar la comprobación de la sonda.. **

  • Azure Basic Load Balancer admite sondas de estado TCP y HTTP. Azure Load Balancer estándar admite sondas de estado TCP, HTTP y HTTPS.
  • Las sondas de salud se originan en la dirección IP 168.63.129.16. Por lo tanto, esta dirección IP no debe bloquearse para que puedan funcionar las sondas de salud.
  • Una sonda TCP falla cuando el agente de escucha TCP en la instancia no responde en absoluto, o cuando la sonda recibe información de restablecimiento de TCP.
  • Una sonda HTTP / HTTPS falla cuando hay un código distinto de 200 (Ej .: 403, 404 o 500) o el punto final de la sonda no responde en absoluto durante el período de 31 segundos. También puede fallar si el punto final de la sonda cierra la conexión a través de un restablecimiento de TCP.

Consulte este artículo para obtener más información sobre los sondeos de salud.

 

Puertos Alta Disponibilidad

El Puerto de alta disponibilidad solo se puede configurar utilizando el Balanceador de carga estándar interno. Basic Load Balancer no admite esta configuración.

El puerto HA es una de las funciones más útiles que ofrece un equilibrador de carga estándar interno. Hay muchos escenarios, donde tenemos que cargar el tráfico entrante en todos los puertos y protocolos. Antes de que estuviera disponible la función Puertos HA, fue una tarea difícil configurarlo porque, de manera predeterminada, las reglas de Equilibrio de carga funcionan según este principio: "Si un tráfico entrante llega al puerto X utilizando el protocolo Y, reenvíe el tráfico al puerto X1 utilizando el protocolo Y" . En este principio, tenemos que crear una regla separada para cada puerto y protocolo.

La característica de puertos de HA resuelve este problema. Cuando se configura HA Ports, podemos definir una sola regla que cubrirá todos los puertos y protocolos. El equilibrador de carga interno cargaría el equilibrio de todos los flujos TCP y UDP, independientemente del número de puerto. De hecho, cuando selecciona la opción "Puertos HA" durante la creación de la regla de Load Balancer, desaparecen las opciones de puerto de origen, puerto de destino y protocolo.

La función de puertos HA se está utilizando en los siguientes escenarios:

  • Alta disponibilidad
  • Escala para dispositivos virtuales de red (NVA) dentro de redes virtuales.

Para configurar el puerto HA, necesitamos especificar lo siguiente:

• Puerto frontal y posterior a cero (0) • Protocolo = Todos

Consulte este artículo para obtener más información sobre la regla de puertos de alta disponibilidad (HA) y este artículo para configurar los puertos de alta disponibilidad en un ILB.

Enrutamiento de puertos (Reglas NAT)

Azure Load Balancer admite la función de reenvío de puertos, con la configuración de las reglas de traducción de direcciones de red (NAT).
Mediante la función de reenvío de puertos, podemos conectarnos a una red virtual de Azure usando la dirección IP pública de Load Balancers. El equilibrador de carga recibirá el tráfico en un puerto determinado y, según la regla de NAT, reenviará el tráfico a una máquina virtual específica a través de un puerto específico.

Tenga en cuenta que mientras una regla de equilibrado de carga se adjunta a varias máquinas virtuales en el grupo de servicios de fondo, la regla de NAT se adjunta a una sola máquina virtual de back-end. Por lo tanto, cuando tenga que conectarse a una sola máquina virtual a través de un puerto determinado, use la regla de NAT en lugar de la regla de equilibrio de carga.

Para configurar el reenvío de puertos, consulte este artículo. 

Conexiones salientes en Azure

Hasta ahora, hemos analizado el equilibrio del tráfico entrante y el equilibrio de carga que fluye hacia las máquinas virtuales de Azure, pero el equilibrador de carga de Azure también se puede usar para el escenario de conexión de salida.

Consideremos un escenario en el que una máquina virtual de Azure desea comunicarse fuera del mundo utilizando una dirección IP pública. Existen múltiples soluciones disponibles basadas en el escenario:

Escenario 1

Si la máquina virtual de Azure tiene una dirección IP pública de nivel de instancia (ILPIP), siempre se comunicará con el mundo exterior utilizando esa dirección IP. En este escenario, incluso si esta máquina virtual está detrás de un equilibrador de carga, no utilizará la dirección IP de front-end del equilibrador de carga sino su propio ILPIP. 

Escenario 2

En este escenario, la máquina virtual de Azure está detrás de un equilibrador de carga pública y no tiene ILPIP. Si la regla de Load Balancer está configurada correctamente, entonces el Load Balancer público traducirá el tráfico saliente de la dirección IP privada de las máquinas virtuales a la dirección IP de front-end de Load Balancer, utilizando SNAT. 

Enmascarar Puertos SNAT (PAT)

El enmascaramiento de puertos es un algoritmo, que Azure utiliza para enmascarar (disfrazar) la fuente cuando una única máquina virtual o varias máquinas virtuales se comunican con el mundo exterior.

Supongamos un escenario, donde varias máquinas virtuales están conectadas detrás de un equilibrador de carga pública, y ninguna de las máquinas virtuales tiene su propia IP pública (ILPIP). Como se mencionó anteriormente, Azure Load Balancer traducirá las direcciones IP privadas a su dirección de front-end. Sin embargo, como una única dirección IP pública se usa para representar varias direcciones IP privadas, Azure usará puertos efímeros (puertos SNAT).

Escenario 3

En este escenario, no hay un equilibrador de carga o una dirección IP pública de nivel de instancia. Cuando configuramos la conexión de salida en este escenario, la máquina virtual utilizará una IP pública arbitraria para comunicarse con el mundo exterior. Esta dirección IP es asignada dinámicamente por Azure y no tenemos ningún control sobre ella. Para obtener más información sobre la configuración de la conexión de salida utilizando Load Balancer, consulte este enlace.
**
**

Varios servidores front-end para Azure Load Balancer

Azure Load Balancer proporciona flexibilidad en la definición de las reglas de equilibrio de carga, que se pueden aprovechar en múltiples escenarios.
Azure Load Balancer proporciona una opción para configurar el mismo puerto de back-end en múltiples reglas dentro de un solo Load Balancer, se nos llama reutilización de puertos de back-end.

Hay dos tipos de reglas:

• La regla predeterminada sin reutilización del puerto back-end.

• La regla de IP flotante donde se reutilizan los puertos de back-end.

IP Flotante y Direct Server Return (DSR)

La IP y el DSR flotantes se usan cuando se necesita usar el mismo puerto de back-end en múltiples reglas en un único Load Balancer.

Como lo menciona Microsoft, si desea reutilizar el mismo puerto de back-end en múltiples reglas, debe habilitar la IP flotante (DSR) en la definición de la regla.

Cuando se implementa IP / DSR flotante, la IP de front-end se configura dentro del sistema operativo invitado de Azure VM y no en el equilibrador de carga.

La principal diferencia entre DSR y el enfoque tradicional de equilibrio de carga es que, en DSR, la dirección IP de origen no se traduce a la IP de destino. En otras palabras, no hay NAT y la dirección IP de origen se configura directamente en el sistema operativo invitado de la VM. Si hay más de una VM detrás del equilibrador de carga, cada VM está configurada con la misma dirección IP de front-end. La interfaz donde se asigna la dirección IP de front-end se llama Interfaz de retroceso.

Además de la interfaz de bucle de retorno, habrá un DIP (IP de destino) por VM que se configura en Azure y no dentro del sistema operativo. El propósito de este DIP es facilitar la sonda de salud para que funcione Load Balancer.

Además, cuando el tráfico vuelve, vuelve a la dirección original (no al equilibrador de carga) desde donde se originó el tráfico. Esto es cierto para la operación normal de Load Balancer, incluso si DSR no está implementado. Por eso Microsoft dice: a nivel de plataforma, Azure Load Balancer siempre funciona en una topología de flujo DSR, independientemente de si la IP flotante está habilitada o no. Esto significa que la parte de salida de un flujo siempre se reescribe correctamente para que fluya directamente al origen.

No confunda el tráfico de retorno con la conexión de salida, que hemos analizado anteriormente. La conexión de salida es una configuración separada, donde una máquina virtual detrás de un equilibrador de carga origina la conexión y envía tráfico al mundo exterior.

Este artículo de Microsoft discute estos escenarios en detalle.

Un ejemplo clásico de implementación de DSR es SQL Always On Availability Group. Si necesita implementar Azure Load Balancer para admitir el Grupo de disponibilidad siempre de SQL, considere leer este artículo.

Concluyendo

Hemos discutido la mayoría de las características y escenarios relacionados con Load Balancer, ahora es el momento de poner todo junto. Espero que la siguiente tabla ayude a los arquitectos y diseñadores a elegir el producto adecuado en función del escenario.

Escenario

Solución Propuesta

Load-balance incoming Internet traffic to Azure VMs within a single region.

Public Load Balancer (Basic / Standard)

Load Balance traffic across Azure VMs within Azure VNET (Including traffic from on premise) within a single region.

Internal Load Balancer (Basic / Standard)

Forward traffic to a specific port on a specific VM behind the load balancer (not to any VM , but to a specific VM).

Configure NAT Rule.

VM needs to communicate to outside world, and it does not have its own public IP address.

Public Load Balancer (Basic / Standard), outbound connection with Source NAT (SNAT).

Need multiple Front-ends, but back-end port would not be reused across multiple rules. Each rule will use different back-end port.

It is possible to configure multiple front-ends in a single Azure Load Balancer. Basic /Standard and Internal / External support this configuration.

Reuse Back-end Ports across multiple rules in a single Load Balancer. In other words, same back-end port needs to be used in more than one rule.

Ex: Cluster High Availability, Network Virtual Appliance (NVA)

Enable Floating IP (DSR) in the rule definition. Basic / Standard and Internal / External support this configuration. Please note that without enabling Floating IP (DSR), you cannot re-use same back-end port for multiple rules.

Need to define one single Load Balancing rule, which will be applicable for all ports and protocols and not just for a specific port / protocol.

Configure High Available (HA) Ports. Only Internal Standard Load Balancer supports this configuration.

Load-balance incoming Internet traffic to Azure VMs which are in different Azure Regions.

Azure Load Balancer does not support this scenario, as Load balancer works only within single region. You can use Azure Traffic Manager in this scenario.

Load Balance traffic based on resource utilization. For example, when on premise server would be overloaded, the remaining traffic would be diverted to Azure VMs without any service interruption. (Burst to Cloud)

Azure Load Balancer does not support this scenario. Use Azure Traffic Manager.

Route Traffic based on incoming URL, and not based on source IP address or Port.

Azure Load Balancer does not support this scenario. Use Azure Application Gateway.

Ver también

Otros Lenguajes

Introduccion

Introduccion