Un componente importante de las aplicaciones altamente disponibles es cómo distribuir el tráfico en todas las VM. En la entrada, aprendimos la diferencia entre los conjuntos de disponibilidad y las zonas de disponibilidad, y cómo puede crear varias VM en los centros de datos o regiones de Azure para proporcionar redundancia a la aplicación. Aunque tenga todas estas VM altamente disponibles y distribuidas, eso no ayuda si solo una VM recibe todo el tráfico de los clientes.
Los equilibradores de carga son recursos de red que reciben el tráfico de aplicaciones entrante de sus clientes, examinan el tráfico para aplicar filtros y reglas de equilibrio de carga y luego distribuyen las solicitudes a través de un grupo de VM que ejecutan la aplicación. En Azure, hay un par de maneras de equilibrar la carga del tráfico, como si necesita descargar SSL en aplicaciones grandes que utilizan tráfico de red cifrado. En este capítulo, aprenderá acerca de los diversos componentes del equilibrador de carga y cómo configurar las reglas de tráfico y los filtros, además de distribuir el tráfico a las VM.

Componentes del equilibrador de carga de Azure
Los equilibradores de carga de Azure pueden trabajar en dos niveles: capa 4, donde solo se examina y distribuye el tráfico de red (realmente, la capa de transporte) y la capa 7, donde se reconocen los datos de la aplicación dentro del tráfico de red para ayudar a determinar la distribución de los datos. Ambos niveles del equilibrador de carga funcionan de la misma manera, como se muestra en la figura.

Un equilibrador de carga consta de unos pocos componentes principales:
– Grupo IP de front-end: punto de entrada al equilibrador de carga. Para permitir el acceso desde Internet, se puede conectar una dirección IP pública al grupo IP de front-end. Se pueden conectar direcciones IP privadas para los equilibradores de carga internos.
– Sondeos de estado: controlan el estado de las VM conectadas. Para asegurarse de que el tráfico solo se distribuya a VM en buen estado y con capacidad de respuesta, se realizan controles periódicamente para confirmar que la VM responda correctamente al tráfico.
– Reglas del equilibrador de carga: distribuyen el tráfico a las VM. Cada paquete entrante se compara con las reglas que definen los protocolos y puertos entrantes y, luego, se distribuyen a través de un conjunto de VM asociadas. Si no hay reglas que coincidan con el tráfico entrante, el tráfico se elimina.
– Reglas de traducción de direcciones de red (NAT): pueden enrutar el tráfico directamente a VM específicas. Por ejemplo, si desea proporcionar acceso remoto a través de SSH o RDP, puede definir reglas NAT para reenviar el tráfico desde un puerto externo a una sola VM.
– Grupo IP de back-end: lugar donde se conectan las VM que ejecutan la aplicación. Las reglas del equilibrador de carga están asociadas con los grupos de back-end. Puede crear diferentes grupos de back-end para diferentes partes de sus aplicaciones.

Azure Application Gateway: equilibrador de carga avanzado
Los equilibradores de carga de Azure pueden trabajar en la capa de red o en la capa de aplicación. Este capítulo se centra en el equilibrador de carga normal de Azure, que funciona en la capa de red (capa 4, o protocolo de transporte). En esta capa, el tráfico se examina y distribuye, pero el equilibrador de carga no tiene ningún contexto de lo que significa el tráfico o las aplicaciones que se ejecutan.
Application Gateway de Azure: es un equilibrador de carga que funciona en la capa de aplicación (capa 7). Application Gateway obtiene información de la aplicación que se ejecuta en la VM y puede administrar los flujos de tráfico de formas más avanzadas. Una de las principales ventajas de Application Gateway es la capacidad de manejar tráfico web encriptado y HTTPS.
Cuando se equilibra la carga de los sitios web con certificados SSL, se puede descargar el proceso que verifica y descifra el tráfico de los servidores web. En sitios web con mucho tráfico SSL, el proceso para verificar y descifrar el tráfico puede consumir gran parte del tiempo de proceso en las VM o aplicaciones web. Application Gateway puede verificar y descifrar el tráfico, pasar la solicitud web pura a los servidores web y luego volver a cifrar el tráfico recibido de los servidores web y devolverlo al cliente.
Application Gateway ofrece algunas otras funciones del equilibrador de carga más avanzadas, como la capacidad de distribuir tráfico a través de cualquier punto de conexión IP en lugar de una única VM de Azure. A medida que compila aplicaciones que utilizan más que VM, estas reglas de distribución avanzadas pueden serle de utilidad. Los mismos conceptos básicos se aplican que con un equilibrador de carga normal; en este capítulo nos centraremos en esto para que entienda cómo funciona todo de manera conjunta en Azure.

Creación de grupos IP de front-end
En las entradas anteriores, creó VM que tenían una dirección IP pública asignada directamente a ellas. Utilizó esta dirección IP pública para luego acceder a la VM con una conexión remota como SSH o RDP, o utilizó un navegador web para acceder a un sitio web que se ejecutaba en la VM. Cuando se utiliza un equilibrador de carga, ya no se conecta directamente a las VM. En lugar de ellos, para permitir que el tráfico llegue a su equilibrador de carga y se distribuya a las VM, se debe asignar una o más direcciones IP a la interfaz externa de un equilibrador de carga.
Los equilibradores de carga pueden funcionar en uno de dos modos:
– Equilibrador de carga de Internet: tiene una o más direcciones IP públicas conectadas al grupo IP de front-end. Un equilibrador de carga de Internet recibe directamente el tráfico de Internet y lo distribuye a las VM de back-end. Un ejemplo común son los servidores web front-end a los que los clientes acceden directamente a través de Internet.
– Equilibrador de carga interno: tiene una o más direcciones IP privadas conectadas al grupo IP de front-end. Un equilibrador de carga interno funciona dentro de una red virtual Azure, como para las VM de bases de datos back-end. Normalmente, no expone bases de datos de back-end o niveles de aplicación al mundo exterior. En lugar de ello, un conjunto de servidores web front-end se conecta a un equilibrador de carga interno que distribuye el tráfico sin ningún tipo de acceso público directo. La figura muestra cómo un equilibrador de carga interno puede distribuir el tráfico a las VM de back-end que están detrás de un equilibrador de carga orientado al público y VM web de front-end.

El modo para el equilibrador de carga no cambia el comportamiento del grupo IP de front-end. Se asignan una o más direcciones IP que se utilizan cuando se solicita el acceso al equilibrador de carga. Se pueden configurar tanto las direcciones IPv4 como IPv6 para el grupo IP de front-end, lo que le permite configurar las comunicaciones IPv6 de un extremo a otro entre los clientes y las VM a medida que el tráfico fluye dentro y fuera del equilibrador de carga.
Pruébelo ahora
Para entender cómo funcionan los componentes del equilibrador de carga, siga los siguientes pasos para crear un equilibrador de carga y un grupo IP de front-end:
1 Abra Azure Portal y seleccione el icono Cloud Shell en la parte superior del
panel.
2 Cree un grupo de recursos con az group create.
Especifique un nombre de grupo de recursos, como azuremolchapter8,
y una ubicación:
az group create –name azuremolchapter8 –location westeurope
A medida que continúe compilando sobre el capítulo 7 y utilice zonas de disponibilidad, tenga cuidado con la región que seleccione para asegurarse de que la zona de disponibilidad sea compatible.
3 Cree una dirección IP pública con az network public-ip create.
En la entrada anterior, aprendió que las zonas de disponibilidad proporcionan redundancia a los recursos de red, así que cree una dirección IP pública estándar con la VM y especifique un nombre, como publicip:

az network public-ip create \
–resource-group azuremolchapter8 \
–name publicip \
–sku standard

Para crear una dirección IP pública IPv6, puede agregar –version IPv6 al comando anterior. Para estos ejercicios, puede usar direcciones IPv4.
4 Cree el equilibrador de carga y asigne la dirección IP pública al grupo IP de front-end. Para agregar la dirección IP pública, especifique el parámetro –public-ip-address. Si quería crear un equilibrador de carga interno, tendría que haber utilizado el parámetro –private-ip-address.
Al igual que con la dirección IP pública, cree un equilibrador de carga estándar con redundancia de zona que funcione a través de zonas de disponibilidad:

az network lb create \
–resource-group azuremolchapter8 \
–name loadbalancer \
–public-ip-address publicip \
–frontend-ip-name frontendpool \
–backend-pool-name backendpool \
–sku standard

En las próximas páginas profundizaremos en los grupos de back-end.

Creación y configuración de sondeos de estado
Si una de las VM que ejecuta su aplicación tiene un problema, ¿cree que el equilibrador de carga debiera continuar distribuyendo el tráfico a esa VM? Un cliente que intenta acceder a su pizzería puede ser dirigido a esa VM y no podrá hacer su pedido. Un equilibrador de carga supervisa el estado de las VM y puede eliminar aquellas que tienen problemas. El equilibrador de carga continúa monitoreando el estado y vuelve a agregar la VM al grupo para distribución del tráfico una vez que la VM vuelve a responder correctamente.
Un sondeo de estado puede funcionar de dos modos:
– Basado en puerto: el equilibrador de carga comprueba la respuesta de la VM en un puerto y protocolo específicos, como puerto TCP 80. Mientras la VM responda a los sondeos de estado en el puerto TCP 80, la VM permanecerá en la distribución de tráfico del equilibrador de carga. De lo contrario, la VM se elimina de la distribución de tráfico del equilibrador de carga, como se muestra en la figura 8.3. Este modo no garantiza que la VM sirva el tráfico como se esperaba, solo comprueba que la conectividad de red y el servicio de destino devuelvan una respuesta.
– Basado en ruta de HTTP: una página personalizada, como health.html, se escribe y se coloca en cada VM. Esta comprobación de estado personalizada se puede utilizar para verificar el acceso a un almacén de imágenes o a una conexión de base de datos. En este modo, la VM solo permanece en la distribución de tráfico del equilibrador de carga cuando la página de comprobación de estado devuelve una respuesta código HTTP 200, como se muestra en la figura siguiente. Con un sondeo de estado basado en puerto, el servidor web real puede ejecutarse pero no tener conexión a la base de datos. Con una página de comprobación de estado personalizada, el equilibrador de carga puede confirmar que la VM es capaz de servir el tráfico real a los clientes.

Se requiere trabajo adicional para crear la página de comprobación de estado personalizada, pero la experiencia mejorada para el cliente hace que valga la pena. La página de comprobación de estado no tiene que ser complicada. Podría ser una página HTML básica que se utilice para confirmar que el propio servidor web puede atender páginas. Sin la página de comprobación de estado, si el proceso del servidor web tiene un problema, la VM aún estaría disponible en el puerto TCP 80, y el sondeo de estado basado en puerto creería que la VM está en buen estado. Un sondeo de estado basado en ruta HTTP requiere que el servidor web devuelva correctamente una respuesta HTTP. Si el proceso de servidor web se cae o falla, no se envía una respuesta HTTP, por lo que la VM se elimina de la distribución de tráfico del equilibrador de carga.
La frecuencia con la que el sondeo de estado comprueba la VM y cuál es la respuesta, también se puede configurar mediante dos parámetros:
¡ Intervalo: permite definir la frecuencia con la que el sondeo de estado comprueba el estado de la VM. De forma predeterminada, el sondeo de estado comprueba el estado cada 15 segundos.
¡ Umbral: permite definir la cantidad de errores de respuesta consecutivas que puede recibir el sondeo de estado antes de que se elimine la VM de la distribución de tráfico del equilibrador de carga. De forma predeterminada, el sondeo de estado tolera dos fallas consecutivas antes de que la VM se elimine de la distribución de tráfico del equilibrador de carga.

Pruébelo ahora
Complete los siguientes pasos para crear un sondeo de estado para su equilibrador de carga:
1 Abra Azure Portal y seleccione el icono Cloud Shell en la parte superior del panel.
2 Especifique un nombre para el sondeo de estado, como healthprobe. Para configurar el sondeo de estado para un servidor web, especifique el puerto 80 de HTTP y, a continuación, defina una página de comprobación de estado personalizada en health.html. En la sección 8.2, creará esta página de comprobación de estado en sus máquinas virtuales. Para mostrar cómo se puede configurar el intervalo y el umbral de la respuesta de sondeo de estado, defina un intervalo de 10 segundos y un umbral de tres fallas consecutivas:

az network lb probe create \
–resource-group azuremolchapter8 \
–lb-name loadbalancer \
–name healthprobe \
–protocol http \
–port 80 \
–path health.html \
–interval 10 \
–threshold 3

Después de crear el sondeo de estado, ¿cómo se hace para que compruebe el estado de las VM? Los sondeos de estado están asociados a reglas del equilibrador de carga. Se puede utilizar el mismo sondeo de estado con varias reglas del equilibrador de carga. ¿Recuerda la entrada cuando creó reglas y grupos de seguridad de red (NSG)? Esos NSG se pueden asociar a varias VM o subredes virtuales de red. Una relación similar «una a muchas» se aplica a los sondeos de estado.
Veamos cómo poner su sondeo de estado a trabajar y crear reglas del equilibrador de carga.

Definición de la distribución de tráfico con reglas del equilibrador de carga
Cuando el tráfico se dirige a través del equilibrador de carga a las VM de back-end, puede definir qué condiciones hacen que el usuario se dirija a la misma VM. Es posible que desee que el usuario conserve una conexión con la misma VM durante una sola sesión, o que permita que devuelvan y mantengan su afinidad de VM basándose en la dirección IP de origen. La figura siguiente se muestra un ejemplo del modo de afinidad de sesión predeterminado.
En el modo de afinidad de sesión, el flujo de tráfico se controla mediante un hash de 5 tuplas que utiliza la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el tipo de protocolo. Básicamente, para cada solicitud que un usuario hace a su servidor web en el puerto TCP 80, este se dirige a la misma VM de back-end por la duración de esa sesión.
¿Qué sucede si el cliente cierra la sesión del explorador? La próxima vez que se conecte, se iniciará una nueva sesión. Dado que el equilibrador de carga distribuye el tráfico en todas las VM en buen estado del grupo IP de back-end, es posible que el usuario se conectará a la misma VM; pero cuantas más VM tenga el grupo IP de back-end, mayor será la posibilidad de que se conecte a una VM diferente.

Como dueño y desarrollador de la aplicación, puede que quiera que el usuario se conecte a la misma VM que se conectó antes al iniciar otra sesión. Por ejemplo, si la aplicación controla las transferencias de archivos o utiliza UDP en lugar de TCP, es probable que quiera que la misma VM continúe procesando las solicitudes de los usuarios. En estos casos, puede configurar las reglas del equilibrador de carga para afinidad de IP de origen. La figura siguiente muestra un ejemplo del modo de afinidad de IP de origen.

Pruébelo ahora
Complete los siguientes pasos para crear una regla del equilibrador de carga que utilice un sondeo de estado:
1 Abra Azure Portal y seleccione el icono Cloud Shell en la parte superior del panel.
2 Para crear una regla del equilibrador de carga, especifique un nombre para la regla, como httprule.
3 Proporcione el puerto externo en el que se recibe el tráfico y el puerto interno al cual distribuir el tráfico. En este ejemplo básico, el tráfico se recibe en el puerto 80 y luego se distribuye al puerto 80:

az network lb rule create \
–resource-group azuremolchapter8 \
–lb-name loadbalancer \
–name httprule \
–protocol tcp \
–frontend-port 80 \
–backend-port 80 \
–frontend-ip-name frontendpool \
–backend-pool-name backendpool \
–probe-name healthprobe

Si ejecuta varios sitios web en una VM que responde en diferentes puertos, una regla determinada podría dirigir el tráfico a un sitio web específico en la VM.

Enrutamiento de tráfico directo con reglas de traducción de direcciones de red
Las reglas del equilibrador de carga distribuyen el tráfico a través de los grupos de back-end de las VM, por lo que no hay garantía de que se pueda conectar a una VM determinada para fines de mantenimiento o administración. ¿Cómo se puede conectar a una VM específica que está detrás de un equilibrador de carga? Una última parte de la configuración del equilibrador de carga que hay que tener en cuenta son las reglas de traducción de direcciones de red (NAT), que permiten controlar el flujo de tráfico específico para dirigirlo a una única máquina virtual. En la figura se muestra cómo las reglas NAT reenvían tráfico específico a VM individuales.

Las reglas NAT funcionan junto con las reglas NSG. La VM solo puede recibir el tráfico si hay una regla de NSG que permita el mismo tráfico que la regla NAT del equilibrador de carga.
¿Para qué podría crear reglas NAT? ¿Qué sucede si desea utilizar SSH o RDP para conectarse a una VM específica (y no utiliza Azure Bastion, que mencioné en el capítulo 2) o utiliza herramientas de administración para conectarse a un servidor de base de datos back-end? Si el equilibrador de carga distribuyera el tráfico a través de las VM de back-end, tendría que intentar conectarse una y otra vez, e incluso así podría no conectarse a la VM deseada.

Prácticas de seguridad recomendadas
Profundizaremos en algunos temas de seguridad en la parte 3 del libro, pero la seguridad debe ser una consideración permanente a medida que se compilan y ejecutan aplicaciones en Azure. La seguridad no debe ser un aspecto para agregar más adelante. Con el auge de la informática en la nube y las VM y aplicaciones web desechables, es fácil pasar por alto algunas prácticas recomendadas de seguridad básicas. Especialmente si trabaja en Azure como parte de una suscripción más amplia de la empresa, asegúrese de que cualquier recurso que cree no proporcione accidentalmente una manera para que los atacantes tengan acceso a su infraestructura.
¿Qué clase de cosas son malas? Bueno…algunas de las cosas que ya ha hecho en este libro. Los puertos de administración remota para SSH y RDP no deben abrirse a Internet público como lo ha hecho, o al menos se debe restringir el acceso si proviene de un rango de direcciones IP específico.
El procedimiento recomendado sería utilizar un servicio administrado, como Azure Bastion, o crear manualmente una VM segura que tenga disponible la administración remota. Según sea necesario, se conecta el host Azure Bastion o su única VM segura, y luego se conecta a través de la red virtual interna de Azure a las VM adicionales. Utilizó este enfoque de VM de servidor de salto básico en el capítulo 5. Este enfoque minimiza la superficie de ataque y reduce la necesidad de reglas NSG y reglas NAT del equilibrador de carga. En el capítulo 16 se describe Azure Security Center y se muestra cómo puede solicitar y abrir dinámicamente puertos de administración remota para un período específico, que es lo mejor de ambos mundos.
Incluso si trabaja con una suscripción privada de Azure que no tiene conectividad a otras suscripciones de Azure en la escuela o el trabajo, intente minimizar la cantidad de conectividad remota que proporciona.

Pruébelo ahora
Complete los siguientes pasos para crear una regla NAT del equilibrador de carga:
1 Abra Azure Portal y seleccione el icono Cloud Shell en la parte superior del
panel.
2 Para crear una regla NAT de equilibrador carga, defina un nombre, como natrulessh y el grupo IP de front-end a utilizar. La regla NAT examina el tráfico en un protocolo y puerto determinados, como el puerto TCP 50001. Cuando hay una coincidencia de reglas, el tráfico se reenvía al puerto 22 de back-end:

az network lb inbound-nat-rule create \
–resource-group azuremolchapter8 \
–lb-name loadbalancer \
–name natrulessh \
–protocol tcp \
–frontend-port 50001 \
–backend-port 22 \
–frontend-ip-name frontendpool

En este punto, ha creado un equilibrador de carga básico. Examine cómo se han reunido los componentes del equilibrador de carga:

az network lb show \
–resource-group azuremolchapter8 \
–name loadbalancer

Ha asignado una dirección IP pública al grupo IP de front-end y creó un sondeo de estado para comprobar el estado de una página de estado personalizada para un servidor web. Se creó una regla del equilibrador de carga para distribuir el tráfico web de sus clientes a un grupo de back-end; la regla utiliza sondeo de estado. También tiene una regla NAT de equilibrador de carga que permite el tráfico SSH, pero todavía no hay máquinas virtuales que reciban ese tráfico. Los clientes de su pizzería tienen hambre, así que vamos a crear algunas VM que puedan ejecutar su aplicación web y a la que el equilibrador de carga pueda distribuir el tráfico.

Asignación de grupos de VM a grupos de back-end
La sección final del equilibrador de carga define los grupos de back-end que incluyen una o más VM. Estos grupos de back-end contienen VM que ejecutan los mismos componentes de la aplicación, lo que permite al equilibrador de carga distribuir el tráfico a un grupo de back-end determinado y confiar en que cualquier VM de ese grupo puede responder correctamente a la solicitud del cliente. La figura detalla cómo los grupos de back-end agrupan lógicamente las VM que ejecutan las mismas aplicaciones.

Usted crea y utiliza un equilibrador de carga con VM, pero todo funciona en el nivel de red virtual. El grupo IP de front-end utiliza direcciones IP públicas o privadas. El sondeo de estado analiza las respuestas en un puerto o protocolo determinados. Incluso cuando se utiliza un sondeo HTTP, el equilibrador de carga busca una respuesta de red positiva. Las reglas del equilibrador de carga se centran en cómo distribuir el tráfico desde un puerto externo en el grupo de front-end a un puerto en el grupo de back-end.
Cuando asigna VM al grupo de back-end que recibe tráfico distribuido por el equilibrador de carga, es la NIC virtual la que se conecta al equilibrador de carga. La VM se conecta a la NIC virtual. Esta separación de VM y NIC virtual tiene sentido en términos de cómo se administran los recursos. Las reglas NSG controlan qué tráfico tiene permitido fluir a la VM, pero se aplican a una subred de red o a una NIC virtual, no a la VM.
¿Qué significa esto cuando se configuran grupos IP de back-end? Debe crear el resto de los recursos de la red virtual antes de poder conectar una VM al equilibrador de carga. Los pasos para crear los recursos de red deben ser un resumen de lo que aprendió hace unas entradas, así que veamos cuánto recuerda.

Pruébelo ahora
Complete los siguientes pasos para crear recursos de red adicionales, como se muestra en la figura 8.9:
1 Abra Azure Portal y seleccione el icono Cloud Shell en la parte superior del
panel.
2 Cree una red y subred virtuales:

az network vnet create \
–resource-group azuremolchapter8 \
–name vnetmol \
–address-prefixes 10.0.0.0/16 \
–subnet-name subnetmol \
–subnet-prefix 10.0.1.0/24

En la práctica, es muy probable que estos recursos de red ya existan. Estos son también los mismos nombres y rangos de direcciones IP que usó en el capítulo 5. Debe limpiar los recursos Azure al final de cada capítulo, por lo que tal reutilización de rangos IP no debería ser un problema. Solo tenga en cuenta que normalmente no creará una red y subred virtuales cada vez que cree un equilibrador de carga; más bien, puede utilizar los recursos de red virtual existentes.
3 Cree un NSG:

az network nsg create \
–resource-group azuremolchapter8 \
–name webnsg

4 Cree una regla de NSG que permita que el tráfico desde el puerto TCP 80 llegue a las VM. Esta regla es necesaria para que las VM del servidor web reciban y respondan al tráfico de clientes:

az network nsg rule create \
–resource-group azuremolchapter8 \
–nsg-name webnsg \
–name allowhttp \
–priority 100 \
–protocol tcp \
–destination-port-range 80 \
–access allow

5 Agregue otra regla para permitir el tráfico SSH para administración remota. Esta regla de NSG funciona con la regla NAT del equilibrador de carga creada en la sección 8.1.4 para una de las VM:

az network nsg rule create \
–resource-group azuremolchapter8 \
–nsg-name webnsg \
–name allowssh \
–priority 101 \
–protocol tcp \
–destination-port-range 22 \
–access allow

6 Asocie el NSG con la subred creada en el paso 2. Las reglas NSG se aplican a todas las VM que se conectan a esta subred:

az network vnet subnet update \
–resource-group azuremolchapter8 \
–vnet-name vnetmol \
–name subnetmol \
–network-security-group webnsg

7 El equilibrador de carga funciona con NIC virtuales, así que cree dos NIC virtuales y conéctelas a la subred de red virtual. Especifique también el nombre del equilibrador de carga y el grupo de direcciones de back-end al que se conectan las NIC virtuales. La regla NAT del equilibrador de carga solo se conecta a esta primera NIC virtual creada:

az network nic create \
–resource-group azuremolchapter8 \
–name webnic1 \
–vnet-name vnetmol \
–subnet subnetmol \
–lb-name loadbalancer \
–lb-address-pools backendpool \
–lb-inbound-nat-rules natrulessh

8 Cree la segunda NIC de la misma manera, menos la regla NAT del equilibrador de carga:

az network nic create \
–resource-group azuremolchapter8 \
–name webnic2 \
–vnet-name vnetmol \
–subnet subnetmol \
–lb-name loadbalancer \
–lb-address-pools backendpool

Creación y configuración de VM con el equilibrador de carga
Hagamos una pausa para explorar lo que acabamos de crear. La figura muestra el panorama general de cómo se ven los recursos de red y el equilibrador de carga. Observe la integración de estos recursos. El equilibrador de carga no puede existir por sí solo. Las NIC virtuales deben estar conectadas al equilibrador de carga para que se pueda distribuir cualquier tráfico. Esas NIC virtuales requieren una red y una subred virtuales e, idealmente, están protegidas por un NSG. Aunque no lo crea, las VM que luego ejecutan la aplicación no tienen casi nada que ver con los pasos para crear y configurar el equilibrador de carga.

Ha creado muchos recursos de red y ha configurado varias partes del equilibrador de carga. La dirección IP pública y el equilibrador de carga se crearon en una zona de disponibilidad como recursos redundantes a nivel regional, así que vamos a crear dos VM en diferentes zonas para reforzar la forma en que las zonas de disponibilidad mejoran la alta disponibilidad de sus aplicaciones.
Si utiliza conjuntos de disponibilidad en lugar de zonas de disponibilidad, es aquí donde crea un conjunto de disponibilidad y, a continuación, agrega las VM; luego, la plataforma Azure distribuye las VM entre los dominios de error y de actualización. La ideas es maximizar el uso de la alta disponibilidad de Azure para su pizzería, así que use zonas de disponibilidad.

Pruébelo ahora
Complete los siguientes pasos para crear las VM y conectarlas al equilibrador de carga:
1 Cree la primera VM y asígnela a una zona de disponibilidad con –zone 1:

az vm create \
–resource-group azuremolchapter8 \
–name webvm1 \
–image ubuntults \
–size Standard_B1ms \
–admin-username azuremol \
–generate-ssh-keys \
–zone 1 \
–nics webnic1

2 Cree la segunda VM y asígnela a la zona de disponibilidad 2; conecte la segunda NIC virtual que creó anteriormente utilizando –nics webnic2:

az vm create \
–resource-group azuremolchapter8 \
–name webvm2 \
–image ubuntults \
–size Standard_B1ms \
–admin-username azuremol \
–generate-ssh-keys \
–zone 2 \
–nics webnic2

Para ver el equilibrador de carga en acción, necesita instalar un servidor web básico, como lo hizo en la segunda entrada. También puede probar la regla NAT del equilibrador de carga. ¿Empieza a ver cómo todos estos componentes en Asure están relacionados y se complementan entre sí?

Pruébelo ahora
En el capítulo 5, analizamos el agente SSH. El agente SSH le permite pasar una clave SSH de una VM a la siguiente. Solo VM1 tiene una regla NAT del equilibrador de carga, así que debe usar el agente para conectarse a VM2. Complete los siguientes pasos para instalar un servidor web en las VM:
1 Inicie el agente SSH y agregue la clave SSH para que pueda conectarse a ambas VM:

eval $(ssh-agent) && ssh-add

2 Obtenga la dirección IP pública que está conectada al grupo IP de IP front-end del equilibrador de carga. Esta es la única manera de que el tráfico se dirija a través de las VM:

az network public-ip show \
–resource-group azuremolchapter8 \
–name publicip \
–query ipAddress \
–output tsv

3 Ya está listo para aplicar SSH a VM1. Especifique la dirección IP pública del equilibrador de carga (reemplace en el siguiente comando) y el puerto que se utilizó con la regla NAT del equilibrador de carga, como 50001. El parámetro -A utiliza el agente SSH para traspasar sus claves SSH:

ssh -A azuremol@ -p 50001

En el capítulo 2, utilizó apt-get para instalar toda la pila LAMP, lo que incluye el servidor web Apache. Veamos algo un poco diferente del servidor web Apache con el servidor web independiente, pero de gran potencia, NGINX. Normalmente instalaría IIS en una VM Windows. Ejecute el siguiente comando para instalar el servidor web NGINX:

sudo apt update && sudo apt install -y nginx

4 En el repositorio de ejemplos de GitHub que utilizó en capítulos anteriores, hay una página web HTM básica y una página de comprobación de estado para el sondeo de estado del equilibrador de carga. Clone estos ejemplos en la VM:

git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

5 Copie la página HTML de ejemplo y la comprobación de estado en el directorio del servidor web:

sudo cp azure-mol-samples-2nd-ed/08/webvm1/* /var/www/html/

6 Ahora tiene que conectarse a la segunda VM e instalar el servidor web NGINX y el código de ejemplo. ¿Recuerda el agente SSH? Debería ser capaz de aplicar SSH de la VM 1 a la VM 2 en la dirección IP interna, privada:

ssh 10.0.1.5

7 Instale el servidor web NGINX:

sudo apt update && sudo apt install -y nginx

8 Clone los ejemplos de GitHub en la VM:

git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

9 Copie la página HTML de ejemplo y la comprobación de estado en el directorio del servidor web:

sudo cp azure-mol-samples-2nd-ed/08/webvm2/* /var/www/html/

Abra un navegador web y conéctese a la dirección IP pública del equilibrador de carga. Se carga la página web básica y muestra que su pizzería ahora tiene VM redundantes en zonas de disponibilidad que se ejecutan detrás de un equilibrador de carga, como se muestra en la figura. Podría necesitar actualizar forzosamente su navegador web para ver que tanto VM 1 como VM2 responden a medida que el equilibrador de cara distribuye el tráfico entre ellas.

Laboratorio: Visualización de plantillas de implementaciones existentes
Este entrada une lo que aprendió en varias entradas anteriores. Creó recursos de red. Hizo que el equilibrador de carga y las VM estuvieran altamente disponibles con zonas de disponibilidad. Y se instaló un servidor web e implementaron archivos de ejemplo. Su pizzería ha llegado muy lejos desde que partió como una página web básica en una sola VM, como lo era al comienzo del libro.
Para unir otro tema más de un capítulo anterior, en este laboratorio queremos que explore todos los recursos que componen el equilibrador de carga. Para ello, mire la plantilla de Resource Manager. El objetivo de este laboratorio es ver cómo una sola plantilla puede crear y configurar lo que ha tomado muchas páginas y varios comandos de CLI. Y créame, ¡tomaría incluso más comandos de PowerShell! Siga estos pasos:
1 Abra Azure Portal.
2 Busque y seleccione Grupos de recursos en la barra de navegación del lado izquierdo del portal.
3 Elija el grupo de recursos, como azuremolchapter8.
4 Elija Exportar plantilla en la barra de la izquierda, como se muestra en la figura.
5 Para ver la parte relevante de la plantilla, seleccione cada uno de los recursos que se muestran en la lista. Tómese unos minutos para analizar esta plantilla y ver cómo están presentes todos los recursos y componentes que configuró en la CLI de Azure.

Una plantilla hace que sea mucho más fácil implementar un entorno de aplicaciones altamente disponible, redundante y con equilibrio de carga. Puede cambiar el nombre, las reglas y el modo de distribución del equilibrador de carga, y dejar que la plantilla implemente y configure todo el entorno de la aplicación.
No olvide eliminar este grupo de recursos para aprovechar al máximo sus créditos Azure gratuitos.

Y bien amigos aquí terminamos uno de las partes mas importantes del entorno de Azure la cual es un poco difícil de entender al inicio pero es vital en la mayoría de los proyectos, yo incluso diría que en todos los proyectos y sin mas nos despedimos por hoy, feliz finde!!!!