En un post anterior estuvimos hablando sobre Azure Load Balancer:
como herramienta para distribuir la carga de peticiones entre varias máquinas virtuales o servicios de Azure.
Azure Load Balancer puede distribuir la carga en base a direcciones IP origen/destino y puertos origen/destino. En cambio, Azure Application Gateway puede distribuir la carga basándose en las 7 capas del modelo OSI. Usando esta capacidad podríamos, por ejemplo, distribuir la carga según la URL a la que tratan de acceder los usuarios. Aquí vemos un esquema de este modo de trabajo:
Detrás de nuestro Application Gateway tenemos dos servidores web que entregan páginas diferentes, una para el dominio Adatum y otra para el dominio Contoso. El Application Gateway solo tiene una IP pública a la que llegan las peticiones de los clientes. Dependiendo de si la petición es para adatum o para contoso, el Gateway las distribuye según las reglas definidas.
Azure Application Gateway también incluye otras características como SSL termination o WAF (Web Application Firewall) sobre las que hablaremos en otros posts. En este caso vamos a implementar una estructura como la del esquema, en la que tendremos 2 servidores web (instancias de máquinas virtuales Ubuntu con Apache instalado), que formarán parte de los backend del Application Gateway. Crearemos las reglas necesarias para que cuando se haga una petición a www.adatum.com, esta petición se dirija al Servidor 1, y cuando se haga una petición a www.contoso.com, esta petición se dirija al Servidor 2.
Ya tenemos creado un grupo de recursos RG-AppGW y dos máquinas virtuales Ubuntu:
Y en estas máquinas virtuales hemos instalado Apache y hemos personalizado el archivo index.html:
En la misma red virtual en la que estamos desplegando la infraestructura creamos una subred para el Application Gateway. Basta con que esta red tenga una máscara de 28 bits:
Y ya podemos crear el Application Gateway. Al hacerlo nos encontraremos con 4 opciones, Standard, Standard V2, WAF y WAF V2:
Los SKU V2 incluyen características como el autoescalado, la redundancia en diferentes zonas de disponibilidad, mejoras de rendimiento y otras más que podemos comprobar en el siguiente enlace:
También se ha cambiado el modo de facturación con las V2, que ahora no depende del número de instancias ni de su tamaño, sino del consumo. En la región en la que estamos haciendo el despliegue el precio es:
Donde cada Capacity Unit sería el equivalente a 50 conexiones por segundo con un certificado TLS de 2048 bits RSA, o bien 2500 conexiones persistentes con un ancho de banda de 2.22 Mbps.
Creamos el Application Gateway con las siguientes características:
Le damos una IP pública:
Añadimos el Servidor 1 como primer backend:
Y el servidor 2 como segundo backend:
Y nos quedará así:
Y añadimos las reglas necesarias para la distribución del tráfico:
Añadimos una regla para www.adatum.com:
Seleccionamos el tipo de listener como “Multiple sites” porque alojaremos adatum.com y contoso.com detrás del Gateway.
Definimos una configuración de HTTP para esta regla:
Y también un backend objetivo, en este caso el Servidor 1:
Y hacemos lo mismo para el Servidor 2:
Con esto ya podemos desplegar el Application Gateway, lo que llevará unos minutos.
Para poder comprobar el funcionamiento de las reglas, ya que no disponemos de los dominios adatum.com y contoso.com para redirigirlos a la IP de nuestro Application Gateway, podemos modificar nuestro archivo hosts. Si nuestra máquina es Windows, editamos el archivo hosts que se encuentra en %systemroot%\System32\drivers\etc y añadimos las siguientes líneas sustituyendo la IP por la de nuestro Aplication Gateway:
Y de esta forma podemos comprobar que se redirige el tráfico en función de la URL de la petición:
Y podemos monitorizar la actividad de nuestro Application Gateway:
