El 5, 8, 12 y 14 de Abril, se estará llevando a cabo un evento de capacitación en Windows Azure organizado por Eduardo Mangarelli. Voy a tener el agrado de poder participar de esta sesiones conjuntamente con Ricardo Gonzalez Vargas, Eduardo Castro y Jaimir Guerrero.
Contenidos:
Aprenda cómo ejecutar las aplicaciones existentes en Windows Azure con dos nuevas características y altamente solicitado: VM Role y Modo administrador. Vamos a demostrar las mejores prácticas para crear y cargar imágenes personalizadas del sistema operativo, la implementación y la gestión de los servicios que utilizan esas imágenes, y la automatización de la configuración utilizando el modo de administración y el modelo de servicio.
Una de las principales tareas que debemos realizar al considerar migran un proyecto a la plataforma de Windows Azure es la migración de la base de datos. En una primera instancia hay que verificar cuales son as características que estamos utilizando de la base de datos y corroborar que no estemos utilizando ninguna característica que no se encuentre disponible. En caso de estar utilizando alguna de ella debemos identificar para que se requiere y determinar cuales son los posibles caminos alternos.
Features no disponibles en SQL Azure.
Una vez que corroboramos cada unas de estas características y en la medida de lo posible haberlas suprimido ó modificado por otros mecanismos podemos realizar la migración de nuestra base de datos. Esencialmente el motor de SQL Azure es similar al motor de SQL Server 2008 R2, con lo cual podríamos ejecutar directamente los scripts para crear la base de datos; aún así, hay distintas consideraciones que debemos tener en cuenta dentro de las bases de datos en Azure; por ejemplo todas las tablas deben tener índices clustered. Para validar cada una de estas características y poder adecuar los scripts así como alertarnos sobre features que estemos utilizando y que no se encuentren disponibles podemos utilizar la herramienta de migración de bases de datos. SQL Azure Migration Wizard. Esta herramienta nos permitirá generar los scripts para crear nuestra base de datos en SQL Azure; aún así, hay muchas características y validaciones que debemos realizarlas en forma manual.
 |
En el paso inicial podemos seleccionar la opción SQL Database del grupo Analyze and Migrate. Esta funcionalidad nos genera los scripts para poder crear los elementos de nuestra base de datos dentro de SQL Azure y al mismo tiempo nos generan los scripts para migrar los datos contenidos en las tablas a migrar. |
 |
Luego especificamos la conexión a la base de datos que vamos a utilizar para la migración. |
 |
En el paso siguiente debemos especificar cuales son los componentes que deseamos migrar. Si bien lo más común es migrar toda la base de datos es aconsejable que se realicen los scripts por separado siguiendo el siguiente orden, primero las tablas, luego las vistas o funciones y por último los stored procedures. Al realizar cada uno de estos componentes por separado nos permite identificar más fácilmente los errores que nos marque la herramienta y podemos corregirlos en forma independiente. Al generar primero las tablas nos aseguramos que la estructura y campos de cada una sean válidos, así como los índices. Una vez que la herramienta hace su procesamiento y nos genera el script debemos correrlo en forma manual para terminar de depurarlo y modificarlo si es necesario. Una vez que el script es procesado por SQL Azure correctamente podemos continuar con las vistas o funciones, y finalizar con los stored procedures haciendo el mismo procedimiento que hicimos con las tablas. |
 |
Al ejecutar proceso de análisis de migración vamos a ver que varias modificaciones son realizadas en automático. Nuestra primer tarea es verificar que ninguna de esas conversiones realizadas afecten al funcionamiento de nuestro sistema. Por otro lado, varios de los mensajes nos advertirán de modificaciones que debemos realizar que la herramienta no puede hacerlo en forma automática; para solucionar cada una de estas debemos ver el log dejado por la herramienta y proceder a la ejecución manual del script en donde vamos a poder identificar cada uno de los errores que nos informe SQL Azure sobre el script que estamos intentando desplegar. |
 |
En la solapa derecha podemos ver el script generado por la herramienta, guardarlo y procesarlo manualmente utilizando el Management Console del SQL Server 2008 R2 para conectarnos a la base de datos de SQL Azure y hacer el despliegue de nuestras tablas, vistas, funciones y stored procedures. Podemos ver que al final del script de las tablas tenemos los comandos para restaurar los datos, los cuales se encuentran en archivos .dat guardados por la herramienta. |
Esta herramienta también posee una aplicación batch que nos permite hacer la ejecución de los scripts y la misma sirve para subir los datos hacia SQL Azure.
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.
En este caso estamos usando el file system de la misma forma en que lo venimos utilizando en las aplicaciones on-premise.
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.
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.
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:
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.
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.
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.
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.
Inicialmente, ofrece una base de datos relacional como un servicio, hay nuevas mejoras a la experiencia del usuario y adiciones a los servicios de datos relacionales siempre. En particular, las actualizaciones de SQL Azure Data Sync, activan la sincronización de datos entre en las instalaciones de SQL Server y SQL Azure. Además, SQL Azure Reporting, pronto estará disponible para los clientes y socios para proporcionar información sobre bases de datos SQL Azure. En esta sesión se ofrecerá una visión general y la demostración de todas las mejoras a los servicios de SQL Azure, y explora los escenarios sobre cómo utilizar y sacar provecho de estas nuevas características.
Con el fin de sacar el máximo provecho de Windows Azure y SQL Azure, lo que necesita saber, más que la forma de escribir el código. Usted necesita saber cómo incorporar la aplicación en un ambiente de equipo, implementar, controlar, gestionar y recuperar información de diagnóstico posterior de la nube. En esta sesión, aprenderá todo lo que necesita saber para tener éxito con un proyecto que utiliza Windows Azure y SQL Azure como la configuración de su entorno de desarrollo, la automatización de crear, unidad de prueba e implementación de entornos diferentes, de puesta en escena a la producción y la gestión de las credenciales y las funciones de usuario utilizando el Windows Azure Portal. También aprenderá a utilizar el Windows Azure Portal, para supervisar y gestionar la aplicación para descubrir problemas y cómo utilizar los diagnósticos, escritorio remoto, IntelliTrace para depurar y solucionar esos problemas.
Estamos introduciendo varias características, nuevas y emocionantes para Windows Azure. En esta sesión se tendrá una visión de alto nivel de las nuevas capacidades que incluyen: Nueva función de la máquina virtual, Mejoras en el rol de IIS Web, Privilegios elevados, Escritorio remoto, Windows Azure Virtual Networking, Nuevo Portal de Gestión y mucho más.
Una de las nuevas características de Windows Azure es la posibilidad de acceder a cada uno de los Roles (Web, Worker y VM) mediante el escritorio remoto. Esta nueva posibilidad nos permite personalizar mucho más nuestra instancia, permitiendo realizar instalaciones más particulares para nuestros casos de uso y utilizar distintos componentes que nuestra aplicación requiera.
A continuación vamos a ver los pasos necesarios para poder acceder a nuestro web role utilizando el escritorio remoto:
 |
Lo primero que debemos realizar es configurar nuestra aplicación habilitando la opción de acceso remoto, especificar el usuario y el password para el cual se permite el acceso. Para realizar esta configuración podemos utilizar el formulario de publicación de Visual Studio 2010. |
 |
En el formulario de despliegue presionamos sobre la opción “Configure Remote Desktop connections…” en donde mediante la utilización de una serie de formularios nos ayudarán a configurar cada una de las características necesarias de nuestra aplicación. |
 |
Si no poseemos ningún certificado disponible para utilizar podemos crear un certificado seleccionando la opción “create”. |
 |
Especificamos el nombre del usuario y el password que vamos a utilizar para acceder a la instancia mediante el escritorio remoto. |
 |
Una vez que configuramos el certificado y las credenciales que vamos a utilizar necesitamos exportar el certificado para almacenarlo dentro de Windows Azure. |
 |
Exportamos el certificado marcando la opción “Exportar la clave privada” |
 |
Seleccionamos la opción “intercambio de información personal: PKCS … |
 |
Especificamos la contraseña del certificado y almacenamos en un archivo del certificado exportado. |
 |
Luego, dentro del portal de Windows Azure subimos el certificado que acabamos de exportar especificando nuevamente el password. |
 |
Habilitamos el uso del escritorio remoto para la instancia que estamos subiendo y configuramos las credenciales que vamos a utilizar para conectarnos. |
 |
Una vez configurado e inicializado el role podemos conectarnos mediante el escritorio remoto con las credenciales especificadas en la configuración. |
 |
Esta es la vista del escritorio remoto del web rolo. Podemos observar que tenemos acceso a todos los recursos y podemos visualizar el IIS con nuestro sitio desplegado. |
 |
Esta es la vista de la performance de nuestra instancia, en este caso es una instancia Medium. |
 |
Se puede acceder a los servicios y su configuración; varios de ellos son servicios creados y configurados específicamente para Windows Azure. |
 |
De la misma forma podemos acceder al file system y ver distintos archivos de configuración de nuestro sitio. |
Muchas aplicaciones hacen uso del objeto session para almacenar datos de las sesiones que mantienen con un usuario o instancia de explorador. Este mecanismo les permite mantener datos entre las distintas peticiones de las páginas y recursos en general del sistema y de esta forma compartir información o almacenarla para no tener que consultarla sucesivamente y obtenerla cada vez que se requiera.
La utilización de este tipo de mecanismos tiene algunas; la primera de ellas es que el sitio estará dependiendo del estado en el que se encuentre; o sea, que no será stateless. Con esto queremos decir que dada una página o recurso x que haga uso de la sesión puede tener dependencias con que otra página o recurso allá dejado datos en dicho objeto para posteriormente obtenerlo. Si no utilizamos correctamente este objeto podemos estar creando dependencias entre recursos de nuestro sistema que no necesariamente tienen que existir y estaríamos limitando la utilización del mismo.
Otra desventaja que encontramos si no lo utilizamos correctamente es que el sistema está impidiendo la escalabilidad horizontal del mismo debido a que por defecto los datos de la sesión se guardan dentro del servidor de la aplicación. Mientras la aplicación se encuentre desplegada en un solo servidor no vamos a tener inconvenientes con este tipo de mecanismos, pero al desplegarlo en varios buscando escalar la aplicación horizontalmente no vamos a encontrar con un problema. Este fenómeno produce que, si tenemos 3 servidores para resolver las peticiones que le realicen a nuestro sistema, al gestionar por primera vez un recurso tal como una página responde el servidor A, mientras que la segunda vez que realicemos una petición puede responder el servidor B y el mismo no tener acceso a los datos de sesión que guardo el A en su mismo servidor.
Descripción de los pasos:
Como consecuencia de este escenario nuestro sistema sólo admite ejecutarse en un servidor para obtener un funcionamiento correcto.
Para evitar este tipo de conflicto debemos almacenar los datos de la sesión en un almacenamiento que sea accesible desde cualquier servidor y que permita que todos lo acedan al mismo tiempo pudiendo obtener los recursos necesarios.
Cuando estamos pensando en hacer un sistema bajo la plataforma de Windows Azure estamos pensando en que nuestro sistema debe ser escalable para poder abastecer la demanda que se presente en cada momento y no estar nunca con los recursos por debajo de los necesarios para procesar las peticiones. Por tales motivos la utilización del objeto session deben ser previamente analizados para no generar este tipo de problemas.
Para poder habilitar la utilización del objeto session dentro de Windows Azure debemos realizar los siguientes pasos.
De esta forma podemos utilizar el objeto session dentro de nuestros sistemas en Azure sin ningún problema. En este ejemplo la sesión esta siendo almacenada en SQL Azure. Dentro del trining Kit de Azure viene un ejemplo de como hacer para que se almacenen los datos en el table storage de Azure (ASPProviders).
Tema Rubric. Blog de WordPress.com.
