Windows Azure Connect: "¿Por qué? ¡Porque podemos!"

Hoy toca hablar de uno de las nuevas características que se ha puesto en marcha en la plataforma Azure y que, aún estando en CTP -todavía no es ni Beta, sino una preview abierta a comentarios-, me ha llamado mucho la atención la sencillez con la que se pueden crear redes virtuales en la nube.

Esta nueva característica se llama Windows Azure Connect y es la primera que se ha habilitado al público dentro del conjunto de herramientas de gestión de redes que se denominan Windows Azure Virtual Network.

¿Qué es lo que permite esta característica?

Resumiéndolo en una frase: "construir de manera sencilla y rápida redes virtuales seguras en la nube, para interconectar equipos y roles que estén tanto en la nube como en una red privada".

¿Por qué de manera sencilla y rápida?

Porque la configuración se realiza automáticamente instalando un software cliente que es el que se encarga de realizar y mantener las comunicaciones, o a través de configuración de los roles desplegados en Azure.

¿Por qué segura?

Porque todas las comunicaciones van cifradas a través de IPsec. IPsec protege las comunicaciones sobre redes IP a través del uso de servicios criptográficos. 

Los elementos de red

Para gestionar la red virtual contamos simplemente con dos tipos de elementos:

• Endpoints: que son los extremos de las comunicaciones. Pueden ser locales (PCs, equipos virtualizados, etc. a través de la instalación del agente software de Connect) o Roles de Azure (WebRoles o WorkerRoles)
• Grupos: un grupo es un conjunto de EndPoints más las reglas que indican con qué otros grupos se comunica.

Y ya está, no hay más. Más simple que el mecanismo de un chupete. 

Combinando estos dos elementos se puede configurar innumerables casos de uso que solucionan la mayoría de las situaciones: nubes híbridas en las que una parte está en la nube y otra en tu propio datacenter, comunicaciones entre distintos proveedores de cloud -por ejemplo conectando infraestructura existente de GoGrid con WebRoles en Azure-, etc. etc. etc.

El diagrama siguiente muestra un ejemplo de interconexiones posibles, aunque el esquema final depende de la solución a implementar:

Por ahora, durante este periodo de pruebas los Endpoints locales sólo pueden ser equipos ejecutando sistema operativo Windows (ya que el software de instalación sólo está disponible para esta plataforma), aunque ya se ha anunciado en los foros que en un futuro se añadirá la posibilidad de conectar Azure con dispositivos VPN, lo que permitirá comunicación a bajo nivel con recursos no-Windows que ahora mismo el agente de Connect no soporta.

NOTA IMPORTANTE: al estar esta característica en periodo de pruebas previas a su lanzamiento en BETA, aún no está alojado en los datacenters de Windows Azure sino en otros externos. Su uso durante este periodo de pruebas no tiene coste alguno, pero sí el uso de ancho de banda de salida de los elementos alojados en Windows Azure. 

HelloWorld, Azure Connect

Como ejemplo de prueba de conectividad, he realizado una simple conexión entre el PC de mi casa y el portátil sin llegar a conectar con un webrole -lo dejo para otro post-. Con ello, incluso teniendo IPs dinámicas en ambos extremos he conseguido establecer una comunicación segura entre ambos equipos con lo que puedo gestionar remotamente todos los recursos de la red de mi casa -imaginen las posibilidades de poder ampliar esta red con quien tú quieras, a través de comunicaciones seguras.

Los pasos que seguí fueron:

1. Acceder al portal de Azure y pulsar en el menú "Virtual network". En la parte superior aparecen las suscripciones disponibles
2. Al pulsar sobre una suscripción, nos sale un cuadro de diálogo indicando si queremos activar Microsoft Connect para esa suscripción. Aceptamos la condición y sis tenemos activada esta características sobre la suscripción -no olvidemos que ahora mismo está en CTP y hay que solicitarla- el proceso acaba por habilitar más opciones en el portal
3. Una vez activado Connect en la suscripción, pulsamos el botón "Install Local EndPoint" para instalar el software cliente en el equipo local
   
4. Pulsamos el botón "Copy Llink to Clipboard" para copiar la URL de descarga al portapapeles (si sale una advertencia de seguridad de Silverlight indicando que la aplicación va a interactuar con el portapapeles le damos a "Ok")
5. Pegamos la dirección en el navegador -ojo, ahora mismo sólo se soporta Internet Explorer- con lo que aparece el cuadro de diálogo de descarga sobre el que pulsamos la opción "Ejecutar" directamente
   
6. Seguimos los pasos del asistente de instalación hasta completar la misma

Una vez realizada esta instalación, al acceder de nuevo al portal y seleccionar el nodo "Activated Endpoints" veremos nuestro equipo en la lista de Endpoints, así como otras estadísticas de conexión.

Después de esta instalación, el equipo se considera un "local endpoint". Hay que tener en cuenta que sólo se puede instalar una instancia de este software por equipo, ya que utiliza el token de activación para la suscripción en cuestión. Si se desea que el equipo se conecte con otra suscripción, hay que desinstalar el software actual desde el panel de control y repetir el proceso para la nueva suscripción. Si se desea eliminar el local endpoint, se puede realizar o bien desinstalando el software del equipo o bien yendo al portal de Azure y eliminarlo de la lista usando la opción "Delete Endpoint".

Para instalarlo en otro equipo basta con seguir de nuevo los pasos descritos -ojo, no vale el mismo enlace de descarga, con lo que hay que repetir la operación desde el inicio-, con lo que repetí los pasos en el segundo equipo, para tener finalmente los dos EndPoints.

Con los EndPoints en marcha, ahora sólo faltaba comunicarlos entre sí. Para ello, creamos un grupo siguiendo estos tres pasos:

1. Desde el portal de Azure, seleccionamos el nodo "Groups and Roles" que está justo debajo de la suscripción
2. Pulsamos el botón "Create Group" para abrir el formulario de creación de grupo, introduciendo los datos solicitados -para que se puedan comunicar entre sí, marcad la opción "Interconnected".
3. Pulsamos el botón "Create" para finalizar la operación

Ahora podemos ver el grupo recién creado, y que además cada elemento tiene una nueva propiedad "Addresses" en formato IPv6 en el panel lateral derecho.

Si abrimos una consola de comandos y hacemos un simple ping a la IPv6 podemos ver la respuesta de comunicación a través del tunel IPsec.

No os echéis las manos a la cabeza con los tiempos de respuesta. Hay que tener en cuenta muchos factores: el ping ha viajado encriptado a través de Internet desde Tenerife, ha pasado por varios satélites y cables de fibra óptica submarinos hasta llegar a un Datacenter en Estados Unidos que actualmente no es de Azure sino uno en pruebas, y ha vuelto realizando el mismo camino de vuelta -el vídeo final de las conclusiones explica mejor este apartado :). Teniendo en cuenta que en Tenerife tenemos un ping mínimo en las ADSLs de Telefónica de 120ms, más de la mitad del tiempo ha sido por la comunicación entre Canarias-Cádiz-Canarias. 

Veremos en cuánto se queda este tiempo cuando el futuro NAP que esté operativo en Tenerife a partir de Marzo y cuando Connect esté disponible en los datacenters europeos como Dublín.

Del mismo modo, podemos comprobar que podemos acceder por escritorio remoto al otro equipo sin ningún problema:

Conclusiones 

Cada vez queda más patente que el público objetivo de la plataforma Azure son los desarrolladores, ya que a golpe de dos clicks de ratón puedes crearte una red virtual sin tener pajorera idea de lo que es una máscara de red, un router, una VLAN o una VPN (no quiero decir que no sepamos algo de ello, pero seguro que bastante menos que los de IT). Para los desarrolladores, disponer de una herramienta integrada con Azure en la que crear una red virtual sea un proceso tan sencillo y seguro, es todo un lujo.

El otro día hablando con un amigo de IT que ha también ha estado evaluando distintos proveedores de cloud computing, una vez que había visto lo que ofrecía Azure se inclinaba más por soluciones tipo GoGrid o Amazon EC2, y es normal, ya que Azure -por lo menos lo que se ofrece ahora mismo- es más una plataforma sobre la que construir y desarrollar aplicaciones que sobre la que desplegar y configurar sistemas pre-existentes. Esto puede cambiar con la entrada de los VM Roles, veremos qué sucede.

Como siempre, os dejo un enlace para acabar el post, esta vez a una escena que viene al pelo de la serie Big Bang Theory, lástima que no se pueda incrustar. Todo queda dicho en el diálogo siguiente:

Penny: ¿Por qué lo hacéis?
Todos: ¡Porque podemos!

http://www.youtube.com/watch?v=94c03FArdnQ