Recientemente Microsoft ha lanzado una nueva versión del portal de administración de SQL Azure, versión hecha completamente en Silverlight 5.

Entre las principales novedades a destacar está el hecho que se ha incluido información que permite monitorizar ciertos aspectos de la base de datos, cosa que anteriormente se podría llegar a a hacer, pero no de una manera tan sencilla como ahora. Eso sí, esto no quita que se echen de menos algunas características adicionales de monitorización, pero este puede ser un primer paso.

En un post anterior os presentaba un pdf de descarga gratuita que hemos creado con información sobre la plataforma Windows Azure.

Acabamos de publicar la segunda parte sobre los sistemas de almacenamiento en Windows Azure, dónde se habla de SQL Azure y WIndows Azure Storage.

Parte I – Introducción a Windows Azure

Parte II – Sistemas de almacenamiento, SQL Azure y Windows Azure Storage

Recordad que con este contenido lo que hemos intentado es hacer una labor de recopilación de toda la información que hemos ido realizando desde la primera versión de la plataforma, para una vez actualizada, poder presentarla de forma ordenada al lector y así simplificar el proceso de aprendizaje.

Espero que os sea de utilidad!

Una de las nuevas funcionalidades que estarán disponibles en SQL Azure para finales de 2011 es la característica de federación.

Uno de los grandes beneficios de la plataforma Windows Azure es la capacidad que ofrece a la hora de escalar aplicaciones. De manera muy sencilla y dinámica un usuario puede modificar el número de instancias de una aplicación.

Hablando de instancias de Windows Azure este punto es cierto, pero la base de datos podría convertirse en un cuello de botella, ya que ésta no tiene la capacidad de escalado que tienen las instancias de Azure. El usuario no dispone de la posibilidad de realizar un escalado horizontal y aumentar o disminuir las bases de datos SQL Azure en función de las necesidades de la aplicación.

Por ejemplo, este es un escenario típico en aplicaciones multi-tenant, dónde con un mismo despliegue se quiere ofrece el servicio a diferentes clientes.

Al implementar soluciones de este tipo la primera aproximación es usar una única base de datos capaz de contener la información de todos los clientes.

Esta solución es perfectamente viable, pero en algunos escenarios surgen problemas de escalabilidad en caso de que la aplicación crezca en el número de clientes.

Otra de las soluciones aportadas, buscando un alto grado de escalabilidad ha sido utilizar múltiples base de datos, en lugar de una única que contenga todos los datos de la aplicación.

La aplicación es capaz de gestionar múltiples clientes diferentes, cada uno con su información, pero a nivel de base de datos cada uno tiene su base de datos propia.

Este escenario es perfectamente viable, pero implica que si existen 1000 clientes existirán 1000 base de datos, lo que aumente la complejidad de administración de la aplicación y claro está, los costes de despliegue.

SQL Azure Federation viene a cubrir este tipo de escenario, ya que esta característica simplificará enormemente el escalado horizontal, posibilitando que el usuario pueda aumentar o disminuir las bases de datos de la aplicación de forma dinámica y sin que este hecho provoque una parada del servicio.

Es el usuario quién decide los miembros de la federación, es quién decide cuándo añadir o disminuir miembros y es quién decide en base a qué criterio debe realizarse la partición de la información (en la primera versión sólo soportará la partición por rangos, por ejemplo, por cierto valor de un determinado campo).

La sintaxis de la sentencia para crear una federación es la siguiente:

Dentro de la federación existe un elemento que se conoce como “Federation Root”. Este elemento representa el nombre lógica de la base de datos y es quién conoce todos los miembros de la federación y qué información tiene cada uno de ellos.

Las aplicaciones siempre debe conectarse al “root”, y éste quién dirige las peticiones a la base de datos correspondiente.

SQL Azure Data Sync es una de las funcionalidades de SQL Azure accesible desde el portal de administración de Windows Azure, aunque esté todavía en CTP.

Básicamente, como se puede entender de su nombre, es un servicio de sincronización de datos, que permite sincronizar base de datos de SQL Azure que estén en el mismo o diferente datacenter o based de datos que se encuentren on-premise con base de datos que se encuentren hosteadas en Windows Azure.

La sincronización entre las base de datos se podrá hacer de forma bidireccional.

Como paso adicional que se verá posteriormente, la sincronización con una base de datos on-premise requiere la instalación de un agente de sincronización en el servidor on-premise. Este paso no es necesario en el caso de realizar el proceso entre base de datos que estén en Windows Azure.

Como se ha comentado anteriormente toda la funcionalidad está accesible desde el portal de administración de Windows Azure.

Una vez se accede a la característica de sincronización, el primer paso será realizar un aprovisionamiento del servicio. El proceso de aprovisionamiento pedirá que aceptar los términos de licencia e indicar en qué datacenter se quiere realizar dicho aprovisionamiento.

Una vez realizado el proceso se habilitarán las opciones de sincronización. En proceso de sincronización es un asistente en el cuál se guiará paso a paso sobre todas las acciones necesarias para configurar un proceso de sincronización.

Sincronización entre base de datos SQL Azure

Si se selecciona la opción de sincronización entre base de datos SQL Azure, el primer paso será dar un nombre a dicho proceso.

El siguiente paso será añadir una de las base de datos a sincronizar, indicando la ubicación de la misma y las credenciales de acceso.

El siguiente paso será elegir la base de datos con la cuál se realizar la sincronización.

En este paso, como se puede apreciar en la figura, se debe elegir la dirección del proceso de sincronización.

Una vez indicados los dos puntos de la sincronización el siguiente paso será indicar la periodicidad del proceso y el método de resolución detección de conflictos que quiere aplicarse.

Y en el último paso puede definirse con más detalle qué información es la que se desea sincronizar; qué tablas, qué columas etc…

Y por último,el asistente pedirá guardar los cambios seleccionando la opción de “deploy”.

Una vez configurado todo el proceso desde el portal de administración podrá verse toda la información del proceso y claro está,modificar cualquiera de los elementos configurados en el asistente.

Así mismo también el portal de administración nos ofrece la posibilidad de consultar un log con todas las operaciones que se realizan en los procesos de sincronización.

Comentar por último que aunque en este apartado el proceso de creación del grupo de sincronización se ha hecho a través de un asistente, existe también la posibilidad de no usarlo y de crear el proceso de sincronización de forma “manual” consiguiendo, claro está, el mismo resultado.

Sincronización con un servidor on-premise

El proceso de sincronización con un servidor on-premise es prácticamente igual al realizado entre servidores SQL Azure, salvo por el hecho que implica la instalación de un agente de sincronización en el servidor on-premise.

Aunque para realizar un proceso de este tipo se podría utilizar un asistente similar al visto anteriormente, en este ejemplo lo que se va a realizar es añadir un servidor on-premise al grupo creado anteriormente.

Para ello, sobre el diagrama de la Figura anterior puede seleccionarse la opción de añadir un servidor on-premise.

Dicha opción permite añadir un servidor que ya disponga del agente de sincronización o un nuevo servidor que no lo tenga. En este caso se optará por la segunda opción.

Después de este paso será necesario descargarse el agente de sincronización (msi) e instalarlo en el servidor on-premise. Una vez instalado hay que arrancar el agente (desde el menú inicio) e indicarle la clave de acceso generada en el paso 3.

Una vez hayamos configurado la clave, el siguiente paso será registrar la base de datos local que queremos sincronizar.

Una vez hecho este paso, se podrá ver cómo la base de datos registrada se muestra en el servidor y podemos seleccionarla para ser usada en el proceso de sincronización.

Una vez añadido el servidor, para que la modificación tenga efecto será necesario volver a realizar un despliegue, seleccionado la acción “deploy”.

[post original publicado en el blog de Juan Carlos Gonzalez]

Uno de los anuncios que ha hecho Microsoft con respecto a SQL Azure es que por fin tenemos la posibilidad de comenzar a usar SQL Azure Reporting (hasta ahora su uso estaba restringido). En mi caso, tenía ganas de ver de que va esto de SQL Azure Reporting y he de decir que me he quedado un tanto decepcionado ya que:

• Sólo se pueden crear informes para BD’s SQL Azure, no estando soportados otros orígenes de datos.
• A la hora de crear un informe de SQL Azure Reporting hay que dar más de una “vuelta” hasta darte cuenta del proceso.
• Relacionado con lo anterior, que no se pueda lanzar el generador de informes desde el portal de Azure para facilitar la creación del informe.

Dicho esto, vamos a ver un pequeño paso a paso de como crear un informe de SQL Azure Reporting:

• Nos conectamos al portal de Windows Azure y nos validamos con nuestra suscripción. Pulsamos sobre la opción “Informes” disponible en el menú vertical.
• Lo primero que tendremos que hacer es crear un servidor de SQL Azure Reporting a través de la opción correspondiente. A continuacón, se muestra la correspondiente ventana de Términos de uso…pulsamos “Siguiente” en la misma.
• En la nueva ventana del asistente, especificamos la suscripción de Azure a crear y la región de provisionaiento y pulsamos “Siguiente”.

Tras especificar usuario y contraseña para SQL Azure Reporting y pulsar Siguiente, comienza el provisionado del servicio.

• Cuando el proceso acaba, veremos que tenemos creado un nuevo servidor de SQL Azure Reporting bajo nuestra suscripción que podemos proceder a utilizar.
• Lo primero que necesitamos es un origen de datos que crearemos con la opción correspondiente en la sección Data Source. En esta ventana especificaremos la cadena de conexión que tiene que ser de la forma:

   1: Server=tcp:<Servidor_SQLAzure>.database.windows.net;Database=Customers;User ID=UsuarioSQLAzure;Password=ContraseñaSQLAzure;Trusted_Connection=False;

• Fijaros que a la hora de especificar la conexión, podemos indicar que o bien se soliciten las credenciales o que estas estén almacenadas de forma segura a nivel de base de datos. En mi caso, he escogido la primera opción aunque la buena práctica sería la segunda y usando un login de SQL Azure con los permisos mínimos para permitir la visualización del informe.

• Probamos que la conexión a nuestro SQL Azure es correcta.
• Una vez creado el origen de datos, este debería aparecer en el listado de objetos de reporting disponibles en el servidor de SQL Azure.
• A continuación,el objetivo es crear un informe a partir de ese origen de datos definido…y la clave para crearlo es la url del servidor de informes.

• Esa Url es la que tenemos que especificar en las opciones de configuración del generador de informes (aká Report Builder).
• De esta forma,cuando vayamos a crear un origen de datos podremos seleccionar el ya disponible en SQL Azure Reporting. Tened en cuenta que se os irán pidiendo credenciales de acceso al servidor según vayáis creando los sucesivos elementos que se necesitan en el informe.
• Una vez que tenemos disponible el origen de datos del informe, podemos crear un conjunto de datos a partir del mismo.

• Lo siguiente que haremos es diseñar la consulta del informe, ya sea visualmente o vía T-SQL.
• Probamos que la consulta está operativa.
• Y a continuación definimos un informe sencillo sobre la base de ese conjunto de datos.

• Para cargar el informe en el servidor de SQL Azure Reporting, simplemente usamos la opción de carga disponible en el portal de Windows Azure.
• Para visualizar el informe desde el servidor de SQL Azure Reporting, simplemente navegamos a la Url del servidor de informes y hacemos clic sobre el informe en cuestión.
• Cómo es lógico, y de acuerdo a mi configuración, se nos pedirán las credenciales de ejecución.

• Tras especificar dichas credenciales, el informe se muestra sin problemas:

Y hasta aquí llega este primer post sobre SQL Azure Reporting.