DNM+ Online
dotnetmania 2.0
Sincronización de datos en entornos relacionales con SQL Azure
La nube ha llegado y lo ha hecho para quedarse. Y entre los muchos escenarios posibles de uso que nos ofrece, están todos aquellos que necesitan de uno o varios sistemas de gestión de bases de datos relacionales, con la utilización del servicio Platform as a Service (PaaS) SQL Azure. En este artículo describiremos cómo puede sincronizar una o varias bases de datos SQL Server/SQL Azure con diferentes configuraciones, para permitirle a su organización o empresa la máxima flexibilidad y disponibilidad de los datos en cada momento de acuerdo a sus necesidades y sus restricciones.

Microsoft SQL Azure es un servicio de base de datos en la nube construido sobre la tecnología de Microsoft SQL Server, que le ofrece a su empresa un entorno de datos de alta disponibilidad, gran escalabilidad, soporte de cliente multi-servicio con duplicidad de la información (3 réplicas de sus bases de datos) para una seguridad casi absoluta de los datos. El modelo de base de datos como servicio implica la ausencia de procesos de instalación de software, de aplicación de mejoras o parches de seguridad o cambios de versión. El servicio se proporciona como tal, y todas estas tareas de mantenimiento se realizan desde la entidad que ofrece y proporciona dicho servicio.

En el ecosistema de servicios y aplicaciones relacionadas con SQL Azure, en este artículo vamos a centrar nuestra atención en el producto denominado SQL Azure Data Sync, actualmente en versión CTP2 (Community Technology Preview), que es un servicio de sincronización de datos basado en la nube y construido sobre la tecnología Microsoft Sync Framework.

El servicio nos ofrece sincronización de datos bidireccional entre diferentes entornos de datos, con la premisa de que haya al menos una base de datos SQL Azure por medio (como proveedor de datos o receptor); de esta manera, podemos disponer de sincronización SQL Azure-SQL Azure, o SQL Azure-SQL Server (en todos los casos bidireccional o unidireccional en cualquiera de los sentidos, incluyendo, por supuesto, la casuística de diferentes bases de datos, tanto en la nube como en espacios geográficos distintos). Con la versión actual, es posible extender la funcionalidad de una base de datos on-premise a la nube, incluso en parte, pudiendo éste ser un escenario ideal para, por ejemplo, poder disponer de aplicaciones con datos sensibles (LOPD) en la que los datos públicos sin restricciones de política de datos puedan ir a la nube y los datos críticos en alguna de las prioridades de LOPD (en este caso) puedan permanecer en los centros de datos de las empresas u organizaciones.

Sobre el coste del servicio, a fecha de hoy se ofrece sin coste, si bien se debe tener en cuenta el trasiego de información desde/hacia las bases de datos SQL Azure, que se tarificará al precio del ancho de banda según franja horaria y tipo de petición (inbound/outbound).

Quién es quién en SQL Azure Data Sync

Si quiere probar esta tecnología, antes que nada vamos a introducir algunos conceptos básicos que le servirán de utilidad en el proceso de sincronización (completa o parcial) de bases de datos entre sus sistemas corporativos y la nube.

En la figura 1 se ofrece uno de los múltiples escenarios posibles en lo que a sincronización se refiere cuando hablamos de SQL Azure y Data Sync. En el caso más sencillo, dispondremos de dos bases de datos, una de las cuales estará en la nube (SQL Azure) y otra que estará o bien en Azure o bien en su centro de datos. El caso más complejo podría contemplar decenas de bases de datos organizadas de acuerdo a un esquema corporativo más real (SQL Azure, centro de proceso de datos principal de la corporación y diferentes centros deslocalizados o delegaciones).

Figura 1. Escenario de aplicación de sincronización de datos con la nube

Agente SQL Azure Data Sync. Proceso que se sitúa entre el servidor de bases de datos de SQL Server y la base de datos SQL Azure. Es la entidad que posibilita la comunicación bidireccional segura (HTTPS) entre una base de datos alojada en su centro de proceso de datos y otra en la nube. En el caso de escenarios de sincronización SQL Azure (únicamente), no es necesaria instalación ni configuración alguna. Solo en el caso de que queramos sincronizar con nuestro sistema on-premise será necesario descargar el agente, configurar la conexión y poner en marcha el servicio.

Grupo de sincronización de SQL Azure (Sync Group). Conjunto de bases de datos que participan en un proceso común de sincronización de datos, donde se establece cuál es la que actúa como base de datos principal (hub), y para el cual se planifica un esquema de actualización, unas prioridades u orden y un periodo de tiempo (en minutos u horas) para la ejecución de la sincronización (por grupo de sincronización). Toda base de datos perteneciente a un grupo de sincronización que no es base de datos principal, es una base de datos miembro.

Base de datos principal (Hub). Establece cuál será la base de datos SQL Azure que actuará como punto de referencia dentro de un grupo de sincronización. El proceso de sincronización dentro de un grupo de sincronización es siempre en este orden: primero los cambios en las base de datos miembro se propagan a la base de datos principal, y luego los cambios de la base de datos principal se propagan a las bases de datos miembro (incluyendo las actualizaciones del primer paso).

Base de datos miembro. Dentro de un grupo de sincronización, toda base de datos que no es una base de datos principal o hub. Ya se ha comentado el orden de sincronización, que tiene su importancia a la hora de constatar las situaciones de conflicto o choque de datos entre dos bases de datos que participan en el proceso de sincronización.

Panel de estado (Dashboard). Se trata de un panel de información detallada sobre la sincronización (histórico o log), que reflejará cada una de las operaciones de sincronización de acuerdo a su ejecución y su resultado (filas actualizadas en cada sentido, etc.).

Tarea de sincronización (Sync Job). Se refiere a una tarea de sincronización que se puede añadir a la planificación de sincronización de un determinado grupo de sincronización. Como ejemplo, si un grupo de sincronización se ha configurado para lanzarse cada cinco minutos, durante la ejecución de cada planificación de estas ejecuciones (es decir, cada cinco minutos) se lanzarán tantas tareas de sincronización como sea necesario de acuerdo al escenario que se haya implementado. Por ejemplo, en una sincronización entre SQL Azure y un SQL Server local, de tipo bidireccional, se lanzarán dos tareas de sincronización, una de upload y otra de download (figura 2).

Figura 2. Dos tareas de sincronización para una ejecución de la sincronización planificada

Conflicto de sincronización (o colisión de datos). Se producirá cuando se hayan actualizado dos fuentes de datos diferentes y la base de datos central tenga que resolver la actualización en un proceso de sincronización. Existirá siempre pérdida de datos, pues no se proporciona lógica de resolución de conflictos en el proceso de Data Sync. En caso de conflictos de choque de datos, se utiliza el principio “en caso de colisión, el hub gana”; cuando la primera fuente consulte el hub para ver cambios, éstos se grabarían en el hub, y estos cambios son los que se distribuirán a las siguientes bases de datos (perdiendo los datos que haya en las mismas), siguiendo el orden de sincronización definido en el grupo.

Configuración y realización de la sincronización

Vamos a ver SQL Azure Data Sync a través de un ejemplo práctico, en el que se configurará la sincronización bidireccional de datos entre varias tablas de dos bases de datos, una on-premise (miembro) y otra en SQL Azure (principal o hub). Recuerde que el caso de SQL Azure-SQL Azure tiene una configuración algo más sencilla (no se debe configurar el agente de sincronización). El ejemplo asume que tenemos una cuenta Windows Azure con SQL Azure y alguna base de datos en un servidor de la misma. También asume que disponemos de una clave de Data Sync CTP2 y que está activado el servicio con dicha clave. Puede solicitar claves de prueba para Data Sync y para Reporting Services en Azure desde el sitio de Microsoft Connect [2]. Actualmente, la versión CTP2 no está integrada en el portal de administración general de Windows Azure, y se debe acceder a ella desde un portal de prueba [3]; tras introducir el código de invitación, accederá a la interfaz principal, como se observa en la figura 3.

1. Instalación y configuración del agente en el portal Azure Data Sync

Al tratarse de un proceso de sincronización SQL Azure/on-premise, es necesario utilizar el Agente de sincronización en las máquinas cliente, correctamente configurado para acceder a la base de datos destino/origen (dependiendo de cómo se configure) y para comunicarse con el servidor SQL Azure que haga las veces de principal o hub.

Para acceder a la configuración de los agentes, vaya a la ficha de datos "Agents", donde podrá primero generar una clave de agente (Agent Key), necesaria para configurar la comunicación cifrada con los sistemas on-premise. Para generar esta clave, debe pulsar “Generate Agent Key”, acción que le pedirá un nombre para el agente y creará una clave para el mismo.

Figura 3. Pantalla de descarga y primeras configuraciones del Agente de sincronización

Una vez generada la clave, el siguiente proceso es la descarga del software del Agente (en la parte inferior de la ventana, la opción “Agents Download”, que da acceso a la descarga e instalación de este software en el ordenador que vaya a alojar el servicio de sincronización). Tras la descarga, instalamos el software, que nos pedirá nuestra cuenta de la máquina (debe realizar instalación de servicios del sistema) y la ruta de la instalación.

Figura 4. Instalación del SQL Azure Data Sync Agent CTP2 en la máquina local

2. Configuración del Agente de sincronización local

Antes de la configuración, y como nos va a hacer falta, podemos crear la base de datos en SQL Server local; esta base de datos nueva será donde se regenerará el esquema de la base de datos SQL Azure y después se completarán los datos en la primera sincronización. Podemos usar el código siguiente para crear la base de datos una vez conectados al servidor, usando, por ejemplo, SQL Server Management Studio:

create database DSyncAzureLoteria
go

Instalado el Agente de sincronización local, es necesario realizar la configuración del sistema local utilizando la interfaz WPF de este servicio. Desde "Inicio" | "Todos los programas" | "Microsoft SQL Azure Data Sync" | "SQL Azure Data Sync Agent CTP2", aparece el cuadro de diálogo de configuración (figura 5). Desde aquí, los pasos a seguir son:

  • Primero, habilitar la casilla de verificación “Encrypt Password”, para que la contraseña vaya cifrada en la comunicación.
  • A continuación, utilizaremos “Edit Agent Key”, donde pegaremos el token que hemos generado al dar de alta el servicio en la herramienta web de Data Sync CTP2.
  • Agregamos un nuevo miembro de sincronización (“Add Member”), proporcionando los datos de la base de datos en local (vacía y sin esquema inicialmente), pudiendo usar tanto credenciales de SQL Server como de Windows.
  • Aceptamos y probamos la conexión pulsando el botón “Test connection”. Comprobado que conectamos sin problemas, podemos utilizar “Ping Sync Service” para comprobar que hay conectividad desde el agente de sincronización local con el servicio web en SQL Azure Data Sync.
  • Cuando todo está correcto y el ping ha funcionado, tenemos ya la configuración local casi lista. Se creará internamente un archivo AgentConfigData.xml con estos valores de conexión que guarda nuestra configuración.

Figura 5. Configuración del Agente de sincronización local

3. Inicialización del servicio local de sincronización

Tenemos la parte de configuración Web, hemos configurado el Agente de sincronización contra el sistema (o sistemas locales, pues admite dar de alta varios servidores SQL Server), y el último paso de configuración local consiste en la puesta en marcha del servicio de sincronización de Windows. Desde Windows podemos acceder a la lista de servicios del sistema ejecutando services.msc. Esto abrirá la ventana de servicios y sus configuraciones en Windows 7. En la ventana de servicios, localizamos SQL Azure Data Sync Agent CTP2 y con el botón secundario del ratón elegimos "Propiedades". En la ventana de propiedades, nos aseguramos de que iniciamos el servicio (botón "Start") y que el modo esté establecido en automático. Aplicamos los cambios y pulsamos "Aceptar". Es hora entonces de terminar la configuración de la sincronización estableciendo el grupo de sincronización, las bases de datos y las tablas que intervendrán en la misma y lanzar la primera ejecución y la planificación de las actualizaciones.

4. Creación del grupo de sincronización

Para terminar el proceso de configuración de la sincronización, solo nos falta definir qué bases de datos participarán en el proceso y qué tablas de las mismas se sincronizarán, así como una planificación de cada cuánto tiempo se producirá la descarga de datos (así como la dirección de la misma).

De nuevo en el portal de SQL Azure Data Sync CTP2, primero accedemos a la ficha "Databases", donde debemos ir dando de alta tantas bases de datos como queramos sincronizar. Las bases de datos SQL Server locales deberán tener instalado y configurado el servicio Agente de sincronización.

Pulsamos el botón “Add” para añadir las bases de datos necesarias; en nuestro caso, la que hemos definido en el punto anterior y la base de datos de SQL Azure en la que ya tenemos el esquema y los datos.

Una vez registradas las bases de datos, vamos a la ficha "Sync Groups" (figura 6), donde definiremos los grupos de sincronización del proceso. Cada grupo debe tener una base de datos de las que hemos elegido en la ficha "Databases" que sea la principal, y el resto serán bases de datos miembro. Pulsamos el botón “New Sync Group” y entramos en el modo edición del grupo. Aquí de nuevo los pasos son simples: registrar las bases de datos que queremos unir al grupo (cuadro desplegable “Select Database to Add” y botón “Add”). Repetimos el proceso para las bases de datos que queramos sincronizar en el mismo grupo. Y cuando ya las tengamos (en nuestro caso, una de SQL Azure y una de SQL Server), debemos seleccionar en la lista la que vayamos a elegir como hub o principal (seleccionar en la lista y pulsar el botón “Set Hub”). Comprobamos que se ha detectado y se ha elegido la base de datos principal, y entonces podemos pulsar el botón “Next” para pasar al siguiente elemento de configuración, donde estableceremos qué tablas y en qué orden se producirá la sincronización (importante por el tema de las colisiones).

En este punto, no podemos todavía elegir la dirección (por defecto es bidireccional, pero no podemos cambiarla hasta que no esté finalizado el segundo paso, la configuración de las tablas y el orden de sincronización). Para acceder a esta configuración, pulsamos “Next”.

Figura 6. Configuración inicial del Sync Group y la base de datos principal

5. Selección de tablas a sincronizar y orden de sincronización

El segundo y último paso de configuración web consiste en seleccionar las tablas que queremos sincronizar en cada base de datos. Pulse las flechas derecha/izquierda para agregar tablas de las bases de datos elegidas en la lista a la sincronización, y use las flechas arriba/abajo para cambiar la prioridad (orden) de sincronización de las tablas (teniendo en cuenta las restricciones de integridad y las tablas que dependen de otras tablas y están vinculadas por clave externa).

Es importante en este punto asegurarse de que todas las tablas que participan en la sincronización a través de Data Sync disponen de una clave primaria, pues es un requisito para la sincronización con este servicio. No se realizará la sincronización de aquellas tablas que no tengan definida su clave primaria.

Para establecer la planificación de la sincronización (el mínimo permitido es 5 minutos entre llamadas de sincronización), debe marcar la casilla de verificación "Enabled" y establecer el rango temporal que necesite de cara a la sincronización de los datos. Tenga presente que en bases de datos muy grandes o con gran volumen de transaccionalidad (creación o eliminación y actualización de filas) y en tiempos pequeños se pueden producir problemas debidos a que una sincronización no puede realizarse hasta que no haya finalizado la anterior, y el problema sería que una primera sincronización tardara más del tiempo establecido hasta la siguiente, en cuyo caso la segunda no se realizaría.

Figura 7. Selección de tablas a sincronizar y orden de la sincronización

Ya está el proceso casi terminado. Pulsamos “Create Sync Group” y volvemos a la ficha "Sync Groups", donde al elegir el grupo que acabamos de configurar y pulsar sobre “Edit” podremos acceder a la configuración del sentido de la operación (por defecto bidireccional). También puede añadir más grupos de sincronización o comenzar (forzando) la sincronización de un grupo al pulsar el botón “Sync Now”. Observe al forzar la primera sincronización la lista dinámica de actualización (ficha “Sync Logs”), donde irán apareciendo las diferentes operaciones de conexión, actualización de los esquemas y la primera operación de sincronización de datos que, en caso de ser bidireccional, se dividirá a su vez (esta información está accesible desde el log) en dos tareas de sincronización.

Con esto finalizaría todo el proceso. Nos queda realizar algunos cambios en las bases de datos de SQL Azure o SQL local para comprobar los logs de sincronización y comprobar cómo cuando hay modificaciones de los datos en cualquiera de los extremos se produce la sincronización en las correspondientes tareas de sincronización. Tenga en cuenta que el servicio de sincronización es un proceso de Windows y que consume recursos, máxime si ha escogido una planificación cada cinco minutos; puede que su sistema esté ocupado realizando estos procesos y esto haga que baje el rendimiento de otras operaciones o procesos. Por otro lado, solo conviene elegir estos intervalos tan cortos en situaciones en las que hay una gran transaccionalidad y se necesitan los datos en los diferentes sistemas con relativa alta frecuencia.

Buenas prácticas para la sincronización Cloud

Ubicación física de los servidores SQL Azure con respecto a sus sistemas

Aunque es algo obvio, no viene mal comentar que la ubicación de la base de datos que haga las veces de principal o hub deberá estar lo más cerca posible del resto (o del grupo mayor de bases de datos que tengan que usar el servicio). De esta forma, se minimizarán los costes de latencia por proximidad. De la misma forma, si las bases de datos SQL Azure están en el mismo DataCenter de Microsoft, se ganará en rendimiento de sincronización.

Planifique correctamente el orden de ejecución de las sincronizaciones

Recuerde que el orden de las bases de datos y de las tablas en los grupos de sincronización tiene una importancia manifiesta; en caso de conflictos, siempre se aplica la regla “el hub gana” y el hub se actualiza de acuerdo al orden establecido en cada grupo.

Middleware para manejar colisiones de forma ‘inteligente’

Para minimizar las consecuencias de las colisiones de sincronización, podemos intentar ejecutar los procesos de sincronización de forma controlada a través de una capa de software de tipo middleware que reciba las peticiones de actualización de datos y se encargue de resolver conflictos de una manera más elaborada; esta aproximación requiere la programación del proceso de actualizaciones vía un componente intermedio (Web Role o Worker Role) que se encargará de encolar las peticiones, mantener cierto nivel de conocimiento sobre las actualizaciones solicitadas y solicitar la actualización de datos de acuerdo a nuestra propia lógica de sincronización, intentando perder la mínima cantidad de datos en el proceso o redirigiendo los conflictos a espacios temporales donde puedan ser monitorizados manualmente y aprobados los cambios en el orden apropiado.

Grupos de sincronización extremadamente densos

Se consideran grupos de sincronización extremadamente densos los grupos de sincronización que incluyen un volumen de datos lo suficientemente grande y una periodicidad de sincronización tan ajustada que provoquen que una tarea de sincronización no pueda acabar antes del comienzo de la siguiente. En este caso, las sincronizaciones siguientes a la que no ha terminado todavía no se llevarán a cabo; por lo tanto, es una buena práctica conocer tanto los volúmenes de información movidos en cada caso como los tiempos planificados para las actualizaciones. Intente que la primera actualización sea bajo demanda (sin planificación), y a continuación, el resto se realicen según el esquema previsto y previendo la carga media de transacciones de una sincronización de su grupo, y dejando suficiente margen de tiempo entre dos ejecuciones consecutivas de la sincronización.

blog comments powered by Disqus