Windows Azure, Infraestructura al rescate

Soluciones

Las plataformas de nube cada vez son más complejas y ricas, en cuanto a servicios se refiere. La demanda por parte de los clientes de más productos, que a la vez sean más sencillos pero más potentes, hace que se tengan varias opciones para solucionar los problemas de despliegue y configuración de aplicaciones.

En ese sentido, Windows Azure, dispone de varias maneras de publicar una aplicación web hecha con tecnología ASP.NET de Microsoft, y dependiendo de las necesidades de escalabilidad y requerimientos de despliegue se puede utilizar una herramienta u otra.

PaaS o IaaS

clip_image001
clip_image002

clip_image003 clip_image004 clip_image005

Teniendo en cuenta el siguiente diagrama de red:

En el que se tienen varios servidores que desempeñan distintas funciones de red, todas ellas expuestas a través de un balanceador de red. Este tipo de escenarios donde en el servidor Windows Server hay desplegada una o varias aplicaciones ASP.NET que se conectan al servidor de SQL Server para almacenar datos y que además, tienen datos de los clientes almacenados en un NAS y todo ello utilizando el servidor de cache para aumentar la velocidad de acceso de determinados datos de la base de datos y de ficheros almacenados en el NAS.

Este tipo de escenarios suele ser bastante común para una aplicación empresarial, normalmente este esquema de red suele está desplegado en las oficinas del cliente o en algún data center de terceros, en el que el cliente tiene total libertad para conectarse a las maquinas por escritorio remoto, pero la configuración de la red como tal está supeditada al control del hoster. Es un modelo mixto de control.

Máquinas virtuales de Windows Azure

Para migrar esta solución a Windows Azure se puede utilizar Infraestructura como Servicio que ofrece la flexibilidad necesaria para administrar:

· La red virtual a la que pertenecen.

· La creación y tamaño de las máquinas virtuales.

· El sistema operativo y software instalado en la máquina.

· El grupo de alta disponibilidad del puerto

Con todo esto se puede configurar cualquier aspecto de la creación, conectividad y disponibilidad de las máquinas.

Virtual Network

Antes de empezar a crear las maquinas, se tiene que crear una red virtual. Con esta característica, las maquinas que se creen dentro de la misma red virtual tendrán visibilidad entre ellas sin necesidad de configurar los endpoints. Esto permite que el tráfico de red sea privado entre las máquinas y que por tanto la latencia de red sea muy baja cuando lo que se quiere es conectarlas entre sí.

En el escenario que se está valorando existe una máquina virtual con Windows Server, donde se ejecuta el servidor web y otra máquina SQL Server donde estará el motor de base de datos. Por lo menos esas dos máquinas tienen que tener conectividad entre ellas porque el resto de servicios, NAS y Cache, serán sustituidos por servicios que Windows Azure ofrece como tal.

A continuación se muestra un ejemplo de red virtual creada con dos un rango de red basado en 10.10.0.x y dos sub redes dentro del rango principal.

clip_image006

Máquinas Virtuales

El siguiente paso es crear las máquinas virtuales como tal. Hay que tener en cuenta diferentes opciones a la hora de crear las máquinas y si no se siguen los pasos necesarios, puede pasar que se tengan que borrar las máquinas virtuales (que no los discos duros) y volverlo a crear todo.

Antes de poder crear la primera máquina, se tiene que tener una cuenta de Azure Storage creada para poder alojar el disco duro. Esto es así, porque se necesita un almacenamiento persistente donde guardar los 127gb de espacio que ocupa el primer disco duro del S.O.

Una vez creada la cuenta de Azure Storage el siguiente paso es seguir el asistente de creado desde el portal de administración de Windows Azure.

Seleccionar una imagen

clip_image008

Esta es la interfaz de usuario que se muestra cuando se quiere crear una máquina virtual. Se puede listar todos los tipos de imágenes de S.O. o se puede hacer un filtrado dependiendo si es o no productor Microsoft y en el caso de que lo sea, por tipo de producto.

Configuración

Una vez seleccionada la imagen del sistema operativo, en este caso, Windows Server 2012 R2 DataCenter, se puede seleccionar el nombre de la máquina virtual, que no tiene que coincidir con el nombre público de DNS del servicio, el tamaño de la máquina virtual (aquí hay más detalles de los tamaños), y un nombre de usuario y contraseña para poder conectarse a la máquina.

clip_image010

En el siguiente paso de la configuración se puede asociar con el servicio en la nube que se desee. Este servicio en la nube será el que genere la ulr final que será del tipo xxxx.cloudapp.net. También se puede configurar el grupo de afinidad de la maquina o la red virtual que quieras configurar. Las redes virtuales tienen una afinidad previa. Lo siguiente es seleccionar la sub red de la que formará la máquina, la cuenta de storage, y el grupo de disponibilidad.

clip_image012

El último paso de todo el proceso es establecer la configuración de los endpoints. Esto permite configurar el firewall de la infraestructura de Windows Azure, no tiene nada que ver con el Firewall con el que viene integrado Windows. En el caso de que sea un servidor web se configurará el puerto 80 para HTTP y el puerto 433 para HTTPS.

Para la máquina de SQL Server se tendría que configurar el puerto 1433 para el listener del motor.

Cache

Windows Azure dispone de un servicio de cache que funciona en demanda. Simplemente se tiene que provisionar directamente en el portal de Windows Azure y partir de ese momento se puede usar.

Este servicio dispone de su propia API para enviar y recibir objetos a través del cable, pero si durante el desarrollo se utiliza memcached como servicio y se tiene todo hecho de esa manera, el servicio de cache soporta el protocolo de memcached.

Además exsite una API en .NET Framework disponible a través de nuget para empezar a trabajar con la API de Cache.

NAS

El último servicio que queda por migrar de la solución on premises es el servicio de almacenamiento. Para solucionar este problema hay dos posible soluciones. La más cómoda y eficiente es usar el servicio de Windows Azure Storage para blobs, que permite generar contenedores de información y dentro de esos contenedores se puede guardar ficheros.

Se puede consumir el servicio de dos maneras, a través de una API REST que permite utilizar toda la funcionalidad del servicio. Además de eso se puede hacer que los usuarios puedan acceder a los recursos que hay almacenados en Storage a través de HTTP de varias maneras.

Se puede hacer un contenedor público para exponer el contenido a través de su nombre. Esto es útil cuando se tienen recursos de una web: imágenes, ficheros css, ficheros javascript y otros recursos. Después hay otro tipo de acceso más restringido basado en una llave en la URL que permite dar acceso ad-hoc durante una ventana de tiempo a la persona que posea esa url. Útil cuando se tienen escenarios de compartir información sensible con terceros y se genera una url que tiene una vida delimitada.

El utilizar el servicio de Windows Azure Storage implica que se tienen que hacer cambios en el código de la aplicación web para poder almacenar los ficheros en este nuevo servicio. Si se utilizan las APIS de .NET Framework y se está familiarizado con los Streams la migración es fácil. Y como la propia API está construida sobre REST en HTTP se puede consumir prácticamente desde cualquier dispositivo.

En el portal de Azure se puede encontrar la información necesaria para empezar a trabajar con Windows Azure Storage desde varios lenguajes.

Conclusión

Al final de todo se han cambiado las maquinas que se tenían on-premises por diferentes servicios de Windows Azure que se ofrecen a modo de servicio.

El diagrama final quedaría como este:

clip_image013

Luis Guerrero.

Technical Evangelist de Windows Azure.