Alta Disponibilidad

Bases de Datos para la Administracin

Gonzalez, Javier Martinez, Cristian Provenzano, Matias Leyva, Favio

Alta Disponibilidad (HA)

Por qu Alta Disponibilidad? Es importante ahorrar tiempo en los negocios para satisfacer las demandas de los clientes Cuando los sistemas no funcionan, las empresas pierden ingresos, oportunidades, clientes y reputacin La alta disponibilidad reduce el impacto de las operaciones diarias necesarias para el mantenimiento y ayuda a una recuperacin rpida frente a los desastres Los negocios requieren flexibilidad para desarrollar fcilmente soluciones de disponibilidad alta para atender las necesidades del negocio y la tecnologa Minimizar o evitar el tiempo de inactividad de servicio Planificado o No Planificado Cuando los componentes fallan se produce una interrupcin del servicio breve o inexistente. Conmutacin por error automtica Eliminar los puntos nicos de fallo Componentes redundantes Servidores con tolerancia a fallos.

Componentes Redundantes Enfoque: Utilizar componentes redundantes para el servicio de base de datos Nodos de servidores de base de datos Componentes de Servidor ECC RAM; HW y SO tolerante a fallos. Instancias de Sistemas de Gestion de Base de Datos (SGBD) Bases de datos de usuarios Dispositivos de almacenamiento Componentes de dispositivos de almacenamiento MPIO: Interfaces; paths; switches; controllardoras RAID: Discos Red MPIO: Interfaces; paths; switches Copia de datos Ej: Recuperacin de pginas daadas en Mirroring

Nivel Bajo - sin recuperacin automtica con posible prdida de datos

Backup / Restore

Failover Clustering Database Mirroring

Nivel Medio - recuperacin manual con posible prdida de datos

Log Shipping Replicacin

Log Shipping

Nivel Alto - recuperacin automtica sin prdida de datos

Database Mirroring Failover Clustering

Replicacin

Backup / Restore

El log Shipping es una automatizacin de backupcopia-restauracin del log de transacciones, basado en SQL Server Agent. Esto sirve para tener alta disponibilidad en SQL Server con un mtodo barato y sencillo. Con este modo, bsicamente lo que hacemos es tener una o ms instancias de SQL Server en modo de slo lectura en las que restauramos el log de cambios de la base de datos principal cada cierto tiempo.

Servidor principal realiza backup del log de transacciones (.trn) con periodicidad X (generalmente en una carpeta compartida del servidor) Servidor secundario copia backups de la carpeta compartida a una ubicacin local con periodicidad Y (el usuario que levanta SQL Agent debe tener permisos de lectura sobre la carpeta compartida donde el servidor principal deja el backup) El servidor secundario restaura dicho backup con una periodicidad Z (los backups son restaurados en orden y en el caso de que surja algn problema no se continua con la restauracin) Adicionalmente, puede existir un servidor de monitorizacin, donde podemos controlar la informacin sobre el estado de todos los servidores que forman parte de Log Shipping. Por ejemplo tendremos el historial y estado de las operaciones de backups (que estarn disponibles tanto en el servidor principal de LScomo en el de monitoreo; lo mismo pasa con los restores realizados que se hayan en los servidores secundarios y en el monitorizacin. Tambin, podremos configurar alertas por si no se ejecuto algn job, o estos tienen errores, etc. El servidor secundario es quien lanza la copia y trae la informacin del servidor principal

Permite la centralizacin de bases de datos de todas las filiales en un nico servidor, lo que permite aprovechar los datos y la informacin a travs de herramientas de inteligencia de negocio (BI). Permite transferir fcilmente los datos a intervalos regulares y definidos, lo que significa que no necesitamos mantener constantemente una conexin abierta, minimizando as el riesgo de fallo en la conexin. Permite auditar automticamente el estado de configuracin, reduciendo el trabajo del DBA. Permite el uso de la base de datos central como una copia de seguridad en caso de fallo de un servidor de SQL Server en una de las filiales Permite la configuracin automtica a travs de la implementacin de secuencias de comandos de T-SQL, minimizando los errores de intervencin manual.

El servidor secundario y principal deben estar en el mismo dominio AD y con visibilidad entre ellos, o en distintos dominios pero con relacin de confianza
No existe tolerancia a fallos, es decir, si algn archivo de backup se corrompe y no es posible restaurarlo, la base de datos secundaria queda en estado inestable y sin poder recibir ms restauraciones (des-sincronizacin) Esta des-sincronizacin no puede repararse de manera automtica, sino que hay que hacerlo de forma manual

La principal diferencia con el mirror, es que el log shipping permite tener la segunda instancia en modo Standby, lo que permite acceder a esta instancia en modo slo lectura (readonly). Hay muchas empresas que por ejemplo tienen la base de datos online (instancia primaria) con todo el negocio y luego tienen las instancias secundarias en modo slo lectura, por ejemplo con los reportes de SQL Server para no cargar a la primaria. Otra diferencia es que pueden tenerse ms de una instancia secundaria, cosa que en el mirror, slo puedo tener una secundaria. La principal desventaja con el mirror se refiere al failover automtico que no tenemos en Log Shipping, sino que lo tenemos que hacer de forma manual.

Ejemplo de Escenario

La configuracin estndar Log Shipping no funciona en entornos basados en franquicias, donde los servidores no forman parte del mismo dominio de AD. Pero con algunas modificaciones menores, se puede utilizar Log Shipping para consolidar la informacin de varias filiales para el anlisis y la toma de decisiones con los datos consolidados.

Entonces por ejemplo tenemos una empresa de venta de ropa donde hay alrededor d 100 sucursales con franquicia distribuidas geografiamente por todo el pas y cada una con su dominio propia; por lo que necesitamos consolidar las diferentes bases de datos en un nico Centro de Procesamiento de Datos (CPD) para la toma de decisiones y anlisis de inteligencia de negocio (BI). La conexin entre las distintas sucursales y el CPD es muy lenta y de baja calidad

El problema principal en una configuracin de Log Shipping entre servidores que no son parte del mismo dominio de AD es que es imposible conceder acceso a las carpetas que contienen los backups que deben restaurarse en el servidor secundario. Nuestra solucin de Log Shipping es, en lugar de lanzar una tarea que copie los archivos de backup en una ubicacin compartida del servidor, cada sucursal ejecuta una tarea que copia los archivos en un repositorio FTP. Esta implementacin deja intacta la parte de la operacin que utiliza la aplicacin de Log Shipping, asegurando que la administracin de backups y restores, -as como el seguimiento del Log Shipping mediante informes de estado y alertas del servidor- se lleva a cabo normalmente.

1.

2.

3.

4.

Un servidor FTP, al cual las sucursales puedan acceder. Se recomienda que el servidor FTP se ejecute en un sistema diferente al del alojamiento de los servicios de SQL Server. La cuenta que ejecuta la tarea debe ser una cuenta vlida en el mismo dominio donde se haya el CPD Compartir una carpeta en el FTP para que el usuario que ejecuta al agente SQL Server desde dentro del dominio del CPD tenga acceso de lectura/escritura. Disponer de un software (por ejemplo, FileManager) que tenga: a. Un mecanismo que pueda copiar a travs de FTP todos los nuevos archivos de backups que no se hayan copiado. Este software no deber copiar el mismo archivo ms de una vez y controla los envos, as como los errores de red posibles que se produzcan. b. Un mecanismo para eliminar los archivos de backup que existan en la ruta de acceso FTP, gestionando la eliminacin de los archivos restaurados despus de un nmero indicado de das.

Servidor Principal: es la instancia de SQL Server en la configuracin de Log Shipping que aloja la base de datos principal que queremos "distribuir" a otra instancia de SQL Server. Servidor secundario: es el SQL Server que aloja la base de datos restaurada que es objeto del proceso de Log Shipping desde el Servidor Principal. CPD: Es la Oficina central donde queremos consolidar todos los datos. Los servidores de SQL Server en CPD desempearn un papel secundario porque es donde se restaurarn los datos. Franquicia : La franquicia es el entorno aislado desde el que queremos obtener los datos. Cada franquicia desempear el rol de Servidor Principal (o central) en la arquitectura de Log Shipping.

La replicacin es un conjunto de tecnologas para la copia y distribucin de datos y objetos de base de datos de una base de datos a otra.

Luego se sincronizan las bases de datos del grupo para mantener la consistencia

La rplica permite distribuir datos a diferentes ubicaciones ya sean usuarios remotos o mviles mediante: Redes de rea local y amplia Conexiones de acceso telefnico Conexiones inalmbricas Internet

Un escenario tpico consiste en la sincronizacin de servidores de bsqueda locales o regionales para un mejor rendimiento con el servidor principal de forma peridica, o sincronizar con un sitio remoto de recuperacin de desastres.
La replicacin se utiliza normalmente en escenarios de servidor a servidor que requieren un alto rendimiento, tales como:

- SNAPSHOT

- TRANSACTION

- MERGE

Poca frecuencia de cambios de datos. Es aceptable tener copias de los datos que estn fuera de fecha con respecto a la publicada, por un perodo de tiempo. Replicar pequeos volmenes de datos. Un gran volumen de cambios se produce en un corto perodo de tiempo.

Se desea que los cambios incrementales se transfieran a los suscriptores a medida que ocurren. La aplicacin requiere baja latencia entre los tiempos de modificaciones que se realizan en el Publicador y los que llegan al suscriptor. La aplicacin requiere acceso a los datos de los estados intermedios. El Publicador tiene un volumen muy alto actualizaciones. El Publicador o Suscriptor es una base de datos no es de SQL Server, como Oracle.

Varios suscriptores pueden actualizar los mismos datos en varias ocasiones y propagar los cambios al Publicador y otros suscriptores. Los suscriptores deben recibir los datos, realizar cambios sin conexin y despus sincronizar los cambios con el publicador y otros suscriptores. Los conflictos pueden ocurrir y, cuando lo hacen, es necesario la capacidad de detectar y resolverlos. La aplicacin requiere datos netos en vez del acceso a los datos de los estados intermedios.

Agente SQL Server

Agente de Snapshot
Agente de lectura de registros Agente de distribucin Agente de mezcla Agente de lectura de cola

Agente de seguridad
Administracion de roles Lista de accesos a Publicadores

Filtros de datos publicados

Microsoft SQL Server Replication Monitor

Microsoft SQL Server Management Studio Transact-SQL and Replication Management Objects (RMO) Alerts for replication agent events System Monitor

NO TIENE ENCRIPTACION ALTO COSTO DE MANTENIMIENTO TANTO DE SOFTWARE COMO HARDWARE NO PERMITE REALIZAR FAILOVER AUTOMATICAMENTE PUBLICADORES (> SQL Server 2005 Solamente) NO PROPORCIONA DETECCION O RECUPERACION ANTE CONFLICTOS (< SQL Server 2008) METADATA Y OBJETOS FUERA DE LA BASE DE DATOS NO SON REPLICADOS

 Es una solucin para suministrar alta disponibilidad a nivel de base de datos Opuesto al clustering, el cual satisface la necesidad de alta disponibilidad a nivel de instancia Nos ahorramos la necesidad de una cabina de discos para almacenar las bases de datos Database Mirroring NO puede ser considerado como un sustituto a Clustering

Transparente para el cliente

Recuperacin rpida

Sin perdida de datos

Servidor Principal
Conecta las aplicaciones y recibe las transacciones

Servidor Mirror
Recibe los logs de transacciones del Servidor Principal y las aplica en la base de datos reflejada

Servidor Witness (Opcional)

Monitoriza el estado en que se encuentran los servidores Principal y Mirror

 Aumenta la proteccin de los datos

Proporciona una redundancia completa o casi completa de los datos, en funcin de si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento Incrementa la disponibilidad de una base de datos Resuelve errores de lecturas de paginas Mejora la disponibilidad de la base de datos de produccin durante las actualizaciones

Alto Rendimiento
Asncrono sin testigo

Failover manual Posible prdida de datos Mayor rendimiento

Alta Proteccin
Sncrono sin testigo

Failover manual Sin prdida de datos

Alta Disponibilidad
Sncrono con testigo

Failover automtico Sin prdida de datos

Cliente

1. Transaccin

7. Reconocimiento Testigo (ACK) 2. Transfiere a espejo

6. Reconocimiento (ACK)
2. Escribe en Log 3. Log escrito 4. Escribe en log Log

Data

Log

Data

Principal

Mirror 5. Log escrito

Cliente

5. Transfiere a espejo 4. Reconocimiento (ACK) 8. Reconocimiento (ACK) 2. Escribe en Log Data Log 3. Log escrito 6. Escribe en log

1. Transaccin

Principal

Mirror

Log Data 7. Log escrito

 Conmutacin automtica por error Tiempo Deteccin del error Tiempo Conmutacin por error
Conmutacin manual Forzada Tiempo Deteccin y respuesta humana. Tiempo Conmutacin por error Deteccin de errores El tiempo que necesita el sistema para detectar un error depende del tipo de error Error de Red: instantneo (~1s) Bloqueo del servidor: predeterminado 10s

Escenario Simple

Escenario Simple Clustering + Mirroring

Conjunto de dos o ms mquinas que se caracterizan por mantener una serie de servicios compartidos y por estar constantemente monitorizndose entre s.

Si se produce un fallo del hardware o de las aplicaciones de alguna de las mquinas del cluster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios que han fallado en cualquiera de las otras mquinas del cluster.

Cluster Nodo Instancia SQL Server BD

Active-Active

Active-Pasive

Windows Failover Cluster service se Activa

Actualizacin de Software en Nodos Pasivos en vez de Activo. Transparencia ante el usuario final. Active-Active: Uso del hardware al 100%

No mejor performance. Activo-Pasivo: Servidor libre, sin uso. Dependencia de Switch SAN (alto costo) Active-Active: en caso de Failover puede que el nodo resultante quede sobrecargado.

Active-Active: Todos los servicios de todas las instancias pueden correr en un nodo. Active-Pasive: Cuando el costo de los equipos y licencias no es un problema.

Redundancia a nivel de Instancias de SQL Server Mejora ante Failover y no performance.