Muchas de las aplicaciones existentes dependen de la escritura de archivos para poder funcionar correctamente. En este articulo vamos a ver como podemos seguir escribiendo y leyendo archivos sin modificar nuestra aplicación permitiendo facilitar la migración de una plataforma a otra.

Básicamente tenemos 2 escenarios posibles. El primero de ellos y en realidad, el más interesante es cuando tenemos una aplicación desplegada en múltiples instancias y requerimos de un medio de almacenamiento de archivos que se encuentre disponible para sea cual sea la instancia que lo esta accediendo. En este escenario no podemos utilizar el storage local de una instancia de Windows Azure, dado que solo estará disponible para esta y al mismo tiempo, si esa instancia es eliminada perdemos esos datos. El otro escenario es cuando solamente necesitamos almacenar archivos dentro de la instancia, lo cual puede ser porque solo tengamos pensado utilizar una única instancia y nos importe por otro lado si los datos son eliminado tras borrar esa instancia. En dicho caso, podemos utilizar los recursos locales de la instancia y almacenar los archivos en ella.

Otro caso un poco distinto, es cuando necesitamos acceder a archivos que son de una herramienta o componente de tercero, para lo cual debemos especificar un ruta en particular.

En base a los casos anteriores tenemos 3 formas de manejar los archivos.

  • Referencia directa.
  • Utilizando el storage local de Windows Azure.
  • Utilizando Windows Azure Drive (X-Drive)

Referencia Directa

En este caso estamos usando el file system de la misma forma en que lo venimos utilizando en las aplicaciones on-premise.

image

En este método tenemos que tener las consideraciones necesarias con respecto al path en donde vamos a almacenar los archivos. Una de las posibilidades es especificar el path en forma manual ej.: C:\DemoAzure teniendo en cuenta que ese path debe existir y la aplicación debe tener permisos para escribir en dicho path. Esto eventualmente lo podemos realizar con un script o en forma manual con el escritorio remoto. La otra posibilidad es hacerlo en un path relativo a la deployment de la aplicación. En este último caso tenemos que tener la consideraciones de que la herramienta de despliegue de Visual Studio solamente incluye las carpetas que contienen archivos, dado que este mecanismo no esta contemplado directamente debemos incluir un archivo para que la misma sea tomada en cuenta y se agregue en el despliegue.

image

Una vez contemplado que el directorio donde queramos escribir se encuentre creado y que la aplicación tenga los permisos correspondientes (de forma similar a on-premise) el código será exactamente el mismo.

En este escenario hay que tener en cuenta que si eliminamos la instancia del role entonces perderemos los archivos almacenados mediante este mecanismo y por otro lado estos archivos no pueden ser compartidos con las demás instancias estando disponibles solamente para la instancia que se encuentra en el servidor local.

Utilizando el storage local de Windows Azure

Este mecanismo es muy similar al anterior, solo que delegamos la administración del directorio y la gestión de los permisos a las librerías de Windows Azure. Como consecuencia no podemos decidir cual será exactamente el directorio en donde se almacene dichos archivos.

La forma de crear estos recursos es configurándolo para cada uno de los roles definidos. Podemos hacerlo utilizando Visual Studio:

image

Dentro de los parámetros a configurar especificamos el nombre que va a tener este recurso, y por el cual nosotros lo vamos a poder identificar dentro de la aplicación, el límite de espacio que le vamos a asignar y si el mismo debe ser limpiado cuando se recicle el role, lo cual puede ser por motivos intencionales, actualizaciones o algún error que surja y que provoque la necesidad de reiniciar el role.

image

Este escenario es exactamente igual al anterior, por lo que los archivos estarán almacenados dentro del storage local del role y el mismo no estará disponible si se elimina el role o si necesitamos accederlo desde otra instancia.

Utilizando Windows Azure Drive (X-Drive)

En este caso los archivos no serán almacenados dentro del storage local de la instancia como los 2 anteriores, sino que utilizará las páginas de un blob como recurso para administrarlos como un driver utilizando NTFS. Este mecanismo nos permite utilizar los archivos desde múltiples instancias y no corremos peligro de que los mismos se pierdan por algún error, actualización o la necesidad de eliminar una instancia en particular.

El acceso a este recurso es muy similar a los anteriores por lo que el impacto del cambio es muy bajo. Por otro lado también nos permite realizar sistemas altamente escalables y replicar nuestra información geográficamente.

image

En este ejemplo primero obtenemos la configuración del storage que vamos a utilizar. Luego creamos un cache local para poder realizar lecturas más rápidas y disminuir la cantidad de idas y vueltas al storage; este cache debe estar configurado como se muestra en la sección anterior. Posteriormente crea el blob si no existe y da de alta la utilización de ese blob como una unidad de disco, designada por la letra X de ahí el nombre.

Posteriormente la utilización es la misma que en los demás casos, asignado al recurso mediante la letra del driver.

Este mecanismo es el más escalable de los tres y el que permite concurrencia de instancias, nos asegura no perder ningún dato, y poder desplegarlo geográficamente.