Otra de las grandes noticias de la plataforma es que tenemos la posibilidad de crear máquinas virtuales en la nube!
Resumiendo y simplificando un poco podemos decir que es una especide Hyper-V en la nube, dónde podemos desplegar cualquier tipo de sistema operativo, ya sea de plataforma Microsoft o de plataforma Linux, sí, Linux.
Utilizando este tipo de máquinas tendremos todo el control sobre la máquina, sobre lo que instala, se actualiza y demás…pero claro, a costa de tener que hacer más cosas, tener que gastar más tiempo y dinero en tares que no son propias de la aplicación. En un entorno PaaS como el que teníamos disponible hasta hace poco nos podemos centrar en el desarrollo de la aplicación y olvidarnos de muchos aspectos de la infraestructura.
Disponer en un entorno de máquinas virtuales con estado también nos va a permitir otros escenarios, como la instalación de un SQL Server, un SharePoint, un Active Directory o cualquier otro producto que consideremos.
En este post vamos a ir viendo cómo es posible crear una máquina virtual y poco a poco iré entrando en detalle en alguna cosa que hay que conocer si queremos trabajar con VM de Azure.
Desde el portal de Windows Azure podemos crear una VM, usando por ejemplo la galería:
En la galería podemos encontrar ya algunas plantillas que podemos usar para crear nuestra máquina virtual; Windows 2008. Windows 2012, CentOS, SUSE, OpenSUSE, Ubuntu etc…
Estas son simplemente algunas de las que a día de hoy existen, pero seguro que cada vez habrá más. Por ejemplo, existe ya una preview de una plantilla que instala SQL Server 2012.
A su vez también Microsoft dispone de diversos partners que ofrecen también distribuciones Linux certificadas que pueden desplegarse en Windows Azure.
Claro está, podríamos también subir nuestras imágenes (plantillas) o generarla a partir de una máquina ya desplegada.
El siguiente paso nos pide que le demos un nombre a la máquina y una contraseña para el usuario administrador.
Otro tema de los temas importantes es que debemos elegir el tipo de máquina que queremos usar, que marca los recursos asignados.
Como podéis ver se elige el tamaño de la máquina, como se hace cuando se despliega un Cloud Service (Web-Worker role). Eso realmente es así porque, aunque aquí no lo veamos, cuando Windows Azure aprovisiona una nueva máquina virtual está creando un Cloud Services implícito dónde despliega una máquina virtual con estado.
En el siguiente paso podemos elegir si queremos crear la máquina en un servicio independiente o si queremos conectarla a otra máquina.
Dos máquinas conectadas estarán en el mismo grupo de disponibilidad. En este caso lo que hace Windows Azure es desplegarla dentro del mismo servicio.
Windows Azure ofrece para una máquina un SLA del 99,9%, 99,95% si ponemos dos dentro del mismo grupo de disponibilidad, es decir, dentro del mismo servicio. Cuando le pedimos a la plataforma que las establezca en el mismo grupo ésta coloca cada máquina virtual en un fault domain diferente para asegurar que si una máquina cae la otra esté disponible.
Si la máquina la establecemos como standalone podemos crear un nuevo grupo de disponibilidad, para que cuando creemos la segunda máquina podamos asociarla.
Es importante comentar, que para escalar las máquinas virtuales no disponemos de las mismas capacidades que si usáramos Cloud Services.
Por ejemplo, si queremos tener dos máquinas en balanceo, somos nosotros los que tenemos que crear las dos máquinas conectadas, dentro del mismo grupo de disponibilidad.
Dos máquinas que están dentro del mismo grupo de disponibilidad están dentro del mismo servicio, se pueden comunicar entre ellas y se las puede configurar para que balanceador de Windows Azure haga balanceo sobre un determinado puerto.
Recordad también, que Windows Azure dispone de un API de administración REST que permite realizar todas las acciones que están disponibles en el portal, ya que éste hace uso del mismo API que cualquiera de nosotros podría utilizar.
Así mismo existen Sdks para trabajar desde plataforma Microsoft, Linux y MAC. https://www.windowsazure.com/en-us/develop/downloads/
Una vez terminados los pasos del Wizard Windows Azure se encargará de aprovisionar la máquina.
En la parte inferior podremos ver diversas acciones que podemos hacer; conectarnos a la máquina, reiniciarla, pararla, añadirle un disco, quitárselo, generar una imagen (plantilla) a partir de la máquina virtual o borrarla.
Si la máquina es Windows nos podremos conectar por RDP, si es Linux podremos usar otras herramientas como Putty o VNC si lo instalamos.
Un concepto que es importante tener claro es la diferencia entre discos e imágenes. Los dos son ficheros VHDs que se almacenan en Windows Azure Storage, pero sirven para cosas diferentes.
Cuando creamos una máquina virtual, ésta monta un disco que está en el storage.
Cuando creamos una máquina desde una imágen, se hace una copia del VHD y se monta el disco a partir de la copia.
Nosotros podemos crear imágenes con la acción “capture” (tras haber hecho un sysprep) o simplemente subir nuestros propios VHDs. Se pueden migrar máquinas que estén en un entorno local Hyper-V a la nube simplemente subiendo el VHD (o viceversa), sin ninguna acción adicional.
Una máquna virtual tiene que tener cómo mínimo un disco, el del sistema operativo, pero también se le pueden asociar (attach) discos adicionales de datos.
El disco del sistema operativo puede tener como máximo 127 Gb y puede tener discos adicionales hasta 1TB. El número de discos depende de cada versión.
Otro tema importante a conocer son los endpoints, que no son más que los puertos y protocolos a través de los cuáles se podrá acceder desde fuera de Windows Azure.
A nivel de comunicación, recordad que dos máquinas dentro del mismo grupo de disponibilidad se pueden comunicar sin problemas. Si queremos escenarios más complejos con conectividad entre diferentes máquinas virtuales, aplicaciones desplegadas en Cloud Services o incluso con entornos on-premise, tendremos que usar Virtual Network, otra de las novedades de la plataforma.
También, si queremos que las IPs de las máquinas se mantengan, tendremos que usar Virtual Network.
Por defecto, cuando se crea una máquina virtual, se crea un único endpoint para permitir la conexión remota, RDP en el caso de máquinas Windows.
Se pueden añadir los endpoints que se consideren, indicando el puerto y el protocolo.
Si dos máquinas están en el mismo grupo de disponibilidad podremos crear un endpoint simplemente asociándolo a otro que ya exista. De esta manera, Windows Azure sabrá que tiene que balancear la carga entre las N máquinas del grupo de disponibilidad para el puerto y protocolo indicado.
Como podéis ver, se puede elegir el protocolo UDP, otra de las novedades de la nueva versión!
También por último destacar que existe un campo que nos pide el puerto público y otro para el puerto privado.
De esta manera, una aplicación que haga uso de un puerto, podemos exponerla por otro puerto y será el balanceador el que se encargue de redirigir el tráfico del puerto público al privado.
Tanto el protocolo UDP como el “post forward” de puertos está también disponible para Cloud Services, lo que por ejemplo va a posibiltar escenarios dónde desde fuera de la nube podamos realizar conexiones contra instancias concretas de un servicio.
