Llevo un rato dándole vueltas a la cabeza a ver qué título le ponía a esta entrada en el blog, porque el amplio abanico de posibilidades que se me están ocurriendo es muy grande. Podría simplemente haberlo titulado “Editando los contenidos de un VHD en Azure desde tu escritorio”, pero es que también “Haciendo un backup en Azure Storage con Drag and Drop” también es válido. Por supuesto, “Cómo actualizar el contenido de tu sitio DNN en Azure desde tu explorador de Windows” es de dónde ha nacido la idea.
Y es que desde mi última entrada sobre cómo editar los contenidos de un VHD en Azure y pensando que aún así debería haber un método más fácil para actualizar los contenidos de un VHD, empecé a barajar la idea de usar el actual servidor SMB del DNN Azure Accelerator mezclado con Windows Azure Connect.
¿Qué es Windows Azure Connect?
Hace tiempo que ya escribí una entrada sobre este servicio de Windows Azure –aún en CTP y gratuito de momento- pero por simplificar, resumámoslo en que es un componente para poder crear redes virtuales entre “tu mundo” y Windows Azure. Con ello consigues, por ejemplo, ver las máquinas que están en la nube como si estuvieran en tu red local: les puedes hacer un ping, puedes ver el equipo a través de la red si tiene habilitada su regla en el firewall...¿cómo? ¿qué puedes ver los equipos en Windows Azure por la red y ver sus ficheros?
Y ahí está el quid de la cuestión. Si ya en el mismo DNN Azure Accelerator los web roles acceden por la red para publicar los contenidos del worker role SMB, ¿por qué no podría conectarme desde mi equipo a esa misma unidad compartida para modificar los contenidos a través de una red virtual creada por Windows Azure Connect?
La respuesta es: ¡Y por qué no! Sí, por supuesto que se puede. Y esta entrada trata de explicar los pasos para configurarlo de forma manual.
¿Qué necesito?
Para poder conectar tu equipo a una unidad VHD en Azure, necesitarás lo siguiente:
- Una suscripción activa a Azure sobre la que vas a desplegar tanto los servicios de computación (servidor de ficheros) como el almacenamiento. Puedes crearte una en http://www.windowsazure.com.
- Un servidor worker role que monte la unidad VHD y la comparta, habilitando el tráfico SMB (puerto 445). La forma más sencilla es montar el paquete DNN Azure Single and ExtraSmall del DNN Azure Accelerator. Si quieres construirte tu propio servicio te recomiendo le eches un vistazo a este post de Dinesh Haridas.
Pasos a seguir
1) Habilitar en la suscripción el servicio Windows Azure Connect. Como ahora mismo aún está en CTP, deberás solicitar su activación a través del menú de “programas BETA” en la consola de administración de Windows Azure. La parte buena es que mientras está en CTP, este servicio es gratuito.
2) Usar el “Relay” de Connect más cercano a tus servicios. Para ello, pulsa sobre el botón “Relay Region” e indica la región más cercana. Supuestamente también usarás la misma región para desplegar tu servidor más adelante.
3) Instalar el cliente de Connect en tu equipo local (o desde donde quieras acceder a tu unidad compartida en la nube). Para ello, accede desde la sección “Red Virtual” de la consola de administración de Azure, y selecciona la suscripción. pulsa sobre el botón “Instalar extremo local”, siguiendo las instrucciones en pantalla.
Una vez instalado, podrás ver en el área de notificación de la barra de tareas de Windows el icono correspondiente al servicio.
4) Obtener un token de activación de Azure para el servidor SMB que se desplegará en Azure. Para ello, pulsamos el botón “Obtener Token de Activación” de la misma consola de Windows Azure. Copiamos el “guid” que nos devuelve en el portapapeles porque lo vamos a usar en el paso siguiente.
5) Desplegar el servidor SMB en Azure conectado con Windows Azure Connect. Tal y como se comentó anteriormente, una forma rápida es usar el paquete DNN Azure Single and ExtraSmall del DNN Azure Accelerator. Sin embargo, el paquete que está compilado e incluido dentro de la descarga, no tiene habilitado Windows Azure Connect –sí lo estará en la próxima versión del Accelerator. Mientras tanto, puedes descargar la última versión del código fuente y abrirlo en Visual Studio 2010, modificando las propiedades de Red Virtual del paquete antes de volver a generarlo.
6) Una vez que hemos desplegado el paquete en Azure (hay un excelente video al respecto, por lo que me voy a saltar esa parte), volvemos a la sección de Red Virtual de la consola de administrador de Windows Azure para habilitar la interconexión entre nuestro equipo y el rol desplegado, creando un nuevo grupo. En la imagen siguiente se muestra un ejemplo donde conecto con dos servidores SMB distintos ubicados en dos servicios distintos (realmente 2 instancias de DotNetNuke en Azure):
7) Con esto, ya deberíamos ver el equipo remoto en la nube ejecutando un simple ping. Para ello, copiamos la dirección IPv6 del equipo remoto de la misma consola de administración, y en una consola de comandos de DOS escribimos ping <direccionIPv6>.
No os asustéis por el ping de la imagen. En el momento de la captura estaba conectado a través de una red 3G y me estaba dando más del doble de tiempo de conexión.
NOTA: en caso de que no haya respuesta de ping, puede ser que nuestro equipo local no tenga habilitada la regla en el firewall. Para ello ejecutamos el comando siguiente:
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
Para resolver más problemas de conectividad, puedes consultar el enlace siguiente: http://msdn.microsoft.com/en-us/library/gg433016.aspx
8) Mapear la unidad de red a nuestro equipo local. Para ello, abrimos en el explorador de Windows la ventana de “Conectar nueva unidad de red...”, introduciendo la ruta: \\<IPv6>.ipv6-literal.net\<carpeta>, donde <IPv6> es la dirección remota a la que hemos hecho ping en el paso anterior sustituyendo el carácter “:” por “-“ (es la nomenclatura para el comando “net use”), y <carpeta> es el nombre del recurso compartido. Las credenciales usadas son las mismas que usamos al desplegar el servicio en Azure (ver fichero de configuración del servicio desplegado).
Opcional: yo he usado el archivo c:\windows\system32\drivers\etc\host, añadiendo un alias para la IPv6 con un nombre más común. Así sé qué unidad es de cada servidor sin tener que recordar la IPv6. También hay que tener en cuenta que esta IPv6 puede cambiar al reiniciarse el servidor por cualquier motivo, por lo que éste último paso 8 habría que repetirlo de nuevo. Una opción podría ser crear una aplicación cliente que detectara estos cambios y que hiciera un “remap” de las unidades automáticamente.
Conclusiones
El resultado es el poder modificar el contenido del VHD directamente desde nuestro equipo. Las posibilidades se me amontonan en la cabeza. Siempre hay que tener en cuenta que trabajaremos con nuestro ancho de banda a Internet –que por cierto, va impresionantemente bien con una conexión lenta-, por lo que para operaciones “grandes” de copia/pega de archivos sobre la misma unidad, compresión masiva de carpetas, etc. es recomendable conectarse al servidor SMB vía escritorio remoto.
Respecto al DNN Azure Accelerator, comenzaré a trabajar para poner un paso en el asistente para no tener que volver a recompilar el paquete en Visual Studio, tal y como hice con el paso de configuración RDP. En breve estará disponible.
Algunas reflexiones
- Sabiendo que la facturación del espacio consumido por los VHD (Page Blobs) es por “espacio ocupado” (las páginas vacías del VHD no se cobran), ¿te has parado a pensar que podrías tener unidades virtuales en Azure Storage de 1Tb (1.000Gb) cada una en la que Microsoft sólo te cobraría por el espacio utilizado? Si borras ficheros del disco (y lo mantienes desfragmentado), te baja la factura
- ¿Qué tal funcionarán los sistemas de backups tradicionales con una unidad de red montada de este modo? Está claro que aquí el cuello de botella lo impone el ancho de banda de tu conexión a Internet, pero normalmente los programas de copias de seguridad realizan modificaciones incrementales ==> Esto tengo que probarlo
- Tal y como comentó Joe Brinkman, actualizar tu web de DotNetNuke se convierte en cosa de niños simplemente copiando y pegando archivos a través del mismo explorador de Windows:
- ¿Qué tal funcionaría una instancia ExtraSmall si sólo es para servir ficheros a través de la red?
Ya sólo faltaría algún método de alta disponibilidad para el servidor SMB...pero eso también está a punto de llegar...
Espero que sea de utilidad. Para mí lo es...¡y mucho!
