thesolidqjournal database administration

Por Enrique Catal

32

Personalizacin de Log Shipping para consolidar la informacin

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 de cara al anlisis y la toma de decisiones.

l hecho de que Log Shipping fuese una de las primeras soluciones fciles de usar para sistemas de alta disponibilidad en SQL Server no significa que no sea vlida hoy para muchos problemas del mundo real. En este artculo, veremos cmo hacer buen uso de Log Shipping ms all de la configuracin estndar para consolidar datos en entornos distribuidos eficaz y rpidamente, mediante el uso de un sistema de paquetes de SQL Server Integration Services (SSIS) generado automticamente. La centralizacin de informacin en entornos distribuidos es una necesidad tpica en modelos de negocios basados en la franquicia, por ejemplo. Cada franquicia tiene su propio entorno de aplicaciones distribuidas. Como, por lo general, este tipo de entorno evoluciona con el tiempo, la comunicacin electrnica entre distintas ubicaciones con sus propios servidores y bases de datos puede ser un problema. Y como cada franquicia tradicionalmente tiene sus propios datos independientes y aislados del resto de franquicias, es difcil mantener servicios centralizados para toma de decisiones y anlisis de la informacin de negocio. Log Shipping, sin embargo, permite, con un mnimo impacto en desarrollo e implementacin, centralizar los datos para la posterior consolidacin y anlisis.

Visin general del Log Shipping

En trminos generales, Log Shipping automatiza el proceso de restauracin de una copia de seguridad del registro de transacciones a otra base de datos en otro sistema. La figura 1 muestra los elementos comunes de un trasvase.

Figura 1: Elementos de Log Shipping

A menudo se opta por Log Shipping como una solucin de consolidacin y centralizacin de datos, ya que cumple una serie de requisitos estndar:

The SolidQ Journal, Enero 2011 www.solidq.com/sqj

33

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 (BI) de negocio. 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. Adems de estas caractersticas, el trasvase de registros tambin admite a la transferencia de datos a varias instancias de SQL Server. As que si es necesario, puede enviar copias de seguridad de las transacciones automticamente a varias instancias de SQL Server en los servicios centrales. En resumen, puede confiar en Log Shipping como medio para facilitar la consolidacin de la informacin mediante arquitecturas como las de la figura 2.

Figura 2: Arquitecturas tpicas de Log Shipping

The SolidQ Journal, Enero 2011 www.solidq.com/sqj

thesolidqjournal database administration

34

Utilizando un modelo de negocio basado en la franquicia como ejemplo, vamos a repasar algunos trminos clave con los que debera familiarizarse respecto a Log Shipping: Rol Principal El Rol 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. Tenga en cuenta que Log Shipping es una configuracin a nivel de base de datos, por lo que cuando se habla de Rol, estamos pensando en trminos de la base de datos. Rol secundario: El Rol Secundario es el SQL Server que aloja la base de datos restaurada que es objeto del proceso de Log Shipping desde el Rol Principal. Servicios centrales: Es la Oficina central donde queremos consolidar todos los datos. Los servidores de SQL Server en servicios centrales 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 principal (o central) en la arquitectura de Log Shipping. En general, Log Shipping realiza automticamente las siguientes operaciones: 1. Crea una copia de seguridad del registro de transacciones de la base de datos en el servidor subsidiario a intervalos regulares que se pueden configurar.

2. Copia ese Backup (copia de seguridad) en el servidor de backup (en la red de servicios centrales). 3. Restaura la copia de seguridad del registro en el servidor SQL en servicios centrales con la frecuencia necesaria, dejndolo en modo NORECOVERY o en STANDBY. Adems de estos pasos, tambin necesita eliminar copias de seguridad antiguas despus de un perodo de tiempo y realizar otras tareas de mantenimiento de Log Shipping. Para obtener informacin acerca de cmo administrar el Log Shipping, vea Log Shipping Administration en los Libros en Pantalla de SQL Server 2008 R2.

Modificaciones menores para una solucin personalizada

La configuracin de Log Shipping estndar est diseada para un entorno de Active Directory (AD). Sin embargo, en un escenario tpico basado en franquicias, cada filial generalmente tiene su propio AD, totalmente independiente de la Oficina central. 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 las copias de seguridad del registro de transacciones que deben restaurarse en el servidor de destino. Por ejemplo, la cuenta que ejecuta el agente de SQL Server en el servidor secundario (en servicios centrales) debe tener acceso de lectura en la red donde el servidor principal almacena las copias de seguridad. Esta configuracin es simple en una topologa administrada bajo un solo dominio de AD, pero resulta complicada cuando ese no es el caso y es necesario configurar la seguridad de paso a travs, o relaciones de confianza entre dominios. La seguridad de paso a travs es una tcnica que permite a un usuario local de Windows acceder a un recurso remoto sin ningn AD o configuracin de Kerberos. Bsicamente, los dos roles deben tener el mismo usuario local de Windows con la misma contrasea. Puede configurarse una aplicacin llamada por ese usuario local para acceder al servidor secundario. Sin embargo, la seguridad de

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 las copias de seguridad del registro de transacciones que deben restaurarse en el servidor de destino.

The SolidQ Journal, Enero 2011 www.solidq.com/sqj

35

paso a travs no es til para nuestro escenario de franquicia del ejemplo porque hay potencialmente cientos de diferentes filiales que necesitaran configurar la seguridad de paso a travs. Aunque la configuracin de Log Shipping estndar no es viable para un entorno tpico de franquicia, podemos hacer algunas modificaciones menores de la configuracin para adaptarla a esa situacin. El concepto principal en nuestra solucin personalizada de Log Shipping es que en lugar de lanzar una tarea que copie los archivos de backup en la ubicacin central de servicios centrales, cada filial ejecuta un trabajo que copia los archivos en un repositorio FTP en la ubicacin central. Esta implementacin deja intacta la parte de la operacin que utiliza la aplicacin sqllogship.exe, 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. Para personalizar este escenario de Log Shipping, slo necesita asegurarse de que se dan los siguientes requisitos previos: 1. Un servidor FTP en la ubicacin central en un dominio (vamos a llamarle Contoso, por ejemplo) al que las filiales puedan acceder. Suponga que ha configurado el servidor FTP con una direccin IP 172.16.2.249. Por razones de seguridad, debe asegurarse de que servidor es accesible slo a travs de una VPN y sin acceso a una extranet. Tambin se recomienda que el servidor FTP se ejecute en un sistema diferente al del alojamiento de los servicios de SQL Server. 2. La cuenta que ejecuta la tarea debe ser una cuenta vlida en el mismo dominio Contoso, en lugar de un usuario local. 3. Compartir una carpeta en el FTP para que el usuario que ejecuta al agente SQL Server desde dentro del dominio Contoso tenga acceso de lectura/escritura. En nuestro ejemplo, sera la carpeta \\172.16.2.249\backups_ftp, y sera accesible slo desde dentro del dominio Contoso de servicios centrales. 4. Disponer de software como FileManager (u otra aplicacin similar) configurada correctamente, por ejemplo, en un clster, para utilizar cualquier

ruta en un recurso de clster. FileManager es una utilidad de Solid Quality Mentors que copia los archivos de origen de una fuente a otra utilizando diferentes protocolos como el FTP. Incluye las siguientes caractersticas, que son importantes en nuestra aplicacin Log Shipping: a. Un mecanismo que pueda copiar a travs de FTP todos los nuevos archivos de .trn que no se hayan copiado. La utilidad no copia 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 .trn que existan en la ruta de acceso FTP, gestionando la eliminacin de los archivos .trn restaurados despus de un nmero indicado de das. Esperamos que este artculo le ayude a comenzar con la personalizacin de su solucin de Log Shipping para un entorno tipo franquicia. En un prximo artculo, veremos cmo aplicar la configuracin para consolidar la informacin en una aplicacin distribuida cuando cada servidor SQL est disperso geogrficamente y cada entorno est aislado del resto con su propio dominio.

Sobre el autor
Enrique Catal (blog)es un mentor con Solid Quality Mentors en Espaa, especializado en el motor relacional de SQL Server, la resolucin de problemas de rendimiento y la aplicacin de sistemas OLTP altamente escalables y altamente disponibles. Es MCT, MCITP, MCTS y Microsoft Active Professional (MAP) 2010. Es arquitecto principal de la solucin SolidQ Health Check, SCODA, y del Generador SSIS. Recientemente escribi el Planning for SQL Server Migration to SQL Server 2008 from 2000-2005 (ISBN: 978-84936417-6-4). Ha presentado Webcasts para el lanzamiento oficial de Microsoft SQL Server 2008 y colabora con Microsoft en la creacin de Webcasts y conferencias de MSDN y TechNet. Adems del blog El Rincn del DBA, que mantiene junto a otros colegas de Solid Quality Mentors, tambin lleva su propio blog personal.

The SolidQ Journal, Enero 2011 www.solidq.com/sqj