Nueva solución de alta disponibilidad para SQL Server 2012, de hecho, Always On en realidad no es ninguna tecnología, es un paraguas que cubre un abanico muy amplio de tecnologías, donde quizás la tecnología mas reconocida de ese abanico sea los Grupos de Disponibilidad (Availability Groups).
Se basa básicamente en disponer de un cluster de N nodos de Windows (Microsoft Cluster Service), sobre los cuales instalamos instancias no clusterizadas de SQL Server. Una vez que tenemos las instancias instaladas, cada una con sus discos locales, podemos establecer una especie de Mirroring entre ellas, de modo que se nos presenta una especie de mezcla entre Cluster y Mirroring.
Para entenderlo, supongamos un escenario de distribución geográfica:
Primero supongamos que tenemos un servidor, el cual queremos dotarlo de una muy alta disponibilidad, una de las soluciones podría ser montar Database Mirroring tradicional de SQL Server 2005 sobre una maquina en el mismo RAC, aprovechando la cercanía y de que se puedan conectar directamente podemos recurrir a una copia síncrona, lo cual, esta copia síncrona garantiza que nuestros datos están en ambos sitios, dándonos una alta disponibilidad… Lo interesante de la nueva tecnología que nos ofrece Always On, en contraste con Database Mirroring, es que nuestros clientes no se van a conectar al nodo directamente a través de un nodo testigo, si no que se van a conectar a un recurso de cluster que es el grupo de disponibilidad que es el único recurso de cluster que hay por defecto en Always On. (No hay una necesidad de disponer de un disco compartido por o para cada recurso de cluster.)
Muchas empresas recurren a soluciones basadas en Mirroring, por que sale bastante mas económico que la replicación entre cabinas…
Database Mirroring nos limita en cuanto a la cantidad de replica que podemos tener, en Always On podemos tener hasta 4 replicas con diferentes configuraciones: síncronas o asíncronas, y/o dotarnos de un servidor situado en una zona geográfica distinta, y para no de pender de que la red tenga que ser ultra rápida, dada la lejanía, se puede establecer la replica de forma asíncrona. Con lo cual, vamos a poder tener, copias síncronas y/o asíncronas simultáneamente. No es un Activo—Activo simultáneamente, más bien es un Activo_Escritura_Lectura—Activo_Lectura gracias que una de las replicas puede funcionar en modo lectura, sin entrar en detalle…
En Database Mirroring, nosotros teníamos la base de datos que estaba en espejo, siempre en norecovery, siempre aplicando los cambios del log de transacciones. Y en Always On, nosotros podemos tener la base de datos espejada en modo de lectura, permitiéndonos una variedad muy amplia de escenarios. Por ejemplo, si tenemos un sistema OLAP y tenemos que hacer un proceso con Cubos, podemos hacer que una parte ataque a la replica y no afecte al sistema transaccional, normalmente este escenario no lo vamos a tener en un Datawarehost, aunque pueden darse casos... Otro ejemplo que también es muy recurrente, y se dan en escenarios donde tenemos un Reporting Service que queremos acceder a datos muy transaccionales, donde puedo tener mi replica en el mismo RAC (o en Azure), a la cual atacaría con el Reporting…
Destacar la posibilidad de hacer backup (definir una política) sobre los otros nodos que están haciendo una copia síncrona o asíncrona de los datos. Se puede disponer de un nodo (destinando o no) solo para realizar los backups, dejando de cargar a los usuarios desarrolladores y demás con estas tareas, hay ciertas tareas concretas que no se pueden hacer pero muchas si….
Destacar la posibilidad de que SQL Server se autocorrija a si mismo en caso de que detectara un fallo de página, iría a la replica y buscaría la pagina correcta para que automáticamente se recomponga la pagina con error…
Fuentes:
Microsoft, msdn, TechNet blog...
Apunte y recopilación por Norman M. Pardell
