Conectar una Azure Cloud Drive directamente a tu equipo

ConnectLlevo 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.

Mapped-drive-on-Azure

¿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.
WindowsAzureConnectBeta

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.

RelayRegion

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.

InstallLocalEndPoint

Una vez instalado, podrás ver en el área de notificación de la barra de tareas de Windows el icono correspondiente al servicio.

AzureConnectClient

ConnectDiagnostics

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.

GetActivationToken

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.

IntroducingActivationToken

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):

Management Network

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>.

Ipv6

PingResponse

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).

MappingTheDrive

Credentials

Opcional: yo he usado el archivo c:windowssystem32driversetchost, 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.

DriveMapped

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 Sonrisa
  • ¿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 Lengua fuera
  • 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:
    jbrinkman
  • ¿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!

Modificar las credenciales RDP en los roles de Azure sin Visual Studio

remotedesktopUno de los principales problemas que se ha encontrado la gente al gestionar una aplicación en Azure es el no poder habilitar de una forma sencilla la conexión a escritorio remoto. ¿A qué me refiero con sencilla? Pues a no tener que descargar Visual Studio 2010 sólo para generar el paquete con las credenciales de acceso y generar el certificado X509 con el que se encriptan las mismas.

Y es que aunque Visual Studio nos automatiza mucho esta tarea, hay perfiles “no desarrolladores” (por ejemplo, nuestros compis de IT) que no suelen tener instalado Visual Studio en sus equipos, aunque posiblemente sí se tengan que encargar del depliegue y gestión de roles en Azure (¿ha llegado ese momento?).

Para ello usaremos:

  • Utilidad makecert.exe, para generar los certificados
  • Consola de comandos de PowerShell

NOTA: el paquete “cspkg” a desplegar en Azure estará “compilado” como que tiene RDP habilitado (es decir, que el fichero de definición del servicio tiene importado los espacios de nombres de RemoteAccess, etc.). Aquí lo que se trata es de poder usar otras credenciales que las que se crearon en tiempo de compilación, así como otro certificado.

Generando manualmente el certificado X509

1) Crear un certificado a través de línea de comandos con la utilidad “makecert.exe”, haciendo exportable la clave:

makecert.exe -r -pe -a sha1 -ss My -len 2048 -sky exchange -n "CN=Azure Deployment" mycertificate.cer

Habilitar RDP en Azure

Es importante indicar el parámetro “-sky exchange” ya que si no nos encontraremos con el error “The remote desktop certificate with thumbprint ‘xxx’ does not have a type of key exchange and cannot be used for decryption” al intentar usar este certificado en Azure.

2) Exportar el certificado en formato “PFX” para subirlo y asociarlo al servicio en Azure. Para ello:

  1. Abrimos el gestor de certificados desde una consolad e comandos tecleando “certmgr.msc”
  2. Localizamos el certificado que acabamos de generar y pulsamos el botón “Exportar” para abrir el asistente de exportación
    Exportar Certificado a PFX
  3. Seguimos las instrucciones del asistente, exportando la clave privada así como todas las propiedades extendidas del certificado
    Export PFX Assistant
  4. Finalmente introducimos una contraseña que usaremos en el momento de importarlo en Azure y un nombre de fichero “.pfx”

3) Importar el certificado en Windows Azure a través de la consola de administración de Azure. Importamos el certificado pulsando botón derecho sobre el servicio y agregando el fichero y su contraseña que hemos generado:
Add Certificate to the service
Upload certificate to Azure

Generar la contraseña encriptada

El siguiente paso, es generar la contraseña que deseemos para nuestras credenciales RDP. Una de las formas más sencillas, para los amantes de PowerShell, es a través de la consola usando los pasos siguientes:

1) Abrir una consola de comandos PowerShell, a través de Inicio>Accesorios>Windows PowerShell (ejecutar como “Administrador” pulsando el botón derecho sobre el icono)

2) Ejecutar los comandos siguientes pulsando Enter después de cada línea:

[Reflection.Assembly]::LoadWithPartialName("System.Security")
$pass = [Text.Encoding]::UTF8.GetBytes("<Password>")
$content = new-object Security.Cryptography.Pkcs.ContentInfo –argumentList (,$pass)
$env = new-object Security.Cryptography.Pkcs.EnvelopedCms $content
$env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient(gi cert:CurrentUserMy<Thumbprint>)))
[Convert]::ToBase64String($env.Encode())

Recuerda cambiar el valor "<Password>” por la contraseña que desees. También debes modificar el valor “<Thumbprint>” por la huella del certificado que generaste en la sección anterior. La forma más sencilla de encontrar este valor es en el panel de control de Windows Azure, seleccionando el certificado y viendo las propiedades en la barra lateral derecha:

Certificate Thumbprint

3) Copia esa información en el Notepad, eliminando los caracteres de nueva línea.

Introduciendo los valores en el fichero de configuración del servicio

Finalmente, con los valores anteriores, abrimos el fichero de configuración del servicio (.cscfg) y modificamos los valores solicitados:

Service configuration file

Indicar que la fecha de expiración de la cuenta debe estar en formato ISO 8601 “yyyy’-‘MM’-‘dd’T’HH’:’mm’:’ss’.’fffffffK”.

Conclusión

Como hemos visto, hemos realizado todo el proceso sin tener que tocar Visual Studio. Del mismo modo, todo este proceso puede automatizarse programáticamente a través de .NET, creando una simple utilidad para facilitar las labores a nuestros compañeros.

Un ejemplo de esta implementación, es el nuevo paso en el asistente del DNN Azure Accelerator en el que se simplifica la generación del certificado, se solicitan estas credenciales y se encriptan en un sólo paso (idéntico al que está en Visual Studio 2010!!).

Os dejo con dos capturas de pantalla como avance. Lo subiré a CodePlex en breve:

RDP Settings on the DNN Azure Accelerator

RDP enabled packages

Espero que sirva de ayuda.

Un saludo a todos.