Replica geográfica de SQL Database Azure

Uno de los principales factores para los sistemas de misión crítica y de alta disponibilidad para asegurar la continuidad operativa es la disponibilidad de la base de datos.

Si bien, en forma interna, Azure realiza distintas instancias de cada base de datos que instanciamos de SQL Database, dichas copias existen para asegurar la operación por parte de Azure.

Con la replica geográfica permite configurar hasta cuatro bases de datos secundarias legibles en las mismas ubicaciones de centros de datos o en otras (regiones). Las bases de datos secundarias están disponibles en caso de una interrupción del centro de datos o de imposibilidad para conectarse a la base de datos principal.

Si, por cualquier motivo, se produce un error en la base de datos principal o, simplemente, debe desconectarse, puede conmutar a cualquiera de las bases secundarias. Cuando se activa la conmutación, las demás bases de datos secundarias se vinculan automáticamente a la nueva base de datos principal.

La Replicación geográfica implementa un mecanismo para proporcionar redundancia de base de datos en la misma región de Microsoft Azure o en distintas regiones. Esta funcionalidad replica de forma asincrónica las transacciones confirmadas desde una base de datos en hasta cuatro copias de la base de datos en servidores diferentes.

Cuando se configura la replicación geográfica, se crea una base de datos secundaria en el servidor especificado y la base de datos original se convierte en la principal. La base de datos principal replica de forma asincrónica las transacciones confirmadas en cada una de las bases de datos secundarias. Aunque, en un momento dado, la base de datos secundaria puede estar algo retrasada respecto a la principal, se garantiza que los datos secundarios guarden siempre coherencia transaccional con los confirmados en la base de datos principal.

Una de las principales ventajas de la replicación geográfica es que ofrece una solución de recuperación ante desastres en el nivel de base de datos con un tiempo de recuperación muy reducido.

La redundancia entre regiones permite que las aplicaciones se recuperen de la pérdida permanente de todo un centro de datos, o de partes de él, causada por desastres naturales, errores humanos catastróficos o actos malintencionados. En la siguiente ilustración, se muestra un ejemplo de replicación geográfica configurada en una base de datos Premium con una principal en la región centro-norte de EE. UU. y una secundaria en la región centro-sur de EE. UU.

geo-replication-relationship

Una muy buena ventaja de la utilización de bases de datos secundarios es la posibilidad de reducir la carga de la aplicación para los procesos que solo requieren lectura y que muchas veces alteran la performance, como la generación de reportes. Si la replica se la crea con este fin se la puede crear en la misma región que la principal, pero en dicho caso no sería útil como DRP.

Debido a la elevada latencia de las redes de área extensa, la copia usa un mecanismo de replicación asincrónica. Esto hace inevitable cierta pérdida de datos si se produce un error. Sin embargo, es posible que algunas aplicaciones requieran que no se pierdan datos. Para proteger estas actualizaciones críticas, podemos llamar al stored procedure sp_wait_for_database_copy_sync inmediatamente después de confirmar la transacción. La llamada a sp_wait_for_database_copy_sync bloquea el subproceso de llamada hasta que se replica la última transacción confirmada en la base de datos secundaria. El procedimiento esperará hasta que la base de datos secundaria confirme todas las transacciones en cola.

Automatización de Backups SQL Database Windows Azure

Anteriormente publiqué en mi blog una solución para realizar backups automatizados de SQL Database. Actualmente Windows Azure cuenta con la configuración necesaria para realizar esta actividad sin la necesidad de publicar componentes adicionales a nuestra solución.

Para configurar esto debemos seguir los siguientes pasos.

  • Seleccionar la base de datos que deseamos automatizar el backup en el portal de Windows Azure.

image

  • Seleccionamos la solapa de Configuración

image

  • Habilitamos la exportación automática

image

  • Especificamos la cuenta de storage donde se almacenarán los backups y determinamos la periodicidad de los mismos. Si seleccionamos una periodicidad menor a los 7 días nos indicará que puede afectar a la performance.

image

  • Configuramos la cantidad de tiempo que permanezca cada backup en storage

image

  • Por último se ingresan las credenciales de la base de datos y se guardan los cabios de la configuración

image

Una vez que la tarea de backup sea ejecutada podremos revisar el archivo almacenado en storage.

backup

Como pueden ver, en forma automática ha creado un container de blobs denominado automated-sql-export en el cual vamos a encontrar cada uno de los archivos de backup. La nomenclatura del archivo es [server]-[nombre-base-datos]-[FECHA].bacpac. Por tal motivo la misma cuenta de storage puede ser utilizada para almacenar los backups de distintas bases de datos.

Para restablecer una base de datos a partir de un backup generado utilizando este mecanismo podemos ir nuevamente la solapa de configuración donde encontraremos una opción para este fin.

image

image

Seleccionamos el Backup, el nombre de la base de datos y el servidor donde la queremos, permitiendo incluso crear uno nuevo

image

Una vez configurada la restauración y finalizada la ejecución podemos revisar la base de datos creada.

image

image

Replicas entre instancias de SQL Database en Windows Azure – Sincronización de bases de datos

Existen muchos escenarios distintos en los cuales es necesario realizar replicas de datos entre distintas instancias de bases de datos. Entre los más comunes podemos mencionar los esquemas de DRPs (para recuperación en caso de desastres) o bien para centralizar información de distintos puntos.

En el siguiente artículo veremos como podemos sincronizar datos entre distintas bases de datos distribuidas en distintos puntos.

Imaginemos el escenario de un sistema de punto de venta, el cual se encuentra desplegado en distintos datacenters para facilitar el acceso desde varios posiciones geográficas.

bases de datos

Cada uno de estos datacenters atiende las solicitudes de clientes cercanos a la región donde se encuentran.

  • West EEUU atiende las solicitudes de América.
  • Nort Europe atienda las solicitudes de Europa.
  • East Asía atienda las solicitudes de Asia.

Cada una de las bases de datos contiene una porción de la información total del negocio. Si necesitáramos realizar un sistema de reportes y análisis centralizado deberíamos agrupar toda la información dentro de una misma instancia. Por otro lado, en la base de datos centralizada podríamos realizar modificaciones que sean necesario sincronizar posteriormente con cada cliente o con alguno en particular, como aprobaciones de transacciones comerciales superiores a cierto monto. Para este caso, vamos a suponer que es necesario sincronizar datos con la sucursal de Europa.

Esquema de replicación

El modelo de las bases de datos de cada una de las sucursales no es realmente importante, con lo cual desarrollaremos unas tablas en forma simbólica para el ejemplo.

Como se puede ver en la siguiente imagen cada una de las bases de datos se encuentra ubicada en las regiones especificadas anteriormente.

image

Para este ejemplo crearemos 3 tablas básicas.

  • Cliente
  • Producto
  • Pedido

Cada una de estas tablas tendrá un campo Id y un campo Data a modo de ejemplo.

Las tres bases de datos tendrán la siguiente estructura de tablas

image

Y cada una de las tablas tiene los siguientes campos

image

La base de datos que centraliza los datos es la denominada “Replica”. Inicialmente esta base de datos no es necesario que tenga ninguna estructura en particular.

Las tres bases de datos de las sucursales han sido inicializadas con un set de datos similar al siguiente:

image

Una vez que tengamos nuestras tres bases de datos creadas y con datos de prueba debemos configurar el proceso de sincronización.

Recordando el esquema de las bases de datos tenemos lo siguiente:

 image

Para configurar la sincronización debemos ingresar nuevamente al portal de Windows Azure y entrar al listado de Bases de datos de SQL Databasee.

image

Seleccionamos la opción “ADD SYNC” de la barra inferior “New Sync Group”.

Ingresamos un nombre para el grupo de sincronizaciones y seleccionamos un datacenter para la misma

image Seleccionamos la base de datos “Replica” como Hub y debemos especificar si en caso de conflictos se toma en cuenta el valor del Hub o del Cliente. En este ejemplo he seleccionado el cliente.

image

Luego agregamos la primer base de datos. En mi ejemplo será West EEUU. También debemos especificar en que dirección será la sincronización, para este caso será desde el Cliente hacia el Hub.

image

Una vez creado aparecerá una nueva solapa con las sincronizaciones.

image

Si ingresamos a la sincronización que acabamos de crear veremos los siguientes datos:

image

A continuación agregaremos las demás sincronizaciones utilizando la opción “ADD” de la barra inferior. Notar que las opciones de “SYNC” y “STOP” se encuentran deshabilitadas.

Agregamos la sincronización con NorthEuropaDB. En este caso debemos indicar que la sincronización será bidireccional.

image Agregamos la sincronización con EastAsíaDB

imageUna vez que ya hemos agregado todas las bases de datos debemos guardar los cambios utilizando la opción de la barra inferior.

image

En la solapa de configuración encontraremos las opciones necesarias para modificar la contraseña de las conexiones y configurar si deseamos realizar la sincronización en forma automática o manual. Por el momento dejaremos la configuración sin realizar ninguna modificación.

image

Ingresamos en la solapa SYNC RULES para dar de alta las reglas de sincronización.

image

Seleccionamos inicialmente a WestEEUUDB

imageEn la barra inferior utilizamos la opción “Select” => All Columns in All Tables.

image Guardamos los cambios y realizamos el mismo proceso con EastAsíaDB. A este punto podemos notar que la opción “SYNC” ya se encuentra disponible. Para agregar las reglas de EastAsiaDB utilizaremos la opción “DEFINE” de la barra inferior. Por último realizamos el mismo proceso con NorthEuropaDB.

Una vez realizado esto ejecutamos la sincronización utilizando el botón SYNC de la barra inferior.

Al finalizar ingresamos a la base de datos de Replica para revisar el estado de la misma. Dentro de la estructura de tablas podemos identificar que no solo se encuentras las tablas que fueron sincronizadas, también existen tablas de control de sincronización.

image

Dentro de “Replica” encontraremos los siguientes registros

image

image

image

Las bases de datos de WestEEUUDB y EastAsiaDB no han sido modificadas.

Si revisamos la base de datos de NorthEuropaDB cuya sincronización con el Hub es bidireccional encontraremos registros adicionales dependiendo del orden en que las sincronizaciones fueron ejecutadas.

En mi caso la base de datos de Noth Europa tiene los siguientes registros para Pedido

image

En la solapa de Logs podremos visualizar las actividades realizadas

image

Si modificamos algún dato en alguna de las bases de datos de las sucursales en la siguiente sincronización se encontrarán disponibles en el Hub “Replica”. Para el caso de la sincronización bidireccional, serán sincronizados aquellos datos que hasta el momento se encuentren en el Hub. Por tal motivo, al realizar una modificación en WestEEUUDB o en EastAsiaDB puede requerir de dos sincronizaciones hasta llegar a NortgEuropaDB (puede ser sincronizado en la primera o en la segunda vez).

Por último, si así lo deseamos, podemos volver a la página de configuración para automatizar el proceso.

Migración de SQL Server a SQL Database (SQL Azure) – Campos encriptados en base de datos

Muchas veces cuando realizamos un migración de una base de datos SQL Server a SQL Database nos encontramos con campos que se encuentran encriptados utilizando la encriptación nativa de SQL.

El siguiente mecanismo es una forma muy simple de solucionar este problema. No es la única forma de realizarlo, pero este mecanismo nos puede ayudar a resolver rápidamente el conflicto.

La estrategia para resolver este problema es encriptar los campos en código antes de escribirlos en la base de datos y desencriptarlos al leerlos.

En el siguiente link se podrán descargar el código de ejemplo para realizar esto de manera simple en C#. También se podría realizar utilizando un certificado, pero el código de ejemplo utilizado aquí no tiene ninguna dependencia.

image

Método para encriptar.

image

Método para desencriptar.

image

Automatización de Backup de SQL Database Windows Azure

Una actividad frecuente que debemos realizar de nuestras bases de datos en producción es el BackUp. Si bien Windows Azure nos ofrece varias copias de nuestra instancia de SQL las cuales se replican automáticamente, debemos asegurarnos de que si hubiera algún cambio de datos por un error en un proceso o un error humano estas réplicas no tendrán la información anterior y por otro lado no podemos solicitar la visualización de las mismas. Las replicas solo están para asegurar un nivel de servicio.

Por tal motivo es necesario realizar frecuentemente actividades de BackUp. Para no depender de la realización manual de esta actividad y automatizarlo en un proceso, podemos utilizar la siguiente solución de codeplex la cual implementa en un worker role el proceso de BackUp:

http://azureautobackup.codeplex.com/

Él código que realiza la tarea de backup es muy simple, con lo cual si fuera necesario podemos quitarlo de la solución en la que se encuentra e implementarlo en cualquier proceso que nosotros ya tengamos como parte de nuestra arquitectura.

Trazabilidad de sesiones en SQL Database Windows Azure

Cuando un error ocurre en nuestra aplicación es importante contar con toda la información necesaria para determinar la causa y dar una solución al problema.

Con este fin, es importante que podamos contar con la información de errores y logs para el análisis del error.

En SQL Database existe un campo denominado TraceId para conexión que establecemos con la base de datos. Este id es un GUID único para cada una de nuestras conexiones y podemos utilizar el mismo para que el equipo de Soporte de Windows Azure rastree la conexión y de esta forma obtener la información de errores y logs realizados por esa conexión. Por tal motivo, al realizar un log de un error en nuestro sistema donde intervino una operación de base de datos debemos almacenar este identificador.

Para poder obtenerlo basta con ejecutar la siguiente sentencia contra la base de datos, debemos recordar que este identificador es por conexión así que debemos realizarlo en cada una de ellas.

image