Compartir a través de

Azure Load Balancer: un nuevo SKU estándar para capacidades premium (es-MX)

  • Artículo

artículo original: https://blogs.msdn.microsoft.com/igorpag/2018/03/24/azure-load-balancer-a-new-standard-sku-for-premium-capabilities/

Un poco de historia

Cuando habla de Cloud Computing, no puede evitar considerar la creación de redes: es el pegamento que mantiene todo junto y permite a los usuarios acceder a sus recursos y servicios para comunicarse entre sí. En el núcleo de la red Azure, desde el principio, es Azure Load Balancer. Si probablemente recuerde los primeros días de las funciones Web y Worker en Azure PaaS v1, y la primera versión de IaaS Virtual Machines, probablemente no utilice Azure Load Balancer (LB) en sí: frente a estos recursos, tenía esta pieza de tecnología de red que permitió equilibrar el tráfico en un conjunto de instancias de cómputo múltiples.

https://msdnshared.blob.core.windows.net/media/2018/03/120.jpg

En ese momento, LB era invisible y no configurable, con algunas excepciones. También hubo una distinción entre Azure Software Load Balancer (SLB) y Azure Internal Load Balancer (ILB), lo que refleja la primera ola de mejoras en esta parte de la plataforma. Incluso si el término ILB continúa existiendo en la documentación, generalmente hablamos de "Azure Load Balancer" (LB), no importa si la dirección IP del front-end es interna (ILB) o externa (SLB). Dentro del alcance de este artículo, me referiré a Azure Layer-4 Load Balancer como "LB". Layer-7 Azure Application Gateway no se considera. Además, ya no hay mejoras en la API de Administración de servicios de Azure (ASM) para LB, todas las funciones nuevas y lo que se analiza aquí se remitirán a la API de Azure Resource Manager (ARM).

https://msdnshared.blob.core.windows.net/media/2018/03/210.jpg

Introducción de un nuevo SKU de Load Balancer

Azure se está acercando a su décimo aniversario y con una ola masiva de mejoras bajo el nombre de "Azure Standard Load Balancer":

Load Balancer Standard

https://azure.microsoft.com/en-us/updates/public-preview-load-balancer-standard

Azure Standard Load Balancer (LB) incorporará mejoras masivas en el rendimiento, la escala, la flexibilidad y la cobertura de nuevos escenarios que antes no era posible implementar. Antes de continuar, permítanme aclarar los nuevos nombres y la introducción de la separación de SKU: el nuevo tipo mejorado de Azure LB es ahora el SKU "Estándar", mientras que la versión anterior de LB irá bajo el nombre de SKU "Básico". NOTA: no se anuncia retiro para el SKU "Básico". Solo para enfatizar que estos SKU son diferentes, y que Standard se ha construido desde cero , no es posible actualizar dinámicamente de uno a otro, al menos hoy. Incluso si los SKU no son mutables, se proporciona un procedimiento para cambiar, pero causará un tiempo de inactividad, puede verificar aqui. Antes de hablar más en profundidad sobre las características técnicas, permítanme destacar dos diferencias importantes entre estos dos SKU:

  • Precio

Los SKU estándar y básico tienen precios muy diferentes. El LB básico es gratuito, mientras que el LB estándar tiene una tarifa asociada. Ese precio se basará en la cantidad de reglas configuradas (las reglas NAT son gratuitas) y los datos procesados para los flujos originados entrantes. Sin embargo, no habrá un cargo por hora para el equilibrador de carga estándar cuando no se configuren las reglas. Además, el escenario ILB no se carga en absoluto. Puede verificar los detalles de precios aquí.

  • Límites en Suscripciones

El SKU estándar viene con mayor capacidad y escalabilidad, luego algunos de los umbrales máximos por región por suscripción de Azure son diferentes. En este artículo, tenga en cuenta los diferentes valores para la cantidad de reglas, las configuraciones de la interfaz y el tamaño de la agrupación back-end:

https://msdnshared.blob.core.windows.net/media/2018/03/38.jpg

Introducción de una nueva SKU de dirección pública de IP

Azure Standard SKU LB no viene solo, también vamos a tener un SKU estándar para direcciones IP públicas. Estos están estrictamente relacionados, el nuevo SKU de IP es necesario y está estrechamente vinculado al Load Balancer utilizado: el concepto aquí se refleja en la regla que dicta el uso de IP con LB: no es posible mezclar SKU básicos y estándar para estos objetos. Todas las direcciones IP públicas creadas antes de la introducción de SKU son SKU básico. Con la introducción de SKU, tiene la opción de especificar cuál le gustaría que sea la dirección IP pública. Puede preguntarse por qué se creó esto, tengo mi idea al respecto, no confirmada oficialmente, pero si observa la lista de características, parece estar relacionada con la (próxima) introducción de Zonas de disponibilidad de Azure (AZ):

Tipos de direcciones IP y métodos de asignación en Azure

/en-us/azure/virtual-network/virtual-network-ip-addresses-overview-arm

https://msdnshared.blob.core.windows.net/media/2018/03/48.jpg

 

Hablaremos más en profundidad sobre "Zonas de disponibilidad" (AZ) más adelante en este artículo. Mientras tanto, veamos algunos puntos importantes:

  • Opciones de SKU: Azure LB SKU estándar requiere Azure IP Standard SKU.
  • SKU de IP pública estándar solo estático: esto tendrá un impacto en el costo y la cantidad máxima de direcciones IP que podrá implementar, puede leer sobre esto aquí y aquí.
  • Zonas de Disponibilidad (Availability Zones): si desea utilizar LB en el escenario AZ, debe usar SKU estándar.

Crearlo en PowerShell requiere solo un parámetro adicional "Sku" para ser especificado con el valor "Estándar"::

New-AzureRmPublicIpAddress -Name $pubIpName -ResourceGroupName $rgname -AllocationMethod Static -Location $location -Sku Standard -IpAddressVersion IPv4

NOTA: La dirección IP pública de Azure SKU estándar no se puede usar con VPN Gateway ni Application Gateway.

Nuevas características del SKU estándar de LB

Durante los últimos años, para algunos de mis proyectos de Azure, me enfrenté a varios tipos de problemas y limitaciones para el SKU "básico" de equilibrio de carga de Azure. Mirando la lista de mejoras para SKU "Estándar" en el artículo siguiente, estoy impresionado y contento de que ahora casi todo haya sido finalmente resuelto. Permítanme informar la lista a continuación, junto con mis comentarios y experiencias de esos proyectos..

Azure Load Balancer Standard overview

/en-us/azure/load-balancer/load-balancer-standard-overview

 

Backend Pool

El grupo de Backend es esencialmente el conjunto de instancias de "cálculo" a las que el LB reenviará el tráfico. Durante uno de mis proyectos en el pasado, me enfrenté a dos problemas distintos, aquí están las descripciones y cómo SKU estándar ahora está tratando de resolver:

  • Escalabilidad: límite máximo de 100 instancias de VM. Ahora con SKU estándar, el límite se ha elevado 10 veces hasta 1000.
  • Flexibilidad: solo fueron posibles configuraciones con VM (o VM Scale Sets - VMSS) en un solo Conjunto de disponibilidad (AS). Ahora con SKU estándar puede incluir cada instancia de VM dentro del mismo VNET, independiente o en múltiples AS.

Configuración Frontend 

Configuración de múltiples Frontend IP: en realidad, esto también es posible con SKU Básico (ver aquí), pero con SKU estándar se ha mejorado. Ahora puede usar estas IP múltiples para escalar el número de puertos efímeros para SNAT. Si ha tenido problemas en el pasado con el agotamiento del puerto SNAT, debe usar SKU estándar LB con IP de SKU estándar frontales adicionales. Lea cuidadosamente aquí en escenarios y cómo resolver problemas potenciales.

https://msdnshared.blob.core.windows.net/media/2018/03/57.jpg

Lea atentamente a continuación los escenarios y cómo resolver posibles problemas..

Conexiones de salida en Azure

/en-us/azure/load-balancer/load-balancer-outbound-connections

Zonas de Disponibilidad (Availability Zones-AZ)

AZ es una característica muy importante que estará disponible pronto, actualmente en vista previa en regiones seleccionadas. Sin esta característica, no es posible tener ubicaciones aisladas de fallas dentro de una región de Azure, lo que proporciona energía redundante, refrigeración y redes. Las Zonas de disponibilidad permiten a los clientes ejecutar aplicaciones de misión crítica con mayor disponibilidad y tolerancia a fallas a las fallas del centro de datos, utilizando la replicación de datos síncrona, para lograr una pérdida de datos cero en caso de que se produzca un descenso de una sola zona. Con AZ, Azure podrá proporcionar 99,99% HA SLA para sus máquinas virtuales. Si desea usar un Load Balancer que sea resistente a las zonas, debe usar SKU estándar.

https://msdnshared.blob.core.windows.net/media/2018/03/610.png

 

Vale la pena señalar las siguientes notas sobre los conceptos "zonal" y "zona-redundante":

  1. Azure "Load Balancer", "Virtual Network" y "Subred" son objetos de toda la región, que es regional y nunca zonal.
  2. Los escenarios público y interno Load Balancer admiten zonas redundantes y zonales.
  3. La dirección de "IP pública" puede crearse localmente en una zona (zonificada) o regional, que es resistente a zonas: en el primer caso, debe especificar una zona al crear el objeto, en este último caso, no debe.

Para detalles adicionales, puede leer el artículo a continuación:

Zonas de disponibilidad y Balanceador de carga estándar

/en-us/azure/load-balancer/load-balancer-standard-availability-zones

Si desea saber más sobre las Zonas de disponibilidad de Azure, puede leer la publicación del blog a continuación:

¿Por qué Zonas de disponibilidad de Azure?

https://blogs.msdn.microsoft.com/igorpag/2017/10/08/why-azure-availability-zones

Puertos de Alta Disponibilidad - HA 

Esta función solo está disponible con SKU LB estándar y en escenarios de equilibrio de carga (ILB), no se puede utilizar con IP pública de Internet. Mechanic es muy simple: puedes escribir una simple regla simple que equilibrará * todos * los puertos y protocolos TCP o UDP. Sin esta característica, debe escribir explícitamente una regla de equilibrio de carga para cada puerto, con un umbral máximo de 250 utilizando el equilibrio de carga interno de SKU básico.

Introducción a puertos de alta disponibilidad

/en-us/azure/load-balancer/load-balancer-ha-ports-overview

¿Qué tipo de escenarios pueden tener beneficios de esto? El primer uso es para dispositivos virtuales de red (NVA). Con (HA) Ports es fácil configurar una sola regla de equilibrio de carga para procesar y distribuir el tráfico de VNet que llega a través de cualquier puerto de Capa 4 a sus NVA, aumentando la confiabilidad con una conmutación por error más rápida y más opciones de escalamiento horizontal.

https://msdnshared.blob.core.windows.net/media/2018/03/75.jpg

Puede crear dicha regla fácilmente usando Azure Portal o PowerShell (la plantilla ARM y Azure CLI 2.0 también están disponibles siguiendo estas instrucciones):

New-AzureRmLoadBalancerRuleConfig -Name "HAPortsLBrule” -FrontendIpConfiguration $FEconfig -BackendAddressPool $BEPool -Protocol "All" -FrontendPort 0 -BackendPort 0

Puede crear dicha regla fácilmente usando Azure Portal o PowerShell (la plantilla ARM y Azure CLI 2.0 también están disponibles después de....

https://msdnshared.blob.core.windows.net/media/2018/03/83.jpg

Monitoreo y Diagnósticos

Uso de SKU básico para Azure Load Balancer (LB), una vez habilitado como se describe aquí, hay tres tipos diferentes de registros disponibles: Auditoría, Health Probe y Alerts. El último es particularmente útil para solucionar problemas potenciales en el LB, como el agotamiento del puerto SNAT. Todos estos registros pueden recopilarse y almacenarse en una cuenta de almacenamiento de Azure y luego analizarse con herramientas como PowerBI. Lo nuevo en SKU estándar es la posibilidad de recuperar métricas y contadores importantes que le darán una mejor idea de cómo está funcionando su LB. Puede obtener la lista de métricas disponible para un recurso de Azure Standard SKU LB utilizando Azure Portal (a través de la integración de Azure Monitor) o el cmdlet de PowerShell "Get-AzureRmMetricDefinition" del módulo "AzureRM.Insights":

https://msdnshared.blob.core.windows.net/media/2018/03/93.jpg

Los primeros dos "contadores" le informarán acerca de la disponibilidad efectiva de frontend IP (VIP) y backend IP interno (DIP), los demás contadores son autoexplicativos. Para la descripción de cada artículo, vea este artículo. Esta funcionalidad es una adición a los diagnósticos ya disponibles en el SKU básico que aún puede aprovechar:

https://msdnshared.blob.core.windows.net/media/2018/03/105.jpg

SLA de alta disponibilidad

Personalmente, me encantan los SLA, como algo que le permite construir su arquitectura sobre bases sólidas, y "revender" a sus clientes finales una aplicación en la que pueden confiar. El estándar SKU LB viene con un SLA de alta disponibilidad de nueva marca de 99,99%, el SKU básico no se cubre aquí. Mejora muy útil y agradable.

SLA para Load Balancer

https://azure.microsoft.com/en-us/support/legal/sla/load-balancer/v1_0

La nueva función de control de métricas le permitirá evaluar fácilmente la disponibilidad y otros contadores del Portal de Azure con agradables diagramas personalizables.

https://msdnshared.blob.core.windows.net/media/2018/03/1112.jpg

Rompiendo cambios en Azure Standard SKU Load Balancer 

Decidí dedicar una sección a este tema porque hay dos cambios importantes en el comportamiento del SKU estándar, en comparación con el SKU básico anterior. Si ya está utilizando este último y planea pasar al anterior, lea detenidamente mis notas a continuación y los enlaces de documentación asociados::

  • Network Security Group (NSG): Cuando asigna una dirección IP pública SKU estándar a una interfaz de red de máquina virtual, debe permitir explícitamente el tráfico previsto con un grupo de seguridad de red. La comunicación con el recurso falla hasta que crea y asocia un NSG y permite explícitamente el tráfico deseado. Esto es por obvias razones de seguridad.
  • Conectividad de salida VM: si una VM forma parte de un grupo de backend SKU LB estándar, la conectividad de salida no está permitida sin configuración adicional. Esto es totalmente diferente de Basic LB, donde una VM tiene una conectividad de salida totalmente abierta a Internet. Para permitir la conectividad de salida VM, una regla de equilibrio de carga (regla NAT no es suficiente) debe programarse en el LB, como se explica en el artículo siguiente (consulte "Escenario 2: VM equilibrada sin una dirección IP pública de nivel de instancia" ):

Conexiones de salida en Azure

/en-us/azure/load-balancer/load-balancer-outbound-connections

NOTA: hay una excepción a la regla que acabo de darle, se lo explicaré en un minuto.

El artículo anterior es una pieza muy interesante de la arquitectura de red de Azure, le recomiendo que lea por completo, si desea tener una comprensión completa del comportamiento de Azure LB. Lo que es particularmente interesante es la lista de escenarios para la conectividad VM saliente:

https://msdnshared.blob.core.windows.net/media/2018/03/125.jpg

Respecto a la excepción que mencioné en la nota anterior, como puede leer en el primer escenario, si agrega una configuración IP adicional a su máquina virtual, con una IP pública de nivel de instancia (ILPIP), su VM podrá llegar a Internet saliente.

¿Qué falta todavía?

Como dije al principio de este artículo, Azure Standard SKU LB resolvió la mayoría de los problemas que enfrenté en el pasado, un trabajo increíble del equipo de Azure Networking. Como Cloud Architect para mis clientes y socios, todavía hay un par de especificaciones "agradables para tener" que me gustaría saber:

  1. Latencia de Load Balancer: oficialmente, no hay mención de la cantidad de sobrecarga que fluirá el tráfico a través del equilibrador de carga. Hemos hecho pruebas en el pasado y tenemos una idea, pero no hay SLA en eso.
  2. Rendimiento de Load Balancer: ¿Cuántos Gbit / s o Pps (paquetes por segundo) puede soportar un equilibrador de carga Azure? No hay una guía de capacidad al respecto, sospecho que debido a que los equilibradores de carga Azure se ejecutan en una infraestructura de múltiples usuarios, los números pueden cambiar..

En cuanto al segundo punto, en el pasado era raro alcanzar el límite de rendimiento, otros límites se aplicaron antes. Pero ahora puede escalar el conjunto de servidores back-end a 1000 máquinas virtuales, entonces será interesante realizar algunas pruebas de rendimiento a escala. De todos modos, permítanme cerrar el artículo con la oración contenida en el resumen articulo para Azure Standard Load Balancer:

....La baja latencia, el alto rendimiento y la escabilidad están disponibles para millones de flujos para todas las aplicaciones TCP y UDP.....

Ejemplos en GitHub

Como el SKU LB estándar es nuevo y algunos comportamientos son diferentes del pasado, creé algunas muestras muy simples utilizando PowerShell con las que puedes jugar y personalizar. Puedes encontrar en este link en GitHub. Tenga en cuenta que estos NO están listos para producción, los creé solo para fines de aprendizaje. Además, el código en las muestras no está destinado a ser lanzado todo de una vez. En su lugar, debe revisar cuidadosamente cada sección comentada, comprender los efectos y luego ejecutarla para observar el resultado.

  1. EJEMPLO[1]: Cree una VM zonificada simple con un nivel de instancia public Standard IP (ILPIP). Vea cómo crear una máquina virtual en una zona de disponibilidad (AZ) específica de Azure, luego cree una nueva IP pública de tipo SKU estándar y úsela para exponer la máquina virtual. Se necesita un Grupo de seguridad de red (NSG) para permitir el tráfico a través de la IP pública estándar, de manera diferente a la IP pública básica como se hizo en el pasado, donde todos los puertos estaban abiertos para acceso de VM..
  2. EJEMPLO[2]: Cree un nuevo tipo SKU LB estándar y úselo junto con una nueva IP pública SKU estándar. A continuación, cree dos máquinas virtuales "zonificadas" con discos administrados, cada una alojada en una zona de disponibilidad (AZ) diferente de Azure. Vale la pena señalar que las dos máquinas virtuales estarán en la misma subred y la red virtual, incluso si están en diferentes zonas de distribución. Finalmente, se demostrará cómo Standard SKU LB redirigirá de forma transparente a la máquina virtual en la zona [2], si la VM en la zona [1] estará inactiva. En esta muestra, se creará el NSG necesario y se vinculará al nivel de subred, no a la NIC VM específica como en el ejemplo anterior.
  3. EJEMPLO[3]: Cree un LB interno SKU estándar (ILB) con el puerto HA configurado y una máquina virtual zonal detrás. Verá cómo la regla de publicación para esta función es diferente y cómo funciona con la máquina virtual creada en una zona específica..
  4. EJEMPLO[4]: Aquí verá cómo recuperar definiciones de métricas y valores para SKU estándar LB, utilizando PowerShell.

https://msdnshared.blob.core.windows.net/media/2018/03/163.jpg

Conclusiones

Nuevo SKU estándar de Azure para Azure Load Balancer (LB) ha sido lanzado oficialmente ayer. Es un componente clave para muchos escenarios nuevos de Azure, lo que es más importante para las Zonas de disponibilidad de Azure (AZ). Además, proporciona una mayor escalabilidad y nuevas capacidades de diagnóstico y monitoreo que no están disponibles en la versión SKU básica. Espero que hayas disfrutado el artículo, no dudes en enviarme tus notas y comentarios. Puedes seguirme en Twitter usando @igorpag. Saludos.